Minutes of Weekly Meeting, 2016-02-10

Meeting called to order: 11:07 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Peter Horwood
Carl Walker
Tim Pender
Heiko Ehrenberg
Brian Erickson
Brad Van Treuren (joined 11:13)
Adam Ley (joined 11:27)

By Proxy:
Michele Portolan

Excused:
Bill Eklow

2. Review and approve previous minutes:

  • 02/03/2016 minutes (updated draft circulated 02/06/2016).
    • No further corrections noted.
    • Approval deferred until Brad joined the call.
    • Brad moved to approve, seconded by Eric, 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.
  • 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".

4. Reminders

  • {Brad joined}
  • 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.
    • Article preparation was largely falling to Brad who currently has little spare time for this. Ian wondered how useful the newsletter was compared to the effort required to produce it on a regular basis.  Ian said he would like to see the last of Brad's Green Papers produced, since it had been previously advertised, but after that felt the Newsletter might be better used only when we have something relevant to announce.
  • Try to get Al Crouch on call re 1687.1 - Possibly no longer relevant?
    • Ian suggested dropping this invitation as the presentation provided to the most recent TTSC meeting gave adequate information. Brad agreed noting that SJTAG was well represented on Al's list of interested parties.

5. Discussion Topics

a. Close in on PAR scope and purpose.

  • {Ian shared forum post of bullet points, http://forums.sjtag.org/viewtopic.php?p=1111#p1111}
  • Ian observed that much of recent discussion has been about abstraction, with Michele also having noted in an email discussion that we should be able to deal with SoCs as wells as boards and multi-board systems.  This had been echoed in notes that Brad had attached when supplying the updated bullet point text and Ian remarked that this seemed to be aligned with the notion of "assemblies of assemblies". 
  •  Brad asked Ian to share the diagram that he had sent Brad by email earlier in the week.
  • {Ian shared Network_Hierarchy.pptx, http://files.sjtag.org/IanMc/Network_Hierarchy.pptx}
  • Ian commented that this had been a very quick sketch to illustrate the idea that there may be a way to look at the hierarchy one layer at a time and iterate that as necessary, rather than trying understand the entire network that might exist. It would give a consistent view from whatever was chosen to be the "top level" for a particular perspective, but the diagram may be oversimplified.
  • Brad noted that the "Target" or "Target/Interface" here matched the dot5 concept of "PORT", and the "Network" was the PHY and above, while the interfaces were where the "middleware" sat with the top level interface being the "application".
  • {Adam joined}
  • Brad felt it demonstrated the hierarchical decomposition in an abstract way that did not specifically refer to finite elements like boards or SoCs.
  • Brad suggested there may be some missing boxes between "Interface" and "Network" to describe behaviour, similar to the role of PDL in 1687 and 1149.1-2013. The algorithms here may not be simply vectors but the logic of the functionality - it may be the code that runs the bridging operation.
  • There is a value add opportunity for the vendor to provide the IP for the bridge and the code to control that.
  • Brad observed that there can be both hardware interface and software interfaces.  Ian confessed that in preparing the diagram, he was probably thinking only about the hardware perspective.
  • Brad suggested that we may require sibling diagrams, showing both the hardware and software hierarchies as that was essentially our "model".
  • Ian asked if developing these diagrams would be an assistance in determining the PAR's scope.  Brad thought that was difficult to answer and suggested it would be better to do that after the PAR was in place, but said that the diagram shows that we can define the hierarchy in a standard and abstract way.  Brad felt Michele's email had maybe been looking at more finite elements, rather than the purely abstract.
  • Ian closed the topic to allow time to address AOB. Ian will make the diagram easily accessible {ACTION}.

6. Topic for next meeting

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

7. Key Takeaway for today's meeting

  • 'PORT' maps to 'Target'/'Interface' in Ian's Network_Hierarchy diagram.

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 17, 2016, 11:00 AM EST.
    • Michele will probably be absent.
    • Brad's and Carl's attendances are dependent on other recurring commitments.
  • February schedule:
    • 24.

10. Any other business

  • Michele had provided an email update on VTS and ETS preparation.
  • VTS Presentation:
    • So, here is a first proposal for the contents of the VTS presentation. I
      will draw the PPT as soon as I get the bandwidth

      1 -> Title
      2 -> Context: Illustrative SJTAG Infrastructure
      3 -> same as above, but showing a wider definition of "system" (Soc, 3D,
      etc...)
      4 -> problems of coexistence of standards
      5 -> System JTAG: presentation, scope (debug vs mass production),
      Inclusive VS prescriptive
      6 -> 3 bullet points from ITC poster (Access, Extend, Coordinate)
      7 -> work to date:
               -->understand the problem space
               -->identify the common denominator/elements
               -->find the missing links
      8 -> Possible SJTAG environment: "SJTAG visualisation" from ITC poster
      (bottom left corner)
      9 -->18 Tie to my "Manager for System Centric Test" as
               --> a  benchmark for SJTAG concepts
               --> show what can really be done
               --> real-world application

    • Ian noted that this is a roughly 50/50 split between SJTAG background material and Michele's engine material.
    • Brad and Eric wondered how far Michele would be able to take slide 5 as we do not yet have a defined scope for SJTAG. The main concern is for the "Inclusive vs prescriptive" aspect.  It may be more apparent once the slides are created.
  • VTS Abstract:
    • VTS asked me for a short abstract they can put in the program. What about:

      The world of test-related standards is living a big turmoil in recent
      times: the ever-growing complexity of chips required significant
      evolution in traditional approaches. This, coupled with the issue of
      Test Point Erosion, led to the definition of new standards for embedded
      testing, such as IEEE 1500 and IEEE 1687, the redefinition of classic
      JTAG into 1149.1-2013 or the new horizons opened by 3D chips and
      explored by activities like the IEEE P1838. Each of these standards
      addresses its own problem space, but a final system will most probably
      be composed of individual elements incorporating one or more of these
      often contradictory solutions. Is it really possible to efficiently test
      such an heterogeneous system?

    • Heiko had earlier corrected "this" to "these" in one place.
    • Eric asked if was correct to say "often contradictory solutions"?  Brad thought Michele may have meant "often competing solutions" - things don't always overlap.  Ian remarked on the slightly differing PDLs in 1687 and 1149.1-2013, although Brad commented that SPI and I2C were really competing interfaces, and suggested that maybe Michele need some wording that revealed that each option has its benefits and consequences for different applications.
  • ETS Workshop:
    • ETS has just approved a 1687-focused workshop proposed my Martin Keim
      (Mentor) to be held conjunction with the Symposium. The CfP has still to
      be issued, but it will probably be a better fit for SJTAG than ETS2....I
      am in the organizing committee, and I already proposed that some space
      should be given to the "contiguous standards". I will keep the group
      posted as soon as I have something more precise....
    • Ian considered this be simply for information and not something that required a response. However it does imply that there is an alternate track for us if there are no suitable "partners" for a session in the ETS2 track. 

11. Review new action items

  • Ian: Post the Network_Hierarchy diagram where it can be referenced.

12. Adjourn

  • Eric moved to adjourn seconded by Peter. Meeting adjourned at 11:55 AM EST.

Thanks to Heiko for additional notes.

Respectfully submitted,
Ian McIntosh