Minutes of Weekly Meeting, 2013-05-06

Call to Order:
11:05am EDT

1. Roll Call

Eric Cormack
Carl Walker
Adam Ley
Brian Erickson
Heiko Ehrenberg
Harrison Miles
Tim Pender (joined 11:14am EDT)

Excused absences:
Patrick Au
Ian McIntosh
Brad Van Treuren

2. Review and approve previous minutes:

Approval of April 29 minutes sent Apr. 30):

  • no corrections noted;
  • moved to approve by Adam, second by Harrison, no objections;

Approval of April 22 minutes sent Apr. 23):

  • no corrections noted;
  • moved to approve by Heiko, second by Adam, no objections;

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
  • Harrison will attempt to come up with a table of use cases and their associated layer and what can be done at that layer. Ongoing.
  • 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. Ongoing.
  • Ian: Update draft newsletter and circulate for email approval. -- DONE
    There were two small corrections noted by Brad and Adam that were incorporated prior to issue.
    The motion to approve came from Brad, seconded by Heiko. There were no dissenting votes, although only four votes in total were cast.

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

  1. Consolidation of the concept of protocol/interface layers as they apply to SJTAG.
    • {Ian sent the following pre-meeting notes, marked with "** Ian:"}
    • ** Ian: To build upon my comment from two weeks ago about 1149.1-2013 having complicated things by introducing behavioral requirements on top of the existing interface description: I'm a little wary of further use of networking analogies in our discussion (they may not really mean much to some of our group), but I can't avoid considering this: In networking you have common protocols like TCP, UDP, ICMP: There are protocols that sit on top these, such as HTTP, FTP, SMTP which rely on TCP for instance. But TCP, UDP, ICMP all sit on top of IP (Internet Protocol). I tend to think of 1149.1 as JTAG's IP layer and is about how you move things between some controller entity and the registers of a device while dot6, dot7, P1687 start to bring in 'behaviors' in terms of making the device 'do' something (dot4 is perhaps an oddity here since it more of true extension to dot1).
    • ** Ian: These latter standards are all device selection dependent: You may have a BScan chain on your design but while you can say "I want to test this board with JTAG", you can't necessarily say "I want to test this board with P1687" since that requires that you actually have P1687 capable devices in the design and that is not a given.
    • ** Ian: 1149.1-2013 has now crossed a boundary and muddied the waters: Sure, the extensions are optional and we had options before, but whether a device had a TRST pin or an IDCODE register didn't really influence what the device could do during test. I think I would rather have seen the 2013 additions floated out into another standard (and not necessarily even part of P1687).
    • Harrison notes that market pressure has dictated many of the things that have been introduced in 1149.1-2013, other standards have not been there quick enough;
    • ** Ian: Back to SJTAG: Unlike the networking analogy, rather than fanning out into more refined specifications as we move up the layers, each reliant on one specific protocol below it, once you go above the P1687, dot7 (and indeed 1149.1) you actually run into a need to pull diverse and possibly contradictory protocols together and use them all within one tool. That doesn't mean that SJTAG can't appear outwardly similar to an existing standard; but it will need to be different to it.
    • SJTAG needs to take information from the "south-bound" interface of those other standards and pass that to the "north-bound" interface; these other standards don't really have any self awareness, SJTAG needs to take their feedback and control the flow and pass information on intelligently;
    • ** Ian: With the other issue we identified a couple of weeks ago, it's also dangerous or misleading to try to equate any of the 'layers' as being exclusively linked to some particular level within the hardware hierarchy: 1149.1 operates on a chain and doesn't know if that chain is within a device, a board or a rack assembly. The same probably applies to all the other common standards because the concept of a 'boundary' is something of a moveable feast.
    • Harrison disagrees on the issue of layers not being useful, in P1687 for example layers are very important;
    • {Brian left at 11:24am EDT}
    • Ian suggested a few topics for our discussion today: The following are sub-topics that Brad had discussed with me [Ian] - the items marked with a '*' have been covered to some extent within recent meetings:
      1. Mining the scan interface primitives from Mike's presentation to capture as a set of verbs for the kinds of things we want to do at the system level.
      2. To be considered is a discussion about the concepts needing to be captured by a description language for the interactions between devices/instrument.
      3. * I would go back to the resurrected slides of the protocol stack and talk through where Mike's example overlapped (actually he had application, test management, and TAP controller has his main blocks).
      4. * A discussion on a "virtual P1687 register" meaning the access to a physical functional register set for instruments in non-boundary-scan devices. Mike demonstrated his ability to kick off BIST operations in a non-boundary-scan device and read the status pin for the results using the BSR of an FPGA in EXTEST as GPIO. Certainly, that does not fall within the scope of P1687, but could for SJTAG.
    • {We did not get a discussion going and Heiko suggested we wrap the meeting up early.}

6. Today's Key Takeaways:


7. Schedule next meeting:

May schedule: 13, 20, 27
- 13 : Eric out
- 27th is Memorial Day, US-based attendees will likely miss that meeting; we should probably skip the 27th;

8. Any other business


9. Review new action items


10. Adjourn

Tim moves to adjourn, Eric seconds;
meeting adjourned at 11:30am