Standard based Instrumentation schemes for 3D SoC

Neal StollonChairman, Nexus 5001 Forum www.nexus5001.org

Neal Stollon, Ph.D, P.E.Chairman, Nexus 5001 Forum nstollon@nexus5001.org Ph 972 458 9625

Neal Stollon is chairman of the 5001 Nexus Forum, which provides industry support for IEEE ISTO Nexus 5001 and related instrumentation standardization efforts. He has a Ph.D in EE from Southern Methodist University and is a licensed P.E., and has a decade of experience in debug architectures and instrumentation issues, on top of another decade or so of processor and SoC experience at TI, LSI Logic, MIPS, and elsewhere. Dr. Stollon is CTO at HDL Dynamics, providing systems analysis and consulting on embedded IP and instrumentation solutions for digital systems He is also the author of the book On Chip Instrumentation: Design and Debug for Systems on Chip . He may be reached at neals@hdldynamics.com Author Information

Standard based Instrumentation schemes for 3D SoC AbstractStacked multi-die and 3D SoC are being prototyped as a next generation for increasing silicon complexity. Complex designs increasingly require means for on-chip debug and interactive access and analysis instrumentation.

The complexities and interconnect limitations of 3D SoC make on-chip debug and instrumentation challenging, especially as they must be compatible with other standards being developed for heterogeneous 3D stacks. On-chip debug and instrumentation must interoperate with existing (i.e. JTAG) and proposed test strategies (i.e. PAR 1838) for 3D SoC.

Key requirements for a 3D SoC debug and instrumentation environment map against proposed solutions, One is based on the IEEE 5001 Nexus standard. Nexus instrumentation features meet several of the key requirements for 3D SoC including low pin and via options for high performance debug interfaces between die layers support for heterogeneous and multi-core systems

Interface standards should support both debug control and data trace in ways that are compatible with proposed 3D SoC test schemes.

What is 3D SoCManufacturing technique for next generation of computing complexity Stacked die allow 3D low latency integration Test and Debug are integration and interconnect challenge

Typical 3D SoC Test and Debug Proposals discussed per PAR 1838

Active JTAG TAP controller on all dieActive JTAG TAP controller on bottom dieIEEE 1500 wrapper/signaling on other die TCKTMSTDITDOJTAGPath IEEE 1500signals

3D Instrumentation ChallengesLarger number of cores, more deeply embedded problemsDebug data previously available at I/O, now embedded in 3D structures Diverse die with differing cores and other IPinstrumentation integration is limited by Vendor specific featuresNeed to support range of instrumentation protocols/interfacesLimited IO and inter-layer vias are available for debug useVias are expensive resourceSupport for Legacy standards and existing debug features:

3D SoC Debug SchemesDebug enabling TAPs support both test and debug operations1149.7 2 wire mode, decreases JTAG vias requiredDebug data port can be overlaid on 1500 signal interfaces

Typical 3D SoC Test and Debug Proposals

Active ATU TAP controller on all dieActive JTAG TAP controller on bottom dieIEEE 1500 wrapper/signaling on other die Data port Muxed to 1500 wrappers1149.7 (2 wire)TMSTDITDOTCKTMSTDITDOTCK1149.7 (2 wire)ReducedJTAGPinsLeverageIEEE1500SignalsUsed for test

Concensus of 3D SoC Debug NeedsReal Time Instrumentation Debug and Calibration in stack Multiple Trace and Memory and Register Access MethodsReal Time Read (Trace) / Write (Configuration) operations

Heterogeneous Processor support lots of legacy IPCPU/SoC architecture agnostic standard (different architectures per die)Implicit multi-core support

Long Thin Wire for debug High performance and low IO Interface options

Leverage mature technologiesCompliance between standards/industry bodies addressing 3D SoC Proven use case in complex electronics

Multiple tools SourcesSupport from leading vendors in the tools communityIndustry consortia support*

A 3D SoC Nexus 5001 configurationDebug ControlMessagesBase die Subsystem Middle die Subsystem Top die Subsystem Trace CombinerRouterData /Trace MessagesSerDes

