Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[HELP] Generate test coverage for sub-module after top-scan

Status
Not open for further replies.

wjccentury

Junior Member level 2
Joined
Sep 12, 2005
Messages
24
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,484
clock pis off did not force off clock

Hello, everyone,

I have finished the top scan insertion, but the test coverage is just 90%. Now I am analysing the reason.

I want to get the test coverage of each sub-module in DFT Compiler after top scan.
However, I don't want to set current_design for each sub-module and set its dft signal and then get its test coverage. That is too complex because I have so many sub-modules.

Who can tell me how to generate the test coverage for each sub-module? I need to find a way to improve my test coverage.

Thanks.
 

Re: [HELP] Generate test coverage for sub-module after top-s

I'm curious how you got your test coverage - what tool? Whatever the case, you can track down your coverage loss in a couple of ways:

1) Find a reporting command that will give you hierarchical coverage info
(Mentor FastScan has one such command)

2) Look at your scan DRC's - they will usually point you straight to the coverage loss.

DRC's will report non-scan cells, unstable/uncontrolled asynchronous flop pins, or x-generating logic (embedded memories, for example), all of which will cause fault coverage loss. You may also have over-constrained your design (by gating off a bunch of things in scan mode)

John
DFT Digest
 

Re: [HELP] Generate test coverage for sub-module after top-s

Thank you, John

I use Synopsys DFT Compiler, I hope there is hierarchical coverage command but I can't find. I hope somebody can give me some hints.

In my drc check report, I found many clock violations about Clock PIs off did not force off clock input pin of scan cell .

Do you know how to solve this warning? Thank you!


dft_guy said:
I'm curious how you got your test coverage - what tool? Whatever the case, you can track down your coverage loss in a couple of ways:

1) Find a reporting command that will give you hierarchical coverage info
(Mentor FastScan has one such command)

2) Look at your scan DRC's - they will usually point you straight to the coverage loss.

DRC's will report non-scan cells, unstable/uncontrolled asynchronous flop pins, or x-generating logic (embedded memories, for example), all of which will cause fault coverage loss. You may also have over-constrained your design (by gating off a bunch of things in scan mode)

John
DFT Digest
 

Re: [HELP] Generate test coverage for sub-module after top-s

This DRC indicates that your scan clock is not controllable from a primary input. It's likely that your design has a PLL or some sort of clock gating that prevents you from directly driving your scan cells in scan mode.

To remedy this, you need to mux in a scan mode clock, replacing the 'mission mode' clock with a direct primary input controlled signal. This is a common situation. It applies to resets also.. You will need an extra signal (also primary input controlled) to put the chip into 'scan mode'.

You might want to read through these two articles that present DFT guidelines to follow. Your results will be much better.

**broken link removed**
**broken link removed**

John
 

wjccentury,

Not sure if there is such command in DFT compiler, but you can use the following command in Tetramax after an ATPG run:
report_fault -class <fault_class> -l <n> <m>

where <fault_class> is one of the fault classes listed in Tetramax fault coverage report (I usually put AN, since it is the main contributor to low test coverage)
<n> is the number of hierarchical level to report counting from the top of your design
<m> is the minimum number of faults in the given fault_class before the block is reported.

For example, if you do
report_fault -class AN -l 3 20
You get any hierarchical block 1-3 level underneath the top, with a minimum of 20 ATPG Untestable faults reported.

Hope this helps.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top