Part of the  

Chip Design Magazine

  Network

About  |  Contact

Posts Tagged ‘DFT’

Cadence Launches New Verification Solutions

Tuesday, March 14th, 2017

Gabe Moretti, Senior Editor

During this year’s DVCon U.S. Cadence introduced two new verification solutions: the Xcelium Parallel Simulator and the Protium S1 FPGA-Based Prototyping Platform, which incorporates innovative implementation algorithms to boost engineering productivity.

Xcelium Parallel Simulator

.The new simulation engine is based on innovative multi-core parallel computing technology, enabling systems-on-chip (SoCs) to get to market faster. On average, customers can achieve 2X improved single-core performance and more than 5X improved multi-core performance versus previous generation Cadence simulators. The Xcelium simulator is production proven, having been deployed to early adopters across mobile, graphics, server, consumer, internet of things (IoT) and automotive projects.

The Xcelium simulator offers the following benefits aimed at accelerating system development:

  • Multi-core simulation improves runtime while also reducing project schedules: The third generation Xcelium simulator is built on the technology acquired from Rocketick. It speeds runtime by an average of 3X for register-transfer level (RTL) design simulation, 5X for gate-level simulation and 10X for parallel design for test (DFT) simulation, potentially saving weeks to months on project schedules.
  • Broad applicability: The simulator supports modern design styles and IEEE standards, enabling engineers to realize performance gains without recoding.
  • Easy to use: The simulator’s compilation and elaboration flow assigns the design and verification testbench code to the ideal engines and automatically selects the optimal number of cores for fast execution speed.
  • Incorporates several new patent-pending technologies to improve productivity: New features that speed overall SoC verification time include SystemVerilog testbench coverage for faster verification closure and parallel multi-core build.

“Verification is often the primary cost and schedule challenge associated with getting new, high-quality products to market,” said Dr. Anirudh Devgan, senior vice president and general manager of the Digital & Signoff Group and the System & Verification Group at Cadence. “The Xcelium simulator combined with JasperGold Apps, the Palladium Z1 Enterprise Emulation Platform and the Protium S1 FPGA-Based Prototyping Platform offer customers the strongest verification suite on the market”

The new Xcelium simulator further extends the innovation within the Cadence Verification Suite and supports the company’s System Design Enablement (SDE) strategy, which enables system and semiconductor companies to create complete, differentiated end products more efficiently. The Verification Suite is comprised of best-in-class core engines, verification fabric technologies and solutions that increase design quality and throughput, fulfilling verification requirements for a wide variety of applications and vertical segments.

Protium S1

The Protium S1 platform provides front-end congruency with the Cadence Palladium Z1 Enterprise Emulation Platform. BY using Xilinx Virtex UltraScale FPGA technology, the new Cadence platform features 6X higher design capacity and an average 2X performance improvement over the previous generation platform. The Protium S1 platform has already been deployed by early adopters in the networking, consumer and storage markets.

Protium S1 is fully compatible with the Palladium Z1 emulator

To increase designer productivity, the Protium S1 platform offers the following benefits:

  • Ultra-fast prototype bring-up: The platform’s advanced memory modeling and implementation capabilities allow designers to reduce prototype bring-up from months to days, thus enabling them to start firmware development much earlier.
  • Ease of use and adoption: The platform shares a common compile flow with the Palladium Z1 platform, which enables up to 80 percent re-use of the existing verification environment and provides front-end congruency between the two platforms.
  • Innovative software debug capabilities: The platform offers firmware and software productivity-enhancing features including memory backdoor access, waveforms across partitions, force and release, and runtime clock control.

“The rising need for early software development with reduced overall project schedules has been the key driver for the delivery of more advanced emulation and FPGA-based prototyping platforms,” said Dr. Anirudh Devgan, senior vice president and general manager of the Digital & Signoff Group and the System & Verification Group at Cadence. “The Protium S1 platform offers software development teams the required hardware and software components, a fully integrated implementation flow with fast bring-up and advanced debug capabilities so they can deliver the most compelling end products, months earlier.”

The Protium S1 platform further extends the innovation within the Cadence Verification Suite and supports the company’s System Design Enablement (SDE) strategy, which enables system and semiconductor companies to create complete, differentiated end products more efficiently. The Verification Suite is comprised of best-in-class core engines, verification fabric technologies and solutions that increase design quality and throughput, fulfilling verification requirements for a wide variety of applications and vertical segments.

