P2654 WG Minutes - 2021-12-06

Minutes of P2654 Working Group Meeting No.134, 2021-12-06

 Meeting called to order:  11:04 AM EST

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

The cumulative reference pack is located here: http://files.sjtag.org/P2654WG/P2654_Reference_Pack.pptx (updated Dec 31, 2020)

iMeetCentral site: https://ieee-sa.imeetcentral.com/sjtag-sg/ 

1. Roll Call

Ian McIntosh (Leonardo) (chair)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd) (joined 11:26)
Joel Irby (AMD)
Richard Pistor (Curtiss-Wright)
Jon Stewart (Dell) (joined 11:14)
Louis Ungar (A.T.E. Solutions) (joined 11:08)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco)

Guests:
---

Excused:
Bill Huynh (Marvell Inc.)
Tom Thompson (for IEEE)

2. Agenda

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

3. IEEE Patent Slides

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

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #133, November 29 (draft circulated November 29)
    • No corrections noted.
    • Brad moved to approve, seconded by Terry, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • P1687: Reminded that PDL-0 was originally intended to be an API. Suggestion on propagation to support Transfer Procedures.

7. Discussion Topics

7 a) Continue Review of Standard Draft

  • {Slide 14}
  • Louis raised a question on whether P2654 would provide anything to help with detection of counterfeit products.
  • May be possible to some extent, but isn't something that is expressly considered.
  • Where a part, generally a digital part, contains some characteristic or value that can be read to determine its authenticity then P2654 should support that.  An example might be the ECID (electronic chip identification), accessed by the ECIDCODE instruction in 1149.1-2013, which can include an encrypted data field that can be used to verify that the device is genuine.
  • Validation may not be immediate - it might require the retrieved data to be sent to the device manufacturer for verification as the means to verify may be kept private.
  • An example of capacitors that failed at much lower voltage than they were supposed to be rated was cited - it is unlikely that P2654 would be able to offer anything here.
  • Noted that the issue of detecting counterfeit parts has a lot of similarities with the question of managing "security" (IP protection, authorised use, etc.).
  • P2654 can't really mandate that features are provided by device manufacturers, but can help allow applications to make use of them when the features exist.  Any description of these types of activities would need to be informative rather than normative.
  • Do we explain enough about who our target audience is?  Would someone interested in counterfeit detection recognise that P2654 might offer something?  The only mention of who would be interested in the standard is in 5.6, "Stakeholders of the Standard", in the PAR.  Possibly this could be expanded and brought into the introductory sections of the Standard. 
  • Document was not updated and latest version remains IEEESTD-P2654_Draft_D01_BGVT_20211115.docm.

8. Any Other Business

  • {Slide 15}
  • None.

9. Glossary: 

  • None.
  • Carried over:
    • Network will need to be defined
    • PTPG - Programmable Test Pattern Generator/Generation
    • Better define structural test boundary vs functional test
    • Transfer module/library
    • Injection transfer module/library
    • RVF Message (to be refined)
    • RVF Command (to be refined)
    • "Tooling" - need to be clear on what is meant.
    • "True System".
    • Comment that "End-User" is subject to perspective and so needs to be qualified.
    • ModelPoint.
    • System Element.
    • System Resource.
    • 'System' needs the concept of a controller capability added.
    • "Filtering" may need to be defined.
    • "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.

10. Takeaways:

  • Should include an example Use Case illustrating a "security" application. 

11. Schedule next meeting

  • December 13, 2021
    • Dec 13 will be the last meeting for this year.
    • Joel expects to be out.

12. Topic for next meeting

  • Continue review of standard draft
    • IEEESTD-P2654_Draft_D01_BGVT_20211115.docm
    • Continue with clause 4.3.

13. Reminders

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh