2009 Survey, Section 5

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

Section 5 - Your opinions on SJTAG...

q5-1.png

5.1 - How important is it for an SJTAG standard to address the application of JTAG within distributed systems?

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

We have to confess to being surprised by this response. While we recognized the growing prevalence of distributed systems, we hadn't anticipated this level of interest in SJTAG support within them. This is an area for futher investigation as we did not, for example, collect information on which Use Cases people are considering here.

 

q5-2.png

5.2 - Which of the following board related features are you interested in an SJTAG standard governing?

(check all that apply)

  1. Coordination of JTAG access and control between parent and child boards
  2. Coordination of JTAG access and control between child boards on a single parent
  3. Coordination of JTAG access and control of multiple scan chains on a single board
  4. Control of system/board services and not just the ability to test them (e.g., instrument control/monitoring)

Another surprise, and possibly a problem: There is a relatively strong showing here for mezzanine to mezzanine test (option b). For statically configured relationships to the parent, this isn't too much of an issue but many implementations of this kind involve dynamically configured switching to route signals to or from daughterboards. This dynamic aspect breaks into subject areas we consider in Section 7.

 

q5-3.png

5.3 - Which of the following multi-board related features are you interested in an SJTAG standard governing?

(check all that apply)

  1. Inter-board test coordination of JTAG access and control between boards on a common backplane (backplane test)
  2. Inter-board test coordination of JTAG access and control between boards on separate backplanes (cable test)
  3. Coordination of JTAG access and control between boards and off-backplane resources (e.g. power or thermal management modules)
  4. Coordination of concurrent actions on multiple boards (e.g. BIST, Update)

It was expected that backplane test would feature strongly here, even though it's an area that our own experiences tend to indicate is rarely as simple as many would initially believe. The recognition of the importance of concurrency (e.g. in relation to things like BIST) was a pleasant surprise and demonstrates that we have reasonably sophisticated users here, who have given the matter some thought.

 

q5-4.png

5.4 - Which of the following configuration issues are you interested in an SJTAG standard governing?

(check all that apply)

  1. Define hierarchical connectivity standards between parent/child interfaces (e.g., mandate separate secondary chains for off-board paths)
  2. Define chain management standards for multiple chain configurations on a board (e.g., mandate use of linkers/gateways that connect to secondary chains)
  3. Only define the JTAG connectivity for scan paths
  4. Define the JTAG connectivity for scan paths as well as the signal interconnections at the mating points
  5. Partition the possible scan paths into STATIC (paths that don't change configuraion), EXTERNAL (paths that go off board), and DYNAMIC (paths that change configuration over time) path groups
  6. Need to support external JTAG access and control of secondary chains on a board (e.g., dedicated emulation ports)
  7. Define hierarchical access and control relationship standards between two or more children
  8. Define hierarchical access and control relationship standards between separately controlled sub-systems (e.g., cable testing)

Possibly the most important thing to take away from this is that SJTAG will fall short of user expectations if it only addresses the connectivity of the scan paths. This may be something we can also read across from the responses to Q3.7 and Q3.8 where HSDL did not score highly.

 

q5-5.png

5.5 - Which of the following mangement issues are you interested in an SJTAG standard governing?

(check all that apply)

  1. Single point of access to all board JTAG interfaces within a system ("covers on" access)
  2. Provide redundant test interfaces
  3. Centralized control of testing of boards (System Management Controller)
  4. Localized control of testing on boards (Board Management Controller)
  5. Testing from an external controller while boards are in the system
  6. Use IEEE Std 1149.1 as an alternate system command and control bus

This was probably quite a difficult question for people to grasp due to the terminology involved in some of the options. While using JTAG as a redundant test interface was not a popular option, the others scored rather evenly. We do wonder, however, if the data management issues associated with centralized control (option c) are being taken into account by those choosing that option. Once again, we can see the need for improvents in our White Paper, both to clarify our terminology and to raise the issues to the surface.

 

q5-6.png

5.6 - Which of the following embedded testing issues are you interested in an SJTAG standard governing?

(check all that apply)

  1. Self-contained on-demand embedded testing (e.g., Board and System BIST)
  2. Self-contained power up embedded testing (e.g., POST)
  3. Let me manage JTAG based tests the same way I do for functional tests in my system (e.g., Common Software API from User)
  4. Define a software API for JTAG test applications embedded in a system
  5. Define a software API for vector application from system software
  6. Define a software API for board-level vector application from system controller software
  7. Define a software API for applying specific self-contained tests on a board from a system controller
  8. Define a software API for updating available self-contained tests on a board from a system controller
  9. Define a software API for applying specific self-contained tests in a system from a remote controller
  10. Define a software API for updating available self-contained tests in a system from a remote controller

This was a question specifically related to embedded uses of JTAG. The options offering vector level control are not as popular as those considering "tests". However a broad spectrum of control scenarios are considered relevant to SJTAG and again this emphasizes some of the difficulty in defining a scope for the SJTAG standards effort.

 

q5-7.png

5.7 - Do you feel emulation support at the system-level is important to you?

  1. Yes
  2. No

Support for emulation is clearly a desirable property of an SJTAG standard. IEEE Std 1149.7 promises to provide assistance in that direction, but it seems unlikely to used much beyond board level, and is not really something that is supported by existing silicon. Some of the factors affecting the usefulness of emulation via JTAG at system level are addressed by Section 7.

 

q5-8.png

5.8 - Do you feel board-level access to instrumentation inside devices is important?

  1. Yes
  2. No

The response here shows the importance of ensuring that SJTAG remains compatible with IJTAG/P1687. Presently the two groups have only a relativley loose coupling, with a few members participating in both activities, so we may need to firm up on that aspect.

 

q5-9.png

5.9 - Do you feel system-level (multiple board) access to instrumentation inside devices is important?

  1. Yes
  2. No

There is slightly less interest in supporting access to device instrumentation when we get to a multi-board scenario. This is possibly because some people perceive that all the tuning/monitoring activities that they might be interested in will be complete before the board is integrated ito the system. Others may see a need for re-tuning transmitters, etc., as system configurations change.

 

q5-10.png

5.10 - What level of diagnostic resolution do you feel is important for JTAG to offer at the system level?

(check all that apply)

  1. In-system diagnostics (System Level Built-In Self Test)
  2. Off-line/external diagnostics
  3. GO/NO-GO diagnostic granularity
  4. Failure information to device pin and net
  5. Identification of all device pins connected to a failing net

In-system and off-line diagnostics are fairly evenly matched here. There is probably a correlation here to the level of enthusiasm the respondent has for the use of diagnostics software within their system; this is something we will look at in Section 8.

On the level of granularity, there is again evidence of two "camps": Those who simply want to swap out a defective FRU, and those who want to have a detailed diagnostic at as early a stage as possible. There may be varied reasons for those perspectives, which this survey did not explore, but we need to follow up on that, understand where the differences come from, and look for any scope to bring the views together.

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