Minutes of Weekly Meeting, 2015-02-23

Meeting called to order: 11:05 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Heiko Ehrenberg
Tim Pender
Peter Horwood
Michele Portolan
Carl Walker (joined 11:06)
Brad Van Treuren (joined 11:11)
Bill Eklow (joined 11:45)

Adam Ley
Brian Erickson

2. Review and approve previous minutes:


  • Draft circulated 02/16/2015.
  • No corrections noted.
  • Eric moved to approve, seconded by Heiko. No objections or abstentions.

3. Review old action items

  • All: do we feel SJTAG is requiring a new test language to obtain the information needed for diagnostics or is STAPL/SVF sufficient? See also Gunnar's presentation, in particular the new information he'd be looking for in a test language (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • Ian: Add the previously discussed lists to the 'master' template. Ongoing.
    • Some sections need further expansion that may take time to develop.

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172

5. Discussion Topics

a. Further thoughts for ITC??

  • Bill had previously suggested a possible link between Michele's paper and an SJTAG Poster.  Michele thought could be managed, assuming that his paper was accepted.
  • Michele mentioned the prospect of a system test session at ITC.  Ian believed that was dependent on sufficient papers being submitted and Bill's indication last week was that there hadn't been that many papers submitted so far.  It may be April before it's known what will be included at ITC.

b. Revisit draft PAR statements - continuation.

  • Ian felt that the recent discussions had brought out three specific notions that seemed to form part of the definition of what might represent the core SJTAG PAR:
    • Address level immediately above 1149.1 - are we clear what we mean by that?
    • Include a transportable description of gateway type devices - is that PDL?
    • Accommodate alternative interfaces to 1149.1 - do we use alternatives only for control or also for data?
  • Taking each in turn:
  • Address level immediately above 1149.1
  • Michele thought that the first thing might to establish a position on scan path linkers.
  • From Brad's view of the application space he saw a need to coordinate a variety of interfaces - 1149.1, SPI, I2C and even memory mapped, register based IO. A test may be run from a PC in which case there may be a need to use an emulation interface to get access to those registers  but the test may need to be adapted to run on-board using the embedded microprocessor. Brad added that in a 1687 discussion Jeff Rearick had talked about things he was doing in AMD processors that might have 8 cores, a range of tests that were done inside the package using 1687-like interfaces - temperature monitoring, memory tests, etc.: We still want to be able to use those for the board test, although Brad noted that the interfaces will be different and Jeff has more control.
  • Brad felt we needed to support multiple interfaces if we are truly to support system test, so the question might be whether these interfaces should be included within the main standard or split out into sub-standards.  Ian felt it would be difficult to manage in a single, core standard.  Brad agreed but noted that the core needs to define the basic protocols.  Ian considered that if the core defines those basic protocols, then users would be free to develop their own interface extensions without needing the extensions to be defined within a standard.
  • 1149.1-2013 basically sets the TDR as the primary element, while 1687 goes more into the instrument, but the basic minimum is that a Data Register acts as the exchange between the tools and the instrument, so a Data Register is then our "primitive" and the key is how we manipulate it - how we read from it, write to it, what it means when we have selected it.  Much of that is already addressed in existing standards but we can control when that transaction takes place.  We don't need to get into the details, which can be left to the other standards, just define the access of the transaction.
  • Core standard needs to define the transactions we need and the accesses for those transactions: That gives us a "bridge" to the other interfaces that are extensions to the SJTAG core. 
  • Include a transportable description of gateway type devices
  • Gateways here probably means "everything related to chain management". These are the "switches and routers" of the topology of a JTAG chain.
  • Ian asked if we saw this as being a PDL description.  Brad didn't think PDL in its current form would be adequate: PDL is directed towards a single instrument but we need to consider the behaviour of the whole device which may have multiple registers that require to be accessed in sequence.  Ian then wondered if that could be a suite of PDLs with a layer of higher level control.
  • Michele felt it wouldn't be wise to name a specific language in the PAR.  Brad and Ian agreed, with Ian noting that he was only citing PDL here as it had been adopted by other JTAG related standards.
  • Brad asked if the PAR for the core standard needed to have some vision of what other sub-standards might be created.  The general opinion was that it need not as each standard will have its own PAR; it is more likely that those sub-standards would instead describe how they extend the core standard.
  • Brad wants to focus on the idea that there is a data link that talks to the facility and and access link that needs to be controlled.
  • Tim felt that, at the highest level, a language would have generic read/write instruction and a bus number to operate on.  That high level view could have knowledge of the different states of the system, Tim's point being that it can be managed better if the control comes top-down.
  • {Bill joined}
  • Part of our description needs to document that there's some sort of order to events; timing requirements so as not to have conflicts.
  • Accommodate alternative interfaces to 1149.1
  • The foregoing discussions had already answered Ian's question here, in that it seemed that we did have a need to use alternative interfaces for data as well as control.
  • Brad noted that 1687 requires the capture-shift-update cycle for it's interface but we can't mandate that throughout SJTAG as we're leveraging other standards and we still need to get a piece of data into a particular data register.
  • This raised the topic of "indirection", e.g. if we're using I2C for control, how do we represent that at a transport level as a single interface?  It's really a "super-interface".  Brad described an analogy from his robotics work where one one multi-axis controller was replaced by a combination of a higher resolution single axis controller along with a dual axis controller but there was no change to the interface as seen by the robot control software.  Ian imagined that this was done by wrapping the two control interfaces with a layer that presented the expected super-interface and had sufficient sentience to know how the two controllers needed to interact.
  • Brad commented that you may have a temperature sensor that you want to monitor in case you need to interrupt a test if an overheat is detected.  If that requires I2C then it needs to be dealt with at a higher level rather than having to expressly think about how to control the I2C interface; it's an expectation on the standard to describe how such things hang together and present a simple user interface, much like how a CD Player hides the relative complexity of its operation compared to a tape Walkman yet presents a slightly simpler user interface.  Ian acknowledged that point, but, playing Devil's Advocate, asked if by offering that simplicity in SJTAG you might remove some control from the test developer.  Brad accepted that might happen, but suggested that the standard could allow for extensions to provide that lower level control.

6. Key Takeaway for today's meeting

  • It would be difficult to manage support for multiple interfaces in a single standard and would be better suited as separate sub-standards from a core standard.
  • The key to the data register as a "primitive" is managing how we manipulate it, write to it, read from it, and what it means when we have selected it.  Much of that is already addressed in existing standards but we can control when that transaction takes place.
  • The SJTAG Core standard needs to define the transactions we need and the accesses for those transactions, giving us a “bridge” to other interfaces that may become extensions to the SJTAG core.
  • Part of the SJTAG description needs to document that there’s some sort of order to events; timing requirements so as not to have conflicts between elements of the system under test.

7. Glossary terms from this meeting

  • None.

8. Schedule next meeting

  • Next meeting March 2.
  • March schedule: 9, 16, 23, 30.

9. Any other business

  • The newsletter is due. Brad is still finding limited time to work on the Green Paper.
  • Group officers needs to be addressed. Start the process on 3/2/15.

10. Review new action items

  • None.

11. Adjourn

Eric moved to adjourn at 12:05 PM EST, seconded by Peter.

Respectfully submitted,
Ian McIntosh