P2654 WG Minutes - 2020-11-02

Minutes of P2654 Working Group Meeting No.85, 2020-11-02

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_85.pdf

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

1. Roll Call

Ian McIntosh (Leonardo)
Terry Duepner (National Instruments)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Richard Pistor (Curtiss-Wright)
Jon Stewart (Dell) (joined 11:08)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)

Guests:
---

By email (non-attendees):
---

Excused:
Bill Huynh (Marvell Inc.)
Heiko Ehrenberg (GOEPEL Electronics)
Joel Irby (AMD)
Louis Ungar (A.T.E. Solutions)
Tom Thompson (for IEEE)

2. Agenda

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

3. IEEE Patent Slides

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

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #84, October 26 (draft circulated October 26)
    • No corrections advised.
    • Brian moved to approve, Carl seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

  • {Slide 12}
    • [84.1] Ian: Retrieve latest template for the Standard.
      Latest templates have been placed on our iMeetCentral site. COMPLETE
    • [84.2] Ian/Eric: Post template to iMeetCentral for update and review
      Location for drafts advised. Template still needs to be populated with outline headings and uploaded.  Ian will speak to Eric about this.  ONGOING.
  • Action Item Register: http://files.sjtag.org/P2654WG/ActionItemRegister.xlsx

6. Inter-group Collaboration

  • {Slide 13}
  • TTSC:
    • 1149.7 moving to NesCom for ballot approval.
    • 1450, 1450.1 and 1450.6 revision PARs approved by TTSC and will move to NesCom.
    • For our WG, Heiko is appointed as Elections Administrator and Sankaran Menon (from P2929) as Elections Auditor. 

7. Discussion Topics

7 a) Default minimum description for behaviour and transformation, e.g. for Black Box

  • {Slide 14}
  • Would a circuit description represent an extension of the minimum description or a replacement for it (e.g. in a different form)?
  • 1687.1 is developing a thought that the notion of a black box is insufficient in itself and perhaps needs primitives defined with RVF for input and RVF for output, but nothing more than that.
  • Does 1687.1 need to consider black boxes? Yes, if the component designer wants to hide aspects of the design implementation.
  • There should be some standard commands or at least a query that will list what commands are available.  That probably comes from the software associated with the design(either software/firmware on the assembly or the model of the assembly if the "knowledge" is not actually present within the assembly).
  • In 1687.1 the black box representation may apply to the top-level of the device or to some segment of the network within the device.
  • Michele's examples include the handling of encryption. For P2654, we are probably indifferent to whether the data we carry is encrypted or what it does, but the point here is that a binary plugin could be provided in a similar manner to allow e.g. EDA tool vendors to develop solutions with having access to the full design detail of a part.
  • Is our description always related to the RVF in/RVF out/primitives form, irrespective of black box considerations?
  • Could have a query that acts while knowing particular bits to look out for. iScan could be applied, problem is that this would only check against an expected result so could only pass/fail something so is more limiting that STAPL might be in a similar situation.
  • Brad is working on a C++ IntBV implementation to show how it can be utilised in Python. C++ is explicitly typed while python is very loosely typed.  SWIG can be used to convert C++ to whatever else may be required.
  • We could scope to operations on RVF to RVF conversion.
  • For many system test cases we probably don't really need to negotiate several layers of hierarchy. In most cases we probably have some top level "controller" that then has direct access to underlying "targets".  This may extend though where instruments are accessed via something other than 1149.1, so multi-hop becomes necessary.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • Transformation may be described by primitives along with RVF input and RVF output.
  • Queries my be targeted directly to instruments/registers or may ask the model for data about itself. 

10. Glossary Terms from This Meeting

  • None.
  • Carried over:
    • 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 9, 2020.
  • Noted that November 23 is the week of Thanksgiving (US) and may affect attendance.

12. Topic for next meeting

  • Transformation and RVF-to-RVF interface boundaries

13. Reminders

  • Now that Election Officers have been appointed we should commence the elections process.  Ian will be contacting the EOs to arrange this after ITC.

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh