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! (more…)

Over there on the right hand side of this page, you’ll see a section called ‘pages’. Underneath, I’ve added two links recently, one called ‘DFT Calendar, and another called DFT Bookcase.

The calendar has a small list of design for test related links to conferences and such.

The bookcase has the entire list of books that appear randomly in the ‘recommended reading’ section farther down on the right-hand sidebar.

I’m always looking for suggestions for what to add to this website to add value to you, the reader. And while you’re at it, if you don’t mind, REGISTER (there’s also a link over there - you guessed it - to the right!). Let me know you’re out there…

Thanks for reading!
John

If you’ve ever been involved with device test or design for test, you’re very likely familiar with at least one of these acronyms - most probably WGL (Waveform Generation Language). If you’ve been in practice in the last 10 years, you’ve at least heard of STIL (Standard Test Interface Language).

How much do you know about CTL (Core Test Language)? If you’re like me, not a ton. I haven’t worked on chips that have integrated a lot of hard IP. Hey, not everyone gets to work on the really big ones. But I do know the industry’s going that way. It’s a huge topic. You can’t turn a page in a trade mag or visit an engineering website without seeing something about the quality of IP. There’s many facets to the overall quality of something like that, but our job as DFT folk is to know if you can test it.

I’d be interested to hear from anyone reading if you’ve used IEEE 1500 compliant cores, and what your experience has been in using them!

Anyway, back to CTL - it’s the newest in the evolution - in the narrowest sense - of formats/languages describing test data. And, it’s not all that new, really. It was approved as IEEE Standard 1450.6-2005 in 2005. However, it’s much more than just test data (which is what STIL, or Standard Test Interface Language, is). CTL really defines a core from a test perspective, and how that core may be integrated into an SoC. It describes the test structures included in the core and how to communicate with them.

More after the click.. (more…)

Another article, this by Sanjiv Teneja of Cadence Design Systems, promoting DWT, or “Design-With-Test” has been posted over at Test & Measurement, as a guest commentary. I blogged a few weeks ago about a similar article by another marketing man from the same company. I smell a conspiracy! Just kidding, go to DeepChip for conspiracies.

Tomato, tomahto, DFT, DWT - the point is clear: Design-for-Test is not what it used to be.  Some of the areas touched on in this article were:

• Power concerns with ATPG and test compression
• Routing congestion concerns with test compression
• Improved defect coverage through timing aware
• Physical awareness during all embedded test (scan, BIST, 1500 core)

I’ve got a couple more - how about:

• Design of AC-JTAG for high-speed differential signals
• Low impact mixed-signal test features

All these issues work to draw the DFT engineer, once upon a time concerned mostly with stuck-at fault coverage and cleverly concocting ATE test modes, deep into the floorplanning, placement, routing and physics of the design flow.  You want test compression? Make sure you understand the router’s scan chain re-ordering  requirements and limitations. Are your ATPG patterns going to smoke your chip?  What happens to your scan chains when your design team decides to use voltage islands?

This is not your daddy’s DFT…

Wow, I shouldn’t be tootin’ my own horn here since I blindly tripped upon the news myself, but today, after over a month since it was reported here, Synopsys released the announcement about Tom Williams winning the EDAA Lifetime Achievement award.

I’m sure there was no hurry to announce it, since the award won’t be given until the plenary session of the DATE Conference on April 17th.

This isn’t really a news blog, so it’ll probably be the first and last time I’ll bring you news first.  But at least I can say I did it once!

And from DFT Digest, another congratulations to Dr. Williams, and thanks for the LSSD…