Mainly because they can. They already have excellent team & experience in designing low power cores from the ground up, and also they have their great LLVM team for the compiler. Core plus compiler, that's all you need for a in-house processor. There are very few companies with this kind of combinations, and those who have them all chose to build their own hardware stack.
When you have the hammer, it becomes a crime to not hit the nail. Especially so when you find out you have a better hammer than your hammer contractor.
I’m interested in what hardware experts think about this too. TFA suggests an opportunity for deeper/proprietary silicon designs, which might be a nice way to create a moat before WinArm PCs and laptops arrive.
“SiFive can offer something Arm cannot, flexibility. Customers can modify their cores by adding hardware accelerators directly into the vector register file. This can be used for extending the X280 core to applications such as DSP, image signal processing, and AI.”
I guess with ARM they can either design their own cores, or buy arm's, but not other arm architecture licence holders. With riscv they can do their own design or choose from a larger list of competing vendors
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.
znwu|3 years ago
When you have the hammer, it becomes a crime to not hit the nail. Especially so when you find out you have a better hammer than your hammer contractor.
CharlesW|3 years ago
“SiFive can offer something Arm cannot, flexibility. Customers can modify their cores by adding hardware accelerators directly into the vector register file. This can be used for extending the X280 core to applications such as DSP, image signal processing, and AI.”
humanwhosits|3 years ago
kaszanka|3 years ago
[1]: https://news.ycombinator.com/item?id=32722510
snvzz|3 years ago
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.
Kukumber|3 years ago
They are not attached to a HW, they'll sell you apple and its services, what ever helps them, they'll adopt it
PPC, Intel, ARM, RISC, it doesn't matter
And if they want a smart watch that last more than a mere day, they'll need to get rid of ARM asap anyways
ksec|3 years ago
Unless you have some concrete evidence, I dont think you know what you are talking about.
unknown|3 years ago
[deleted]