By Ron Press, Mentor Graphics
The no money down, no design change way to benefit from hierarchical DFT
After experiencing the risks and inefficiencies of pattern generation for a large flat design, many DFT engineers realize that they need to implement hierarchically. A true hierarchical DFT requires the addition of wrapper chains to isolate blocks, but you might be able to take advantage of hierarchical DFT features on your current design even if it wasn’t designed for hierarchical DFT. I refer to this ability to take advantage of hierarchical pattern reuse but without the hierarchical DFT infrastructure as “pseudo-hierarchical DFT.”
The hierarchical DFT idea of divide-and-conquer for DFT insertion and test generation is extremely valuable for large designs. Once a design is greater than 50 million logic gates, it becomes unnecessarily inefficient to create patterns on the full flat design late in the design flow. With hierarchical DFT, the pattern generation is performed concurrently on the blocks early in the design phase as soon as each block is ready. Then the patterns are automatically reused and mapped to the design top level. Thus, pattern generation for blocks is taken out of the critical path and often 10 times faster with a smaller workstation … and, I should stress, out of the critical path.
When I was a young engineer at Raytheon, a senior member of the technical staff discussed with me the need for systems engineers. His point was that many people become overwhelmed by a project or design requirement that seems too large to tackle. However, a good system engineer can divide up the big problem into many manageable parts. Then those parts are designed and implemented separately and placed together. This is how major complex systems are successfully produced. Many of the ICs being designed today are huge complex designs like a system and the solution is the same – divide and conquer.
My recommendation is to always use hierarchical DFT for very large designs, even 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 patterns created for each block can be efficiently reused/retargeted and merged with other block patterns without dependency on top level clocking. For cases 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. For more, see a related blog Improve IC development and reduce risk for big designs by moving DFT up and left
For hierarchical DFT, blocks need isolating wrapper chains regardless of the design they are embedded within. 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, wrappers, OCC, yadda yadda yadda … but what if the wrappers weren’t already designed in and you have a huge existing design? Top-level ATPG for a huge design is too cumbersome, too slow, and is thrown in the critical path because the entire design needs to be complete for traditional ATPG. My advice – try pseudo-hierarchical DFT. Because the block IO are likely mostly registered (flops close to the IO for retiming) then you can still create and reuse block-level patterns. The idea is that you create block-level patterns just like for hierarchical DFT. The block isn’t designed to be isolated but because many IO are registered and already in scan chains it turns out that many blocks can produce high coverage even without wrapper chains. You need to force block inputs to X’s and not observe outputs as with normal hierarchical DFT. When stuck-at patterns are made they can often get high coverage. 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 X’s don’t propagate into the block.
Pseudo-hierarchical DFT might not have a dramatic improvement for all designs but it is great stepping stone on the way to full hierarchical DFT when it does. Most of the efforts in developing a robust hierarchical DFT solution go 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 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; and any signal that needs to be static during the block pattern application must also be initialized from the top level.
I recently saw a case where the 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 from those retargeted patterns considering the full chip design and faults. In order to achieve the full coverage, you still need to perform ATPG on the full design to test between the block IO and any logic close to the 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.
I can’t guarantee that pseudo-hierarchical DFT will work well on every design; you should always try to perform full hierarchical DFT. However, pseudo-hierarchical DFT will work on many designs and will be a big improvement in efficient ATPG and results. Pattern retargeting and the related DRCs takes care of all the necessary checking and porting of information to ensure the patterns will work.
To learn more about hierarchical DFT, download this whitepaper Divide and Conquer: Hierarchical DFT for SoC Designs