Minutes of P2654 Working Group Meeting No.123, 2021-09-20

 Meeting called to order:  11:05AM EDT

The slide references relate to the pack used during this meeting, located here: 
http://files.sjtag.org/P2654WG/P2654_Meeting_123.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)
Eric Cormack (DFT Solutions) (joined 11:29)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Joel Irby (AMD)
Richard Pistor (Curtiss-Wright)
Jon Stewart (Dell)
Brad Van Treuren (VT Enterprises Consulting Services)
Louis Ungar (A.T.E. Solutions)
Carl Walker (Cisco)

Guests:
Tom Thompson (for IEEE)

Excused:
Bill Huynh (Marvell Inc.)
Terry Duepner (National Instruments)

2. Agenda

  • Agenda amended to include update on C4 Model diagrams.
  • Brad moved to accept the agenda as amended, seconded by Heiko, 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 #122, September 13 (updated draft circulated September 15)
    • No corrections noted.
    • Brad moved to approve, Carl seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • Nothing to note.

7. Discussion Topics

7 a) P2654 C4 Model Changes

  • {Slide 14}
  • README.md is automatically displayed if you browse to https://github.com/bradfordvt/P2654Model2 and includes the latest diagram changes made by Brad (no need to download the docx file).  Clicking on a diagram will open that diagram in a new tab, allowing a larger view.
  • The captions now include a numbering scheme to represent position in hierarchy (since the images displayed in the README.md file do not support the click-to-examine method of tunnelling through diagrams):
    • 'S' indicates 'System' set of diagrams, 'B' indicates 'Board' and 'D' indicates 'Device'.
    • First number is the hierarchical 'level' of that diagram within the set.
    • Second number is the index of that diagram with the level.
    • e.g. S.1.3 is diagram #3 within level 1 of the System set.
  • Did we consider board and device to be substantially similar? The tooling flow will be different; even for a COTS board there will be different data forms - you'll have a form of netlist rather than RTL.

7 b) Resume Review of Standard Draft

  • Some of what we have in the Introduction in section 4.1 perhaps belongs in the Overview in section 1.  Setting out what we're trying to do ought to be covered in the Overview. By the time we get to section 4 and 4.1 we're getting into fleshing things out.  Should avoid re-stating too much from the Overview.
  • Figure 5 has been edited for the ITC presentation (swapping the positions of the orange and green arrows) to make it more consistent with the format Jeff (Rearick) has been using.
  • How much effort do we need to put in to explain that we have complementary rather than competing standards? Perhaps this is something that can be addressed in an example or two in an annex.
  • Need to emphasise that we can leverage these other standards but we don't require them.  We need to be able to use devices etc., that don't necessarily conform to a published standard, but in any case there does need to be some underlying DFT applied to make the devices/interfaces useful to us.  In some cases we might need to bridge through standards, e.g. going via 1838 (3D IC) to get to 1687. 
  • The ModelPoint offers a transition between the 'tooling domain' and the 'P2654 domain'.
  • The paragraph above Figure 3 (and Figure 3 itself) may belong under "Background".
  • The Overview in section 1 ought to tell the reader whether the standard is relevant to their use and whether it's worth reading further. Once they get to section 4 they'll be looking to learn how to implement the standard.
  • Brad will place the document,  with markup, in iMeet.  Comments do not need to be inserted directly into the document - they can just be posted as responses.
  • Note: The markup will not show if you view the Word document online in iMeet, it needs to be downloaded.  Other option is to post a PDF showing the markup, but that is extra effort we don't want to expend for every edit.
  • steps to the Frameworks. Instead, these should go to the Local Repository and then from there to the Frameworks.
  • Version edited today saved as IEEESTD-P2654_Draft_D01_BGVT_20210920.docm in the Drafts/Group Submissions folder.

8. Any Other Business

  • {Slide 15}
  • None.

9. Glossary: 

  • None.
  • Carried over:
    • 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:

  • None. 

11. Schedule next meeting

  • September 27, 2021
    • Jon expects to be out.

12. Topic for next meeting

  • Continue review of standard draft
    • IEEESTD-P2654_Draft_D01_BGVT_20210920.docm

13. Reminders

14. List New Action Items

  • None.

15. Adjourn

  • Brad moved to adjourn, seconded by Peter.
  • Meeting adjourned at 12:06 PM EDT

Respectfully submitted,
Ian McIntosh