IEEE P1687.1 Overview and Status for STAM Team Presentation

IEEE P1687.1 overview and status for STAM team Jeff Rearick, AMD January 14, 2019 P1687.1 working group * View these slides in Slide Show mode there s lots of useful animation

Outline Overview of IEEE P1687.1 An architecture for non-TAP access to 1687 networks The most primitive example: bit banging Complications introduced for non-ATE applications P1687.1 and STAM: how should we interface?

Outline Overview of IEEE P1687.1 An architecture for non-TAP access to 1687 networks The most primitive example: bit banging Complications introduced for non-ATE applications P1687.1 and STAM: how should we interface?

The Scan Client 1687 network interface Example SOC Functional circuitry PDL written here 1687 serial Network Instruments ScanIn CaptureEn ShiftEn UpdateEn Select TCK Reset ScanOut ScanInterface (Scan client)

The TAP Client 1687 network interface Example SOC Functional circuitry PDL written here eTAP eTAP 1687 serial Network Instruments ScanIn TMS Select TCK TRST ScanOut ScanInterface (TAP client)

Working model for todays 1687 SOCs Example SOC Functional circuitry PDL written here TMS TDI TCK 1149.1 TAP and Test Access Port Controller 1687 serial Network Instruments TRSTN TDO AccessLink <name> Of STD_1149_1_2001 { } ScanIn ScanIn CaptureEn ShiftEn UpdateEn Select TCK Reset ScanOut TMS Select TCK TRST ScanOut This configuration is well-supported (or) ScanInterface (Scan client or TAP client)

What about SOCs without TAPs? Example SOC This could be I2C, SPI, MDIO, Functional circuitry PDL written here Device Pin Interface & Controller 1687 serial Network Instruments AccessLink <name> Of Generic { } ScanIn ScanIn CaptureEn ShiftEn UpdateEn Select TCK Reset ScanOut TMS Select TCK TRST ScanOut This configuration is NOT well-supported yet. (or) ScanInterface (Scan client or TAP client)

What about SOCs without TAPs? Example SOC This could be I2C, SPI, MDIO, Functional circuitry PDL written here ? What goes in the box? This is what P1687.1 will figure out Device Pin Interface & Controller 1687 serial Network Instruments ScanIn ScanIn CaptureEn ShiftEn UpdateEn Select TCK Reset ScanOut TMS Select TCK TRST ScanOut This configuration is NOT well-supported yet. (or) ScanInterface (Scan client or TAP client)

DataInterface (Data client) PDL written here A parallel problem Example SOC DataIn DataOut func register 1 Instruments This could be I2C, SPI, MDIO, Functional circuitry func register 2 There is no DataInterface statement in ICL to tag this type of parallel interface Device Pin Interface & Controller Functional registers This configuration is NOT well-supported, either yet.

DataInterface (Data client) PDL written here Analog: tiny delta Example SOC DataIn DataOut AnalogPort func register 1 Instruments This could be I2C, SPI, MDIO, Functional circuitry func register 2 There is no DataInterface statement in ICL to tag this type of parallel interface Device Pin Interface & Controller Functional registers This configuration is NOT well-supported, either yet.

DataInterface (Data client) The full picture Example SOC DataIn DataOut PDL written here AnalogPort func register 1 Instruments This could be I2C, SPI, MDIO, Functional circuitry func register 2 PDL written here Device Pin Interface & Controller Functional registers 1687 serial Network Instruments ? What goes in the box? ScanIn ScanIn CaptureEn ShiftEn UpdateEn Select TCK Reset ScanOut TMS Select TCK TRST ScanOut (or) ScanInterface (Scan client or TAP client)

Outline Overview of IEEE P1687.1 An architecture for non-TAP access to 1687 networks The most primitive example: bit banging Complications introduced for non-ATE applications P1687.1 and STAM: how should they interface?

A proposed 1687.1 solution Example SOC Parallel data is handled with the native register access already in the device func register 1 func register 2 Device Pin Interface & Controller Transform 1687 portal register engine ScanIn CaptureEn ShiftEn UpdateEn Select TCK Reset ScanOut All traffic with the 1687 network is transformed into writes and reads of the 1687 portal register Functional registers Conversion of the portal register data to and from the 1687 network is done here ScanInterface (Scan client)

