<2009 Survey, Section 7 User Survey 2009 Results 2009 Survey, Sections 9, 10>

Section 8 - The cost of SJTAG...


8.1 - Which of these possible uses for JTAG within a system do you think you would use?

  1. Structural Test
  2. Configuration/Tuning/Instrumentation
  3. Software Debug
  4. Built-In Self Test
  5. Fault Injection
  6. Programming/Updates
  7. Root Cause Analysis/Failure Mode Analysis
  8. Power-on Self Test
  9. Environmental Stress Test
  10. Device Versioning

The chart layout makes the differences appear more pronounced than they really are. Structural Test, BIST, Programming and POST are the unsurprizing top scorers here, while Software Debug and EST bring up the rear, probably as there are Use Cases that either won't generally have been considered or that are perceived as difficult. 



8.2 - How do you perceive the cost of using JTAG as an embedded technology relative to using an external tester?

  1. Far less costly
  2. Less costly
  3. About the same cost
  4. More costly
  5. Far more costly

Some 73% feel than an embedded JTAG solution will be less costly than using external control, and this may require some exploration: What is seen as the cost bases associated with external control that lead to this opinion? Are the benefits of embedded control being tied to specific Use Cases? The fact is that there are tradeoffs to be considered here, and we are unconvinced that we are adequately representing those tradeoffs.

Part of the cost argument against embedded control is likely to be the implication related to board real estate and resource utilization.



8.3 - What is the overall hardware cost per board you expect you would incur if you added SJTAG support?

  1. 0-10%
  2. 11-20%
  3. 21-30%
  4. 31-40%
  5. Other

Additional hardware costs for SJTAG are expected to be up to 20% of the BoM cost, with the majority anticipating that this will be below 10%. If adopting SJTAG means a change of methodology then the associated return on investment will probably need to be much better than the 10% cost. We can see more in the following question.



8.4 - What is a reasonable hardware cost per board, as a percentage of the total material cost, you would accept for SJTAG support?

  1. 0-10%
  2. 11-20%
  3. 21-30%
  4. 31-40%
  5. Other

The difference between this result and the previous one is revealing, as some of those who expect the hardware cost to be up to 20% will only actually tolerate up to 10%. It may have been interesting to discover if 5% was a better target than 10%, but we did not offer any finer resolution in the answers.



8.5 - What is the overall software cost per board you expect you would incur if you added SJTAG support?

  1. 0-10%
  2. 11-20%
  3. 21-30%
  4. 31-40%
  5. Other

A similar question to Q8.3 but this time looking at the expected software impact. Again we see an expectation that costs will be below 10% of the total software effort.



8.6 - What is a reasonable percentage of software for a board would you accept for SJTAG support?

  1. 0-5%
  2. 6-10%
  3. 11-15%
  4. I would rather control it from off board

This time we acceptance of costs up to 10% but with a majority opinion that this needs to be less than 5%. We don't have a measure of what those percentages mean in dollar terms or whether opinions might vary depending on the total size of the project, but we felt those were questions that would be too difficult to ask.

We have a sense that the 5% target suggested here would have applied equally to the hardware in Q8.4, had we oferred that option.



  • 1 year max
  • A system that improves current situation significantly (i.e. lowers overall costs) with small added direct cost to the product.
  • simple and quick test
  • A sytem that is easy to develop for standard CAD / VHDL using off the shelf commercial tools
  • Convince people to use it in the field.
  • Flexibility and freedom in defining my architecture, and a standard way to describe it to the tooling
  • Vision and management support. Showcase example of success in manufacturing environment.
  • Achievement of a high degree of In-system diagnostics
  • Reduction of in-service maintenance and support costs
  • It depends on the use case driving the use of SJTAG. The best case would be adding the capability without adding additional hardware cost to the design, but at the same time get the performance I need for the specific use cases. It is more of a trade-off between cost and performance that is the factor of whether I can get a ROI that is economical as well as meet my design needs.
  • Minimize field service agents by remote access to products. Self diagnosing products can assure FRU are in hand when field service does need to go onsite.
  • Less field failure
  • <10%
  • Reduced cost of test/diagnosis in production and in the field, Improved system up-time, Reduced system maintenance cost.

8.7 - What do you feel you need to get your return on your investment?

It's probably best to let the responses speak for themselves. This was an open-ended question and people have chosen to look at it from several different perspectives. This is actually quite useful for us as it has produced some types of response that we couldn't have predicted when formulating the question, but give insights into what people see as the obstacles and opportunities.



Other responses:

  • b) and d) are probably near equal
  • Again it depends on the use case driving support for SJTAG. Options b, c, and f are the high runners.
  • A combination of all a) to f)
  • Option a) is my first choice, but the ROI for option b) I believe would also be significant.

8.8 - Which single feature of SJTAG would you expect to give you the most ROI?

  1. Ease of field reprogramming
  2. System/field diagnostics
  3. Explicit knowledge of test coverage compared to functional test
  4. Reduced support equipment costs for Field Service or ESS/EST
  5. Software Debugging
  6. Fault Injection/Fault Insertion
  7. Other

The options related to field service are dominating here. Maybe this is to be expected as activities in the field are almost certain to be operating at the system level by necessity, while factory operations often have the option to break a system down into FRUs (at a cost).



"Why not" responses:

  • Our company may benefit from SJTAG in some products, but our BTS products, with which I mainly work with, are relatively simple systems nowadays, hence SJTAG seems less important as it would have seemed say 10 years ago.
  • Depends on the type of the product. For only some kind of high-end product, SJTAG may be available to be added.

8.9 - Do you consider SJTAG as an important technology to embed in your product?

  1. Yes
  2. No

Perhaps the use of the word "embed" in this question was ambiguous, as it could be taken as either meaning using embedded JTAG (which was the original intended interpretation) or simply adopting JTAG within the system. We can take some comfort from the knowledge that, either way, there is a general opinion that JTAG is worthwhile at system level.



"Why not" responses:

  • Money but most of all such a product that would truly benefit from it. We have used system level access for ~5 years within our Flexi-product, but as it's modular product and consists of relatively simple (sub-)systems, we have managed with simple HW solutions (we had a feasibility study on different implementation options and least expensive solution was chosen). Our solution is not the optimum for overall product life-cycle, but covers R&D and production needs quite well.
  • Being able to use the tool do to what I want, not the other way around
  • Understanding of how to manage parallelism, and how to manage interaction/synchronization
  • A well defined standard supported by the tool flow.
  • How to manage tests within the system. How to report the diagnostic outputs back to the system level diagnostics software.

8.10 - What do you feel your team is lacking in order to use JTAG from the system level?

(check all that apply)

  1. Understanding how to modularize scan chains
  2. Understanding multi-drop addressing protocols
  3. Understanding how to use JTAG for more than test
  4. Understanding how to use JTAG for more than software emulation
  5. Understanding how to connect to JTAG at the system level

There is some indication here of users, possibly not the respondents themselves, with a narrow focus on JTAG's uses, but the larger proportion of responses relate to system architecture and path control issues. All of these are pointers that user education is required, so this is potential material for our White Paper.

<2009 Survey, Section 7 User Survey 2009 Results 2009 Survey, Sections 9, 10>