<2009 Survey, Section 8 User Survey 2009 Results >

Section 9 - Widening the scope...


q9-1.png

9.1 - Before you took this survey, what was your perception of JTAG?

  1. JTAG is mainly/only a test interface
  2. JTAG is mainly/only a programming interface
  3. JTAG is mainly/only an emulation interface
  4. JTAG can be used for several purposes
  5. No particular view on JTAG

The responses here, when compared to those in Q8.10, reinforce the conclusion that while the respondents on this survey are more sophisticated users with a broader knowledge of JTAG and it's applications, they are acutely aware of others who are less well informed.

 


q9-2.png

9.2 - Would you consider system level JTAG useful for you to do more than test?

(e.g., Fault Injection, Configuration, Instrument Control)

  1. Yes
  2. No

Following up on the previous question, there is universal recognition that JTAG has system level uses beyond testing. We pursue this in the next question.

 


q9-3.png

"Why not" responses:

  • Do, Within our simple product.
  • Capability isn't ready to do it.

9.3 - Would you consider using JTAG to perform structural test at the system level?

  1. Yes
  2. No
  3. I already do this

We could be inclined to dispute the second claim in the "Why not" responses, as there is an existing capability as evidenced by the number of respondents reporting that they already use JTAG for system level testing. However, we appreciate that the real issue being pointed out by that comment is how inaccessible the technology is, which was really the premise behind the inception of the SJTAG Initiative.

 


q9-4.png

"Why not" responses:

  • Current devices in use don't generally support this

9.4 - Would you consider using JTAG to perform configuration, tuning, and instrumentation management at the system level?

  1. Yes
  2. No
  3. I already do this

A small number of "No" answers but not all that many reasons given. Another possibility may be related to security concerns, in which case we'd expect similar levels of response on other uses that might have the potential to expose design IP, such as Q9.5 and Q9.9.

 


q9-5.png

"Why not" responses:

  • Yes if you consider µP emulator but it is at device level only (on one board) and not at a system.

9.5 - Would you consider using JTAG as a system software debugger interface?

  1. Yes
  2. No
  3. I already do this

And indeed, we do see a similar percentage of "No" responses here. We've touched on the problems of vendor tools and gateways earlier in this survey, but that does not detract from the ideal of being able to support emulation/debugging at the system level.

 


q9-6.png

9.6 - Would you consider using JTAG to access Built-in Self Test (BIST) features of devices?

  1. Yes
  2. No
  3. I already do this

BIST appears to be a popular application area for SJTAG, with almost 1 in 5 users already established as practitioners.

 


q9-7.png

9.7 - Would you consider using JTAG to access Built-in Self Test (BIST) features of boards?

  1. Yes
  2. No
  3. I already do this

A similar response to Q9.6, but with slightly fewer reports of established practice. Possibly it is easier to use 'RUNBIST' at the device level than it is to co-ordinate activities to achieve a useful BIST at board level.

 


q9-8.png

9.8 - Would you consider using JTAG to manage Fault Injection/Insertion features on a board?

  1. Yes
  2. No
  3. I already do this

It is perhaps not surprising that so few people presently use JTAG for fault insertion. However, it is interesting that it is an application area that interests the entire survey base, and shows that there is a desire to get more use out of JTAG. In fact, in comparing the strength of the response here to that in Q8.1, we wonder if this question actually alerted the respondents to this as a new Use Case.

 


q9-9.png

9.9 - Would you consider using JTAG to perform programming and/or code updates on a board installed in a system?

  1. Yes
  2. No
  3. I already do this

Again, the "No" responses could include those who see security as an obstacle. The motivation behind the "Yes" answers may be more interesting: Do they currently see JTAG as a means for test, do they presently only consider programming at board level, do they see system level programming as something that uses a "mission bus" rather than JTAG? This is a question we may need to explore further.

 


q9-10.png

9.10 - Would you consider using SJTAG to capture and preserve data that could be used later for root cause failure analysis or failure mode analysis?

  1. Yes
  2. No
  3. I already do this

The responses here correlate quite nicely with those from Q9.8, so we are able to conclude that those with an interest in fault injection are also interested in the benefits arising from using JTAG to assist RCA/FMA.

 


q9-11.png

9.11 - Would you consider using JTAG testing as part of a Power-On Self Test (POST) process for a board?

  1. Yes
  2. No
  3. I already do this

