<2009 Survey, Section 5 User Survey 2009 Results 2009 Survey, Section 7>

Section 6 - Defining Interfaces...


q6-1.png

6.1 - At what levels do you feel SJTAG needs to define interfaces for control of your system?

(check all that apply)

  1. Application
  2. Test Packaging and Program Flow Control
  3. Test Programs and Test Flow Control
  4. Test Steps (ordered collection of scan operations)
  5. IEEE Std 1149.1 Scan Operations (Scan Primitives like SVF supports)
  6. Test Access Port Controller Operations

There is an apparent conflict here with the responses given in Q5.6. This may due to user opinions on how, for example, SVFs are imported and controlled not aligning with the perceptions of the SJTAG group. We did attempt to find correlations between the way people voted here and in other questions, but unfortunately, there is not enough additional data to draw any meaningful conclusion. 

 


q6-2.png

6.2 - Is it sufficient to only standardize the interfaces for each layer?

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

We have to assume that the large number of "Don't know" responses here is an indication that the layer model diagram that was used to support this question was not being understood and required additional explanation. The layer diagram was presented during the SJTAG Poster at ITC 2008, and perhaps we aren't seeing the problems of interpreting it that someone seeing it for the first time has.

 


q6-3.png

6.3 - Do you feel you need vector level application interfaces to your boards from a system controller?

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

Again, there seems to be a strong contradiction when compared with the level of response on option e) in Q5.6, especially as the number of people responding to this question is quite strong. We are considering that areas such as this may need to be set aside for inclusion in a subsequent extension to a base SJTAG standard.

 


q6-4.png

6.4 - Do you feel you need test level application interfaces from a system controller to your boards?

(Calling a localized test on a board from the system controller)

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

The result here is more consistent with the response to Q5.6, so we are more comfortable that this represents a realistic aspiration of the users.

 


q6-5.png

6.5 - Do you feel your system could support an object oriented SJTAG architecture?

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

The absence of "No" responses may be telling here: We are left with those who can support an OO architecture pretty evenly balanced with those who have no particular opinion. For anyone who is not familiar with the basic premise of object orientation, it may be difficult to grasp how this relates to architecture. We can also count those who know what OO is, but genuinely don't know the answer to the question. But we're left with the conclusion that, on balance, most systems could probably support an OO architecture.

 


q6-6.png

6.6 - What type of memory would be available in your system to support embedded JTAG testing applications?

  1. Only FLASH/Persistent Storage memory is available with on-chip RAM
  2. Only RAM is available
  3. RAM and FLASH Filesystem is available
  4. RAM and Networked Mapped filesystem is available

It is encouraging that we see a hit in every column here, as this shows that people are thinking about SJTAG tests running at application level rather than being in the kernel. However, we can also conclude that it would be wrong for an SJTAG standard to assume the presence of some networked filesystem within embedded applications.

 


q6-7.png

6.7 - What size of persistent storage would be available in your system to support embedded JTAG testing applications?

  1. < 1MByte
  2. 1MByte to 8MBytes
  3. 8MBytes to 16MBytes
  4. 16MBytes to 32MBytes
  5. 32MBytes to 64MBytes
  6. 64MBytes to 128MBytes
  7. 128MBytes to 1GByte
  8. 1GByte to 4GBytes
  9. > 4GBytes

Again looking at storage in the embedded SJTAG scenario: We have something of a 'hole' between 8MBytes and 4GBytes! This probably represents the difference between systems that have no access to mass storage and those that do. This perhaps suggests two distinct 'classes' of embedded JTAG, maybe with correspondingly different capabilities, e.g. capacity for real-time diagnostics.

 


q6-8.png

6.8 - What size of dynamic memory storage would be available in your system to support embedded JTAG testing applications?

(amount an application may use and not overall physical size)

  1. < 1MByte
  2. 1MByte to 8MBytes
  3. 8MBytes to 16MBytes
  4. 16MBytes to 32MBytes
  5. 32MBytes to 64MBytes
  6. 64MBytes to 128MBytes
  7. 128MBytes to 1GByte
  8. 1GByte to 4GBytes
  9. > 4GBytes

The split here in available dynamic storage may be indicitave of differences between mobile and, for example, larger server applications. When considering this and the previous question, it is perhaps important to remember that the questions specifically mention "testing": The results may be rather different if another Use Case were considered, such as applying Updates in the field.

 


q6-9.png

Other responses:

  • It may differ dependent on the type of sysem
  • Storage and recovery of test results. Note: In 6.7/6.8 available storage is per board.
  • Callback API for reporting failure information (failing device pin and net, vector number, test name/index) to the host program.

6.9 - What do you feel is important for JTAG to cover at the system level?

(check all that apply)

  1. Board test storage on the UUT
  2. Centralized repository of tests for the system
  3. JTAG Plug-n-Play (New boards are immediately testable in system)

The results here are relatively close, although using a central repository of tests is a marginal winner despite the maintenance difficulties that such a policy might introduce. We expected JTAG Plug'n'Play to be more popular, but again this may be a case that the concept is not particulary well explained or understood.

<2009 Survey, Section 5 User Survey 2009 Results 2009 Survey, Section 7>