RTL Design-for-Test
Design-for-test is a rapidly expanding task which is becoming more integrated with the design flow as time goes on. As I mentioned in my previous post, there are DFT-related tools spanning the range from RTL to the extreme back-end (which fall into the DFM category, IMHO). I thought I’d talk a little about those tools closest to the front-end of the flow: RTL.
Relax, there’s more to your job than ATPG fault coverage (I hope). Anybody out there evaluated or used this tool? Let me know your opinion.
Another slightly more pro-active approach to design-for-test in the RTL domain is offered by a company called DeFacto Technologies, headquartered near Grenoble, France. Their objective is to provide a tool that will insert DFT code into your RTL before synthesis, thereby reducing (RTL->synth->DFT analysis) iterations. Their product is, according to the website, due to roll out this fall. Should be interesting!
Enough for now, when I follow up, I’ll talk about some DFT-related tools you might use after the silicon comes back…
Stumble It!
What sorts of DFT problems are designers causing at RTL, that you need another tool to help analyze them?
Can’t you just have some basic rules like “don’t gate the clocks”, “asynchronous set/reset must be controllable by I/O”, “keep data and clock separate”, and you’re pretty safe? Can a DFT tool like Synopsys DFTCompiler do all the checking you need?
I’m trying to be open minded, but am having trouble picturing where RTL DFT tools will add value.
That’s a very good question. On one hand, you’ll have to remember, there’s more to scan these days than controlling the clocks and resets. On the other hand, I’m not sure SpyGlass can deal with all the different permutations involved. Like I said, I haven’t looked at the tool. Maybe, if we’re lucky, somebody that has will respond. Actually, I’m pretty sure I have a reader that works for Atrenta…
From what I’ve been able to gather, including some posts at DeepChip from a few years ago, it seems the big value is not having to use DC to do your checking. I don’t know what the cost differential is here, but I’ll bet SpyGlass-DFT is less expensive than DFTC, so in a resource impacted situation…?
In addition, and again, I don’t know how well these work, but SG-DFT says it will auto-fix RTL to improve scannability, as well as pinpoint causes of at-speed coverage loss, which are definitely not features in DFTC. It also claims to help a designer make test strategy decisions by analyzing controllability and observability. DTC will list rule violations, but won’t tell you what to do about them – for that, there’s SOLD
Stay-tuned, and maybe we’ll flush out some more detail!
I used to work for atrenta couple of yrs back and I used to support SG-DFT. Its sort of analysis tool and you should be using incrementally depending on the stage in the design you are in…during early RTL development phase, SG-DFT evaluates your RTL and tells you how scan ready is your design. As chips are getting complex enough, there are millions of RTL lines of code and people dont always follow every recommended practice..so this tool initially helps you to evaluate ur scan readiness of the RTL..with different pieces of RTL, you can do what if analysis…secondly,as you already identified, it does evaluate the observability and controllbility of the design and will identify points where you can insert additional test points to increase the coverage..additionally what it also does is, it looks all your testpoints and will tell you if you have inserted more testpoints than necessary..for example, you might have 500 testpoints and your coverage is 90%, but if you insert testpoints here, your coverage might remain same or go up and you dont need 500 testpoints. so it does all sorts of these analysis…calculates your fault coverage..I believe the coverage metrics reported by SG-DFT match pretty close with ATPG…you might want to check with their Sales/Marketing folks about the numbers…SG-DFT like other atrenta’s products is a ruled based DFT checker and it has lot of rules to make sure you dont run into any DFt issues downstream or you dont have to re-spin the whole flow again..
kiran.
Hey Kiran:
Thanks for responding; I was hoping you would! It seems you reinforce what I could gather from the website and datasheet. The basic idea is to address DFT earlier in the design cycle, along with added analysis over-and-above what DFTC can do.
I have a question: when you were supporting this tool, what type of engineer were you supporting, and what was their typical knowledge of DFT in general? Design engineers? DFT engineers?
Thanks for adding your $0.02. It’s good to have engineers of all experience levels and backgrounds contribute!
John
Hi John,
. Also, many physical synthesis tools does scan repartitioning/chain re-ordering with the scan segment, it will be hard to diagnose any issues with these by RTL level analysis tools. Its not a simple scan anymore 
and I have seen an design lately where they employed test compression on few blocks, LV on few blocks, simple scan insertion on few blocks, not to mention about the clock mixing,scan abstraction ( because of hand inserted scan on one block ), we are already at a level beyond what an RTL level analysis tools can offer..
Just want to add few more observations. These SG-DFT tools can add value only to test your scan readiness, and if scan inserted, generated coverage metrics and testpoint insertion to improve controllability and observability. But with DFT itself getting so complex with all those test compression , power aware , LBIST/MBIST, RTL level analysis tools only can serve the basic need and I dont think any RTL level analysis tool can analyze the test logic/structures created DFT implementation tools today. With the test complexity increasing as the process node shrinks, DFM comming into picture, it is a whole different world now
When I was supporting this tool, I worked both with design engineers and pure DFT engineers. Many startups cant afford to have someone dedicated to DFT and their chips wont be so complex . They prefer simple scan insertion and stitching etc..But I will say this..even though DFT is very important piece in design , many design engineers dont have good understanding of test is..many still see it as post manufacturing phenomena and think its not their problem…During trainings, I had to teach basics of scan e.g muxed scan, LSSD, DFT basics like observability and controllability etc
..One RTL engineer was saying to me that for him anything beyond RTL synthesis is back-end stuff 
..From my experience , 50-60% of the people who say they know DFT only has understanding of the simple scan….20% people understand DFT (1149.1 also ) very well and have good knowledge ..only 20% have knowledge of advanced stuff like test compression,power aware DFT, DFT in physically synthesis, board level test,testing memories , mixed signal IC testing etc (if I include IC testing as well )..
just my 2 cents
Thanks,
Kiran.
Thanks for your thoughs, Kiran – definitely worth more than $0.02! I myself am in the middle of a project that is just as you describe. multiple test compression implementations (but not on all blocks), low voltage islands, mbist, jtag, at-speed scan, custom test features, analog testability… lotsa fun, and I don’t think that it would be accomplished without a dedicated resource, whether it be a DFT engineer, or a designer assigned to the task – and you’re right, designers aren’t usually up to the task when it comes to the latest developments in DFT.
John
John ,
can you shed some light on the analog testability. IT would help all readers too.
Thanks,
Kiran.
Kiran,
You forgot to mention that 10% of people who say they know DFT are referring to Discrete Fourier Transforms!
Siyad
Hi ,
I personally have worked on spyglass DFT . As Kiran was telling , the test has moved a level up than what the RTL analysis can tell us. But it is also true that the Spyglass is good enough to help the designer get the basic controlability and observability right. In my experience spyglass is good enough to suggest test points which could improve the coverage numbers. It helps reduce hassles of coming back to the RTL or the scan stitiching tool to autofix it.
The overhead of autofix would be that the test logic inserted could sometimes screw the functionality of the design or it could add unnecessary logic which would merely increase the gate count on your design. So Spyglass is not a thing which can be just ignored.