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?

In the past there have been requests to address analog/Mixed-signal Design for Test on this blog.  I’ve tried to incite discussion on the subject a couple of times in previous posts (here and here) - limp efforts, at best. To be honest, I wasn’t able to come up with much beyond the mantra of all DFT engineers: maximize controllability and observability.  But that doesn’t mean there wasn’t plenty going on - just that I wasn’t paying attention.  Well, sort of.

At least one commenter to my posts dredged up the name Opmaxx; It’s the name of a company founded in the mid/late 90’s to create products for analog and mixed-signal ‘design centering’ and test automation.  I remember it because it came about just as I was getting more involved in DFT and starting to pay attention to the industry.  One of the products introduced by Opmaxx was called BISTMaxx; it inserted structures that subdivided any circuit into blocks that were then isolated during test mode and turned into oscillators.  The underlying concept is that faulty circuits would produce different oscillation frequencies than good circuits.  The general term for this method is called oscillation BIST.

I know of at least one instance (takes you to an article - scroll down to ‘Test Challenges’) where someone put this into their chips and into production.  Opmaxx was acquired by Fluence, then a subsidiary of Credence, was later absorbed into another Credence acquisition called IMS.  At one point, I believe they were selling BIST products for DACs, ADCs, VCOs and PLLs.  Eventually, at a time I’m unable to pinpoint, Credence dropped these products.  The industry was either not ready or unwilling to accept them, I guess.

However, still in the MS-DFT game was, and is, LogicVision.  I don’t know if they ever had ADC/DAC BIST, although Stephen Sunter (director of mixed-signal and parametric test at LogicVision) has presented papers regarding algorithms for implementing it.  They have had, and still do have A PLL BIST solution, and recently they have developed a SerDes BIST solution, based on undersampling, that claims to achieve sub-picosecond accuracy on any tester.  The SerDes BIST is based upon looping transmit data back through the receive channel, while varying certain parameters - thus being able to actually characterize the ‘eye’ of the signal… (more…)

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…