Channels2-wire JTAG (1149.7) core core core coreTrace RAMData BufferDie Level 1149.1 JTAG chainDie level Processor Cross-triggersMultiplexed IEEE 1500 signalling(Bidirectional for calibration capabilities) LocalNexus *

*Nexus 5001 Applied to each 3D die Layer 1500 complaint Output Port

1500 complaint Input Port

JTAG TDI/TDO DebugSocket

Data In FSMData Out FSMJTAG TAPTCODE & Message Control/ FormattingTrace RAM RegistersNexusDebug Registers Debug Ctrl Debug Data Out DebugData In.ProcessorDATA SocketDebugSocket

Other IPDATA SocketNexus Defined DomainCommon regardless of Layer configurationLayer Defined Domain(Configurations different For each layer)bus FabricSYSTEM BUS

Why Nexus 5001 for 3D SoCReal Time Debug Instrumentation Architecture and interface standard IEEE Standard 5001 ISTO Industry organization CPU/SoC architecture agnostic standard (15 different architectures to date)Default standard use in US Automotive electronicsSupport from range of vendors in the tools communityAligned with other standards bodies - 1149.1, 1149.7, MIPI, Power.org, OCP-IP

Nexus provides a Instrumentation toolbox for SoC DebugPredefined or User defined Debug packet messages, application registers Support for levels of increasing debug functionalityEmbedded run control, Breakpoints, Instruction/data trace Memory and Register configuration and system analysis accessDefines Multiple Trace and Debug Access Methods and interfacesJTAG & Parallel AUX. Read (Trace) / Write (Configuration) Ports

Extended support for range of lower IO interface optionsHigh speed SERDES Interface protocols2 Wire/Parallel JTAG(IEEE 1149.7) Interface

Nexus 5001 packets support multi-core messages from different layers Nexus protocol is based on packets Packet may be originated by any core with Nexus instrumentation, independent of die layer subsystemNexus Messages consist of 6 bit TCODE (Transfer Code) followed by variable number of packets Messages source packet Indicates IP block of message Allows simple Multi-core Nexus support on per message basis Each message contains optional timestamp for data synchronization Vendor packets are allow user specific commands and operations

A trace message example

Nexus 5001 provides compliant access under JTAGNexus Commend Sequencing:IR Nexus_Enable command Select DR Nexus Reserved Register (IMPR, OPMR, or other)DR Nexus Message to IPMR - parse message in registerDR Nexus Message to OPMR scan out data in register

Nexus 5001 provides protocol that operates under 1149.1 JTAG standard

Nexus 5001 includes IEEE 1149.7 JTAGNexus debug over 2 wire interface provides minimum feature set

Does not impact Nexus TCODE protocol or Multi-Processor/SoC debug support

Nexus Aux (Data) In and Out ports extend 1149.7 bandwidth options for trace, calibration, memory access,

1149.7 Star configurations allow direct control/data connection for Nexus ports in different devices Address data flow with synchronization of data ports

Nexus operation is compatible with 1149.7 (T0-T5) classes Nexus protocol sits on top of 1149.7 signaling, Improved transaction performance using 1149.7 (T5) CDX/BDX functions

1149.7 + Data PortStar Configuration DATA OUTDATA INNTCK TMS TDITDOMNTAP 2TCKTMSTDITDOAUX INAUX OUTTCKTDITDOAUX INAUX OUTTCKTMSTDIAUX INAUX OUTTDITDOAUX INAUX OUTTCKTMSTDITDOAUX INAUX OUTTAP 1TAP 3

5001 Nexus enables advanced IEEE 1149.7 JTAG features Custom instrument integration CDX/BDX interfaces 2 wire JTAG interface Parallel or Serial data connection Improved speed of debug operations Streamlined JTAG Function control Full 1149.1 emulation

Increasing layers of functional enhancementsBased on compliance with 1149.1 operations

