P2654 WG Minutes - 2022-11-14

Minutes of P2654 Working Group Meeting No.169, 2022-11-14

Meeting called to order:  11:02 AM EST

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

Reference pack 1 is located here: http://files.sjtag.org/P2654WG/P2654_Reference_Pack.pptx (all 2020 material)
Reference pack 2 is located here: http://files.sjtag.org/P2654WG/P2654_Reference_Pack_2.pptx (all 2021 material)

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

1. Roll Call

Ian McIntosh (Leonardo) (chair)
Eric Cormack (DFT Solutions)
Brian Erickson (JTAG Technologies)
Joel Irby (Self) (joined 11:09)
Richard Pistor (Curtiss-Wright) (joined 11:07)
Louis Ungar (A.T.E. Solutions)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)

Guests:
---

Excused:
Heiko Ehrenberg (GOEPEL Electronics)
Tom Thompson (for IEEE)

2. Agenda

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

3. IEEE Slides

  • {Slides 5-13}
  • Patent, Copyright and Behavior slides reviewed without comment.

4. Review and Approve Previous Minutes

  • {Slide 14}
  • Meeting #168, November 7 (draft circulated November 7)
    • Brad moved to approve, seconded by Eric, no objections or abstentions → Approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 16}
  • 1149.4 is moving to MEC, could probably start forming their ballot group if they have not already done so.

7. Discussion Topics

7 a) Document structure

  • {Slide 17}
  • Brad added to the material for P1687.1 to address a question on where the instance configuration data comes from - a common translator parser (but P2654 needs additional APIs beyond that).  This is covers in slides 23, 24 of our pack and the APIs are those that our clause 9 will document.
  • Are we better to tackle clause 9 first?  While iterating between clauses is going to be inevitable, starting to document the APIs first might reduce some of the re-work.
  • We'll maybe need to address the question of language - should the APIs use C or C++?  C++ is better for handling the instances, but introduces some issues on Windows where library function names can be compiler dependent
  • We really don't want the end user (the person assembling a test) to need to do any complex manipulation of the device/part vendor supplied files. Some complexity within the tooling may be acceptable to achieve that.
  • To progress, we defer decisions on language for now and concentrate on the "actions" that are required.
  • Using Brad's HPP file (https://ieee-sa.imeetcentral.com/p/aQAAAAAE-ur_) as a starting point, start transcribing into clause 9.4.1.  Put the example into the Description part of the clause then break out the detail in the Specification:
    • List functions at level 1
    • List parameters/arguments at level 2
  • Brad will continue to populate this off-line to save time.
  • Current WiP document is now IEEESTD-P2654_Draft_D02_BGVT_20221114.docm, on iMeetCentral at https://ieee-sa.imeetcentral.com/p/aQAAAAAE_X19. 

8. Any Other Business

  • {Slide 18}
  • None.

9. Takeaways:

  • None. 

10. Glossary: 

  • None
  • Carried over:
    • 2654 Interface Translator Node (2654ITN)
    • Translator: See 2654 Interface Translator Node (2654ITN)
    • Transfer Channel, replacing P2654 Message Channel
    • 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.

11. Schedule next meeting

  • November 21, 2022
    • Heiko likely to be out next week.

12. Topic for next meeting

  • Continue discussion of document structure.

13. Reminders

14. List New Action Items

  • None.

15. Adjourn

  • Eric moved to adjourn, seconded by Joel.
  • Meeting adjourned at 12:00 Noon EST

Respectfully submitted,
Ian McIntosh