A proposed 1687.1 solution Example SOC but this could be many things: bit banging, instruction-based, with or without FIFOs, with our without clock generation, . Key question: mandate a prescribed hardware implementation, or let the user describe his hardware? P1687.1 will likely do the latter. func register 1 func register 2 Device Pin Interface & Controller Transform 1687 portal register engine ScanIn CaptureEn ShiftEn UpdateEn Select TCK Reset ScanOut Functional registers ScanInterface (Scan client)

Outline Overview of IEEE P1687.1 An architecture for non-TAP access to 1687 networks The most primitive example: bit banging Complications introduced for non-ATE applications P1687.1 and STAM: how should we interface?

A proposed 1687.1 solution for P1687.2 Example SOC func register 1 func register 2 Device Pin Interface & Controller Transform 1687 portal register engine ScanIn CaptureEn ShiftEn UpdateEn Select TCK Reset ScanOut Functional registers ScanInterface (Scan client)

A proposed 1687.1 solution for P1687.2 Example SOC func register 1 func register 2 Device Pin Interface & Controller Bit-banger 1687 portal register ScanIn CaptureEn ShiftEn UpdateEn Select TCK Reset ScanOut Functional registers ScanInterface (Scan client)

Bit-banging: the most primitive solution Example SOC func register 1 func register 2 Device Pin Interface & Controller ScanIn CaptureEn ShiftEn UpdateEn Select TCK Reset ScanOut Bit-banger 1687 portal register Functional registers

Bit-banging: the most primitive solution Example SOC func register 1 func register 2 Device Pin Interface & Controller ScanIn CaptureEn ShiftEn UpdateEn Select TCK Reset ScanOut Bit-banger 1687 portal register CaptureEn UpdateEn ScanOut ShiftEn ScanIn Select Reset TCK Functional registers

SPI example: bit banging SPI allows choice of word size; 8 bits used here 0 1 2 3 4 5 6 7 ScanIn CaptureEn ShiftEn UpdateEn TCK Select Reset ScanOut 1687 network Copy state and present inputs to 1687 network, capture output from 1687 network. Each clock phase on the 1687 network costs 8 SCLKs (therefore each TCK cycle costs 16 SCLKs) SS = 1 idle idle SS = 0 sel slave desel slave get slice 0 1 2 3 4 5 6 7 send slice get slice SS = 1 SS = 0 Downside: each time slice on the 1687 network costs 8 SPI SCLK cycles

Example for bit-banging proposal (0) PDL func register 1 Instruments func register 2 . . . INSTR_IN Pin Level Interface & Controller A T E 1687 serial Network Bit-banger Instruments 1687 portal register . . . INSTR_OUT func register n PDL Functional registers End goal: retarget PDL to ATE pin events

Example for bit-banging proposal (1) INSTR_IN INSTR_REG Instruments INSTR_OUT PDL iProc my_test {} { iWrite INSTR_IN 0b0101 iWrite INSTR_REG 0xABCD iApply iRead INSTR_OUT 0b1111 iApply }

Example for bit-banging proposal (2) INSTR_OUT I_REG O_REG INSTR_REG OTHER_REG Chain1 INSTR_IN ICL INSTR_IN I_REG O_REG 1687 serial Network OTHER_REG INSTR_REG Instruments INSTR_OUT PDL iProc my_test {} { iWrite INSTR_IN 0b0101 iWrite INSTR_REG 0xABCD iApply iRead INSTR_OUT 0b1111 iApply } iScan Chain1 40 si 0x50ABCD0000 \ so 0xXXXXXXXXXX iApply iScan Chain1 40 si 0x50ABCD0000 \ so 0xXFXXXXXXXX iApply Retarget to ScanInteface Chain1 (traditional 1687)

