David Kanter (dkanter.delete@this.realworldtech.com) on August 4, 2021 8:58 am wrote:
> --- (---.delete@this.redheron.com) on July 31, 2021 6:23 pm wrote:
> > David Kanter (dkanter.delete@this.realworldtech.com) on July 30, 2021 1:52 pm wrote:
> > > Doug S (foo.delete@this.bar.bar) on July 30, 2021 11:01 am wrote:
> > > > Heikki Kultala (heikki.kult.ala.delete@this.gmail.com) on July 29, 2021 11:18 pm wrote:
> > > > > Doug S (foo.delete@this.bar.bar) on July 29, 2021 5:44 pm wrote:
> > > > > > None of it really matters, since the process names have nothing to do with a physical dimension
> > > > > > anywhere in the design. It is just a placeholder for "2x the transistors in the next generation"
> > > > > > but we aren't even seeing that lately as TSMC only got 1.8x scaling on N5 and 1.7x on N3
> > > > > > - but TSMC wasn't calling those 5nm and 3nm, it is mostly outsiders doing so (maybe TSMC
> > > > > > does as well, but probably only because outsiders referred to them that way)
> > > > > >
> > > > > > Who knows what TSMC will call the stuff below N2, will it be N1.4 or P1400 or just
> > > > > > choose another letter at random, multiply by 10, so X14 then X10 and so on.
> > > > >
> > > > > TSMC did not get 1.8x scaling on N5. In reality (by synthesizing any
> > > > > reasonable piece of logic than does something) it's much worse.
> > > > >
> > > > > Or, lets say that TSMC might have gotten 1.8x for single best-case standard cell
> > > > > component type for their marketing materials, but TSMCs customers get MUCH LESS
> > > > > than 1,8x for their real-world designs that actually do something useful.
> > > >
> > > >
> > > > Cache scaling is not as good, so customers like Apple who added a lot of cache when going
> > > > to N5 get worse scaling. For N5 to N3 TSMC states logic scales at 1.7x, cache scales at 1.2x
> > > > and I/O scales at 1.1x. I don't recall seeing them report cache scaling for N7 to N5.
> > > >
> > > > Anyone know why cache scaling is becoming a problem? Might it have to do with congestion in the metal
> > > > layers? If they do can something like Intel's PowerVia and have metal sandwiching the logic, the metal
> > > > routing will become easier - especially for parts that will be stacked which is more and more common.
> > >
> > >
> > > Good question: There's a bit of an answer here:
> > >
> > > https://www.linkedin.com/pulse/cmos-density-scaling-cppmxp-metric-ali-khakifirooz/
> > >
> > > SRAM size is largely determined by fin pitch and isolation pitch.
> > >
> > > Quoting here:
> > >
> > >
> > >
> > >

The choice of fin pitch, however, also determines the isolation pitch. With a typical practice
> > > of printing a sea of fins at constant pitch and removing unwanted ones, the minimum isolation
> > > pitch is equal to twice the fin pitch, or roughly 1.5× the minimum metal pitch.
> > >
> > > As seen in Figure 3, isolation pitch already lagged behind CPP and MxP in the most recent
> > > planar technologies. The introduction of FinFET technology simply guarantees that it will
> > > always lag behind. Since the isolation pitch determines the SRAM cell size, such a practice
> > > produces SRAM bitcells larger than what is doable with a certain lithography.
> > >
> > > A solution is to print fins at different pitch when needed. In fact the smallest SRAM
> > > cells reported so far all printed the fins at a pitch larger than that used in logic
> > > and avoided the need to “remove-every-other-fin” principle. In SADP, one can simply
> > > print mandrels somewhat wider and spaced further away from those in logic.
> > >
> > > Of course, one concern is the non-uniformity of the resulting fin width [7]. An extension of
> > > this approach to SAQP is a bit more complicated [8], but worth considering, given the fact that
> > > even “remove-every-other-fin” will require double patterning. As a side note, I should mention
> > > that the width of the isolation region is also limited by the requirement to place gate contacts
> > > outside the active region and innovations are needed to reduce this area penalty.
> > >

> > >
> > > So bottom line, FinFETs make dense SRAM a little tricky in addition
> > > to the need for boosting logic to enable good read/write margins.
> > >
> > > David
> >
> > It's also worth pointing out that "cache", at least for Apple,
> > is a *lot* more sophisticated than what's in your textbooks.
> > (I assume something similar is true for other vendors, though likely lagging somewhat.)
> >
> > What this means is that "actual" cache at any node will lag "theoretical cache" and more
> > so every year, as actual cache adds more transistors and more wires. Where TSMC may be completely
> > correct in claiming that can get 100 units of "textbook" cache in 1mm^2, Apple may get only
> > 80 units of "Apple 2021 version super-low-energy" cache in the same 1mm^2.
> >
> > What sorts of changes?
> > - split caches into very small subarrays that can be independently powered
> > - very careful charging of bitlines (with the voltage changing over time) to minimize energy
> > https://patents.google.com/patent/US10720193B2 and https://patents.google.com/patent/US20190272859A1
> > - separating the logic voltage from the memory storage so the logic can run at lower voltage
> > https://patents.google.com/patent/US7355905B2
> > - which expands to a variety of different things -- vary the memory storage voltage under
> > certain conditions https://patents.google.com/patent/US20100182850A1 or add a third voltage
> > used when writing the memory https://patents.google.com/patent/US8885393B2
> > - then you start adding redundancy to ensure your cache works in the face of a
> > few manufacturing errors, like https://patents.google.com/patent/US10592367B2
> >
> > (These are just at the level of a physical SRAM bank. There is, of course, the additional
> > level of more logic added to every cache every year, but I'm ignoring that.)
> >
> > I've included only a few patents to make the point; there are many more. They start in the early
> > PA Semi days, and maintain a constant pace, with a number of innovations even as late as 2018.
> >
> > I'm not in a position to calculate how much overhead all this fanciness adds. My guess is
> > it has limited effect on the transistor budget, but noticeable effect on metal congestion.
>
> I thought I'd share an excellent paper by Intel's SRAM group that describes
> some of the challenges of FinFET based SRAMs and the assist logic needed.
>
> ISSCC 14nm SRAM paper
>
> In some sense, the high-density SRAMs may not even be readable
> or writeable without this kind of assist circuitry!
>
> David


Thanks !