Minutes of Weekly Meeting, 2015-02-02

Meeting called to order: 11:13 AM EST

(Start delayed due to issues with the WebEx service) 

1. Roll Call

Ian McIntosh
Eric Cormack
Brian Erickson
Carl Walker
Brad Van Treuren
Peter Horwood
Heiko Ehrenberg
Michele Portolan (joined 11:29)

Excused:
Adam Ley
Bill Eklow

2. Review and approve previous minutes:

01/26/2015:

  • Draft circulated 01/26/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. Any material for ITC?

  • Brad had previously noted that the current Green Papers weren't suitable for ITC.  The intent of those (discussion documents) were quite different from what was expected for a full ITC paper.  Bill had offered the option of "Invited Talks" but probably still needed some coherent topic to present and Ian wasn't sure we had that yet.  No doubt a poster, as part of the usual Standards material, would be available.
  • Workshops or tutorials: Brad felt we were still largely at a concept stage and didn't have anything crisp or clearly defined to talk through.  Eric asked Heiko about the first 3D workshops as he felt these were mainly concept.  This was partly true but there were a number of views and ideas presented there to discuss.
  • There was a question of who was likely to attend ITC.  Adam and Heiko were likely to be there (and presumably Bill).  Michele is hoping to get a paper accepted, and if so then he expects to attend otherwise it would be difficult to justify the trip.
  • Possibly a panel discussion would better suit where we are as it would give better opportunity for potential "end-user" feedback.  This would need a panel of differing opinions or viewpoints, although some opinions would hopefully come from the floor.  Ian suggested that Phil Geiger or Al Crouch might be candidates.  Need to run the idea by Bill {ACTION - Ian}.

b. Revisit draft PAR statements - continuation.

  • Ian picked up on a comment from Al Crouch's emails on Jan 12 meeting, recommending that ant PAR should keep the scope and purpose generic and possibly try to avoid making reference JTAG or JTAG-like standards at all.  While the group had probably already recognised the need to keep the PAR generic, Ian wasn't sure whether avoiding mentioning JTAG would be a help or a hinderance.
  • Another comment of Al's was on the partitioning of the problem space across the standards.  Brad noted that the iNEMI BA-BIST Phase 3 attempted to tackle the "space between chips" by trying to establish a way for board test engineers to describe to chip designers how the on-chip instruments could be made more usable at the board level.  Ian asked if the use of the term "BIST" implied that this was meant to be to allow device self-test at board level or if it was to allow a more general use of the instruments.  Brad stated it was the latter: Leverage instrumentation existing within the chip and apply to board applications, e.g. re-use a Memory BIST engine intended for on-chip memory test to test off-chip memory.
  • Ian felt that a lot of system level testing didn't necessarily require "instrumentation" but if we're considering that a TDR is a very simple "instrument" then maybe it's just terminology and perception.  
  • Brad noted that the iNEMI group had been quite interested that we had looked at SERDES co-ordination and had established several usage scenarios with regard to the relative location of and connection between the Tx and Rx elements.
  • Brad commented that the chosen execution model influences what can be done.  Using pre-generated vectors is very different from a highly dynamic (at run time) case.  Ian noted that a lot can still be done with pre-generated vectors, although as the applications become more sophisticated and the subject more complex, it becomes less practical. Brad wondered if the notion of complexity should be part of our breakdown of hierarchy and remarked on a previous idea that our first standard might just be a definition of the hardware interface requirements and we then build from there.
  • Brad felt, looking at the usage domain, that canned vectors would not be sustainable for the increasingly complex situations.  There's a need to know what to apply where and when as segments, not one giant vector that scans the entire system, which is perhaps what the retargetter of 1687 expects to happen.  The multidrop bus is perhaps an illustration of why you can't have everything connected at once.  Ian added that when you start to build up a large system of several boards within the tooling then it can start to get unwieldy to manage.
  • Delegate deciding what needs to be sent to a segment to the segment itself.  Then the problem becomes one of scheduling, for which there are plenty of established techniques available.
  • Ian observed that there are now many cases where, as opposed to "conventional" JTAG testing, there is no single "correct" response vector even with a "don't care" mask on some bits, e.g. if trying to read the output of an ADC or temperature sensor.  This requires processing of the returned vector by some higher level process, although as Brad noted all the tool vendors are alert to this and provide a means (albeit different in each tool) to allow these cases to be handled but it usually not automated and must be manually written. Heiko agreed with this but felt it still fell into the 1149.1 domain.
  • PDL helps to do deal with this for 1687 and 1149.1-2013 by supplying additional data that can be used to automatically generate the tests.  Similarly, it should be possibly to describe, in a standard manner, how to talk to a Flash for example and have that portable across different tools: A language being used to describe the write protocol, read protocol, initialisation, etc. - leveraging the IO points, maybe considered another type of "instrument".
  • Michele commented that for his demo he had tried to implement some of things Brad had talked about and found that he could do them while staying within each of the standards.
  • Ian closed the discussion as time had run out.

6. Key Takeaway for today's meeting

  • A TDR can be considered a simplistic "instrument".
  • It should be possible to standardise descriptions of IO behaviours, e.g. for Flash programming or I2C access.
  • Pre-generated vectors cannot handle the case where a test can return a valid range of results.

7. Glossary terms from this meeting

  • None.

8. Schedule next meeting

  • Next meeting February 9, Heiko may be absent.
  • February schedule: 16, 23. Ian will be absent Feb. 23.

9. Any other business

  • The newsletter is due. Brad is about half-way through the next Green Paper.
  • Group officers needs to be addressed.

10. Review new action items

  • Ian: Discuss opportunity for a panel at ITC with Bill.

11. Adjourn

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

Respectfully submitted,
Ian McIntosh