Minutes of Weekly Meeting, 2017-06-19

Meeting called to order: 11:09 AM EDT

1. Roll Call

Brad Van Treuren
Carl Walker
Eric Cormack
Heiko Ehrenberg
Peter Horwood

By Proxy:

Bill Eklow
Ian McIntosh

2. Review and approve previous minutes:

  • Approval of June 5 minutes (updated draft circulated on 06/07/2017)
    • No corrections noted.
    • Eric moved to approve, second by Carl; no objections; -> approved.

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
  • Possible invitation for Al Crouch to talk about Parallel SIBs.

5. Discussion Topics

a. TTSC meeting preparation / Anything arising from SKIDL discussion.

  • Heiko: Do we want to become a study group at this time?
  • Eric: We think it is time to make the next step and request to become a IEEE study group.
  • Peter: Do we need to start using the IEEE portal for meeting minutes, etc? Heiko said that he seems to remember that it was recommended to do so, but not necessarily required (for study groups) to do so, as long as progress and participation is documented somewhere and documentation is available to TTSC.
  • Heiko should request to be put on the agenda for the upcoming TTSC call {ACTION}. If we don't change our mind before the TTSC call, Heiko (or someone else being on the call) can make the case as to why we want to become a study group (arguments to be worked out in our conference calls until then). Adam Cron could request documentation from us prior to the TTSC call if we get added to the agenda.
  • SKIDL discussion should also continue within the study group.
  • Brad: Existing tools have limitations in their current retargeting capabilities. We need to show deficiencies of current standards and explain how we envision closing that gap for SoC / board / system level test environments.
  • Brad: Retargeters generate static test sequences, focused on static topologies. Boards and systems however require handling of dynamic changes in topology / order of events. PDL0 may just define a pattern to be applied to the instrument, it does not define the protocol on how to get to that instrument. 1687 leverages ICL to define how to access the instrument. PDL1 allows flow control based on feedback responses.  1687 and 1149.1-2013 rely on the AccessLink definition (with 1149.1-2013 it is always JTAG) and 1687 assumes the AccessLink protocol to be understood by the retargeting tool as defined by the ICL description. PDL generally doesn't describe the access link protocol, but the data being sent to the instrument in the correct order. Tcl could be written to define the protocol at each level, but a chip tester retargeter does not play Tcl at execution time, but instead uses the PDL code as a template for how to write the appropriate sequence for a specific tester native language.  Thus, runtime decisions regarding flow control are not supported or are limited in support for those environments.  APIs could be used to define Read, Write, and Read/Write methods in order to specify specific protocols to be used in conjunction with patterns defined in PDL. The problem comes with the context of the messages.  What is a write message?  For 1687.1, it could be one or more commands consisting of data spanning multiple write operations.  For example, there could be a Scan With Capture command to send data to a specific scan network followed by reading data scanned out of that network.  It may be a command that has been optimized and use only Scan Without Capture.  How is the Write method to know how to interpret the data bits being sent at an I2C level? This is the context issue that is not addressed. It has become clear in discussions that people generally prefer to delegate decisions to the next higher level through call-back functions (e.g. I2C protocol should be defined at a higher level, where the test pattern description file does not need to be concerned with how to deliver that pattern). So is there a way to write a "device driver" type of method that defines the protocol for a level in a generalized format?  Does it leverage write, read, read/write primative methods of an AccessLink to perform the low level transmissions following a specific data flow?  Is the protocol really scoped to the DataLink or to the AccessLink?  These are all questions that remain unanswered and suggesting they can be handled using callbacks is insufficient.
  • Peter voiced a concern related to having to prove that we won't compete with an existing standard. Our understanding is that we would need to show why our approach would be better if we overlap with something already addressed in other standards.

6. Topic for next meeting

  • Building Blocks - Use Case of a simple Interconnect Test - continuation.
    • Translating AccessLink specification.

7. Key Takeaway for today's meeting

  • None.

8. Glossary terms from this meeting

  • None.
  • Carried over:
    • Definition of "interchangeability" required.
    • 'Instance' (or a more specific version of the term) may require definition in future.
    • 'Master through Slave Mode'
    • 'Master to Master Mode'
    • Need a refined definition of "system" for the purposes of the PAR.
    • 'Priority' - may relate to 'frequency' and 'urgency' in distinct definitions.

9. Schedule next meeting

  • Next meeting June 26 (Heiko and Brad will be out).
  • July schedule:
    • 3, 10, 17, 24.

10. Any other business

  • Ian hopes Michele will be able to provide a fuller report on the TESTA tutorial in due course.

11. Review new action items

  • Heiko to request SJTAG to be put on TTSC meeting agenda; suggest Adam request any material as needed prior to that call.

12. Adjourn

  • Eric moved, Brad seconded.
  • Meeting adjourned at 12:01 PM EDT

Notes prepared by Brad Van Treuren from initial draft by Heiko Ehrenberg.