Minutes of Weekly Meeting, 2016-02-03

Meeting called to order: 11:09 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Brian Erickson
Brad Van Treuren
Heiko Ehrenberg
Adam Ley (joined 11:12)
Bill Eklow (joined 11:43)

By Proxy:
Michele Portolan

Tim Pender
Carl Walker

2. Review and approve previous minutes:

  • 01/27/2016 minutes (updated draft circulated 01/30/2016).
    • No further corrections noted.
    • Eric moved to approve, seconded by Brian, 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 (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.
  • All - Post thoughts on what things ought to be addressed by our initial PAR, either to the forum thread (http://forums.sjtag.org/viewtopic.php?f=3&t=740) or by email to the group. Ongoing.
  • Ian: Prepare bullet points from the PAR forum thread. 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
  • The Newsletter was due at the end of July. Brad probably has one topic left on his list.
  • Try to get Al Crouch on call re 1687.1 - Possibly no longer relevant?
  • {Adam joined}

5. Discussion Topics

a. Close in on PAR scope and purpose.

  • Ian had circulated the bullet points requested at the previous meeting and had copied these to the forum thread (http://forums.sjtag.org/viewtopic.php?f=3&t=740) {shared}.
  • Ian asked if there were any additions or removals required - none suggested.
  • Ian asked if these were any help in distilling the key elements or attributes for the PAR - no immediate response.
  • Adam noted that one of the bullets was unclear: "Consider, not necessarily in dot1, how to leverage one of the existing SJTAG dot standards as a means for the access link for another standard". Either the word 'existing' was superfluous or 'SJTAG' was supposed to be 'JTAG', since there were no existing SJTAG standards.
  • Brad, as author of the original comment, responded that it was hastily recorded but was meant to show that SJTAG standards, e.g for protocol bridges (where the JTAG interface is used to indirectly control, for example, I2C access to a device) should fit easily onto any prior SJTAG standard.
  • Brad agreed to reword the bullet: Email to Ian who will update the bullet list {ACTION}.
  • Ian noted that there were some themes in the list but there were points that weren't captured yet. In an email exchange with Michele related to the ETS/VTS material, it was pointed out that example board diagram did not really address SOCs or multi-board cases and that broad scope is something we've discussed recently. Michele was looking at how the diagram could be expanded.
  • Ian noted that the latter bullet points referred to "models" and was concerned that it might become confusing what sort of model we're referring to. Adam agreed that 'model" was a heavily overloaded term, but commented that sense was quite clear in those bullets. Brad commented that we are dealing with several 'models' and can't use the term loosely:
    • a software model
    • a hardware model
    • a system model
    • (Michele's list also includes 'execution model')
  • [Michele, by proxy] Indeed. It is my belief that the current execution model for JTAG, where sets of vectors are computed in ATPG and then pushed by a "dumb controller" is reaching its limit, and if we want to achieve the goals we are setting out for SJTAG we will need something new...
  • Adam suggested adding a bullet "Be sure to use 'model' in a way that does not lead to confusion". Brad added that showing context would help.
  • Ian referred to Michele's remark in the forum post preceding the bullet point list regarding PORT. Brad replied that we should avoid being limited to a TDR in the way that 1687 is; a set of bits in a scan chain.  The PORT abstraction gives flexibility in the target that the data is being sent to.
  • Ian wondered if that abstraction might be difficult to achieve. Brad agreed that working with abstracts is more difficult than working in concrete. 1149.1-2013 considers fixed length TDR but also has variable length TDR which is really a subset of the TDR.  There's also the idea of a 'virtual register" of mapped bits.
  • {Bill joined}
  • Ian was concerned that there may not be a common high level abstraction possible: Delivering a vector to a TDR requires much less than, say, sending data to I2C where an address needs to be sent, then the data, then check the acknowledge response.
  • Bill noted that there groups looking for more efficient protocols to push data through the boundary scan chains.  That area could be good opportunity for SJTAG.  Ian inferred that this meant some form of protocol conversion and that this would not be currently inherent. Bill added that there will be VTS presentation on this.  There is a need for higher bandwidth and it is almost mandatory with massive 1687 networks emerging.
  • [Michele, by proxy] I agree that we need this protocol abstraction, but I am not sure if the PORT abstraction is the right one, so I would not explicitly put in the PAR, as it is something that will need to be decided by the Working Group. For instance, from my work, I actually use two abstractions: a generic "register" where data can be read/written, and an "Access Interface" that defines the protocol to make this access. It works quite nice: I can define PDL routines one one or more registers, compose then on a complete chain and then obtain either the JTAG or I2C operations automatically.
  • Brad commented that he didn't feel you could control the speed of JTAG as it is often determined by board factors. Ian agreed with this. Brad noted that 1149.10 was and effort towards a high speed link, and both 1687 and 1149.1-2013 offer some speed boost by being able to shorten the chain length, but the clock speeds are a physics issue.  Ian noted that devices in the path. like gateways, could be the limiting factor for TCK.
  • Brad did note however that being able to use, e.g. parallel interfaces might be something that SJTAG could help with. Bill saw benefit in speeding up the interface to the network in some fashion.
  • [Michele, by proxy] I agree too, and this comes back to my previous comment: once you decouple the register from protocol this becomes easier. Has anyone any example of what one of these "parallel interfaces" might be?

6. Topic for next meeting

  • Close in on PAR scope and purpose (continued).

7. Key Takeaway for today's meeting

  • The term 'model' must be used in a suitable context to avoid potential confusion.

8. Glossary terms from this meeting

  • None.
    • 'Instance' (or a more specific version of the term) may require definition in future.

9. Schedule next meeting

  • Next meeting February 10, 2016, 11:00 AM EST.
    • Bill will be absent. Michele may be absent.
    • Brad's and Carl's attendances are dependent on other recurring commitments.
  • February schedule:
    • 17, 24.

10. Any other business

  • VTS: A potential problem with Michele presenting for us at VTS has been resolved.

11. Review new action items

  • Brad: Reword the bullet point "Consider, not necessarily in dot1, how to leverage one of the existing SJTAG dot standards as a means for the access link for another standard".

12. Adjourn

  • Eric moved to adjourn seconded by Brian. Meeting adjourned at 11:58 AM EST.

Respectfully submitted,
Ian McIntosh