Example for bit-banging proposal (3) iWrite Portal 0b01000000; iApply; iWrite Portal 0b01000100; iApply; # capture iWrite Portal 0b00100000; iApply; iWrite Portal 0b00100100; iApply; # shift 0 (rightmost) iWrite Portal 0b00100000; iApply; iWrite Portal 0b00100100; iApply; # shift 0 ... # shift 13 more 0s iWrite Portal 0b00100000; iApply; iWrite Portal 0b00100100; iApply; # shift 0 iWrite Portal 0b10100000; iApply; iWrite Portal 0b10100100; iApply; # shift LSB of D iWrite Portal 0b00100000; iApply; iWrite Portal 0b00100100; iApply; ... # shift rest of DCBA0 iWrite Portal 0b10100000; iApply; iWrite Portal 0b10100100; iApply; # shift LSB of 5 iWrite Portal 0b00100000; iApply; iWrite Portal 0b00100100; iApply; iWrite Portal 0b10100000; iApply; iWrite Portal 0b10100100; iApply; iWrite Portal 0b00100000; iApply; iWrite Portal 0b00100100; iApply; # shift MSB of 5 iWrite Portal 0b00010000; iApply; iWrite Portal 0b00010100; iApply; # update iWrite Portal 0b00000000; iApply; iWrite Portal 0b00000100; iApply; # nop iWrite Portal 0b00000000; iApply; iWrite Portal 0b00000100; iApply; # nop iWrite Portal 0b01000000; iApply; iWrite Portal 0b01000100; iApply; # capture iWrite Portal 0b00100000; iApply; iWrite Portal 0b00100100; iApply; # shift 0 (rightmost) ... # shift 0000DCBA iWrite Portal 0b00100000; iApply; iWrite Portal 0b00100100; iApply; # shift in the LSB of the 0 iRead Portal 0bxxxxxxx1; iApply; # check the MSB of the F iNote status Compare INSTR_OUT 0b1111 ; iWrite Portal 0b00100000; iApply; iWrite Portal 0b00100100; iApply; # shift in the LSB of the 0 iRead Portal 0bxxxxxxx1; iApply; # check the next bit of the F iNote status Compare INSTR_OUT 0b1111 ; Retarget to Portal register CaptureEn UpdateEn ScanOut ShiftEn ScanIn Select Reset TCK INSTR_IN 1687 serial Network INSTR_REG Bit-banger Instruments 1687 portal register INSTR_OUT ScanIn CaptureEn ShiftEn UpdateEn Select TCK Reset ScanOut PDL iProc my_test {} { iWrite INSTR_IN 0b0101 iWrite INSTR_REG 0xABCD iApply iRead INSTR_OUT 0b1111 iApply } iScan Chain1 40 si 0x50ABCD0000 \ so 0xXXXXXXXXXX iApply iScan Chain1 40 si 0x50ABCD0000 \ so 0xXFXXXXXXXX iApply 0x50ABCD0000 0xXXXXXXXXXX 0x50ABCD0000 0xXFXXXXXXXX

Example for bit-banging proposal (4) Trick: define portal register as a Callback DataRegister DataRegister Portal { WriteCallBack write_I2C_1687_Portal_register; ReadCallBack read_I2C_1687_Portal_register; } func register 1 func register 2 . . . Pin Level Interface & Controller A T E 1687 portal register . . . func register n pin events! Funcitonal registers # bit-bang the I2C interface to deliver the write data iProc Write_I2C_1687_Portal_register {write_data} { iCall SelectPortalAddress; iWrite SCL 0b0 iWrite SDA $write_data[0] iApply iWrite SCL 0b1 iApply iWrite SCL 0b0 iWrite SDA $write_data[1] iApply ... } *Note: I realize that this example is for I2C while the previous slides were about SPI. It is left as an exercise to the reader to take one as inspiration to complete the other .

Note about this example Bit-banging is just the simplest way to illustrate one possible implementation of the proposed P1687.1 architecture Bit-banging is slow and inefficient; other implementations can be faster and much more efficient Instruction-based approaches (with commands for capture, shift, update, etc.) 1149.5 test bus controller approach many others These approaches focus on the hardware mechanisms and expect there to be some degree of documentation of that hardware Perhaps the more interesting aspect of P1687.1 is the software

Outline Overview of IEEE P1687.1 An architecture for non-TAP access to 1687 networks The most primitive example: bit banging Complications introduced for non-ATE applications P1687.1 and STAM: how should we interface?

Problem statement IP-level tests that will be retargeted to SOC level for application on ATE are generally static in nature Retargeting can be done offline, a priori, with no conditional branching based on data read from the DUT IP-level tests that are intended for use in an embedded system context may be dynamic (interactive) in nature The flow of the test requires the controller to respond to data read from the DUT It is not obvious that an offline retargeting flow can be applied here Does P1687.1 need to re-think retargeting? or should this embedded requirement be part of the baseline IEEE 1687? or is this embedded requirement something that STAM should tackle?

Outline Overview of IEEE P1687.1 An architecture for non-TAP access to 1687 networks The most primitive example: bit banging Complications introduced for non-ATE applications P1687.1 and STAM: how should we interface?

