IEEE P2654 Draft Discussion

Discuss the generic proposals for SJTAG
User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 111
Joined: Fri Nov 16, 2007 2:06 pm
Location: VT Enterprises Consulting Services, USA

IEEE P2654 Draft Discussion

Post by Bradford Van Treuren »

This topic is used to discuss the organization of the IEEE P2654 System Test and Maintenance (STAM) Draft document.

Initial outline proposed during the 06 January 2020 meeting is:
  1. Overview
  2. Normative references
    1. IEEE Std. 1149.1-2013
    2. IEEE Std. 1687-2014
    3. I2C Standard
    4. SPI Standard
    5. etc.
  3. Definitions
  4. Concepts and Architecture/Technology
    1. Introduction
    2. Interfaces
      1. Physical Layer (leveraged standards)
      2. Access and Data Link Layer
    3. Transformational Logic
    4. Synchronization across interfaces
    5. Order of execution of commands
    6. Impediments
    7. Retargeting
    8. Test Portability
    9. Security
    10. Relationship to other standards
  5. Education
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 474
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

Re: IEEE P2654 Draft Discussion

Post by Ian McIntosh »

Within "Concepts and Architecture/Technology" I suspect that Interfaces (and "Access Points"), Retargeting and Transformation are going to be key elements that need to be defined and explained. That'll be part of the "education" as I expect that understanding those is going to be essential to be able to read any of the rest of the standard.

"Impediments" is maybe something of a "catch all" term at this stage: They probably come in several forms: Those that might prevent you applying the standard at all, those that might prevent you applying the standard to part of the system, or those that don't stop you implementing the standard but reduce it's effectiveness. I could imagine that some may not be obvious at the outset - I could envisage a case where after setting up and initiating a test action you need to retrieve the result within a certain timeframe, but the paths between what you want to use as the test controller and the test instruments has too much delay to meet the requirement.

I'm thinking that Test Portability is probably a topic in it's own right: There are probably several aspects to this that might come into play within the standard in different ways: Porting of canned tests from a device vendor into the STAM arena (and do we want to say anything about how a vendor should package such a test so that it is more readily usable by STAM?); Porting of tests from an external host controller to an embedded host controller; Porting of test across different vendors tool sets, etc.
Ian McIntosh
Testability Lead
Leonardo UK

User avatar
Ian McIntosh
SJTAG Chair
Posts: 474
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

Re: IEEE P2654 Draft Discussion

Post by Ian McIntosh »

We've talked a little about defining methods/formats for describing e.g. transforms that will be needed to build up the system model, but have we considered how the model will learn about the topology? It surely needs to know how the available interfaces relate to each other: It can't just assume that because Device A has an I2C master and Device B has an I2C slave that Device A has access to Device B. Netlists are the obvious answer but two things cross my mind on that:
  • For 1149.1 to be useful at the board level, it also needs a netlist. But I don't think the standard ever mentions netlists, and I think users of the standard (including tool vendors) just kind of infer/assume the use of netlists. Do we want to leave the same fill-in-the-blanks-yourself situation or do we want to be more specific?
  • We've previously noted that interconnection of boards is often an ECAD blackhole: You may have a netlist for a backplane as well as the plug-in boards but that doesn't guarantee that you know where the boards plug in. That's especially true when you have multiple boards that could fit a given socket or multiple sockets that could accommodate a variable number of plug-ins.
Ian McIntosh
Testability Lead
Leonardo UK