Minutes of P2654 Working Group Meeting No.101, 2021-03-15

Meeting called to order: 11:05 AM EDT

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/P2654WG/P2654_Meeting_101.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)
Heiko Ehrenberg (GOEPEL Electronics)
Joel Irby (AMD)
Richard Pistor (Curtiss-Wright)
Jon Stewart (Dell)
Louis Ungar (A.T.E. Solutions)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)


By email (non-attendees):

Bill Huynh (Marvell Inc.)
Terry Duepner (National Instruments)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Tom Thompson (for IEEE)

2. Agenda

  • Brad moved to accept the agenda, seconded by Eric, 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 #100, March 8 (draft circulated March 8)
    • Change "Ned" to "Need" in 7a, 4th bullet.
    • Brad moved to approve as amended, Eric seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

7. Discussion Topics

7 a) Primitives: What is needed for a generic group?

  • {Slide 14}
  • See also slides 63 to 67 in the meeting pack.
  • Email discussion in past week primarily noted differences between Michele's MAST and Brad's demo platform.  Mast is mainly scoped to P1687.1's needs, which can be more easily compartmentalised.
  • Can we term these terms we're discussing "node types" (or "model node types"), simply to have group name for them?  Each is a specialisation of a model node.
  • CUSTOM (slide 64): Argument against using this universally is that it would lose some sense of what the behaviour is.
  • Description Brad uses is in JSON, Michele's is more custom. Either way, agreeing on a format is needed for portability.  JSON is convenient in that parsers are readily available. A drawback is that a structure can't use multiple occurrences of the same node type at the same level without encapsulation using "{...}".
  • CUSTOM is a catchall of all the previously described node types, so includes e.g. the clauses associated specifically with LINKER.
  • Does this cover everything for future proofing? Could we find we need to add more later? Shouldn't be necessary - simply provides pointers to software (the plug-ins?) that provide the actual behaviour - doesn't dictate the behaviour directly.
  • Not shown, but parameters can be added to each strategy, injector, etc.
  • CUSTOM can be either a leaf node or a hierarchical node. Some of the existing node types were created because they were found to be recurring cases of adapting CUSTOM nodes.  So could users create their own node types if they found recurring cases?  Possibly but may well break the modelling software as it wouldn't know how to add that new type into its parsing.
  • The specialised names are really just conveniences - they let you know what kind of strategy is going to be used - the difference between a generalised representation and something more human readable.
  • Broadcom Gateway is an example of a device that requires two different interfaces to be used and so may require a CUSTOM description, similarly devices that might optionally use I2C or SPI on the same pins or devices with multiple JTAG ports associated with different cores.
  • ROOT (slide 66) generally pulls in a list of CONTROLLERS.
  • Order of children in tstrategy is important - see note on slide 65.
  • ROOT contains dissimilar sub-trees while CHAIN and CONTROLLER contain similar sub-trees.
  • CONTROLLER (slide 67) is associated with each distinct hardware. It is the point in the model where RVF requests are mapped to hardware driver calls. CONTROLLER is in some ways comparable to what Michele has described for P1687.1 as the Access_Interface. Michele's Access_Interface defines the point in the model where retargeting is replaced with transformation.
  • All terms are simply proposals at this stage that Brad is trying to represent in his proof-of-concept model and have not been adopted by either P1687.1 or P2654.

8. Any Other Business

  • {Slide 15}
  • Second NTF online session will be March 23rd at 1 PM CET.
  • Michele looking for P2654 representation in TAAA Workshop (CfP circulated by email). No immediate offers to participate.

9. Today's Key Takeaways

  • Any node could be described by CUSTOM with the same behaviour - it is just a means of referencing.

10. Glossary Terms from This Meeting

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

  • March 22, 2021
    • Note DST will be in effect: 11 AM EDT, 3 PM GMT.

12. Topic for next meeting

  • Outline documentation from concept descriptions.

13. Reminders

  • None.

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh