A New Golden Age for Computer Architecture
cacm.acm.org
cacm.acm.org
The base RISC-V ISA is indeed very small. However, to compete with ARM/MIPS/x86 usefully as an application core, one must include many standard extensions. All of which add comparable complexity to the ARM/MIPS feature which they ape. It feels wrong to assert then without some serious qualification that RISC-V is simpler or easier to verify. A RISC-V core is no more or less complex to verify than a comparably featured ARM/MIPS core.
That said, and open ISA like RISC-V can really lead the way in terms of shared verification IP. That is the benefit to an open ISA, not it's simplicity, but the fact that it becomes worthwhile for people to share their verification infrastructure. Unfortunately, I haven't seen much of this yet. riscv-formal is amazing, and the riscv-compliance suites are getting better, but proper constrained random stimulus generation and coverage collecton? Not yet, at least, not out there in the open source world. I really wish that Western Digital had included their verification infrastructure when they open sourced Swerv [1].
Really enjoyed the article otherwise!
0 - A reasonable person might disagree this claim is being so explicitly made, but that's what I took from it.
> Fewer instructions. RISC-V has many fewer instructions. There are 50 in the base that are surprisingly similar in number and nature to the original RISC-I.30 The remaining standard extensions—M, A, F, and D—add 53 instructions, plus C added another 34, totaling 137. ARMv8 has more than 500; Fewer instruction formats. RISC-V has many fewer instruction formats, six, while ARMv8 has at least 14.
Also, I don't know how the 500 ARMv8 instructions was reached. If there are 500 instructions in the entire ISA, that's an unfair comparison, since there might be functionality in there not directly present in RISC-V. E.g. SIMD functionality.
Ofcourse fewer instructions to implement are fewer instructions to verify, but I disagreed with how simple the article made it sound.
> REP MOVS/STOS Executing with Fast Strings Enabled and Crossing Page Boundaries with Inconsistent Memory Types may use an Incorrect Data Size or Lead to Memory-Ordering Violations
> Changing the Memory Type for an In-Use Page Translation May Lead to Memory-Ordering Violations
> When a Link is Degraded on a Port due to PCIe* Signaling Issues, Correctable Receiver Errors May be Reported on The Neighboring Port
The 1st is related to ISA complexity, the 2nd and 3rd aren't.
Based on a quick scan, I think 24 of the first 100 errata are ISA-complexity related. So "meaningfully easier" might be justified, but many problems come from peripherals or the MMU rather than the instruction decoder.
[0] https://www.intel.com/content/dam/www/public/us/en/documents...
Bugs in instruction decoders are something of a false flag in my opinion. They are no less important than other bugs, but they are much easier to find as well, because the problem space is more manageable. A little more complexity in an instruction decoder is not, in my opinion, enough justification to exclude otherwise useful instructions or functionality.
We used to do this in the 1990s with PHS cell phones in Japan: you certainly didn't need to listen to the microphone until a call was actually connected, and even then the caller might listen and not talk, so after connection you'd listen to the microphone but still not start up the voice compression chips until the noise got above a threshold (so a bit of the moshi moshi would get cut off -- no big deal).