Blog Review – Monday, September 26, 2016

Monday, September 26th, 2016

Robotic surgery reaches new levels, and ARM raises safety critical benchmarks with Cortex-R52, supported by Synopsys tools. There is a preview of Intel’s DVCon Europe’s presentation for virtual systems and DTF proves to be a classic rulebook.

Described as a ‘fairy tale’ by the grateful recipient, surgeon using a joystick to remove a membrane from the patient’s eye could sound like an Orwellian nightmare, but Tom Smithyman, ANSYS, has collected his favorite blogs, one of which is on the BBC website and explains how surgeons at the John Radcliffe Hospital performed robotic-assisted eye surgery.

You may have heard that ARM launched its Cortex-R52, ARMv8-R processor and hot on the heels of the announcement, Synopsys has announced design support for safety critical automotive, healthcare and industrial applications, reports Phil Dworsky, Synopsys.

Still with ARM, Rob Coombs, explains how mobile security architecture can be adapted for IoT applications, with copious graphics and an introduction to TrustZone for ARMv8-M on microcontrollers.

The more things change, the more they stay the same, can be the conclusion reading a blog by Stephen Pateras, Mentor Graphics, who shows that DFT-related rules hold true now, as they did in the 1980s.

Is a coup is in the offing at the IEEE? John Blyler Systems Design Engineering, makes sure of the facts by checking with the current President-Elect, Karen Bartleson about the proposed amendment to the IEEE constitution ahead of next month’s vote.

DVCon Europe 2016 takes place in the German city of Munich next month and Jakob Engblorn, Intel, will present a paper there based on integrating SystemC models into a virtual system. For those who can’t attend in person, his blog previews his technical and informative paper.

Caroline Hayes, Senior Editor

Formal, Logic Simulation, hardware emulation/acceleration. Benefits and Limitations

Wednesday, July 27th, 2016

Stephen Bailey, Director of Emerging Technologies, Mentor Graphics

Verification and Validation are key terms used and have the following differentiation:  Verification (specifically, hardware verification) ensures the design matches R&D’s functional specification for a module, block, subsystem or system. Validation ensures the design meets the market requirements, that it will function correctly within its intended usage.

Software-based simulation remains the workhorse for functional design verification. Its advantages in this space include:

-          Cost:  SW simulators run on standard compute servers.

-          Speed of compile & turn-around-time (TAT):  When verifying the functionality of modules and blocks early in the design project, software simulation has the fastest turn-around-time for recompiling and re-running a simulation.

-          Debug productivity:  SW simulation is very flexible and powerful in debug. If a bug requires interactive debugging (perhaps due to a potential UVM testbench issue with dynamic – stack and heap memory based – objects), users can debug it efficiently & effectively in simulation. Users have very fine level controllability of the simulation – the ability to stop/pause at any time, the ability to dynamically change values of registers, signals, and UVM dynamic objects.

-          Verification environment capabilities: Because it is software simulation, a verification environment can easily be created that peeks and pokes into any corner of the DUT. Stimulus, including traffic generation / irritators can be tightly orchestrated to inject stimulus at cycle accuracy.

-          Simulation’s broad and powerful verification and debug capabilities are why it remains the preferred engine for module and block verification (the functional specification & implementation at the “component” level).

If software-based simulation is so wonderful, then why would anyone use anything else?  Simulation’s biggest negative is performance, especially when combined with capacity (very large, as well as complex designs). Performance, getting verification done faster, is why all the other engines are used. Historically, the hardware acceleration engines (emulation and FPGA-based prototyping) were employed latish in the project cycle when validation of the full chip in its expected environment was the objective. However, both formal and hardware acceleration are now being used for verification as well. Let’s continue with the verification objective by first exploring the advantages and disadvantages of formal engines.

-          Formal’s number one advantage is its comprehensive nature. When provided a set of properties, a formal engine can exhaustively (for all of time) or for a, typically, broad but bounded number of clock cycles, verify that the design will not violate the property(ies). The prototypical example is verifying the functionality of a 32-bit wide multiplier. In simulation, it would take far too many years to exhaustively validate every possible legal multiplicand and multiplier inputs against the expected and actual product for it to be feasible. Formal can do it in minutes to hours.

