Minutes of Weekly Meeting, 2016-09-21

Meeting called to order: 11:07 AM EDT

1. Roll Call

Ian McIntosh
Brad Van Treuren
Carl Walker
Brian Erickson
Peter Horwood (joined 11:08)
Heiko Ehrenberg (joined 11:22)

By Proxy:

Eric Cormack
Adam Ley

2. Review and approve previous minutes:

  • Approval of August 17 minutes (updated draft circulated 08/20/2016).
    • No corrections noted.
    • Insufficient attendees to vote on approval.
  • Approval of September 7 minutes (draft circulated on 09/07/2016)
    • No corrections noted.
    • Brad 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
  • The Newsletter was due at the end of July 2015.

5. Discussion Topics

a. Quick commentary on BTW session

  • There had been about a dozen attendees at BTW. Heiko had provided Ian with feedback that while there was no specific discussion of SJTAG outside of the call session, there were several points where the interlinking of IC, board and system test issues were recognised along with the need for standardization at the system level.
  • Brian reported that a common question was "When will this be done? When can we get this?"
  • Brad recalled mention that 1687 and 1149.1-2013 were stalling because they didn't have something like SJTAG as an enabler. Brian didn't remember that particular comment but did agree that they seemed to be lacking traction in the industry although 1149.1-2013 is beginning to get some.
  • Brad commented on the embedded case where the instrument accesses often needs to be kept simple (e.g. I2C or SPI) as the overhead of something like 1687 is too great. However, as devices run out of address space for I2C and SPI, 1687 becomes more palatable for "write once" configuration registers where the 1687 network could sit behind a single address.
  • Ian asked if it was possible to get the WebEx session recording downloaded as he wasn't sure how long it would be retained on the WebEx server. Carl thought the recording would be retained for at least six months, but would look into downloading it.

b. Continue PAR discussion
- Review re-drafted "Need"
- Check Scope, Purpose and Need for consistency.

  • {Brad shared the 'Need' slide (Slide 35) from the previous meeting}
  • Ian was concerned about the use of "fail to" and proposed "do not" instead, as the existing wording incorrectly implied that 1687 and 1149.1-2013 had not achieved something that was expected of them. Brad and Heiko agreed.
  • Brad wondered if this was concise enough, but could not see how to shorten the statement without losing the granularity.
  • The meeting referred back to Adam's forum posts on the PAR format {shared} to check the guidance on the Need statement. While the Scope is mandatory and must appear verbatim in the standard and the Purpose is optional but appear in the standard is present in the PAR, it seems the Need is not required for the standard. Ian recalled that it is primarily for TTSC/NESCOM consideration, and the guidance is simply that it should be "brief" and "a few sentences" (it is currently 5 sentences, some quite long). Ian felt it best just to leave it for now.
  • Brad pulled the latest versions of Scope, Purpose and Need into a new slide pack {shared}.
  • The slides were checked that they were written in present tense and re-checked for readability.
  • The Scope was in present tense, and no further edits were identified. All text set to black.
  • The bullet points used during composition of the Purpose were deleted. The statement is in present tense. Ian felt that it was not clear exactly what was being "integrated" and proposed replacing "with" in the first sentence with "by utilizing" to better separate "what" from "how". Brad agreed, but suggested that "by using" would be a slightly better choice of words. All text set to black.
  • Need statement is in present tense. Since this was reviewed earlier in the meeting it was not expected that there would be any further revisions. All text set to black.
  • New slides:
    • SCOPE:
      • This standard defines methods to allow, in conjunction with existing methods, for the coordination and control of device, board, and sub-system test interfaces to extend access to the system level. The standard does not replace or provide an alternative to existing test interface standards, but aims instead to leverage them by defining a description to better manage how they are used in the system.
    • PURPOSE:
      • The purpose of this standard is to provide a means to seamlessly integrate component access topologies (that follow a Capture, Shift, Update cycle), interface constraints, and other dependencies at the board and system level by using a uniform description that focuses on topology and behavior (as opposed to physical structure). By modeling this topology at the board and system level, a set of familiar and yet interchangeable interfaces may be used by higher level tools to coordinate these access topologies and provide a means of routing data sets to particular destination registers in the correct time order.
    • NEED
      • A standardized method is needed to coordinate component access topologies, interface constraints, and other dependencies at the board and system level in order to be able to effectively leverage the existing and future component level standards. Thus, a new supervisory standard is required to define the coordination and dependencies of instruments as well as configuration, management, and application of vector based testing at the board and system levels. For example, IEEE 1687 and IEEE 1149.1-2013 provide methods for describing each of the instrument interfaces on a per component basis, but do not provide the contextual prerequisites for the dependence on each instrument configuration and/or aggregation of multiple instruments for the overall board and/or system maintenance operations. Further, many components only support non-JTAG interfaces (e.g., I2C or SPI) to their instrumentation registers. This standard will provide a means to utilize the pin level access provided by other standards.
  • The new slide pack has been added to the file manager: http://files.sjtag.org/Brad/Final%20SPN%20Draft%2020160921.pptx.
  • The above Scope, Purpose and Need have been posted to the forums and comments should be made there: http://forums.sjtag.org/viewtopic.php?p=1176#p1176.

6. Topic for next meeting

  • Enumerate our requirements
    • What are we trying to implement?

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.

9. Schedule next meeting

  • Next meeting September 28. Eric will be absent.
  • October schedule:
    • 5, 12, 19, 26.

10. Any other business

  • Brad mentioned that in the 1687.1 meeting, Jeff Rearick had referred to 1685, a standard related to circuit descriptions in XML that Brad had not previously been aware of. As this defines the structure of Intellectual Property (IP) inside of a circuit Brad thought we may be able glean some things from it that we could use in our descriptions. It is notable that it refers to "meta-data documentation" which may be what we need. Brad was cautious though that its usefulness may be limited as it was concerned with structure while we are more concerned with behaviour. Some of the graphing used is interesting and seems similar to UML and we probably need something, UML or similar, to assist in pictorially representing our ideas.
  • 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

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

Respectfully submitted,
Ian McIntosh