Minutes of Weekly Meeting, 2017-07-10

Meeting called to order: 11:08 AM EDT

1. Roll Call

Ian McIntosh
Carl Walker
Eric Cormack
Peter Horwood
Heiko Ehrenberg
Brian Erickson (joined 11:15)

By Proxy:


2. Review and approve previous minutes:

  • Approval of June 26 minutes (draft circulated on 06/26/2017)
    • No corrections noted.
    • Eric moved to approve, seconded by Carl, no objections or abstentions.

  • Approval of July 3 minutes (draft circulated on 07/03/2017)
    • 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.
  • Heiko: Draft data pack for TTSC and circulate to group. 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
  • Possible invitation for Al Crouch to talk about Parallel SIBs.

5. Discussion Topics

a. TTSC meeting preparation.

  • Heiko had prepared the slide pack discussed at the previous meeting and forwarded to Adam Cron in advance of the call.  Adam had made an initial comment that the likely issue would be to show how SJTAG differed from 1697.1 and 1149.10 - this was largely what we expected. Ian felt comfortable about the difference against 1687.1 but was less clear about 1149.10 as he had gained the impression that it wasn't quite the "fast alternative to JTAG" that he had understood it to be and had become more of a "debug port", however Heiko affirmed that it was a faster test access port, but not necessarily using JTAG. That being the case it had the same relationship as the other interfaces we were considering.
  • Ian asked if Heiko was comfortable that he had the information to argue any points that may be raised; Heiko confirmed that he was, and felt that the Scope, Purpose and Need in the pack went a long way to addressing any points that might come up. It was unlikely to get into any detail as that would be the work of the Study Group. Ian agreed that while we may have developed certain perspectives, a different composition in the Study Group may lead in different directions.
  • Al Crouch had sent out some suggestions on possible omissions from the "SJTAG Universe" diagram and had provided a markup on a copy taken from a previous presentation by Michele {shared - http://files.sjtag.org/External/SJTAGfromMicheleModifiedByALC.pptx}. The main points were adding acknowledgment that security (which many will see as important) is provided for by SJTAG, if only that we will pass the data required by the endpoints of the security mechanisms, and filling in the "gap" in the Reliability loop with a number of sub-topics.
  • It would be difficult to fit all of these into the existing diagram but we may find an alternative way to lay out the diagram at a later date. Peter commented that "Security" maybe actually fits in the outer yellow loop, as it can be encountered in almost every scenario.
  • Heiko will try to send out a brief note after the TTSC call to let the group know what was concluded. 

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

  • This topic had been carried over for a number of weeks. Ian felt it was really "Brad's topic" but would try to take forward.
  • The last activity had been to get JTAG, I2C and SPI version of the simple interconnect test into similar, comparable forms {shared http://files.sjtag.org/Brad/Example%20DSL%20of%20Models_20170522.txt}.
  • In simple terms, the differences that remain between the three cases are the form of addressing and the format of the data (padded/unpadded).  In the JTAG case the PDLRead and PDLWrite procedures are required to go along with the final DSL code, while the read and write statements in the I2C and SPI cases are essentially primitives.
  • Ian recalled the proposal of Michele's from some while ago that it may be possible to deal with everything in terms of Reads and Writes - from this it looks possible although addressing needs to form a part of that.
  • In a portable format, the data would need to be kept "raw" with any padding added by the specific interface handler/translator.
  • Ian tried to look at the implications of the different address forms:
    • I2C needed more information that could be determined from the connection of any address pins within the netlist; the internal base address of the device family would also need to be known. Component references don't really come into it as far as the interface is concerned (except as part of an indirect way of resolving the address).
    • In the JTAG case, address could be considered as the position in the chain (or chains) but tooling usually derives that from the netlist and at the tools level only a component reference is required. That is essentially what we'd done by referring to ICL (left) and ICR (right).
    • For SPI, the CS signals ought to be unambiguous from the netlist data, but Ian wondered if we'd used the correct notation: If these are identical parts (for the sake of argument) rather than CS0 and CS1, should these be ICL-CS and ICR-CS (i.e. component ref. - pin ref.)? Heiko suggested that CS0, CS1 may be correct if they are signal names.
  • Ian felt more work was needed on addressing and how it could be made portable.

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 July 17, Ian will be absent.
  • July schedule:
    • 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

  • None.

12. Adjourn

  • Brian moved to adjourn, seconded by Peter.
  • Meeting adjourned at 11:56 AM EDT

Respectfully submitted,
Ian McIntosh