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

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

3. Outline STAM: Need  Purpose  Scope Timeline
Leverage heterogeneous standards and interfaces
Use cases

4. 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)

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

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

7. 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.
Google search: SJTAG glossary

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

9. 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)

10. System-Level Access/Data Paths
ScanBridge over JTAG
ASP over TAP
I2C Selection
ScanPathLinker over JTAG
I2C Selection
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

11. Standards and Interfaces
IEEE (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; : 2-pin compact JTAG standard

12. Standards and Interfaces
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; : 2-pin compact JTAG standard

13. Illustrative SJTAG Infrastructure
– JTAG “Master”
– “Local” chain
– 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
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

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

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

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

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

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

19. Contact 

20. Questions?
Add IEEE logo in top left corner?