Minutes of Weekly Meeting, 2015-02-09

Meeting called to order: 11:05 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Peter Horwood
Brian Erickson
Carl Walker
Tim Pender
Brad Van Treuren
Michele Portolan
Bill Eklow (joined 11:32)

Adam Ley
Heiko Ehrenberg

2. Review and approve previous minutes:


  • Draft circulated 02/02/2015.
  • No corrections noted.
  • Eric 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.
  • Ian: Discuss opportunity for a panel at ITC with Bill.

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. Any material for ITC?

  • Ian had contacted Bill about a possible panel.  Bill had noted that poster was also available and that and abstract wouldn't be required for standards.  While our topics might be a good draw for the board test community, Bill felt it was key to make it appealing to the rest of the test community. 
  • The wording of the question to be debated would be crucial in getting the right interest, so Ian thought it was worthwhile knowing that Bill's hope was to have a broad appeal.
  • Brad thought that one question might consider whether, from an execution model point of view, it was better to have a global vector or to manage the vectors at a segment level.  He was concerned that many people may not understand why managing at the segment level was important and that it may be too much to take in during the course of an hour or so. Ian thought that might be underestimating the ITC audience but Brad noted that lots of board test engineers simply know how to use the tools they have and don't really understand  the theory behind them and why they work as they do. Ian acknowledged that the ease of use of most tooling does lead to that situation.
  • It wasn't known if there was a deadline for panel proposals to be submitted.  Ian would ask Bill if didn't join the call before the close of the meeting.
  • {The following discussion took place after 5b, once Bill had joined}
  • There was an official deadline of February 22, but that might not be strictly observed for panels.
  • Bill felt that a panel topic need to be something fairly high level - you could dig deeper once you got into the discussion.  An example might be "How do we evolve BScan into a system-level architecture?"
  • Bill noted that he'd likely have to reserve slots for invited talks and a slot on standards would be possible.
  • Brad was prompted to ask if another subject for a panel would be whether SJTAG should consider only 1149.1 as the core level of SJTAG or should it allow for other methods of controlling the access to the device?  Ian commented that some of his cases were "hybrid" and might use I2C or SPI that terminates at an FPGA so 1149.1 can be used to control the I2C or SPI devices via the FPGA.  Brad observed that there was a tooling requirement to support that kind of indirection and it wasn't generally available in most tools.  . Further, Brad stated that even IEEE 1687 has no way of describing that kind of indirect instrumentation to an I2C or SPI writer.  [Brad by proxy: IEEE 1687 can describe how to communicate with the I2C or SPI writer, but does not provide the management or aliasing of indirection that would allow you to write the ICL and PDL to describe what you really want to do with the I2C or SPI based instrument.  Basically, IEEE 1687 describes how to talk to the protocol translator, but is unable to pass the intent beyond the translator into the other protocol and control the real instrument.]
  • Bill didn't mean to imply anything by his reference to BScan above, and also noted that it could be legitimate for a panel to conclude "No, it can't be done".  A further topic suggestion might be "What are the things that are holding back system level JTAG?"

b. Revisit draft PAR statements - continuation.

  • Ian acknowledged Adam's emailed observation that this agenda item maybe wasn't achieving it's objective.
  • Ian again referenced Al Crouch's remarks on the partitioning of the solution space between standards with 1149.1 being a "border of the chip solution".  This effectively left SJTAG with scope to pick up the area between the chip boundaries.  However, Ian felt 1149.1 did address some of the space between chips (e.g. interconnect test) and this was maybe even more true when considering 1149.6.  What wasn't covered by these standards was chain management and selection.  Brad agreed that 1149.1 considered the interaction between BSRs and that a BSR could be the "1149.1 instrument".  What 1149.1 did not cover was the issue of fan out of TMS and TCK, so maybe what SJTAG could help with first was the level immediately above 1149.1 and the management of sub-chains.
  • That caused Brad to ask whether we ought to be considering something that was commercially available or creating a description for chain management.  Ian remarked that the original outline from Ben was for SJTAG to be device independent and we probably didn't want to appear to favour any specific device family.  1687 was defining changes to the silicon and could request whatever selection methods they felt were optimal.  Board designers are typically looking at the function of catalogue parts and will choose what suits their needs.  Michele agreed, noting that DFT was rarely a key factor in part selection for board designers and that systems have to make the best of what's in the sub-systems it uses, e.g. COTS boards.
  • Ian noted that some chain management devices will have features that offer some sort of value add that goes beyond the basic chain management, e.g. Firecron JTX parts have IO ports, and are full cross-point switches, but these features may not be directly supported by current tooling: Should the standardised description just address the basic features or should it also try to describe the full feature set? Could it reasonably do so?  Peter added that different tools may have different ways of accessing the devices and that these my not be supported by the standard (different paths through the state machine).  Brad agreed there may be a need to expressly detail how you negotiate the states.  In a further example, Brad described that when using cascaded BSCAN2 instances, how they were arranged depended on what BScan tools were to be used as they each approached the scenario differently.  Peter noted that tool vendors will inevitably adopt whatever is the easiest path to fit the solution into their existing software architecture. 
  • Brad noted that there were existing dependencies on state machine traversal, e.g for 1149.7 or for scan bridges.
  • What Brad was sensing from the discussion was that there was a leaning towards and open scheme rather that basing on any commercial solution.  Bill strongly agreed, noting this as an aim of all standards.  Brad then made a formal proposition "that the SJTAG standard should describe the structure and access behaviour for chain management control in a general manner and not for specific devices".  This was seconded by Bill, opening the proposal for discussion.
  • Bill asked if this was still predicated on 1149.1.  Brad answered that it was broader and could include I2C, for example; the wording was intended to allow that.  Bill clarified for himself that this meant describing the structure and protocol to access a particular function - a function being what Brad meant by "behaviour".
  • Tim mentioned chain management.  Brad highlighted that the key word here was "management" not "chain selection": It was not dealing with only an individual chain but a set of chains.
  • The group voted unanimously to accept Brad's proposal, although Eric noted that those not on the call should be given the opportunity to comment, so the vote is pending comment from those not in attendance.

6. Key Takeaway for today's meeting

  • An SJTAG standard should describe the structure and access behaviour for chain management control in a general manner and not for specific devices.

7. Glossary terms from this meeting

  • None.

8. Schedule next meeting

  • Next meeting February 16, Michele may be absent.
  • February schedule: 16, 23. Ian will be absent Feb. 23.

9. Any other business

  • The newsletter is due. Brad has had limited time this week.
  • Group officers needs to be addressed.

10. Review new action items

  • None.

11. Adjourn

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

Respectfully submitted,
Ian McIntosh