P 1687 1 standardizing software Jeff Rearick October

P 1687. 1: standardizing software? Jeff Rearick October 6, 2020

Observations • Brad’s recent demonstrations have been software implementations of the concepts we have discussed • Michele has also done a software implementation of these concepts • These pieces of software seem to also be useful in the context of P 2654 • We need to identify what to write in the standard with respect to these software contributions

Problem statement • If most of P 1687. 1 and P 2654 revolve around software, what exactly are we going to standardize? • • • Architecture? Data Structures? Algorithms? Language(s)? Implementations? Actual tools?

Considerations • Software-related standardizations which make sense (to me at least): • • APIs (e. g. function prototypes for callbacks) Binary formats (e. g. RVF) e. BNF syntax (e. g. ICL) Usage/incorporation of open-source applications (e. g. g. RPC) • Software-related standardizations which don’t make sense • How to structure a retargeter / transformer (data structures, algorithms) • Actual implementations • We should strive to align P 1687. 1 and P 2654 where possible • There may be system-to-system communication needed in P 2654 that does not exist in P 1687. 1 • We should be able to define hardware physical implementations in 1687. 1 which are left more abstract in 2654 (e. g. virtual registers) • We must produce examples for some common DPICs, and these must demonstrate the capabilities of 1) tracking of data transformations for debug/analysis purposes (e. g. IJTAG network chain integrity test applied via a non-TAP DPIC must still identify the broken scan chain), and 2) identifying the position of the functional registers by name in the payload bits.

From Heiko’s ITC 2019 presentation retargeter S/W Stored i. Procs Device Pin Interface device i Interface i 2 Interface i 1 API Communication Interface P 2654 stages communication with the DPIC while assembled on the board P 1687. 1 handoff at the DPIC. . . Functional Registers Transform Engine Chip IEEE P 2654 IEEE P 1687. 1 PDL ICL circuitry Instruments 1687 serial network Instruments 5

A detailed look at HW/SW problems retargeter S/W Stored i. Procs device i Device Pin Interface Chip HW Interface i 2 Board/System HW Interface i 1 Chip SW API Communication Interface Board/System SW Chip . . . Functional Registers Transform Engine PDL ICL circuitry Instruments 1687 serial network Instruments 6

A detailed look at HW/SW problems S/W New ecosystem Some ICL changes Stored i. Procs device i Device Pin Interface Chip HW Interface i 2 Board/System HW Interface i 1 Chip SW API Communication Interface Board/System SW . . . Functional Registers Transform Engine Some tool changes retargeter PDL ICL circuitry Instruments 1687 serial network Instruments Chip Some description language changes There is plenty of board HW already This is done by IEEE 1687 7

8 Must we solve 4 problems? retargeter S/W Stored i. Procs device i Device Pin Interface Chip HW Interface i 2 Board/System HW Interface i 1 Chip SW API Communication Interface Board/System SW Chip . . . Functional Registers Transform Engine PDL ICL circuitry Instruments 1687 serial network Instruments

9 Let’s reduce it to 3 problems! IEEE P 2654 retargeter S/W Stored i. Procs ICL Board/System/Chip SW Chip HW Device Pin Interface device i Interface i 2 Interface i 1 API Communication Interface Board/System HW . . . Functional Registers Transform Engine Chip IEEE P 2654 PDL IEEE P 1687. 1 circuitry Instruments 1687 serial network Instruments

10 A vision for common software S/W There may be a unified IEEE P 2654 approach from system interface. Stored to 1687 network i. Procs Board/System/Chip SW ICL . . . Functional Registers Transform Engine circuitry Instruments 1687 serial network Chip IEEE P 2654 PDL Chip HW Device Pin Interface device i Interface i 2 Interface i 1 API Communication Interface Board/System HW retargeter IEEE P 1687. 1 IEEE 1687 Instruments

11 A vision for common software Some ICL changes IEEE P 2654 S/W Stored i. Procs PDL Chip HW Device Pin Interface i 2 Interface i 1 API Communication Interface device i retargeter ICL Board/System/Chip SW Board/System HW Some tool changes . . . Functional Registers Transform Engine circuitry Instruments 1687 serial network Instruments Chip IEEE P 2654 IEEE P 1687. 1 IEEE 1687 Does 1687 need to change?

12 A vision for common software IEEE P 2654 retargeter S/W Stored i. Procs ICL Board/System/Chip SW Chip HW Device Pin Interface device i Interface i 2 Interface i 1 API Communication Interface Board/System HW PDL . . . Functional Registers Transform Engine circuitry Instruments 1687 serial network Instruments Chip IEEE P 2654 IEEE P 1687. 1 IEEE 1687 Not if we stop at retargeting. TBD

Possible solutions • We need to clearly describe the interface between P 1687. 1 and P 2654: what is communicated and how is it communicated? • Request / Response model when P 2654 is the initiator (i. e. when system level code is being directed to the DPIC to carry instrument access actions). • Request / Response model when P 1687. 1 content is being “promoted” (i. e. retargeted and transformed) to the DPIC and merely represented in another format (not JTAG/SVF, but perhaps user-specified API calls like “i 2 c_write()”) • We need to account for an arbitrary number of “hops” (transformations) between DPICs and make each hop look the same from a process point-of-view.

Implications (this slide created after Oct 6 mtg) Response to “above” device i Interface i 2 Request from “above” Interface i 1 • The general (P 2654) solution will address an object like this green one with four distinct types of communications: Request to “below” Response from “below” • The specific (P 1687. 1) solution will address an endpoint which has no communication to/from “below” and must explain how to transform between any DPIC protocol and a 1687 network: DPIC Request from “above” Response to “above” Functional registers Transform engine transform 1687 network