May 1, 2005 -- Design for test (DFT) solutions are increasingly indispensable to the chip designer, but what does DFT really mean, and what sort of relief does it provide? And why are solutions stuck at the gate level instead of at the register transfer level (RTL), where main design decisions are taken and important design requirements such as reuse are considered?

The cost associated with manufacturing testing of integrated circuits is climbing. The International Technology Roadmap Semiconductors reports that the semiconductor industry has reached a point where testing a chip costs as much as manufacturing it. With greater functionality being packed into each design, both the time required to test each integrated circuit (IC) and the cost of the necessary testing equipment keep increasing. Design for test, which essentially means constructing designs with easy testability in mind, is key to solving the problems of both time and expense.

Today, it is mandatory to consider testability issues very early in the design process and it is not acceptable for an RTL designer to deliver synthesizable code in Verilog or VHDL with testability problems (that is, with test vectors of poor quality). Yet qualification of the quality of test vectors is still performed at the gate level, which means that RTL designers must run the synthesis process and iterate around this time-consuming process before delivering testable RTL code. For example, one logic synthesis pass for a medium sized intellectual property (IP) core of hundreds of thousands of gates may take hours; involving RTL designers in such an iterative process is painful and a waste of time.

A complete and effective DFT solution is one where planning, analysis and implementation are accomplished at RTL. For example, given an IP-based system-on-chip (SoC) and a widely used DFT methodology such as internal SCAN (ISCAN), the best scenario is to start planning ISCAN hierarchically at the level of each IP core; analyze the rules that allow detection of testability problems; and finally generate the final RTL design project, embedding the necessary ISCAN logic.

Several solutions are proposed today for checking testability problems at RTL. However, these solutions are incomplete because implementation of all necessary test logic is still performed at the gate level. This means repeating the implementation process every time an IP core is reused and every time logic synthesis is run. For example, given a design project with a "reuse ratio" of 80%, if DFT logic is already implemented at RTL, this means avoiding 80% of implementation time and effort. Such savings scale with the number of iterations around logic synthesis. Furthermore, when a soft IP core is reused from one project to another or from one technology process to another, DFT implementation has to be repeated.

Figure 1: DFT at register transfer level vs. classical DFT at gate level.

Since implementing test logic for a DFT methodology such as ISCAN may exceed 10% of logic synthesis time, projected time savings can be important. Implementing at the register transfer level also will accelerate delivery of soft IP cores, which means a better predictability of the overall design cycle time.

If DFT would be so much better at RTL, why didn't EDA vendors develop it years ago? Basically, they have not had sufficient incentive. Reasons are historical, strategic and technical. Historic reasons tend to be related to new players in the DFT arena, who have acquired gate-level DFT technologies and not made any improvements.

Strategic reasons seem to cluster around major EDA players for whom it is important to collapse, during logic or physical synthesis, several design steps, including DFT. There is no incentive for these companies to move DFT to RTL, since their business models revolve around synthesis.

Technical reasons have been a major obstacle for a while. Several companies have tried to cover all DFT needs at RTL. The problem is that, until now, their solutions did not provide Quality of Results (QoR) comparable even to traditional low-level approaches. (QoR implies both quality and cost. Quality is related to DFT expectations such as fault coverage. Cost relates to several parameters such as performance degradation, area overhead, and testing time.) For example, for an RTL-to-RTL ISCAN solution, users expect several features such as fast implementation of test logic, easy logic synthesis, efficient generation of test vectors, no degradation of design performance (e.g., timing and floor planning), reusability, no iterations around logic synthesis, and better organization between design engineers.

Some movement towards DFT implementation at RTL is on the horizon. Some standalone DFT solutions are proposed at RTL for such methodologies as boundary scan, memory BIST and compression. However, important DFT methodologies such as ISCAN and logic BIST are not covered yet.

As with logic synthesis in the past, adoption of RTL DFT solutions should be progressive. Adopting a complete DFT flow at RTL has to be accomplished in two steps: standalone RTL DFT solutions followed by an integrated solution that covers all DFT needs. A standalone DFT solution such as ISCAN also may be adopted progressively.

It should go without saying that comprehensive RTL DFT solutions should deliver at least the QoR of gate-level solutions, and be fully compliant with existing gate-level DFT solutions. For instance, for RTL ISCAN, implementation should be first at the IP core level before complete adoption at the level of the SoC. Emergence of new standards such as CTL (Core Test Language), which help to describe test logic, also will assist with interoperability, smooth transition and a full compliance between RTL DFT solutions and existing gate-level solutions.

Moving DFT to RTL will eliminate iterations around logic synthesis and ease IP re-use. It's time the EDA industry had a complete DFT solution that covers planning, analysis and implementation before synthesis.

By Chouki Aktouf, Ph.D, founder and CTO, DeFacTo Technologies