DFT Digest - Expanding Design for Test in an Ever-Shrinking World...

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

cnBeta.COM [图]2007年Linux平台下的8款最佳游戏

[图]2007年Linux平台下的8款最佳游戏

ugmbbc发布于 2007-05-29 16:39:01|4930 次阅读 字体：大 小 打印预览
Linux新闻主题

Linux游戏支持情况糟糕一直是广为诟病的问题,不过07年的这8款游戏相当精彩,具有可玩性,并且最重要的是,这八款游戏不需要Wine就可以直接运行,当然,不要指望Linux游戏的效果能够和Windows平台对抗,能玩到就已经是万岁了.
含图片和开发商链接,一起来关注一下吧!

1. Battle For Wesnoth

wesnoth

一个即时战略游戏,已经获得了一百万下载量的开源游戏,拥有35种语言.
* 200+ unit types
* 16 different races
* 6 major factions
2. Nexuiz

nexiuz

Nexuiz,第一人称射击游戏,类似于DOOM3,它的Logo基于中文的"力"字制作而成.

Several notable features of the game include
* ability to multiplay up to 64 players
* ability to generate bots for practice sessions
* dynamic lighting system similar to Doom 3
3. America’s Army

americas army

美国大兵游戏,看上去像不像CS?出了单机还可以联网对战.
4. nemy Territory : Quake Wars

quake wars

也是一个第一人称射击游戏,使用Quake4的技术开发,但不包含最新的情节.
5. Tremulous

tremulous

又是一个第一人称射击游戏,Linux下的玩家是不是很爱打枪?
6. Tux Racer

tux

终于有一个Q一点的游戏了,看上去类似于经典的Flash企鹅游戏,也有点像FC上的南极冒险.
7. World Of Padman

padman

漫画风格的游戏,使用Quake 3引擎.
8. Vendetta

vendetta

第一人称视角的 MMORPG,看上去好像家园啊....

Powered by ScribeFire.