Minutes of Weekly Meeting, 2017-03-13

Meeting called to order: 11:14 AM EDT

1. Roll Call

Ian McIntosh
Carl Walker
Brian Erickson
Brad Van Treuren
Heiko Ehrenberg

By Proxy:
Peter Horwood


2. Review and approve previous minutes:

  • Approval of March 6 minutes (draft circulated on 03/06/2017)
    • No corrections.
    • Brian 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.
    • Heiko had contacted Adam Cron on this matter and Adam had passed on the Study Group guidelines (http://standards.ieee.org/develop/corpchan/studygrp.pdf). It was noted that these may be more useful than the Operations Manual.
    • Ian hadn't read the document but Heiko commented that it did not look very specific in terms of required documentation, so Heiko will ask about forming a Study Group at the TTSC meeting on April 5th, and remarked that, between the website and minutes, we have plenty of information around if anyone wants to look into it.

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.

  • {Brad shared a copy of the spreadsheet updated during the Feb. 27 meeting}
  • The previous meeting had considered whether it was possible to address the derived standards by dealing with the "parent" standard appropriately - the conclusion was that it was possible but portability would suffer.
  • Ian remarked that he had forgotten that there was a column headed "Core (Draft 1)" intended to show interfaces that should be included in the initial standard.
  • While the previous discussion had looked at I2C and it's derivatives, Ian wondered if it were easier to approach the 1149.1 based standards in that way. Brad felt that rows 5,6 and 7 could be represented purely by 1149.1 - it is effectively what SVF does, and Peter had previously commented on the need to support "canned tests" for black box cases.
  • SVF and STAPL lacked the fine-grained control necessary to be used for system level control *; they are vehicles to apply vectors but lose the knowledge of system behaviour.
  • [* Peter, by email] This is not the case when using a Firecron Gateway device as the chain selection protocol is contained within the SVF or STAPL vectors (operating within the 1149 state machine) enabling total control of the scan chains.
  • Brian asked if that suggested there was a need for a more efficient vehicle. Brad felt not, but that there was a disconnection of the capability for diagnostics when moving to SVF or STAPL. Brad mentioned that the SJTAG demo showed how a test could be ported and still retain a diagnostic capability.
  • [Peter, by email] As shown at BTW 06 SVF tests were exported to SVF from an Asset system and executed on a remote controller with the execution results being imported back into the Asset tool or they can be fully diagnosed by the run time provider.
  • Ian suggested that in the COTS of secure systems, it may be that case that a go/NoGo result is all that is required. Brad argued that could lead to NTF/NFF when a FRU is returned as the operating environment can't be replicated. Brad cited an example given by Bill Eklow where a snapshot of the state of an ASIC could be captured or test data returned and analysed at base before the FRU had even left the customer premises.
  • [Peter, by email] The snapshot state can be generated from either an SVF or STAPL test, it all comes down to the runtime providing results data in a format that can be used.
  • Brad noted that "something" has to manage what we're connecting to and asked if that was something that SJTAG had to do.  He felt many would see it as inadequate if we did not.
  • Brad tried to take the kind of viewpoint that Michele might: Can we abstract to a common set of operations? Ian seemed to recall that Michele had suggested that many interfaces could have the capture-shift-update cycle imposed, even if that wasn't the way they were intended to operate. Brad referred to a proof of concept that he had done where the control of 1149.1 was through I2C on a backplane. That didn't follow the CSU cycle but used I2C as I2C. Brad noted that some of the interfaces that weren't CSU were providing a response to a command.
  • Ian remarked that whether it was I2C or 1149.1, it was a key point that a system ought to provide external access to the various targets within the system, for initial bring-alive or recovery of a corrupted system. It was the notion of SJTAG as an "enabling technology" - once the principles are in place, it enables other things that may not even have been conceived of at the outset. Brad suggested that it was possible that we might prevent such extensions and 1687 did that. Ian argued that while it would allow various solutions to emerge that were outwith "SJTAG compliance" there are precedents such as 1532 formalising an extension of the use of 1149.1 for device programming that many people were doing in ad hoc ways.
  • Brad added columns to the table for "CSU adherence" and "Command/Response" and started trying to mark the interfaces that followed the CSU cycle.  Brad then noted that Command/Response could be a layer above CSU. Ian added that it was perfectly possible for, e.g., a I2C temperature sensor to be repeatedly polled for data without a command ever being sent.  However, this could still be considered "Command/Response" but with a null command. Similarly, a CSU cycle may have a null (or ignored) Update or Capture.
  • Brad considered that we may be identifying a "middleware" layer for data transfer, where the Command/Response defines the reads and writes.
  • The updated spreadsheet is available on the File Manager here: http://files.sjtag.org/Brad/StandardsTable20170313.xlsx.

6. Topic for next meeting

  • Building Blocks - "Middleware".

7. Key Takeaway for today's meeting

  • Command and Response may be modelled above Capture-Shift-Update and Read/Write.

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 20.
    • Meeting will be one hour earlier than normal for European participants.
  • March schedule:
    • 27.
    • Heiko is out for the next three weeks. Brian is out April 3.

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 Carl.
  • Meeting adjourned at 12:06 PM EDT

Respectfully submitted,
Ian McIntosh