Discussion and feedback on the SJTAG Initiative Group weekly meetings.
- SJTAG Chair
- Posts: 429
- Joined: Mon Nov 05, 2007 11:49 pm
- Location: Leonardo, UK
Since most people won't have a copy of the text file I shared at this week's meeting when we were discussing gateway questions for the tool vendors, here is the material for reference:
- provision for non-JTAG control (i.e., control through non-JTAG terminals)
- provision for non-JTAG slave I/O (e.g., flash write, etc)
Is it possible to reuse test code across multiple boards in a system that differ only in the slotID/multi-drop address in configuration? (e.g., using parameterization or indirection/references when describing the hierarchy configuration) For an ASP? For a ScanBridge?
What information is required to preserve the state of a secondary port of an ASP, ScanBridge, and linker during deselection so a connection could be properly re-established?
How important are the broadcast address synchronization scans for system test (e.g., lock step state transitions of all boards installed in the backplane to cause everyone to go through EXIT2DR, UPDATEDR, to IDLE simultaneously from PAUSEDR)? Do your tools take advantage of this feature in current gateways for backplane testing?
In our boundary scan software, we have a requirement to be able to shift through all local scan paths concurrently, or at least to be able to transition through UpdateIR and UpdateDR concurrently on all local scan paths (for interconnect test).
* connected in parallel; we needed to experiment a bit and built in some tricks into the control sequences in order to achieve this behavior; (-> overhead in case of IR Scan; limitations in supported TAP state sequences)
* was easier with ASP;
* There are limitations in how different scan router devices can be mixed in an hierarchy
* Especially for CPLD/FPGA programming with SVF or JAM or Stapl files, there is potential for problems; often such devices don’t tolerate extra header/trailer bits shifted during scan operations due to scan router devices in the chain; such SVF / STAPL files should be generated incorporating bits for the whole chain (including scan router device control, but design tools usually don’t support scan router devices;
I also have some details as to how we model scan router devices in our boundary scan software:
we use a file that describes the scan chain(s) of the UUT (including local paths on scan router devices) and path selection commands in our tool’s programming language; so, for a user the control of different scan router devices is pretty much consistent;
internally our s/w/ tools differentiate three groups of scan router behavior: Scanpath-Linker, ScanBridge, and ASP; and each group has its own defined control sequences; these groups have so many differences that a generalization seems very difficult (not possible or not worth the effort); different scan routers within each group are assigned specific parameters (e.g. number of local chains), so that additional types of scan routers that match the general behavior of those in one of these three groups can be supported with little additional effort;
At some point during today’s discussion we touched on non-JTAG control of scan router devices:
(“ [Brad] If you have I2C to select the path, as I think Broadcom did in their paper, are there some common properties with other protocols?”)
In principle we can support such use of non-JTAG signals for scan router control, but not in an automated fashion (although, automation could be implemented, if necessary);
Additionally, Tim supplied the following which I didn't pick up until after the meeting:
Tim Pender wrote:I used the ASP on some previous designs about 10 years ago, the ICT testers and FPGA vendor tools did not support the TI shadow protoscol. The good thing was that the chip provided a discrete control to select the scondary path in a transparent manner so the tooling had a work around.
The asp only support one secondary and does not support cascading which made for heavy loaded JTAG bus and seperate methods for buffer singnals along with muxing TDO signals from our seperate backplanes that were in the system.
Since that time I have developed my own custom muxing solution using EPLD, these use discrete controls for IO and have provisions to allow scan path selection via I2C and support for multiple hosts.