Gateway communication

Discuss the generic proposals for SJTAG
Post Reply
User avatar
Tim Pender
SJTAG Member
Posts: 19
Joined: Wed Mar 12, 2008 9:21 pm
Location: Eastman Kodak, Rochester, NY

Gateway communication

Post by Tim Pender » Mon Mar 17, 2008 4:17 pm

Gateway communication
The selected jtag chain needs to match that of the programming files so gateways need the knowledge of which path to select. Is this something accopmlished with extra traces beyond the tap pins or can data be shifted in via tap pins in stable states other than shift states (like TI shadow protocol).
I don't like Jtag partitioning devices that are "In" the chain because it creates too many issues with DSP and PLD vendor tools. I prefer a transparent gateway that select the path based on user input. Do you want to standardize scan path selection into a programming file, like a scan path selection register, individual gateways would need to interpret it to make the path selection. Program file generators would have to create an scan path selection action that could be read by a gateway. Or should a separate sequence file be needed.

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

Post by Ian McIntosh » Mon Mar 17, 2008 7:42 pm

This is an important question because it goes beyond just programming: It is probably pivotal to establishing what makes a good SJTAG-able design, what the tooling needs to support, etc.
ATCA doesn't even give us *TRST in the TAP so requiring additional signals fir scan chain selection is a non-starter there. But ATCA is only one example and we shouldn't assume that it represents "best practice".

I don't really have any issue with the use of "in-the-chain" selectors: For the most part my tooling deals with most of the issues that they throw up, at least as far as production test and programming is concerned. However they do cause mayhem with things like microcontroller emulation tools that use the TAP in non-compliant modes. But that's usually only an issue during development/design proving. For this reason we have the concept of "Backplane TAP" and "Frontplane TAP": The Backplane TAP is the normal, single TAP that is used at system level, while the Frontplane TAP(s) can only be got at with the covers off, and basically breaks into individual chains downstream of the switch.

I'm not saying this is a good solution (it creates routing and signal integity problems, for instance) but it's the workaround that we have.

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

Post by Tim Pender » Tue Mar 18, 2008 5:17 pm

Most emulator tools do not like "in the chain" gateways. The gateway chip is needed to easily isolate the emu Jtag chain for emulation and also link these into the chain durring boundary scan testing. During the early development stages boundary scan access is also needed to verify on board interconnect, firmware programming, etc. The Boundary scan host should have access to all JTAG devices throughout the entire life cycle. Maximum flexibility is key, support multipe hosts, multiple chains, support manual and software control over which host is connected to each chain.

For instance in my 2003 BTW paper, I demonstrate support for 4 different hosts and 4 different chains. By default if an emu cable is connected to the board, the Jtag mux FPGA would connect the dsp chain to the emu host. If an Altera cable is plugged into the board the Altera host is connect to its native eplds. Connecting our Boundary Scan Tester cable to the board could link all devices. While using vendor specific hardware (dsps, fpgas)it is advantageous for the gateway to manually selct the path without any special scan path selection protocol over the Jtag bus. I think it is advantageous to keep it simple for the co verification effort between firmware and Hardware engineers. Having confusing methods of linking the chains will surely frustrate the designers during development.

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

Post by Ian McIntosh » Sat Mar 29, 2008 2:22 am

Tim Pender wrote:Most emulator tools do not like "in the chain" gateways.
Agreed!
Tim Pender wrote:For instance in my 2003 BTW paper, I demonstrate support for 4 different hosts and 4 different chains.
I like the scheme you describe in that paper, but I guess even that will run into some limitations in terms of the permutations of hosts/chains that can be supported easily, e.g. for some operations I may want my BSCAN controller to use chain A but not chains B, C and D (maybe because they're not powered), while in other tests I want to use all the chains, so some secondary chain selection would be required.
Tim Pender wrote:While using vendor specific hardware (dsps, fpgas)it is advantageous for the gateway to manually selct the path without any special scan path selection protocol over the Jtag bus.
Again, I agree. It seems unreasonable to expect device vendors to support all the possible scan path selection protocols. It's not their "core business" and would create support issues I'm sure they'd be keen to avoid.
Tim Pender wrote:Having confusing methods of linking the chains will surely frustrate the designers during development.
And indeed, the JTAG tool vendors too!

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

Post by Bradford Van Treuren » Mon Jun 16, 2008 2:20 pm

The greatest complaint I have with most of the "in the chain" gateways, scan path linkers, and now the TI LASP is the use of the linkage bit between the various sub-chains that are spliced together by the selection protocol. Many of the tools are unable to support these linkage bits in the chain as they are not able to be described by BSDL since the linker/gateway devices are not managable by BSDL constructs directly. This is why the tool vendors that support such devices have to fabricate their own model representations for them.

To overcome these problems, we generally have the emulation pods plug in on the secondary side of such devices with the ability to isolate that secondary chain from the linker/gateway device when the pod is connected. This works for programming pods as well. We have found this backend control instead of the front end control like Tim describes in his paper to be as effective if we design our chain topology well and allows us to reduce the pin count for the gateway/linker devices. The real issue is that the chain topology needs to be planned out carefully as to all of its uses up front. This includes system and programming uses and not just test efficiency uses.

As Ian pointed out, most cases were these tools that have problems with gateway/linker devices in the chain are used is in development/prove-in case and not really needed for cover's on testing because processors require a reset to get into emulation mode as it is. Ideally, it would be nice to actively attach to a hung processor that is spinning off in space from its normal control flow and be able to immediately enter emulation mode to halt it and view the PC, SP, and other registers to obtain the state of the processor as to where it thinks it is running. Most processor emulation ports do not support this feature at this time.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

Post Reply