STAM: The Final Frontiers of System Test Access Management 2018 International Test Conference

STAM: System Test Access Management Its continuing mission: to explore strange new worlds of test & diagnosis…. To boldly go where no one has gone before. (animation: each bullet point appears in sequence) Prime Directive: Don’t impose (many) new requirements on sub-system designs. Instead, leverage existing interfaces and protocols.

Outline STAM: Need  Purpose  Scope Timeline Leverage heterogeneous standards and interfaces Use cases https://standards.ieee.org/findstds/standard/1856-2017.html

STAM: Need  Purpose  Scope System Test Access Management NEED: Standards exist to manage access at device level, but access from board or system level is currently ad hoc. PURPOSE: Leverage existing standards for seamless integration of component access topologies, interface constraint management, and other dependencies. SCOPE: Behavioral (not structural) descriptions and methods (animation: each bullet point appears in sequence)

Why now? PROBLEM: As 2-D Moore’s “Law” scaling gains diminish, heterogeneous integration of subsystem assemblies will drive cost and performance gains while complicating test and diagnosis. SOLUTION: STAM-compliant IP designs and EDA tools enabling seamless access to subsystems for test, diagnosis, and prognosis

Timeline for SJTAG: STAM, ... 2005 2009 2017 2019 2021 2023 4 6 7 1 2 3 5 8 9 1) 2005: SJTAG created 2) 2006: Survey SJTAG members 3) 2009: Survey user & industry experts 4) 2017-Q3: STAM Study Group created 5) 2018-Q3: STAM PAR submitted 6) 2018-Q4: PAR approved, STAM WG formed 7) 2022-Q2: Initial draft of standard for STAM 8) 2022-Q4: Close of balloting for STAM 9) 202x: Develop follow-on standard(s) At the IEEE European Board Test Workshop held in Tallinn, Estonia, May 2005, a group of 14 board test professionals met to discuss a common set of problems associated with the extended test and configuration use of 1149.1 boundary-scan infrastructure within complex multi-board systems. As a result of this discussion, it was decided to create a system-level JTAG initiative, called System JTAG (SJTAG). It also was decided to create a white paper to more clearly define the nature of these problems and hence their possible solutions. Regular meetings to identify problems, needs, requirements, analyze existing standards, and... develop one or more standards documents.

What’s a “system”? ...an organized collection of components or assemblies that are designed to operate together to perform one or more tasks or functions. (Source: ITC18 STAM Poster) A structured hierarchy of subsystems and components with three (3) fundamental properties: Boundaries, Structure, and Synergy. Source: SJTAG glossary Examples: Vehicles: automobiles, airplanes, satellites Smart infrastructure: city/business/personal Cloud computing with networked edge devices: sensors, actuators, processing elements, ... Boundaries, which include not just an interface but also hand-off between the entities it binds Structure, which is a collection of interrelated and/or interdependent parts that often includes a graded hierarchy, and  Synergy, which implies that the whole is greater than the sum of its parts and that the system possesses emergent properties that are not divisible to its subsystems. http://wiki.sjtag.org/index.php?title=Glossary:System Google search: SJTAG glossary

STAM: Use Cases Standards-compliant  Manageable by algorithm System introspection: Device IDCODE, fingerprinting for anomaly detection Power-On Self-Test (POST) Environmental Stress Testing (EST) Root cause or failure-mode analysis Software debug Structural testing Programming/Updating Fault injection Configuration, tuning, instrumentation Standards-compliant  Manageable by algorithm

SJTAG/STAM Stack Standards-compliant access replaces ad hoc access. Functional description of access allows: adaptability/resilience; and black-box/white-box test. Compatible with design-for-security, e.g., management of keys for locking SIB(s) (animation: each bullet point appears in sequence)

System-Level Access/Data Paths ScanBridge over JTAG ASP over TAP I2C Selection ScanPathLinker over JTAG I2C Selection 1149.1 Test Access Port (TAP) P1687 Network Core w/ Instrument 1500 Wrapper AccessLink AccessLink SJTAG Gateway SJTAG Selector Multi-drop JTAG Board JTAG JTAG Sub-chain JTAG Sub-chain I2C AccessLink P1687 Network Core w/ Instrument 1500 Wrapper Via JTAG/I2C Translator Instrument Separate I2C Bus SJTAG I2C Bridge AccessLink I2C Bus

Standards and Interfaces IEEE 1149.1 (JTAG), 1687 (iJTAG) SPI, I²C, USB IEEE 1856: prognostics IEEE P1838 (3-D test), P2427 (analog test) 6LowPAN, ZigBee, Z-Wave, Bluetooth/BLE Mesh networks: ZigBee: 2.4GHz; Z-Wave: 915MHz Star networks: ? IEEE 1856: Standard Framework for Prognostics and Health Management of Electronic Systems IEEE P1838: Standard for Test Access Architecture for Three-Dimensional Stacked Integrated Circuits IEEE P2427: Standard for Analog Defect Modeling and Coverage SPI (Serial Peripheral Interface); I2C (“eye-squared-cee”, Inter-Integrated Circuit) 6LowPAN (IPv6 over Low-Power Wireless Personal Area Networks) 1149.1: 5-pin (or 4-pin) JTAG standard for boundary scan; 1149.7: 2-pin compact JTAG standard

