Up to my eyes…
I’m still here… I’ve just not had the time and energy to post lately. I’m working on an analog testability post, which I’ll post in the next couple of days… I think. It’s time like these that I find myself jealous of those big, successful blogs that have several editors contributing - it’s not that there’s a lack of stuff to talk about…
August 29th, 2007 at 9:45 pm
I know exactly what you mean. When I started dftforum.com, I thought there will be at least some activity (maybe a few posts a day). So far, it has been dead for months.
I know that there are a lot of new people in the DFT field looking for help/info, especially in India. But looks like we DFT folks are a very shy group.
September 4th, 2007 at 4:22 am
Hi
I am new to DFT . I am using Dftadvisor by mentor graphics . Can any one through light on S1 voilation.
what information does a designer give to the dft engineer along with the netlist and library .
September 5th, 2007 at 10:51 pm
Hi John,
Would it be possible to shed some light on scan chain reordering ?. Did you ever happen to do it ? What are the main reasons the scan chains are re-orderd ? .
September 17th, 2007 at 1:42 pm
aanand,
if it wouldnt be for congestion and wirelength , I cant think of any thing else?
September 18th, 2007 at 9:51 pm
Kiran ,
I also heard from someone that it is also done for power saving …( not really sure how they do it ). Then another scenario I can think of is the flops which are logically adjacent could be physically far away. In this case timing problems may araise, the flops can be reordered to fix this.
- Aanand
September 18th, 2007 at 10:04 pm
Hi ,
A basic question … You are given a design . The first cut coverage report says 85 % . What do you as a DFT Engineer think of doing to improve the coverage ?
A few things which I can think of are
1. Are all the flops scanned ?
2. Are the latches transparent ?
3. Are the black boxes bypassed in scan mode ?
4. What are the sub blocks which are having less coverage ? find them and then look for any catches.
5. How are the scan clock muxing and resets handled ?
6. Possible contention issues on the tristates , pads ?
7. DFT models validated ? could look for possible issues with them .
8. Reset / Clock generation logic included in scan chain ?
9. Levels of non scan logic ? if more then the basic scan patterns might not cover them.
These are all the things I could think of . Please let me know if anyone has more points to add to the list.
John,
Please let me know it is ok with you to start of these kinda discussions here ( In the reply secion ) .
Or is there a better way we could do it ?
- Aanand
September 18th, 2007 at 10:21 pm
Goldy,
The S rules are the scanablity rules.This checks for the clock inputs of the non scan elements to see if they can be turned off. This rule makes sure that it can convert all the possible non-scan cells to scannable ones.
- Aanand
September 19th, 2007 at 12:11 pm
Aanand,
for flops logically adjacent and physically being farway,we normally insert lockup latches ;no matter what u insert lockup latches ( ofcourse tools give u options where u dont need to insert lockup latches); scan re-ordering doesnt help in this cases…yes scan reordering helps in power savings ..this is intangible benefit of scan reodering….may be u can specify the max power that can be consumed by scan chain segement..but normally u save power in DFT either by reducing the number of scan chains or chain length itself and lastly not doing at speed testing or use some test compression tech to reduce the scan chain vector volume..John can comment more
September 25th, 2007 at 4:36 pm
Aanand,
for your testcoverage question, In addition to what you already pointed out, you might want to check
1. if there are any macros (memories) in the design and how is test defined for them.RAM/ROM/Any macros should have proper rings or bypass wrappers. If not, lot of faults gets blocked as well as get uncontrollable which degrade coverage
drastically.
2. Check if you have any Boundary Scan. Many people disable scan on the TAP controller logic etc
3. Check to see if there are any Analog components like PLL etc.
4. Also, check for logic excluded from Scan.
5. If all is well, then check your script if you are mistakenly exlcluding any cells .
6. Check if and how much redundant logic is present in your design. More redundant logic generally leads to , lesser fault coverage, but no impact on test coverage
7. finally, you can dump list of faulty nodes using ATPG tool and then see if test point insertion can improve the controllability/observability of the logic.
I dont get your 9th point about Levels of non scan logic. Why/how should the non scan logic affect the scan pattern ? am I missing something here?
September 25th, 2007 at 4:39 pm
I missed adding the following in my previous comment on fault/test coverage.
8. Async set/reset repair
September 25th, 2007 at 5:40 pm
I’m way behind on this discussion - but about the “levels of non-scan logic” - whenever you leave some logic unscanned, the ATPG will attempt to test throgh it by generating sequential patterns - so the combinational nature of full-scan breaks down a bit, the ATPG works harder, and creates bigger patterns as a result.
September 25th, 2007 at 5:52 pm
As I read through this discussion of things causing poor fault coverage, one thing that comes to my mind is that the best and first place to look is your scan DRC report. Most, if not all testability problems will be found there.
Another issue I don’t see explicitly mentioned is that of flops clocked with the negative edge. ATPG is much smarter these days in generating patterns for this case that will pass in simulation, but there is some fault coverage loss.
It has been mentioned, but in my experience the biggest fault coverage hits are experienced around memories: shadow logic.
JMF