DFT Digest

12 Responses to “Tutorials/Resources”

1. Kiran Says:
   November 26th, 2007 at 4:05 pm

   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…

2. John Says:
   November 26th, 2007 at 4:38 pm

   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

3. Shakti Says:
   December 6th, 2007 at 12:51 am

   There is no content on the various algorithms in DFT. Kindly include.

4. John Says:
   December 6th, 2007 at 7:14 am

   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:

   Wen, Xiaoqing VLSI Test Principles and Architectures: Design for Testability Morgan Kaufmann- Jul, 2006
   Agrawal, Vishwani D. 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

5. John Eaton Says:
   December 16th, 2007 at 3:43 pm

   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.

6. John Says:
   December 17th, 2007 at 4:55 pm

   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

7. john_eaton Says:
   December 19th, 2007 at 12:16 pm

   “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

8. John Says:
   December 19th, 2007 at 2:12 pm

   “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?

9. John Eaton Says:
   December 19th, 2007 at 5:59 pm

   “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

10. » DFT education for designers - is it worth it? Says:
    December 21st, 2007 at 10:30 am

    [...] Eaton writes in a comment posted to the tutorials/resources page: I am looking for that one document that you can give to a [...]

11. Kiran Says:
    December 21st, 2007 at 11:31 am

    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

12. John Eaton Says:
    December 21st, 2007 at 8:27 pm

    “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

Leave a Reply