1149.7 Advanced CDX /BDX Options Background Data Transport (BDX) - utilize idle bandwidth during TAP IDLE, PAUSE_DR, and PAUSE_IR for transfersOptimized throughput of data intensive trace/calibration operationsCustom Data Transport (CDX) - implement a custom link protocol to on the fly change direction of the data transfers.Allows Nexus data transfers to be driven from target

Nexus 5001 supports SerDes SignalingThe Aurora protocol defines the physical layer, the link layer, data striping for one or more lanes, and flow controlSupports both Framed and Streaming transfer modesLinks support either a single or multiple lane channels*

Key pointsWe propose a Test compatible Debug Port implementation 1500 and Parallel data ports operate under a common framework Nexus provides infrastructure for needed 3D SoC Packet based commands simplify 3D internal connections Nexus-2012 standard adds access port options compatible with 3D SoCSERDES protocol at base layerDebug data can be transferred as very fast add/drop port Leverages the very low latencies between 3D die layers1149.7 2 wire option reduces number of through vias requiredNexus Message can be treated as JTAG Rd/Wr register 1149.7 FSM are local to the per layer Port implementationDiffering layers may have different instrumentation

This discusses work in progressThis presentation leverages concepts and work from IEEE PAR 1838 (3D Test Access Group) and IEEE 1500 (Embedded Core Test Group) it has not been approved by either group.

*TITLE PAGE*AUTHOR PAGE as required for submission*ABSTRACT PAGE as required for submission

*This is consolidated overview of the 3D Soc concept and current approach to adding test features for 3D SoC. Debug features would build on and leverage test approaches

*General overview slide on Debug challenges for 3D SoC, which are primarily related to diversity of core and instrumentation features that need to be supported on different layers and on interconnect limitations, which are driven by minimizing vias across layers*This introduces 2 of the key approaches to reuse of test features for instrumentation, leveraging 2wire JTAG implementations and reuse of 1500 pins, which define parallel test interface for passing instrumentation to layers and cores*Summarizing list of what are key debug an instrumentation features needed for 3D SoC. Pretty self explanatory. May switch this in flow with previous slide*Start to discuss how Nexus features can be applied to different layers. Focus on Base die requiring more extensive features than other die layers, since base die is external interconnect this is consistent with test assumptionsMore detail on 149.7 and Aurora serdes in subsequent slides *Detail on Nexus infrastructure at each die layer. Key point is that Nexus defined domain is largely independent of logic architecture for a given layer. Optimizations may reduce amount of Nexus logic for a given layer based on What features are required, however they are a consistent subset of Nexus operations. Interfaces are assumed to be JTAG as command and 1500 as a data port interface *Overview slide on Nexus features and background with emphasis that Nexus as a standards is aligned with other efforts that are looking at 3D SoC and their end user communities*Discussion of Nexus as a packet based instrumentation architecture, which is key to being able to work over multiple layers. Some detailed discussion of features of the packet message and example of a Nexus message for use in discussing various features of interest including source ID and timestamps. Discussion of TCODE as key element, defining standardized messages, which improves reuse One point being that many of packet field in most messages are optional/variable which allows traffic optimizations.*Example showing one method of how Nexus message is transported over JTAG protocol. The point being this is consistent with current methods of transporting instrumentation information over JTAG*Detailed discussion of 149.7 2-wire JTAG, that provides several features of interest in 3D SOC, notably reduced pin requirements and configuration in parallel/star configurations. This reduced via overhead per die. 1149.7 also allows some advanced JTAG features that allow more advanced features to be included on die layer basis. *More discussion on 1149.7 features with emphasis on compliance with 1149.1 operations (required for die test function) while providing optimizations for more effective deubg and instrumentation interfaces.*Detailed discussion of some of the more advanced features of 1149.7, as they apply to 3D SoC*General overview of Aurora protocol, being proposed as a debug/calibration data transport interface. This may be used as an add/drop interface to allow a single channel to transport data over multiple die layers. We note that a Serdes Phy may not be required due to die proximity *Summary slide touching on key points of previous slides