ISSCC N2 and 18A has same SRAM Density.

[siliconbruh999]

GNR was released Sep 2024. Considering the catastrophic performance numbers Intel put up in 2P, I would have thought they would have released a fix by now if it was something easily fixed.

Even for 1P, GNR is trailing by ~ 20% which is still quite a difficult position for Intel to find itself in for the DC market where they are bleeding market share and profit badly.

I was personally thinking that CWF on 18A might be a serious competitor for Intel, but much is dependent on Intel figuring out the issues in tile to tile communications that appear to cripple ARL. In DC it seems like these problems would cause even more issues than it does in the desktop/laptop.

Phoronix has not benched GNR after release there are some quirks in other software as well

 

[OneEng]

Phoronix has not benched GNR after release there are some quirks in other software as well

True, but the 2P issues seemed to be prevalent across all software.

 

[nghanayem]

It is much worse than that! the mobile customers don’t want BPD, they also don’t want the Molybdenum (Mo) vias and eventually critical Mo interconnects that are coming. My understanding is the foundries may have to create: no BPD with Cu interconnect, and BPD with Mo interconnect, process versions for several nodes. BPD adds cost and Mo is more expensive than Cu, the mobile guys don’t want to pay for performance they don’t need.

I really don't get it. Wafer costs can be kept similar at same or better density, or density can be dramatically better if you are willing to increase wafer cost. And not wanting to move to different metallization schemes down the line WILL cause power-performance inversions vs prior nodes. It also feels weird to say they don't want to pay for performance they don't need since performance equals power savings. If they can run at lower voltages for a given frequency they can fit more functionality in a given battery life, or more battery life/cheaper cooling at iso functionality. If this is their mindset they should be using 32/28nm class nodes for all mobile-APs because nobody really *needs* more functionality than a Samsung S3 or iPhone 5 with the same all day battery life that even phones back then could do. To make maters even worse BSPD is a requirement for CFET. If you insist on not learning how to design chips for BSPD or fully taking advantage of it, what were you going to do stop adopting new nodes once CFET comes online? Because if some fabless house insisted on no BSPD but did't also stop before CFETs they would be in for one hell of a rude awakening once they needed to learn how to maximize BSPDNs and 3D stacked devices at the same time.

I think this is one of those instances where fabless design houses need to be reminded to stay in their lane and let the experts do their thing. Unfortunately foundry is a service buisness rather than a products or solutions business. So you give the customer what they ask for, not what you think will best fit their needs. It reminds me of a story I heard from a guy from a smaller foundry. While they were working on their 22/20nm class process they were weighing whether it made sense to adopt double paterning so they could push the minimum metal pitch a little farther. Due to the MMP for both options not being drastically different it was decided that losing bidirectional routing and increasing cycle time/wafer cost would not be justified by the minor minimum metal pitch/area reduction. If memory serves it was a mobile client who later asked this foundry why they were doing single patterned metals, when the leading foundry is doing double paterning metals so they could have a slightly smaller MMP. The foundry then explained their rational with the data they used for their process definition. This customer then told them that they don't want it that way, and to redefine the whole process around a slightly tighter MMP and double paterning. So this foundry did as they said. Then after like two years this customer came back to them and told them that they were 100% right with their original process definition and adopting a double patterned BEOL at that node was a mistake. They then asked the foundry to redefine the process again per the original plan. And so the foundry did as they were asked.

The moral of the story for any chip designers in the audience is your foundry or internal fab engineers are very smart and understand your needs and their own process. If they have strong data to support what they want to do is the correct choice; you should let them do it.

 

[Markwrob]

And yet, there is an age-old saying that applies: "The customer is always right. (Even when they're wrong.)"

Really appreciate the discussions here, great information!

 

[OneEng]

I hear you guys. I do recall having a customer ask for a specific architecture. This architecture was going to result in the need for a small army of engineers to maintain it once it was launched. I did exactly as they asked. The customer was very happy with the delivery ..... and the entire program was canned 3 years later (due to high maintenance cost that could not be justified relative to the savings) completely destroying the business case for doing the program in the first place.

Sometimes, if you do exactly what the customer asks, the customer goes under, and your sales go under with them.

It's a very sticky wicket. Do what is asked, even if it has no future? Or do what is best and serve clients that are OK with it?

I have always chosen to go with what the customer says ..... even when they are wrong. More often than not, this results in a favorable outcome OVERALL as you are well regarded by the customer and any they speak to. One program isn't the entire ball game, so you have to play the odds that other follow on work will sustain the business.

 

[cliff]

I have often asked my PDK team to make the stdcells tighter....then we decrease the utilization % so they will route.