David Lavo

1. David Lavo A Good Excuse for Reuse:“Open” TAP Controller Design

2. Purpose • TAP controllers are becoming a delivery and control mechanism for DFT • Reuse and integration of DFT are hampered by incompatible TAP designs • RTL standardization of the TAP is facilitated by the IEEE Standard • Extending the core organization to add-on DFT increases reuse and productivity

3. Outline • TAP controllers and board test • TAP controllers and DFT • A particular problem • The benefits of organization • “Open TAP” architecture • Automated TAP configuration • A discussion of reuse and its potential

4. TAP Controllers and IEEE 1149.1 • 1149.1 was established primarily for board test • Targets shorts and opens in board interconnect • Eliminates probe & bed-of-nails testing • All tests conducted through the TAP controller: • Shifting in and decoding instructions • Shifting, capturing and driving pin data • Disabling pad outputs (high-z) • Polling chips on-board, internal tests, etc.

5. IEEE 1149.1 Components • Instructions and data scanned into TDI, out TDO • State of the controller is determined by TMS • TCK clocks the FSM and other test components • TRST is an asynchronous reset

6. The TAP Controller Grows Up (and becomes popular) • On-board test control is too tempting for test engineers to leave alone • The TAP controller is evolving into a platform for all sorts of test purposes: • Logic and memory BIST control • Internal scan chain control • Running and modifying internal tests • Clock generation and control • Debug and diagnosis facilities

7. Every TAP for Itself • Basic TAP functions are defined by 1149.1, but: • Implementations vary widely • Many different ways of adding functionality • TAP controllers created for a single purpose or chip are difficult to re-use, extend and modify • Re-designing core components is inefficient and error-prone • Third-party DFT often comes with its own TAP

8. Third-Party BIST Controller(s) Third-Party TAP Controller with BIST Control Reused TAP ControllerwithScan Control Internal Scan Chains One (Common) Scenario Undefined Interface to TAP State and Logic Incompatible Boundary Control Signals Incompatible Boundary Control Signals TAP Merge? New JTAGPads Scan WrapperControl ClockControl

9. Flat Architecture: module TAP(…); FSM Misc Logic Instruction Decode Instruction Register Instruction Decode Bypass Register Glue Logic Register MUXing Instruction Decode endmodule // TAP Order From Chaos • There are many different ways of organizing a TAP controller design in RTL code • The RTL architecture can make a big difference when re-using and extending TAP designs

10. Hybrid Architecture: module TAP(…); Bypass Register Instruction Decode Glue Logic Instruction Decode endmodule // TAP Order From Chaos • There are many different ways of organizing a TAP controller design in RTL code • The RTL architecture can make a big difference when re-using and extending TAP designs module FSM(…) module Inst_Reg(…) module Reg_MUX(…)

11. Ideal TAP RTL • Should be easy to understand • Should conform closely to 1149.1 documentation • TAP core should be complete and compliant • TAP core should have only essential logic • Should be extendable for different types of boundary registers and other specializations • Should have parameterized values for register lengths, opcode values, state encoding, etc.

12. Object-Oriented RTL • Principle: Build up complexity from well-defined, inviolable objects • Interface over implementation • A TAP has core objects and interfaces defined by an IEEE Standard • A methodology for extension: • Build from core signals and interfaces • Extensions should themselves be modular and object-oriented • Extensions should be “well-behaved”

13. The “MPH” Model

14. The “MPH” Model (cont)

15. { ShiftDR, ClockDR, UpdateDR } TCK { ShiftIR, ClockIR, UpdateIR } TMS SelectIR TRST_N EnableTDO TAP Controller Core Components Finite StateMachine(FSM)

16. TAP FSM Signals

17. { ShiftIR, ClockIR, UpdateIR } Instruction[N-1:0] SelectBoundary SelectBypass { ShiftDR, ClockDR, UpdateDR } TCK TMS TRST_N TDI breg_sout TDO EnableTDO TAP Controller Core Components Bypass Register Finite StateMachine(FSM) Instruction Register StandardInstructionDecode RegisterSelect (MUX)

18. { ShiftDR, ClockDR, UpdateDR } TCK TMS TRST_N idcode_sel TDI TDO breg_sout Adding an IDCODE Register Bypass Register IDCODE Register Finite StateMachine(FSM) Instruction Register IDCODEInstructionDecode StandardInstructionDecode Expanded RegisterSelect (MUX) RegisterSelect (MUX)

19. BBC TCK TMS BIST Control TRST_N TDI breg_sout Boundary Control {ShDR, ClkDR, UpdDR } { ShiftDR, ClockDR, UpdateDR } → { BIST Breg Ctl }  { Custom Control Signals } →{ User Breg Ctl } { ShiftDR, ClockDR, UpdateDR } User BReg Control Bypass Register Finite StateMachine(FSM) Instruction Register StandardInstructionDecode RegisterSelect (MUX) TDO

20. Handling Resource Conflicts • Sharing common resources can lead to conflicts • Especially true at Register Select/MUX, Boundary Register • At Register Select: • Multiple selects indicates error, select Bypass Register • At Boundary Register: • Allow multiple controllers, optionally check for simultaneous accesses • Well-behaved and well-designed modules shouldn’t compete

21. Benefits for the Design Organization • The modular nature of the “Open TAP” makes configuration and support much easier • Highly-tested core components • Standard model for development • Much improved reuse of extensions • The designer benefits as well • Well-organized RTL • Reuse of DFT, support tools, documentation • “Plug-and-play” configuration

22. Web-Based TAP Configuration

23. The TAP Controller as Reuse Ideal • A nearly-ubiquitous chip component • A core set of functions well-defined by a Standard • Some specialization is almost always required or desired • Relatively low performance requirements!

24. The TAP Controller as DFT OS (?) • TAP controller sits at the tool interface to DFT • Test IP could be delivered with its interface: • Core and submodule test • Logic and memory BIST • Analog test • Different types of boundary registers and scan flops • Test and diagnosis • A common TAP base enables mixing of third-party DFT and other test IP

25. Is Cooperation Possible? • It is not easy to get designers to agree on a design, even for TAP controllers • However: • Most TAP designs are still relatively simple • The core interfaces are key, not implementation • The benefits may outweigh the inconvenience • Partial adherence - modularity - is better than nothing

26. Conclusions • Everyone has his or her own use for a TAP controller • Ad-hoc RTL designs are difficult to re-use, extend, and debug • Simple organization of RTL creates opportunities for a high level of reuse • Delivery of DFT becomes standardized • Bottom line: • Increased productivity for test engineer • Increased productivity for test support person • Increased testability for designs