SiFive’s P870 Takes RISC-V Further
chipsandcheese.com
chipsandcheese.com
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.
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://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.
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.
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":
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.
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.
(no concrete promise, thus not late)
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.
I wonder how many GHz this µArch would reach with TSMC 3nm.
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.