DFT Digest

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!

He are short explanations for my top 10 rules. I’d like to add pictures and such, and maybe I’ll do that and then post this as a permanent item on another page. When I get time… So here they are:

9 - Melting pot: NOT! don’t mix scan cell types in a design

Way back when, there were 3 flavors of scan: ‘muxed-D’, ‘clocked-scan’ and LSSD. I’ve not heard of clocked-scan for a decade. I don’t know if anyone uses it. Mux-D is the prevailing de-facto standard, and there are still pockets of LSSD (IBM, Motorola, Freescale).

But the point is – don’t mix them in a design! It won’t work. There are advantages and disadvantages to all of them as design styles, but as far as scan operation goes, they are fundamentally different. Now, before you protest, I know that it is possible for different design styles to reside in independent blocks of a larger design, such as an SoC. You can generate scan patterns separately for each. But if you’re planning a design from the top down, don’t let the designer’s think they can pick and choose…

8 - Primary input controlled resets

It is fairly common for sequential logic to generate reset signals for other areas of a device. However, if this is not dealt with explicitly, it will break the scan design. The reason is simple: If a derived reset emanates from a flip-flop that is scanned, during the shift operation, the random values being shifted through the flop will randomly reset circuitry to which it’s attached.

To remedy this, using a scan_mode signal, gate the ouput of the flop generating the reset to a safe, inactive, value. The scan_mode signal is a static signal which signifies that the device is in the mode to do scan testing. Some gate the flop off using scan_enable. This will get a better fault coverage, but may not work in capture mode due to race conditions. The absolute highest fault coverage can be obtained using a third signal in conjunction with scan_enable, and testing in two passes [1]

7 - Primary input controlled clocks

Obvious, no? Nothing’s obvious it seems, so I’ll say it: You cannot generate scan vectors for a device if you do not have complete control over the clock input for every scanned flip-flop. This is necessary for the tool to be able to reliably shift data through the chain.

What about for at-speed scan? You say, “I can’t get a XXX-MHz clock into the device! So can I use the internal PLL?” Well, yes and no. Even for at-speed ATPG, you don’t need to shift data into the device at-speed. The capture cycles, however do need to be at-speed. In this case, with a little work, you can design a gating mechanism that will allow two clock cycles to slip through from the PLL during the launch-capture phase of each scan vector.

6 - Control your tri-state busses

Internal tri-state busses should have been outlawed years ago. They may be area/power efficient, but they’re slow, and they cause havoc for ATPG. Consider the fact that the tri-state enable logic is driven by one or more scanned flops, which get random data as the ATPG shifts scan data in and out of the part. That could make for some hot action on that bus, since more than one driver may be turned on at once as the random values filter through the enable logic.

So what do we do? The first and best answer is to let the scan insertion tool to automatically take care of it. Most will.

If you must design your own protection, the brute force approach is to bring in the scan_enable signal, and during scan mode, disable all but one of the drivers on the bus while shifting data (that you leave one to drive the bus is important – if you leave none, it would result in a floating bus, another DFT no-no). When in capture mode, the bus driver enable logic will work as normal (and should be contention safe, unless designed improperly).

5 - Mixing clocks and data is racy

If, for any reason, a clock that latches data into a flop also partially determines the data being latched into it you have a potential race condition. You might see this in cases where the design uses both edges of the clock in a datapath, and the clock is used to select different data (in muxes). This situation will cause the ATPG tool to complain loudly, and will almost surely cause simulation mismatches.

To deal with this situation, you have to bring in the scan_mode signal to gate off the clock during scan, and just test for one side of the mux, or maybe insert an extra scan mode flop to control the signals that in normal mode emanate from the clock.

4 - Avoid combinational feedback

Combinational feedback is not usually a problem in good synchronous design, but could happen inadvertently if one mealy state machine directly feeds anouther (which is why it’s a good practice to register outputs of FSMs – but I digress). This feedback is a particular headache for scan design, because it can be impossible for the ATPG to be able to generate an accurate pattern.

If combinational feedback does appear in your design, the loop must be broken with a special flop inserted in the path only during scan mode.

3 - Remember your memories

Yes, I know you don’t scan your memories, but how you treat the logic around your memories will make a difference in fault coverage. Logic surrounding embedded memories (everything from the last flop to the memory inputs, and from the memory outputs to the first flop) suffer from fault coverage. It’s hard to control and hard to observe.

The first order response to this is to insert a bypass. In scan mode, the memory data inputs get muxed with the memory data outputs and are latched into the first flops after the memory. You can do this explicitly, or if you’re BISTing the memory, have the memory BIST tool do it automatically. In fact, they do a better job; they include the address bits in the bypass logic to get better fault coverage.

If you model your memory well, and mind the control signals, you may be able to convince your ATPG to test through the memory, negating the need for a bypass.

2 - Proceed with caution (from one clock domain to another)

The biggest scan chain killer, beyond uncontrolled flop inputs, is a hold time violation. Since hold time is frequency independent, you can shift data into a scan chain as slow as you want, but if you have a hold time problem, you’re screwed.

The most popular cause of hold time violations is clock skew. Designers take great pains to minimize clock skew for anything within a given clock domain. But there’s no reason to work so hard as to minimize it across all clock domains. So what if your scan chain contains flops in more than one clock domain? Use lock-up latches.

Lock-up latches are D-latches gated with the inverse of the clock that strobes the flops preceding it in the scan chain. This technique buys you another half cycle of hold time. This is a no-brainer, and actually the scan insertion tools all do this automatically. If you specify, most tools will also put a lock-up latch at the end of each chain, which may come in handy if you are combining some scan chains at a higher level of hierarchy.

1 - Know your ATE

What to you know about your target tester? How much are you willing to spend on ATE (Automatic Test Equipment)? Well, there is ATE, and then there’s ATE…

From the larger perspective, if you have money to sink into either purcahsing or renting a big-ticket tester, you may not have to work so hard on DFT. But if you’ve got an eye on the bottom line, the demands for internal test structures goes up. Make sense?

But that’s not all. From both a digital and analog perspective, it’s good to know the capabilities of the target tester so you can configure the test features to match it. Otherwise, you’re either looking for another ATE, or stuck not testing something. So when planning your scan design, think of the clock frequency that can be delivered by the tester, and how the scan vector memory is architected.

0 - Scan everything

For God’s sake, scan everything you can. for every non-scan circuit, there’s a major hassle awaiting. You have to test it somehow. Scan is the most automatic form of test available. Fight for it.

[1] VLSI Test Principles and Architectures, Pg. 76