Drawing on hierarchical DFT to benefit all designs and flows
Hierarchical DFT is a strategy that DFT engineers who have recently completed pattern generation for a large design will readily appreciate. But what about those of you who have yet to adopt it? Well, you can benefit from an important method within that strategy, no-money down and within your existing design path. Here’s how.
While true hierarchical DFT requires the addition of wrapper chains to isolate blocks, you might be able to exploit hierarchical DFT features—even on a design in progress that was not designed specifically for hierarchical DFT—by using a pattern reuse method we call ‘pseudo-hierarchical DFT’. It represents an important step toward hierarchical DFT and still offer major benefits on existing designs until the full technique in planned in.
The idea of divide-and-conquer for DFT insertion and test generation is extremely valuable for large designs. Once a design exceeds 50 million logic gates, creating patterns on the full flat design late in the design flow becomes unnecessarily inefficient. With hierarchical DFT, the pattern generation is performed concurrently on the blocks early in the design phase as soon as each block is ready (Figure 1). The patterns are then automatically reused and mapped to the top-level design. Thus, pattern generation for blocks is taken out of the critical path and is often 10 times faster with a smaller workstation… just to stress, the task is taken out of the critical path.
Figure 1. Hierarchical DFT pattern generation (Mentor – click to enlarge)
It is always a good idea to divide a large and complex problem to into many smaller manageable parts. Applied to SoC design, the smaller parts are designed and implemented separately and stitched together. As applied to IC test, hierarchical DFT should be used for all very large designs, though there is a cost to adding scan wrapper chains to blocks for isolation and including on-chip clock controllers (OCCs) within the blocks. The OCCs placed within blocks ensure that the patterns created for each block can be efficiently reused/retargeted and merged with other block patterns without dependency on top level clocking. Where the main clock control is at the top with several clock entry points to the block, then a “parent/child OCC” can be used. Pseudo-hierarchical DFT still needs the OCC located inside the block or to have a structure like parent/child OCC.
For hierarchical DFT, blocks need isolating wrapper chains regardless of the design within which they are embedded. The addition of wrapper chains does not have much area impact because existing flops are typically used during wrapper chain identification. Many of today’s designs have registered IO, so signals entering or exiting the blocks are retimed to make higher level timing closure easier.
So, yes, setting up a design for hierarchical DFT takes a little preparation, but DFT engineers can benefit from hierarchical DFT on a design with no block wrappers. This situation is not uncommon; you have a huge design and find that top-level DFT is too cumbersome, too slow, and threatens to delay the product schedule because it is in the critical path. The DFT engineers want to get started on per-block DFT and they can do so by using pseudo-hierarchical DFT. Because the block IOs likely are mostly registered (flops close to the IOs for retiming) then you can still create and reuse block-level patterns.
Pseudo hierarchical DFT
For pseudo-hierarchical DFT, you create block-level patterns as you would for hierarchical DFT. The block is not designed to be isolated but because many IOs are registered and already in scan chains, many blocks can still produce high coverage even without wrapper chains. The coverage will not be as extensive as with wrapper chains for hierarchical DFT but it can still be high and provide significant value. You need to force block inputs to Xs and not observe outputs as with normal hierarchical DFT. Stuck-at patterns often get high coverage, but transition patterns will not be as efficient because any additional capture cycles will cause the input X states to propagate within the circuit and lose coverage. In hierarchical DFT, this isn’t an issue because the input wrapper chains are kept in shift mode so the Xs do not propagate into the block.
Pseudo-hierarchical DFT does not offer a dramatic improvement for all designs but it provides a solid progression; it is a great stepping stone on the way to full hierarchical DFT.
Most of the effort in developing a robust hierarchical DFT solution goes into the design rules checking (DRC) and passing of information. This makes pattern reuse/retargeting safe and reliable. A few examples of rules that that are checked for hierarchical and pseudo-hierarchical DFT are:
- The circuit is initialized such that the scan channels have a sensitized path from the block to the top level IO.
- Pipelines are fine.
- Any signal that needs to be static during the block pattern application must also be initialized from the top level.
In a recent case where a design was mostly composed of duplicate blocks, stuck-at coverage for pseudo-hierarchical DFT at the block level was greater than 95%. When this one block was automatically retargeted (passed to the top level design) for the many instances where it was used, the full chip coverage was 92% just based on those retargeted patterns considering the full chip design and faults.
In order to achieve full coverage, we still needed to perform ATPG on the full design to test between block IO and any logic close to a IO missed during block ATPG. However, instead of starting with no coverage and running ATPG on the full flat design for every pattern, we started with 92% coverage automatically reported from a fast block-level ATPG and retargeting. Thus, the top-up ATPG with the full design was less than one tenth what it was for the normal flat ATPG. The pattern count for the same coverage was also much smaller compared to patterns generated on the full flat design.
Pseudo-hierarchical DFT is not guaranteed to work well on every design; you should always try to perform full hierarchical DFT. For some designs, pseudo-hierarchical DFT will result in big improvements in efficient ATPG. Pattern retargeting and the related DRCs takes care of all the necessary checking and porting of information and block level patterns to ensure the patterns will work on the full design.
To learn more about hierarchical DFT, download the whitepaper:
