Minutes of Weekly Meeting, 2016-08-17

Meeting called to order: 11:08 AM EDT

1. Roll Call

Ian McIntosh
Eric Cormack
Adam Ley
Brad Van Treuren
Heiko Ehrenberg (joined 11:17)
Bill Eklow (joined 11:17)

By Proxy:

Carl Walker

2. Review and approve previous minutes:

  • Approval of August 03 minutes (draft circulated 08/07/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: Review revised PAR Scope and indicate acceptance or otherwise by email to Ian as soon as possible. The current text can be found in the Meeting Minutes - 2016-07-27 or on the forums: http://forums.sjtag.org/viewtopic.php?p=1158#p1158.
    • Only a few responses (all positive) received. Ian is inclined to take the absence of a response as tacit approval. COMPLETE.
  • All: Propose additions to the bullet list of Aims for the PAR Purpose. Comments to be posted to the forums (http://forums.sjtag.org/viewtopic.php?p=1167#p1167).
    • One forum post by Ian. 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 2015.

5. Discussion Topics

a. Continue PAR discussion
- Refine "Purpose" from the assembled bullet points

  • Brad displayed the "Purpose" slides from the previous meeting.
  • {Brad shared Slides 28 and 29}
  • Ian noted his forum post, asking if we should explain how we see the standard being used, but wasn't sure how relevant it was to "Purpose". {Brad shared forum post http://forums.sjtag.org/viewtopic.php?p=1170#p1170}. Brad was interested in what Ian meant by "a set of templates from which you "roll your own solution"".  Ian explained that we weren't giving a complete solution, only methods or techniques that could be employed by a tool vendor to provide their own particular solution. 
  • {Heiko and Bill joined}
  • Brad saw "template" as being more related to some generic form and referenced some recent 1687.1 emails in which Reinhard Meier referred to a "generic interface".  Brad felt that what we were talking about was abstraction rather than a generic.  Generic describes more of the structure of an interface (definition of an API parameters) whereas Abstraction describes more of the behavioral aspect of the interface.  Abstraction lets you begin common behavior using techniques like "duck typing" that is used by Python and even VISA.  For example, in VISA a time reference and a DVM could produce results that looked like an oscilloscope to the user, who didn't need to know how the results were obtained
  • Brad accepted that Ian's question pointed out that we may not have identified all the expectations of our "customers" - the end user and tool vendors.  Ian agreed that there had been a change from the initial notion of a standard to help the end user directly to something that helped the tool vendors, so the end user benefit was indirect.  Eric felt that examples would provide hints or suggestions towards the hardware aspects and there was a lot of material in our wiki, etc.  Ian agreed but felt that many people reading the PAR won't have seen all the other material we've developed.
  • Ian noted that trying explain how our proposals would benefit the end user is not something that could easily be done in a few words. Bill agreed that a small number of words was needed for the PAR which should be a very terse abstract of what we intend to do, and suggested that we should also have a very succinct definition of "a system". There is a definition in the wiki (http://wiki.sjtag.org/index.php?title=Glossary#S) describing "an aggregate of circuit boards" which Ian felt ought to be "an aggregate of circuits", however Bill suggested it would be better to focus on PCBs in a one sentence description for the PAR as he knew of no other standard that has that definition. Ian was happy with that so long as it didn't preclude people from deriving other interpretations.
  • Bill also noted that the aggregation may have varying protocols. Ian recalled that we had addressed this point but it was in the "Need" section that we were yet to trim down.
  • Brad commented that we seem to be portraying SJTAG as an abstract test interface.  1149.5 was also a test interface, but it required all transactions to be made using a single new hardware interface; not abstract. We are backing off from a specific hardware interface to a software only abstraction.  That may be more acceptable to industry.
  • Bill remarked that the work Michele had been doing presented a good foundation for what SJTAG is doing. Brad added that Michele's work was a SJTAG Proof of Concept, emphasizing that it was 'a' Proof of Concept not 'the' Proof of Concept.
  • Brad felt there was also an economic perspective: For many of the other standards there was no real incentive to go out and implement them. Many tool vendors have tried to embrace 1687 but aren't really finding any drive to adoption and the same applied to 1149.7 despite its advantages and even 1149.1-2013. Ian agreed and suggested that these may find niche uses in ASICs but weren't really flowing into commercial devices that he was seeing.  Even 1149.6 wasn't widespread. Bill commented that it probably took two or three years before 1149.6 started to take off, Brad adding that even then it was clumsy to use.
  • Brad also noted that 1149.1 based protocols are too slow for a lot of instrumentation applications. SPI and I2C can be faster but looking at I2C, the address space is limited. 1687 may not be that bad but does get push back because of the complexity. Bill agreed that Cisco had found it complex but were beginning to get a handle on it.
  • Brad observed that we're showing there are other directions than the retargetter for embedded applications.  Bill noted that 1687 was driven by the hardware, so being software based could get a lot of interest as you don't have to look at new versions of chips. Brad agreed. He said that this made it significantly different from the problems 1687.1 and 1149.10 are debating as they are hardware standards tackling different problem domains - we are trying to create a software abstraction to the existing hardware standards.
  • Ian considered how to progress from the bullet list to a form of text for the PAR and wondered about ranking the bullet points for importance. Bill proposed that rather than that, it would be better to go to higher level or more abstract form of words. Detail should be avoided as people will tend to probe at small details.
  • {Bill raised the topic of BTW - the discussion has been noted under AOB}
  • Brad will post the new slide additions to the forums (posted to http://forums.sjtag.org/viewtopic.php?p=1171#p1171).
  • Added to Slide 28:
    • PURPOSE:
      • Seamless Access
        • how industry may exploit it?
  • Added to Slide 29:
    • PURPOSE:
      • Problem Domain (what we are trying to do)
        • Aggregation of circuit boards (w/ varying protocols e.g., 1149.x, 1687, I2C, USB, SPI)
        • Trying to create a software abstraction to the existing hardware standards
  • The revised slide pack has been added to the file manager: http://files.sjtag.org/Brad/SCOPE%20DRAFT20160817.pptx.

6. Topic for next meeting

  • Continue PAR discussion
    • Refine "Purpose" (higher level or more abstract) from the assembled bullet points.

7. Key Takeaway for today's meeting

  • None.

8. Glossary terms from this meeting

  • Need a refined definition of "system" for the purposes of the PAR.
  • 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'

9. Schedule next meeting

  • Next meeting August 24. Heiko, Adam and Bill will be absent due to TTSC call at the same time.
  • August schedule:
    • 31.

10. Any other business

  • Bill had been asked about getting something together on SJTAG for BTW, but wasn't sure who would be attending. Heiko said he was but maybe wasn't the best person to talk about SJTAG. Bill suggested that maybe BTW could interrupt the SJTAG call so we could give an overview of what SJTAG is doing, and maybe make a pitch that we're submitting a PAR and perhaps get a few more interested people. The 9:00-5:00 timing means that the start of the session is aligned with the SJTAG call - by the time they get settled it may be 9:15.  Ian was happy to support this as he was unable to travel to BTW and Brad agreed that it was the only way he could take part.  
  • 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

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

Respectfully submitted,
Ian McIntosh