2009 Survey, Section 7

Details
<2009 Survey, Section 6 User Survey 2009 Results 2009 Survey, Section 8>

Section 7 - Gateways...

q7-1.png

7.1 - How important is it for an SJTAG standard to provide a defined access mechanism for gateway devices?

(board TAP access control devices, scan chain selection devices or device instrumentation gateways)

  1. Essential
  2. Important
  3. Desireable
  4. Unnecessary
  5. No opinion

Clearly, there is a broad opinion that SJTAG needs to address gateways and the methods of accessing them. No doubt there is a belief here that standardization will lead to more consistent tool behaviour and enhanced support for gateways within device vendor tools. 

 

q7-2.png

Other responses:

  • Gateway behaviour should be described in a standardised way, however not necessarily a BSDL extension
  • Gateway access protocol should be able to be user defined to the tool in a standardized way which describes the actions required to perform the selection process. Just informing the tool that a selection has been made is insufficient.
  • a) or c)

7.2 - JTAG Gateways are used to provide selective access to scan paths. How do you feel an SJTAG standard should describe a gateway?

  1. JTAG software tools should have built-in awareness of gateway operation
  2. Gateway devices should operate in a standardised manner
  3. Gateway behaviour should be described by a BSDL extension
  4. Gateway behaviour should be determined by the end user
  5. Other

Even opinions here over whether the tools should be inherently aware of how gateways operate or whether gateways should be described to the tools, which are largely opposing views. We suspect that option a) may be the preference of those who desire to have "point 'n' click" tools, while c), d) and possibly e) are options preferred by those looking for more control over the tooling.

We can infer that existing tooling provides an implementation that is adequate for some system level applications, but probably not all and some enhancement is required to offer full support for SJTAG's Use Cases.

 

q7-3.png

7.3 - How do you feel an SJTAG software tool should handle scan path selection?

  1. Tooling should automatically select paths
  2. The user should manually select the paths to use
  3. The user should be able to constrain automatic path selection
  4. Other

The conclusion here is that automatic selection of paths is desirable but with recognition that some limitations on this need to be imposed on the tooling. This is understandable if people are conscious of the potential for conflicts or creating "dangerous" chain configurations resulting in unwanted behavior.

Another aspect of chain control comes in when we consider concurrency, where we need to co-ordinate activities on multiple boards, chains, or devices, a subject we touched on in Q5.3.

 

q7-4.png

Other responses:

  • The standard should leave the gateway definition to the user, but have him describe it in a standardised manner (language?)

7.4 - How do you feel an SJTAG standard should deal with gateway protocols?

  1. The standard should prescribe the method/format for defining the protocols
  2. The standard should prescribe the method/format for defining only the connectivity
  3. The standard should leave the gateway definition to the user
  4. Other

With the responses in favor of option b) we see support for the methods described by HSDL, however there is a larger body of support for bringing the protocol definitions under the control of an SJTAG standard.

 

q7-5.png

7.5 - Do you feel an SJTAG gateway selection protocol should be limited to strictly using the IEEE Std 1149.1 compliant scan operations?

  1. Yes
  2. No
  3. Don't know

Apparently a strong opinion that SJTAG needs to be looking at more that just strict 1149.1 operations, although the "Don't know" answers make this less than clear cut. It is possible that people are considering both non-compliant protocols over the JTAG bus and the incorporation of non-JTAG buses (such as I2C).

 

q7-6.png

7.6 - Do you feel resynchronization linkage bits need to be included in the support of gateways by the SJTAG standard?

  1. Yes
  2. No
  3. Don't know

The number of respondents unable to commit an opinion on this is something of a surprize. We expected most people to identify synchronization bits (padding bits) in gateways and linkers as a primary source of trouble when using device vendor tools and emulation tools. This may be another area where our documentation is failing to adequately illustrate the problem area.

 

q7-7.png

7.7 - I believe SJTAG gateway support will be necessary for:

(check all that apply)

  1. Managing access to chain partitions within a device
  2. Managing access to chain partitions on a board
  3. Managing access to mezzanine/daughter boards
  4. Managing access to boards installed in a chassis
  5. Managing access to chassis within a system
  6. Managing access to sub-systems within a system

There is a consistent view on the need for gateway support in relation to board chains, daughterboard chains, and the boards within a chassis. There is, however, less interest is controlling access to chains within a device. This may indicate less widespread use of MCMs and SoCs or perhaps limited awareness of 1149.7 or P1687.

 

q7-8.png

Other responses:

  • A flexible solution is needed, however described in a standardised way
  • Note: The Gateway into a board and the test source selection may be separate functions.
  • Don't understand the question!

7.8 - On the primary side (ports closest to Test Controller), the gateway definition needs to support which type of interface definition to be thought complete?

  1. A single generic interface usable by external or embedded access
  2. Two separate interfaces providing dedicated paths from two Test Controller sources (e.g., external and embedded)
  3. Three distinct interfaces providing dedicated paths from three Test Controller sources (e.g., external, local/on-board embedded, and multidrop)
  4. Other

This is where we start to look at reuse of tests and this question goes hand-in-hand with Q7.9. There is a large body of opinion that only a single interface is necessary, and slighly less powerful view that three are necessary. What we believe this is telling us is that there is an aspiration towards a single interface, but for some that comes with a recognition that multiple control sources may require distinct interfaces.

 

q7-9.png

7.9 - Do you feel it is important to make the multidrop accessible chain topology be identical to the local board access chain topology?

(i.e., some multidrop gateways add registers to the chain for selection)

  1. Yes
  2. No
  3. Don't know

The "Don't know" responses probably indicate a lack of personal experience with gateways in a multidrop environment, so considering the other responses we can see that there is a desire for topologies to appear identical, irrespective of the control viewpoint, and this ties in with the results from Q7.8.

 

q7-10.png

7.10 - Is it important to support hierarchical chain topologies?

  1. Yes
  2. No
  3. Don't know

Support is going to be expected within an SJTAG standard for hierarchical topologies (e.g. chassis to boards, board to daughterboards).

 

q7-11.png

7.11 - Is scalability of your test through gateway paths important for SJTAG

(reuse of test vectors at multiple levels of hierarchy of scan path)?

  1. Yes
  2. No

This question received a more positive response; it is perhaps a little easier to understand the question's aim here. Respondents feel quite strongly that the ability to reuse tests at levels other than where they were originally developed is something very desirable.

<2009 Survey, Section 6 User Survey 2009 Results 2009 Survey, Section 8>