-          At one point, a negative for formal was that it took a PhD to define the properties and run the tool. Over the past decade, formal has come a long way in usability. Today, formal-based verification applications package properties for specific verification objectives with the application. The user simply specifies the design to verify and, if needed, provides additional data that they should already have available; the tool does the rest. There are two great examples of this approach to automating verification with formal technology:

  • CDC (Clock Domain Crossing) Verification:  CDC verification uses the formal engine to identify clock domain crossings and to assess whether the (right) synchronization logic is present. It can also create metastability models for use with simulation to ensure no metastability across the clock domain boundary is propagated through the design. (This is a level of detail that RTL design and simulation abstract away. The metastability models add that level of detail back to the simulation at the RTL instead of waiting for and then running extremely long full-timing, gate-level simulations.)
  • Coverage Closure:  During the course of verification, formal, simulation and hardware accelerated verification will generate functional and code coverage data. Most organizations require full (or nearly 100%) coverage completion before signing-off the RTL. But, today’s designs contain highly reusable blocks that are also very configurable. Depending on the configuration, functionality may or may not be included in the design. If it isn’t included, then coverage related to that functionality will never be closed. Formal engines analyze the design, in its actual configuration(s) that apply, and does a reachability analysis for any code or (synthesizable) functional coverage point that has not yet been covered. If it can be reached, the formal tool will provide an example waveform to guide development of a test to achieve coverage. If it cannot be reached, the manager has a very high-level of certainty to approving a waiver for that coverage point.

-          With comprehensibility being its #1 advantage, why doesn’t everyone use and depend fully on formal verification:

  • The most basic shortcoming of formal is that you cannot simulate or emulate the design’s dynamic behavior. At its core, formal simply compares one specification (the RTL design) against another (a set of properties written by the user or incorporated into an automated application or VIP). Both are static specifications. Human beings need to witness dynamic behavior to ensure the functionality meets marketing or functional requirements. There remains no substitute for “visualizing” the dynamic behavior to avoid the GIGO (Garbage-In, Garbage-Out) problem. That is, the quality of your formal verification is directly proportional to the quality (and completeness) of your set of properties. For this reason, formal verification will always be a secondary verification engine, albeit one whose value rises year after year.
  • The second constraint on broader use of formal verification is capacity or, in the vernacular of formal verification:  State Space Explosion. Although research on formal algorithms is very active in academia and industry, formal’s capacity is directly related to the state space it must explore. Higher design complexity equals more state space. This constraint limits formal usage to module, block, and (smaller or well pruned/constrained) subsystems, and potentially chip levels (including as a tool to help isolate very difficult to debug issues).

The use of hardware acceleration has a long, checkered history. Back in the “dark ages” of digital design and verification, gate-level emulation of designs had become a big market in the still young EDA industry. Zycad and Ikos dominated the market in the late 1980’s to mid/late-1990’s. What happened?  Verilog and VHDL plus automated logic synthesis happened. The industry moved from the gate to the register-transfer level of golden design specification; from schematic based design of gates to language-based functional specification. The jump in productivity from the move to RTL was so great that it killed the gate-level emulation market. RTL simulation was fast enough. Zycad died (at least as an emulation vendor) and Ikos was acquired after making the jump to RTL, but had to wait for design size and complexity to compel the use of hardware acceleration once again.

Now, 20 years later, it is clear to everyone in the industry that hardware acceleration is back. All 3 major vendors have hardware acceleration solutions. Furthermore, there is no new technology able to provide a similar jump in productivity as did the switch from gate-level to RTL. In fact, the drive for more speed has resulted in emulation and FPGA prototyping sub-markets within the broader market segment of hardware acceleration. Let’s look at the advantages and disadvantages of hardware acceleration (both varieties).

