SoC层次化测试方法

D E S I G N -T O -S I L I C O NW H I T E P A P E RDIVIDE AND CONQUER:HIERARCHICAL DFT FOR SOC DESIGNSRICK FISETTE, MENTOR GRAPHICSINTRODUCTIONLarge System on Chip (SoC) designs present many challenges to all design disciplines, including design-for-test (DFT). By taking a divide-and-conquer approach to test, significant savings in tool runtime and memoryconsumption can be realized. This whitepaper describes the basic components of a hierarchical DFTmethodology, the benefits that it provides, and the tool automation that is available through Mentor’s Tessenttool suite.WHAT IS HIERARCHICAL DFT?For large SoC devices, the front-end and physical design practices are typically performed at a core level.Whether it’s called a core, block, tile, macro, or module they all refer to the level of hierarchy at which designtasks are completed. These completed cores are then integrated into the SoC. Hierarchical DFT refers to thepractice of implementing all DFT with respect to these same core hierarchical boundaries. The test patternsfor these cores are then applied individually or in groups from the SoC level.With hierarchical DFT, once a core design is complete it means it’s DFT is complete as well, and that it includesa set of patterns that can be used to test the core regardless of how it gets integrated into an SoC. Cores canbe tested individually, in groups, or all together; whatever best suits the test plan and available pin resourcesin the SoC. Interconnect between cores and chip-level glue logic are then tested separately and the coveragefor all test modes is combined into a single comprehensive coverage report.WHY ADOPT A HIERARCHICAL DFT METHODOLOGY?A hierarchical DFT methodology solves many issues that are often encountered with the insertion of DFTstructures and running ATPG for large SoCs. Some of the most common and compelling problems that can bemitigated with hierarchical DFT include the following:LONG ATPG RUNTIMESAs netlist sizes grow so does the runtime for scan ATPG. It is not unusual for pattern generation to take manyhours or even many days depending on the fault model and design size.LARGE MEMORY FOOTPRINTThe memory required for loading an entire SoC design into the workstation for ATPG can require 10s of Gb, ifnot more than 100 Gb. This severely limits how many machines can be used, if indeed, any machines have therequired amount of memory. Even if those machines are available then there is often competition with otherdesign disciplines (e.g. physical design/verification) for using these resources.DFT IN THE CRITICAL PATH TO TAPEOUTTraditional DFT methodologies require that the full-chip netlist be finalized before production test patternscan be generated. This requirement places DFT squarely in the critical path to tapeout. To further complicatethis situation any late (even minor) changes made prior to tapeout to address functional bugs will meanthrowing away any existing patterns and restarting that process, potentially delaying tapeout.LIMITED CHIP PINS FOR DFTIt is common to have very large SoCs that have relatively few chip-level pins available for DFT purposes.Especially with core-based designs where the number of cores can far exceed the number of chip-level pins.One potential solution is to concatenate chains from one core to another, but this can result in very long shiftcycles and create dependencies between cores that make the cores harder to reuse. It also still requires thatthe full-chip netlist be completed before patterns can be generated. The same can be said for any approachthat puts compression logic at the chip-level in order to drive multiple cores with many scan chains. Thisarrangement also has a negative impact on compression logic because of the resulting very high chain-to-channel ratio.OVERVIEW OF THE HIERARCHICAL DFT FLOWThe best way to address the challenges of testing large SoCs is to take a divide and conquer approach thatcuts the task down into smaller, more manageable pieces. The following high-level description highlights thekey DFT tasks required for hierarchical DFT and how they fit into the overall flow.CORE-LEVEL WRAPPER CHAIN INSERTIONThe core is the least common denominator in a hierarchical flow and is the lowest hierarchical level at whichtest patterns are applied. What makes testing an individual core possible, regardless of how it’s integrated intoa higher-level design, is a wrapper chain. Much like a boundary scan chain, the core wrapper chain providesguaranteed control for all inputs of a core and guaranteed observation of the outputs. As long as you canaccess the wrapper chain you can test that core without compromising test coverage.The wrapper chain is a key concept and is the foundation upon which the hierarchical DFT methodology isbuilt. When testing the contents of the core, otherwise known as Internal mode, the wrapper chain isconfigured to launch values into the core and capture responses coming out, as illustrated in Figure 1.The External mode of the core reconfigures the wrapper chain to launch values from the outputs to test chip-level glue logic and interconnect while inputs capture the responses, as shown in Figure 2.The wrapper chain therefore delineates between the logic tested in Internal mode and the logic tested inExternal mode. In addition to the wrapper chains, it is also necessary to insert all scan chains, compressionlogic, and test control logic to make it “DFT complete.”CORE-LEVEL RETARGETABLE PATTERN GENERATIONThe benefit of running ATPG at the core level for Internal mode is significantly reduced runtime and memoryfootprint compared to running ATPG at the chip level. Runtime savings are design dependent, but it is notunusual to see a 5x-10x reduction by running ATPG at the core level. Memory footprint savings of a similarmagnitude are also possible. Once the core is “DFT complete,” it is possible to generate a set of scan patternsFigure 1: Wrapper chain configuration for Internal testmode. Figure 2: Wrapper chain configuration for External test mode.at the core level that can subsequently be retargeted to the chip level. The key assumption is that the core iswrapped. Any other core-based DFT methodology that does not include wrapper chains cannot produceretargetable patterns without seriously compromising test coverage at the core boundaries and chip-levelglue logic. Once core-level patterns have been generated, they should also be verified at the core-level muchthe same as functional and physical verification are done. The outputs from this step in the flow are a set ofretargetable patterns and a fault list containing all the coverage information for that pattern set.GRAYBOX GENERATION FOR COREGraybox models are intended to reduce thememory footprint for External mode by as much as10x or more. As previously described, Externalmode only targets logic outside of a core’s wrapperchain. Some of that logic still resides within theboundary of the core. Since none of the logic insidethe wrapper is tested in External mode there’s noneed to include it in the core netlist for that mode.The graybox netlist of the core removes all of thelogic tested in Internal mode and only includeswhat’s needed for External mode, as shown inFigure 3. This is another key hierarchical DFTconcept and makes it possible to test an entire SoCdesign without ever having to load the full chipnetlist at any time.The amount of core netlist reduction madepossible by using a graybox netlist varies widely based on the design. When measured by the number design instances in the graybox netlistcompared to the full netlist, it’s typical to have lessthan 10% or a reduction of 10X. Table 1 shows a few examples graybox netlist reduction.CHIP-LEVEL RETARGETING OF SCAN PATTERNRetargeting previously generated core level patterns to the chip level is where the biggest ATPG runtimesavings are realized. Large SoC designs may require days to generate patterns from the chip level, butretargeting patterns reduces the chip-level effort to minutes. There are many variations of how a chip-levelarchitecture can configure cores to be tested in Internal mode. It could be one core at a time, all corestogether or a group of cores at a time. For each grouping of cores to be tested together, you load in either agraybox or blackbox netlist of those cores. The full netlist is not necessary because the retargeting starts atthe core boundary and works its way out to chip-level pins. First, it performs the mapping of Internal modescan patterns from the core pins up to the chip-level pins. In addition it must also merge the pattern sets ofmultiple cores so that they can be simultaneously applied. Retargeting reduces the memory footprint of theFigure 3: The graybox netlist of a core only includes the logicneeded for External mode test.loaded design and eliminates the need to regenerate patterns at the chip level to test the cores. A single set ofretargeted patterns is saved for each Internal mode configuration required. The example in Figure 4 showshow Internal mode 1 groups Cores 1 and 2 together whose patterns are retargeted and merged together.Cores 3 and 4 are retargeted and merged together in Internal mode 2.EXTERNAL MODE PATTERN GENERATIONOnce all cores have been tested in Internal mode, all that’sleft is to test the interconnect and glue logic between thecores and calculate the final chip-level test coveragenumber. First, the chip-level netlist is loaded along with thegraybox of each core. The External mode configurationaccesses all the wrapper chains of the cores as well as anychip-level scan chains and ATPG is run, as shown in Figure 5.Once these patterns are completed, all of the interconnectand glue logic has been tested, which, on top of all theInternal mode configurations, means the entire chip hasbeen tested. In order to calculate the final test coverage ofthe entire chip, the fault lists saved from each core’s Internalmode pattern set are merged into the External mode faultlist. The tool then calculates the combined coverage of theInternal modes and External mode. The final pattern set that is delivered to the ATE consists of the patterns for External mode and as many retargeted Internal modepattern sets as there are Internal mode configurations.COMPONENTS OF A HIERARCHICAL DFT SOLUTIONHierarchical DFT is not a single tool feature but rather a methodology that requires changes in how DFT isinserted in cores, how patterns get generated and how those patterns get applied. The following sectionsprovide more details regarding the DFT tool automation in the Tessent tool suite that support a hierarchicalmethodology.WRAPPER CHAINS/CORE ISOLATIONWrapper chain identification and insertion is a fundamental step in preparing cores for hierarchical test. Thereare two different types of wrapper cells supported: dedicated and shared . A dedicated wrapper cell is a newcell that is added to the design for test purposes that provides the control and observation on I/Os that isFigure 4:Internal test modes at the chip level.Figure 5: External mode tests the interconnect and glue logic between cores.required for hierarchical DFT. However, dedicated wrapper cells are not usually an ideal solution because theyadd area to the design and add delay to the functional path. This added area and delay problem has been abarrier to wider adoption of hierarchical DFT.Tessent Scan gets around this problem byidentifying and stitching shared wrappercells by default. A shared wrapper cell is anexisting functional register that can alsoserve to isolate a primary input/output fortest purposes. It therefore is shared forfunctional as well as DFT purposes. This isthe ideal solution for wrapping a corebecause there is no additional logicrequired for test purpose and has no impacton the functional path.Any input/output that is not immediatelyregistered at the core boundary requiresadditional analysis to identify which existingfunctional flops can be used as wrappercells. This identification can get complicatedquickly because the tool must account forall fanouts to registration points as well asinternal feedback paths that drive logicclouds interacting with the I/Os. All of these situations must be identified and handled by the wrapper insertion process. The resulting wrapperchains and scan chains might look like Figure 6. All the logic inside these wrapper chains is tested as part ofInternal mode while any logic outside the wrapper chains will be detected in External mode. Notice also thatthe input wrapper chains, core chains and output chains each have their own scan shift enable signal. That isnecessary in order to achieve at-speed test coverage at the boundary of the core.Take for example a typical at-speed testscenario (launch off capture) as shownin Figure 7. To detect the fault at theinput of the buffer, you need a launchflop and a capture flop, but you alsoneed another flop to provide atransition value to the launch flop.When operating at the boundary of awrapped core, you do not have a flop toprovide that transition value, as shown in Figure 8. Instead, this is handled by holding the input wrapperchain in shift mode even during the capture cycle. Thisallows the scan shift path to provide the transitionvalue instead of the D input of the launch flop, asshown in Figure 9.Figure 6: Shared wrapper chains.Figure 7: At-speed testing inside the core.Figure 8: At-speed testing at the core boundary.At the same time, the values on the Dinput of the core flops and the outputwrapper cells must be captured. Internaltest mode is defined by the fact thatinput wrapper chains are constrained inshift mode so they can launch into thecore while the rest of the registers in thedesign can capture. Conversely, Externalmode requires that the output wrapperchains be held in shift mode in order tolaunch at-speed to chip-level logic whilethe other registers can capture. Thismeans you need separate control of theinput wrapper scan_enable and theoutput wrapper scan_enable to successfully operate Internal andExternal modes, respectively. Theidentification of these various shared wrapper cell scenarios, as well as the insertion of the wrapper chaincontrol elements, are automatically handled by Tessent Scan.GRAYBOX NETLIST GENERATIONThe purpose of the graybox representation of a core is to reduce the memory footprint otherwise required byDFT tools to load a full netlist. It can be used in place of the full core netlist in any situation in which only thelogic at the boundary of the core is needed. Typically, that means External mode but may also apply to scanpattern retargeting situations. Figure 10 illustrates the comparison between a full core netlist and what isretained for a graybox core.What needs to be included in the graybox is primarily the wrapper chains and any combinational logic thatsits between the wrapper chains and the primary inputs/outputs of the core. This is very similar to an interfacelogic model that might be used for static timing analysis (STA) in which the path between an I/O port and aregister must be analyzed. What is not included in an STA model would be internal feedback paths that alsodrive clouds of logic interfacing to the I/Os. There may also be some control logic needed to put the core intoits test mode or possibly needed by other cores or chip-level logic. The typical reduction factor from the fullnetlist size to the graybox is in the range of 10x to 20x, with some designs outside that range. This reduction isdependent on how much logic must be traced through in order to identify shared wrapper cells. TessentTestKompress includes the ability to generate the graybox netlist.Figure 9: At-speed testing at the boundary of a wrapped core.Figure 10: Complete core netlist compared to graybox netlist.SCAN PATTERN RETARGETINGMapping patterns from the boundary of a core to chip-level pins is only a small part of the overall retargetingtask. One must also take into account any inversions or added pipeline stages at the chip level and modify thepatterns accordingly. If the chip architecture is such that multiple non-identical cores can be accessed andtested simultaneously, the pattern sets of those cores must be merged. A critical part of the retargetingprocess is the design rule check (DRC) that verifies the chip’s setup conditions match the conditions duringcore-level pattern generation. Without this check in place to flag setup problems early, it falls to the user todebug the problem by simulating the faulty retargeted patterns in a chip-level simulation environment, amuch longer and difficult debug process.Clock control and the placement of that control logic in the design hierarchy is a major consideration whenimplementing pattern retargeting. The ideal solution is to have clock control logic that is programmable byscan data located inside the core. Because the programming of the capture clock on a per pattern basis is partof the scan data, clocking information is completely self-contained in the pattern set and is not dependent onexternal clock sources. This makes it possible to merge the pattern sets of multiple cores without creatingclocking conflicts. Once clock sources are located outside the core (and are presumably shared by other cores)you can only merge patterns for one clock at a time. Otherwise the cores being merged may require differentcommonly sourced clocks for any given pattern, which would result in capture errors in one or both of thecores. While still retargetable, the resulting patterns are less efficient than they would be if the clock controlwere inside the core. Tessent TestKompress includes all of the pattern retargeting functionality described. BENEFITS OF HIERARCHICAL DFT REALIZED IN SILICONAny change in methodology means additional effort, or at least different effort, that must be justified. In thecase of hierarchical DFT, the most notable additional effort required is the wrapper insertion. A secondaddition is a change in clock control implementation for retargeting, if it is not already located inside thecores. This additional up-front effort, though, pays dividends throughout the design process and even onthe ATE.Users who are employing this methodology with pattern retargeting are seeing ATPG runtimes reduced by 5xor more. As important as that reduction is, reduced cumulative time for hierarchical ATPG does not accuratelyquantify the complete benefit to runtime challenges. What’s more important is when in the design scheduleATPG occurs. With retargeting, the patterns for all the cores can be done far in advance of the completion ofthe chip-level netlist. That means as soon as the chip netlist is complete, the core-level patterns already existand can be retargeted in just minutes instead of taking days to generate patterns from the chip level at acritical point in the schedule. If there is a late ECO to one of the cores, then you only need to rerun ATPG forthat one core and then retarget. Generating scan patterns is no longer a gating item as you get close totapeout. The verification of those patterns is also considerably simplified because it is done primarily at thecore level at the time the core is completed.The memory footprint reduction is highly design-dependent, but it’s not unusual to see a 10x reduction.Whatever memory is required for your largest core represents the most memory you’ll need for the entirechip. The chip-level netlist for External mode is typically very small because it comprises mostly grayboxmodels, which are usually 1-5% the size of the full core netlist. There are a couple of aspects to why thismemory reduction is advantageous. It opens up quite a few more multi-processor machines to work on ATPGthat would otherwise have all their memory consumed before all the CPUs can be used. This means you cantake better advantage of distributed and multi-threaded processing without running into memory limitations.You also will no longer have to compete for the biggest machines with other design disciplines like physicaldesign and physical verification, which usually require lots of memory.TECH12050-w MGC 05-14F o r t h e l a t e s t p r o d u c t i n f o r m a t i o n , c a l l u s o r v i s i t :©2014 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and may be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies. In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks mentioned in this document are the trademarks of their respective owners.A less intuitive advantage to hierarchical DFT is that pattern count (and consequently test time) is oftenreduced by as much as 2x. This can be attributed to the fact that the limited scan channel resources no longerneed to be divided across the entire chip. Instead, by breaking up the testing into smaller pieces, all of thoseresources can be dedicated to testing the individual cores thereby improving efficiency.Diagnosis also benefits from hierarchical DFT with pattern retargeting capabilities. Being able to map chipfailures back to the core level allows you to run diagnosis at the core level rather than the full chip. Just likeATPG, the runtime is reduced dramatically.CONCLUSIONWith some up-front design effort and planning, the biggest challenges of testing large SoCs can be addressedwith a hierarchical DFT methodology. Implementation of the methodology is greatly assisted by theautomation now available in the Tessent tool suite for the most important design tasks.。