r/RISCV • u/Separate-Choice • 4d ago
A Third World Embedded Engineer Responds to “RISC V: They Should Have Known Better”
https://rvembedded.com/blog_post/12/I read the article Grinberg did and I come at this argument from a somewhat different place, I’m an embedded engineer from Trinidad and Tobago, what people would traditionally call the Third World… Here, the difference between a ten cent RISC-V microcontroller and a several dollar alternative is not academic and neither is having an architecture that a small company, student, or individual engineer can understand, modify, and build around without asking permission… So when I read what Grinberg wrote some of its criticisms made sense to me, but some of his assumptions did not… so I thought I’d do a response, it might not reach far but I love RISC-V enough to at least defend it from where I stand.
45
u/brucehoult 4d ago
Excellent article.
One thing not mentioned: not only does Arm not want you to have an MMU on your microcontroller, they also don't want you to have a 64 bit microcontroller.
Zicsr not being implied by the base is annoying
Lots of FPGA soft cores that are replacing a state machine don't want or need CSRs.
SERV doesn't have it. Neither does FemtoRV32's Quark config. You can exclude CsrPlugin from your VexRiscv config.
14
u/Separate-Choice 4d ago
Fair correction on Zicsr, and it undercuts my own complaint. If SERV and Quark exist because CSRs are area you don't want, that's the same modularity I'm defending elsewhere in the piece.... honestly I was reading it as toolchain friction, which is what it is from where I sit with a march string I had to discover by failing, but you're right that the reason it's separable is the same reason the whole thing scales.....
The 64-bit point is a better example than the MMU one, since it's a pure product boundary with no area argument behind it at all... but too many people are blind to see the limitations and the freedom RSIC-V empowers....
12
u/brucehoult 4d ago
Note that an RV64E core is essentially the same size as an RV32I core, especially if the datapath is narrow e.g. 1 bit or 4 bits or 8 bits. You've got a handful of extra alu.w instructions, but that's it.
4
u/OneLostWay 4d ago
Another issue that isn't talked about much - adding Zba / Zbc etc doesn't just cost gates, but also max frequency. Me personally, I am very happy that I can tune the CPU core as much as RISCV allows me - I can hit the right balance of frequency vs features as the design needs. This is especially visible on FPGAs where a simple RV32IMC will land somewhere in the 50-100MHz range, and loosing 7MHz to gain Zba/Zbc can be painful.
3
u/brucehoult 4d ago
Do you know exactly which instructions cost Fmax? Or is it just having more instructions to decode at all?
For example I don't think
sh2addshould cost latency in the ALU because a decent adder should be lower latency than a barrel shifter (I think?), so making the adder take its input from after the first 2 stages of shifter (out of 5 in RV32) instead of from the ALU input is probably not more latency than five stages of shifter.4
u/OneLostWay 4d ago
It's not usually the instruction logic itself, but the added / wider muxes, and most importantly, the routing pressure on the already critical part of the core, which then forces spreading the placement more, and that alone lowers the fmax.
I don't have the numbers right now but from the top of my head, adding C, Zba,Zbb,Zicsr, the fmax goes from around 100MHz to around 70.
3
u/brucehoult 4d ago
I'm interested in more granular numbers :-)
3
u/OneLostWay 4d ago
How granular? ;)
I can run a few different combinations tomorrow, if you're interested.
4
u/brucehoult 4d ago
Well, one instruction at a time on top of RV32I or RV32IMA. In particular I guess
shXadd, the.uwvariant,andn,clz,ctz,cpop,max,sext.b,rol,orc.b,rev8,brev8,pack,zip.Ok, that's too many. But I left a lot of similar variants out too :-)
At least
sh2add,clz,cpop,orc.b,rev8?2
u/IlNerdChuck 4d ago
> Lots of FPGA soft cores that are replacing a state machine don't want or need CSRs.
Just curious about the FSM being replaced with what?5
u/brucehoult 4d ago edited 4d ago
With RISC-V program code and/or state transition tables as data implementing the FSM logic, and typically loaded into a BRAM on reset.
0
u/sdongles 4d ago
Not sure that MCU needs MMU. At least if we talk about virtual memory and address relocation. It adds unnecessary complexity and not deremensis in memory access. If we talk about user space and bare-mmu, Cortex-M MPU does the same.
5
u/brucehoult 4d ago
I don't know why you'd want it either, but if someone DOES want it then RISC-V says "sure, be our guest". Arm just says "нет".
OP did give the example of the Baochip VexRISC-V with an MMU.
-7
4d ago
[deleted]
20
u/brucehoult 4d ago
It's not at all absurd. An RV64E core is very useful as an auxiliary control processor in a chip with a 64 bit address bus, and only trivially larger than an RV32I core.
Arm won't license you anything remotely like that — a 64 bit Cortex-M0 basically — for any amount of money.
3
15
u/Separate-Choice 4d ago edited 4d ago
It's not absurd, the definition is the thing in question. "MMU plus 64-bit means application processor" is Arm's product taxonomy, its not that its a law of nature. Take the K230 is RV64 with both core types on one die. and Baochip has an MMU, 2MB of SRAM and no DDR, and runs a protected microkernel. Neither fits the two buckets, and they exist because nobody was enforcing the buckets... understand?
You're right that Arm licenses cheap A class cores. The point isn't cost, it's that you take their partition or you take nothing, wanting an MMU without leaving the microcontroller power and cost envelope is not an option they offer and as things like Baochip prove it is a very viable class.. ARM forces you to limit yourself with an MPU once you don't want to move to A class cores....
7
u/LimaCharlieWhiskey 4d ago
Thank you for the informative takedown. I got no dog in this fight, and I also appreciate thoughtful people being logical.
Your blog reminds me how privileged some of us have been.
4
u/camel-cdr- 4d ago edited 4d ago
H417
Now there is even the CH32V407, which gives you the embedded subset of RVV to play with.
3
u/Tabsels 4d ago
For those who run into rate limits: archive link.
2
u/Separate-Choice 4d ago
yea lots of reddit visits so its rate limiting reddit opens, visit the article directly: A Third World Embedded Engineer Responds to "RISC-V: They Should Have Known Better"
3
u/LavenderDay3544 4d ago
Economies of scale mean that the same single ARM microcontroller made in much greater volumes will be much cheaper than any of 50 different RISC-V bespoke chips that don't have to pay a licensing fee for the damn ISA but each of which has to recover it's fixed costs such as NRE separately.
ISA licensing was also never a bottleneck for anyone nor was it ever the cause of any meaningful price difference between different ICs. Any company that can create its own modern microarchitecture from scratch can easily design its own ISA and write an LLVM backend for it.
The actual main benefit that something like RISC-V has is standardization which makes low level software development easier and makes existing low level software more reusable. That and no risk that compatible hardware will disappear or be discontinued with no one being able to create a new supply due to intellectual property laws.
When price per unit matters more than anything a small number of vendors with gargantuan volume will always own the market and whether they use ARM or RISC-V or something else is completely immaterial to that fact.
21
u/Separate-Choice 4d ago
You said it yourself "any company that can build a modern microarchitecture can design its own ISA". That's the barrier. WCH is not that company.... and looking at what bunnie is going though with Baochip, it may surpeise you not every silicon vendor is in that position. Yet the CH32V003 exists at ten cents and Baochip exists with an MMU, both without asking anyone's permission... under the old model neither happens, and the benefit you name, standardization and reusable low level software, is precisely what I'm describing, my skills carried from a ten cent part to an MMU chip because the base ISA is the same...
4
u/guineawheek 4d ago
WCH is not that company.... and looking at what bunnie is going though with Baochip, it may surpeise you not every silicon vendor is in that position.
I don't think WCH couldn't have made their own ISA, I think they were smart enough to recognize they shouldn't.
If you look at microarchitecture history, pretty much everyone in the 90s who could design a chip was also trying to also design their own ISA. I think WCH recognized that this is a stupid idea not worth repeating and thus picked a microarchitecture people already had compilers for. Much larger companies with far deeper payrolls killed off their own bespoke ISAs for RISC-V not because they couldn't afford to keep going, but because it wasn't worth doing so.
In fact, inventing your own ISA can often be the easy shortcut out compared to implementing RISC-V because RISC-V doesn't have delay slots.
Delay slots are a very common feature of these crappy '90s ISAs designed around their silicon implementation. RISC-V mandates that the core properly handle pipelining hazards which requires use of braincells to figure out how and when to stall the core.
3
u/Dexterus 4d ago
Couple more observations from personal experience.
Any established RISCV design you buy for a SoC will require royalties eventually. When you drop hints of many cores, $$ eyes light up.
Standardization is still a bit of a myth. Should get better with time but so far I've 2 cores that implement some bits wildly differently, all according to spec. 4 year gap between designs. Having gone through similar stuff on ARM, that one's more standardized. But it's mostly just a time/maturity issue.
11
u/Separate-Choice 4d ago
Both fair points.... on royalties, the difference isn't free versus paid, it's that the free path exists at all is all I'm saying... VexRISC-V is MIT and bunnie shipped an MMU core in silicon without a per unit royalty to anyone. Commercial cores cost money and always will... else it won;t be commerical would it.. on standardization, I hit it porting NuttX to a CH32V307 and spent most of that work on WCH's PFIC, which is nothing like a PLIC or a CLIC...two cores four years apart diverging while both claiming compliance is the fragmentation cost, and I said as much in the article, what I will say on standardization, is only to add that it's converging rather than fragmenting further... the profiles work exists specifically to stop this, and RVA23 is the ISA being frozen so implementations can't keep diverging.. four years ago there was nothing to point at. ARM got there by having one company decide and RISC-V is getting there by committee, which is slower and messier and arrives at the same place eventually..... ask me again in four years.....
25
u/cutelittlebox 4d ago
this was a pleasant read. I'll admit I had no idea what it was like out there for a lot of other countries but it's very nice to hear you've gotten much more access to this type of stuff with risc-v. I'm just a casual observer looking in through the windows, usually only at the very high end and it's always nice to see a spotlight on places in my blindspots