[HN Gopher] U.S. focuses on invigorating 'chiplets' to stay cutt...
___________________________________________________________________
U.S. focuses on invigorating 'chiplets' to stay cutting-edge in
tech
Author : adapteva
Score : 56 points
Date : 2023-05-12 15:09 UTC (7 hours ago)
(HTM) web link (www.nytimes.com)
(TXT) w3m dump (www.nytimes.com)
| jeffbee wrote:
| I am impressed by the fabrication technology for these
| heterogenous systems. It was already complex enough to fabricate
| a CPU, but chiplets require incredible precision for placing the
| die on the interposer wafer for soldering. And the coplanarity of
| the whole assembly is critical, else it will be impossible to
| effectively cool. It's incredible that any of it works.
| adapteva wrote:
| Agreed...although not sure if it's any more impressive than
| automated fabs that churn out nanometer precision transistors
| with billion transistors chips costing less than a cup of
| coffee per chip.:-)
| [deleted]
| neonate wrote:
| https://archive.ph/pUgCO
|
| http://web.archive.org/web/20230512160522/https://www.nytime...
| Our_Benefactors wrote:
| https://archive.is/pUgCO
|
| Will this eventually give me more FPS in cawadooty?
| jeron wrote:
| Your computer may be able to run minesweeper one day
| tikkun wrote:
| I'm not the OP, but I'd be curious for an informed HN reader's
| take on this.
| yaantc wrote:
| By using several small chips instead of a big monolithic one,
| it's possible to reduce costs in 2 ways:
|
| 1) the yield is better for a small die. For a given density of
| defect, a big chip will have a higher probability to have a
| defect than a small one. Basic example: you use 4 chips instead
| of one, and one defect that would kill the big chip will only
| kill one of four of the small chips. It's more subtle than
| this, there are simulators on the web to see the impact of size
| on cost for those interested;
|
| 2) parts of the chip can use cheaper nodes. For example the
| I/Os not only can use less advanced and cheaper nodes, but
| those nodes have often better support for analog IPs.
|
| On the flip side, communications that were internal in the big
| monolithic die now must cross those small dies boundaries. And
| communications is expensive: you would certainly not want to
| handle this through a PCB. Instead, more local short range
| interconnects are used that are much more power efficient than
| a PCB interconnect (but not as good as in die). These require
| sophisticated packaging, which adds to the cost. Still for
| complex chips the net effect is positive, see what AMD did
| (with Intel now following).
| eimrine wrote:
| Am I informed right that chiplets tend to live not very long
| in comparison to single chips? I have a friend who uses to
| repair computers and he claims that "combines" (that is how
| he calls chiplets) tend to break chip vs plate connections
| and he can not repair this, all what he can is to replace the
| whole BGA thing.
| JonChesterfield wrote:
| One chiplet probably can't be sanely replaced if it dies,
| but equally we couldn't really cut out and replace part of
| a single die either. So that seems like a wash.
|
| I could believe they're more vulnerable to mechanical
| damage. Also seems possible that the thermal expansion
| introducing mechanical stresses is more of a problem. I
| suppose we won't really know for a while yet.
| adapteva wrote:
| Not sure what your friend is referring to, but packages
| with exposed dies are definitely more fragile than ones
| with built in heat sinks.
| adapteva wrote:
| As a summary, the last 50 years has achieved smaller, cheaper,
| faster through monolithic integration Moore's Law). Cost and
| complexity of design and manufacturing is now making that
| approach impractical. Disaggregated design and manufacturing
| through small chiplets is "the next thing". A bit hyperbolic,
| but it gets to the point ..
| kccqzy wrote:
| I'm not at all an expert in hardware, but I have experience
| using chiplet-based chips in production and optimizing for
| them. Those chips are better from a performance per $ point of
| view, but they don't necessarily achieve the highest absolute
| performance. The main limiting factor appears to be latency for
| communication between chiplets. If you write anything with
| shared mutable memory you are affected by this. Simple atomic
| operations like compare-exchange is much slower if the threads
| run on different chiplets.
|
| However I fully expect this to be the future. The performance
| per $ is what really matters to the bean counters, and us
| software engineers will just have to write better software to
| work around it, perhaps with something like NUMA-aware
| scheduling that understands chiplets.
| bee_rider wrote:
| I wonder if it would be better to scale down cluster
| paradigms (MPI stuff), rather than trying to somehow scale up
| shared-memory paradigms.
| JonChesterfield wrote:
| Dropping cache coherency is a big lever for performance.
| That's definitely more annoying to program against than a
| magically coherent model though.
| tikkun wrote:
| I'm mostly meaning: will the best chips (CPUs and GPUs) in 2030
| use this method, or not?
| dotnet00 wrote:
| Barring some unexpectedly big breakthroughs in things like 3d
| stacking or in improving yields for increasingly complex
| process nodes, chips in 2030 will definitely be using this
| method.
| adapteva wrote:
| The best chips TODAY use chiplets. Check out Epyc, Ponte
| Vecchio, all high end GPUs and ML accelerators using HBM
| memory. A chiplet is generally defined as a chip/die with
| custom interfaces for in package communication.
| jeffbee wrote:
| I think what they are asking is if chiplets have a durable
| advantage, or a transitory one.
| adapteva wrote:
| The current leading edge processing products moved to
| chiplets because it was the optimal/only solution from a
| cost and performance perspecitve. If we assume that
| reticle sizes will stay roughly similar and process
| scaling will continue to slow, then it would seem that
| the future bends further toward chiplets...
| [deleted]
| georgeburdell wrote:
| Chiplets are the microservices of the semiconductor world. It's
| good in that smaller individual chips are cheaper to produce,
| and the whole package is more scalable, but it's bad in that
| there are interfaces that reduce performance vs a monolith
| verall wrote:
| I think this is a poor comparison because microservices exist
| to help code mirror the org chart while chiplets exist for
| physical engineering reasons.
|
| Microservices are _supposed_ to improve testability, reduce
| complexity, etc: it is an organizational choice. Chiplets add
| complexity: silicon interposer, tougher packaging, NUMA, etc:
| it 's an engineering choice with a tradeoff for better yield,
| chips reaching maximum reticle size, etc
| adfgionionio wrote:
| This isn't really true. Chiplets can be used to "break apart"
| what would traditionally be one chip, but also to more
| tightly integrate things that would previously have been
| discrete components on the motherboard and to use the right
| process for given a functionality.
|
| Consider AMD's approach. They use multiple CPU dies in a
| single package to build very high core count systems that
| would previously have required multiple sockets. Bringing
| these into one package can make communication more energy-
| efficient and faster, as well as simplifying other aspects of
| the system. They also use different processes for different
| dies. The "IO die" is fabricated on a slightly old process as
| it is not performance-critical while the best process is
| reserved for building cores.
| hoosieree wrote:
| Some folks I work with are interested in chiplets for
| secure/defense purposes. If you don't trust the fab but you do
| trust the integrator, the fab can make multiple little modules
| with well-defined interfaces, and your integrator can instrument
| the interfaces more easily than an entire chip.
| adapteva wrote:
| Yes, here have been a fair number of public DoD studies around
| the virtues of disaggregation when it comes to security.
| Minimize the people/things you have to trust (eg. RoT).
| JonChesterfield wrote:
| That makes total sense. The paranoid approach to software
| involves writing N separate pieces using teams that can't talk
| to each other to minimise how many people know what the overall
| system can do. Applying the same reasoning to hardware seems to
| end up with this conclusion (and probably some enthusiasm for
| FPGAs).
|
| I'm curious to what extent software built in this isolated
| silos scheme actually works, best guess is it's OK but slow and
| expensive to build. Same idea might apply here, i.e. it's a way
| to make hardware take longer to put together.
| bee_rider wrote:
| I'm sure they are smart, and are applying bigtime brainpower to
| the project. But my basically layman gut take is, it seems
| surprising that inside-the-package is a reasonable place to
| have an attack surface.
|
| And is it really impossible to sneak an antenna into chiplet?
| 867-5309 wrote:
| invigorating chiplets' _______?
___________________________________________________________________
(page generated 2023-05-12 23:00 UTC)