Design for testability (DFT) is a very important topic for test-engineering professionals. If DFT isn't incorporated into new designs, these professionals find their jobs much more challenging than they would otherwise. Without DFT, test engineers must work really hard to achieve adequate fault coverage, especially when even the best automatic test pattern generation (ATPG) tools have problems doing that automatically. This is due to circuit configurations such as asynchronous set/reset circuits, internally generated and gated clocks, and combinational and sequential feedback loops. But functional test-vector generation often lasts late into the night! Then, designers must fire off the fault simulator to see if they have yet overcome the DFT problems.
Test engineers have been valiantly "overcoming" DFT problems for decades, and they're still doing so! But it is job security, no matter how frustrating. After all, test is a "back end" problem. It isn't something to consider early in the product concept and design phases. Right? Wrong! Design for testability is still trying to find mainstream adoption in the design phase of product development. Industry analyst estimates of the 2000 expenditures for DFT (and built-in self-test, or BIST) EDA tools peg them at less than 2% of the overall market for EDA tools. Currently, lots of money is spent on system-level-design entry tools, physical place-and-route tools, and hardware/software co-design tools. Plus, these tools now allow designers to design multimillion-gate system-on-a-chip (SoC) designs so complicated that some of them can never be tested properly!
DFT techniques are well known in the test community and well documented by the literature it produces. The benefits that these techniques bring—higher-fault-coverage tests, which have more compact manufacturing test-vector sets, with less test development time—have been proven in design after design, when incorporated early. The pain of design iterations also has been experienced by those design teams that didn't implement scan or BIST in the initial design. Engineers who have experienced this pain usually only want to suffer through it once. Thereafter, they are believers in DFT. Unfortunately, though, these scarred veterans still only hold a small percentage of the overall design engineering population. Additionally, their managers often advise them not to worry about test, as they claim manufacturing will handle it.
It's really time for DFT to become adopted by the mainstream of new IC design flows. The tools exist to automate the necessary RTL and gate-level analysis tasks, perform the scan synthesis, do the APTG, and even insert BIST and boundary scan. Automating these tasks can shave weeks to months off the overall product development cycle, especially where levels of complexity have caused test generation time to actually exceed the functional product development time. Many foundries take raw design data and make it testable before tape-out. Then, they send it back to have timing re-verified after scan insertion, often adding considerable time to the design cycle. But, the shift to the customer-owned tooling model is moving this burden from the foundries to the design teams, so those teams need tools.
Isn't it time to take this still-orphaned technical child off the streets of test and bring it into the home of design where it can grow and flourish?