SoC Design Flow & Tools: SoC Testing

SoC Design Flow & Tools:SoC TestingJiun-Lang HuangGraduate Institute of Electronics EngineeringDepartment of Electrical EngineeringNational Taiwan University

Outlinel SoC Test Challengesl Test Access Mechanisml Core Test Wrapperl IEEE P1500l Test Optimizationl Analog/Mixed-Signal Testing2

SoC Test Challenges

VLSI Realization ProcessCustomer NeedsDetermine RequirementsWrite SpecificationsDesign Synthesis and VerificationTest DevelopmentFabricationManufacturing TestChips to Customers4

The Role of Testingl The role of testing is to detect whethersomething went wrong.l Diagnosis, on the other hand, tries todetermine exactly what went wrong & wherethe process has to be altered.l Test objectives– Design verification– Ensure product quality– Diagnosis & repair5

What are we after?l Design errors– Violations of design rules.– Incorrect mapping between different levels ofdesign– Incomplete or inconsistent specificationl Fabrication errors (caused by human errors)– Wrong components– Incorrect wiring– Shorts caused by improper soldering6

l Fabrication defects (caused by imperfectmanufacturing process)– Mask alignment errors– Improper doping profilesl Physical failures– Electro-migration or corrosion– Aging/Wear-out of components– Infancy failures7

Types of TestingSystem specificationsArchitecture designLogic & Circuit designPhysical designLayoutFabricationPackagingllllTransformation of customer requirementsto system specifications is audited.The design is verified against the systemspecifications to ensure its correctness.Fabricated parts are subjected tocharacterization/production testing and/orincoming inspection to detect processdefects.Failure mode analysis (FMA) is applied tofailed parts8

Characterization Testingl For design debug and verification– Usually performed on a new design prior to massproduction.– Verify the correctness of the design & determineexact device limits.– Comprehensive functional, DC and AC parametrictests are applied to a set of samples.– Use of specialized equipment• Scanning electron microscope (SEM)• Electron beam testerl Results are used for setting final spec. anddeveloping production testing program.9

Production Testingl To enforce quality requirements– Applied to every fabricated part.– The test set is short but verify all relevantspecifications, i.e., high coverage of modeledfaults.l Test cost and time are the main drivers.10

Burn-In Testingl Occurrence of potential failures can beaccelerated at elevated temperature– The main purpose is to screen out infant mortalityl Methods of burn-in– Static burn-in– Dynamic burn-in– Test during burn-in– High-voltage stress burn-in– The combinations of the above11

Bathtub Curve of IC’s Failure RatelEarly failure detection reduces cost– Burn-in to isolate infant mortality failuresInfantmortalityperiodNormallifetimeWear-outperiodFailure rate~ 20 weeks 5 – 25 yrsTime12

Incoming Inspectionl Type of tests– May be similar to or more comprehensive thanproduction testing.– May be tuned to specific applications.l May be performed by test house.l May be applied to random samples only.13

The Principle of Testing14

Test QualityNumber of acceptable partsYield Y =Number of fabricated partsNumber of detected faultsFault CoverageT=Number of all possible faultsDefect Level DL= 1-Y1-T15

Test EconomyCost of Manufacturing Testing in 2000l 0.5-1.0GHz analog instruments with1,024 digital pins:– ATE purchase price= $1.2M + 1,024 x $3,000 = $4.272M– Running cost (five-year linear depreciation)= Depreciation + Maintenance + Operation= $0.854M + $0.085M + $0.5M= $1.439M/year– Test cost (24 hour ATE operation)= $1.439M/(365 x 24 x 3,600)= 4.5 cents/second16

Technology Trend:System-on-Board to System-on-ChipPhysical componentsSystem on BoardVirtual componentsSystem on Chip17

The ImpactlSoC components are only manufactured and tested inthe final system.SoB ProcessSoC ProcessIC DesignASIC DesignCore DesignUDL DesignIC Fab.ASIC Fab.IC TestASIC TestSOB DesignSOB Fab.SOB TestSOC DesignSOC Fab.SOC Test18

