P2654 WG Minutes - 2021-12-13

Minutes of P2654 Working Group Meeting No.135, 2021-12-13

 Meeting called to order:  11:07 AM EST

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

Guests:
---

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

2. Agenda

  • Brad moved to accept the agenda, seconded by Carl, 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 #134, December 6 (draft circulated December 6)
    • 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}
  • 1149.1 - little indication of participation so far, may post to LinkedIn.  Ian had requested that information on study group start-up was relayed at NTF [post meeting note: NTF was held Nov 30-Dec 1].
  • P2427 exploring next steps with a view to moving to ballot, possibly around February 2022.

7. Discussion Topics

7 a) Continue Review of Standard Draft

  • {Slide 14}
  • On architecture, 1687.1 is fleshing out some of the terms Brad has been using recently so they can be referenced in that standard, much of that will carry over into our work.
  • May want to start by explaining the Host and Client interface relationship and how that maps into the software virtualisation. That might be in either the Introduction (4.1) or Architecture (4.3).  This may help with interpreting later diagrams.
  • Fig 8 of 1687 may be useful {slide 119} for this and could replace the existing placeholder diagram in the document.
  • Would this get confusing if the downstream interface (i.e. "to the right") acted as a server to an upstream client? For our context, the "client" is always in the leaf.
  • Rules for 1687 Transfer Procedure {slide 122}: Do we want to be as specific as this in our rules? It might limit the scope of what we support.  There are aspects that need to be considered for some cases, such as how/when retargeting is done.  But are there rules that can be extracted as generic or universally applicable?  May need to try some cases to see.
  • Rules for specific cases are allowable in the case of optional features, e.g. where a retargeter is needed then a rule can require that retargeting takes place before the transfer procedure is applied. That rule can be ignored otherwise.
  • Rules for 1687.1 Transfer Procedure {slide 123}: Seriality of objectives (complete one before starting another) - this is distinct from any notion of concurrency. Also applied to 1687 and 2654 {slide 124} rules. Noted that iTake and iRelease as in 1687 PDL may not be ideal.
  • Considering some of the themes discussed today, it's not clear how these might best fit into the headings we have laid out.  There is repetition of headings from section 4 into later sections so we may end up duplicating text: Perhaps we have created too many "layers" and should instead have a simpler introduction in section 4 and leave more of the detail to later.  Compare with current layout of P1687.1 document.
  • Much of the explanation (education) might be better placed alongside examples in informative annexes.
  • The modelpoint abstraction means we don't have to consider too much of what each interface does, so we just need to provide solutions that work for the modelpoint.  This notion probably ought to be brought out early in the standard.
  • Document was not updated and latest version remains IEEESTD-P2654_Draft_D01_BGVT_20211115.docm.

8. Any Other Business

  • {Slide 15}
  • Ian will be reviewing group membership over the holiday period.  Aim is to get roster in IEEE myProject "correct".
  • Schedule for getting to ballot and potential for PAR extension request discussed.

9. Takeaways:

  • The use of Modelpoint as an abstraction of interfaces into the software model should be presented early in the standard. 

10. 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.

11. Schedule next meeting

  • January 10, 2022
    • A new WebEx meeting invite series for 2022 will be issued in due course.

12. Topic for next meeting

  • Consider the structure of the document.

13. Reminders

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh