Minutes of Weekly Meeting, 2016-12-14

Meeting called to order: 11:05 AM EST

1. Roll Call

Ian McIntosh
Carl Walker
Eric Cormack
Brad Van Treuren
Brian Erickson
Peter Horwood
Bill Eklow (joined 11:09)

By Proxy:
---

Excused:
Heiko Ehrenberg

2. Review and approve previous minutes:

  • Approval of October 26 minutes (draft circulated on 10/26/2016)
    • Moved by Bill, seconded by Heiko, approved.

  • Approval of November 2 minutes (draft circulated on 11/02/2016)
    • Moved by Eric, seconded by Peter, approved.

  • Approval of November 9 minutes (updated draft circulated on 11/13/2016)
    • Moved by Eric, seconded by Peter, approved.

  • Approval of November 23 minutes (updated draft circulated on 11/23/2016)
    • Moved by Eric, seconded by Heiko, approved.

  • Approval of November 30 minutes (draft circulated on 11/30/2016)
    • No corrections noted.
    • Eric moved to approve, seconded by Brian.
    • No objections or abstentions.
  • Approval of December 7 minutes (draft circulated on 12/07/2016)
    • An error in the date had been previously noted by email.
    • Brad moved to approve as amended, seconded by Eric.
    • 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.
  • Ian: Make final edits to newsletter and circulate for email approval. 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

b. PAR text feedback
- Newsletter/LinkedIn post

  • Ian chose to deal with this item first.
  • The newsletter had been sent out and a copy of the text posted to LinkedIn.  There has been no direct feedback so far, but this was not unexpected.
  • Ian noted that LinkedIn provides a running demographic breakdown of the readers of the article and had captured a snapshot earlier in the day {shared}.

a. Enumerate our requirements
- What are we trying to implement?
- Review previous Key Takeaways for relevant ideas - continue from row 72

  • The intent was to continue with the breakdown of the Key Takeaways.
  • {Brad shared the Key Takeaways and the Requirements worksheets}
  • Row 72 had no relevance to current activity.
  • Row 74 commented that slow interfaces were more appropriate for control than for data and I2C was cited as an example of a slow interface. However it was acknowledged that often data was passed over I2C and slower interfaces.  Indeed, P1687.1 was looking at transacting data over I2C. Bill thought this might be something to pass to P1687.1 and take what they came up with.  Brad noted that it was our intent to leverage other standards in that way. Ian considered that it wasn't possible to dictate what interface would be available, so maybe this should just be some kind of note.  
  • Row 75 suggested that the SJTAG standard should describe the chain management in a general manner. Bill wanted to put this into a context for a Study Group, commenting that we should ask "What are the challenges? What is the problem we are trying to solve?", and that this was elucidating a part of the problem. Brad agreed that we should probably note this as a goal for the group.
  • Row 76 held three takeaways.
  • TDR as an instrument  After a little discussion, Ian felt this was probably just a note on nomenclature that may need to be spelled out for some users who may see instruments as "complex" entities. Brad noted that 1149.1-2013 provided some context to the TDR as an instrument, so it may not be an issue.
  • Standardise descriptions of IO behaviours. This raised some discussion of what was intended. The original notes referred to Flash programming and I2C access as examples, which could be considered as Use Cases but ultimately these could be decomposed into Reads, Writes and Initialise operations and was essentially what Michele's model did. 1687's PDL provides such a description but it is up to the implementer to define the context. The question is "How do we describe the device in a neutral way?" Peter asked if Brad was suggesting that we specify a generic file format. Brad wasn't sure that he was and noted how JEDEC use a Boolean logic model as way to describe DDR test operations on top of 1581. Peter felt it was probably similar to the case with BSDL, where each tool vendor may use their own internal model and simply use a front-end translator to import the BSDL. Ian had the feeling that this maybe wasn't "core" to SJTAG as it could be done without standardisation, so it was maybe an easement that could be provided by an extension.
  • The last point was that "canned vectors" have difficulty in dealing with the case where a range of return data is possible, e.g. alternate device IDs or where the data represents an analogue value. Ian felt that part of the issue is the nature of 1149.1, which basically expects to do a bit-by-bit comparison on the data, and Don't Cares are not sufficiently flexible. This is unlike an analogue test where you'd declare the type of measurement you're taking and the upper and lower limits for the result. Brad thought that the definitions for the AccessLink and DataLink need to provide a programmatic means to analyse the return data.  Most tooling now provides a means of doing that but it is not automated.

  • The updated version of Brad's Requirement Excel file is available here: http://files.sjtag.org/Brad/SJTAG%20Requirement%20List%2020161214.xlsx.

6. Topic for next meeting

  • Enumerate our requirements - continued
    • What are we trying to implement?
    • Review previous Key Takeaways for relevant ideas - continue from row 77.

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 January 11, 2017.
    • Several people expected to be unavailable on December 21st. In addition, a number of people, including Ian, would only be returning to work on January 4th, and there may be little time to prepare for a meeting, so it was agreed that the next meeting should be January 11th .
  • January schedule:
    • 18, 25.

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

  • None.

12. Adjourn

  • Brian moved to adjourn, seconded by Eric.
  • Meeting adjourned at 12:05 PM EST

  • Best wishes to everyone for Christmas and the New Year!

Respectfully submitted,
Ian McIntosh