-          Speed:  Speed is THE compelling reason for the growth in hardware acceleration. In simulation today, the average performance (of the DUT) is perhaps 1 kHz. Emulation expectations are for +/- 1 MHz and for FPGA prototypes 10 MHz (or at least 10x that of emulation). The ability to get thousands of more verification cycles done in a given amount of time is extremely compelling. What began as the need for more speed (and effective capacity) to do full chip, pre-silicon validation driven by Moore’s Law and the increase in size and complexity enabled by RTL design & design reuse, continues to push into earlier phases of the verification and validation flow – AKA “shift-left.”  Let’s review a few of the key drivers for speed:

  • Design size and complexity:  We are well into the era of billion gate plus design sizes. Although design reuse addressed the challenge of design productivity, every new/different combination of reused blocks, with or without new blocks, creates a multitude (exponential number) of possible interactions that must be verified and validated.
  • Software:  This is also the era of the SoC. Even HW compute intensive chip applications, such as networking, have a software component to them. Software engineers are accustomed to developing on GHz speed workstations. One MHz or even 10’s of MHz speeds are slow for them, but simulation speeds are completely intolerable and infeasible to enable early SW development or pre-silicon system validation.
  • Functional Capabilities of Blocks & Subsystems:  It can be the size of input data / simuli required to verify a block’s or subsystem’s functionality, the complexity of the functionality itself, or a combination of both that drives the need for huge numbers of verification cycles. Compute power is so great today, that smartphones are able to record 4k video and replay it. Consider the compute power required to enable Advanced Driver Assistance Systems (ADAS) – the car of the future. ADAS requires vision and other data acquisition and processing horsepower, software systems capable of learning from mistakes (artificial intelligence), and high fault tolerance and safety. Multiple blocks in an ADAS system will require verification horsepower that would stress the hardware accelerated performance available even today.

-          As a result of these trends which appear to have no end, hardware acceleration is shifting left and being used earlier and earlier in the verification and validation flows. The market pressure to address its historic disadvantages is tremendous.

  • Compilation time:  Compilation in hardware acceleration requires logic synthesis and implementation / mapping to the hardware that is accelerating the simulation of the design. Synthesis, placement, routing, and mapping are all compilation steps that are not required for software simulation. Various techniques are being employed to reduce the time to compile for emulation and FPGA prototype. Here, emulation has a distinct advantage over FPGA prototypes in compilation and TAT.
  • Debug productivity:  Although simulation remains available for debugging purposes, you’d be right in thinking that falling back on a (significantly) slower engine as your debug solution doesn’t sound like the theoretically best debug productivity. Users want a simulation-like debug productivity experience with their hardware acceleration engines. Again, emulation has advantages over prototyping in debug productivity. When you combine the compilation and debug advantages of emulation over prototyping, it is easy to understand why emulation is typically used earlier in the flow, when bugs in the hardware are more likely to be found and design changes are relatively frequent. FPGA prototyping is typically used as a platform to enable early SW development and, at least some system-level pre-silicon validation.
  • Verification capabilities:  While hardware acceleration engines were used primarily or solely for pre-silicon validation, they could be viewed as laboratory instruments. But as their use continues to shift to earlier in the verification and validation flow, the need for them to become 1st class verification engines grows. That is why hardware acceleration engines are now supporting:
    • UPF for power-managed designs
    • Code and, more appropriately, functional coverage
    • Virtual (non-ICE) usage modes which allow verification environments to be connected to the DUT being emulated or prototyped. While a verification environment might be equated with a UVM testbench, it is actually a far more general term, especially in the context of hardware accelerated verification. The verification environment may consist of soft models of things that exist in the environment the system will be used in (validation context). For example, a soft model of a display system or Ethernet traffic generator or a mass storage device. Soft models provide advantages including controllability, reproducibility (for debug) and easier enterprise management and exploitation of the hardware acceleration technology. It may also include a subsystem of the chip design itself. Today, it has become relatively common to connect a fast model written in software (usually C/C++) to an emulator or FPGA prototype. This is referred to as hybrid emulation or hybrid prototyping. The most common subsystem of a chip to place in a software model is the processor subsystem of an SoC. These models usually exist to enable early software development and can run at speeds equivalent to ~100 MHz. When the processor subsystem is well verified and validated, typically a reused IP subsystem, then hybrid mode can significantly increase the verification cycles of other blocks and subsystems, especially driving tests using embedded software and verifying functionality within a full chip context. Hybrid mode can rightfully be viewed as a sub-category of the virtual usage mode of hardware acceleration.
    • As with simulation and formal before it, hardware acceleration solutions are evolving targeted verification “applications” to facilitate productivity when verifying specific objectives or target markets. For example, a DFT application accelerates and facilitates the validation of test vectors and test logic which are usually added and tested at the gate-level.

In conclusion, it may seem that simulation is being used less today. But, it is all relative. The total number of verification cycles is growing exponentially. More simulation cycles are being performed today even though hardware acceleration and formal cycles are taking relatively larger pieces of the overall verification pie. Formal is growing in appeal as a complementary engine. Because of its comprehensive verification nature, it can significantly bend the cost curve for high-valued (difficult/challenging) verification tasks and objectives. The size and complexity of designs today require the application of all verification engines to the challenges of verifying and validating (pre-silicon) the hardware design and enabling early SW development. The use of hardware acceleration continues to shift-left and be used earlier in the verification and validation flow causing emulation and FPGA prototyping to evolve into full-fledged verification engines (not just ICE validation engines).

