DFT Digest

System Verilog was signed off as a standard by IEEE in late 2005. In the 2-1/2 years since, front-end design tools for synthesis and verification have been making significant strides in support of the standard - not without limitations and missteps - but the effort is there. Progress has been made. So what of the DFT tools? Well, so far - in my experience - it ain’t happening.

The first thing I hear the peanut gallery saying is, “So what? ATPG tools read synthesized netlists, and they’re almost always structural Verilog anyway”! True, for the most part. But how about the situation where you’ve got a mixed SoC where the top level is not synthesized? Designers, when given the chance, will take advantage of the shortcuts available in the newer incarnations of the Verilog language (both 2001 and System Verilog). So the DFT engineer is forced to retrofit the top-level modules to old Verilog.

OK - no big deal… right?

But what about other kinds of DFT tools? memory BIST tools? Boundary scan tools? In a typical flow, these tools provide efficient implementation of Design for Test by reading the design RTL, integrating the test structures into the code, and outputting the augmented RTL, ready for synthesis. So what’s a DFT engineer to do when the design team decides to transition to System Verilog? If these tools aren’t supporting System Verilog, the DFT engineer (or designer) is in for more manual work.

So what is the typical response of the DFT vendor when asked about the lag? “Not enough customer demand”. So does that mean the uptake of System Verilog is not as swift as reported?

What’s your experience?