( DAC 04 Item 12 ) --------------------------------------------- [ 02/09/05 ]
Subject: LogicVision, Mentor FastScan, TetraMAX, Atrenta Spyglass DFT
NEAT LINT -- All the usual suspects here: LogicVision BIST vs. Mentor
TestKompress vs. Genesys BIST; Synopsys TetraMAX vs. Mentor FastScan;
Inovys; SynTest. The one odd new beastie at this DAC was Atrenta
Spyglass DFT caught the attention of some users.
I'm running Spyglass DFT on our front-end group's RTL with the intent
of increasing the quality of their netlists. I'm catching them with
their shorts down. All their bad code syntax, undriven nets,
unreachable clock domains, uncontrollable resets are hanging out
there for me to see -- PRIOR to synthesis! We're hoping to mandate
that RTL pass Spyglass checks at certain levels before synthesis is
run or before the netlist will be accepted.
I'm also finding bugs in some of our IP. Spyglass DFT is just a great
tool for quality control/assesment. We think this may save us from
having to go back to the design team for a new netlist every time give
us junk just so they can meet their schedule and look good to
management. Well, at least there's a chance. At least I have
something to show my management that proves how bad their "golden"
code is, before spending a week hacking at the netlist and failing
to get it through ATPG.
Atrenta support is really good (for us -- we're big global corp).
When a bit of our code caused Spyglass to die with an abnormal
termination and stack trace, they got us a patch and a workaround
overnight. There is an advantage from support staff in India for
us in the US afterall. Of course, one of us was up all night
talking to them.
- [ An Anon Engineer ]
SpyGlass DFT: What would we do without it?? I tell you, this is one of
the best things happened to ASIC world.
Before we started using this tool, our flow was: synthesize RTL and get
the netlist and run ATPG on pre-layout netlist in order to report the
test coverage. If the test coverage was unacceptable, we'd modify the
RTL and go through the same synthesis iteration until the test coverage
is acceptable.
SpyGlass DFT basically got rid of all this. It predicts the test
coverage at the RTL level itself. We found that the coverage predicted
by Spyglass DFT is within 0.5% of our final ATPG number.
This method provided a huge boost to our efficiency and cut down the
useless DC iterations. We parse the RTL, not only for linting, DFT
checks and other policies but also to predict our test-coverage. If
the coverage is unacceptable, we simply modify the RTL until we are
satisfied by the coverage number. The clean RTL is then synthesized to
produce quality netlist.
The other benefit of using this tool is that since most of the time the
coverage number is dependent on the clocking structure of the design,
it make sense to analyze the clocks of the design using this tool and
produce a clocking diagram which is subsequently used to produce the
much sought after SDC file with correct clock propagation through all
identified modes (case analysis points).
- Himanshu Bhatnagar of Conexant
Spyglass DFT helps out by identifying potential design problems very
early on. It really reduces the design cycle by not having to wait
after synthesis to find out DFT problems. It helps reduce need for
late re-architecture due to DFT. TestKompress is very helpful in
reducing DFT time.
- [ An Anon Engineer ]
So far, we have used Synopsys TetraMAX and it is sufficient.
LogicVision BIST is also used by us and is sufficient, but the tool
is very expensive.
- [ An Anon Engineer ]
I've done both LogicVision and Genesys flow but for a much simplified
version of designs. In my experience, I feel that the LogicVision flow
is fully automated and is highly a pushbutton approach for BIST
insertion. The Genesys tools requires more scripting from the user
and manual insertion of BIST structures into design (which can be
cumbersome for huge designs.) The Genesys documentation also needs
to be improved.
- Suresh Kumar of Open-Silicon Research Ltd.
LogicVision BIST. I've not personally used their tools, but they are
used in our flow. And while in the end, I've been told, we get what
we want, but to get there can be alot of "fun".
One area that I've been trying to figure out ways to deal with is a
chip with late design ECO's on a sub-block of a major design block
that has been LogicVision'd. Based on what I've gotten from the
folks who run the tool, there doesn't seem to be a way to change RTL
for the block in question. You have to synthesize the block, and
re-apply all of the LogicVision changes to just that block... at
least this has been the answer that I've gotten when I've asked this
question.
Since changing the RTL might add/remove a flop or some names might
get changed and since LogicVision places flops onto internal chains
and puts LV wrappers around the flops, I've been told that the only
way to work it is from the top...
What I'd like to see, is for the LogicVision tools to be able to save
off a "what LogicVision did to the block for test" file... and what
ever else is necessary so that for late-in-the-game fixes, so I'm not
left w/ trying to do manual gate ECOs on synthesized netlists, which
can be a very harrowing experience these days. The more they try to
speed up tester time, the more difficult they make things. We don't
push gates anymore during a design. But you really still need to fight
in the trenches for this stuff late in the flow.
- [ An Anon Engineer ]
We used LogicVision in our last huge chip. We really pushed the
limits, encountered all sorts of headaches, but got the job done
eventually.
Used Fastscan many chips ago, seemed like the same story that time,
too. Nature of the beast perhaps. Fastscan may have improved since
then, but we had to really screw around with our architecture and the
sequence in which we did things to get it to work. Our guy who did it
is now on permanent disability because he fried his brain, but I am
not sure I can blame that on Mentor.
- [ An Anon Engineer ]
TestKompress: Great tool and we use it on all of our large designs.
Several of them have taped out and are already in production. We
generally target 10X compression. The beauty of this tool is that the
area overhead is minimum compared to its rivals. The flow is a bit
convoluted, however once you define the methodology, its simple.
- Himanshu Bhatnagar of Conexant
Actually, I don't use TestKompress, despite the strong effort from the
Mentor sales guys to get me to use it. The problem I have with it, is
that it's too intrusive on my design. I have my own script for doing
scan stitching. I don't use Mentor DFT Advisor and TestKompress
actually adds logic into your design.
I also never used TetraMAX. The other DFT tools I've used in the past
were Cadence Testbench, SynTest ASICgen. I've also used Sunrise
briefly, but that was long long agao.
With that said, I basically have four things I dislike about Fastscan
1. The Fastscan GUI is extremely weak. It treats the whole design as
a flat netlist, and does not display wire names. The other big
problem with the GUI is that if you try to trace a node that is
disconnected, it hangs for a long time before it comes back with a
huge block that it thinks the wire should connect to.
2. The flow of Fastscan is sub-optimal for large design. Every time
you start the tool it has to read in the netlist (they do have a
binary form, so that speeds things up a bit, but that's still about
30 minutes), but then Fastscan has to go through the chain extraction
process again before starting useful work (that's another hour).
3. Fault simulation slow for multi-cycle. Fault simulation is extremely
slow if you have multiple clock pulses in capture. This is a problem
Mentor looked at, and they suggested the use of a faster machine,
which does help quite a bit.
4. No bridging fault model. Fastscan doesn't currently have support
for bridging faults. This totally surprised me, because I thought
everybody had support for that. They do have BCE (bridging coverage
estimate) which is totally bogus. Mentor did promise that it will
be out soon, so I'm holding my breath till then.
In terms of the Fastscan positives, it was relatively easy to get
started with it. It's nice that they have library support from all the
vendors we've used, so I didn't have to create memory models. The
patterns worked almost immediately. The Fastscan manual is very good,
although a few more links would be nice to find related topics. Their
response for support is excellent (but I've seen that with all other
DFT vendors as well).
- Samy Makar Azul Systems
Only familiar with Fastscan. It works OK, but should have better
documentation.
- [ An Anon Engineer ]
Now I use TetraMAX, but in the near future will change to Mentor flow.
- [ An Anon Engineer ]
I've only used TetraMax, have had good success with creating at-speed
delay faults patterns.
- [ An Anon Engineer ]
TetraMAX works for us.
- Robert Cram of Gennum Corp.
We have used TetraMAX for a number of years for scan pattern
generation. Results seem OK and tool stability OK. We are however
trying to push the pattern generation onto our vendors as we see
this as a task that we only need to verify, not provide.
- [ An Anon Engineer ]
I think Synopsys DFT Compiler/SocBIST/TetraMAX is easy and powerful
and combined with DC. Cadence test should be combined with their
Get2chip.
- [ An Anon Engineer ]
What about test pattern verification, test pattern and test program
development, and failure organization tools from Teseda and Inovys?
I know there are a good number of folks from the top 30 Semi houses
that are using them -- especially the failure feedback tools that
provide the pattern/chain/bit format back to the ATPG tools for
debug and diagnostics.
- [ An Anon Engineer ]
Inovys sells testers that use STIL directly, do they understand scan
chain ordering and can tell you exactly which flop failed. They have
smaller desktop systems starting at $49K for 64 pins going up to large
systems with up to 1,536 pins and up to 400 MHz clock rates. Capture
memory is 32 M and pattern memory looks very configurable so it's
something like 100 billion divided by the number of pins.
Syntest sells a complete line of test related tools, including scan
insertion, ATPG, BIST and boundary scan. Their scan tool allows using
a very large number of small scan chains that appear to the user to
be a small number of larger scan chains, but can save a great deal of
tester time despite using only a few pins. Very few fault simulators
can accept SDF (tools from Mentor and Synopsys can't, the Cadence
offering is the antiquated Verifault-XL). If your circuit is nicely
behaved you won't need this, but if it isn't our recent benchmark shows
the Syntest tool (Turbofault) is about two orders of magnitude faster
than Verifault-XL.
- John Weiland of Intrinsix Corp.
Test tools are not for our role.
(We usually ask ASIC vendors for DFT insertion and ATPG)
- [ An Anon Engineer ]
Index
Next->Item
|
|
