Minutes of P2654 Working Group Meeting No.34, 2019-09-16

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

1. Roll Call

Ian McIntosh (Leonardo)
Eric Cormack (DFT Solutions)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.) (joined 11:13)
Joel Irby (Arm)
Richard Pistor (Curtiss-Wright)
Jan Schat (NXP Semiconductors)
Jon Stewart (Dell) (joined 11:07)
Louis Ungar (A.T.E. Solutions)
Brad Van Treuren (No affiliation)
Carl Walker (Cisco Systems)


By email (non-attendees):


2. Agenda

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

3. IEEE Patent Slides

  • {Slides 5-9}
  • Patent slides reviewed.

4. Review and Approve Previous Minutes

  • {Slide 10}
  • Meeting #33, September 9 (draft circulated September 9)
    • No corrections.
    • Eric moved to approve, Brad seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

  • {Slide 11}
  • [29.1] Terry to update Glossary (Due in two weeks).
    • Should become unblocked as a result of action 33.1.
    • Ongoing.
  • [30.1] Tiger team to provide a schedule for what they plan to do by August 26th.
    • Outline circulated.
    • CLOSED.
  • [33.1] Ian: Arrange suitable time for "training" on use of the website.
    • Timeslots identified, first session arranged for tomorrow (17th).
    • CLOSED.
  • Action Item Register: http://files.sjtag.org/P2654WG/ActionItemRegister.xlsx

6. Discussion Topics

6 a) Handoff - possible partitioning of problem space

  • {Slides 12-18}
  • Following are points noted as slides were presented:
    • Slide 15: There may be asynchronism if IFa and IFb of U5 operate under different clocks.
      What if U5 were apparently transparent but included a malicious feature to capture data? Could there be a bypass? Some form of password to authenticate? A bypass may be difficult as the device will presumably be designed in to provide some necessary function which would then be absent if bypassed. Have to start with the assumption that the design intent is good and that everyone is "playing nice".
    • Slide 16: Path selectors/multiplexers/linkers may look transparent in use, but may need prior setup, or introduce additional bits (delays).
    • Slide 17: To execute the test, P2654 doesn't need to know anything about the purpose of the test or the circuit layout covered by the green arrow. Diagnostics would need to have knowledge but this is at the application level. So not in P2654's scope but may still be in the scope of some other part of SJTAG.
    • Slide 18: There has to be handoff from the retargeting but is it described in terms of signal levels over time or by behaviour?
      Mentor describes a state diagram of the TAP from which any desired language representation can be exported. However, diagnostics requires retention of a model in terms of what happens in each cycle. A view may be that P2654 ought to retain that cycle perspective - that may work for 1687 but nothing similar is likely to be available for other interfaces.
    • Overall cycle time for a test may be important, especially if there is no flag to signal that result data is ready/valid. Concept of time-to-live (TTL) may be relevant. Can we tell if the test fails because the result data is bad or because there's a broken interface in the path?
    • How portable are transformations? Can transformations from one vendor be linked/merged/used by transformation produced by another vendor? Do we need a common API? For the blue arrows, between devices, then this should be "portable" and is really a requirement of being an external interface. For the yellow arrows inside the devices, these will be unique or proprietary to the vendor, but it should still represent the external "public" interfaces at each end.
    • There may be a need for a generic API and permission to extend that for proprietary specific cases.

7. Any Other Business

  • {Slide 19}
  • None.

8. Today's Key Takeaways

  • What do we do with e.g. level shifters that alter signal levels but don't change the data?
  • How do we represent transformations in linker devices (scan path linkers, I2C selectors)?
  • Handling of rogue/malicious components in the design/3rd party boards.

9. Glossary Terms from This Meeting

  • None.
  • Carried over:
    • "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 meeting.
    • "Event", "Access Interface" as proposed at April 15 meeting
    • LRU and SRA.

10. Schedule next meeting

  • September 23, 2019
    • Eric may be absent.

11. Topic for next meeting

    • Security
      • Types of security.
      • Scope within P2654.

12. Reminders

  • None.

13. List New Action Items

  • None.

14. Adjourn

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

Respectfully submitted,
Ian McIntosh