( ESNUG 360 Item 11 ) -------------------------------------------- [11/02/00]
From: Bejoy Oomman <bejoygo@genesystest.com>
Subject: Genesys Replies To Industry Gadfly "Memory BIST Follow-Ups" Column
Hi John,
Thank you very much for your kind coverage of Genesys Testware memory BISTDR
solutions. Let me annotate my answers to the questions raised.
John Cooley wrote:
> Last month I gushed about GeneSys Test's BISTDR. BISTDR is a
> paramaterized, synthesizable mem BIST cell that, on power-up, tests all
> your memory and remaps all bad addresses to working spare address spaces.
>
> The neat thing about e-mail and having a column in EE Times is that it
> gives 165,000 readers a chance to add their 2 cents. The first to write
> was Cliff Whitmore of 3D Labs. "I'm trying to figure out the actual
> mechanics of how they make remapping work. Do they rely on a specific
> memory technology (from a particular vendor), or do they insert logic
> between my address generation logic and the RAM for the remapping, or do
> they blow a fuse map at wafer test, or what???"
Our BISTDR can work with any memory compilers and do bad cell remapping
fully externally. This entails some performance penalty due to muxes at
the data input data output and address lines for remapping. If the memory
has a redundant cells and repair circuitry (fuses or muxes) in it the
BISTDR can also take advantage of it to eliminate the performance penalty
of external muxes. We just officially announced this capability this week
at the International Test Conference.
> The second to write was Hank Walker of Texas A&M. (Hank has this way of
> sometimes tersely cutting to the technical chase.) He sent me a one
> sentance letter. "IBM has done this in their memory BIST engines for
> many years."
As far as I know IBM has used this for embedded DRAM macros for years. In
fact, we developed this technology 2 years ago for embedded DRAMs. However
embedded DRAMs never really took off and third party embedded DRAM IP
developers became networking IC companies (Silicon Access, Mosaid). We
re-architected the solution for large embedded SRAMs this year. Fortunately
for us, all networking IC vendors have very large SRAMs that need this now.
Compaq (formely Digital) has used this technique for its Alpha Cache SRAMs.
So has Lucent. IBM, Compaq and Lucent use only fuses for the actual repair.
We can use either fuses or muxes for repair. Most of our customers like
muxes for repair since fuses increase the unit cost of the part
significantly due to additional fuse blowing steps required. Fuses are also
notoriously unreliable and do not scale well with technology. However
muxes have a small performance penalty over fuses. Fuses also make BISTDR
transparent to the user. People typically use fuses for the highest
performance or the highest volume memories.
> And Roderick McConnell of Infineon half-humorously warned me to "Beware:
> many cells fail only after a while. If you are trying to repair these at
> power-on, you may end up doing a lot of rebooting. Perhaps you're happy
> that a "bad bit" in an SRAM causes the connection to be lost when you are
> using a mobile phone with a long-winded salesperson who just doesn't stop
> talking -- but that's tough to predict."
This is the main technical objection raised by our potential customers. It
is true that some SRAM failures are temperature and voltage sensitive. Some
failures also occur in the field after some time. We are not addressing
these failures with BISTDR. We are trying to improve yield by correcting
static failures that are visible during package part testing. Static cell
failures are the most common source of yield loss for ICs with large
embedded memories. During memory characterisation testing or volume
manufacturing testing we have to make sure that the repair signature is
consistent at different voltage and temperature points to ensure that the
chip has only correctable static failures.
> "Have you looked at Virage's STAR (self-test and repair) capability yet?
> We are beginning to use their SRAMs, and this capability looks very
> interesting," wrote Jeff. "Basically, you get a scan interface to disable
> addresses and remap them. It's very fine-grained. The overhead is very
> low, because it is built into the hard macros."
>
> (Why this was odd was that Virage isn't really known in the test world.
> See for yourself. http://www.VirageLogic.com Virage makes COT embedded
> memory compilers for fabs like TSMC, UMC, and Chartered. But it's not
> all that surprising to be testing memories since they make them.)
>
> I phoned Virage to see what was up.
>
> It turns out that Virage's STAR generates memories sized from 64 k to 4 meg.
> "We have added redundancy with spare rows and columns in our embedded STAR
> memories," said Alex Shubat, the CTO of Virage. "It can do off-chip test
> with laser fuse-box repair at manufacture. It lets you skip using a memory
> testor in fab. STAR can also do build in self-repair on power-up."
>
We work closely with Virage Logic to add support for their STAR compiler in
our products. I beleive the self-repair at power-up mentioned by Alex is
our BISTDR product. STAR contains the dynamic repair circuitry already,
so we need not synthesize the remapping circuitry. This eliminates the
performance penalty of BISTDR. Other memory compilers like Dolphin Tech's
RAMpiler are developing similar capabilities.
- Bejoy Oomman
Genesys Testware Fremont, CA
|
|
