Minutes of Weekly Meeting, 2016-01-20

Meeting called to order: 11:09 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Adam Ley
Tim Pender
Peter Horwood
Brad Van Treuren (joined 11:17)

By Proxy:

Heiko Ehrenberg
Michele Portolan
Carl Walker

2. Review and approve previous minutes:

  • 01/13/2016 minutes (draft circulated 01/16/2016).
    • No corrections noted.
    • Insufficient attendees to vote on approval.

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 - For ETS2, propose possible example SJTAG applications with associated problems that are commonly encountered. COMPLETE.
  • 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.

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?

5. Discussion Topics

a. ETS2.

  • In Carl's absence, Ian was unable to share the forum post with the draft abstract and follow-up remarks, so Adam provided the link in WebEx Chat (http://forums.sjtag.org/viewtopic.php?f=3&t=744).
  • Eric asked about adding slides into the introduction with the types of Use Case information that Hieko had suggested. Ian noted that the priority for now was the abstract, but certainly that could be part of the presentation material.
  • Brad noted that in addition to the points raised by Michele, there was the case where boards could be reused in a different system, with no consideration of the original test philosophy. Ian added that in the case of COTS boards, they were designed for no particular system at all. Brad agreed that was the same domain.
  • Adam remarked that in a custom system with custom boards then you have control over the testing that is possible. With a COTS board you "get what you get", which Ian noted can often be nothing as regards test.
  • Brad remarked that he had seen COTS boards integrated to a custom backplane via a translator.
  • Adam commented that we would want COTS boards to make some form of provision for system test. Brad felt this was actually two things: Some level of board self-test and something that tests the interconnects into the rest of the system. The latter often doesn't exist even for custom boards. 
  • Ian reported that Michele had been in touch with the ETS organisers and the format was a 90 minute slot with three or four presenters on related topics in the session, with about 50% of the time set aside for discussion. This means around 10-15 minutes of presentation time.
  • Need to set time aside in next week's call to get a draft abstract put together. Ian will try to prepare a very rough draft as something talk round next week.
  • Brad asked if we really needed to expand the existing paragraphs in the draft. Adam felt 100 to 150 words was probably typical, 200 maximum, and that the original draft was perfectly good.
  • Adam considered that the ETS organisers may be open to "coaching" with respect to abstracts, and that we should circulate the existing draft and see if they feel it needs expansion. Brad agreed with this approach. Ian will speak with Michele and ask him to do this since he has already made contact with the organisers.

b. Close in on PAR scope and purpose.

  • There had been some additional postings to the forum thread. Adam supplied the link to the forum posts (http://forums.sjtag.org/viewtopic.php?f=3&t=740).
  • Brad had made a post looking at 1149.5 and commented that what he hoped to do was find what it did right and leverage what we can from that to help partition out the dot references for our standard(s).
  • Considering 'architecture' (rather than signal levels, etc.) Brad went to Fig 1.5: This shows a 'Physical Layer' which in 1149.5 was specifically the MTM Bus, but there are other buses in the system (e.g. IPMI in ATCA does a similar job) and SJTAG should be able to live on top of any of these.  The embodiment of the physical layer can be covered in dot releases. The Link Layer in Fig 1.5 is equivalent to our Access Link, but the Message Layer is maybe too broad for our use.
  • A key point for Brad was the notion of a Port, which could be a register or an interface to an application. This abstract view of a port was heading in the right direction but 1149.5 then got too involved with the detail of the hardware. It defined a port protocol so it was no longer abstract. We need to come up with a good representation of a port in our model.
  • Ian felt it was important that we stop once we identify that something looks like it's going in the right direction, so we don't get bogged down in detail.
  • Brad asked if wanted a distributed model (like Ethernet and most networking) or a single centralised model that is aware of all the connectivity. Ian felt that existing JTAG tooling largely assumed the centralised model. Brad noted that a distributed model would probably need some intelligence in the end points, and that may be too big an assumption. Ian thought that perhaps made the decision for us as there would be reluctance in many cases to adding resources that are only used for test.
  • Brad thought we needed to represent a port that could be reused across multiple physical layers. Each dot standard would then reflect back to the original model. We'd need to glean from each of the ports what would need to be included to be SJTAG compliant. Brad could see the number of data bits being part of that but things like input/output of each cell is already available in the BSDL. But for SPI (for example) there's no BSDL and there's need to be another source for the data.

6. Topic for next meeting

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

7. Key Takeaway for today's meeting

  • None.

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 January 27, 2016, 11:00 AM EST.
    • Brad's attendance is dependent on other commitments.
  • February schedule:
    • 3, 10, 17, 24.

10. Any other business

  • None.

11. Review new action items

  • No new actions: The PAR forum thread action is continued.

12. Adjourn

  • Eric moved to adjourn seconded by Peter. Meeting adjourned at 12:00 noon EST.

Respectfully submitted,
Ian McIntosh