Minutes of Study Group Meeting, 2018-02-12

Meeting called to order: 11:05 AM EST

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/StudyGroup/SG_Meeting_24.pdf

The "markup slide" created during the meeting is here: http://files.sjtag.org/StudyGroup/SG_Meeting_24_bgvt_SingleSlide.pdf

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Heiko Ehrenberg (Goepel Electronics)
Eric Cormack (DFT Solutions Ltd.)
Terry Duepner (National Instruments)
Bill Eklow (Retired)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.)
Bill Huynh (Marvell Inc.)
Joel Irby (ARM) (joined 11:13)
Naveen Srivastava (Nvidia)
Jon Stewart (Dell) (joined 11:13)
Brad Van Treuren (Nokia)
Carl Walker (Cisco Systems)
Russell Shannon (NAVAIR Lakehurst)
Louis Ungar (ATE Solutions)
Sivakumar Vijayakumar (Keysight)

By email (non-attendees):


2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • February 5
    • Draft circulated 02/05/18
    • Brad moved to approve, seconded by Eric, no objections or abstentions. Approved.

4. Review Open Action Items

  • {Slide 11}
  • [21.1] Brad: Supply Ian with glossary definitions used by 1687.1 for "transformation" and "retargeting".
    • ONGOING.

5. Discussion Topics

a) Work on refinement of what SJTAG is.

  • {Slide12 - headings}
  • Today's intent was to review and discuss the comments collected last week.
  • Recent forum postings summarised (from http://forums.sjtag.org/viewtopic.php?p=1261#p1261{shared by Brad}. Noted that registered users can "subscribe" to the thread to get email notifications each time a post is added.
  • Brad prepared a copy of the original Need slide for editing and collection of comments during the discussion {shared, see link at the top of these notes}.
  • The following is a brief summary of the points raised:
    • The recent discussions have raised lots or pertinent points but have not yet helped to formulate a Need statement.
    • Probably need to include some form of words that captures the posts from Heiko and Louis. Clarify the confusing text that was highlighted in colour. What else needs to change? What needs added? What can be removed? 
    • The current form of words talks a lot about "interfaces" while recent comments have been more on ideology - these are related but different. Shouldn't get too hung up on interfaces, so the whole grey text (the added examples) can probably be removed. Not all these "interfaces" are similar anyway - some are just hardware, others describe hardware and protocol.
    • The purpose of this section is to explain why there is a need for a new standard.
    • Would it be fair to say that this need arises because systems are generally no longer designed by one entity but bring in sub-systems from other suppliers? Possibly, but even within one organisation there are no guarantees that approaches will be similar across sub-systems. But industry is moving towards using COTS products where possible, so we should be looking to utilise the test features within the COTS items at the system level. We can judge how successful that is from the top-down.
    • There is no universally accepted tools for system test. How do you improve system test? You need better tools, but you can't have those unless there's a way for the tools to see the features that are available (arguing for top-down approach).
    • As  counter example, a 1687 application is going to be looking at an instrument buried deep inside a system, so the application is driven from the bottom. Top-down is difficult in that case. It's trying to improve system test by making use of what's there.
    • Leveraging the interface standards is not the only way to do this.
    • May need to split into two bodies, one, top-down,  addressing features sets and the second dealing with the application of lower level standards. There is risk that the two bodies produce orthogonal standards that can't be married up, but that can be mitigated by good communications between groups (as were are asked to do with 1687.1).
    • Some simulation tools exist for systems that talk of the interactions between sub-systems. In any case, a sub-system that has 1149.1 and/or 1687 will inevitably be more testable than sub-system that does not have these features.
    • One concern about bottom-up is that even just trying to bring 1149.1 up to the system level can have problems, e.g. chains getting too long.
    • In an ideal world, systems would be made entirely of COTS sub-systems that all meet these testability standards.
    • Example of a board with multiple instances of DSP + DDR, each instance looks identical so common embedded tests can be retargeted for each instance, allowing tests where no functional test would be possible.
    •  There are really two aspects here: The requirement to provide testability features needs to be driven/flowed down into the design, but then once the components are selected, the precise capabilities needs to be flowed back up so that test generation knows what can be used. Testing to the requirement doesn't mean you're getting the best coverage possible. Two different vendors of similar COTS products will have different implementations for similar functionality, so what and how you test them could be very different.
    • COTS vendors need a standard to look to know what to provide.
    • Top-down, SJTAG is an enabler of testability feature sets. 
    • Do we want health information or test data? One is loosely coupled the other is tightly coupled to the design. Possibly different offerings, different levels of compliance, e.g. level 3 gives access to the data, level 1 just the health information and level 2 somewhere in between. This probably a discussion of detail best left for a future working group.
    • Are we looking at a base level standard supported by sub-standards or trying to do this in one? Could be a 10-year task. If you do it starting with a base level supervisory standard then that needs to set out a framework that the other standards can plug into.
    • General health reporting could be another standard run in parallel.
    • The main problem with multiple standards (or even a large single standard) is manpower - we'd need to attract more resource to staff up multiple projects or else they'd need to be tackled in series. We probably need to scope what we do first for the resources we have and leave it open enough to expand that if more effort becomes available.
    • We could tackle the base but have a generalisation of interfaces so that people could do their own compliances within the vision and that might then be picked up by subsequent standardisations.
  • Brad will copy the marked up text to the forums for discussion through the course of the week.
  • Reference slides (not used during this meeting):
  • {Slides 13, 14 - Marked-up Need and comments from previous two meetings}
  • {Slide 15 - Draft Scope}
  • This is draft text as proposed by the "Initiative group" (as are the following two slides).
  • {Slide 16 - Draft Purpose}
  • Red text is highlighted as it is a constraint that we might want reconsider, or at least discuss.
  • {Slide 17 - Draft Need}
  • The wording of this has already been pointed out to be deficient as it stands. It is probably too long anyway - the latter part has been greyed as it is largely just an expansion of the main points.

6. Today's Key Takeaways

  • {Slide 18}
  • Requirements flow naturally goes top-down. Component BOM drives what is testable in the design (bottom-up). A hybrid approach is needed.

7. Glossary Terms from This Meeting

  • None.
  • Carried over:
    • "Interface" is missing.
      • No obvious IEEE accepted definition.
      • 1687 has definitions for specialised forms: Device Interface and Instrument Interface.
      • We may need specialised forms for Software Interface and Hardware Interface.
    • 1687.1: Transformation, Retargetting.
    • IEEE 1856: Sense - "Sensor" done, Acquire, Analyze not really defined.

8. Topic for next meeting

9. Schedule next meeting

  • February 19 - Tentative: Noted that this is "President's Day" in the US, so date is dependant upon a sufficient number of expected attendees.

10. Reminders

11. Any Other Business

  • None.

12. List New Action Items

  • None.

13. Adjourn

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

Respectfully submitted,
Ian McIntosh