Apple to Move a Part of Its Embedded Cores to RISC-V | Hacker News Reader

Apple to Move a Part of Its Embedded Cores to RISC-V

techpowerup.com

118 pointsgcoguiec48 comments

This is a two paragraph, highly speculative "summary" of [0] which was posted earlier [1].

But even reading the original article, it barely mentions Apple and CharlesW highly editorialized that submissions title:

The Apple bit:

> For example, Apple’s A15 has more than a dozen Arm-based CPU cores distributed across the die for various non-user-facing functions. SemiAnalysis can confirm that these cores are actively being converted to RISC-V in future generations of hardware.

The original title:

> SiFive Powers Google TPU, NASA, Tenstorrent, Renesas, Microchip, And More

The bulk of the article is about Google and hyping Risk-V, not Apple.

[0] https://semianalysis.substack.com/p/sifive-powers-google-tpu...

[1] https://news.ycombinator.com/item?id=32872927

10 billion RISC-V cores were shipped last year - mostly you wont see them because they're heavily embedded - in disk drives/etc - used to be every flash drive had an ARM core in it and paid a few pennies to ARM, that's likely to change quickly

One thing to note is that RISC-V is only royalty-free for people making custom silicon implementations - i.e. the equivalent of an ARM architectural license. You still have to design the cores and that's the really hard part, moreso than designing the ISA.

Apple is in a unique position where they have all these Cortex cores for various reasons, but also have the resources to actually design a RISC-V implementation that could replace them all. I doubt the people designing flash controller ICs have that level of design experience.

There seem to be a bunch of open source risc-v cores. Such as the CORE-V cores. However I’m not sure how suitable they are for commercial use compared to the proprietary options.

>You still have to design the cores and that's the really hard part, moreso than designing the ISA.

Designing them is an option. RISC-V's license allows doing so. But, unlike ARM, where your only alternative is to license ARM's own designs, in RISC-V there are several options.

You could use open source cores, or license cores from someone. As there's an open market of cores, there are several competing companies, offering several competing cores and support arrangements.

There's lots of open source RISC-V cores - but can't be any fully OS ARM ones (even if someone's made a n OS ARM core you still have to pay ARM a royalty)

The big advantage to rolling your own private ISA is that there's already a rich compiler and O/S ecosystem for RISC-V while if you do use RISC-V it's all already there for you.

It really does feel like a second generation 'barn raising'

> but can't be any fully OS ARM ones (even if someone's made an OS ARM core you still have to pay ARM a royalty)

Wait long enough and you can. Even if you can’t work around them, patents expire, and you can copy the instruction set for reasons of compatibility.

