9
\$\begingroup\$

I'm right now combing the electrical engineering literature on the sorts of strategies employed to reliably produce highly complex but also extremely fragile systems such as DRAM, where you have an array of many millions of components and where a single failure can brick the whole system.

It seems like a common strategy that's employed is the manufacturing of a much larger system, and then the selective disabling of damaged rows/columns using settable fuses. I've read[1] that (as of 2008) no DRAM module comes off the line functioning, and that for 1GB DDR3 modules, with all of the repair technologies in place, the overall yield goes from ~0% to around 70%.

That's just one data point, however. What I'm wondering is, is this something that gets advertised in the field? Is there a decent source for discussing the improvement in yield compared to the SoA? I have sources like this[2], that do a decent job of discussing yield from first principles reasoning, but that's 1991, and I imagine/hope that things are better now.

Additionally, is the use of redundant rows/columns still employed even today? How much additional board space does this redundancy technology require?

I've also been looking at other parallel systems like TFT displays. A colleague mentioned that Samsung, at one point, found it cheaper to manufacture broken displays and then repair them rather than improve their process to an acceptable yield. I've yet to find a decent source on this, however.

Refs

[1]: Gutmann, Ronald J, et al. Wafer Level 3-d Ics Process Technology. New York: Springer, 2008. [2]: Horiguchi, Masahi, et al. "A flexible redundancy technique for high-density DRAMs." Solid-State Circuits, IEEE Journal of 26.1 (1991): 12-17.

\$\endgroup\$
9
  • 3
    \$\begingroup\$ Row and column redundancy is still used today. Block-level redundancy was used in the Itanium 2 L3 cache (see Stefan Rusu et al., "Itanium 2 Processor 6M: Higher Frequency and Larger L3 Cache", 2004). Another consideration for yield is binning both for speed/power/operating temperature and "capacity" (e.g., chip multiprocessors can be sold with a range of core counts; even high defect count DRAM might, in theory, be sold as a half-capacity part). \$\endgroup\$
    – user15426
    Commented Feb 26, 2015 at 23:06
  • \$\begingroup\$ fascinating, thank you. Looking at the cache design, I see 140 subarrays, each with 2 sub-banks, which in turn have eight 96x256 array blocks. Each block has 32 bits. Which means there's, in total, 140*2*8*96*256*32 = 1.762x10^9 bits required to produce 48x10^6 bits of storage. Is this correct? \$\endgroup\$
    – Mephistopheles
    Commented Feb 27, 2015 at 0:02
  • 3
    \$\begingroup\$ No, the 32 bits are part of 96x256 block (12 cache ways * 8 * 4 * 32 bits per cache line). It should also be noted that some of the bits are used for ECC, so the cache had 6MiB of data. (The use of ECC introduces another wrinkle in yield under binning. ECC requirements vary by application and excess ECC can be used to support lower voltage (or refresh rate for DRAM) without data loss for a lower power part as well as provide correction for manufacturing defects. Such is more a theoretical consideration as marketing factors generally do not allow such flexibility.) \$\endgroup\$
    – user15426
    Commented Feb 27, 2015 at 0:49
  • \$\begingroup\$ thanks again. This is more to gain an estimate for the overall cost of the manufacturing process. That is, how much additional board space (as a representative for physical resources expended) is required to reach this 6MiB? I'll try to estimate this from the area taken up by the L3 cache and get back to you. \$\endgroup\$
    – Mephistopheles
    Commented Feb 27, 2015 at 3:23
  • 2
    \$\begingroup\$ Using bit cell area does not account for row decode and other overhead. The area overhead of redundancy could be simply estimated by recognizing that 4 of the 140 subarrays are spares (a little less than 3% overhead), ignoring extra routing overhead. It should also be noted that 3MiB L3 cache versions were sold, so yield for 6MiB versions was allowed to be lower. (I would guess that using larger than minimum-sized transistors for the SRAM cells, for lower leakage, might also decrease the effective defect rate slightly.) 136 used subarrays indicates 8 for ECC (6+% overhead). \$\endgroup\$
    – user15426
    Commented Feb 27, 2015 at 12:41

1 Answer 1

Reset to default
1
\$\begingroup\$

No manufacturer will ever release yield data unless they have to for some reason. It's considered a trade secret. So- to answer your question directly, no- it isn't advertised in the industry.

However, there are many engineers whose jobs are to improve the line throughput and end-of-line yield. This often consists of using techniques like binning and block redundancy to make losses off the line function enough to be saleable. Block redundancy is certainly used today. It's pretty easy to analyze:

(failed blocks per part)/(blocks per part)*(failed blocks per part)/(blocks per part)

That'll get you the probability of both parallel blocks failing. I'd doubt you'd end up with a yield as low as 70%, as typically 90% is the minimum acceptable yield.

\$\endgroup\$
1
  • 2
    \$\begingroup\$ While I appreciate your answer, @Paul-a-clayton provided this information and was also able to cite real publications (specifically the Itanium 2) in the comments. Furthermore, while block redundancy is discussed in those papers, it says "This use of subarrays optimizes the die area utilization without constraining the core floor-plan" with no mention of fault-tolerance. If you have papers that specifically propose block redundancy as a tool for error addressing, they would be greatly appreciated. \$\endgroup\$
    – Mephistopheles
    Commented Apr 8, 2015 at 16:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.