( ESNUG 422 Item 4 ) -------------------------------------------- [02/19/04]
Subject: ( DAC 03 #20 ) User Experiences With Genesys Memory Soft Repair
> Genesys makes BIST for logic and memories (including CAMs, which they
> say are better supported this year). Their memory BIST allows for soft
> repair of faults (note that the new Virage memory compilers allow for
> both soft and hard repair). Their boundary scan insertion tool is now
> hierarchical. They can insert ordinary boundary scan (not P1500, etc.)
> around internal blocks and do ATPG on one block at a time. They say
> they work with normal ATPG tools to do this; I didn't get to look at
> the flow.
>
> - from http://www.deepchip.com/items/dac03-20.html
From: [ The Horse With No Name ]
Hi, John,
Keep me anonymous.
A little background about our chips. We designed two big chips, each one
in excess of 5 Million gates, 500+ memory macros, 10M+ bits of memory, 300+
Mhz clocks, on a 130 nm process. We used off the shelf memory compilers,
and standard cell libraries. We have chips back and fully functional with
no issues found so far with any of our BIST / BISTR schemes.
With that many bits of memory, we knew we had to have memory repair for the
sake of getting reasonable yields. We scoured the market for vendors that
would provide solutions for repair. There were very few at that time, with
Genesys being the lead contender.
Genesys supports dynamic soft repair, which is essentially repair done at
power on reset, as well as fuse based repair. We decided to go with dynamic
soft repair for reasons that are fairly obvious. Dynamic soft repair is
done at power on reset, where the chip is at ambient termperature. Memory
defects can be temperature sensitive, with such defects appearing only at
higher temperature. So there is a possibility that the repair done at power
on reset will not catch all defects. There are ways to screen these during
final test to weed out such temperature sensitive parts, so that they never
show up on the field.
There are a few issues that one needs to be aware of with repair schemes
implemented outside the memory:
1. Extra logic is added at the outputs for column repair, increasing
the access times
2. Extra logic is added on the address lines for row repair, increasing
the setup requirements on those bits.
3. Adding a column with muxing done outside of the memory adds
inefficiency in the repair scheme. Let us say we pick a memory
configuration with 4 banks. By adding one column, one could
potentially repair one bad bit per bank, ie a total of 4 bad bits;
one in each bank. But since there is no visibility on the internal
bank access bits, we can only really repair one bad column for the
whole memory. So there is a loss in efficiency.
Now regarding our experience with Genesys -- It was painful, and took us
quite a bit of effort to insert BIST/BISTR into our designs. Now, one has
to put the pain in the context of what we were trying to do. For smaller
chips with a lot less memory, it will definitely be very straight forward
and easy. Genesys has also been improving their tools, and hence things
will be a lot easier now. In hindsight, it was well worth the effort. We
were the first ones that stressed their tools by the size of our designs
and the nature of the algorithms we picked for our implementation. There
were a lot of tool bugs that eventually got resolved, but it did generate
some grief. On the bright side, I wouldn't expect new users to find any
such issues.
- Configuring the software for the algorithms is not straight forward.
But the Genesys folks helped us quite a bit in coming up with right
configurations (as part of standard support).
- Quite a lot of upfront planning is required to
1. Set overall goals for the chip in terms of redundancy / repair
requirements, area budget for BIST overheads.
2. Select algorithms and implementations for each of the memories
such that those goals are met withing the area constraints
imposed.
Again, Bejoy and his support staff helped guide us through the process.
- The manual effort involved in inserting BIST is non-trivial. We did a
lot of automation to alleviate most of the manual tasks required for
BIST insertion.
- Integration into RTL could have been handled differently. There was
no way of simulating the actual BIST logic in RTL, other than through
synthesizing the BIST logic and instantiating the gate modules in RTL.
Empty simulation shells were provided which were essentially
placeholders for RTL simulations.
- Synthesis and PrimeTime scripts for individual BIST modules were
automatically generated by the tool. We had to write some wrappers on
top of their tool to go fix minor issues.
- Certain configurations yielded clock MUXing logic. In general we stayed
away from such configurations.
- Finally post-silicon BIST characterization required homebrew scripts
to decode the status bits that are part of the BIST scan chain but hard
to get at. Genesys has recently added automation for this in their
tools, and it can only help.
In conclusion, the effort involved was quite intense, but it was necessary
and had to be done. Silicon verification has shown no issues related to
BIST logic. Bejoy and his staff were very supportive throughout and helped
see us all the way through.
- [ The Horse With No Name ]
|
|
