Minutes of Weekly Meeting, 2017-04-03

Meeting called to order: 11:13 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Peter Horwood
Brad Van Treuren

By Proxy:
---

Excused:
Heiko Ehrenberg
Brian Erickson
Carl Walker

2. Review and approve previous minutes:

  • Approval of March 27 minutes (updated draft circulated on 03/29/2017)
    • No further corrections.
    • Eric moved to approve, seconded by Brad. 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 - 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. Ongoing.
    • Ian will leave this action open until after the TTSC meeting.

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. Building Blocks - Abstraction, translating from abstract to a specific interface.

  • Ian and Brad both wanted to comment on Peter's proxy notes {Ian shared an excerpt from the notes including Peter's comments}.  Ian remarked that point 3 had made him wonder if he'd understood correctly what Brad had meant when adding the attribute on Parallel Protocol Architecture, as Peter's interpretation seemed equally valid. Brad agreed but noted that he had indeed been thinking about a parallel interface.
  • Ian took Peter's points 1 and 4 together to observe that in talking about "data width" we had ignored that there are other attributes such as the channel width, and the size of a possible data "frame" or packet as well as the width (or length) of the data itself.
  • Peter commented that in 1149.1-2013, it was necessary to specify which segments were being left out, so this was effectively similar to selecting a different BSR of a different length. Ian agreed that this meant the data length was known for any given setup, but the reason for the 'X' against Variable Data Width was because that width could change and was not invariant over time.
  • {Brad shared the spreadsheet from last week, ready for update}
  • Brad amended the table to add and clarify attributes, as discussed above. Brad wondered if these wre attributes associated with the AccessLink rather than the DataLink. Ian felt they belonged to the AccessLink, and that the DataLink was probably about moving the "content" rather than the structure that content needed to be in.  Ian did wonder if in prior discussions of AccessLinks we may have introduced a point of confusion: In this case we were considering the AccessLink and DataLink to share the same physical interface, but when we first made the distinction between AccessLink and DataLink we were looking at a case where the AccessLink might be and I2C interface to a device that set up a DataLink path for 1149.1 (similar to the Brocade device). Brad agreed that the AccessLink and DataLink could use the same interface but there was no requirement to do so.
  • Brad asked what we were learning from the table. Ian felt it maybe wasn't that much: Rather than seeing commonality, it looked more like a table that would help someone choose which interface was most appropriate for a particular case. There was maybe some commonality between 1149.1 and SPI if you considered only a few of the attributes, but almost none between I2C and the other two.
  • Brad suggested formulating a few Use Cases and trying to see how we'd talk to the "back-end" using each of those interfaces, perhaps a data register of fixed width that we communicate with as write-only, read-only or read followed by write to follow the CSU cycle.
  • Ian remarked that while 1149.1 followed the CSU cycle, the practicality of a real test was that you applied the test stimulus using an update first and then captured the result, so you had two CSU cycles, each with "wasted" data out or in (ignoring that tooling can exploit that when applying multiple vectors). Ian's point was that the end user's perspective may be different from the tooling perspective. Brad saw this as "behavioural", much as Michele has been pushing for some time. Ian suggested that the CSU was really a result of the way the TAP worked and the "economy" of the interface itself.
  • It seems typical of testing in general that stimulus is applied and then a measurement taken. Even when there is no direct application of a stimulus, it may be applied by the environment or state of the UUT.
  • It seemed more appropriate to look at something more like a very simple interconnect test, rather than an arbitrary register, Peter suggesting the typical kind of example you would show in a presentation on 1149.1 with two devices and the TDO of one connected to the TDI of the other; write on one side and read on the other.
  • Brad asked if we needed a simulation or a walkthrough in PowerPoint. Ian felt the walk through would be simpler to deal with, at least initially.
  • The updated spreadsheet is available on the File Manager: http://files.sjtag.org/Brad/CompareContrast20170403.xlsx.

6. Topic for next meeting

  • Building Blocks - Use Case of a simple Interconnect Test.

7. Key Takeaway for today's meeting

  • Economy of the interface (with regard to 1149.1).

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 April 10.
  • April schedule:
    • 17, 24.

10. Any other business

  • Ian has been approached to give an update on SJTAG to the Nordic Test Forum, but is still waiting to find out if Leonardo will fund the trip.
  • 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

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

Respectfully submitted,
Ian McIntosh