Minutes of Weekly Meeting, 2015-04-20

Meeting called to order: 11:05 AM EDT

1. Roll Call

Ian McIntosh
Carl Walker
Eric Cormack
Peter Horwood
Brian Erickson
Tim Pender
Heiko Ehrenberg
Brad Van Treuren (joined at 11:08 AM)

Adam Ley
Michele Portolan

2. Review and approve previous minutes:

4/06/2015 minutes (draft circulated 4/06/2015):

  • No corrections noted;
  • moved to approve by Tim, second by Brian;
    • No objections or abstentions -> minutes approved.

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.
  • Ian: Check spacing below captions on up-to-date browsers. COMPLETE
  • Ian: Determine if captions can easily be centred properly. COMPLETE

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. Revisit draft PAR statements - continuation, look at formal PAR format.

  • Ian had circulated two PAR examples, one from 1687 the other he had collected from the PAR submission system himself.  Ian had thought the latter was part filled out for SJTAG, but is in fact a blank form:  It is useful only in that it puts all the headings closer together.
  • {Forms shared}
  • Sections 13 (Scope), 14 (Purpose) and 15 (Reason) are the main content of the PAR, and the first two of these are presented in the SJTAG Mission Statement on the home page (albeit in an out-of-date form).  As suggested by Bill at a previous meeting, none of these sections is very long - a single paragraph for each on the 1687 example - and being too verbose is probably to be avoided.
  • Section 3 is the title for the document (standard).  This needs to convey the aim very succinctly. Brad suggested "Standard for access and control of test interfaces at board and system level", making the emphasis on the interfaces themselves but wasn't too happy about using the term "level".  Ian's alternative of "Standard for access and control of test interfaces of boards and systems" was considered to be too informal.  Tim suggested swapping the order to "systems and boards" to put the emphasis on systems. Brad wondered if we needed to delineate between boards and systems since we considered them as just "assemblies".  Group agreed that yesterday's system is now often today's board.
  • Should we be mentioning "semiconductors"? Do we only have semiconductors?  Ian felt mentioning semiconductors might make it seem more a chip level effort and there may be a problem differentiating from 1149.1.  Brad noted that we were talking about getting to the device test infrastructure, 1149.1 is the device test infrastructure. Heiko felt this might mean it is more important to get the Purpose and Scope correct.
  • Brad thought we might be trying to do too much in a single standard and it may be better to delegate some parts out to other standards developed by their own groups.  That would still leave the problem of what that decomposition would be, although it should help  to clarify our Scope and Purpose.
  • In looking at section 13, Ian noted the ancillary question on dependency on other documents, which might be an issue if decomposed.  Brad felt that was OK.  Brad's intent was to pare down to a core then expand within extensions - leaning towards the Use Case for board level with e.g. gateway support added by an extension as a dependency. Treat it as a data management problem. Start with something simple and expand the core only when we find something we can't live without.
  • Start by assuming pure 1149.1 synergy and consider the hardware interfaces, structural definitions, behavioural definitions that a software model would need.  Consider how board chain management, which would be necessary, would impact that.
  • Ian wondered if some of our recent discussions were leaning towards a solution for all test of a system while the original vision had been for a means to make JTAG useful at the system level - perhaps the "pure 1149.1 synergy" was more like the latter. Brad commented that 1149.5 tried to be the system test and maintenance bus so we needed to avoid some it problems (e.g. dependency on a specific controller resident in a chip) while taking note of what elements have been adopted.
  • Peter agreed that we needed to declare that we have an interface to a board but should we also be defining the signal voltage?  Probably not, that's implementation dependant - it's vectors sent over some interface and could involve a "proxy", so if the core talks about "an interface" then there could be a dot that describes how the proxy could fulfil that interface.
  • Core could say "Each module shall be capable of executing JTAG vectors...", "These signals must be available..." and could give an example perhaps using a test header on a board.
  • Tim felt some details may be needed.  For example PCI includes JTAG but there's no indication of whether it's expected to be routed on the backplane. Brad noted that if taking it to a backplane multidrop then some form of gateway device would likely be required.
  • Although multidrop was commonplace, Ian wondered if we were proposing to exclude ring and star arrangements: They may have their own issues but they can work for some people.  Peter added that, in volume, the cost savings over using gateways might be sufficient to outweigh any inconvenience and felt we could not exclude those topologies.  Brad noted that a JTAG switch could be another "dot" standard that is still plug'n'play with the initial core.  COTS boards may have a defined interface that needs a translation board to integrate with the host system.
  • Tim commented on the capacitive load of big multidrop arrangements and that in such cases it may be better to route, point-to-point, to a "test board".
  • Brad reiterated the need to carve out aspects of control in a modular fashion and determine what is in the core:  Board chain management is probably core but multidrop isn't.

6. Topic for next meeting

  • Identify feature list for a "dot 1", e.g. a Reset that is optional but other four TAP signals must be available.

7. Key Takeaway for today's meeting

  • Gateways to be a "dot" extension rather than "core".
  • Define only an interface/portal to a board, not specific hardware.
  • 1687, etc., talk about "signals", not what they're wired into.

8. Glossary terms from this meeting

  • None.

9. Schedule next meeting

  • Next meeting April 27. Ian will be absent.
  • May schedule: 4, 11, 18, 25. Eric will be absent on 4th

10. Any other business

  • Ian had hoped to have some metrics on accesses to the Green Paper and Newsletter but had not had time to collect data before the meeting.
  • Louis Ungar had discussed SJTAG during a DFT course at a US Navy base recently and had asked how best interested parties could contact us.  Ian has supplied details.
  • Post Meeting Note: The Newsletter has been viewed by 39% of recipients: That is slightly down on the average (45%). The Green Paper has been viewed 82 times since April 6 (for reference, the previous Green Paper has had 298 hits since November 3). 

11. Review new action items

  • None.

12. Adjourn

Moved to adjourn by Eric, second by Tim. Meeting adjourned at 12:04 PM EDT.

Respectfully submitted,
Ian McIntosh