Separation of Responsibilitiesl The core provider– Test pattern generation for the cores.– Core internal design-for-testability.l The core user– Test generation for the chip• Reuse of core-level test patterns.• Additional test patterns for non-core circuitry.– Chip-level design-for-testability.19

SoC Test Challengesl Distributed design & testl Test accessl Test optimization20

Distributed Design & Testl In general, the core provider develops the coretest including DfT & test patterns.l However, the core provider does not know thesystem chip environment– Which test method to use?– What type of faults to target?– What level of fault coverage?which may lead to– inadequate test quality, or– waste of resources.21

l Need a set of standardized set of deliverables.– Test methods– Test modes and protocols– Fault models and fault coverage– Test pattern data– Core-internal design-for-test– Core-internal design-for-diagnosis– Diagnostics and failure analysis information22

Test Accessl Direct access to deeply embedded cores isdifficult.l It’s not uncommon thatcore’s I/O pin count > SoC’s I/O pin countl To test each core, we need to provide– core test access, and– core isolation mechanism.23

Test OptimizationllTest access infrastructure optimization– Test quality vs. overheadConstrained test scheduling– Overall test time– Power consumption– Test access bandwidth– Available test resources– Other considerationsCore aCore bCore cCore dCore eCore gCore fTime24

A Conceptual SoC TestArchitecture

A Conceptual SoC ArchitectureSourceTAMCUTTAMSinkWrapperlllTest pattern source and sink– The source generates the test stimuli for the embedded core.– The sink compares the responses to the expected responses.Test access mechanism (TAM)– Test data transport from the test source to the CUT and fromthe CUT to the test sink.Core test wrapper– Connects the terminals of the core to the rest of the IC and theTAM.[Zorian, Marinissen, Dey – ITC98]26

A Conceptual Test ArchitectureDACmPSRAMSourcePCITAMWrapperCUTTAMSinkROMDSP27

On/Off-Chip Test Source/SinkSourceDACPCIROMmPCUTDSPSRAMSinkOn-chip Source/Sink• Closer to CUT• Less TAM area• Less dependence on ATE• BIST area overheadOff-chip Source/Sink• Bandwidth limited by pincount• More TAM area• More expensive ATESrc.DACPCIsrcmPCUTSRAMsnkSnk.ROMDSP28

Test Access Mechanism(TAM)

TAMl Function– Deliver test stimuli from the test source to the CUT.– Transport test responses from the CUT to the testsink.l TAM design involves making trade-offsamong– data transport capacity,– test time, and– TAM overhead.30

TAM Widthl Determines the test data transport bandwidth.l Considerations– A wider TAM shortens the test time, but consumesmore wiring area.– The width of the test source and sink.– Available IC pins if external test source/sink.l Constraints to meet– Test time– Area overhead31

TAM Lengthl Physical distancel Ways to reduce TAM length– On-chip test sources and/or sinks.– Sharing TAM among cores can shorten the totalTAM length.• Reduced wiring area.• Possibly reduced test concurrency.– Reusing functional hardware as TAM.• May not meet the desired test time constraint.32

TAM ImplementationslllllDirect access scheme– Immaneni, Raman – ITC90Bus-based scheme– Varma, Bhatia – ITC98, Harrod – ITC99Transparency– Beenker – D&T86, Beenker 95, Marinissen – TECS97,Ghosh et al. – ITC97, CAC98Boundary-scan based– Whetsel – ITC97, Bhattacharya – VTS98,Touba, Pouya – D&T97, ITC97Test Rail– Marinissen et al. – ITC9833

Direct Access Schemel Map all core inputs, outputs, and I/O ontopackage pins.l In test mode, the I/Os of the selected core areaccessible through a group of package pins.– Each core can be tested with its standard testprogram.l Test isolation provided and cores are testedindependently.[Immaneni, Raman – ITC90]34

