Minutes of P2654 Working Group Meeting No.38, 2019-10-14

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

1. Roll Call

Ian McIntosh (Leonardo)
Eric Cormack (DFT Solutions)
Terry Duepner (National Instruments)
Brian Erickson (JTAG Technologies)
Peter Horwood (No affiliation)
Bill Huynh (Marvell Inc.)
Jan Schat (NXP Semiconductors)
Naveen Srivastava (Nvidia)
Jon Stewart (Dell)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)


By email (non-attendees):

Heiko Ehrenberg (GOEPEL Electronics)
Joel Irby (Arm)
Richard Pistor (Curtiss-Wright)
Louis Ungar (A.T.E. Solutions)

2. Agenda

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

3. IEEE Patent Slides

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

4. Review and Approve Previous Minutes

  • {Slide 10}
  • Meeting #37, October 7 (draft circulated October 7)
    • Louis should have been noted as an expected absence.
    • SCSI command should be "Inquiry" instead of "Enquiry",
    • Terry moved to approve as amended, Eric seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Discussion Topics

6 a) P2654 Simulations

  • {Slides 12}
  • Brad's presented an overview of his simulation project on GitHub
  • (The link in the meeting slidepack is to the GitHub project page; the presentation slides are in the 'Docs' folder as HLD.pptx.  This is an evolving record of the work Brad is doing so a snapshot of the slides as presented during the meeting can be found here: http://files.sjtag.org/P2654WG/HLD_20191014.pdf).
  • The simulation is meant to be available for people to use as and when they have time for experimenting with ideas.
  • The code is downloadable. Essentially uses HDL with ICL for 1687 entities.
  • Telnet has been chosen for the outward-looking interface as most languages can provide a Telnet interface.
  • Build example implementations of methodology ideas; simulation environment for instruments, devices and even boards. Predominantly 1149.1 and 1687.1 for now, mostly the latter.
  • Based on Python/myHDL - similar to Verilog but allows use of GTKWave, printing, etc., and gives more capable debugging. Can generate VHDL/Verilog from the Python.
  • Runs as a thread inside the Telnet server.
  • (Slide 4) The green boxes represent hardware logic for the host bus/bus master (instruments themselves are not shown but would be further to the right).
  • Virtual Drivers are essentially in the application space.
  • Is the purpose to prove the description is correct or that the machinery is correct or something else? A bit of all of these - it's trying to answer: Given the description we have, can we actually control this?
  • Wouldn't Formal Verification be quicker, proving that 1s and 0s get through? Possibly but this is for experimentation before you get to the stage of having something to verify. Formal verification will tell you that you have a problem but you'd need to go back to the simulation to see why it is going wrong.
  • Are there any interface that fit in the "other" category? Obvious ones include UART, USB and Ethernet. However, many serial protocols are layered on other serial protocols so there is often a way to "fudge it".
  • If this was transferred to real hardware then the Telnet client-server could be dropped and the virtual drivers replaced with ones that connect to the "real" interfaces instead.
  • P2654 will access top level ports, it will not have direct access to instruments.
  • Does the simulation account for security? It's not currently considered. We expect to leverage the security provided by the devices or standards we employ - we're simply passing data. Some security could be employed in software but that tends not to be very effective.
  • Further slides looked at client, device and instrument representations and Brad showed the structure of the code in the GitHub project.

7. Any Other Business

  • {Slide 13}
  • None.

8. Today's Key Takeaways

  • None.

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

  • October 21, 2019

11. Topic for next meeting

  • P1687.1 feedback on Brad's Module Classification slides.

12. Reminders

  • None.

13. List New Action Items

  • [38.1] Brad: Email brief instruction on using the simulation tool.

14. Adjourn

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

Respectfully submitted,
Ian McIntosh