Minutes of Weekly Meeting, 2013-05-13

Meeting called to order: 11:06 AM EDT

1. Roll Call

Peter Horwood (left ~11:25)
Carl Walker
Heiko Ehrenberg
Harrison Miles
Ian McIntosh
Brad Van Treuren
Adam Ley (left 11:50)

Eric Cormack
Patrick Au

2. Review and approve previous minutes:


  • No correction noted.
  • Adam moved to approve, seconded by Carl. 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
  • Harrison will attempt to come up with a table of use cases and their associated layer and what can be done at that layer. Ongoing.
  • Ian/All: Look for real world examples of boards that we could take through from board test to a system test implementation as a worked example case. Ongoing. Ian added that he expected this would take a little time.

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

  1. Consolidation of the concept of protocol/interface layers as they apply to SJTAG.
    • Ian wished to clarify his thoughts on some points that were discussed at last weeks' meeting: Ian had not been suggesting that there was little value in the 'layers' as we had been discussing them but simply that it was possibly too simplistic to assume that a given layer mapped only to a specific hardware assembly level, e.g 'board level' or 'device level'. Also, while it was maybe useful to compare against other models, such as the OSI model, it was important to recognize where our needs diverged from the model as well as trying to draw on the similarities.
    • Brad noted that the physical entity levels defined certain interface capabilities: At the system level certain choices would be available, at the board level certain other choices, etc.
    • The Physical Layer in the OSI model equates to where delegation takes place in our model. We don't have a straight, top-down model like OSI: Digital IO is parallel to 1149.1, dot6 and dot7 are extensions on top of dot1. Harrison worried that we may be trying to couple his slides too tightly to the OSI model - it was only intended as a baseline. As a further thought, he felt that the transport of vectors was a neutral choice based on environment. His view was more about how much you know depending on where you sit. Dot1-2013 is a temporal problem that will be worked out over time. Ian understood that the mapping to the OSI model wasn't intended to be literal, but was wary of the danger of trying make a 'fit' in places where none existed, and was tempted to agree that the transport level might be outside of SJTAG's scope which might more about managing the (essentially software) layers above that.
    • Brad noted that we still need to work out what it is we're trying to do. His original stack was for a traditional test flow, with predetermined test vectors, while instruments and emulation bring in dynamics for returned vectors that don't fit that stack. Harrison commented that the first release of P1687 won't handle dynamics either, and an ICL for the board level is likely to be required and that is going to be like SJTAG. Ian felt that might put the board ICL into the SJTAG domain.
    • Brad wanted to know how HSDL.7 related to board level ICL. Harrison began to comment on applicability to debug type operations but Adam pointed out that, without negating Harrison's comments, HSDL.7 was not needed nor intended for debug, it was conceived for test applications. Derived from TI's HSDL, HSDL.7 generally does provide for scan infrastructures above the chip level, e.g. multi-path constructions. However it require some investigation to determine whether it meets the needs for board level use.
    • {Peter left}
    • Ian was reminded of the other aspect of 'dynamics' that had been discussed; where the path configuration may change, e.g. as a result of power state of the UUT. Brad responded that with a Plug'n'Play scheme the UUT stores its own tests so it can adapt to configuration changes due to hot swap of boards in a backplane. The infrastructure to retrieve the test remains the same and it becomes a question of how you hand off from the board to the system.
    • Harrison remarked that everything that had been discussed applied equally to P1687. Instruments will likely be used in mission mode; it may be a different layer but the same sort of decision need to be taken.
    • Brad observed that P1687 is introducing JTAG access to instruments in manner similar to that used for memory mapped instruments; it was unifying the methods.
    • Ian was unsure of how the recent discussion might be used to flesh out the definition of SJTAG. Harrison felt that depended on whether a top-down or a bottom up approach was desired. If top-down then some of the things discussed could be dealt with later, but for bottom-up then we'd need to tackle some of them now. Harrison felt the board was the 'bottom' for SJTAG. Brad thought the P1687 realm might be clouding up the 'traditional' SJTAG process, and felt it may be better to consider established technology (maybe from 5 years ago, before much of the P1687 discussion) would offer a better baseline and then consider how to add newer technologies. Brad saw two flows: One that can be partitioned in advance and one that is dynamic. Tests need to generate 'events' to the overall control system, either to request that some action occurs or to report that something has happened. SVF is essentially open loop and cannot report events during execution, while STAPL can do this to some extent.
    • Brad felt that the North-bound flow in his stack was pretty clear. With reference to the original SJTAG demos, Brad noted that the work on this showed that certain data needed to be transmitted back in order to do diagnostics. Harrison added that the South-bound flow would need to know about the 'state' of the board; not just that it was in 'test state', but the power on state, as this was getting into functionality that was beyond that required for manufacturing tests. Brad commented on 'dimensions of access' - whether externally controlled or not, since the embedded domain requires more constraints.
    • There then followed a discussion over what constituted 'testing during manufacture' since it could encompass system integration or installation, although some people may assume this to mean post-assembly board test. Ian remarked that the group needed to define a consistent glossary in order to avoid ambiguity. Brad noted that even the term 'system' is ill-defined and could relate to a sub-rack or a chassis or a rack depending on context.

6. Key Takeaway for today's meeting

  1. P1687 is serving to make JTAG access to instruments more unified with access to memory mapped instruments.
  2. There is a need to remove ambiguities from our terminology, e.g. 'system', 'manufacture', etc.

7. Schedule next meeting

Next Meeting:
May 20.
Since May 27 is a holiday for many there will be no meeting on that date.

June schedule:
3, 10, 17, 24

1 {Adam left}

8. Any other business


9. Review new action items


10. Adjourn

Brad moved to adjourn at 12:02 PM EDT, seconded by Carl.

Respectfully submitted,
Ian McIntosh