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?

I was perusing the latest version of IEEE Design & Test, which focuses on ICs for Secure Embedded Computing, and it reminded me of a small flap a couple years back about the security, or lack thereof, of scan chains (Scan design called portal for hackers, EETimes, 10/25/2004). Although I haven’t personally noticed any other discussion on the subject since then, a quick Google found a paper as recent as 2006 (A Low-Cost Solution for Protecting IPs Against Scan-Based Side-Channel Attacks, VTS ‘06).

FYI, “Side-channel Attacks” are attempts to decipher or learn encryption algorithms (or learn the IP inside a chip, maybe) by gaining information about the physical implementation of the device itself - in this case, via the scan-chains. Methods for side-channel attacks run the gamut from glitch and power analysis to fault injection attacks. It’s amazing what people can learn by causing a chip to work abnormally.

As it turns out, it’s pretty easy to hack an encryption chip using scan chains (Scan Based Side Channel Attack on Dedicated Hardware Implementations of Data Encryption Standard). So what’s the alternative? Mention was made in the EE Times article that a “primary alternative [to scan/ATPG] is built-in self-test (BIST), which is more secure because it doesn’t require visible scan chains”. And so we see another facet to the “Scan vs. BIST” debate.

Interestingly enough, there were no direct references to scan-based attacks in any of the D&T articles. So what is the status of this issue? Did it not pan out to be that much of a problem? The applications for embedded security can only be growing. Are any of you readers close to this issue?

I’d love to hear from you…

I don’t know if I ever mentioned it before, but a DFT blog was not my original objective for creating an IC design oriented website. In truth, a couple of buddies and I had visions of a well-oiled EDA forum site with experienced professionals trading tricks of the trade – I was just going to be the design for test moderator. But, as always, engineers get busy or distracted, and well, we haven’t pulled it off yet.

However, there are other websites with forums out there. A couple come to mind: design-for-test.com (this would be my preferred place to post a DFT question, as it’s run by an expert), edaboard.com, and edacafe.com also has a forum. One thing about these forums – it seems DFT still remains somewhat an esoteric art. Some of the questions: “Why DFT?”, “What is DFT?”, or “Please state all the DFT design rules and their solutions…”

Once again, design for test is often lobbed to a junior member of the design team, who more often than not, has no idea where to start. And since a majority of our engineering schools spend next to no time on test, well, here we are.

Dave Letterman counts down from 10 to 1, but I’m pretty much a bigendian digital DFT engineer, so I’m going from 9 to 0. So without further ado, I present to you my ‘Top 10 Scan Design Rules’:

9 - Melting pot: NOT! don’t mix scan cell types in a design
8 - Primary input controlled resets
7 - Primary input controlled clocks
6 - Fight the scourge of internal tri-state busses
5 - Mixing clocks and data is racy
4 - Avoid combinational feedback
3 - Remember your memories
2 - Proceed with caution (from one clock domain to another)
1 - Know your ATE
0 - Scan everything

The longer winded explanations are after the click. Have a read, and let me know what you think! (more…)