New Test Compression Technology Reduces Test Time

Monday, February 29th, 2016

Paul Cunningham, VP of R&D, Cadence

The chip industry spends roughly $4B annually on automated test equipment (ATE) for manufacturing test. Every working chip that comes off the production line absorbs this spend as part of its overall production cost. At advanced nodes, as chips grow more complex to support increasingly rich user experiences, this cost will only continue to rise.

Time on ATEs involves testing of memories, chip I/O interfaces, analog logic, and digital logic. One of the most substantial segments here is testing of digital logic, which typically encompasses 10-50% of total test time. Over the years, the Design for Test (DFT) industry has introduced various technologies to reduce test cost. XOR-based test compression is the most widely used approach today. To reduce test time, XOR compression partitions registers in a design into more scan chains than there are scan pins on the chip to connect to the ATE.

As the ratio between the number of scan chains and the number of scan pins increases, the length of each scan chain decreases. This means fewer clock cycles to shift in each test pattern. For a constant pattern count, fewer shift clock cycles per pattern requires less total test time on the ATE.

With fewer clock cycles per pattern, there are also fewer bits of infor­mation in each pattern to control register values and detect faults. If the compression ratio becomes too high, then the achievable fault coverage will drop since some faults will require more register values to be controlled than there are bits in a test pattern. Also, as the compression ratio increases, even if fault coverage can be maintained, the number of patterns required to maintain this coverage rises rapidly since it becomes more difficult to pack the detection of multiple faults into a single pattern. All of this causes a diminishing benefit on total test time from increasing the compression ratio. Typical compression ratios of around 50-100X are used today.

In addition to fault coverage drop and pattern count growth, increasing the compression ratio also significantly impacts the physical implementation of a chip because every scan chain must be connected to and from the XOR compression logic (Figure 1).

Figure 1: Wiring overhead associated with compression logic.

At a typical industry compression ratio of 100X, the average impact of XOR compression logic across a range of common digital components is 3-5% of total chip routing resource. When increasing the compression ratio to 400X, the impact on chip routing resource increases to a staggering 10%. This would require a significant increase in die size to accommodate and ultimately outweigh any potential cost savings from the reduced test time.

New Test Technology Supports Compression Ratios Beyond 400X

Cadence recently introduced new test technology that supports higher compression ratios while reducing test time. The Modus Test Solution provides a 2D Elastic Compression architecture consisting of 2D Compression and Elastic Compression. The architecture enables compression ratios beyond 400X with an up to 3X reduction in test time versus traditional XOR compression at a 100X compression ratio. There’s no impact on fault coverage or chip routing resource.

If 2D Compression is used on a traditional non-elastic XOR compression structure at a 100X compression ratio, then the impact of the compression logic on chip routing resource is only 2%, an up to 2.6X improvement over current industry solutions. 2D Compression targets the impact of high compression ratios on chip routing resource. The technology takes advantage of the two-dimensional nature of a physical chip layout to build an XOR network that can unfold into a grid structure across the chip (Figure 2).

Figure 2: In 2D Compression, an XOR network unfolds into a grid structure across the chip.

Wirelength of the 2D grid structure scales sub-linearly with the compression ratio. At a 400X compression ratio, the wirelength is still no worse for routing resource than traditional “one-dimensional” XOR compression at a 100X compression ratio.

Cadence’s tool pairs Elastic Compression with 2D Compression to mitigate the fault coverage and pattern count impact of high compression ratios. Unlike traditional XOR compression, the 2D Elastic Compression architecture leverages the registers and sequential feedback loops alongside traditional XOR logic in the decompressor circuit.

The sequential nature of an elastic decompressor enables the automatic test pattern generation (ATPG) algorithm in the Modus Test Solution to utilize multiple shift cycles to control register values in a single fault capture cycle (Figure 3). Conceptually, this is similar to “borrowing” scan pins from previous clock cycles to help detect more challenging faults in the current clock cycle. An elastic decompressor can also adaptively increase the number of shift cycles in a test pattern to be larger than the scan chain length, providing even more controllability to detect tough faults.

Figure 3: With the sequential elastic decompressor, the ATPG algorithm in the Modus Test Solution can control register values in a single fault capture cycle