P1687.1 and STAM discussion Jeff Rearick November 27, 2018 Outline: Can we simplify P1687.1 by splitting out part of our big-picture to be done by STAM? Do we need to re-visit the notion of retargeting (since it doesn t work for embedded)?

Definitions Events are operations on one register (an iApply causes a CSU sequence on a register). Retargeting deduces the operations on a ScanInterface | DataInterface to cause those register events. Transactions on a device interface (an access interface) represent the protocol at the pins of the device which become the operations on the ScanInterface. Transaction-to-transaction transformations are between device interfaces (hosts and clients) These are easy: it is what the interface is meant to do Interface k1 Interface k2 Interface i1 Interface i2 Interface j1 Interface j2 device i device j device k These could be hard: device knowledge is necessary (behavior) Interface k1 Interface k2 Interface i1 Interface i2 Interface j1 Interface j2 device i device j device k Transaction-to-Event transformations are from an interface to a register. In STAM, an event is any state change in the hardware, not just a register. STAM doesn t know which register is being targeted. STAM should only be dealing with transactions, not specific events. There may be several events which happen that are dealt with in one transaction; STAM doesn t care. Summary: Register events require retargeting to ScanInterface|DataInterface operations which are transformed through an access interface into transactions on device pins.

P1687.1 problem description func register 1 Instruments func register 2 . . . System interface Transform Interface n1 Interface n2 Interface i1 Interface i2 1687 serial Network interface Client ATE or engine 1687 portal register device i device n Instruments Functional registers We can presume that there will be a 1687 network on the right-most side of any device addressed by this standard We can presume that there will be circuitry to transform registered data to and from 1687 network operations Can we presume that this registered data is directly accessible from a device client interface? If not, then we need to address the problem of transforming through an arbitrary number of devices (which may be integrated into a single SOC)

P1687.1 tasks with multi-hop architecture 1 DataInterface (Data Client) func register 1 Instruments func register 2 . . . System interface Transform Interface n1 Interface n2 Interface i1 Interface i2 1687 serial Network interface Client ATE or engine 1687 portal register device i device n Instruments Functional registers ScanInterface (Scan Client) 2 5 AccessLink Generic Pin-based interface (ATE) or programming interface (system s/w) 3 Host-to-client interface transformation 4 Though-the-device (client-to-host) transformation [Michele would call this a retargeting operation ; likewise, the transformation engine is just another device through which we would retarget] Event-to-Transaction transformation == retargeting (Left) (Right)

P1687.1 tasks with client interface access 1 DataInterface (Data Client) func register 1 Instruments func register 2 . . . System interface Transform 1687 serial Network interface Client ATE or engine 1687 portal register Instruments Functional registers ScanInterface (Scan Client) 2 AccessLink Generic 3 Pin-based interface (ATE) or programming interface (system s/w) This is the ideal scenario: there are no intermediate hops between the device interface where ATE connects and the interface used to control the registers

P1687.1 tasks with client interface access 1 DataInterface (Data Client) func register 1 Instruments func register 2 . . . System interface Transform 1687 serial Network interface Client ATE or engine 1687 portal register Instruments Functional registers ScanInterface (Scan Client) 2 AccessLink Generic 3 Pin-based interface (ATE) or programming interface (system s/w) Even if there is something in the green box, the callback approach would still work (though the callback would get more complicated)

STAM and P1687.1 division suggestion func register 1 Instruments func register 2 . . . System interface Transform Interface n1 Interface n2 Interface i1 Interface i2 1687 serial Network interface Client ATE or engine 1687 portal register device i device n Instruments Functional registers STAM P1687.1 * Note: Brad s objection is that this approach requires a retargeter, which is not available in the embedded environment. Michele suggests that if the system is described appropriately, we don t need a retargeter, just a transformer calling callbacks. We need to understand the embedded use model and what it implies about how we describe the system under test and the tests to be re-used.

How should P1687.1 answer the retargeting question? We may have two very different use models in play for P1687.1: ATE-centric, which looks just like 1687 from a retargeting perspective, but without a TAP serving as the DPIC Embedded, which cannot use a retargeter as part of the flow for using PDL in a system environment Michele and Brad are proposing a higher level of abstraction for retargeting Can we re-formulate the notions of retargeting and transformation (like Michele has done) to solve both the non-TAP access problem and the embedded use case? Should P1687.1 take the simple approach (i.e. assume offline retargeting) and finish quickly, or should we try to address the bigger embedded question? If we take the quick approach, are we doing anything that would inhibit STAM from succeeding?