[HN Gopher] 100x defect tolerance: How we solved the yield problem
___________________________________________________________________
100x defect tolerance: How we solved the yield problem
Author : jwan584
Score : 34 points
Date : 2025-01-15 21:19 UTC (1 hours ago)
(HTM) web link (cerebras.ai)
(TXT) w3m dump (cerebras.ai)
| ChuckMcM wrote:
| I think this is an important step, but it skips over that 'fault
| tolerant routing architecture' means you're spending die space on
| routes vs transistors. This is exactly analogous to using bits in
| your storage for error correcting vs storing data.
|
| That said, I think they do a great job of exploiting this
| technique to create a "larger"[1] chip. And like storage it
| benefits from every core is the same and you don't need to get to
| every core directly (pin limiting).
|
| In the early 2000's I was looking at a wafer scale startup that
| had the same idea but they were applying it to an FPGA
| architecture rather than a set of tensor units for LLMs. Nearly
| the exact same pitch, "we don't have to have all of our GLUs[2]
| work because the built in routing only uses the ones that are
| qualified." Xilinx was still aggressively suing people who put
| SERDES ports on FPGAs so they were pin limited overall but the
| idea is sound.
|
| While I continue to believe that many people are going to
| collectively lose trillions of dollars ultimately pursuing "AI"
| at this stage. I appreciate the the amount of money people are
| willing to put at risk here allow for folks to try these "out of
| the box" kinds of ideas.
|
| [1] It is physically more cores on a single die but the overall
| system is likely smaller, given the integration here.
|
| [2] "Generic Logic Unit" which was kind of an extended LUT with
| some block RAM and register support.
| wizzard0 wrote:
| this is an important reminder that all digital electronics is
| really analog but with good correction circuitry.
|
| and run-time cpu and memory error rates are always nonzero too,
| though orders of magnitude lower than chip yield rates
| ajb wrote:
| So they massively reduce the area lost to defects per wafer, from
| 361 to 2.2 square mm. But from the figures in this blog, this is
| massively outweighed by the fact that they only get 46222 sq mm
| useable area out of the wafer, as opposed to 56247 that the H100
| gets - because they are using a single square die instead of
| filling the circular wafer with smaller square dies, they lose
| 10,025 sq mm!
|
| Not sure how that's a win.
|
| Unless the rest of the wafer is useable for some other customer?
| olejorgenb wrote:
| Is the wafer itself so expensive? I assume they don't pattern
| the unused area, so the process should be quicker?
| yannyu wrote:
| > I assume they don't pattern the unused area, so the process
| should be quicker?
|
| The primary driver of time and cost in the fabrication
| process is the number of layers for the wafers, not the
| surface area, since all wafers going through a given process
| are the same size. So you generally want to maximize the
| number of devices per wafer, because a large part of your
| costs will be calculated at the per-wafer level, not a per-
| device level.
| ajb wrote:
| Good question. I think the wafer has a cost per area which is
| fairly significant, but I don't have any figures. There has
| historically been a push to utilise them more efficiently, eg
| by building fabs that can process larger wafers. Although
| mask exposure would be per processed area, I think that there
| are also some proportion of processing time which is per
| wafer, so the unprocessed area would have an opportunity cost
| relating to that.
| Scaevolus wrote:
| Why does their chip have to be rectangular, anyways? Couldn't
| they cut out a (blocky) circle too?
| guyzero wrote:
| I've never cut a wafer, but I assume cutting is hard and
| single straight lines are the easiest.
| nine_k wrote:
| It's a win because they have to test one chip, and don't have
| to spend resources on connecting the chiplets. The latter costs
| a lot (though it has other advantages). I suspect that a
| chiplet-based device with total 900k cores would just be not
| viable due to the size constraints.
|
| If their routing around the defects is automated enough (given
| the highly regular structure), it may be a massive economy of
| efforts on testing and packaging the chip.
| bee_rider wrote:
| > Second, a cluster of defects could overwhelm fault tolerant
| areas and disable the whole chip.
|
| That's an interesting point. In architecture class (which was
| basic and abstract so I'm sure Cerebras is doing something much
| more clever), we learned that defects cluster, but this is a good
| thing. A bunch of defects clustering on one core takes out the
| core, a bunch of defects not clustering could take out... a bunch
| of cores, maybe rendering the whole chip useless.
|
| I wonder why they don't like clustering. I could imagine in a
| network of little cores, maybe enough defects clustered on the
| network could... sort of overwhelm it, maybe?
|
| Also I wonder how much they benefit from being on one giant
| wafer. It is definitely cool as hell. But could chiplets eat away
| at their advantage?
| IshKebab wrote:
| TSMC also have a manufacturing process used by Tesla's Dojo where
| you can cut up the chips, throw away the defective ones, and then
| reassemble working ones into a sort of wafer scale device (5x5
| chips for Dojo). Seems like a more logical design to me.
| mhh__ wrote:
| Amazing. I clicked a button in the azure deployment menu
| today...
___________________________________________________________________
(page generated 2025-01-15 23:00 UTC)