Direct Access SchemelModification to user logic block.TSELTMODE>EmbeddedOutputEmbeddedBidirectionalUser InTest InPrimaryInputInput >>UserLogicBlock>>DirCtrlBi-DirEmbeddedBidirectionalControlPrimaryOutputPrimaryBidirectionalOutput35

Direct Access SchemelAn implementation exampleUINTINTMODEOutTSELTSEL1OutputPadInputPadUINTINTMODEOutTSELTSEL2UserSignalOutputPadInputPadInputPadTMODEUINTINTMODEOutTSELTSEL3Test Control Logic36

Remarksl Advantages– Embedded cores can be tested and debugged as astand-alone device.– Transition from core-level test to chip level test issimple.– A slight increase in overall package pin count anddesign complexity.l Drawbacks– Not scalable.• The complexity of control logic and test circuitry growswith the number of embedded cores.– Long test time.• Blocks are tested sequentially.37

Bus-Based TAMlUtilizing on-chip system bus or dedicated test bus fortest data transport.– Varma, Bhatia – ITC98– Harrod – ITC99Src.DACmPSRAMROMDSPSink38

Test BuslArchitecture overview.TDI/OCoreCoreTDITDOTest CtrlTest Bus[Varma, Bhatia – ITC98]39

Test BuslAn example.10 72CoreCore1248322422Input Test Bus101210Core72Core1248322472 3272Output Test Bus40

AMBA Bus-Based Testing44

Remarksl Advantages– Reusing system bus reduces TAM overhead.– Transition from core-level test to chip-level test issimple.l Drawbacks– Fixed bus width may be insufficient for some cores.– Difficult to integrate full-scanned cores.45

TransparencyDACmPSRAMSourcePCICUTSinkROMDSP46

Transparencyl Transparent path– A path from input to output which propagates datawithout information loss.l Examples– Scan chains– Arithmetic functions: + 0, x1– Embedded memories– Basic gates: AND, OR, INV, MUXl Past techniques– Beenker – D&T86, Beenker 95,Marinissen – TECS97,Ghosh et al. ITC97, CAC9847

Remarksl Advantages– Low area overheadl Drawbacks– Transport latency through cores– The desired transparency is not guaranteed.• Too much transparency – waste.• Too little transparency – TAM needed.– Non-trivial transition of core-level test to chip-leveltest.48

Test RaillIC level view.Core A116 161616Core B1Core C116 161612Core E18Core D1Core 1F412[Marinissen et al. – ITC98]51

Test RaillCore level view.CoreParallelSerialDecompressionCoreCompressionCompressedCore52

Test RaillAn example.– A: 4 scan chains.– B: BIST– C: Functional testADecomp.BComp.C53

Remarksl Advantages– FlexibleEnables integration of various core test techniques.– ScalableAllows trade-offs between area, quality, and testtime.l Drawbacks– Difficult to find optimal solution.54

Multiplexing ArchitectureCore A Core B Core C[Aerts & Marinissen – ITC98]55

Daisy Chain ArchitectureCore A Core B Core C[Aerts & Marinissen – ITC98]56

Distributed ArchitectureCore A Core B Core C[Aerts & Marinissen – ITC98]57

Remarksl Different types of TAMs may coexist on asingle chip.l Cores connected to different TAMs can betested concurrently.l Cores connected to the same TAM cannot betested concurrently.58

Core Test Wrapper

Core Test Wrapperl Function– Interface between the core and its environment.• Width adaptation– Provision of the following modes• Normal: function mode• InTest: inward-facing core test mode• ExTest: outward-facing interconnect test model Considerations– Test time.– Performance degradation.– Area overhead.60

Functional Only ConnectionScan ChainScan ChainCore AScan ChainScan ChainCore BScan ChainScan ChainCore C61

Wrapper & TAMBypassBypassBypassScan ChainScan ChainCore AScan ChainScan ChainCore BScan ChainScan ChainCore CTest ControlTest ControlTest Control62

