Minutes of P2654 Working Group Meeting No.62, 2020-04-20

Meeting called to order: 11:12 AM EDT

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

1. Roll Call

Ian McIntosh (Leonardo)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Bill Huynh (Marvell Inc.)
Joel Irby (AMD)
Richard Pistor (Curtiss-Wright)
Jan Schat (NXP Semiconductors)
Jon Stewart (Dell)
Louis Ungar (A.T.E. Solutions)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)


By email (non-attendees):

Eric Cormack (DFT Solutions)

2. Agenda

  • Terry moved to accept the agenda, seconded by Brad, no objections.

3. IEEE Patent Slides

  • {Slides 5-10}
  • Patent and Copyright slides reviewed.

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #61, April 6 (draft circulated April 6)
    • No corrections.
    • Terry moved to approve, Brad seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • Feedback from P1687.1, dealt with under 7b.

7. Discussion Topics

7 a) Recreating tests outside of the end-use hierarchy

  • {Slide 14}
  • Is this something that is a value add from a tool vendor? Or is there a value add from the device vendor?
  • Not so much a test as a stimulus to a sub-assembly.
  • Vectors will go through a large number of transformations before being applied. To definitively debug problems you need to know what is applied and returned at the end device.
  • Could be considered as isolating tests at the sub-assembly level rather than recreating the tests.
  • Need a capability to capture the actual data in the system (including responses). This may imply a requirement to store data: The system model will only be able to show you what may be expected, not necessarily what is actually present in the hardware.
  • Security concerns may mean that you don't get access to the applied data. It could be handled indirectly, e.g. by indexing to some (hidden) internal vector: The user won't know what is applied but the device vendor will know by the indexes used.
  • Plug and play scheme: Plug-in board carries its own tests. Host knows enough to initiate those tests  and understand when they fail but doesn't need software changes if a different plug-in (with different tests) comes along.
  • Not sure if this is part of the core standard or something "nice to have". However, there's a frequent need to dig down into what's happening at lower level for debugging.
  • Have we determined whether the standard is aimed at new design going forward or should it be usable on existing designs?
  • Further notes are included in the pack for today's meeting {slides 35-37}.
  • Clarifying what the purpose of the Use Cases was and how they would be used for the benefit of the standard 

7 b) Continue outline of the draft

  • Brad presented two slides with feedback from the P1687.1 group (http://files.sjtag.org/P2654WG/Meeting_60_P1687.1_feedback.pdf).
  • "Lossy" probably isn't the correct term for what we were describing, "filtering" may be more accurate.
  • The filtering will impede diagnostics.
  • Filtering may be part of a process: Go/NoGo first then progressively query down. 
  • Filtering may be necessary to keep the volume of data at the top level relatively low.
  • P1687.1 expects lossless and filter-free data transfers.
  • What is the effect of compression? Do you need to know the compression algorithm? In many cases "it's just data" and the compressed (or encrypted) nature s irrelevant, in other cases it mean that some processing may need to be done offline.
  • Bullet points recorded during the earlier meetings are now moved to a separate reference file: http://files.sjtag.org/P2654WG/P2654_Reference_Pack.pptx.
  • Forum thread for comments on the outline: http://forums.sjtag.org/viewtopic.php?f=3&p=1444#p1444.

8. Any Other Business

  • {Slide 15}
  • AutoTestCon is cancelled.

9. Today's Key Takeaways

  • None.

10. Glossary Terms from This Meeting

  • "Filtering" may need to be defined.
  • Carried over:
    • Translation may need to be defined.
    • "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.
      • "Interface" is overloaded and requires disambiguation.
    • 1687.1: Transformation.
    • IEEE 1856: Sense - "Sensor" done, Acquire, Analyze not really defined.
    • Device - do we mean a packaged device? May be many devices in a package. "Device" is often used as a modifier, e.g. "device package", "device identification".
    • Use Case Context, Application Context
    • Legacy Infrastructure, SJTAG Infrastructure (placeholders for now, really for working group to define).
    • "Generators": May need to be qualified as "Test Generators" (used by the integrator/tester) and "Model Generators" (used by IP providers, interface designers, etc.).
    • AccessLink and DataLink descriptions will need to be revised.
    • See P1687.1's definitions on Slide 31 of the pack presented by Jeff Rearick on Jan 14, 2019.
    • "State", "Vector", "Sequence" and "Pattern" as proposed at April 8, 2019 meeting.
    • "Event", "Access Interface" as proposed at April 15, 2019 meeting.
    • 'Port' needs to be developed.

11. Schedule next meeting

  • April 27, 2020.

12. Topic for next meeting

  • a) Continue developing outline of standard
  • b) Close in on definition of 'System'

13. Reminders

  • None.

14. List New Action Items

  • None.

15. Adjourn

  • Joel moved to adjourn, seconded by Terry.
  • Meeting adjourned at 12:07 PM EDT

Respectfully submitted,
Ian McIntosh