Minutes of Weekly Meeting, 2013-03-18

Meeting called to order: 11:05 AM EDT

1. Roll Call

Ian McIntosh
Harrison Miles
Carl Walker
Adam Ley
Brian Erickson
Brad Van Treuren (recorded as an excused absence but joined 11:46)

Excused:
Brad Van Treuren
Patrick Au
Peter Horwood
Eric Cormack
Heiko Ehrenberg

2. Review and approve previous minutes:

3/04/2013:

  • No corrections noted.
  • Insufficient attendees to vote on approval.

3/11/2013:

  • Five corrections noted:
    • Add Eric to Absences,
    • Remove three heading lines,
    • Amend comment by Adam: 'I just know what is in ICL is not the total solution and if it is really going to be up to what the Test Engineer needs in order to do their application.'
    • Amend comment by Harrison: 'My point was we need to have some description the that tells us the what how the instruments interact with each other across chip boundaries.'
    • Amend note in section 7: 'UK call-in users need to call in a at 3PM.'
  • Carl moved to approve with the above amendments, seconded by Brian, 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)
  • 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.

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. Follow up on Mike Westermeier's slides
    • Ian commented that Brad had some matters related to the slides used last week that he'd like to come back to, but this would be deferred in Brad's absence.
    • Harrison had circulated some slides of initial thoughts following on from the discussion at the previous meeting. Slide 4 was the main focus for now, and showed an attempt to correlate Brad's diagram of the layer stack to the layers of the OSI model.
    • {Slide 4 shared}
    • Harrison explained that he thought there were some similarities, for example that the TAP Interface layer was equivalent to the OSI PHY layer. The Scan Interface layer contained different evolutions of the protocols, and was roughly equivalent to the Data Link Layer, although this was largely still considering only within the chip boundary. There was an argument that P1687 or P1838 were perhaps at higher levels than some of the others, but they were all related to organizing at the silicon level.
    • When you get to the Test Step Interface, Harrison felt it was not so tightly bound to the OSI Network Layer. SVF and more particularly STAPL had more of the Transport features worked in, providing a degree or portability. Harrison was content with how the Test Program Interface was defined, and with Brad's notion of a namespace this began to look like a Session, with a start, termination, etc. It could still be STAPL-like but would probably start to diverge. Harrison felt this was where the 'Aha!' moment for SJTAG might take place.
    • Harrison observed that a vector does not have the same meaning as you move through the layers: At the TAP Interface it is highly specific to the hardware under test, at the Test Program Interface it is more of a representation of a session's 'flow'. The Data Link Layer does not have the 'rules' for inter-device issues, but there is a need to manage groups of devices and/or boards.
    • Ian made a general comment that while the OSI model was intended to represent networking methods that were already architected into layers, we were trying fit layers to protocols and interfaces that were not really conceived to form part of such an architecture; that might explain why some standards don't 'fit nicely' in our stack.
    • Harrison hadn't attempted to address the Test Package Interface or Application layer yet.
    • Harrison thought the P1687.0 equivalent for SJTAG would lie somewhere between the Session Layer and Network/Transport Layer.
    • Brad had sent some comments on the slide by email which Ian quickly summarized. Brad drew attention to Mike Westermeier's reservations over STAPL's EXPORT capabilities. Ian noted that SVF in particular was limited in what it ported, and wouldn't, for example, allow a diagnostic to be performed, only a go/nogo. Harrison accepted that STAPL may not cover everything needed for a Transport but suggested that extension may be a possible way forward. Ian noted that Gunnar's STAPL++ was just that, although that was mainly extensions towards handling concurrency.
    • Harrison wondered if there maybe a dependency on the industry segment: A divergence in the Session Layer dur to the segment.
    • Again reading from Brad's email, Ian raised the point that Test Steps have a 'specific purpose' and that a Test Step may contain flow control that differs from the flow control at the Test Program Interface level. Harrison felt that an important issue was what was passed over the interfaces: For the 'Southbound' interface between the Test Step Interface and Scan Interface that could be defined as SVF and STAPL, but for the 'Northbound' interface to the Test Program Interface that was unclear. It was not so much a vector as flow. There could be multiple flows using vector primitives, such as a 'Signalling flow' to test a DSP.
    • Ian contrasted our case with the OSI/networking model: For the most part, in the networking stacks you know what the 'data' is that you're passing all the way through, but you're wrapping it with increasing layers of protocol and format as you work up that stack. But in our model the top levels have no knowledge of the vectors, but instead represent a a description or specification. At some point part way down the stack the detailed knowledge of the hardware needs to be introduced so that the required vectors can be determined. Harrison agreed, noting that this reflected the increased observability as you move down the stack.
    • Ian felt this was perhaps a challenge for tooling, but Harrison thought it was doable: The Physical/Scan Interface layers were already being worked by the other standards groups. Ian thought that the end user may not even need to know what the low-level operations were or what standards were being employed. Harrison restated that none of the existing standards really go beyond the chip boundary
    • {Brad joined}
    • Ian quickly summarized the discussion for Brad, and Brad reiterated some of the conclusions: TFCL has no knowledge of the tests it is applying, in just that same way that NI Test Stand does not know what each test step does. It ia very much an abstract layer. Knowledge of what hardware is required is put in each test step. Similarly, Gunnar's ATCA solution just named a test, via the IPMI, to be applied.

6. Key Takeaway for today's meeting

  1. The Test Program Interface layer is expected to be highly abstract.
  2. The Scan Interface layer represents work being done elsewhere and may not be in the SJTAG domain.*
  3. Does the Scan Interface layer still represent 'vector patterns' in light of PDL that describes behavioral patterns?

* Brad noted that the standards do not really address the 'application'.

7. Schedule next meeting

Next Meeting:
March 25 - Brad is likely to miss.

April schedule:
1
8
15
22
29

8. Any other business

None.

9. Review new action items

None.

10. Adjourn

Brian moved to adjourn at 12:00 Midday EDT, seconded by Carl.

Respectfully submitted,
Ian McIntosh