I'm bullish on RISC-V, but sort of bearish on SiFive. The last several systems I've used have been StarFive systems (which is distinct from SiFive.) They (SiFive) seem to be more of a custom IP shop, where you go when you want to spin some custom silicon but not pay ARM. But now that we've broken with China re: chip production, is there anyone on this side of the pacific I can get catalog parts from?
So... their cores are great, but if I'm only going to see them if I write a very large check to SiFive, they're sort of irrelevant to my world. I would love to have SiFive IP that doesn't use Rocket/Scala/Chisel and does produce catalog parts.
That could be just me. I enjoy getting my hands dirty.
Well... our ARM cores use more standard tooling. I sort of detest System Verilog, but I detest it a lot less than Rocket/Chisel. And as annoying as it is to write a big check to ARM, at least you can hire people who know how to use your IP.
It probably wasn't obvious from my earlier comment, but I was comparing SiFive to ARM and then I was comparing SiFive with other RISC-V IP vendors (and open source projects.)
I agree with this, and suspect that if SiFive did get big enough they would start creating patented extensions as a defensive strategy.
Personally I'm more curious about RISC-V in tiny microcontrollers, and were I guiding semiconductor strategy I'd be way more concerned about ability to build embedded systems than GPU farms. The ecosystem to do the former can evolve into the latter, but skipping to the end is just a route to burn absolutely billions.
FWIW, after listening to Chuck Peddle's CHM Oral History interview, I sort of realized I didn't need the ARM ecosystem and just designed my own 6-bit microcontroller. Granted, I'm only doing some very simple control applications and fabbing at 800nm, so it's not going to be competing with an i7 or an A72 anytime soon.
IIRC, the RISC-V spec includes an "embedded profile" that specifies a CPU with 16 32-bit registers, so that should make RV32 even smaller than it would be otherwise. SiFive designed a dog-simple 2-stage pipeline 32 bit core that could even run without I-cache. I mean, it's not a speed demon, but it was implementable in many fewer gates than their earlier E cores.
I worked at SiFive for a year and couldn't make sense of their product strategy. But maybe that's a me problem and not a SiFive problem.
I really do sort of wonder what they're doing with 175m in Series F funding. Where do you go from there?
Intel publicly walked away from a $2B offer for SiFive, which means that at least one large chip manufacturer does not believe their IP is worth more than $2B. I'm not sure if the Round F post-money valuation was made public, but if it's more than $2B, SiFive will need to have a solid story for why a potential buyer should pay more than what Intel didn't want to pay. And if they're going to IPO, it would be helpful to have a reference customer for newer designs which seem to be on par with ARM offerings from four years ago.
It's certainly not impossible, but it seems a tough row to hoe.
But the cool part of this is that the ISA and many supporting packages (rocket, boom, etc.) are "open" and "free as in beer." Even if SiFive did fail, an IP investment in RISC-V would not necessarily have been a bad move. Which is why I said I'm fairly bullish on RISC-V (cause even if SiFive fails, customers existing investment in the ISA is not lost) but bearish on SiFive (because I fear their existing valuation may be too inflated.)
I'm not trying to tell anyone their SiFive baby is ugly. I'm not saying designing a RISC-V solution is a bad move. I'm just saying from my perspective, with incomplete information about what's going on inside SiFive, it looks like they have a difficult road ahead. I would POSITIVELY WELCOME any information regarding reference customers or catalog parts which might imply there's a large customer who's signed on the dotted line to pay SiFive a royalty for using their designs.
Full disclosure: I own no SIFIVE stock (or options) nor do I own stock in any company that competes in the RISC-V design space (Esperanto, Andes, Sandisk/WD, etc.) I still have stock in TXN though, but I haven't heard that they're deep in RISC-V. I am a former employee of SiFive, but was not employed in a management position; don't take my comments as being based on "inside information."
The only true thing that could be done is to have some top secret insight into CPU design optimization and apply it to RISC-V guiding the actual open spec along with you as necessary. Which is close to what Apple appear to have done with ARM64, but then Apple did hire/acquire an absolutely incredible team to get them there, and have the money to reward them.
Well... all the tech committees in the foundation report up through one of the SiFive principals, so if you want to change the spec, it at least appears SiFive has veto power.
> SiFive designed a dog-simple 2-stage pipeline 32 bit core that could even run without I-cache. I mean, it's not a speed demon, but it was implementable in many fewer gates than their earlier E cores.
How about SERV... That core can be configured to not use a register file (everything stored in BRAM).
SiFive's 2-stage pipeline E20 (and Arm's Cortex M0+) still execute 1 instruction per clock cycle on straight line code -- they just take an extra cycle on any taken branch .. doesn't matter whether conditional, unconditional, call, return.
SERV takes 32 clock cycles for most instructions, 64 cycles for some such as shifts and branches.
Yes, there are some things SERV is fast enough for, but E20 is not all that much slower than 5-stage pipe plus branch prediction E31 -- E20 does 1.2 DMIPS/MHz compared to E31 1.6 (and Arm Cortex M0+ 0.95, M3/M4 1.25)
Ha! Yes! The serial RV32 implementation! That was Olof Kindgren's design, right? It's another great design at one corner of the design space. I mentioned the SiFive core since that was the one I was most familiar with. I've heard Olaf speak at conferences. Smart guy.
Here's a class at MIT that takes undergraduates who don't even know verilog and at then end of the class they have a mostly passable RV32I. Admittedly pushing that through VLSI CAD will not be push-button easy but many universities also have an undergraduate tape-out class, including MIT...
Via MPW and assembly service one can easily have that die manufactured, packaged and mounted on custom PCBs for under $50K, a.k.a. much less than you'll pay in salary to have it designed, fabricated and tested. Even at non-American labor rates.
In 2023 producing a computing core, albeit not a state-of-the-art one, is just not the moat it once was...
Yes. I saw that too. It turns out that "building a chip" is different than "building a chip that meets specfic requirements we got from the customer."
I'm not saying "building a RV32x is impossible," I'm saying there are people with existing tool-chains that favour Verilog or SystemVerilog (or even VHDL, though I don't know of them personally.) And telling them "no, you should use Scala / Chisel / Firrtl to model the features you want to add to the system in order to meet customer requirements" is kind of a hard sell for many customers.
I definitely agree with the primary point, "building a chip that meets specfic requirements we got from the customer" is not easy and is what matters.
However, RISCV cores abound. In pretty much any HDL known to man with varying design trade-offs and capabilities. It's extremely difficult to differentiate at the RTL level at this time. Not impossible, but it would be a significant investment, which is I guess SiFive's business model. Sell IP at prices cheaper than that.
Here is a high quality, well documented, SystemVerilog version intended for embedded applications that I know has been included in multiple ASIC and FPGA designs successfully.
> couldn't make sense of their product strategy. But maybe that's a me problem
Well, you drove a Bambino on a 60 miles each way commute over a huge hill, so there's something questionable going on there :p
I can't see much wrong with the "start with microcontrollers, work your way up to single-issue Linux-capable, then dual-issue in-order, then small then bigger and bigger OoO" strategy.
What else can you do? Try to take on Xeon day #1?
On the other hand, sure, you can ask a lot of questions about how you take that to the market, and who the customers will be.
SiFive early on obviously thought there were a lot of people out there who really wanted to make little custom chips for this and that but didn't have the skills, and SiFive (via buying OpenSilicon) could provide a one stop shop. And even provide a lot of automation around that, in the SiFive Chip Designer -- there used to be a web page (similar to SiFive Core Designer) but it's long gone, but see e.g. this Yunsup's presentation https://www.youtube.com/watch?v=pxd93jb1OAk
It seems no one really wanted to do that -- or at least SiFive didn't find them. So they got rid of OpenSilicon again (at a HUGE profit) and seem to be just selling CPU core IP to people who were already making chips, had all the people and knowledge to do that, but just wanted to change away from Arm or Tensilica or 8051 or whatever.
> what they're doing with 175m in Series F funding. Where do you go from there?
That's still absolute chickenfeed compared to what Intel or AMD or probably Arm spend on designing a single core.
I'm talking more about how they thought they were going to interact with customers w/ a design language no one seemed to want to use. I think we agree on that; NO ONE seemed to be asking for Rocket / Scala / Chisel / Firrtl and it seemed odd that every time a potential customer asked for Verilog, they kept pushing Chisel.
But now that they're not pushing the core designer, how are they justifying their multiple? They're no longer a SaaS play, they're an IP design play which makes it a lot more difficult to hit the rule of 40.
But Intel famously passed on the $2B offer, which means they have to do something to convince someone out there they ARE worth whatever their post-money, round F valuation is lest the round C investors lose money and the round A investors not make as much money as they had hoped.
And yes $175m is less than ARM spends to design a core, but that's not what the $175m round F was for. Or at least I hope it's not what it's for, 'cause if they did sink it into designing a core that's just now on par with ARM's a72 (or was the recent goodness supposed to be on par with the a77?) from 4 years ago, what's the motivation for using a RISC-V core instead of an ARM core?
"We're as good as ARM was 4 years ago" isn't a great marketing slogan.
Your information about the details of the OpenSilicon spin-off must be better than mine. "Huge" profit is not what I heard. But neither of us were in San Mateo when that happened.
I would LOVE to be able to buy a part that lets me test any of the recent cores (I mean for less than $100,000.) Or I would love to hear about any customers using the new cores. It shouldn't be that hard to find a reference customer.
RISC-V will not do X and then Y. RISC-V is going in all directions at the same time. People are pushing to the smallest micro controlers, to data centers and to niche applications like space all at the same time.
They seem to be positioning themselves as the "RISC-V Arm" equivalent. Of course there are significant differences, like they don't completely control the architecture (as Arm does). But Arm have made a decent business out of it, so SiFive should be able to do the same.
By the way StarFive were SiFive China until SiFive divested them (the split was a bit acrimonious).
ARM is making peanuts compared pretty much all the companies that actually make high-end chips. Their IP seems to be worth much more than the business.
Just because Arm isn't huge, it's still not nothing. They're about to go into a floatation to try to raise $50-55 billion, which is not too shabby! (Even if it's down from the original target of over $60b).
True (assuming the stock price doesen't crash immediately after the IPO) but still it's not really justifiable based on their current financial figures or future growth prospects.
I'm not even sure what the valuation this valuation might even be based on (which admittedly applies to a bunch of other companies which actually end up doing quite well). They might conceivably be worth 100 P/E as an acquisition but an IPO would only make it less likely?
$50-55 billion would mean that ARM is more overvalued than Nvidia and Nvidia actually has a realistic chance to grow into that valuation.
I can't see how Arm is even worth the $32 billion SoftBank paid for them now. RISC-V didn't exist outside of Berkeley in 2016 when SoftBank bought Arm, but now it's becoming a serious rival and especially a serious limitation on how much Arm can raise prices.
Arm have around 2.7 billion in annual sales with $500m or $600m of profit.
That makes $32b a P/E ratio of 50 to 60, and $50b a P/E ratio of 80 to 100.
In simple terms, if you pay $50 billion to buy Arm, and they make the same profit every year as they are making now, it will take 80 to 100 years for you to make your investment back.
It's like putting your money into a bank paying 1% interest, but a lot riskier.
Such P/E ratios can only be justified by the company and its profits growing rapidly.
Arm's revenue actually fell 1% from 2022 to 2023. The last four years have been roughly 2.0, 2.7, 2.75, 2.7.
Is that a peak, and it's only downhill from now on, because of RISC-V (or otherwise). Or will they start to grow again?
Either way, it sure doesn't look like the very high annual growth rate needed to justify a price of $30b let alone $50b.
> In simple terms, if you pay $50 billion to buy Arm, and they make the same profit every year as they are making now, it will take 80 to 100 years for you to make your investment back.
But that's not how you make money by purchasing companies. You make money by buying the company low and then selling the company high. So if you bought ARM for $50B and sold it for $70B in 5 years, you would make $20B on an investment of $50B
But I'm certainly not in the position to guess how much ARM would appreciate over the next 5 years. I pulled that example out of a hat (or some other, less polite to mention part of my anatomy.)
It is worth considering why you expect anyone else could be more successful.
On the one hand you have ARM investors wanting them to extract more revenue, and the ARM customers do not want to pay more or have more restrictive licenses. They are in a bit of a nasty equilibrium but one that will hit all IP companies eventually.
An old colleague of mine has got into the idea businesses are now going to put the big squeeze on all suppliers that count as part of gross margins, which would include ARM, while essentially ignoring operational costs. The implication would be companies looking to use RISC-V would be more inclined to pay chip design houses on a contract basis more upfront than have anything including royalties. I dislike the idea but think he is right, and that the future of electronics is about to go through the same sea change that software did with open source and the emergence of SaaS.
For sure, but I guess you're not in SiFive's target market. You're not a customer of Arm either, unless you are licensing chip designs from Arm. Someone who merely buys Arm chips is a customer of the company that licenses from Arm, not of Arm.
Nevertheless it seems plausible there are companies that would like to license a RISC-V design (rather than implement their own or use one of the slower free cores) and might therefore be a SiFive customer. I'm not saying it's going to be a huge market, probably a much smaller one even than Arm, but it's a possible one.
Very true. I'm not in SiFive's target market. Though I do use M0 and M4 cores fairly frequently. But I'm not a direct customer of ARM, though. I think that's what you were implying.
I think part of what I'm getting at is it's TOUGH to get people to adopt new IP. And it's TOUGH to be all things to all people so you can compete in the low end against M0s and MSP430s, in the mid range against A77s and in the high end against i9's.
That being said, if SiFive fabbed a catalog part with one or two E20s at a reasonable cost, I have an immediate need of 200 of them. I only wish there were another 500 of me with a similar need so there was a chance we could get it fabbed at a decent price.
> if SiFive fabbed a catalog part with one or two E20s at a reasonable cost
Why would they do that? That's not the business SiFive is in. Arm doesn't do that -- they leave that to people such as the Raspberry Pi Foundation with the RP2040.
Perhaps (if you insist on a SiFive core) you could look at something like the BL602? $0.99 here.
If you're willing to use non-SiFive cores (and why not), the CH32V003 is pretty awesome for $0.10 (8 pin) to $0.14 (20 pin), assuming 2K RAM and 16K flash is enough for your purposes.
But I don't know what is "a decent price" for you.
The biggest benefit of RISC-V is that you are not married to a single IP vendor.
If ARM decides to change their license terms, you are screwed. If SiFive decides to change their license terms, you could just switch to a competing IP vendor without any changes to your software ecosystem.
ARM seems to be half-way moving in this direction. They allowed "royalty free" licenses to educational institutions for some of their low end M0/3/4 cores. But yeah, I think you're right. The cool thing about RISC-V is you can just pick up the ISA and run with it. I'm pretty sure the Rocket core generator is released under a BSD license. SiFive sort of makes sense if you want to integrate proprietary IP with open IP, and some people do actually want to do that. I don't know if there's enough demand for that, though.
But yeah. Even though we have compilers, it's not like you can spin up support for a new ISA in the drop of a hat. If you launched a project with a StarFive part and then decided you wanted to use SiFive IP, you should be able to use the same tooling. The impact of that shouldn't be under-estimated.
That's an important advantage: go Arm, and ultimately you'll be dealing with Arm (the IP licensing company), or with a 3rd party which deals with them.
Go x86, and you'll end up dealing with Intel, or AMD (okay, there's Via & maybe a few makers of legacy x86 parts).
Go RISC-V, and roll your own or pick from a growing list of vendors, are both valid options. And switch supplier while keeping your toolchain ecosystem.
I'd expect at least that this will spur innovation in the field. Likely increase consumer choice.
More suppliers of [insert product type here] is almost always a good thing.
The important part is from a software perspective, none of that stuff matters much. The benefit of RiscV is you can be sure that your low level software (e.g. an OS or HPC thing that requires hand coded assembly) won't be tied to a specific company's hardware.
I read your comment to imply that the ISA is the only thing that matters since that's what defines the software interface and that software is the only thing that matters.
If that is what you're saying, I think you're wrong.
As to the low level hand coded assembly. There's a fair amount of stuff in the Intel architecture that's not officially published. There are tools (from Intel) like VTune and the Intel C compilers that use non-published interfaces to optimize C or assembly, sometimes significantly. It is true you can write software without them, but many people purchase these Intel tools to make sure their systems run quickly and efficiently.
I can't remember if the SiFive U-X4 core equivalents were defined in the open RISC-V specs or as part of SiFive specific interfaces. If the former, then your point is even stronger. If the latter, your point is still valid, though modulo the impact of having relied on a SiFive specific interface.
Jim Keller's Tenstorrent worked with SiFive instead, because ARM didn't want to customize their cores for machine learning workloads and now they are developing a RISC-V with a ridiculous performance profile.
Well. They effectively control the architecture. All the technical committees in the foundation report up through one of the three principals at SiFive. I can't imagine a technical spec would be published without the consent of SiFive.
The ugly truth though is that "catalog parts" carry with it a whole boatload of overhead in the form of sockets/memory infrastructure/voltage regulators/cooling standards etc. The current "big money" is in being the core that gets integrated into a phone or tablet. It makes me sad too as this is a pretty spiffy micro-architecture to play around with.
Yes. That's where the big money is. It seems their current top-of-the-line core is on par with an A72 or A77. I'm not sure how it stacks up against an Apple M1.
My take on SiFive is it's at the point that it COULD compete, but they have to get more mind-share. If you're Samsung or Apple (or MediaTek or Allwinner or Rockchip or ...), you probably have experience with the ARM ecosystem and tools. Presumably you have a history with a business model and have factored in whatever royalties you're paying ARM into your cost of operations. It's a risk to set that aside and start using a different architecture, so you would want to have some quantifiable benefit before you ditched ARM for RISC-V.
It seems to me that clearly elucidating that benefit to potential customers is an important part of this equation. SiFive's earlier designs seemed to have smaller PPA numbers, so that's nice. But they were for in-order execution w/o macro fusion or speculative branching, so they were a little closer to A53s in performance per watt. If you had a RV64 design with the performance per watt of an A77, but with a power/area budget 20% lower, that might have a REAL impact on yield and cost.
That would be a thing to crow about. But that's not the type of crowing I see happening on the SiFive web page.
I keep thinking a catalog part with maybe a pair of U-54s, a pair of 270s and a pair of 670s plus typical SoC peripherals would be a great way to introduce developers to what SiFive designs could do. They could give dev boards to Samsung, Zero, Google, LTE engineers who could tweak the existing android RISC-V android images to get an idea for performance and power use.
Maybe they could sell Apple on the idea of acquihiring SiFive. Apple's never been skiddish about changing processor architectures or suppliers.
So... to recap... I'm thinking catalog parts mostly as a vehicle to prove to potential customers your IP can be fabbed to meet their power / performance / yield / cost targets. And if I can buy a couple hundred of these boards for a different project, then I'm even happier.
> It seems their current top-of-the-line core is on par with an A72 or A77
Their current core, the P870 (the subject of the post we are commenting on) is on par with Cortex X2, announced just over 2 years ago in May 2021.
A76 class was the P550, announced in June 2021, 3 years after the A76's May 2018 announcement.
A72 class was their U84, back in October 2019, 4 1/2 years after the A72's February 2015 announcement.
The time gap has been coming steadily down.
All of these cores, both Arm and SiFive, take about four years to get into cheap mass produced catalog part chips and boards e.g. the A76 RK3588 just started appearing in SBCs around May 2022. A72 to Pi 4 was 4 1/2 years.
I don't know how much you can pick up a JH7110 with four 1.5 GHz U74s (plus that S7) for, but Milk-V are selling a compute module board with one for $34
> So... to recap... I'm thinking catalog parts mostly as a vehicle to prove to potential customers your IP can be fabbed to meet their power / performance / yield / cost targets. And if I can buy a couple hundred of these boards for a different project, then I'm even happier.
Oh I don't disagree, lowering the cost to field a system out of your micro-architecture increases the likely hood a design engineer will design it into their own design. This effect singlehandedly sustained the x86 product line until it didn't.
If by "good" you mean "something that's probably about as good as Dhrystone or Coremark but a lot simpler and harder to game" then I've got a benchmark and quite a few results collected on various things over the last seven years here:
Though... RISC-V support in gnu c and clang have evolved significantly over the last 5 years. Did you re-run any of the tests with more recent compilers? When we were doing benchmarking 5 years ago, it seemed we got slightly better performance every month as Palmer integrated improvements into the gnu toolchain. There were at least a couple months there where we REALLY didn't want to publish benchmarks because we were expecting the numbers to be noticeably better in n days.
This is very straightforward code (which I wrote in 2016 before I'd even heard of RISC-V) that maps very cleanly and obviously to instructions and any gcc from the last 20 years will make essentially the same code. A large part of my goal when I wrote it was to make it far more impervious to compiler "improvements" and gaming that Dhrystone and Coremark -- and I think I succeeded very well.
The RISC-V B extension's `sh2add` and friends make a small difference -- that's basically the 2.7% gap between the VisionFive 2 and the HiFive Unmatched. If I disable Zba on the VF2 then the times are just about identical.
I'm curious what your objections to Chisel are! (I don't really care for Scala either .. unless you mean that like, this somehow affects the way that IP is delivered to you as a customer? I thought you just get a big blob of verilog in the end, and I'm not sure how that'd affect you?)
I'm not the worlds biggest fan of Verilog, but Verilog's semantics are relatively fixed. The interpretation of verilog has remained fairly stable for a decade at least. Chisel is in some ways still a work in progress. So if you want to use it, you have to keep track not only of Chisel productions specific to your design, but also the version of the boom or rocket generator you're using with it. Chisel was never at the center of our design flow, and none of the people I currently work with went to UCB. When we used the Rocket generator we were often "nervous" about whether the version we were using would interpret Chisel productions in the way in which it had previously.
But yes... this led us to a working style where we tried very hard to avoid having to use rocket or boom generators. I didn't want to be in the business of maintaining RISC-V Verilog tools. At around the same time we realized RISC-V was overkill and built a very poorly designed Lisp DSL which output Verilog for a dog-simple 6-bit controller. Not an ideal solution to be sure, but it worked better for us than spending a couple years learning Rocket/Scala/Chisel.
Nick Tredennick (who I believe was the main designer of the 68k) has a quote in his book "Logic Design: The Flowchart Method":
The problem with many texts is that we lie about
details. We are sloppy in areas that are not our primary
concern. Academics are method fanatics. Practitioners
are solution fanatics. In school, we glorify the methods
and lie about the sophisticated problems we solved. In
industry, we glorify the problems and lie about the
sophisticated methods we used. Each side loses
credibility the minute one side reads the other's
literature. The academic knows that the practitioner's
"method" is (ugh!) arbitrary, just as the practitioner
knows the academic's "solution is (ugh!) not applicable.
Because we oversell method and solution, it takes too
long to figure out what really works.
I don't want to say Rocket / Chisel / Firrtl is bad, but it always seemed to be more in support of a "process focused" methodology than the "solution oriented" focus I'm used to. If it works for you, I'm absolutely not going to tell you it's a bad idea to use it. It's just too much overhead for the small projects I work on.
That being said... SiFive was working on CoC (theorum prover) extensions to validate designs using formal methods. THAT sounds fascinating, but I'm not sure how they would monetize it.
[Edit: To recap, I don't have a problem with Rocket / Chisel / Firrtl per se, but they operate at a level I'm uncomfortable with and seem to be less stable than I would prefer. I completely understand this is not the case for many other people.]
> SiFive was working on CoC (theorum prover) extensions to validate designs using formal methods. THAT sounds fascinating, but I'm not sure how they would monetize it.
Synopsys seems to think it's a decent business to be in. :)
Makes me think that asia is gonna have this cheap compute available alot faster at the consumer level than anywhere else for at least the next 5-10 years.
> An insane programmer can set LMUL to a value higher than 1, making vector instructions address contiguous blocks of registers.
I hope that most code won't use LMUL=1, but LMUL>=1 when possible, otherwise we'd leave performance on the table.
The only case I can currently fore see where using LMUL=1 and manually unrolling instead will likely be always beneficial is vrgather operations that don't need to cross between registers in a register group (e.g. byte swapping).
> As with all new architectural features, we’ll have to wait and see how useful RISC-V’s LMUL will be.
RVV without LMUL would be a lot worse, the entire extension is build around the LMUL concept and it's really nice to work with imo.
> The only case I can currently fore see where using LMUL=1 and manually unrolling instead will likely be always beneficial is vrgather operations that don't need to cross between registers in a register group (e.g. byte swapping).
What about algorithms where register pressure is an issue?
I think the problem with LMUL is it assumes that you always want to unroll the innermost dimension (where the vector loads are stride 1). That's usually, the last dimension I try to unroll, if there are any registers left over. If there is any sharing of data across any other dimension in the algorithm, it's better to tile/unroll those first.
Of course, for a simple algorithm, there will be registers left over. But I think more interesting algorithms will struggle on RVV if you must use LMUL > 1 for performance.
> What about algorithms where register pressure is an issue
Then you'll probably saturate the processor without using a larger LMUL, but I think many algorithms can work with LMUL=2, without running out of registers.
LMUL (and especially fractional LMUL) isn't for performance, it's for kernels with mixed-element sizes, to maximise the number of variables (and elements) you can keep in registers without spilling.
Being able to use LMUL as a way to get the effect of unrolling and hide the pointer bumps and loop control on simple loops on narrow processors, without expanding the code, is just a bonus.
My favorite example of big LMUL is matmul. You can do an entire gemm microkernel in like 8 instructions with LMUL=4 by using an 7x4 kernel. You have 32 that turn into 8 registers with LMUL=4, 7 of which end up storing your C values, 1 stores your A values and you put the B values in scalar registers. Thus your entire kernel ends up being 1 4 wide vector load load and 7 4x wide FMA instructions.
> The only case I can currently fore see where using LMUL=1 and manually unrolling instead will likely be always beneficial is vrgather operations that don't need to cross between registers in a register group (e.g. byte swapping).
This is somewhat of a major problem with some kernels. RVV is quite spartan in the permute options it offers, often forcing you to use vrgather for many things. And as you suggest, vrgather doesn't scale well, so sticking to LMUL=1 seems sensible in a lot of cases. (this will also be a problem for RISC-V implementations that aim for longer vectors)
Honestly LMUL>1 could be more useful if more permute instructions were offered, particularly a restricted shuffle (like VPSHUFB on AVX or TBLQ on SVE2.1).
Stuff like vector constants can be more costly with LMUL>1, since they must consume more than one register.
On big cores, the only benefit LMUL>1 gives (other than design concepts like how widen work, or shuffling across vectors etc) is a code size reduction. Which is quite a dubious benefit for a somewhat complex feature.
Maybe smaller cores can extract more out of it, but it's not something I'm too knowledgeable about.
One place where LMUL makes a ton of sense is big-little hybrid designs. Your big cores can get wider execution units that can run LMUL=2 instructions natively while your little cores break them up into LMUL=.5 and processes them 4x slower. This lets you avoid the issue Intel 12th gen ran into where the consumer chips lost AVX-512 capability because the little cores only supported 256 wide vectors.
Also code size reduction can be pretty nice. It doesn't show up well in microbenchmarks but lowering load on the front end of your CPU is always nice. It means you get to save a little power or use the area for extra execution units.
> Your big cores can get wider execution units that can run LMUL=2 instructions natively while your little cores break them up into LMUL=.5 and processes them 4x slower
RVV spec doesn't allow LMUL to vary across cores in a hybrid design, so no, that doesn't work.
RVV doesn't do anything to help with hybrid cores with differing widths.
> It means you get to save a little power or use the area for extra execution units.
Power, maybe, but I don't see the rest being likely. For general purpose cores, you're going to need a wide enough front end to support scalar code, which tends to have more execution units than vector.
I'm not saying that the supported lmul varies. I'm saying that the different cores will break up the same instructions into bigger or smaller execution unit units.
There's nothing inherent with RVV or LMUL which makes this any easier/harder than other ISAs. Intel could design their little cores to break AVX-512 instructions into 4x128b parts if they felt like it, for example.
This LMUL thing sounds like a total antipattern. Does the OS have to handle it manually on context switches, or can it just pop the process's LMUL state with all the normal registers? Sounds like a feature that coult get ugly in embedded applications.
"LMUL state" is three bits (7 possible values) of thread-wide config that just change how operations operate with the same vector registers; similar to say the FP dynamic rounding mode, which also needs to be saved & restored across context switches.
...But I am starting to get suspicious of Tenstorrent. Maybe they have some customers using their designs privately, but I never see any of their hardware used in public.
Indeed, but another company should've announced they are licensing and taping out products on the cores by now, right? If someone starts taping it out right now, the core will be long in the tooth by the time it comes out.
I am also suspicious because their 12nm, 2021 Grayskull PCIe cards never materialized:
> We’ll be selling Tenstorrent AI PCIe cards, workstations, and servers soon. Stay tuned for availability.
Sorry for my ignorance, but any idea when we can see Desktop Processors powered by RISC-V architecture? It would be breath of fresh air to see new architectures power the desktops.
You can buy a RISCV SBC and run a Linux desktop on it today. It's just not competitive with x86 in performance or software support. The closest you'll get to that outside arm or x86 is Talos II stuff, which runs PowerNV.
I remember this one: https://abopen.com/news/building-a-risc-v-pc/ . Since it is from 2019, it is likely there have been some advancements. I also hope for a riscv desktop; it could even be ryf certifiable.
The HiFive Pro P550 should be available this summer, for a pretty desktop-like experience. Don't expect RISV-V to directly compete with Intel/AMD on the high end for at least another decade, though.
Add 3-4 years for cores to make their way into CHEAP mass-production hardware. People who describe this as "not in the near future" are probably still in school.
If your benchmark is x86 from ~2016-2018 then maybe. But the competition is moving forward as well (and Intel, AMD and ARM have a lot more money to invest into R&D)
I could make a similarly unsubstantiated claim that their chips are much faster than RISC-V ones because of that (of course they are unambiguously faster it's just that this is not the only reason).
And anyway if RISC-V is to become competitive it will have to become much more complex as well..
Exactly. It's really fascinating that people view this as an ideological/religious thing. It might even seem that some treat RISC-V as some sort of a cult?
> CISC dogmatism
Besides the fact that your understanding of what CISC/RISC means seems to be stuck in the 90s and the distinction is pretty much irrelevant at this point, you do actually realize that ARM is a RISC architecture?
> blatantly refusing to accept simplicity has inherent value
For microcontrollers? Sure. For high-end/general purpose chips? RISC-V cores will have to implement many 'optional' extension to become competitive.
It's not religious faith, it's engineering knowledge, and having worked with CPU and chip design teams at companies such as Samsung and SiFive.
Anyone who knows what they're talking about will tell you the same thing. If you don't want to listen to me then listen to Jim Keller. Or ARM star designer (ARM7TDMI, Thumb2, among others) David Jaggar.
I can't see any reason why the exact same engineers and managers who designed Apple M1 released in November 2020 would get less than M1 performance when they design a RISC-V chip at a new company, and most likely they already had ideas in their heads to make better-than-M1 but had to leave out.
So they might well hit June 2022 M2 performance, or thereabouts.
Sure, M1 or M2 class RISC-V hitting the market in 2026 or 2027 is hitting an old performance mark and Apple will have moved on.
Even if not the absolutely fastest thing in the world at that point, M1 performance in 2027 is still going to be a totally usable machine for most people for most purposes. I'm typing this on an M1 Mac Mini I bought in November 2020 and I can see absolutely no reason to replace it any time soon.
You can make whatever comparison you want between M1/M2 and x86.
Wouldn't they need to implement a bunch of additional extensions which RISC-V doesen't currently have just to reach feature parity? That alone would've introduced significant delays.
Also it took Apple 8 or so years to build a competitive desktop/laptop CPU. They released their first custom ARM core in 2012 and likely relied a lot on what they learned while working with Cortex so it's not like they started completely from scratch.
And we're talking about Apple, very few if any other companies are willing to invest as much time and resources into a product targeting a stagnant or even shrinking market (desktops/laptops) with very low margins. I don't think Qualcomm can't design something that would be competitive with M1/2 they probably don't just see a lot of sense in that financially. How would RISC-V change this?
Of course there are political reasons for Chinese companies (being increasingly cutoff from western tech to invest into RISC-V) which might be more important than financial ones. So a shift to RISC-V would be almost guaranteed to increase our reliance on China which in no way could be viewed as something positive...
> I can see absolutely no reason to replace it any time soon.
And presumably you would be fine to replace it when as machine which is just as fast in 5 years just because it used a RISC-V CPU despite there being significantly faster ARM/x86 devices on the market?
> it took Apple 8 or so years to build ... likely relied a lot on what they learned
Apple doesn't build or learn anything. The people they employ to work there do. When those people go to another company ... e.g. a RISC-V company ... they take that learning with them.
If we look at the single benchmark available directly comparing RISC-V to x86, the SG2042 is about comparable to a Sandy Bridge CPU from 2012[0]. That's roughly 11 generations behind. There is definitely going to be a market for RISC-V, but in all likelihood that primarily means eating ARM's lunch and highly specialized workloads.
To directly compete with AMD/Intel they are going to have to be within the same ballpark of performance and cost about the same and consume about the same amount of power. There is simply no way in hell that is going to happen in 2024, not with the amount of catchup they have to do. Even Tenstorrent's own Jim Keller expects their Ascalon to be behind Zen 5 in raw performance / GHz, and Ventana's slides show it barely beating 2021 CPUs[1] which are in turn already massively outperformed by current-gen ones[2].
I fully expect a few RISC-V products to be only a generation or 2/3 behind within a couple of years, but that is simply not enough to be a direct competitor.
If we're being generous/technically correct (which of course is the best kind of correct), on September 3rd they've got about two and a half weeks left to meet "this summer". Informally, most people would expect that to mean June/July/August.
I haven't seen any news on since January, and no concrete shipping date. I signed up on the announcement email list and haven't seen anything there either (or at least I think I signed up; I don't even see an acknowledgement email.)
That's not really a criticism or doomsaying about Intel or SiFive from me -- I'm really interested to see what they have -- but they could do with a better communication strategy.
I'm in market to replace platform for my home-built NAS. I'm looking at EPYCs 7001 or 7002 with SuperMicro platform (second hand) as primary target.
When I seen this Milk-V Pioneer platform I was very enthusiastic: looks like what I need (minus IPMI, but I can omit this requirement) - one slot for 10G network, one slot for HBA, M.2 slots for caches, I can select RAM (in opposite to most of these platforms, where RAM is soledrid-on), plus ability to experiment with new platform. Looks perfect.
On one hand I agree with you. It is apples-to-oranges to compare new development platform and old, second-hand, production one.
On other hand... There is NO comparable production RISC-V platforms. You say "It has 64 cores" - well, it is good argument when there is choice. But there is no choice on RISC-V side, there is no such platform with 32 or 8 or any other number of cores. So, I compare what I can buy with "RISC-V" badge and what I can buy with "amd64" badge. When I choose EPYC I could choose from 8 cores up to 64 cores, according to my wallet and needs. For 1000 euro I could have good, proven MoBo which offers more than this "development platform" (i.e. IPMI and VGA exit, which means I don't need any videocard to occupy so precious PCIe slot - and I think, it is good idea for DEVELOPMENT platform to have full remote control & access, IPMI or some other) and 8 core/16 threads first generation EPYC (which will be faster core-to-core, I'm sure), NEW. If I agree to buy second-hand hardware it will be about 550 euros (same mobo, same CPU). For 1400 euros I will get NEW 16 cores / 32 thread EPYC + mobo combo, or about 700 euros second-hand.
Yes, I know, development vs. production, but this situation stays the same for years now.
BTW, situation is the same with ARM platforms too - there is no way to buy "big desktop/small-server class" ARMv8 board with good set of expansion slot.
We get it, you've found an area where a new open architecture (only 12 years old, only been making chips for 5 years) doesn't compete with a 50 year old proprietary architecture that is used by 95%+ of the machines around. It's like it is 1997 and Windows looks unstoppable, what could this silly Linux toy ever be useful for?
Except I really don't think it's fair to call RISC-V 12 (or 13) years old. Sure, that's when some university guys in a pub said "fuck it, we should just make our own ISA" and started throwing ideas around, but it was a long long time before it was frozen and there was something companies could start building on.
That happened in July 2019. just over 4 years ago, which I think should be counted as the zero date.
When did Arm start working on Aarch64? I don't think we have any idea — as far as I know they've never said. My guess is it was around the 2003 release of AMD64. But the world learned about it when they published the finished ARMv8-A spec in October 2011.
If 2011 is the date for ARMv8 then the fair comparable date for RISC-V is 2019.
> only been making chips for 5 years
Five years ago, the only RISC-V chips were one-off ones made in Berkeley university, and the FE310-G000 and FU540-C000, which were also made by those same guys as were in that pub, manufactured in total volumes of a few hundred, and with no guarantee they would be compatible with the eventual ratified standard.
I have a HiFive Unleashed, one of those used to demo them at the Embedded Linux Conference in Portland in March 2018. It was over a year after that before the ISA was ratified (and of course designed well before that) so, as I said, there was no guarantee that it would actually qualify as "RISC-V" long term.
With the HiFive Unleashed SiFive "shipped a draft spec", which is exactly the same thing they shit on Canaan (K210, priv arch 1.9.1, literally a snapshot of the Rocket repo) and THead (C906/C910 RVV 0.7.1) for. They just got lucky that no breaking changes were made, unlike the other guys.
As someone who dabbles in electronics, it was eye-opening to go to DigiKey and PCBWay and price up a modern x86 motherboard.
Obviously DigiKey doesn't have the chipset ICs, but at quantities of 100 just the connectors, VRMs, passives and the big 8-layer PCB to house it was so much higher.
Like I knew it would be higher, but this exercise really put industrialized manufacturing and economy of scale into perspective.
Point of fact: it costs no more (maybe less) than a similarly configured prebuilt x86 computer with 12-16 performance cores, which it will be performance-competitive with on many tasks where you can keep most of the 64 cores busy.
Because it is their first generation chip, thus small production run.
You can either wait for the next one (SOPHON SG2044, with V 1.0 extension, TBA 2024) or get something that's mass-produced now, such as SBCs or tablets based on the JH7110 or TH1520 SoCs.
You can get RISC-V based single board computers today.
I think the meaningful question is when we'll see RISC-V CPUs that are performance competitive with x86 or ARM CPUs. In that case, probably not in the near future, at least not for several years at least. x86 and Arm CPUs have decades of optimization behind them. That's the CPU designs themselves, and also compilers, etc. RISC-V has a lot of catching up to do, and Arm and x86 aren't static targets.
That isn't to say that RISC-V won't catch up. There's real momentum behind RISC-V. Also, the development of software built using machine learning introduces wildcards and the possibility of disruption. So in the medium to long term (end of the decade, maybe?) we might see interesting cell phones or laptops that are useful for more than Hacker News tinkerers. I'm looking forward to them.
>when we'll see RISC-V CPUs that are performance competitive
As you said, Arm and x86 aren't static targets. So while they'll catch up to where Arm is today, Arm will be somewhere further ahead at that point. Especially as implemented by Apple silicon. My concern remains that Apple will have to investment strength to always be a few years in the front. Their lead could in fact increase. And that's just CPU.
Also pioneer pricing, as can be expected. But it has uATX form factor, ddr4, pcie3, usb3, sata3 connectivity. You could certainly build a nice desktop with it.
While very cool, open source drivers for propriety a proprietary gpu design is not quite the same as open silicon or open gpu isa, which is what I think the parent was asking for.
This is not an open and free CPU. It just implements the open and free RISC-V instruction set. Judging by the SiFive business model they will in the future inevitably add proprietary extensions.
SiFive is now a IP license shop I think? similar to Andes from Taiwan who also sells RISC-V cores. Difference is that SiFive is more on the desktop CPU while Andes is more on the embedded space.
In the Machine Learning startup field, RISC-V is the most popular choice these days.
RISC-V also becomes a national priority for China as far as I can tell, it won't surprise me the best RISC-V designs will be from there.
Yes, TLBs are pretty expensive (in area and power) since they are associative memories. The virtual (non-offset) part of an address to be translated is compared to all TLB entries simultaneously to keep latencies down since the TLB is on the critical path from CPU to memory. Accordingly, you need one comparator (lots of XOR gates in a simple implementation) per TLB entry.
145 comments
[ 4.4 ms ] story [ 190 ms ] threadSo... their cores are great, but if I'm only going to see them if I write a very large check to SiFive, they're sort of irrelevant to my world. I would love to have SiFive IP that doesn't use Rocket/Scala/Chisel and does produce catalog parts.
That could be just me. I enjoy getting my hands dirty.
It probably wasn't obvious from my earlier comment, but I was comparing SiFive to ARM and then I was comparing SiFive with other RISC-V IP vendors (and open source projects.)
Personally I'm more curious about RISC-V in tiny microcontrollers, and were I guiding semiconductor strategy I'd be way more concerned about ability to build embedded systems than GPU farms. The ecosystem to do the former can evolve into the latter, but skipping to the end is just a route to burn absolutely billions.
IIRC, the RISC-V spec includes an "embedded profile" that specifies a CPU with 16 32-bit registers, so that should make RV32 even smaller than it would be otherwise. SiFive designed a dog-simple 2-stage pipeline 32 bit core that could even run without I-cache. I mean, it's not a speed demon, but it was implementable in many fewer gates than their earlier E cores.
I worked at SiFive for a year and couldn't make sense of their product strategy. But maybe that's a me problem and not a SiFive problem.
I really do sort of wonder what they're doing with 175m in Series F funding. Where do you go from there?
It's certainly not impossible, but it seems a tough row to hoe.
But the cool part of this is that the ISA and many supporting packages (rocket, boom, etc.) are "open" and "free as in beer." Even if SiFive did fail, an IP investment in RISC-V would not necessarily have been a bad move. Which is why I said I'm fairly bullish on RISC-V (cause even if SiFive fails, customers existing investment in the ISA is not lost) but bearish on SiFive (because I fear their existing valuation may be too inflated.)
I'm not trying to tell anyone their SiFive baby is ugly. I'm not saying designing a RISC-V solution is a bad move. I'm just saying from my perspective, with incomplete information about what's going on inside SiFive, it looks like they have a difficult road ahead. I would POSITIVELY WELCOME any information regarding reference customers or catalog parts which might imply there's a large customer who's signed on the dotted line to pay SiFive a royalty for using their designs.
Full disclosure: I own no SIFIVE stock (or options) nor do I own stock in any company that competes in the RISC-V design space (Esperanto, Andes, Sandisk/WD, etc.) I still have stock in TXN though, but I haven't heard that they're deep in RISC-V. I am a former employee of SiFive, but was not employed in a management position; don't take my comments as being based on "inside information."
The only true thing that could be done is to have some top secret insight into CPU design optimization and apply it to RISC-V guiding the actual open spec along with you as necessary. Which is close to what Apple appear to have done with ARM64, but then Apple did hire/acquire an absolutely incredible team to get them there, and have the money to reward them.
How about SERV... That core can be configured to not use a register file (everything stored in BRAM).
SERV takes 32 clock cycles for most instructions, 64 cycles for some such as shifts and branches.
Yes, there are some things SERV is fast enough for, but E20 is not all that much slower than 5-stage pipe plus branch prediction E31 -- E20 does 1.2 DMIPS/MHz compared to E31 1.6 (and Arm Cortex M0+ 0.95, M3/M4 1.25)
Never heard of this despite being casually interested in hardware, it is apparently this?:
https://nandland.com/lesson-15-what-is-a-block-ram-bram/
https://ocw.mit.edu/courses/6-004-computation-structures-spr...
Via MPW and assembly service one can easily have that die manufactured, packaged and mounted on custom PCBs for under $50K, a.k.a. much less than you'll pay in salary to have it designed, fabricated and tested. Even at non-American labor rates.
In 2023 producing a computing core, albeit not a state-of-the-art one, is just not the moat it once was...
I'm not saying "building a RV32x is impossible," I'm saying there are people with existing tool-chains that favour Verilog or SystemVerilog (or even VHDL, though I don't know of them personally.) And telling them "no, you should use Scala / Chisel / Firrtl to model the features you want to add to the system in order to meet customer requirements" is kind of a hard sell for many customers.
However, RISCV cores abound. In pretty much any HDL known to man with varying design trade-offs and capabilities. It's extremely difficult to differentiate at the RTL level at this time. Not impossible, but it would be a significant investment, which is I guess SiFive's business model. Sell IP at prices cheaper than that.
Here is a high quality, well documented, SystemVerilog version intended for embedded applications that I know has been included in multiple ASIC and FPGA designs successfully.
https://github.com/lowRISC/ibex
Well, you drove a Bambino on a 60 miles each way commute over a huge hill, so there's something questionable going on there :p
I can't see much wrong with the "start with microcontrollers, work your way up to single-issue Linux-capable, then dual-issue in-order, then small then bigger and bigger OoO" strategy.
What else can you do? Try to take on Xeon day #1?
On the other hand, sure, you can ask a lot of questions about how you take that to the market, and who the customers will be.
SiFive early on obviously thought there were a lot of people out there who really wanted to make little custom chips for this and that but didn't have the skills, and SiFive (via buying OpenSilicon) could provide a one stop shop. And even provide a lot of automation around that, in the SiFive Chip Designer -- there used to be a web page (similar to SiFive Core Designer) but it's long gone, but see e.g. this Yunsup's presentation https://www.youtube.com/watch?v=pxd93jb1OAk
It seems no one really wanted to do that -- or at least SiFive didn't find them. So they got rid of OpenSilicon again (at a HUGE profit) and seem to be just selling CPU core IP to people who were already making chips, had all the people and knowledge to do that, but just wanted to change away from Arm or Tensilica or 8051 or whatever.
> what they're doing with 175m in Series F funding. Where do you go from there?
That's still absolute chickenfeed compared to what Intel or AMD or probably Arm spend on designing a single core.
I'm talking more about how they thought they were going to interact with customers w/ a design language no one seemed to want to use. I think we agree on that; NO ONE seemed to be asking for Rocket / Scala / Chisel / Firrtl and it seemed odd that every time a potential customer asked for Verilog, they kept pushing Chisel.
But now that they're not pushing the core designer, how are they justifying their multiple? They're no longer a SaaS play, they're an IP design play which makes it a lot more difficult to hit the rule of 40.
But Intel famously passed on the $2B offer, which means they have to do something to convince someone out there they ARE worth whatever their post-money, round F valuation is lest the round C investors lose money and the round A investors not make as much money as they had hoped.
And yes $175m is less than ARM spends to design a core, but that's not what the $175m round F was for. Or at least I hope it's not what it's for, 'cause if they did sink it into designing a core that's just now on par with ARM's a72 (or was the recent goodness supposed to be on par with the a77?) from 4 years ago, what's the motivation for using a RISC-V core instead of an ARM core?
"We're as good as ARM was 4 years ago" isn't a great marketing slogan.
Your information about the details of the OpenSilicon spin-off must be better than mine. "Huge" profit is not what I heard. But neither of us were in San Mateo when that happened.
I would LOVE to be able to buy a part that lets me test any of the recent cores (I mean for less than $100,000.) Or I would love to hear about any customers using the new cores. It shouldn't be that hard to find a reference customer.
By the way StarFive were SiFive China until SiFive divested them (the split was a bit acrimonious).
ARM is making peanuts compared pretty much all the companies that actually make high-end chips. Their IP seems to be worth much more than the business.
I'm not even sure what the valuation this valuation might even be based on (which admittedly applies to a bunch of other companies which actually end up doing quite well). They might conceivably be worth 100 P/E as an acquisition but an IPO would only make it less likely?
$50-55 billion would mean that ARM is more overvalued than Nvidia and Nvidia actually has a realistic chance to grow into that valuation.
I can't see how Arm is even worth the $32 billion SoftBank paid for them now. RISC-V didn't exist outside of Berkeley in 2016 when SoftBank bought Arm, but now it's becoming a serious rival and especially a serious limitation on how much Arm can raise prices.
Arm have around 2.7 billion in annual sales with $500m or $600m of profit.
That makes $32b a P/E ratio of 50 to 60, and $50b a P/E ratio of 80 to 100.
In simple terms, if you pay $50 billion to buy Arm, and they make the same profit every year as they are making now, it will take 80 to 100 years for you to make your investment back.
It's like putting your money into a bank paying 1% interest, but a lot riskier.
Such P/E ratios can only be justified by the company and its profits growing rapidly.
Arm's revenue actually fell 1% from 2022 to 2023. The last four years have been roughly 2.0, 2.7, 2.75, 2.7.
Is that a peak, and it's only downhill from now on, because of RISC-V (or otherwise). Or will they start to grow again?
Either way, it sure doesn't look like the very high annual growth rate needed to justify a price of $30b let alone $50b.
But that's not how you make money by purchasing companies. You make money by buying the company low and then selling the company high. So if you bought ARM for $50B and sold it for $70B in 5 years, you would make $20B on an investment of $50B
But I'm certainly not in the position to guess how much ARM would appreciate over the next 5 years. I pulled that example out of a hat (or some other, less polite to mention part of my anatomy.)
Fundamentals count for something, no?
On the one hand you have ARM investors wanting them to extract more revenue, and the ARM customers do not want to pay more or have more restrictive licenses. They are in a bit of a nasty equilibrium but one that will hit all IP companies eventually.
An old colleague of mine has got into the idea businesses are now going to put the big squeeze on all suppliers that count as part of gross margins, which would include ARM, while essentially ignoring operational costs. The implication would be companies looking to use RISC-V would be more inclined to pay chip design houses on a contract basis more upfront than have anything including royalties. I dislike the idea but think he is right, and that the future of electronics is about to go through the same sea change that software did with open source and the emergence of SaaS.
ARM is a fabless pure play IP house. The big bucks are not in IP design but in manufacture.
That's another thing they have in common with Arm.
RISC-V is only interesting as a platform for a different business model.
Nevertheless it seems plausible there are companies that would like to license a RISC-V design (rather than implement their own or use one of the slower free cores) and might therefore be a SiFive customer. I'm not saying it's going to be a huge market, probably a much smaller one even than Arm, but it's a possible one.
I think part of what I'm getting at is it's TOUGH to get people to adopt new IP. And it's TOUGH to be all things to all people so you can compete in the low end against M0s and MSP430s, in the mid range against A77s and in the high end against i9's.
That being said, if SiFive fabbed a catalog part with one or two E20s at a reasonable cost, I have an immediate need of 200 of them. I only wish there were another 500 of me with a similar need so there was a chance we could get it fabbed at a decent price.
Why would they do that? That's not the business SiFive is in. Arm doesn't do that -- they leave that to people such as the Raspberry Pi Foundation with the RP2040.
Perhaps (if you insist on a SiFive core) you could look at something like the BL602? $0.99 here.
https://pine64.com/product/pineseed-bl602-wifi-ble5-soc/
If you're willing to use non-SiFive cores (and why not), the CH32V003 is pretty awesome for $0.10 (8 pin) to $0.14 (20 pin), assuming 2K RAM and 16K flash is enough for your purposes.
But I don't know what is "a decent price" for you.
If ARM decides to change their license terms, you are screwed. If SiFive decides to change their license terms, you could just switch to a competing IP vendor without any changes to your software ecosystem.
But yeah. Even though we have compilers, it's not like you can spin up support for a new ISA in the drop of a hat. If you launched a project with a StarFive part and then decided you wanted to use SiFive IP, you should be able to use the same tooling. The impact of that shouldn't be under-estimated.
Go x86, and you'll end up dealing with Intel, or AMD (okay, there's Via & maybe a few makers of legacy x86 parts).
Go RISC-V, and roll your own or pick from a growing list of vendors, are both valid options. And switch supplier while keeping your toolchain ecosystem.
I'd expect at least that this will spur innovation in the field. Likely increase consumer choice.
More suppliers of [insert product type here] is almost always a good thing.
And the specs extend further to non-ISA, such as standardizing boot process and platform.
If that is what you're saying, I think you're wrong.
As to the low level hand coded assembly. There's a fair amount of stuff in the Intel architecture that's not officially published. There are tools (from Intel) like VTune and the Intel C compilers that use non-published interfaces to optimize C or assembly, sometimes significantly. It is true you can write software without them, but many people purchase these Intel tools to make sure their systems run quickly and efficiently.
I can't remember if the SiFive U-X4 core equivalents were defined in the open RISC-V specs or as part of SiFive specific interfaces. If the former, then your point is even stronger. If the latter, your point is still valid, though modulo the impact of having relied on a SiFive specific interface.
Yes. That's where the big money is. It seems their current top-of-the-line core is on par with an A72 or A77. I'm not sure how it stacks up against an Apple M1.
My take on SiFive is it's at the point that it COULD compete, but they have to get more mind-share. If you're Samsung or Apple (or MediaTek or Allwinner or Rockchip or ...), you probably have experience with the ARM ecosystem and tools. Presumably you have a history with a business model and have factored in whatever royalties you're paying ARM into your cost of operations. It's a risk to set that aside and start using a different architecture, so you would want to have some quantifiable benefit before you ditched ARM for RISC-V.
It seems to me that clearly elucidating that benefit to potential customers is an important part of this equation. SiFive's earlier designs seemed to have smaller PPA numbers, so that's nice. But they were for in-order execution w/o macro fusion or speculative branching, so they were a little closer to A53s in performance per watt. If you had a RV64 design with the performance per watt of an A77, but with a power/area budget 20% lower, that might have a REAL impact on yield and cost.
That would be a thing to crow about. But that's not the type of crowing I see happening on the SiFive web page.
I keep thinking a catalog part with maybe a pair of U-54s, a pair of 270s and a pair of 670s plus typical SoC peripherals would be a great way to introduce developers to what SiFive designs could do. They could give dev boards to Samsung, Zero, Google, LTE engineers who could tweak the existing android RISC-V android images to get an idea for performance and power use.
Maybe they could sell Apple on the idea of acquihiring SiFive. Apple's never been skiddish about changing processor architectures or suppliers.
So... to recap... I'm thinking catalog parts mostly as a vehicle to prove to potential customers your IP can be fabbed to meet their power / performance / yield / cost targets. And if I can buy a couple hundred of these boards for a different project, then I'm even happier.
Their current core, the P870 (the subject of the post we are commenting on) is on par with Cortex X2, announced just over 2 years ago in May 2021.
A76 class was the P550, announced in June 2021, 3 years after the A76's May 2018 announcement.
A72 class was their U84, back in October 2019, 4 1/2 years after the A72's February 2015 announcement.
The time gap has been coming steadily down.
All of these cores, both Arm and SiFive, take about four years to get into cheap mass produced catalog part chips and boards e.g. the A76 RK3588 just started appearing in SBCs around May 2022. A72 to Pi 4 was 4 1/2 years.
I don't know how much you can pick up a JH7110 with four 1.5 GHz U74s (plus that S7) for, but Milk-V are selling a compute module board with one for $34
https://arace.tech/products/milk-v-mars-cm?variant=423421722...
Oh I don't disagree, lowering the cost to field a system out of your micro-architecture increases the likely hood a design engineer will design it into their own design. This effect singlehandedly sustained the x86 product line until it didn't.
https://hoult.org/primes.txt
The RISC-V B extension's `sh2add` and friends make a small difference -- that's basically the 2.7% gap between the VisionFive 2 and the HiFive Unmatched. If I disable Zba on the VF2 then the times are just about identical.
But yes... this led us to a working style where we tried very hard to avoid having to use rocket or boom generators. I didn't want to be in the business of maintaining RISC-V Verilog tools. At around the same time we realized RISC-V was overkill and built a very poorly designed Lisp DSL which output Verilog for a dog-simple 6-bit controller. Not an ideal solution to be sure, but it worked better for us than spending a couple years learning Rocket/Scala/Chisel.
Nick Tredennick (who I believe was the main designer of the 68k) has a quote in his book "Logic Design: The Flowchart Method":
I don't want to say Rocket / Chisel / Firrtl is bad, but it always seemed to be more in support of a "process focused" methodology than the "solution oriented" focus I'm used to. If it works for you, I'm absolutely not going to tell you it's a bad idea to use it. It's just too much overhead for the small projects I work on.That being said... SiFive was working on CoC (theorum prover) extensions to validate designs using formal methods. THAT sounds fascinating, but I'm not sure how they would monetize it.
[Edit: To recap, I don't have a problem with Rocket / Chisel / Firrtl per se, but they operate at a level I'm uncomfortable with and seem to be less stable than I would prefer. I completely understand this is not the case for many other people.]
Synopsys seems to think it's a decent business to be in. :)
https://www.synopsys.com/verification/static-and-formal-veri...
I hope that most code won't use LMUL=1, but LMUL>=1 when possible, otherwise we'd leave performance on the table.
The only case I can currently fore see where using LMUL=1 and manually unrolling instead will likely be always beneficial is vrgather operations that don't need to cross between registers in a register group (e.g. byte swapping).
> As with all new architectural features, we’ll have to wait and see how useful RISC-V’s LMUL will be.
RVV without LMUL would be a lot worse, the entire extension is build around the LMUL concept and it's really nice to work with imo.
What about algorithms where register pressure is an issue?
I think the problem with LMUL is it assumes that you always want to unroll the innermost dimension (where the vector loads are stride 1). That's usually, the last dimension I try to unroll, if there are any registers left over. If there is any sharing of data across any other dimension in the algorithm, it's better to tile/unroll those first.
Of course, for a simple algorithm, there will be registers left over. But I think more interesting algorithms will struggle on RVV if you must use LMUL > 1 for performance.
Then you'll probably saturate the processor without using a larger LMUL, but I think many algorithms can work with LMUL=2, without running out of registers.
Being able to use LMUL as a way to get the effect of unrolling and hide the pointer bumps and loop control on simple loops on narrow processors, without expanding the code, is just a bonus.
This is somewhat of a major problem with some kernels. RVV is quite spartan in the permute options it offers, often forcing you to use vrgather for many things. And as you suggest, vrgather doesn't scale well, so sticking to LMUL=1 seems sensible in a lot of cases. (this will also be a problem for RISC-V implementations that aim for longer vectors)
Honestly LMUL>1 could be more useful if more permute instructions were offered, particularly a restricted shuffle (like VPSHUFB on AVX or TBLQ on SVE2.1).
Stuff like vector constants can be more costly with LMUL>1, since they must consume more than one register.
On big cores, the only benefit LMUL>1 gives (other than design concepts like how widen work, or shuffling across vectors etc) is a code size reduction. Which is quite a dubious benefit for a somewhat complex feature.
Maybe smaller cores can extract more out of it, but it's not something I'm too knowledgeable about.
Also code size reduction can be pretty nice. It doesn't show up well in microbenchmarks but lowering load on the front end of your CPU is always nice. It means you get to save a little power or use the area for extra execution units.
RVV spec doesn't allow LMUL to vary across cores in a hybrid design, so no, that doesn't work. RVV doesn't do anything to help with hybrid cores with differing widths.
> It means you get to save a little power or use the area for extra execution units.
Power, maybe, but I don't see the rest being likely. For general purpose cores, you're going to need a wide enough front end to support scalar code, which tends to have more execution units than vector.
https://tenstorrent.com/risc-v/
...But I am starting to get suspicious of Tenstorrent. Maybe they have some customers using their designs privately, but I never see any of their hardware used in public.
Why on earth would you expect to already be falling over hardware in 2023?
CPU core design takes a couple of years, getting to the first test chips a couple more, and then to mass production a couple more after that.
I am also suspicious because their 12nm, 2021 Grayskull PCIe cards never materialized:
> We’ll be selling Tenstorrent AI PCIe cards, workstations, and servers soon. Stay tuned for availability.
https://tenstorrent.com/grayskull/
(no concrete promise, thus not late)
Actually 2024.
SiFive P870, Tenstorrent Ascalon, SOPHON SG2044, Ventana Veyron, and more.
Add 3-4 years for cores to make their way into CHEAP mass-production hardware. People who describe this as "not in the near future" are probably still in school.
Not a decade. For sure not "at least a decade".
If your benchmark is x86 from ~2016-2018 then maybe. But the competition is moving forward as well (and Intel, AMD and ARM have a lot more money to invest into R&D)
Yet their ISAs are much more complex and thus they actually need to invest that much more money.
I could make a similarly unsubstantiated claim that their chips are much faster than RISC-V ones because of that (of course they are unambiguously faster it's just that this is not the only reason).
And anyway if RISC-V is to become competitive it will have to become much more complex as well..
Debate won't prove it, but it's true and time will tell -- and not very much time, at that.
> Debate won't prove it,
I find this (almost) religious style fanaticism about something as mundane as an instruction set quite fascinating.
RISC-V is inevitable.
> CISC dogmatism
Besides the fact that your understanding of what CISC/RISC means seems to be stuck in the 90s and the distinction is pretty much irrelevant at this point, you do actually realize that ARM is a RISC architecture?
> blatantly refusing to accept simplicity has inherent value
For microcontrollers? Sure. For high-end/general purpose chips? RISC-V cores will have to implement many 'optional' extension to become competitive.
>if RISC-V is to become competitive it will have to become much more complex as well.
Yes, by CISC dogmatism, I was referring to this.
>blatantly refusing to accept simplicity has inherent value
With a touch of CISC propaganda:
>seems to be stuck in the 90s and the distinction is pretty much irrelevant at this point
Thankfully, you won't have to wait too long, now.
RISC-V got on-par feature-wise with x86 and ARM, as of December 2021, while keeping itself simple.
>RISC-V enables the best processors
The very high performance implementations of RVA22+V will begin to appear as soon as next year. And that'll be the end of it.
>RISC-V is inevitable.
Anyone who knows what they're talking about will tell you the same thing. If you don't want to listen to me then listen to Jim Keller. Or ARM star designer (ARM7TDMI, Thumb2, among others) David Jaggar.
So they might well hit June 2022 M2 performance, or thereabouts.
Sure, M1 or M2 class RISC-V hitting the market in 2026 or 2027 is hitting an old performance mark and Apple will have moved on.
Even if not the absolutely fastest thing in the world at that point, M1 performance in 2027 is still going to be a totally usable machine for most people for most purposes. I'm typing this on an M1 Mac Mini I bought in November 2020 and I can see absolutely no reason to replace it any time soon.
You can make whatever comparison you want between M1/M2 and x86.
Wouldn't they need to implement a bunch of additional extensions which RISC-V doesen't currently have just to reach feature parity? That alone would've introduced significant delays.
Also it took Apple 8 or so years to build a competitive desktop/laptop CPU. They released their first custom ARM core in 2012 and likely relied a lot on what they learned while working with Cortex so it's not like they started completely from scratch.
And we're talking about Apple, very few if any other companies are willing to invest as much time and resources into a product targeting a stagnant or even shrinking market (desktops/laptops) with very low margins. I don't think Qualcomm can't design something that would be competitive with M1/2 they probably don't just see a lot of sense in that financially. How would RISC-V change this?
Of course there are political reasons for Chinese companies (being increasingly cutoff from western tech to invest into RISC-V) which might be more important than financial ones. So a shift to RISC-V would be almost guaranteed to increase our reliance on China which in no way could be viewed as something positive...
> I can see absolutely no reason to replace it any time soon.
And presumably you would be fine to replace it when as machine which is just as fast in 5 years just because it used a RISC-V CPU despite there being significantly faster ARM/x86 devices on the market?
Apple doesn't build or learn anything. The people they employ to work there do. When those people go to another company ... e.g. a RISC-V company ... they take that learning with them.
Near Zen5 (projected) performance shown in Tenstorrent slides. M2 is not anywhere near that. Apple would wish.
To directly compete with AMD/Intel they are going to have to be within the same ballpark of performance and cost about the same and consume about the same amount of power. There is simply no way in hell that is going to happen in 2024, not with the amount of catchup they have to do. Even Tenstorrent's own Jim Keller expects their Ascalon to be behind Zen 5 in raw performance / GHz, and Ventana's slides show it barely beating 2021 CPUs[1] which are in turn already massively outperformed by current-gen ones[2].
I fully expect a few RISC-V products to be only a generation or 2/3 behind within a couple of years, but that is simply not enough to be a direct competitor.
[0]: https://arxiv.org/pdf/2309.00381.pdf
[1]: https://www.servethehome.com/ventana-veyron-v1-risc-v-data-c...
[2]: https://www.servethehome.com/amd-epyc-bergamo-epyc-9754-clou...
It is the XuanTie C910 open source core. It has been available for many years.
I have no reason to question Jim Keller nor Wei-han Lien ability to deliver, with their proven track record of delivering.
Tenstorrent presentation late last year talked chiplet availability in 2024. That's the best estimate we can work with, for Tenstorrent specifically.
There's multiple other companies and cores we're aware of, and then the others we don't even know of.
e.g. Rivos has a strong team that's been silently cooking something for a very long time now. It could emerge at any time.
I haven't seen any news on since January, and no concrete shipping date. I signed up on the announcement email list and haven't seen anything there either (or at least I think I signed up; I don't even see an acknowledgement email.)
That's not really a criticism or doomsaying about Intel or SiFive from me -- I'm really interested to see what they have -- but they could do with a better communication strategy.
When I seen this Milk-V Pioneer platform I was very enthusiastic: looks like what I need (minus IPMI, but I can omit this requirement) - one slot for 10G network, one slot for HBA, M.2 slots for caches, I can select RAM (in opposite to most of these platforms, where RAM is soledrid-on), plus ability to experiment with new platform. Looks perfect.
But... $1499?! Plus VAT to import to Europe?!
Sorry. I pass :-(
Why does it cost SO MUCH!?
On other hand... There is NO comparable production RISC-V platforms. You say "It has 64 cores" - well, it is good argument when there is choice. But there is no choice on RISC-V side, there is no such platform with 32 or 8 or any other number of cores. So, I compare what I can buy with "RISC-V" badge and what I can buy with "amd64" badge. When I choose EPYC I could choose from 8 cores up to 64 cores, according to my wallet and needs. For 1000 euro I could have good, proven MoBo which offers more than this "development platform" (i.e. IPMI and VGA exit, which means I don't need any videocard to occupy so precious PCIe slot - and I think, it is good idea for DEVELOPMENT platform to have full remote control & access, IPMI or some other) and 8 core/16 threads first generation EPYC (which will be faster core-to-core, I'm sure), NEW. If I agree to buy second-hand hardware it will be about 550 euros (same mobo, same CPU). For 1400 euros I will get NEW 16 cores / 32 thread EPYC + mobo combo, or about 700 euros second-hand.
Yes, I know, development vs. production, but this situation stays the same for years now.
BTW, situation is the same with ARM platforms too - there is no way to buy "big desktop/small-server class" ARMv8 board with good set of expansion slot.
Sure, it's 4 times the performance, but it's also going to be several times the price.
Even a prebuilt 7950X (16 core) machine costs more than the Pioneer, at leas the ones I've found on the net.
I'm already own good chassis, HBA, 10G network adapter and lot of HDDs :-)
Except I really don't think it's fair to call RISC-V 12 (or 13) years old. Sure, that's when some university guys in a pub said "fuck it, we should just make our own ISA" and started throwing ideas around, but it was a long long time before it was frozen and there was something companies could start building on.
That happened in July 2019. just over 4 years ago, which I think should be counted as the zero date.
When did Arm start working on Aarch64? I don't think we have any idea — as far as I know they've never said. My guess is it was around the 2003 release of AMD64. But the world learned about it when they published the finished ARMv8-A spec in October 2011.
If 2011 is the date for ARMv8 then the fair comparable date for RISC-V is 2019.
> only been making chips for 5 years
Five years ago, the only RISC-V chips were one-off ones made in Berkeley university, and the FE310-G000 and FU540-C000, which were also made by those same guys as were in that pub, manufactured in total volumes of a few hundred, and with no guarantee they would be compatible with the eventual ratified standard.
With the HiFive Unleashed SiFive "shipped a draft spec", which is exactly the same thing they shit on Canaan (K210, priv arch 1.9.1, literally a snapshot of the Rocket repo) and THead (C906/C910 RVV 0.7.1) for. They just got lucky that no breaking changes were made, unlike the other guys.
It's the same for the Talos II using IBM's POWER. It costs a lot because a) it is designed as a workstation and b) the volume just isn't there.
Economies of scale basically.
Obviously DigiKey doesn't have the chipset ICs, but at quantities of 100 just the connectors, VRMs, passives and the big 8-layer PCB to house it was so much higher.
Like I knew it would be higher, but this exercise really put industrialized manufacturing and economy of scale into perspective.
Because it is their first generation chip, thus small production run.
You can either wait for the next one (SOPHON SG2044, with V 1.0 extension, TBA 2024) or get something that's mass-produced now, such as SBCs or tablets based on the JH7110 or TH1520 SoCs.
I think the meaningful question is when we'll see RISC-V CPUs that are performance competitive with x86 or ARM CPUs. In that case, probably not in the near future, at least not for several years at least. x86 and Arm CPUs have decades of optimization behind them. That's the CPU designs themselves, and also compilers, etc. RISC-V has a lot of catching up to do, and Arm and x86 aren't static targets.
That isn't to say that RISC-V won't catch up. There's real momentum behind RISC-V. Also, the development of software built using machine learning introduces wildcards and the possibility of disruption. So in the medium to long term (end of the decade, maybe?) we might see interesting cell phones or laptops that are useful for more than Hacker News tinkerers. I'm looking forward to them.
>when we'll see RISC-V CPUs that are performance competitive
As you said, Arm and x86 aren't static targets. So while they'll catch up to where Arm is today, Arm will be somewhere further ahead at that point. Especially as implemented by Apple silicon. My concern remains that Apple will have to investment strength to always be a few years in the front. Their lead could in fact increase. And that's just CPU.
Also pioneer pricing, as can be expected. But it has uATX form factor, ddr4, pcie3, usb3, sata3 connectivity. You could certainly build a nice desktop with it.
I wonder how many GHz this µArch would reach with TSMC 3nm.
In the Machine Learning startup field, RISC-V is the most popular choice these days.
RISC-V also becomes a national priority for China as far as I can tell, it won't surprise me the best RISC-V designs will be from there.
Why are TLBs so small? Are they super expensive or what? With 32 entries TLB it can cover only 1 Mb of RAM if using legacy 4k pages.