Summary

Compression technology plays a vital role in minimizing the high cost of testing chips. However, the industry has been stalled for many years by the fundamental limitations of coverage drop and compression wirelength. 2D Elastic Compression breaks through these barriers and enables test time to be reduced by up to 3X without any impact on compression wirelength or fault coverage.

Hierarchical DFT: How to Do More, More Quickly, with Fewer Resources

Friday, February 26th, 2016

Rick Fisette, technical marketing engineer, Mentor Graphics.

Today’s large System-on-Chip (SoC) designs present many challenges to all design disciplines. Tool runtime and the amount of memory required to load designs continue to grow and stretch available resources and design schedules. For Design for Test (DFT), much of the design and pattern generation activity have traditionally taken place late in the design cycle which puts it in the critical path to tapeout.  As tool runtimes increase and different design disciplines vie for the same compute resources, DFT poses an even greater barrier to a timely tapeout.

Hierarchical DFT Overview

A hierarchical DFT methodology is specifically targeted for the challenges of large SoCs. The basic concept is a “divide and conquer” approach. Each core corresponding to a layout block is isolated by wrapper chains. When implemented properly these wrapper chains add negligible gate area but the isolation they provide make it possible to test each core separately. In Internal mode, a core’s wrapper chains are configured to test the logic within the boundary of the wrapper chains. In this mode, only the netlist for the core needs to be loaded in the ATPG tool for pattern generation, as shown in Figure 1.

Figure 1. Core-level test pattern generation.

In addition to generating patterns at the core level, the wrapper chains are also verified through simulation with fully back-annotated timing. One last core-level step is to generate a graybox model of the core that only contains the wrapper chains and logic outside the wrappers, as shown in Figure 2. This interface model is used to represent the core for subsequent SoC-level steps.

Figure 2. Greybox generation.

Internal mode patterns are then simply retargeted to the SoC-level pins. Even with very few chip-level pins available, cores can share access to these pins and be tested in separate phases. The retargeting done by Mentor Graphics test tool, Tessent TestKompress, will automatically account for pipeline stages and inversions in the scan path and merge patterns together for both identical and non-identical cores, as shown in Figure 3.

Figure 3. Retargeting core patterns to the SoC level.

The remaining SoC-level logic and interconnect are targeted in External test mode. In this mode, the wrapper chains of the cores are reconfigured to launch from output wrappers and capture on the input wrappers. This relatively small pattern set only requires that the SoC-level netlist and grayboxes be loaded in the ATPG tool. This keeps memory footprint low and runtime short.

The test coverage results of External mode are then automatically merged with the coverage of the Internal mode pattern sets so that a single comprehensive SoC test coverage is reported, as shown in Figure 4.

Figure 4. External mode pattern generation.

Pattern Retargeting Benefits

Hierarchical DFT techniques have been in use for some time but new automated capabilities like pattern retargeting significantly enhance the advantages of the hierarchical test. Core-level generated patterns benefit from better efficiencies in clock control and scan channel allocation, which typically result in a 2X reduction in pattern count. The most obvious benefit is that ATPG runtime is reduced by as much as 10X. Even more significant, though, than the days of runtime being eliminated is when it is being eliminated. Pattern retargeting makes it possible to generate and verify scan patterns very early in the schedule as each core is completed. Instead of waiting until very late in the schedule for a final SoC netlist before generating and verifying scan patterns, these time-consuming tasks are shortened, performed across all cores in parallel and completed much earlier in the schedule. Hierarchical DFT with retargeting removes DFT from the critical path to tapeout.

Another DFT task that holds up tapeout is regenerating SoC-level patterns when logic changes are made to the final design due to bugs found late in the verification process. Rather than regenerate patterns from the SoC level, retargeting enables one to quickly regenerate patterns for just the affected core.

Another benefit of pattern retargeting is the up to 10X reduction in memory required for running ATPG. Since CPUs with much less memory are typically more widely available it is now possible to take greater advantage of distributed processing capabilities, further reducing runtimes. Because ATPG no longer needs the largest CPUs, those machines become more available for other design disciplines such as physical design and verification to complete their tasks.

Conclusion

Hierarchical DFT, specifically with pattern retargeting, can provide as much as 2X reduction in pattern count as well as 10X reduction in memory and runtime required for generating and verifying scan patterns. More importantly, DFT tasks are completed at the core level early in the schedule. This removes DFT from the critical path to tapeout and improves time to market.