SiFive's P550 Microarchitecture
chipsandcheese.com
chipsandcheese.com
> The Performance P550 scales up to four-core complex configurations while delivering 30% higher performance in less than half the area of a comparable Arm® Cortex®-A75.
Dylan Patel wasn't impressed by these comparisons with A75 [2]
> @SiFive is claiming half the area and higher perf/GHz, but they are using 7nm and 100ns memory latency. Choosing to compare to the 10nm A75 on S845, notorious for its high latency at over 200ns. Purposely ignoring iso-node or other A75 comparisons.
And this analysis seems to be borne out in this Chips and Cheese post.
> As a step along that journey, P550 feels more comparable to one of Arm’s early out-of-order designs like Cortex A57. By the time A75 came out, Arm already accumulated substantial experience in designing out-of-order CPUs. Therefore, A75 is a well polished and well rounded core, aside from obvious sacrifices required for its low power and thermal budgets. P550 by comparison is rough around the edges.
So what to make of SiFive's claims? It seems quite an important claim / comparison.
If it is as fast as a A57 on similar node, that would still be a major win for RISC-V which so far has been incredibly slow. The Nintendo Switch 1 uses Cortex-A57.
The fact is that the node difference (7nm vs. 10nm) is critical here, SiFive’s area/power efficiency gains aren’t purely architectural but partly process-driven. Even with that advantage, matching a 2018 A75 (designed for mobile thermal/power limits) in 2024 feels like catching up to ARM’s rearview mirror. ARM’s A720 today benefits from years of iterative refinement (cache hierarchies, branch predictors, memory subsystems) that aren’t easily replicated overnight.
Scaling beyond cores is another hurdle, interconnects, memory controllers, and accelerators matter just as much as raw IPC. RISC-V’s ecosystem (tools, firmware, software optimization) also lags ARM’s, which could limit adoption even if the P550 were competitive.
SiFive’s claims highlight RISC-V’s potential, but until they benchmark against modern cores on the same node and demonstrate system-level competitiveness (not just microarchitecture wins), the gap will persist. That said, disruption takes time—ARM wasn’t born polished either. The real test is whether SiFive can close the maturity deficit before ARM’s roadmap (and AI-driven heterogeneity) leaves them behind. I doubt it, the GAP in GPU cores alone between Cortex and M Series is so huge, and then there are accelerators like NPU cores, which SiFive havent even started working on yet.
Even Cortex NPU's are behind Apple M Series, and if a large companies liek Samsung, Qualcomm, Mediatek lag behind Apple is Quality ARM chips with Decent GPU, NPU on Board memory, what hope does SiFive Have? At Worse Burn Investor money and die. At Best supply chips for your remote control, washing machine etc ... competing with mainstream applications would not be wise by any standards.
Dylan's complaint about comparing to the S845 is mystifying ignorance as he should know better.
What other A75 SoCs are there? Exynos used it for their mid cores, but the SoC sucked. MediaTek had the Helio P65, but it was announced in late 2019 which was basically 2 years after S845 was announced at the end of 2017. There were some other smaller suppliers from China, but I have no idea who they are. S850 existed, but as I recall, it was just a better binning of the S845 announced months after the original.
S845 is the ONLY A75 design worth comparing.
That seems unwise. Might work well enough for direct branches, but it's going to preform very badly on indirect branches. I would love to see some tests for indirect branch performance (static and dynamic) in your suite.
> When return stack capacity is exceeded, P550 sees a sharp spike in latency. That contrasts with A75’s more gentle increase in latency.
That might be a direct consequence of the P550's limited BTB. Even when the return stack overflows, the A75 can probably still predict the return as if it was an indirect branch, utilising its massive 3072 entry L1 BTB.
Actually, are you sure the P550 even has a return stack? 16 correctly predicted call/ret pairs just so happens to be what you would get from a 32 entry BTB predicting 16 calls then 16 returns.
When you calculate the target of a jump, you can cache it (that's what a BTB is). Next time you encounter it, you predict the target by accessing the cached value in the BTB and start fetching early instead of waiting for your jump/call to move all the way through the machine.
Otherwise it takes 3 cycles (on the P550) to take a direct call. Doesn't matter that it's unconditional, it can't see the call until after decoding. Sure, it's only two extra cycles, but that's a full six instructions on this small 3-wide core.
And an indirect call? Even if the target is known, it's going to need to fetch it from the register file, which requires going through rename. And unless you put a fast-path in with an extra register-file read-port, you need to go through dispatch and the scheduler too. Probably takes 6-10 cycles to take an indirect branch without a BTB.
On bigger designs it's even more essential to predict unconditional branches, as their instruction caches take multiple cycles, and then there are quite substantial queues between fetch and decode, and between predict and fetch.
"a branch prediction unit that is composed of a 32-entry Branch Target Buffer (BTB), a 9.1 KiB-entry Branch History Table (BHT), a 16-entry Return Address Stack (RAS), 512-entry Indirect Jump Target Predictor (IJTP), and a 16-entry Return Instruction Predictor"
So it does have a 2nd level BTB, it's just that it's labeled as IJTP and is potentially only used by indirect branches.
https://github.com/eswincomputing/EIC7700X-SoC-Technical-Ref...
I really hope that RISC-V can take over as a modern architecture, adding some competition to Intel/AMD and Arm. But they'll need to be able to offer faster chips, or at a minimum more than 4 cores.
Also does anyone know the rate of progress? I believe 10 years ago these where at 0.5mhz?
Most importantly, it's been just a few years since we could start getting reasonable RISC-V boards.
“As of June 2019, version 2.2 of the user-space ISA[46] and version 1.11 of the privileged ISA[3] are frozen, permitting software and hardware development to proceed. The user-space ISA, now renamed the Unprivileged ISA, was updated, ratified and frozen as version 20191213”
So, it’s more like 5 years old, compared to ≈40 for 32-bit x86, ≈20 for 64-bit x86.
P550 was announced shortly after these specs were ratified, so it's one of the earliest RVA22 designs.
I am expecting there'll be others we will get to see this year.
ISA design is a complex endeavor. Arch64 benefited from multiple factors directly attributable to ARMs prior art, domain knowledge, and market positioning.
There is a huge distinction between a globally recognized and dominant ISA engineering firm coming out with a “new” ISA that their engineers had been prepping for for years, and the effort required to create a novel ISA and ecosystem from scratch.
One is just another day at the office, while the other is a very riscy endeavor that requires amassing the talent, creating incentives, creating an engineering culture, and trying to create a niche in a market that was arguably fully populated by other options. And then, you still have to create an entire family of ISAs to match various specification levels.
It’s not an apples to apples comparison.
(which you didn’t explicitly state, so I apologize for thinking it that way)
….of the launching of arch64 with the launching of the RiscV ISA.
They were both theoretically clean slate designs, but one was made by a bunch of academics and the other by a company with decades of ISA design expertise. I’d expect the latter to be much, much more mature, all other things being equal.
At any rate, what riscV really did so far was to make 8bit MCUs irrelevant. I used to use a lot of 8 bit parts even with M0 around, but now with chips like the CH32v003 and family, it’s just ridiculous to even contemplate.
I mean you can hook up an 8pin MCU and a couple of resistors to a vga monitor and a keyboard and have a a computer in a heat shrink tube that walks circles around my ancient apple II for $0.60.
And if you want WiFi, BLE, and some other wireless stuff, with 3x the speed and 100x the memory, the riscV esp32 chips come in at about $1, and they can do pretty strong edge AI. It’s all just silly at this point, and it’s riscV that caused that sea change.
FWIW I agree that AArch64's launch was not the same as the RISC-V launch. There has clearly been a lot more work required to boot the RISC-V ecosystem and they have made amazing progress. Arm had the advantage of incumbency and a lot more resources.
At the same time I think the have oversold progress on application level processors and I don't think this does RISC-V any favours at all. Arm has a lot of experience and the general tone from some of the RISC-V commentary is that they got it 'wrong' with AArch64 which, to be charitable, is unproven.
If you look at an arch like x86 or ARM it was designed right before chips were released, and then extended over time. The same goes for the X protocol, it simply extended previous versions.
If you are designing something from the ground up to avoid the inherent problems of an existing system, it is reasonable to take time and research design problems to make sure you don't recreate the same issues (which would defeat the point of the redesign). It doesn't compete on the same time-frame as an extension of an existing system.
September 2019 for the base specs being ratified.
But even that isn't the true starting gun for anything but basic MCU.. For high performance, it's RVA22. The relevant specs were only ratified in December 2021.
It takes 3 years from IP to chips, and thus we are seeing the first RVA22 chips now.
No surprises there.
Is this 7 nm node really older than raspberry pi 5's 16 nm node?
> Next up is TSMC’s 12 nm FFC manufacturing technology, which is an optimized version of the company’s CLN16FFC that is set to use 6T libraries (as opposed to 7.5T and 9T libraries) providing a 20% area reduction. Despite noticeably higher transistor density, the CLN12FFC is expected to also offer a 10% frequency improvement at the same power and complexity or a 25% power reduction at the same clock rate and complexity.
They optimised for density and power, not frequency. A lot of the benefit they're claiming comes just from this.
https://www.anandtech.com/show/11337/samsung-and-tsmc-roadma...
I am also skeptical that it will lead to more open designs, but perhaps it could increase competition enough in the chip design space that more open chip designers can make a space for themselves, especially if the business of chip fabrication is isolated from design.
They haven't made any in a while, but that doesn't mean they aren't progressing.
Riscv leading to more open designs is wishful thinking, plus probably a large dose of PR. MIPS has been open for years and how many open source MIPS desisgn have we seen so far?
Er, are you talking about LoongArch? The CPU line that https://en.wikipedia.org/wiki/Loongson lists new models of this year?
You could buy their products in west as a sort of a low-power PC for a short while, but I think once netbooks arrived those just vanished.
As I and others have said before, successful consolidation around RISC-V is an ultimately a gift to China. Maybe you’re for that; as an American I am not.
But it's especially a gift to sanctioned regimes, because they can more easily use this architecture for home grown chips that become desirable when mainstream chips are embargoed or under threat of embargo.
Yes, there's still fabrication, but China and Russia have some fabrication going, just not at the latest nodes. Starting from an open standard makes it a lot easier than if they have to clone an architecture/chip or make a whole ecosystem of architecture and software.
Milk-V Megrez is shipping the same SoC running at 1.8 GHz.
Intel's Horse Creek chip with the same cores ran at 2.4 GHz, but Intel is in trouble and cancelled non-core activities. A working board was shown at Hot Chips 23.
Clock speed depends on the SoC integrator at least as much as the core designer, and the process node it is made on. And the packaging thermal envelope.
> Or does the architecture not really support faster chips?
Of course not. From as technical point of view it's essentially identical to Arm64, and with the same financial investment and comparable engineers will run at the same speed.
The P550 is a very early RISC-V design, announced in June 2021, just a few months after the RVA22 spec it implements was published. Three to four years to go from core to SBC is normal in the industry, including for Arm's A53, A72, A76.
SiFive has designed and shipped two or three major generations of more advanced cores since then, in the P670, P870, and P870-D.
rv64imafdch_zicsr_zifencei_zba_zbb_sscofpmf
https://www.sifive.com/document-file/p550-core-data-sheet
Although that was at announcement in June 2022. SiFive have continuous improvement and quarterly updates, which is how the U74 in the JH7110 ended up with Zba and Zba that the FU740 (and I thin JH7100) doesn't have, but missed out on the L2 prefetcher that the next quarterly updata got.
We do know that the Eswin chip has H, right?
https://www.eswincomputing.com/en/bocupload/2024/06/19/17187...
But Intel Horse Creek did (and also was higher MHz, they said 2+ GH, but I think they demoed it at 2.2 at Hot Chips and were shooting for 2.4 in production):
https://community.intel.com/t5/Blogs/Tech-Innovation/open-in...
All will be revealed in 10 days or so.
The the confusion reguarding B probably comes from claimes of B support before ratification, where it wasn't clear that Zbs needs to be supported.
See the discussion here: https://github.com/llvm/llvm-project/pull/122164#issuecommen...
BPI-F3 (etc) has only 512 MB of L2 cache for each cluster of 4 cores, vs 2 MB on the VisionFive 2 (etc), and I think this is the biggest issue. Similarly the TH1520 only has 1 MB of L2.
The Pioneer has the same 1 MB of L2 per four cores, but backs this up with 4 MB of L3, and when you're running single-threaded (or just a few) that CPU also has access to the other 60 MB of L3 cache on the chip at still much better than DRAM latency and bandwidth. It's very nice-perofrming machine if you can afford it -- though the P550 should make a better desktop machine. I'll know in a week or two when my Megrez arrives...
A statement like this pretty much disqualifies your opinions. Why would you expect it to have vector extensions? No one has ever claimed it does, the P550 materials clearly specify the ISA, and the RVA22 spec it implements does not require it.
However it is the fastest RISC-V CPU you can buy today, on a per core basis, by a factor of two, for all those many workloads that don't benefit from SIMD. For example general use as a desktop PC, compiling code etc.
It may well be eclipsed by another factor of two by this time next year (and by something with vector), but that's the rapid pace of progress in RISC-V.
If you need to develop non-vector code on RISC-V this year then this -- or the Mil-V Megrez for half the price and 30% high clock speed -- is the machine to have.
If you don't need RISC-V this year then ... go buy an x86. Or an Orion O6 (which I will also be getting)
> I think some sort of SIMD capability is table stakes for a lot of workloads these days, so I'm disappointed that there doesn't seem to be a CPU on the market that supports them
Some workloads, yes. Not all.
As for what is on the market, the CanMV-K230 with RVV 1.0 shipped in November 2023, and a wide variety of boards and laptops with the SpacemiT K1/M1 SoCs with octa core CPU with 256 bit RVV 1.0 shipped in the 2nd half of 2024, including the Banana Pi BPI-F3, Milk-V Jupiter, Sipeed Lichee Pi 3A, Deep Computing DC-Roma II laptop, MuseBook. Various of these have been reviewed by everyone from Jeff Geerling to Christopher Barnatt to Hackaday.
As for "some sort of SIMD" that's been available in RISC-V since the Allwinner D1 chip shipped in mid 2021, first on the AWOL Nezha EVB, later on things such as the Lichee RV and MangoPi MQ-Pro. These days the same C906 CPU (1 GHz, 128 bit vectors) is available in other SoCs for as little as $3-$5 in the 1 GHz Milk-V Duo with 64 MB RAM (runs a full Linux kernel), up to the $9.90 Duo S with 512 MB RAM.
There are also various boards with the 1.85 GHz quad core C910 TH1520 SoC, such as the Lichee Pi 4A and Milk-V Meles.
Not to mention the 64 core 2.0 GHz 128 GB RAM 64 MB L3 cache 32 PCIe lanes Milk-V Pioneer.
This is needlessly aggressive. I specialize in writing SIMD code. That is my job. I am very eager to get my hands on a RVV chip so that I can play with a new SIMD ISA. So obviously a non-SIMD chip is useless to me.
> Why would you expect it to have vector extensions?
Because it has "Performance" in the name. I double-checked the ISA and saw that it did not have V, and was disappointed.
> If you don't need RISC-V this year then
Why would anybody _need_ RISC-V? RISC-V is exciting because it has the possibility of giving the end user higher performance per dollar. Until it does that, it will relegated to enthusiasts who just like playing with new ISAs.
I apologise.
> I specialize in writing SIMD code. That is my job. I am very eager to get my hands on a RVV chip
The P550 core was announced in June 2021, 2 1/2 years ago. It was stated at the time that it doesn't have RVV.
The X270, announced the same day, is a dual-issue in-order core that DOES have RVV.
https://www.sifive.com/press/sifive-performance-p550-core-se...
I've also been eagerly waiting for RVV 1.0 hardware (and programmed RVV 0.7.1 hardware in the meantime, as a very close proxy ... and the C910 has a quite high performance implementation as an OoO core with dual vector pipelines) so I follow the news, mostly on Reddit's /r/riscv.
Boards with in-order cores implementing RVV 1.0 have been shipping since November 2023.
Those of us who follow the news have been eagerly awaiting the SG2380 SoC and Milk-V Oasis (and other) boards with it. Sixteen 2.5 GHz OoO SiFive P670 cores with RVV, plus 8 SiFive X280 cores with RVV as an NPU.
This was originally announced in October 2023 with predicted delivery in September 2024 (which tbh was never believable, and I expressed that at the time), then January 2025, and then late 2025 (which probably should have been the target in the first place), and now it may be cancelled because of US government sanctions.
> Because it has "Performance" in the name.
That comes from marketers, not engineers.
But it is indeed the fastest RISC-V available today, per core, on real-world scalar code, by a factor of 2. (The C910 is close on code that runs from L1 cache, maybe L2).
> Why would anybody _need_ RISC-V?
At the moment because they want to develop software to be ready when the machines competitive with the top end of Arm and/or x86 do arrive. Or if the current performance and price level already meets their needs e.g. Samsung with their future line of TVs (prototype already demonstrated at a show) using the P470 core. Samsung has had a team porting and optimising their Tizen OS and Microsoft's CoreCLR JIT for about two years now. No doubt similar activity is happening at LG, who have also announced switching to RISC-V.
> has the possibility of giving the end user higher performance per dollar. Until it does that
We are already more than half way from ratification of the base ISA in mid 2019 to that date. Probably 2/3 of the way. The SoCs that will do that are already on the drawing boards. Time is short and there is much to do.
Then, after a little while of tuning, it will the time to access the best silicon process.
Also, I'd imagine you'd want the Ztso extension to port PC games, assuming you mean Rosetta-style instruction translation rather than "somehow get the source and port the engine and all the middleware" -- I don't think the P550 has that extension.
A rv64 port on a rv64 elf/linux (using the rv64 glibc) with the AMD mesa drivers. That will reveal where certainly a lot of work will have to be done, and that at all levels.
And better do that with many AAA games (the nasty and badly coded ones, probably many of them).
Better try to do that work before getting access to the latest silicon process.