( ESNUG 292 Item 5 ) ----------------------------------------------- [6/4/98]
Subject: (ESNUG 290 #4 291 #4) Testing Embedded RAMs Via Full SCAN Chains
> Depending on the size of the ram, this is alot of overhead. What I've been
> working on lately is an independant RAM BIST test (which LSI can generate
> for you automatically) and then I mux in an XOR tree to bypass the RAM
> during internal Scan.
>
> For smaller RAMs, I just used the DW RAMs and did an insert_test.
>
> This brings up a good question. LSI is currently saying that they don't
> want the scan chain hooked up in the netlist because they can do a better
> job or routing if I just do a:
>
> set_scan_configuration -style multiplexed_flip_flop -route false
> insert_scan
> remove_license Test-Compiler
>
> Does anybody have any experience with this?
From: samy@corp.cirrus.com (Samy Makar)
John,
1. Scan for RAMS: One thing you have to be very very very careful
about is that even if you use scan to apply patterns to your
rams, you CANNOT use an ATPG to generate the patterns. No matter
how good an ATPG tool you use, the patterns will be very poor.
The problem with is that the stuck-at model that is used for
random combinational logic doesn't cover a lot of the defects
that really occur in the rams. There are other fault models
that are often considered: transition fault, coupling faults, etc.
The good news is that there are simple algorithms for generating
patterns for RAMS, and that's were BIST comes in. Now, it's always
important to separate BIST for rams and BIST for random logic. For RAMS
the area overhead should be quite small. From what we've done here, it
ranged between 600 - 2k gates. I don't remember the size of the RAMS,
but the percentage gets smaller as RAMS get bigger. Now, how do you test
the RAMBIST... with scan of course :)
Apart from LogicVision, there is also Mentor Graphics, Gensys TestWare,
SynTest, and probably some others whose names I've forgotten.
2. Why LSI doesn't want you to insert_scan: I haven't had any
experience with LSI itself, but have dealt with the same problem.
If you do insert_scan before you know the placement of your flip-flops
then you can seriously affect placement and routing results. What
I've seen (and that's using an internal tool) that I can reduce the
stitch wire lengh by 80 to 90% by choosing the chain order after
placement is done. The guys who do the routing really appreciate this.
Of course, I'm only assuming that this is why LSI does not want you to
insert_scan, but they could have other reasons that I'm not aware of.
- Samy Makar, DFT Methodologist
Cirrus Logic
---- ---- ---- ---- ---- ---- ----
> Thank you for the pointer to LogicVision -- I was not aware of them. My
> only data has been LSI's BIST offerings, which are expensive in gates.
> I sent a note to LogicVision and will let you know what I think of their
> products. My idea of using full-scan chain to test the RAMs still stands,
> since it would have zero-gates of overhead. However, I don't know if it
> is feasible in terms of pattern length or pattern capabilities. Are there
> any other BIST companies that you know of that I could contact. Also, I'm
> very familiar with pattern-based RAM testing, since I used to design SRAMs.
>
> - Victor J. Duvanenko
> Truevision
From: Charles H Small <charles.small@worldnet.att.net>
John:
I have heard from readers saying that they don't want to "waste" silicon on
BIST. I have also heard from beleaguered test types that they will spend
longer developing a test program for an ASIC that the design types spent
designing it.
Do you suppose that if this situation is true that management will, after
taking a nanosecond's look at the bottom line, try to reign in designers and
have them turn out ASICs that are more testable?
I have my doubts. Designers have been harangued since day one about
designing for test. Would you agree that such considerations -- if they
are considered at all -- go out the window in preference to performance?
- Charles H Small
Senior Technical Editor
Computer Design Magazine
---- ---- ---- ---- ---- ---- ----
From: Chuck Benz <cbenz@nexabit.com>
John,
Just in case you didn't know, and hadn't heard from anyone else, my
experience with LSI's BIST generator was that you didn't use the generated
results directly -- you needed to run it through Synopsys. This cut the
size of the logic for a 512 word by 64 bit 2 port memory nearly in half !
After the fact, an LSI engineer confirmed that this was the right thing to
do. Sounds like there's some inefficient logic generation there. This was
on a 500K design done last summer, at my previous employer, DEC.
- Chuck Benz
Nexabit Networks
---- ---- ---- ---- ---- ---- ----
From: Michael Collier <collier@anchorchips.com>
Hi John,
I have some experience doing ram testing using scan. I didn't get to the
point of automating the process but I don't think that would be to difficult
if the scan interface to the internal rams was standardized in the design
( unfortunately ours wasn't ). We controlled the write enables by not
allowing them to happen when scan enable was asserted ( i.e. when shifting
in the scan pattern). We also had to add one additional flop for each ram
to prevent double write enable pulses.
I ran the scan on a Teradyne A580 tester and I was able to successfully
read and write to the internal rams any pattern I wanted. Test time and
test vector size can become prohibitive with large rams ( we were only doing
16X32 rams) but one easy way to minimize this is to make the ram control
logic on a single short chain. This prevents wasting a lot of cycles
getting data in and out of the chip.
One side to effect to having imbalanced scan chains is that you may increase
you test vector size and test time for normal scan patterns because each
scan vector must clock in the number of cells in the longest chain. The
longest chain is minimized when all chain lengths are equal so any imbalance
creates a longer maximum chain.
It's true the ram testing is not true at speed testing but with a little
clever design and test program work you can control the access time to the
rams. In summary ram testing through scan is doable and does have a minimal
impact on area ( one extra flop per ram). The two drawbacks are no true at
speed testing and increased test time.
- Michael Collier, IC Verification Engineer
Anchor Chips San Diego, CA
---- ---- ---- ---- ---- ---- ----
From: "Michiel Ligthart" <michiel.ligthart@ieee.org>
Hi John:
I recently stumbled on a startup named Syntest who, among other scan test
offerings, does RAM test.
Product name is TurboBIST, I believe. You can find them at www.syntest.com.
- Michiel Ligthart
Ex-Exemplar, Ex-Escalade
|
|