Trademarks don’t automatically expire, though, so unless the trademark gets genericized (https://en.wikipedia.org/wiki/Generic_trademark) what you can’t do is call it an ARM CPU.

Arm will still blacklist you if you pull this trick.

And being blacklisted by ARM might hurt your business when you do actually need to buy something from them.

>when you do actually need to buy something from them.

Protip: You don't.

Literally, just license whatever you need elsewhere. RISC-V has an open market of cores, with tens of companies and hundreds of offerings.

The article is wrong, Apple don't really use ARM's Cortex cores within the M1

They already have a their own custom low-power arm64 core design for running these firmware tasks. They have about a dozen of them scattered around the M1, on top of the massive P and E cores.

There are still a few actual ARM inc designed cores spread around the motherboard, in various devices. But inside the SoC, most (if not all) are Apple's own design.

The RV arch is much simpler than ARM and there are many more options in the market for licencing designs, besides the option of designing your own.

That's the real difference: RV is a real market with multiple vendors whereas ARM arch is more or less single vendor lock-in.

It's more likely that RISC-V replaces MIPS than ARM, although it's certainly competing for the latter too.

...and USB flash drives are more likely to be based on 8051s than ARM in volume.

I'm pretty sure they're all ARM. Why would they be 8051s? Are there any sufficiently performant 8051 cores?

Here's one with a 250MHz 8051: https://github.com/flowswitch/phison/wiki/PS2303

They don't need anything as powerful as ARM (and thus avoid the licensing fees), and it's a very price-sensitive market, so a fast 8051 + accelerator hardware is enough.

No doubt some of the more expensive ones may be ARM-based, but I think the 8051-based ones far outsell them in volume.

RV32 will turn out to be the 8051 of the present. The 8051 was the Doge Dart of embedded automation. I bought a book in Vietnamese in Vietnam in 2005 on embedded development hardware and software for the 8051. If the diagrams were any indication of the quality, the writing was excellent.

I highly doubt it. As "reduced" as RISC-V is, 8051 is still tiny in comparison.

8051s are used in applications where a 4-bit MCU (yes, they do exist and are still in widespread use) is not quite enough, or they'd have chosen one of those instead.

There's a community doing "fpga golf". That is, reducing the number of LUT required to implement a CPU of a given ISA.

A basic RV32 CPU is down to 500-700 LUT.

    https://github.com/YosysHQ/picorv32
    https://github.com/olofk/serv

A minimal 8051 requires about 300 LUT.

    https://github.com/MicroCoreLabs/Projects/tree/master/MCL51

Not sure how this translates from an FPGA to a transistor count. But RV32 and 8051 should be within a factor of 2-3.

If all you're doing is making a core with a little ROM, a USB interface and a flash interface chances are your design is pad limited - it probably doesn't matter which CPU you use provided it's tinyish

(oh and 8051 are a pain to work with, they've taken far too much of my lifetime, they need the stake thru the heart thing)

>If all you're doing is making a core with a little ROM, a USB interface and a flash interface

An interesting observation is that RV32 has excellent code density. Meaning, in this sort of scenario, the ROM could be much smaller, or fit way more code at the same size.

within a factor of 2-3

That's still a huge difference, and as I mentioned above, the 8051 is found in applications which are very sensitive to cost. In terms of gate count, the lowest numbers I could find for a RISC-V core are in the 10-20k range, while an 8051 goes down to 2.7k:

https://www.electronicsweekly.com/news/design/eda-and-ip/805...

RISC-V replacing MIPS is old news. It is a done deal.

The company that owns MIPS, Imagination Technologies, has entirely dropped the MIPS ISA to instead focus in designing RISC-V cores.

Imagination Technologies sold off MIPS in 2017 [1] - while RISC-V might have been a thing back then, it was certainly nowhere as known as it is today, and well before any decision to focus on RISC-V.

Interesting in that Imagination have since announced RISC-V cores [2], but that's unrelated to any of the MIPS tech, and none of the MIPS engineers worked on it as the project started well after the sale.

[1] https://www.imaginationtech.com/news/completion-of-sale-of-m...

[2] https://www.imaginationtech.com/news/imagination-launches-ri...

Missed the sale. Now both MIPS[0] and Imagination are instead doing RISC-V.

0. https://www.theregister.com/2022/05/11/mips_riscv_chips/

Shipped last year or shipped in total?

Last year 3B, and the total cores shipped got over 10B recently. I couldn't find more data though.

Ok I looked into this some more.

They said "We estimate there are 10bn cores on the market already" (that would be since 2010). Then there's a slide that says "Nearly 80 billion RISC-V CPU cores by 2025".

https://www.eenewseurope.com/en/europe-steps-up-as-risc-v-sh...

that's from a talk at Embedded World in june 2022.

I can't find that talk on youtube. But there's another shorter talk that's online, from same CEO at the same conference, where they have a slide that says "North America. Industry adoption has taken off with millions of cores shipping from Nvidia, Western Digital, SiFive, and others."

Jim Keller's slide [1] on RISC-V. Simple words. Grug like.

[1] https://www.techgoing.com/jim-keller-innovation-is-happening...

I wish I could invest in his company. He's obviously biased towards RISC-V but things are certainly going this way.

They had a job posting a few months ago which asked for RISC-V experience.

edit: they still have them.

https://jobs.apple.com/en-us/details/200349341/system-archit...

I wish I could buy stock in RISC-V (in the abstract).

If there was a RISC-V ETF, internally using companies that sell RISC-V IP and hardware, I'd definitely buy it, and prefer it over NASDAQ (QQQ).

Could you join VC funds which are investing in Rivos/Ventana/SiFive/etc? (Genuine question - I have no idea if this is possible or not)

A lot of the RISC-V action is going on in China which is obviously rather more difficult. Over there much of that is funded by the Chinese state.

Testing the waters.

Notably, Apple was among main investors when ARM was a startup; they're not doing this to save in ARM fees.

This is based on Dylan Patel’s speculation, and he quite commonly just comes up with something that he wants to be reality and presents it as fact.

What benefits does RISC-V have over ARM besides it being open/free?

What benefits does Linux/BSD have over Windows, as a highly productive development environment outside of all the possibilities it had opened by being open/free ?

IMO the comparison is similar but it's just not quite the same thing.

Don't get me wrong - it's a big deal to have this popular open ISA. But I just don't think it's anywhere near as big a deal as Linux is/was.

I think it might be even bigger in the long run.

smaller instruction set, Arm has grown, reference manual is over 6k pages

smaller easier to read specs

easier to get new features ratified, org is a steward, isn't seeking rents

easy to add custom instructions

lots of OSH implementations to choose from

large 3rd party ecosystem, IP, compilers, OS, etc.

To be fair, even with a closed ecosystem for the cores themselves there is a large third party ecosystem in compilers, OSes, support hardware, and documentation around ARM these days. It's interesting how quickly all of that popped up around RISC-V the past few years though. ARM has had decades getting where they are with the ecosystem around their cores.

It did take decades to get here only because it took millions of years of humanity to get here. We are in a much different space right now, RISC-V benefits from all those years and decades and will naturally reach and surpass parity with all other chips, not just Arm.

RISC-V is basically a different encoding to achieve the same computation as being done on Arm. From far enough out and that isn't very far they are identical. Putting a RISC-V front end on an Arm chip is not difficult. Refactoring Arm tooling to support RISC-V is just engineering work. Every program fixed to run on Arm's memory model, now runs on RISC-V as well. RISC-V is a catamaran zipping around on Arm's moat.

We see the same thing with languages and frameworks. Innovation is accelerating.

There's a big difference in support for RISC-V and for, say, POWER (which has new processors in the line), Sparc, or Loongson (which is a new family of processors with roots in MIPS) which are all based around open architectures. You can restate the idea of Turing equivalence all you want, but that alone does not explain why one processor captures a bunch of human effort around it while others do not.

Part of that I think is Patterson and Hennessy writing one of the most standard books in the field and then turning it into its own ISA, which has in fact taken decades of their effort.

LLVM is a great tool, yes. There's a bigger body of research now than in 1985 or so, of course. But we had pcode before we had LLVM IR, and we had compile-to-C for a lot of languages in between. If you really think the only difference is some Kurzweilian inevitable march toward technological perfection over time and it has nothing to do with the tools being open and of high quality then I don't know what to tell you to dissuade you from that faith.

Smaller instruction set and shorter reference manual aren’t necessarily good attributes. The risc-v reference manual is short because in part because it is has terse-to-vague descriptions of things (not great for a specification) and because the ARM ARM specifies a bunch of things which are omitted from the RISC-V architecture spec, which either implementors will have to design themselves or the RISC-V org will eventually add in a revision or extension spec (e.g. Zicbom, Zicboz, Zicbop)

It's completely permissionless. Grab an open source core, tweak it how you like, and move into production. No one will ask you to sign a licensing agreement or pay any license fees.

Depending on what you're doing this may or may not be an advantage, but it's certainly a large difference from Arm. It could lead to innovation happening more quickly since there's no need to wait for a gatekeeper, it's unclear at the moment how much that matters.

Take a look at e.g. SiFive's core IP offerings.

Given any ARM core (save the wildly inefficient, but faster top performance cores like the X1/X2), SiFive's got one that's like below a third of the size, uses dramatically less power and runs somewhat faster.

This is enabled by the quality of RISC-V's architecture.

The base spec has less than 50 instructions. Even with everything and the kitchensink in there (which is possible; as of the batch of extensions approved in late 2021, RISC-V is not lacking any major features ARMv9 or AMD64 have), RISC-V is still a few hundred instructions, rather than thousands.

And, despite having highly competitive 32bit code density (might be the best by year end, considering with current state of non-finished Zc/B extensions it already is) and the highest code density of 64bit architectures (by comfortable margin), RISC-V is very easy to decode. The compressed code extension does barely even complicate decode, and is still either 2x 16bit instructions or a 32bit one.

In practice, this means cores can be tiny relative to equivalent ARM cores, and SiFive's portfolio is a good demonstration of that.

By contrast:

- AMD64 aka x86 has 1-16 byte instruction length which means a 2-decode or wider implementation has to bruteforce every possible instruction start and discard the bad results. This makes complexity scale exponentially with decode width, and Intel and AMD have found that 4-decode is a practical limit.

- ARMv9's aarch64 is fixed 32bit (yet only slightly easier to decode because of that, relative to thumb2 and RISC-V). This enabled Apple to go 8-decode with the M1. But this comes at the expense of code density: If you want to implement a high performance core, you're going to need a huge L1, which besides huge area and power penalty, is also going to cap the clock the cache can achieve. Regardless, the situation is much better than AMD64(x86), and has enabled Apple to go 8-decode on the M1.

And this is why I think Apple moving to RISC-V in supporting cores is only the first step, and the main cores will eventually follow.

Apple end game:

Apple ISA. Might take them a decade, but in the end, they will eventually do all their own thing.

riscv64gc-apple-darwin

Bit of a RISC-Y manoeuvrer no?

*Badumph*

Reply on news.ycombinator.com