It's interesting that the distribution of replies here is at odds with those for Q9.7. This shows that people are distinguishing between the particular constraints on POST as compared to the more general usage associated with BIST. This could be because it's generally easier to manage board start-up during/after POST than it is to recover functionality after running BIST on a "live" board.

 


q9-12.png

"Why not" responses:

  • Yes if you consider fault injection.

9.12 - Would you consider integrating JTAG testing as part of an environmental stress test process?

  1. Yes
  2. No
  3. I already do this

There is a significantly smaller proportion of people using JTAG during EST than we anticipated. While we see the potential for more productive and effective EST through the use of JTAG, it is obvious that this is not a widespread view. The lack of adoption may be related to external control issues, or it may simply be lack of awareness and again, we may need to explore this further.

 


q9-13.png

"Why not" responses:

  • I don't know
  • Shelf managment has the information but a structural test before JTAG action is welcome to be sure of the target especially if we are in remote condition.
  • Board type, revision and board ID are already stored in non-volatile memory. From this information the BOM can be retrieved in other ways.

9.13 - Would you consider using the JTAG IDCODE to aid you in determining the Bill of Materials on boards installed in the field?

  1. Yes
  2. No
  3. I already do this

Very few people currently using "self discovery" and a small but significant proportion don't see any value in this Use Case. We can accept that systems may well offer alternative (and possibly more efficient) methods to achieve the same result, but it is virtually a free service in JTAG and can remain available even if the mission buses fail.

 


q9-14.png

"Why not" responses:

  • A monitoring path already exist (IPMI).
  • We monitor such signals continuously by other means

9.14 - Would you consider using JTAG to SAMPLE a snapshot of signal/alarm states on a board installed in a system?

  1. Yes
  2. No
  3. I already do this

We can probably make similar observations here as in Q9.13. Acquiring a SAMPLE via JTAG may require a little effort to configure but is available without the mission buses and requires no additional hardware. The same cannot always be said of alternative methods.

 


Section 10 - A few general things to finish...


  • for 2.5, I really wasn't happy with the options presented. had it been available, I would have chosen Predominantly Software and Less Architecture and Still Less Hardware.
  • Time is of the essence. The test industry is moving toward a consolidation of the release of the proposed IEEE standards. Hopefully, SJTAG will be ratified soon to monopolize on them.
  • Since we develop different types of systems with different requirements, my answers above may not reflect all of them. The answers is rather a merge from all systems.
  • This survey comprice to many questions, and takes to long time to complete. Consider make future surveys more dense, with fewer questions.
    Some of the questions is a little to complex to really answer with other than "no oppinion", but alternative is ofthen missing.
    I would say this a a bad survey, because it want to do to much. Much better to focus on a few quesions that you want to get a hint on.
  • The SJTAG standard needs to support both the domain of built-in system testing and testing of system assets from an external tester and somewhere in between.

10.1 - If you have any other comments you'd like to make on system level JTAG, an SJTAG standard or any related topic, then please enter them here.

There is no particular commentary here. We are happy to note all comments, qualifications and criticisms.

 


10.2 to 10.3

These questions related to further referrals and forwarding of survey responses and, in the interests of privacy and confidentiality, the responses are not presented.

 


Summary and conclusions


This was a complex survey and much of it was, intentionally, quite difficult to answer as we were reaching beyond most individual's comfort zones. We were posing questions that we ourselves struggled with over many hours of debate, so we know it was not easy, and we thank everyone who participated for their time and effort.

It was also quite a difficult survey from which to compile results: With almost 80 questions and a frequent need to correlate the aswers of individuals across several questions in order to understand their perspective, this was more time consuming to analyze than we had anticipated. That said, we are glad that we did this because it has brought out a number of points which we have to address:

  • Too many people are still reading the old White Paper (v0.4) instead of the Wiki based version and are taking away the wrong messages. We need to ensure, probably by reorganizing our website, that people are directed to the newer document. This work has already started.
  • The nomenclature we use either doesn't map to accepted usage or isn't readily accessible for the majority of people. This then ties in to the next item:
  • The role of the White Paper for education cannot be underestimated. It is clear that the White Paper is not presently achieving its goals in that respect and some significant revision and/or expansion is required.
  • The way people apply or envision some of our identified Use Cases is not entirely apparent or in line with our present understanding and requires to be explored further. It is possible that we may look to use individual interviews rather than another survey to expand our knowledge in these areas.

Once again, the Group would like to extend its thanks to everyone who took part in this survey: You have each made a valuable contribution towards making the SJTAG standard a reality.

<2009 Survey, Section 8 User Survey 2009 Results  >