This FAQ relates to legacy questions on the SJTAG Initiative. For the FAQ on the P2654/STAM activity please see the current FAQ page.
Quick Links:
Q: What is SJTAG trying to achieve?
Q: Is there a recognised standard for SJTAG?
Q: How can I become involved in the SJTAG initiative?
Q: How is SJTAG likely to be implemented from a physical perspective?
Q: Is there any guidance on best practice for system level JTAG?
Q: What is SJTAG trying to achieve?
A: The aim is to be able to create system and sub-system designs that can readily be tested and programmed on whatever platform is available at that stage, without re-engineering of the applications and without depending on the use of specific components: Basically, an open standard that is independent of both device vendor and software tool vendor.
Q: Is there a recognised standard for SJTAG?
A: Not at this time. The working group is currently compiling a white paper on SJTAG. It is expected that this document will form the basis of an IEEE PAR (Project Approval Request) for the development of a full standard.
Q: How can I become involved in the SJTAG initiative?
A: In the first instance, you should get in touch using the Contact page. Membership of the "Core" Working Group is necessarily limited, but the "Extended" Group can still influence the direction of SJTAG through the SJTAG Forums.
Q: How is SJTAG likely to be implemented from a physical perspective?
A: The first thing to understand is that we are not proposing some new "SJTAG Interface" device. The general topologies are already established and discussed in our White Paper so in one sense we are simply trying to limit the number of permutations and standardise the protocols. In creating these standardisations there will be an expectation that certain resources will be available on each board so it's unlikely that any of today's system JTAG implementations will be fully compliant with a future SJTAG Standard. The language for SJTAG is the critical link between the hardware implementation and the software tooling. We need to describe the composition, capabilities and limitations of each board in a manner that is analogous to the way BSDL describes an IEEE 1149.1 device, bearing in mind that there is a hierarchy in play - A board may carry a mezzanine PCB that also needs to be described, so nesting or inheritance of descriptions is an essential feature.
Q: Is there any guidance on best practice for system level JTAG?
A: To some extent. The topologies are obviously a major element in this. More will obviously be flushed out as we get down to refining the details of the draft standard, but much of guidelines will simply come down to good DfT. There will be a set of criteria that a hardware implementation should meet to be considered "SJTAG Compliant", but we recognise that we can't legislate for all eventualities. As an arbitrary example, we might define that at the board edge certain signals should be implemented as 3.3 volt TTL for maximum portability, but a specific case may have valid reasons for using only 5 volt TTL. It would still meet the principle objectives of SJTAG, so we'd class that as "SJTAG Compatible" although not "SJTAG Compliant", since you couldn't use that board in another system.