Minutes of Weekly Meeting, 2013-04-15

Meeting called to order: 11:05 AM EDT

1. Roll Call

Ian McIntosh
Eric Cormack
Carl Walker
Heiko Ehrenberg
Adam Ley
Brian Erickson
Harrison Miles (joined 11:06)
Peter Horwood (joined 11:22)

Excused:
Patrick Au
Brad Van Treuren

2. Review and approve previous minutes:

4/01/2013:

  • Ian had circulated an updated draft. No further corrections noted.
  • Heiko moved to approve, seconded by Eric. No objections or abstentions.

4/08/2013:

  • 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
    (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.
  • Harrison: Update slide pack to incorporate recently discussed ideas. COMPLETE.

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/Harrison's slides
    • Harrison had added a new slide to his pack and Ian invited Harrison to talk the group through it.
    • {Slide shared}
    • Harrison stated that what he had tried to do was point out what is at the different boundaries, mapping to where the standards are and where the gaps are. What the discussion brings out will affect any further breakdown from here.
    • The TAP and Scan Interface essentially provide on-chip access; at the lowest level that might be a pin function while the highest level applies to the die. Introducing P1687 gives the access on an instrument level. The Test Step Interface was likened to a Board Level Network Layer by Harrison, consisting of an organised collection of test steps organised around boards. These may be used to draw conclusions about the 'quality' of the board.
    • The Test Program Interface becomes a Chassis Level Session Layer, which implies a loose collection of boards. This tackles the question of how you take a number of board level activities and coordinate them within a session. A test may require that more that one board instance is present. This may require more than just the Export of STAPL: Observability at this level of lower levels is not great.
    • The System Level Presentation Layer that Harrison proposes maps reasonably well to the Test Package Interface. This describes flows that have to be applied in a particular way; a collection of operations on a system. The illustrations at right are an attempt to provide some relation to typical test subjects.
    • Harrison felt that the SJTAG dot0 would start at either the board or chassis layers. There needs to be agreement on how you get board and/or chassis done.
    • Ian wanted to compare with the previous version of this slide.
    • {Older slide shared}
    • Harrison explained that he'd merged the two lower layers and ordered the standards in a form of hierarchy.
    • {Peter joined}
    • Ian wondered if SVF and STAPL really had any place in the Board Level Network layer given our previous observations that these failed to carry any 'intent' for the tests, so they're not really enough, although they do at least serve the go/nogo need. Harrison felt that 1687 was needed at the board level, while the full application potential is realized at the top of the stack.
    • Ian commented on the need to merge tests that may have been developed using different tooling to support the testing of COTS boards within a system, so so SVF and STAPL may be inadequate here since board test don't often migrate to system use readily - additional constraints usually need to be applied, and it may be difficult to add that into an exported file. Harrison noted that P1838 was likely to encounter a similar issue.
    • Adam suggested that we really needed to be talking about the requirements for data to be exchanged when porting tests, what is source was, where it is used, what the impact might be for the tooling that creates the test, what the impact might be for the user of the test, etc. SVF and STAPL could be part of that, though there has to be a way to inject the system level constraints. Adam felt that could be by way of a 'wrapper' and indeed for STAPL that could be internal to the STAPL file.
    • Adam thought we should reach for the 'low-hanging fruit' and that is probably board testing: How does the board level test data need to be adapted for a system level context? Take this as a sample Use Case and work it through to see what needs to be done.
    • Harrison felt this was another toolkit above the standards shown on the slide - there needed to be a way to support multi-vendor test and that needs to flow all the way through the production lifecycle. Ian felt there was nothing impeding use through the lifecycle; Harrison agreed other than to note that relatively few people had recognized the need so far.
    • Ian felt that Adam's suggestion was worth taking further. Certainly, it would go a long way towards determining what tools vendors might need to do to be able to support the exchange of tests.
    • Harrison noted that in P1687 instruments essentially come with vectors which may server to ease the question of porting. But even then there needs to be a defined syntax else everyone will do it their own way.
    • Ian thought that working through an example as Adam proposed would be a worthwhile excercise for the group. However, he also noted that previous attempts to arrive at a synthetic, generic example hadn't always been useful so he wondered if a real-world example would be more practical. Adam thought that would be excellent if it were possible. Ian noted that it would have to be something that could be shared, and possibly not overly complex so that it could be relatively easily comprehended.
    • Ian would look for some example, but also suggested that the group should also look to see if they have anything suitable to offer. {ACTION}

6. Key Takeaway for today's meeting

  1. Need to determine the requirements for data that will inform how a board test might be migrated to system test.

7. Schedule next meeting

Next Meeting:
April 22.

April schedule:
29

8. Any other business

  • No further information yet on BTW plans.
  • Ian reminded the group that the Newsletter is due at the end of the month, so please email any article suggestions to him.

9. Review new action items

  • 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.

10. Adjourn

Eric moved to adjourn at 11:51 AM EDT, seconded by Brian.

Respectfully submitted,
Ian McIntosh