Normal OperationBypassBypassBypassScan ChainScan ChainCore AScan ChainScan ChainCore BScan ChainScan ChainCore CTest ControlTest ControlTest Control63

InTestBypassBypassBypassScan ChainScan ChainCore AScan ChainScan ChainCore BScan ChainScan ChainCore CTest ControlTest ControlTest Control64

ExTestBypassBypassBypassScan ChainScan ChainCore AScan ChainScan ChainCore BScan ChainScan ChainCore CTest ControlTest ControlTest Control65

BypassBypassBypassBypassScan ChainScan ChainCore AScan ChainScan ChainCore BScan ChainScan ChainCore CTest ControlTest ControlTest Control66

IEEE P1500Standard for Embedded Core Test (SECT)

Core-Based Testl The core provider delivers– the core design itself, and– a set of tests for the core.l The core user assembles a chip-level testfrom– the pre-defined tests for the various cores, and– additional tests for non-core circuitry.l A test as described above, in which cores aretested as stand-alone units, is called a “corebasedtest.”68

P1500 OverviewllIEEE P1500 SECT is a standard under developmentthat aims at improving– ease of reuse, and– facilitating interoperabilitywith respect to the test of core-based ICs, especiallywhen they are from different sources.Main components– Standardized, scalable core test wrapper– Core test Information Model• Core Test Language (CTL)– Two Compliance levels• IEEE 1500 Unwrapped• IEEE 1500 Wrapped69

A System Chip with P1500 Wrapped Cores70

P1500 Wrapperl Modes– Transparent functional mode– Inward-facing for core-internal tests (InTest)– Outward-facing for core-external tests (ExTest)l Interface– One “Single-bit TAM plug” is mandatory.– Optional “Multi-bit TAM plug.”– Optional “width adaptation” for TAM plugs.– Optional modes similar to JTAG’s “preload” and“clamp.”71

The P1500 Wrapper Architecture72

The P1500 Wrapper Boundary CellllCell modes– Normal, Inward facing, Outward facing, SafeCell events– Shift, Capture, Apply, Update, Transfer73

P1500 Wrapper Parametersl Bandwidth– Number and/or width of WPI-WPO pairs.l Instructions– Optional instructions– User-defined instructions– OpCodes of instructionsel WBR functionality– Shared or dedicated wrapper cells– Shift-only or Shift + Update cells– Storage capacity (one or more bits)– Ripple protection (w/ Update register or gate)– “Safe State” output values74

Test Optimization

Problem Statementl Given the test related information of eachcore, e.g., test pattern, I/O, etc., minimize thetest cost.l Main test cost components– DfT: Area overhead, performance degradation– Test development– Manufacturing test: test timel Other considerations– Power dissipation– Place & route constraints76

Test Scheduling Techniquesl Co-optimization of all HW/SW parameters istoo expensive.l Most researches deal with a subset of theparameters.l Test scheduling approaches– Tree growing [Jone et al. DAC89, Muresan et al., ITC00]– List scheduling [Muresan et al. VTS00]– ILP formulation [Chakrabarty et al. ICCAD99, Nourani etal. ITC00]– Simulated annealing [Larsson et al. ICCAD01]77

Tree Growing Approaches[Jone et al. DAC89, Muresan et al., ITC00]l Test time minimization under powerconstraints.l The test scheduling information is embeddedin he tree structure.l Tree growing constraints (along a path fromroot to leaf)– Test resources– Test length– Power constraint78

t 1t 8 t 3 t 5 t g1t 7t 4 t 2 t g2t 6t g3t 1t 8 t 3 t 5 t g1t 7t 4 t 2 t g2t 9t g379

ILP Formulation[Chakrabarty et al. ICCAD99, Nourani et al. ITC00]lThe test optimization problem is described as:MinimizeAx + Bysubject toCx + Dy ≥ Ex ≥ 0y ≥ 0where– A and B are cost vectors,– C and D are constraint matrices,– E is a column vector of constants,– x is a vector of integer variables, and– y is a vector of real variables.80