The "ideal" SJTAG Gateway

Discuss the generic proposals for SJTAG
Post Reply
User avatar
Ian McIntosh
SJTAG Chair
Posts: 415
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK
Contact:

The "ideal" SJTAG Gateway

Post by Ian McIntosh » Mon Nov 28, 2011 8:06 pm

Let's try to collect thoughts on what features or behaviours we each see as important to us in selecting (or designing) a chain management device. If you have more than one scenario/application then you can offer multiple suggestions, even if they seemingly conflict. Any aspect of function or management is "fair game", but try to avoid mixing in software tooling issues.

Preferably, against each attribute, briefly give the reason or requirement that makes that feature desirable. Include things that you consider "nice to have, but not essential" if you wish, but please indicate if that is the case.

Feel free to come back and add to or edit your suggestions after reading the contributions from others.

See also Tim's loosely related topic: Gateway communication.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Tim Pender
SJTAG Member
Posts: 19
Joined: Wed Mar 12, 2008 9:21 pm
Location: Eastman Kodak, Rochester, NY

Re: The "ideal" SJTAG Gateway

Post by Tim Pender » Mon Nov 28, 2011 9:00 pm

Attributes
  • Support Multiple Hosts- external and embedded JTAG control or redundant controller, simple arbitration would be required if multiple hosts are connected
    Support Multiple Chains -
    "Local" Scan Chain Selection Discrete Input - one control bit for each chain for local control. Active signal input will insert scan chain in the scan path
    "Remote" Scan Chain Selection - one control bit for each chain, controlled via protocol (jtag register, i2c etc)
    Transparency between host and chain
    Sense Scan Chain Power - unpowered or powered scan chain
    Addressable
    Support Gateway Heirachy- when gateway is connected to a chain of another gateway
Last edited by Tim Pender on Tue Nov 29, 2011 2:17 pm, edited 1 time in total.

User avatar
Michele
SJTAG Established Member
Posts: 31
Joined: Wed Nov 11, 2009 8:39 am
Location: Grenoble, France

Re: The "ideal" SJTAG Gateway

Post by Michele » Tue Nov 29, 2011 9:46 am

My "ideal" attributes would be:
1- clear I/Os
2- no "a priori" on internal chain handling
3- Programmable internal state
4 - readback of internal state (optional)
5- transparent (Standard-compliant) when state is fixed


What I mean is that I a gateway should be easily instantiated (1) without any need of knowledge of its internal working (2). Its internal state should be programmable (3),ideally from the "SJTAG language", or also by special tools if needed, and if possible it should be possible to access it from the scan chain (4). Last and more important point, once that the gateway has been programmed to a given state, it should become transparent and expressible though standard construct (BSDL, P1687, .7, etc). This would enable (legacy and not) tooling to delegate the gateway handling to external components (not necessarily JTAG), receiving back a workable description of its state.

User avatar
Ian McIntosh
SJTAG Chair
Posts: 415
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK
Contact:

Re: The "ideal" SJTAG Gateway

Post by Ian McIntosh » Wed Nov 30, 2011 8:10 pm

I'm going to consider this from the perspective of using an external tester, primarily for the Interconnect Test and Programming/Update use cases. I've looked at some embedded cases and I know that I'd have additional criteria there, but I haven't thought those through as much.
  1. The option to configure a fully transparent path (i.e. with no addressing or pad/synch bit inserted in the stream) to a downstream chain, such that device vendor tools can be used with the minimum of fuss. Ideally, it should be possible to enable this using a single discrete signal using a simple logic state (e.g. pull a pin to ground). I acknowledge that at a board level this may only give me transparent access to a single chain on the board and at system level I may have access to a single chain in the system, but I can work with that. I don't want to use some other tooling to set up the board/system prior to using the vendor tools - that's too complicated for test/service engineers to work with.
  2. Support multiple chains. Three is probably a minimum, but five is possibly a more generally useful number in our applications.
  3. Addressable, on a multidrop bus configuration. Having a switched star type of configuration probably means putting the device on the backplane, and I'd prefer to keep active devices off the backplane if possible: It's usually the hardest part of the system to swap out in the event of a fault. Probably needs at least four address bits (three is definitely too few). In fact, where the gateway address is set by picking up a "slot code" from the backplane then we often use one of the addressing pins as a "parity bit" to reduce the risk of a single bad connection causing a conflict, so extra addressing space is "a good thing".
  4. Support a hierarchy of gateways (this is maybe more of a tooling issue). I can require all in-house designed boards in a system to use the same gateway device, but I may have one or more 3rd party/COTS boards that are selected after the system is designed that may have a different gateway part or not have a gateway device at all. I want to put these boards in the chains of a gateway that I do know about (that maybe means breaking my rule in 3., but that's life).
  5. Support for chains operating at different signalling levels. With parts operating at various core and IO voltages, being able to avoid additional level shifters for a "test feature" is desirable. Need to minimize the board real estate that gets consumed for non-operational features.
  6. Avaliable package options: Generally we want a small pysical size and easy assembly, so that means BGA packages are preferred. But if we do have to put a gateway on a backplane then via aspect ratios in thicker PCBs force moving to QFP or similar.
Not all the above are necessarily relevant to SJTAG, but I'm just getting my thoughts down. And the above list seems to be too short to me, so I may re-visit it later.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: The "ideal" SJTAG Gateway

Post by Bradford Van Treuren » Mon Dec 05, 2011 1:57 pm

An additional issue is whether the application needs to perform testing across boundaries of addressable boards. This is often the case when performing backplane testing between boards or cable testing between boards. In these cases, it is generally necessary to be able to park a board in a stable TAP state while transitioning control from one board under test (UUT) to another to capture observed values driven by the first. This is generally accomplished by either freezing the TMS signal for the parked board or shutting down the TCK. The prior is the preferred method. If the application does not need this inter-board testing ability, then the parking feature is unnecessary.

Others have mentioned modes whereby an external conditioning signal is available to force a particular state of the gateway. Concatenating all the chains together is the ideal case for ICT test tooling, so a single pin that could be driven by the ICT tester to force a single chain configuration would be a good thing.

There should also be a way of disabling the secondary chain output of the gateway for when specialized tooling (e.g., emulation pods or FPGA programming pods) are to be controlling the secondary chain. This is especially important for the case where multiple emulation pods are required concurrently (e.g., CPU and DSP simultaneous code debugging.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

Post Reply