Minutes of P2654 Working Group Meeting No.103, 2021-03-29

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_103.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:32)
Terry Duepner (National Instruments)
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)
Carl Walker (Cisco Systems)

Tom Thompson (for IEEE)

By email (non-attendees):

Bill Huynh (Marvell Inc.)
Louis Ungar (A.T.E. Solutions)

2. Agenda

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

3. IEEE Patent Slides

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

4. Review and Approve Previous Minutes

  • Discussion on number of meetings held to date and process of moving through ballot:
    • This is meeting 103 of the Working Group. We are a little over two years through the allotted PAR lifespan of four years. Once the draft of the standard has been prepared, there are a number of stages to go through before it can become an official standard, each of which carries a minimum duration of time: Mandatory Editorial Check (MEC), Ballot group formation, approval to go to ballot, conduct of the ballot, resolution of comments, etc.
    • Some of these steps require submission to IEEE committees that meet quarterly so there are deadlines to meet in to move ahead smoothly.
    • Ballot provides the "end-user" opportunity to study the proposed standard, perhaps test its usefulness, and provide feedback. 
    • 75/75 rule: 75% of the ballot group must vote and 75% of those must vote positively for the draft to pass ballot, else re-work is required based on the comments provided. 30 days are allowed for the ballot and it is not uncommon to go through ballot three times before meeting the approval requirement.
    • Conclusion: We should aim to set aside year 4 for the ballot process and have our draft close to ready by the end of 2021.  Extensions of the PAR are possible, easier to justify if we are in, or very close to, the balloting stage as the PAR expiry draws near.
  • {Slide 11}
  • Meeting #102, March 22 (draft circulated March 22)
    • No corrections noted.
    • Brad moved to approve, Terry seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • None.

7. Discussion Topics

7 a) Continue Use Case diagramming

7 b) Discuss definition of 'Transformation'

  • {Slide 14}
  • Opt to tackle 7b) first (in fact this merged with the intent associated with 7a) from previous meeting).
  • Brad shared the email thread started by Peter on March 16th, in particular the diagram (reproduced as slide 71).
  • Clearly a transformation occurs where different interfaces/protocols are involved but is that really the case when we're talking about moving data through devices using the same protocols?
  • In the diagram, the I2C portal could be driven by any of the connected JTAG ICs.  Commercial tooling could choose to use any one of those JTAG ICs, depending on what best suits the way that tooling works.
  • Wish to avoid reliance on expensive tooling as this has been a problem for IEEE 1687. Wish to allow people to do proof-of-concept type evaluation in a simplistic fashion or readily assemble their own tools.
  • The question is whether a Transformation is where you have any change in the data packet or only where you change domains?  Both cases have an effect on the data stream.
  • At that low level of detail, how much do you need to describe? If it were an ethernet network you could be needing to model numerous bridges, gateway, routers, etc.  Could argue that the Ethernet network simply adds a delay since the data going into the network and the data coming out of the network will be the same.
  • Expectation that a sub-system might provide some functions that are easily relatable, e.g. to allow a PSU to be commanded on - typical of most current test applications.  Considering the diagram, that would require I2C functions from the right hand side to be mapped onto RS232 functions at the left hand side. Some software in the circuitry in the middle would need to be provided to do that.  On the other hand, if you take the arrangement as currently shown, then JTAG tooling could provide a solution the would allow data applied to the UART/TAP bridge to result in the relevant I2C patterns being issued.
  • Parties here are probably talking about very similar concepts but from differing perspectives.  These notions need to be reconciled.
  • further notes are provided on slide 70.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • None.

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

  • April 12, 2021
    • April 5 is Easter Monday - no meeting that day.

12. Topic for next meeting

  • Continue definition of 'Transformation' and diagramming.
    • Are limiting transformations to the Modelpoint?

13. Reminders

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh