Minutes of Weekly Meeting, 2017-06-05

Meeting called to order: 11:06 AM EDT

1. Roll Call

Ian McIntosh
Carl Walker
Brian Erickson
Eric Cormack
Peter Horwood

By Proxy:
Brad Van Treuren
Michele Portolan

Excused:
Bill Eklow
Heiko Ehrenberg

2. Review and approve previous minutes:

  • Approval of May 22 minutes (draft circulated on 05/22/2017)
    • No corrections
    • Brian moved to approve, seconded by Eric. 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
  • Possible invitation for Al Crouch to talk about Parallel SIBs.
  • Python Netlists (SKIDL) suggested by Brad for discussion.

5. Discussion Topics

a. Building Blocks - Use Case of a simple Interconnect Test - Continued, Implications for tooling.

  • Due to the absence of both Brad and Heiko, Ian chose to defer this topic to a later date.

b. Python Netlists (SKIDL).

  • Brad had previously drawn Ian's attention to SKIDL (https://xesscorp.github.io/skidl/docs/_site/) a Python program for generating netlists. The potential attraction was that since it allowed a design to be described programmatically, it may offer a way to deal with dynamic changes to a system configuration (segments powered on/off, boards present/missing, etc.), by updating the netlist according to conditions. None of the others on the call were previously aware of this tool.
  • {Website shared}
  • Ian briefly summarised what SKIDL was aiming to do but noted that he had not himself looked too deeply into it at this point. Eric agreed that it seemed interesting, and Peter also felt it was worth spending some time to look into it, and noted that it appeared to do design rule checking and exported to KiCAD which was used at CERN. Peter would probably read more on it over the coming week.

c. TTSC Meeting.

  • Ian was aware that the next TTSC meeting must be approaching, and it was at this meeting that we had intended to request Study Group status, so we probably needed to think about what we might need to prepare. Ian felt we probably already had most things, the big question, as suggested by Heiko, might be why we think, after having been running for several years, that a Study Group would now get us any closer to a PAR. Eric commented that the formality of a Study Group may encourage participation from people who have previously held back due to our informality. Eric added that most other WGs, such as 1838, all went through the Study Group phase to build up membership. We also have a good idea of what SJTAG is going to be now.
  • [Brad, by email] We also need to realize that now there are other standards coming like 1687.1, or new standards like 1687, 1149.1-2013, or 1149.10 that target a particular niche, but all these fail to provide the tooling and structure necessary to support board or system level aspects that make them useful for the board and system level testing domains.  Most are leveraging them only at the chip level test via ATE chip testers.  SJTAG needs to educate the community about the missing link required to be defined to make these standards more useful for the board and system test domain.  This is what the iNEMI BA-Test activity was trying to define with the description templates developed that were found to be missing from the current tooling and modeling infrastructures existent and used to day.
  • On that last point, Ian remarked that if, as is hoped, we gained new members then we'd need to "recalibrate" our Scope and Purpose to ensure that the view we had developed indeed reflected the expectations of those outside our small group. Ian observed that from what he'd seen of the 1687.1 activity during their Study Group phase, the time was mostly spent building/consolidating the content of their PAR. Eric agreed 1838's Study Group had been very similar.
  • A formal status should help in getting others on-board although Eric felt that we may need to have some presence at one or more of the key test conferences: Eric didn't mean a poster but something more substantial like a full paper presentation or a 1/2 day workshop where we can re-introduce ourselves and get some discussion and feedback. Ian agreed that we had perhaps been around long enough to have become "noise in the background". Ian added that one of the problems at places like ITC was competing with other subjects for attention. It may be that a presentation within the main "stream" is needed, followed up by a later workshop. Fringe meetings at ITC had tended not to attract too many "outsiders".  Eric commented that 1838 had started with presentations, then workshops and also had fringe meetings.
  • Ian wondered if there was as much interest in the subject as there once was, or whether it was just that the "old guard" that recognised/understood the problems were all disappearing - Ian commented that of the "14 board test professionals" that founded SJTAG back in 2005, many had now retired. Maybe newer test engineers just "did something else instead", Peter commenting that it was likely following "the path of least resistance".
  • Eric noted that tools vendors maybe weren't pushing SJTAG, but accepted that some of those on the group might not agree. Ian remarked that JTAG tool vendors were quite possibly going to be "followers" rather than "leaders" on something like this, and referred to a discussion he'd had with Peter Van Einden around 2008 when Peter had said that JTAG Technologies were ready to implement SJTAG as soon as there was a standard to follow.  As for EDA tool vendors, their focus seems to be solely on chip level DFT.
  • Eric asked if recent discussion were perhaps drifting away from our PAR goal, as we hadn't mentioned it in some time. Ian replied that this was largely deliberate and we've been "treading water" with hopefully useful discussions, pending the Study Group. As mentioned earlier, new membership may influence Scope and Purpose. Eric accepted that and agreed that the language discussion was useful and noted that a similar language question had arisen in 1838 which has caused them to stall. Ian observed that descriptive languages seemed to be a common problem: 1687 had created PDL and ICL to address their problems and 1149.1-2013 invoked a slightly different PDL. Ian had never had to use either so didn't really understand the nuances or capabilities, but felt there may end up with even more dialects and confusion in due course. Eric commented that 1838 are considering extensions to ICL. Peter added that Python is becoming more popular (neatly coming full circle back to the earlier SKIDL discussion) and is also taught more widely than the TCL on which PDL is based, so people come out of college already conversant with Python.
  • [Brad, by email] My brother (Dean of the College of Mechanical Engineering at Baylor University) has informed me that Python is the language taught to engineering students in Baylor because it is simple, intuitive, and adaptable to new opportunities easier than C, C++, Java or Tcl.  LabView is also taught as a main controller language for testing.
  • [Michele, by email] It is true that education-wise Python is gaining a lot of traction: it is also the official language for Computer Science classes in High School and Prep School in France. So, future generations will probably be more familiar with it than with C.  But most of the current target audience in test comes from a HW background, so CS concepts (and even worse, Object Oriented) are difficult for them...
  • Peter had been looking into SKIDL during the call and observed that it seemed to export KiCAD netlists but that seemed to be all. There didn't appear to be any way to "store" a design block to reuse, it all had to be created from scratch each time, e.g. a PCB-A in slot 1 and slot 2. It was basically a netlist generator and Peter felt there were other tools that could do that. Ian replied that since it was an open source Python tool, it could be extended to meet requirements, or at the very least, it could be used to help identify/clarify what our requirements are.
  • Peter commented that the multi-board question was really just netlist merging. Ian noted that the problem with that was usually getting net names or pin IDs to correlate between the plug-in and the motherboard. 

6. Topic for next meeting

  • Position for TTSC meeting.
  • Building Blocks - Use Case of a simple Interconnect Test - continuation.
    • Translating AccessLink specification.

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 June 12.
  • June schedule:
    • 19, 26.

10. Any other business

  • Ian hopes Michele will be able to provide a fuller report on the TESTA tutorial in due course.

11. Review new action items

  • None.

12. Adjourn

  • Peter moved to adjourn, seconded by Brian.
  • Meeting adjourned at 11:56 AM EDT

Respectfully submitted,
Ian McIntosh