On-chip, at-speed debug and DFT support for OCP-based SOCs Heinz Holzapfel

1. On-chip, at-speed debug and DFT support for OCP-based SOCsHeinz Holzapfel November 27, 2014

2. Overview • DFT and DFD Challenges • Technology Driving DFT/DFD Changes • Access, Complexity, Scheduling Problems • Using Current Embedded-Core DFT • The Configurable Test Access Solution • Re-Using the NoC Infrastructure • Summary

3. Silicon Debug: Largest & Growing Barrier to Market Entry First siliconto finaltransfer tovolume mfg. Specto startRTL First netlistto finalnetlist RTLto firstnetlist Final netlistto firstsilicon 2002 (180nm) -2% -5% -2% +2% +7% 2004 (130nm) > 28% of TTM ! 2006 (90nm) > 35% of TTM ? Traditional Debug Strategies Failing Source: Collett ASIC/IC Verification Study

4. Few signals observable Slows emulation, Most signalsnot observable Very expensive, Massive dump files Observability/Debug Costs Starts to impact performance Easy Debug Costs Scale Non-Linearly Post Silicon Near Silicon Emulation Modulesimulation Siliconvalidation Sub-systemsimulation Full-chip simulation FPGA prototype Observing enough signals for debug becomes increasingly expensive and intrusive at each verification stage

5. Typical Problems Slowing Ramp to Volume • Silicon validation and debug takes too long • Lack of SoC-wide observability • Deep-state bugs difficult to isolate • Limited at-speed, in-system debug • Performance requirements not met • No on-chip performance monitoring • System integration takes too long • Inadequate pre-silicon validation and verification

6. Technology Advances Driving DFT Problems • High-Speed & LVDS I/O has required new DFT Techniques (loopback, BIST, BERT) • Multi-Core/Multi-Memory environments has created a crisis in test scheduling • Lack of adequate test power evaluation has placed configuration restrictions on test scheduling and DFT architectures • Process Variation in nanometer processes has required flexible, reconfigurable, Scan Architectures

7. Hi-Speed I/O Access/Test Complexity Problem 16 Network-on-a-Chip Chip Interface Only Powers& Grounds,Hi-Speed I/Oand minimallow speed pins 10 Limited I/O Access Complex ExtraTest Access Arch. Different ExistingCore DFT Features Complex TestSchedulingRequired 12 14 22 32 42 Router Router Router 24 34 Core Core Core After the factTest AccessDevelopmentVery Complex, Very ScheduleIntensive 26 36 46 20 30 40 52 62 72 Router Router Router 54 64 Core Core Core 56 66 76 50 60 70 82 92 102 Router Router Router 84 94 Core Core Core 80 90 100 Traditional DFT Architecture Development Painful

8. Current Core DFT & Test Architectures • Full-Scan supporting shift at slow speeds • AC Scan capability using Launch-on-Capture with clock-pair from PLL • Memory BIST with stop-on-fail for production and data scan-out for engineering • Reduced-Pin Access At-Speed Functional patterns from Cache testing

9. 16 Network-on-a-Chip Chip Interface 10 12 Core With Wrap Core With Wrap Core With Wrap Core With Wrap Core With Wrap Core With Wrap Core With Wrap Core With Wrap Core With Wrap 14 22 32 42 Router Router Router 24 34 26 36 46 20 30 40 52 62 72 Router Router Router 54 64 56 66 76 50 60 70 82 92 102 Router Router Router 84 94 80 90 100 Configurable Access • Different Cores • Different Memories • Different TestArchitectures • Different TestFrequencies Traditional DFT Access Failing

10. 20 21 Configurable Fabric Wrapper Core 28 High-SpeedInputs High-Speed Outputs Input Convert Output Convert Internal Logic 31 33 35 37 27 29 23 25 39 ScanProtocolGateway Low-Speed Scan PortsUnbundler ScanProtocol Gateway Configurable Access Adjustable Core I/O Wrapper (e.g. IEEE 1500) Configurable ScanInput Conversion Configurable ScanOutput Conversion Configurable TestClock Control

11. Using the NoC Infrastructure • Test Flow • Verify NoC infrastructure • Use NoC infrastructure to deliver test • Core Test possible in various different methods: • Dedicated All Cores in Test Mode • Single Core in Test Mode • Real-Time per-Test Mode • At Speed Debug • Utilize NOC to support communication with DFD infrastructure

12. Reuse of NoC Infrastructure • Verification of NoC Busses & Routers • Uses Core Wrapper Interfaces • Use of NoC Routers to deliver Test and Debug • Configuration, control, data, and responses • At-speed, targeted • Core’s Test Mode enabled when Vectors Delivered • Other Cores may still operate functionally • Cores may use their standard Core-based DFT • Scan and BIST as delivered with core • Some guidelines make for more effective testing

13. 410 408 406 404 402 Packet Tail Functional Payload = Scan Test Packet Functional Header Functional Packet 410 408 406 404 402 Scan Data Pattern Depth Scan Depth Scan Test Core Test Address 430 428 426 424 422 End of Vector Scan Data Scan Depth Scan Test Core Test Address 428 427 426 424 422 Scan Data Pattern # Scan Depth Scan Test Core Test Address Possible Test Packets Dedicated Core-Test Payload Packet 400 By-Vector Core-Test Payload Packet 420 By-Vector Core-Test Payload Packet 421

14. S S S S S S Monitor PCON JTAG SoC Reconfigurable Debug Infrastructure Spare Link Spare Link Core Spare Link Core Wrappers

15. DAFCA Debug Solution PERFORMANCE MONITORING LOGIC ANALYSIS SOFT REPAIRS ASSERTIONS Event Driven Analysis

16. Debug and Test • Debug Solution may require embedded instruments in cores and routers • Test Solution is bridge from busses to core test interface and wrapper on relevant I/O pins • Debug and Test Access may be through wrapper

17. Conclusion • DAFCA solution is generic configurable wrapper that fits between Cores and Busses/Routers • Configurability enables adjustment and scalability independent of Core-specific DFT and supports DFD • NoC Test Gateway reuses NoC infrastructure and makes test identical to all portions of the design and eliminates the separate test access routing • Per-Core Fabric makes Test Scheduling an at-test-time adjustable feature that allows different modes and types of testing

18. Thank You !