Minutes of P2654 Working Group Meeting No.80, 2020-09-28

Meeting called to order: 11:10 AM EDT

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/P2654WG/P2654_Meeting_80.pdf

The cumulative reference pack is located here: http://files.sjtag.org/P2654WG/P2654_Reference_Pack.pptx 

1. Roll Call

Ian McIntosh (Leonardo)
Eric Cormack (DFT Solutions)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd) (joined 11:12)
Joel Irby (AMD)
Jon Stewart (Dell)
Brad Van Treuren (VT Enterprises Consulting Services)
Carl Walker (Cisco Systems)

Guests:
---

By email (non-attendees):
---

Excused:
Bill Huynh (Marvell Inc.)
Richard Pistor (Curtiss-Wright)
Jan Schat (NXP Semiconductors)
Louis Ungar (A.T.E. Solutions)

2. Agenda

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

3. IEEE Patent Slides

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

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #79, September 21 (draft circulated September 21)
    • No corrections advised.
    • Terry moved to approve, Carl seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • P1687.1: PAR extension approved until December 2022.
  • P2929 PAR approved until December 2024.
    • This new working group will hold a kick-off meeting on15th October - contact Ian for joining details if interested.
  • P1149.4: PAR revision approved until December 2024.
  • P1581: PAR revision approved until December 2024.

7. Discussion Topics

7 a) Demo of software messaging

  • {Slide 14}
  • Demonstration of Brad's simulation in the PyCharm IDE. The design being simulated is that shown in Slide 41, instance of 8244 with LEDs. The P2654Board1 has been presented in previous meetings.
  • The demonstration does not include the JTAGScanChain in the model as the board's scan chain has only one device.
  • As requested by members of the group, Brad is providing a work in progress description of the demonstration in UML Sequence Diagram form. The initial form, that has also been shared with P1687.1, is available at: http://files.sjtag.org/Brad/P2654Model_overview.pptx. Additional slides will be coming. The term WIP shall be used in these notes to refer to this package.
  • {WIP:Slides2-7} repeat {Slides33-21}. {WIP:Slide 7} contains further annotation to clarify the model topography. Note: the node ScanMux is listed as not visible in regards to the PDL path name to the LeafAssemblies BYPASS and BSR.
  • {WIP:Slides 5-6} Describes 4 architectural blocks to be described to define the architecture and model of the P2654/P1687.1 callback flow as described in {WIP:Slide 2}.
  • The demonstration consists of two (2) parts: 1) The P2654Model consisting of the software representing the callback model P2654 represents, 2) The P2654Simulations tooling to represent a physical board for testing (1) since a real board does not exist. P2654Simulations does not represent what P2654 is defining, but is a vehicle to simulate hardware use cases of theoretical use cases that do not exit in real hardware. It is further noteworthy that the Python/myHDL based P2654Simulations may be replaced by other C++/SystemC/Verilog/VHDL simulation environments. Python/myHDL was chosen due to the ease of use and available libraries. myHDL does provide a bridge to Verilog simulation tooling. There is no requirement for any P2654 implementation to use Python or myHDL.
  • {WIP:Slide 8} describes the directory structure of the demonstration code. There may be an additional directory, strategy, to decouple the transformation/reverse transformation logic strategy from the individual assembly objects.
  • The assembly directory represents the primitive objects of the topology or the code representing the logic for each Node of the topology tree.
  • The interface directory contains the code representing the edges connecting the Nodes in the topology tree.
  • The scheduler directory represents the code administrating how the application code is synchronized with the hardware.
  • The topology directory represents the code managing the construction and processing of the hierarchical model tree.
  • In the demonstration, the configure_model() method is used to represent code that is to reside in the builder directory.
  • The application alters the software model using path specific write(), read(), and write_read() methods of the Scheduler class that are synchronized with the apply() method of the Scheduler [ex. self.scheduler.write("JC1.U1.IR", intbv('11111111'))].
  • {WIP:Slides 9-11} describes the write(), write_read(), and read() methods as shown in the demonstration code as sequence diagrams.
  • The Scheduler apply() method corresponds to the PDL iApply synchronization statement indicating to the tooling the software model needs to be synchronized with the hardware. In the demo, the synchronization is really done using background threads that run dependently in the background automatically.
  • {WIP:Slide 12} shows the flow of the Scheduler apply() method. It signals the waiting background thread to run and waits/blocks until the synchronization is complete.
  • {WIP:Slide 13} describes the background synchronization Thread (thread 7) Scheduler._scan_cycle_handler(). It waits for a synchronization cycle request to be signaled by the Scheduler.apply() method by calling _wait_for_cycle(). Once triggered, the code will call _new_cycle to process the synchronization code of each Assembly nodes in a depth first search fashion if there are any leaf nodes that have been modified and needing to be synchronized.
  • {WIP:Slides 14-15} show the logic of _wait_for_cycle() and _new_cycle(). Note that each Assembly object contains an apply() method containing code required to perform the synchronization of request callbacks and response callbacks when executing the synchronization with the hardware. The request callback or the apply() may perform the transformation logic for an Assembly node. The response callback or the apply() may perform the reverse transformation logic for an Assembly node. The apply() method represents the fourth (4th) category from {WIP:Slides 5-6}.
  • {WIP:Slides 16-21} describe the apply() methods for a variety of Assembly nodes.
  • {WIP:Slides 19-21} shows the apply code for the top level of the tree where the hardware driver scan_ir() or scan_dr() methods are called depending on what RVF message type was received.
    • Demonstrated in the meeting is how each Assembly shares a common request handler that has localized registered callbacks for each instance of a specific Assembly node to call by lookup from the registration table. Thus, each Assembly defines a specific callback method to be called to process each command type coming from the host interface associated with the Assembly.
  • Likewise, each Assembly instance has a response handler that may or may not have specific callbacks associated with each command that forwards responses as instance local data to be shared between the response handle and the apply() method of that instance.
  • The requests and responses are trigged by separate threads driving the AccessInterface RVF message handling code. {WIP:Slides 22-23} show the flow of the AccessInterface logic used to ripple the requests, transformation, responses, and reverse transformation of the P2654 processing flow.
  • Once a LeafAssembly node makes a request, the ripple takes place up the tree during the apply() call.

7 b) Alternative Use Cases

  • Not discussed due to lack of time.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • Hardware simulation is separate from the software model.

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

  • October 5, 2020.

12. Topic for next meeting

  • Continue from today.
    • a) Alternative Use Cases)
    • b) Demo Q&A

13. Reminders

  • None.

14. List New Action Items

  • None.

15. Adjourn

  • Peter moved to adjourn, seconded by Brian.
  • Meeting adjourned at 12:14 PM EDT

Respectfully submitted,
Ian McIntosh