Minutes of Weekly Meeting, 2017-03-06

Meeting called to order: 11:17 AM EST

1. Roll Call

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

By Proxy:

Bill Eklow

2. Review and approve previous minutes:

  • Approval of February 27 minutes (updated draft circulated on 03/01/2017)
    • No further corrections.
    • Eric moved to approve, seconded by Peter. 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
  • Possible invitation for Al Crouch to talk about Parallel SIBs.
  • Python Netlists (SKIDL) suggested by Brad for discussion.

5. Discussion Topics

a. Process for going to TTSC/Study Group.

  • Ian was aware that the next TTSC meeting was approaching. Heiko confirmed that it is scheduled for April 5th. Ian thought it was probably too late to get on the agenda, although Heiko advised that there usually a AOB during which it could be raised. We could advise our intent and then make the formal request at the following meeting in July.
  • Heiko noted that the agenda was usually set about a month in advance so there could be time to get on the April agenda. Ian wasn't comfortable about doing that without a good understanding of what we'd need to provide. Eric and Peter agreed.
  • Heiko undertook to raise the matter as AOB and ask what documentation would be required {ACTION}

b. Building Blocks.

  • {Brad shared the spreadsheet updated during the previous meeting}
  • Ian noted that we had grouped some interfaces as being derived from other interfaces and wondered if that allowed us to describe the base interfaces in a way that would apply to the derivatives. Brad felt that depended on the language used. The derived interfaces were refinements with additional restrictions, e.g. for a particular protocol. The AccessLink is a combination of hardware and software. If a very specific description is given for the low-level interface then it may not be possible to apply it to the derived interface(s).
  • Brad suggested they could be treated as virtual interfaces, like rows 24 and 25 but did we want to do that? Ian felt it was all about the work involved. Brad agreed but commented that it would be a good test of future-proofing.
  • Ian asked if 1687.1's consideration of I2C had looked at any derived interfaces. Brad felt that they had not thought about at all, so there was nothing to be learned from them.
  • Ian asked if I2C could be defined such that users or tool vendors could extend the description for derivatives. Brad thought that if SJTAG defined the Read and Write then a tool vendor could extend the description for, e.g. IPMI, but would it still be compliant with the SJTAG standard?
  • Brad assumed that Heiko and Brian would like something that could be translated into the language of their own toolset or executed and a result returned, probably the former being preferred. Both agreed.
  • Ian agreed that extensibility comes at the expense of portability.
  • Brad remarked that a hardship faced by 1687 is that the language is not executable - it is aimed expressly at a retargetter.
  • Brad saw that SJTAG could become like "a monitor" - describing things down to perhaps pin level of the interfaces but not actually doing any of the work to deliver the vectors. That probably falls short of what industry is expecting.  Industry expects a "glue level" on how to handle talking to interfaces in a unified fashion.
  • If SJTAG were to assume the control, the Brad saw three options:
    • Develop a language that is representational only,
    • Develop a language that is executable,
    • Develop a language that is representational but that could be translated to an executable form or directly executed.
  • Brad's TFCL could be implemented as interpreted or compiled to run faster.
  • Brad thought tools may need a new feature added to include a SJTAG format into the toolset, but Brad didn't think  tool vendors would be averse to that.
  • Peter pointed out that providing a description that can be imported will almost certainly reveal IP, so do we need to consider that? Brad agreed that for a Black Box we don't want to give away how it works. In 1687, using iScan instead of iRead/iWrite canhelp to obscure what is going on. Ian felt that sensitive data was most likely to be in the data stream rather than the AccessLink except where the method of access is intentionally obscure, e.g. to prevent injection of malicious code. Brad noted that this might be outside of our scope, for example chips may provide their own security features. Ian agreed, commenting that if we start to get involved then security will become "our problem".
  • Brad proposed a motion: "That SJTAG defers security issues to the leveraged standards". Eric seconded the motion with all in agreement. Motion carried, and noted as a key takeaway.
  • The spreadsheet was not updated so the existing version remains available on the File Manager here: http://files.sjtag.org/Brad/StandardsTable20170227.xlsx.

6. Topic for next meeting

  • Building Blocks - table of standards.

7. Key Takeaway for today's meeting

  • Security will be deferred to the leveraged standards.

8. Glossary terms from this meeting

  • 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 March 13.
    • Noted that DST begins in the US on March 12 (meeting will be one hour earlier than normal for European participants).
  • March schedule:
    • 20, 27.

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 - Raise AOB item at TTSC meeting to express our interest in forming a study group and enquire what material we would need to support the request.

12. Adjourn

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

Respectfully submitted,
Ian McIntosh