1 / 37

IEEE P1687.1 Overview and Status for STAM Team

This presentation provides an overview of IEEE P1687.1 and its architecture for non-TAP access to 1687 networks. It discusses the complications introduced for non-ATE applications and explores how P1687.1 and STAM should interface.

shawannae
Download Presentation

IEEE P1687.1 Overview and Status for STAM Team

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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?

  3. 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?

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

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

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

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

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

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

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

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

  12. 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?

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

  14. A proposed 1687.1 solution … 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. • Example SOC Functional registers func register 1 func register 2 1687 portal register Transform engine Device Pin Interface & Controller ScanIn CaptureEn ShiftEn UpdateEn Select TCK Reset ScanOut ScanInterface (Scan client)

  15. 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?

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

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

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

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

  20. SPI example: bit banging 1687network SPI allows choice of word size; 8 bits used here ScanIn CaptureEn ShiftEn UpdateEn TCK Select Reset ScanOut 0 1 2 3 4 5 6 7 Copy state and present inputsto 1687 network, capture outputfrom 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 get slice desel slave sel slave 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

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

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

  23. Example for bit-banging proposal (2) INSTR_OUT I_REG O_REG OTHER_REG INSTR_REG Chain1 INSTR_IN ICL INSTR_IN 1687 serial Network Instruments I_REG O_REG INSTR_REG OTHER_REG 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)

  24. 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”; INSTR_IN 1687 serial Network Instruments ScanIn INSTR_REG CaptureEn 1687 portal register Bit-banger ShiftEn UpdateEn Select INSTR_OUT PDL TCK ScanIn Reset CaptureEn ScanOut ShiftEn UpdateEn Select TCK iProc my_test {} { iWrite INSTR_IN 0b0101 iWrite INSTR_REG 0xABCD iApply iRead INSTR_OUT 0b1111 iApply } Reset iScan Chain1 40 –si 0x50ABCD0000 \ –so 0xXXXXXXXXXX iApply iScan Chain1 40 –si 0x50ABCD0000 \ –so 0xXFXXXXXXXX iApply ScanOut 0x50ABCD0000 0xXXXXXXXXXX 0x50ABCD0000 0xXFXXXXXXXX Retarget to Portal register

  25. 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; } Funcitonal registers func register 1 func register 2 ... ATE Pin Level Interface & Controller 1687 portal register ... func register n pin events! # bit-bang the I2C interface to deliver the write dataiProc 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….

  26. 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

  27. 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?

  28. 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?

  29. 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?

  30. 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)?

  31. 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) • 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|DataInterfaceoperations which are transformed through an access interface into transactions on device pins. device k device k device i device i device j device j Interface k1 Interface k1 Interface k2 Interface k2 Interface i1 Interface i1 Interface i2 Interface i2 Interface j1 Interface j1 Interface j2 Interface j2 … … … … These are easy: it is what the interface is meant to do These could be hard: device knowledge is necessary (behavior)

  32. P1687.1 problem description Functional registers Instruments func register 1 func register 2 . . . 1687 serial Network Instruments Transform engine Interface i1 device i Interface i2 Interface n1 device n Interface n2 … 1687 portal register Client interface ATE orSystem interface 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)

  33. P1687.1 tasks with multi-hop architecture DataInterface(Data Client) 1 Functional registers Instruments func register 1 func register 2 . . . 1687 serial Network Instruments Transform engine Interface i1 device i Interface i2 Interface n1 device n Interface n2 … 1687 portal register Client interface ATE orSystem interface ScanInterface(Scan Client) AccessLink Generic Pin-based interface (ATE) or programming interface (system s/w) 2 5 Host-to-client interface transformation 3 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] 4 Event-to-Transaction transformation == retargeting (Left) (Right)

  34. P1687.1 tasks with client interface access DataInterface(Data Client) 1 Functional registers Instruments func register 1 func register 2 . . . 1687 serial Network Instruments Transform engine 1687 portal register Client interface ATE orSystem interface ScanInterface(Scan Client) AccessLink Generic 2 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

  35. P1687.1 tasks with client interface access DataInterface(Data Client) 1 Functional registers Instruments func register 1 func register 2 . . . 1687 serial Network Instruments Transform engine 1687 portal register Client interface ATE orSystem interface ScanInterface(Scan Client) AccessLink Generic 2 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)

  36. STAM and P1687.1 division suggestion STAM P1687.1 Functional registers Instruments func register 1 func register 2 . . . 1687 serial Network Instruments Transform engine Interface i1 device i Interface i2 Interface n1 device n Interface n2 … 1687 portal register Client interface ATE orSystem interface * 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.

  37. 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?

More Related