Minutes of Weekly Meeting, 2013-03-04

Meeting called to order: 11:05 AM EST

1. Roll Call

Carl Walker
Adam Ley
Brad Van Treuren
Patrick Au
Ian McIntosh
Peter Horwood
Harrison Miles (joined 11:08)
Eric Cormack (joined 11:08)
Heiko Ehrenberg (joined 11:09)
Tim Pender (joined 11:11)

Brian Erickson

2. Review and approve previous minutes:


  • No corrections noted.
  • Brad moved to approve, seconded by Patrick, no objections or abstentions.


  • No corrections noted.
  • Eric 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.

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. Reaffirmation of officers
    • Ian and Heiko had both indicated willingness to continue in the offices of Chair and Vice-chair respectively for 2013. As Ian had received several votes by email supporting reaffirmation of both parties, he proposed to accept the first two received as mover and second, and ask for any votes of dissent or abstentions from those on the call that had not supplied email votes. The group agreed to this process.
    • Motion by Harrison Miles to reaffirm Ian McIntosh as Chair, seconded by Tim Pender: Carried unanimously.
    • Motion by Harrison Miles to reaffirm Heiko Ehrenberg as Vice-chair, seconded by Tim Pender: Carried unanimously.
  2. Proposals for SJTAG at ITC or BTW 2013 (if any update available).
    • No discussion.
  3. What did we learn from the discussion of lifecycle phases and Use Cases?
    • Ian had quickly prepared some slides based on diagrams that had previously been used in the group's meetings. The idea was to explore the idea touched on at the previous meeting, that XBST and EBST were not really different.
    • {Slides shared - http://files.sjtag.org/IanMc/Revisit_some_old_ideas.pdf}
    • The first slide was the XBST vs EBST hardware comparison from the old v0.4 version of the White Paper. The second slide was an alternative version that Ian had prepared some time ago to propose that there was more than just the two cases previously suggested. The third was an amalgamation of two related slides Brad used at ITC 2008, that showed the 'layers' of test operations and controls and the interfaces between layers. Ian compared this to the 7-layer OSI model, and pointed out that the 'layers' considered here were not the same 'layers' that we had been referring to in some of the more recent discussions. Brad noted that it had been his intent to parallel the OSI model.
    • Ian's contention was that while the entire 'protocol stack' shown might reasonably describe the embedded test scenario if you imagined looking down on the top of the stack, the external test case was simply looking down the same stack, but from part way down, perhaps at the Test Program Interface. However the higher layers of control still existed, but may be represented by, e.g., manual operation and so seem out of sight.
    • Brad noted that these diagrams we an attempt to describe an abstract protocol concept, considering tooling rather than hardware primitives, in line with Brad's long held belief that SJTAG was more of a software problem than a hardware one. There was need to understand the dynamics for control, and the lowest level of control in this context was the TAP state machine.
    • Harrison felt there was a discontinuity at the Test Step Interface, relative to the layers above it. Brad tended to agree, noting that in the early days even moving a test to different controller from the same vendor could be painful. Harrison felt that what was needed above the Test Step Interface was an OOD abstraction layer and API, allowing portability across tool vendors. Above that, Harrison would contend that everything else is application specific. Brad was broadly in agreement with that but noted that there could be some commonality at the Test Program layer. Harrison commented that everything below the Test Step Interface layer need not come from the same vendor.
    • In thinking about what the abstraction needed to possess, Brad noted that Gunnar's ATCA model had the ability to call a test step by name and ALU's TFCL also used name based referencing. Harrison agreed that this should be possible and noted that the bottom side of the abstraction would allow inheritance to the named instances. Brad agreed and remarked that this would largely alleviate the question from the previous side of where the physical control hardware was placed. Additionally this would simplify what the Test Package has to do: It wouldn't need to know what each step does. Harrison noted that the SVF and STAPL tools would not be needed, but Brad explained that these appeared on the diagram simply to help illustrate where these languages might map into the layers, for those who were familiar with them.
    • Brad observed that the method being described allowed decoupling of the tests from the application code, so the application could be reusable across different products and test environments. Harrison felt this was essential in order to get buy in.
    • Harrison suggested that TCL could be usable below the Test Step Interface, while the Test Step Interface could be described in XML. Brad worried that some people might resist XML as it can become very verbose. Ian agreed but suggested that XML could be used to convey an interface specification that could be converted by the tooling in use to a more compact form if necessary and this was probably not dissimilar to what many tools do anyway. Harrison felt that XML would offer accessibility to a larger base of developers than alternatives like C/C++.
    • Brad commented that he had some concerns over P1687's use of TCL as it was not used by all tools, and he had previously proposed a translation to a native language, adding that there was likely to be some political pressure towards PDL, given that it is now a feature of 1149.1-2013. Harrison believed that was possible at the Scan Interface but disagreed with it for the Test Step Interface as it was more procedural and distanced from the hardware.
    • As an example, Brad suggested that POST would be a plug-in at either the Test Program Interface or Test Package Interface.
    • Brad remarked that Ian's earlier comment on 'looking down on the stack' again highlighted the 'cube' aspect. Ian added that you could also move through the stack along that axis, so the External Test was simply getting closer to the hardware, more akin to board level test.
    • Brad suggested that it would be worth examining some of the papers that preceded his 2008 ITC work, especially the BTW slides from Mike Westermeier.
    • {The following discussion took place during the selection of Key Takeaways}
    • Tim asked if power control and selection of which test to perform happened in the Application layer. Ian noted that it was the external EST scenario that had prompted him to think about this topic and things like power control and control of thermal ramps, etc., would be something for the Application layer. Brad added that the Application would set the state of anything that's outside of boundary scan while the Test Package Interface may give access to a 'Test Repository'.
    • Brad noted that instrumentation may make the stack discussed to day invalid, as it changes the focus of attention: What you want to obtain are 'values' as subsets of vectors, not tests. For that reason, Brad would not promote TFCL within his own organization for P1687 applications as it doesn't meet the needs of what P1687 is capable of.

6. Key Takeaway for today's meeting

  1. Abstraction above the Test Step Interface should reference test steps by name.
  2. The Test Step Interface is the most likely candidate for standardization, and is point where the delineation between EBST and XBST can occur.
  3. A functional test could use either the Test Step Interface to perform a single step or the Test Program Interface where a group of tests is required.

7. Schedule next meeting

Next Meeting:
March 11.

March schedule:
11 - Patrick will miss.
18 - Patrick will miss.

8. Any other business


9. Review new action items


10. Adjourn

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

Respectfully submitted,
Ian McIntosh