Hacker News Reader

Comment by msbarnett | Hacker News Reader

All of the M1/Pro/Max/Ultra shared the same fundamental core design. Presumably the same will be true of the M2 series.

As someone else here said, fab nodes are more like Lego blocks than a printer’s dpi – moving a design to a new node means rebuilding it in terms of the new node’s building blocks, not just “shrinking the design”.

So if the M2 Pro/Max/Ultra are intended to follow the same “reuse the cores (possibly rearranged) with more GPU blocks/cache etc” it seems unlikely. But if the make a design break within the M2 series then it’s possible?

I’d expect Apple to follow their historical behavior and lead with the next A-series phone processor on the new node first. M1 Pro/Max/Ultra chips have huge surface areas – since process defect rates are driven down over time, it makes sense to start with your smallest chips first, so that you can get good yield out of your big chips once the defect rate is lower.

View on HN

It wouldn't be the first time though that Apple used different process nodes in the same chip "generation".

- A5(X) 32nm and 45nm - A9(X) 14nm and 16nm - A10(X) 16nm and 10nm

If apple wanted to use N3 for the A15 or the M2 then they'd have designs pretty much ready but due to TSMC delays didn't roll those into production.

I'm pretty sure Apple does a few designs in parallel and react according to what the supply chain and market conditions allow.

Yes. In addition, the parent comment assertion is incorrect. The M1 and M1 Pro/Max did not use the same IP but just scaled.

Indeed, the core designs were different. The M1 had A14 CPU cores, while the pro/max were based on the A15.

A14 —> M1 A15 —> M1 Pro/Max/Ultra, M2

So it stands to reason

A16 —> M2 Pro/Max/Ultra, M3

Though that does not take into account the process node.

Are you sure about that? Everything I can find says that the M1 Pro and M1 Max do use the same cores as the M1, which are not based on the ones in the A15.

I’ll find a reference, but that’s why the efficiency cores on the pro/max are much faster.

As an example of what I find when I look, here's Anandtech: https://www.anandtech.com/show/17024/apple-m1-max-performanc...

'We had indicated in our initial coverage that it appears that Apple’s new M1 Pro and Max chips is using a similar, if not the same generation CPU IP as on the M1, rather than updating things to the newer generation cores that are being used in the A15. We seemingly can confirm this, as we’re seeing no apparent changes in the cores compared to what we’ve discovered on the M1 chips.'

And Wikipedia: https://en.wikipedia.org/wiki/Apple_M1

'The M1 has four high-performance "Firestorm" and four energy-efficient "Icestorm" cores, first seen on the A14 Bionic. [...] The M1 Pro and M1 Max use the same ARM big.LITTLE design as the M1, with eight high-performance "Firestorm" (six in the lower-binned variants of the M1 Pro) and two energy-efficient "Icestorm" cores, providing a total of ten cores (eight in the lower-binned variants of the M1 Pro).'

The efficiency cores on the Pro and Max aren't (so far as I can tell) faster than on the regular M1. But where the regular M1 has 4 performance + 4 efficiency cores, the Pro and Max have 6 or 8 performance + 2 efficiency. (Also, more L2 and L3 cache.)

> As someone else here said, fab nodes are more like Lego blocks than a printer’s dpi – moving a design to a new node means rebuilding it in terms of the new node’s building blocks, not just “shrinking the design”.

This is true but 'rebuilding' specifically refers to producing a new chip layout (i.e. the thing you send off to the fab to manufacture). This can be a lot of work but is all 'back-end' work. You begin with the RTL giving the logical/functional design of the chip and implementation engineers push it through synthesis, place and route etc to produce a physical chip layout. This is what you have to redo, you can just start with the exact same RTL.

When you design that RTL with a particular node in mind you can likely achieve better performance/area but it's not essential to do so.

Plus when you want to do the back-end work you need a fairly complete design to work from. So for instance Apple could be getting a back-end team to build a 3nm M2 now whilst the front end design team are busy working on the M3 (specifically targeted and optimized for 3nm).

According to some reports[1], Apple may indeed produce M2 chips on the 3nm line.

[1] https://www.macrumors.com/2022/08/18/m2-pro-chip-3nm-product...

Intel famously followed the "tick-tock" model where they would alternate between designing a new architecture and then moving that architecture to a new processing node.

So not sure it's true that you can't shrink down a largely similar architecture from one process to another.

Obviously it's fallen off the wagon a bit here, but seems more due to operational issues at Intel than it being fundamentally not doable

https://en.wikipedia.org/wiki/Tick%E2%80%93tock_model

That tick-tock model actually illustrates that it takes significant work to re-do the physical layout of a design for a new process node, even if the higher-level microarchitecture design remains unchanged. You don't get the benefits of a full node shrink for free.

I look at it differently.

The first step is to prove the process - to the appropriate level of control limits, and then the second step is to optimize the process.

You may say it's "significant", but if you look at it another way, it de-risks both tasks as opposed to doing both at the same time but having much higher risk.

So in my mind, the "significant work" is less relevant, as the derisking is much more important.

Yeah, they're basically spending 1 cycle porting the design to a new process, then another cycle with optimizing it.

The hardware side's optimizing the process on the first cycle, then doing a new one on the second.

Can you imagine having to live this life? Port to a new platform every other release?

Not necessarily - tic-tock let them double the number of new product releases compared to having new architectures launch simultaneously on new processes. Doubling the number of product releases was valuable competitively, as well as reducing their risk of having dated products if a deadline was missed.

There was work for sure to move to a new process, but that wasn't necessarily duplicated work with the architecture being created on a prior process. My impression was that it was already parallelized, and that not having to develop new architectures on new processes prevented a fair bit of contention.

Reply on news.ycombinator.com