Minutes of Weekly Meeting, 2014-01-06

Meeting called to order: 11:05 AM EST

1. Roll Call

Carl Walker
Ian McIntosh
Patrick Au
Peter Horwood
Eric Cormack {joined 11:07)
Brad Van Treuren (joined 11:09)
Heiko Ehrenberg (joined 11:15)

Excused:
Adam Ley
Michele Portolan
Brian Erickson

2. Review and approve previous minutes:

11/18/2013:

  • Approval by email:
    • Moved by Carl, seconded by Eric.
    • 4 votes for approval, 3 abstentions.
  • Approved.

11/25/2013:

  • Approval by email:
    • Moved by Carl, seconded by Eric.
    • 3 votes for approval, 1 abstention.
  • Approved.

12/02/2013:

  • Approval by email:
    • Moved by Carl, seconded by Heiko.
    • 4 votes for approval, 0 abstentions.
  • Approved.

12/09/2013:

  • Approval by email:
    • Moved by Adam, seconded by Brian.
    • 3 votes for approval, 2 abstentions.
  • Approved.

12/16/2013:

  • Draft circulated 12/16/2013.
  • No corrections advised.
  • Insufficient attendees to vote on approval.

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)
  • Harrison will attempt to come up with a table of use cases and their associated layer and what can be done at that layer. CANCELLED.
  • Ian/All: Look for real world examples of boards that we could take through from board test to a system test implementation as a worked example case. CANCELLED.
  • Ian - Add the previously discussed lists to the 'master' template. Ongoing.
    • Some sections need further expansion that may take time to develop.

 

  • Ian suggested that the action on Harrison could be cancelled as the original task had been done and Harrison was now unlikely to attend in the foreseeable future to offer any further expansion of his slides.  Additionally, the action to identify a real world example of a board design now seemed to be redundant as the synthetic example that has been used for the template work so far seems to be adequate.  Brad moved to cancel both actions, seconded by Peter with no objections.

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

a. Moving forward:
- How has Scope and Purpose changed? See http://www.sjtag.org/ home page.
- Can we outline a hierarchy/structure of SJTAG standards? See Heiko's additional notes from BTW in the previous minutes, Brad's email of 12/09 and Ian's email of 12/31.

  • {"Mission, Scope and Purpose" from website home page shared.}
  • Ian wanted to check that the Scope and Purpose were still representative of what we now felt we were trying to address but felt that rather than trying to redraft anything directly we should firstly just identify what we thought was now incorrect.
  • MISSION:
  • There were no objections to anything in the current Mission statement
  • SCOPE:
  • The end of the first sentence suggests that "system domains" must always mean a multi-board configuration and this does not seem to fit with our current view of what a system might be.  Brad noted that what is important is where the boundaries are for SJTAG - we don't go into the device but deal with boards and the infrastructure in which the board resides.  Brad further suggested that maybe we should be restricted to consideration of only interfaces, but was also reminded of the System Data Elements diagram that evolved into considering "devices" and "assemblies" to encompass various hierarchies. Perhaps there is a delineation based on access link types - how we go about connecting to a particular access link.
  • Ian noted that he wanted to avoid re-inventing Dot5.  Brad observed that Dot5 essentially became a Test and Maintenance Bus Manager.  Peter agreed and felt the standard should provide enough intelligence without burdening the smaller system with additional resource requirements.  At the opposite end, Brad noted that Dot5 simply duplicated some features that may already be present in larger systems, and that it mandated a specific 1149.1 interface protocol.
  • Brad felt that SJTAG's Dot0 should probably rely on 1149.1 but provide scope for alternatives in future expansions.  Ian thought that so long as the scope was loose enough then the details of how to fit any extensions in could be worked out later.  The danger was painting yourself into a corner by being too prescriptive at the outset.
  • Brad commented on SJTAG as an "enabler" for features on the board, but began asking what was meant by "enabler" and "access mechanism" - were they the same or different?  Ian thought they felt like different things, Brad adding that maybe an enabler provides the signal path but not the protocol.
  • Brad was concerned that there was protocol used, e.g. to manage a multidrop bus and different protocols that apply to the devices in the chains.  Ian saw this as a layering: You had protocols that may be used for chain selection or to manage the system, but once that was done you simply passed signals to the devices and didn't need to know about what protocols were being used at the device level.  The two levels of protocol were distinct.  This was already covered in the Scope where we said the standard would develop a method for accessing features but not deal with the features themselves.  Brad noted that other standards, like P1687 made similar statements.  Ian agreed and saw it as nesting of the offload: P1687 get the signals from the chip edge to the instrument without knowing what the instrument does, SJTAG gets signals from the system edge to the chip without needing to know what the chip does.
  • Brad thought we may have had the wrong viewpoint previously, and should instead be considering the access to the system.  Ian commented that, from an external test perspective, the division of a system into several boards or boards and daughterboards was partly artificial:  What mattered during a test was what was connected to what, not whether a device was on Board 1, Board 2 or Board 3 - that was more important for any subsequent maintenance activity.  So it came down to how you use and manage the chains.
  • Peter felt that what SJTAG needed to say was that you could have interfaces that may or may not be 1149.1 that can be used to configure the JTAG chains in the system, while the JTAG chains themselves used 1149.1.  There could be an input file to describe the devices without necessarily getting involved in what is all in "the cloud" in the middle, with an output that is the scan chains connected in a particular manner.  The tool vendors can then bring their value add by how they deal with what's in the cloud.  Brad remarked that we were considering what data packets we had to deliver and how do we deliver them? The delivery mechanism might be the tool vendors value add, but there might be a need for an equivalent of a PDL to describe how to enable the path of the scan chain.
  • Brad pointed out that what we are really talking about is the management of chain segments at the board and system level.  P1687 describes scan segments (called scan networks) that represent the instrument data registers and the paths to access them.  What is important for us is the realization we need to manage what scan segments get scanned at what instance in time.  It is about ordering the data packets and their arrival at a particular instance in time.  We don't have a single scan chain, but really a collection of scan segments that have data to be scanned in a particular order in time.  Michele and I have been working on trying to describe this and have a few patents on this subject already.  We have proven that you can represent the model of these scan segments by a binary search tree and use the traversal of this tree to determine the correct ordering in time of the particular scan operation for each scan segment.  We are publishing an article in IEEE Design & Test on this subject.  I am not sure it has been published yet. [Michele confirmed the article is now published in the latest IEEE Design & Test special issue - 10.1109/MDAT.2013.2278541].  For SJTAG, each segment might be controlled by a different access link mechanism (e.g., multi-drop, ethernet message to board management processor, ScanPathLinker, second physical TAP Controller).  The key is to be able to describe both how to manage the access link to that scan segment and to manage or describe the ordering of when scans must take place to that scan segment.

6. Key Takeaway for today's meeting

  • There is a delineation between the data being transmitted and the control of the paths to the end points for the data.
  • We need to define the inputs and outputs of "the cloud" (the scan path selection) without worrying about what is inside the cloud.
  • The protocols for control are separate from any protocols being transferred through the interface to devices: The latter are expected to conform to 1149.1 but the former may or may not.

7. Schedule next meeting

  • Next Meeting: January 13.
  • January schedule:
    13, 20, 27

8. Any other business

  • None.

9. Review new action items

  • None.

10. Adjourn

Eric moved to adjourn at 12:03 PM EST, seconded by Brad.

Respectfully submitted, Ian McIntosh