Minutes of Weekly Meeting, 2017-01-11

Meeting called to order: 11:07 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Carl Walker
Brad Van Treuren
Peter Horwood
Heiko Ehrenberg
Bill Eklow (joined 11:09)
Adam Ley (joined 11:10)

By Proxy:

Brian Erickson

2. Review and approve previous minutes:

  • Approval of December 14 minutes (draft circulated on 12/21/2016)
    • No further corrections noted.
    • Eric moved to approve as amended, 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.

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

b. PAR text feedback
- Newsletter/LinkedIn post

  • Ian chose to deal with this item first.
  • The newsletter had 11 confirmed views - there may have been more but tracking blocks will limit what gets reported.
  • The LinkedIn post had 83 views, although many of these will overlap with Newsletter recipients.
  • Only one feedback comment, from Al Crouch, noting that this was pretty much what he expected as the "system/board level glue" and something that was currently missing from the family of standards. Conclusion must be that there is no reason to amend our texts at this stage.

a. Enumerate our requirements
- What are we trying to implement?
- Review previous Key Takeaways for relevant ideas - continue from row 77

  • The intent was to continue with the breakdown of the Key Takeaways.
  • {Brad shared the Key Takeaways and the Requirements worksheets}
  • Row 77 contained three takeaways: The first related to aspects that were once only system level now appearing at board and chip level, with power management being an example that may need to be covered in the overall model. Brad remarked that this was once only a dynamic at the system level but we are now seeing it at lower levels. Brad asked if there were other dynamics that we are not considering, although Ian felt that was like asking what we don't know. Brad suggested we may need to step back and re-analyse on this.
  • Brad asked if SJTAG was going to support hot swap configurations, or if that was an extension. Ian felt it was an extension and that, for simplicity in the first case, SJTAG should concentrate on a static configuration, i.e. where the overall topology does not change over time (Ian wasn't happy with this definition as networks could change within a single board - he was more concerned about not changing boards in a system).
  • Bill suggested that we might need a clearer definition of what "a system" is. Brad noted that it depended on perspective - one person's system is another person's sub-system - and that was why we came up the notion of "assemblies" that could apply at any level. Bill felt we could declare our own definition, e.g. that "system" related to "chassis". Brad preferred an abstract definition that didn't need to consider any specific level. Ian could see that Bill's idea may be more accessible to the broader audience, and you could still allow people to extrapolate the ideas to other levels. Brad was inclined to argue that these may be examples in appendices, to show how to apply the abstract model to particular use cases.
  • Bill countered that the chassis level was more significant because, e.g. 1687 could be used at board level as well as chip level, although it was challenging. Brad disagreed, as while it was technically possible to use 1687 at board level, it wasn't strictly within its scope: ICL and PDL were specifically for the chip level and the board level solutions were more of a stretch of "PDL Level 1" and outside its scope.
  • Adam asked to confirm that Brad was proposing to define a system in an abstract way with and appendix of use cases of different realisations at different levels. Brad agreed that was correct. Adam was in favour of this and noted that since any system is a collection of building blocks, then the building blocks become most important.  Brad suggested that the building block were effectively being deferred to existing standards where possible.
  • Brad asked if there was a "flip side" that argued against the abstract definition. Bill commented that concentrating on the chassis avoided apparent overlap with existing standards. Ian suggested that using the chassis level as the "reference view" for most examples might satisfy that. Brad felt that people working top-down will probably see the chassis as their system, but chip level people are likely to work bottom-up.
  • Brad mentioned the primitives that we'd talked about previously as being the bottom building blocks; we need to understand how they interact with each other - might be a TDR or a gateway interface.
  • Bill noted from experience that the simpler the premise of a standard then the quicker you can get from a PAR to the standard. On that, Brad return to the "static configuration" and Ian stated that he felt a better way to describe that might be that "the netlist set is unchanging". Card swaps (and e.g. Brad's Plug'n'Play example) should be a dot extention, however power management is an integral feature of so many board designs now that it probably needs to be addressed.
  • The second takeaway related to delineating between control paths and data paths - this had already been covered in discussing AccessLinks and DataLinks.
  • The third item, on management of dependent instruments and resources had no clear answer, so it was simply noted that it needed to be managed.
  • Row 79 referred to material from Gunnar on Test Controllers and Test Managers. The Test Manager could reside in-system or be remote. This probably meant that where the protocol was sent from determined what was the Test Manager - there was no fixed locality. Test Manager features can be moved into the target to allow delegation, something Gunnar used extensively.

  • The updated version of Brad's Requirement Excel file is available here: http://files.sjtag.org/Brad/SJTAG%20Requirement%20List%2020170111.xlsx.

6. Topic for next meeting

  • What are our next steps?
    • Bill asked if we intended to go to Study Group. Ian said that he understood that was the intention. Bill suggested that in presenting the case for a study group, we should describe the environment and the opportunities for improvement, show that this is an area that needs some work for a standard. Brad thought that may have been what Ben had been aiming for in creating the group in 2005.
    • Adam noted that a Study Group normally has a 6-month lifespan at the end of which it concludes that the group is disbanded as there no interest it a standard at that time or it offers a PAR. Adam saw no reason why we did not have a case to present to the TTSC to see if there was support for a study group, but commented that there may be some resistance to creating one and it would be wise to  coordinate with the chair, Adam Cron, to get on the agenda and to get his insight on the materials that we should bring.
    • There is a TTSC meeting next week (conflicting with ours), and thereafter roughly quarterly. Adam (Ley) offered to assist in making contact with Adam (Cron).

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.
    • 'Priority' - may relate to 'frequency' and 'urgency' in distinct definitions.

9. Schedule next meeting

  • Next meeting January 18, 2017.
    • Adam Bill and Heiko will all be absent due to the TTSC meeting.
  • January schedule:
    • 25.

10. Any other business

  • Ian hopes Michele will be able to provide a fuller report on the TESTA tutorial in due course.
  • Ian has some material from Al Crouch on his proposal for "parallel SIBs". We may want to include him in one of our future calls to talk about this.

11. Review new action items

  • None.

12. Adjourn

  • Eric moved to adjourn, seconded by Bill.
  • Meeting adjourned at 12:14 PM EST

Respectfully submitted,
Ian McIntosh