DFT Tutorials
This is a work-in-progress; there will be many links to other pages on the internet, and some of it will be my own material. As you look through the material, if there is something you’d like to see here, please e-mail me at jford@dftdigest.com or go to DFT Forum and request a discussion. If I see active discussion on the DFT Forum, I will probably search for material to include here.
- DFT Basics
- Structural DFT
- Scan testing
- Memory BIST
- Logic BIST
- …
- Board-level DFT
- JTAG/IEEE 1149.1/Boundary scan
- IEEE 1149.4 (analog)
- IEEE 1149.6 (Advanced communications I/O)
- …
That’s just a start. I want to add much more, as time permits. Please feel free to add subjects to the list, and I’ll do the best I can. Even better, contribute your own content. I reserve the right to edit it for flow/grammar/spelling, but you will be credited duly.
Just comment below, or e-mail me!
John,
There is lot of DFT basics material available in internet..but we miss mostly is the advanced DFT stuff aka structural and board level DFT..I will point any good links I know which cover these….keep up the good effort…
Kiran:
Thanks as always for the comment. And maybe I’ll approach it differently… maybe I fill out a couple of basics, and then do an advanced topic or two, in no particular order.
When you say ‘advanced DFT stuff aka structural’, are you thinking about theory, or practice? Because to many people, structural DFT starts with scan, which is also, to many people, a basic concept.
John
There is no content on the various algorithms in DFT. Kindly include.
Shakti:
Thanks for your comment! I will continue to add content as time permits – and since you asked about ATPG algorithms, I’ll work on that next. In the meantime, I refer you to the following books, as they both have significant content with regard to ATPG:
VLSI Test Principles and Architectures: Design for Testability
Morgan Kaufmann- Jul, 2006
Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits
Springer- Nov, 2000
You may be able to find, if you google the books and the content from that book that you’re interested in, some of the text from that book at google books. I’ve had some luck with this. No guarantees.
John
Yes there is a ton of stuff out there but it is widely scattered, incomplete and disjointed.
I am looking for that one document that you can
give to a component designer and say ” Here, follow
all these guidelines and we can test your stuff”.
I’m about to give up looking and write it.
Hi John:
I feel your pain. I’m trying to gather – there’s much work to do. About that “one document” you desire: I don’t think it exists, and I’ll tell you why. You’ve not defined “stuff”. Even “component” can be defined multiple ways. Even if you defined components as “semiconductor ICs”, the document could be too broad to be of use to your design team. And even then, they may not read it (I’m being cynical, I know).
I’ve written such documents before, with guidelines, requirements and explanations, and I can tell you that none of them were read by most designers.
Let me suggest this: The only way to really be effective in getting DFT the way you need is to incorporate a checklist into the design review process. I find that designers are concerned mostly of what is expected of them (requirements), and not the why. So I have a simple checklist that is a part of what is reviewed during the design review. It contains items that pertain to the design being implemented: full-scan, mBIST, bypasses, output muxes, etc..
When I get time, I can probably post what I’ve used in the past. Thanks for your comment, and keep reading, and suggesting content! I appreciate it.
JMF
“I’ve written such documents before, with guidelines, requirements and explanations, and I can tell you that none of them were read by most designers.”
Same thing here. When you point this out they accuse you of storing the guidelines
in the same filing cabinet that holds the
plans for the new earth hyperstatial
bypass.
Our process is that before anything is
checked in the owner must rebuild the
chip and run one check_all_sim. This sim
will catch any verilog issues and mistakes
where the new code works but breaks someone
elses code.
We also require all components to run a
synthesis script to prove that their
component and constraints are correct.
We do run rtl checking software that will
catch most structural and test issues. It
takes to long to have each designer run
it so I run it for the chip and send out
the results. That is essential for catching
issues.
John Eaton
“We do run rtl checking software that will
catch most structural and test issues.”
Sounds like a familiar scenario to ours. Do you run the Atrenta RTL checker for DFT? Or is it something homegrown?
I usually work closely with the designers and run the ATPG tool (mostly to go through the DRC check) on each of their blocks as they get new netlists, because it generally does a better job in DRC checking than the synthesis tool.
However, none of this formally tells the designer what needs to be done a priori – it’s a feedback loop.
JMF
BTW – where are those plans for the new earth hyperstatial bypass?
“Sounds like a familiar scenario to ours. Do you run the Atrenta RTL checker for DFT? Or is it something homegrown?”
I work for HP and until recently each site had their own
license server so you had to make a business case for any
new tool.
Corporate has now consoidated all license servers so they
get across the board company wide licenses from the big
four eda vendors. So I have access to more tools than I
know what to do with.
I currently use:
Synopsys dft_compiler
cadence HAL
mentor 0-in checklist and cdc
novas nLint
synopsys Leda
I also used atrenta for four years in the past but with all
these tools I cannot justify spending any more money on
them.
Having a selection like this is great. All these tools are
different so they each tend to catch things that the others
miss. When you run into a tool bug you don’t have to stop
your chip work to fix yet another eda tool bug. I simply
quite using it until their next update. Let some other
smuck do their QA work for free. I have better ways to
spend my time
John Eaton
[...] Eaton writes in a comment posted to the tutorials/resources page: I am looking for that one document that you can give to a [...]
Its quite surprising to me that you are using 3 lint type of tools nlint, leda and HAL when you get all functionality in one atrenta tool..BTW I dont work for atrenta
“Its quite surprising to me that you are using 3 lint type of tools nlint, leda and HAL when you get all functionality in one atrenta tool..BTW I dont work for atrenta”
We really shouldn’s call them linters. They do a lot more than
simple lint checks.
Setup is fairly simply for all rtl checkers. They all use
the same command line syntax as verilog so if you have a
script that can load your design into verilog you simply
change the command name and you load it into any rtl
checker.
Add a constraints file to declare all your clocks, resets
and test_mode signals and one more file to tell the tool
what rules to check and you get results.
You do get redundant coverages but in some cases you find
one tool will catch bugs that others miss. I have also
seen cases where new files were checked in that will
cause one tool to crash. If that happens then we still
have coverage from the others.
I also see wide differences in run times. One tool will
need a 64 bit machine and 7 hours to check a design that
another will check in 30 minutes.
John Eaton
John,
Its would be informative if you post basics of TFT also.
Thanks,
/Sachin
Thanks for the input Sachin – I know I need to put more time into the tutorial section, to make it a bit more useful. I’ll try to get this done in the next few weeks!
JMF
John,
Here is a link to the ASSET website for Board Level DFT guidelines.
http://www.asset-intertech.com/products/free_resources.htm
–scott
Thanks Scott!
I’ll be sure to put it up this month – I’m going to try to put some work into the site during ‘vacation’…
JMF