Minutes of Study Group Meeting, 2018-01-22

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_21.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:09)
Richard Pistor (Curtiss-Wright)
Naveen Srivastava (Nvidia)
Jon Stewart (Dell)
Brad Van Treuren (Nokia)
Carl Walker (Cisco Systems)
Ed Gong (Intel Corp.)
Dilipan Jayachandran (Schweitzer Engineering Laboratories, Inc.) (joined 11:11)
Russell Shannon (NAVAIR Lakehurst)
Sivakumar Vijayakumar (Keysight)

By email (non-attendees):
---

Excused:
Louis Ungar (ATE Solutions)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • January 15
    • Draft circulated 01/15/18
    • Action 17.1 should be marked as 'complete'. The email discussion on what to do with the outcome is a new activity.
    • It was pointed out that Soo Kim (IEEE-SA) had provided information that the Scope and Purpose in the standard no longer needed to be an exact match with what was written in the PAR (the "matching requirement") as stated at the previous meeting. The meaning and intent still needs to be the same in both documents but does not need to be a verbatim copy. This is new information and does not alter the record of last week's meeting.
    • Brad moved to approve with the amendment noted above, seconded by Terry, no objections or abstentions. Approved.

4. Review Open Action Items

  • {Slide 11}
  • [10.2] Brad will draft a definition for "boundary".
    • ONGOING.
  • [14.1] ALL: Develop Purpose description.
    • No recent activity. This is an open ended action and should be closed and replaced by a more specific task when necessary.
    • COMPLETE.

5. Discussion Topics

a) Work on refinement of what SJTAG is.

  • {Slide12 - headings}
  • {Slide 13 - Goals (1)}
  • The "Goal" stated here is from the public participation invitation when this study group was first formed.
  • {Slide 14 - Goals (2)}
  • These summary "Goals" are extracted from the presentation to TTSC when requesting sponsorship of the group. They perhaps read as very JTAG-centric although the third bullet attempts to address other interface options.
  • {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.

  • All of this is familiar to people from the "Initiative Group" - keen to hear the opinions of newer members.
  • Notable that a lot of time has been spent building in DFT features at component level, and only some, if any, at board level and even then they might be locked out by the time the board is delivered to you. What is needed is some sort of access method that gets you to component level features. In essence, this is what the Initiative Group envisioned under "co-ordination and co-operation of existing interfaces".
  • There could be benefits for the ASIC community at a functional level as there are ASICs with 8 or 16 SPI ports, which have arisen out of packaging cores with no thought to co-ordination and at the cost of pin count. It maybe simplifies the board test but makes the ASIC more complex.
  • Another possible area for consideration is standardisation of documentation. Sometimes it is necessary, even for the device vendor's own support people, to work through 1000's of pages of guides and handbooks to work out what is needed for a test.
  • 1687 has gained prominence in standardised testability at chip level but trying to extrapolate that to the board or combo-board level is more difficult - DFT guidelines could help here.
  • 1687 is not seen much in designs. The interface may be being used to control instruments but the complexity of managing it is so great that it can be difficult to use in embedded situations.
  • You can have a device that maybe needs 68 registers set up, perhaps by SPI and once set never need to be touched. You can create a canned function to do that, but real-time access becomes a real burden and there is no documentation on how to use it at the board or system level.
  • Is 1687 being used at the board level? Some EDA tools (e.g. Mentor) are building a workflow for it.
  • A presentation at ITC showed that 1687 was making great information available but it wasn't at all clear if any of this was being made available to the board. It is a potentially sticky point as it can make every part of the device accessible, which the vendor may not want, although there are ways to work with such issues.
  • One Use Case for new chips provides BIST using 1687 at the board level.
  • Some vendors are providing an interface and a corresponding library to access the interface thereby hiding the actual interface from the user. This also makes it easier to use although they are limited to the kinds of hosts that are supported by the library.
  • There could be some standardisation so that each vendor does not build their own solution - it could be through a similar type of language to describe the interface.  This has similarities to "BScan Plug and Play", using call-backs to declare how to use the interface or perhaps a BSDL-like description that may be more portable.
  • Brad and Michele had been discussing a way to define for a particular call-back how to take data from the top level and pass it down to the bottom level.
  • PDL level 0 can't do this; PDL level 1 might be able to, but it is not clear.
  • May want a guideline on being able to access different BIST capabilities. You can do this in 1687 but you have to diagram how you get down through the board, to the component then to the block inside the component. 
  • Michele and Brad were decomposing from the bottom-up as you can delegate up the chain without needing to know the hierarchy: "I need this data" which gets resolved at that level and then ripples up.
  • Bottom-up may not always be suitable as not every feature of every component is used in every design. Could query what is available and ripple up what's needed. Discovery from the system level and then only do what the system wants.
  • An example of a SERDES test: Need to know what to set up on the Rx side and what to set up on the Tx side; don't really need to know about the rest of the board topology.
  • PDL code can define what the functions are, so that will allow a SERDES transmitter to be set up, but there's not a standard interface across chips.
  • Rather than a standard interface, might it be better to have a means to find out what the custom interface is, alongside a few common interfaces?
  • Industry may evolve that out for us - We have been through a similar evolution for FPGA programming: Initially every vendor had their own methods but gradually the more common approaches used today came about. 
  • The first bit of the Need statement may be good but rather than leveraging the standards maybe it should really be leveraging the component capabilities to enhance the higher level test experience?
  • Part of the reasoning behind the existing wording to avoid the sponsor inferring that we were adding another new device level standard rather than re-using what already existed.
  • Off-line discussion can continue in the existing forum thread (noting that a better record of discussion is preserved by using the forums rather than email): http://forums.sjtag.org/viewtopic.php?f=3&t=740.

6. Today's Key Takeaways

  • {Slide 18}
  • We want to leverage capabilities as well as interfaces.
    • Potentially opens up needing to support proprietary interfaces? - Not necessarily.

7. Glossary Terms from This Meeting

  • Should add terms defined in 1687.1: Transformation, Retargetting.
    • Brad to supply Ian with the definitions {ACTION}.
  • Carried over:
    • Terms defined in IEEE 1856: Sense, Acquire, Analyze.
    • BIT - clarify in line with discussion from 2017-12-18 meeting.
    • BIST - distinct from BIT in that is a self-test that does not require any additional resources other than the tested item itself.

8. Topic for next meeting

  • Work on refinement of what SJTAG is.

9. Schedule next meeting

  • January 29.

10. Reminders

11. Any Other Business

  • None.

12. List New Action Items

  • [21.1] Supply Ian with glossary definitions used by 1687.1 for "transformation" and "retargetting".

13. Adjourn

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

Respectfully submitted,
Ian McIntosh