Standards and Interfaces https://blog.mbed.com/post/mbed-client-lite-for-constrained-devices?_ga=2.187914592.975753383.1539370897-324803643.1490041213 Mesh networks: ZigBee: 2.4GHz; Z-Wave: 915MHz 1856: Standard Framework for Prognostics and Health Management of Electronic Systems P1838: Standard for Test Access Architecture for Three-Dimensional Stacked Integrated Circuits P2427: Standard for Analog Defect Modeling and Coverage SPI (Serial Peripheral Interface); I2C (“eye-squared-cee”, Inter-Integrated Circuit) 6LowPAN (IPv6 over Low-Power Wireless Personal Area Networks) 1149.1: 5-pin (or 4-pin) JTAG standard for boundary scan; 1149.7: 2-pin compact JTAG standard

Illustrative SJTAG Infrastructure – JTAG “Master” – “Local” chain – 1149.7 network – Misc. buses U4 U3 FLASH Manager Power U19 ­DSP U5 ­DSP U6 ­RAM U1 System Control Bus ­ µP I2C Sensor U20 ­RAM U2 U7 1149.7 Bridge PM Chain ID Bus U8 ­BIST Engine SPI/I2C Bridge U9 ID Data Store U10 Vector Store U11 FLASH U14 I2C Sensor U18 U12 Selector U13 DPRAM U16 ­PHY U17 Gateway Multidrop ­FPGA U15

Board test use model: JTAG + I2C 1149.1 I/O T A P T A P I2C (m) I2C U4 U1 U2 Hand-off Paradox I2C I2C TAP U5 U6 U3 S B U I2C U7 Paradox - a situation, person, or thing that combines contradictory features or qualities USB I/O U1, U2, U3 are accessible by JTAG (1149.1) board test interface. U4 may be accessible if U2’s I2C master can be accessed via JTAG. How do we access U5, U6, and U7, which have a captive I2C bus? Treat the functional (non-TAP) interfaces as “instruments” to retarget through.

From IEEE 1687.1 WG Meeting: April 17, 2018 Interface i1 device i Interface i2 Interface j1 device j Interface j2 Interface k1 device k Interface k2 … … This is an interface-to-interface connection using some defined protocol (e.g. I2C master to I2C slave) ... and so is this (e.g. 1687 scan host to 1687 scan client) These are easy; they are well-defined protocols designed for plug-and-play usage. Protocol transactions can be represented in some relocatable vector format.

From IEEE 1687.1 WG Meeting: April 17, 2018 Interface i1 device i Interface i2 Interface j1 device j Interface j2 Interface k1 device k Interface k2 … … This is a device which (presumably) can transport data from one of its interfaces to another of its interfaces (but how?)... (example: USB RX -to- I2C master) and so is this (but how?) (example: I2C slave -to- 1687 scan host) These are hard; they require device knowledge and have no well-defined structure. Transport can be modeled in a high-level programming language.

E-MBIST Ecosystem for Data Transfer BSDL 2013 Description SJTAG Templates and Description BA-BIST Template Description BSDL (Pre-2013) Description P1687 Description T D R RW Done Fail Reset Run Algo-Select Data-Select Read-Delay M S T DRAM B S I B Chip Signals TCK TMS TDI TDO TAP Controller BSR BYP ID Code IR I Instrument DataLink SJTAG Infrastructure JTAG Interface Alt I2C 1149.1 BSDL P1687 Access Link Inside the Chip P1687 Network ICL The cloud labeled SJTAG Infrastructure represents the aggregation of logic residing at the board and system level, which provides connection from the Test Manager to the instrument in the device. The arrow from the cloud to the device labeled Alt I2C represents an access path that could also be supported, which provides connection to the P1687 scan network inside of the device.  This alternate interface would require a special access link controller that maps the I2C commands to scan operations for the P1687 scan network. PDL: Procedural Description Language ICL: Instrument Control Language System AccessLink P1687 Instrument ICL Instrument PDL Schematic File of Board Outside the Chip

Call to Action / Next Steps Join the STAM Working Group: Develop protocols for system design and verification. Define security requirements. Make sure your must-have functionality is included. Participating Organizations: Arm🔹ASSET InterTech🔹A.T.E. Solutions🔹Cadence Design Systems🔹Cisco Systems🔹Curtiss-Wright🔹Dell🔹DFT Solutions🔹 Firecron Ltd.🔹GOEPEL Electronics🔹Intel Corporation🔹JTAG Technologies🔹Keysight🔹Leonardo🔹Marvell Inc.🔹 National Instruments🔹NAVAIR Lakehurst🔹Nokia🔹Nvidia🔹Schweitzer Engineering Laboratories, Inc.🔹Via CPU Platform Inc. https://standards.ieee.org/findstds/standard/1856-2017.html

Contact http://www.sjtag.org/members/contact-us Email: chair@sjtag.org 

Questions? Add IEEE logo in top left corner?