Their books are perfect, and I hope this textbook gets adopted by thousands of colleges. Our RISC-V future is bright, now we need one on SoC bringup and getting your OS running on that SoC.
I re-took Computer Architecture recently, and we used their earlier book "Digital Design and Computer Architecture: ARM edition", and it was also excellent.
They mean between the authors. It's a common added expression when discussing two or more people whose names suggest a familial relationship but there isn't one.
Based on description it doesn't sound like SoC design, it sounds like a book about RISC-V microprocessors. To the untrained eye, that sounds similar, but a microprocessor is one part of an SoC, and sometimes it can be a very small part based off the role the microprocessor plays.
Disclaimer up front: I've only read ~10/23 RVSoC draft chapters that were made available as a part of SP2025 E154, so don't take me as any kind of authority on the remaining 13, which I can't wait to get my hands on!
In the preface on xx-xxi:
```
This book took three years of development and another year of production.
There are many more important topics in computer architecture and SoC
design that were omitted from this edition for schedule reasons; we hope
to address them in a future volume:
* Multicore
* Multilevel cache coherency
* Synchronization
* Interprocessor communication
* Timing and power optimization
* Clock gating
* Clock domain crossings
* External interfaces
```
It's definitely processor-centric but I wouldn't say "about RISC-V microprocessors" catches it either. The book is certainly structured around the core, but arguably so too is SoC design, at least at an introductory level. RVSoC uses a real SoC design (CORE-V Wally), and each aspect is covered at a length more or less proportionate to the complexity of its implementation in Wally. Admittedly, Wally's peripherals are fewer and simpler than you might find out in the wild. Wally itself is 80-90% core by lines of RTL (horrible complexity metric I know, sorry).
Another way to look at the book is that it picks up where Digital Design and Computer Architecture (by the same Harris and Harris) leaves off. DDCA is used to teach the E85 course at Harvey Mudd; RVSoC is used to teach E154 (SoC design). DDCA builds up to a simplified RV32I-subset pipelined core. If RVSoC started with peripherals without fully elaborating the core, it would leave both readers of both books and students of both courses with a gap in coverage on core design compared to the depth of the remainder of both books.
Both are very detailed. With RVSoC at 859 pages in print and 1135 after the digital supplement, the core-related chapters are not by any means stealing airtime from the other components of the SoC, you could strip out every core-related page and still have a modestly-sized textbook. While not by any means an encyclopedic reference for SoC design, I found it to be a wonderful bridge from more elaborated microarchitecture into SoC.
I hope they are able to get that future volume out!
What are some good books/resources on overall System-On-Chip Design?
There is a surprising paucity of material on SoC design which are comprehensive and complete. Application-specific tailored features, Cost, Performance, Area, Power etc. all go into SoC design and yet there does not seem to be a comprehensive resource bringing everything together. Even wikipedia isn't detailed enough - https://en.wikipedia.org/wiki/System_on_a_chip
I know of only two decent books viz. Computer System Design: System-on-Chip by Michael Flynn and Wayne Luk (this is pretty good) and the older ARM System-on-Chip Architecture by Steve Furber.
I like RISC-V (it's been my job for the last 7 years) but this is nonsense. Not everything RISC-V is good. CLIC was awful (thankfully it has been abandoned). The spec is not especially well written - the style is inconsistent due to being written by many authors, and it is waaaay too much of a textbook rather than a proper spec. (There is some ongoing work to improve this tbf.)
There's a practically unending list of undefined/implementation defined behaviours, which is great if you want to implement an ultra minimal microcontroller with 100 flops, but pretty awful otherwise.
Requiring the C (compressed) extension in the RVA profiles was definitely a mistake. The lack of true 16/64kB pages and conditional moves are probably a mistake (though fixable).
I don't know how any of these make it more robust and mature.
(But to be clear, I still think it's pretty good overall.)
Requiring C (compressed) is necessary to avoid splitting the Linux ecosystem. Chips lacking C would never be able to run binaries compiled with C. There's no practical way for such binaries to detect this and work around it at runtime as they can with other extensions. And emulation would be super-slow given a large proportion of instructions are compressed.
Also the excuse given by Qualcomm - that it would make all instructions fixed length and so much easier to decode - is just wrong. RISC-V supports variable length instructions, even much longer than 32 bits, and you've just got to deal with it. Just because Qualcomm acquired a company with a microarchitecture that could only deal with fixed length instructions is no reason to break the ecosystem.
Also interested in the problems you see in Zicond. It claims at least to give you most of the benefit of conditional moves using only two instructions, but I've not actually tried using it. (https://docs.riscv.org/reference/isa/extensions/zicond/_atta...)
> RISC-V supports variable length instructions, even much longer than 32 bits, and you've just got to deal with it.
...no, not really? There is nothing like 9 byte-long MOVABS instruction of x64 that exists on RISC-V.
The main difficulty in decoding is that 32-bit instructions are not required to be 4-byte aligned, this means that naïve decoders will spend 2 cycles fetching such split instructions. It's possible to add a 4-byte ring buffer but all in all, efficiently supporting the C extension is non-trivial.
RISC-V definitely does support instructions longer than 32 bits, starting at 48 bits (ie. 32 + 16), and going much longer. They are much easier to decode than x86 because the length is evident from the first byte. No ratified extension uses them now, but you're going to need to deal with them as the extension space gets more crowded. Including dealing with instructions split across cache lines and pages, and instructions aligned to 16 bits.
My point is that fixed-length instructions are supposed to be easier to decode than variable-length ones, right?
If not, then why even bother with fitting immediates and inventing LUI/AUIPC, just have a 48-bit long LI instruction. The same goes for 64-bit, an 80-bit LI.W is still shorter than the piecemeal construction with several instructions.
If yes, then the small cores are arbitrarily given a burden of supporting variable-length instructions, supposedly efficiently: if your instruction fetch is 16-bit wide, you need two fetches to fetch a single 32-bit instruction, which sucks; if it's 32-bit wide, you need to conditionally stash the upper half for the next fetch cycle, and still prefetch yet more 32-bits because that upper half may contain only a half of a full 32-bit instruction; alternatively, you can fetch 32-bits at alternated aligned/misaligned addresses and ignore the inefficiency of throwing away re-fetched bits — again, all of this sucks.
Yes, fixed-length instructions are easier to decode, but that also means a hard upper limit on the number of instructions that could ever be supported. Which is obviously a problem for a future-proof architecture.
I've read that rationale, and it's, well, I'm not going to say it's lying, but it's insincere. By the time it was written, they already settled on 16-bit alignment, and fetching (and then decoding) 16-bit aligned 32-bit instructions is either inefficient, or hard, or requires extra circuitry (or an instruction cache).
High performance RISC-V chips exist from Rivos, Ventana and others, and high performance variable length chips also exist in general (AMD, Intel). So in actual reality it increases complexity somewhat, but is not a problem.
sighs This kind of discussion is so annoying... I start with "RISC-V's decision to make 32-bit instructions only 16-bit aligned complicates instruction fetch and decoding", and the response is "For high performance RISC-V implementations, it's a trivial matter" (which is true), I response with "But then why even bother with mostly-fixed-but-not-quite instruction length, just make a properly variable length ISA, it'd even simplify the instructions", and the reply is "the low-end implementations would struggle with decoding that efficiently" — but they already struggle with instruction fetch when they implement C extension! Nah, it's fine, the high-end chips can cope with that.
And round and around this discussion goes... Apparently, RISC-V has no downsides at any end of the price spectrum, what a marvelous ISA.
If you have some specific question I may be able to answer it, since I've been involved with RISC-V for over a decade, dealt with all the main companies involved, written papers, etc. but so far I see no actual question or concrete objection.
> also means a hard upper limit on the number of instructions that could ever be supported. Which is obviously a problem for a future-proof architecture.
You can see the encoding limitation it in the design on SVE, which only has destructive operations, but MOVPRFX, which is a round about way of doing 64-bit instructions, without doing 64-bit instructions.
Many here wish for the non IP-locked RISC-V to get performant micro-achitectures for embedded/server/desktop/mobile that on the latest silicon process (without that, you can have a very good micro-architecture, that won't probably make the difference).
If some RISC-V high performance CPU manufacturers are being bought by big hardware actors: either they are scared of its competition and want to scrap it or they want to be part of RISC-V.
> small cores are arbitrarily given a burden of supporting variable-length instructions
Even the smallest commercial microcontroller cores e.g. the CH32V003, support the C extension. They strip out other things, such as half the integer registers, but they keep C.
And that's in a market where you can use literally any combination of extensions you want, because the customers compile all their own code, and you just tell them what ISA string to use.
There are two options when designing an ISA to achieve competitive code size, add variable length instructions or add more complex fixed-length instructions which require cracking (2W instructions). The other option is: maybe codesize don't matter?
For high performance implementations both decoding variable length instructions and decoding/cracking fixed-length instructions into uops, are rather analogous in terms of the work hardware needs to do.
However, I think the advantage of fixed-length instructions, is that you can do further tricks, like pre-decoding in Icache.
With RVC, you can also do pre-decoding, but now you need twice the amount of pre-decoding data, unless you find other tricks.
Still, in a reasonable variable-length ISA and fixed-length ISA, the variable-length one will get better code size.
There are also a lot of other things to consider, RVC is self synchronizing, cracking is challenging for decode, but also keeps the backend better fed, how more instruction starts impact branch predictors, instructions crossing cache-lines...
I benchmark compiling programs with a rva23 clang build and clang compiled for rva23-without-C and got a 10% performance improvement from RVC on the SpacemiT X100.
The X100 is a 4-wide out-of-order core and afaik doesn't do anything special for RVC, except for expanding the 16-bit to 32-bit instructions.
It's hard to quantify the real impact on a CPU design, but going the fixed-width route seems to enable more optimizations (not so much the decoding it self).
Well, instruction cache still has limited size, and you still need to get your code into it. Paging in 512 KiB from the disk is faster than paging in 1 MiB from the disk.
> like pre-decoding in Icache.
I'm fairly certain x64 also does that?
> RVC is self synchronizing,
No, not really. You can still jump into the middle a 32-bit instruction, and it's possible it can be reinterpreted as a valid 32/16-bit instruction. Remember when people complained about how "overlapped instructions"/"hidden instruction streams" on x64 enable even more ROPs/gadgets than meets the eye? Don't worry, RISC-V has those too!
> No, not really. You can still jump into the middle a 32-bit instruction, and it's possible it can be reinterpreted as a valid 32/16-bit instruction. Remember when people complained about how "overlapped instructions"/"hidden instruction streams" on x64 enable even more ROPs/gadgets than meets the eye? Don't worry, RISC-V has those too!
Sure, it's a probabilistic thing. Whenever you see a 2-byte block starting with 0b11, you know there is an instruction start after those 2 bytes.
When I last looked at it, I got synchronize 99% of the time, when looking at a 8-byte block.
In one qemu trace I empirically got that only 626 out of 70479 8-byte blocks don't contain synchronizations.
This certainly seems like something you could exploit quite well, if you are doing things like 8+ wide decoding. (maybe have a fast path that safes one cycle of latency)
> Requiring C (compressed) is necessary to avoid splitting the Linux ecosystem. Chips lacking C would never be able to run binaries compiled with C.
Yes that's precisely the point of excluding it from the RVA profiles. It would mean that Linux distros don't compile code with C enabled, so chips are free to not support C and therefore can achieve higher performance (probably). And it opens 3/4 of the instruction encoding space for use by other things.
> Also the excuse given by Qualcomm - that it would make all instructions fixed length and so much easier to decode - is just wrong. RISC-V supports variable length instructions, even much longer than 32 bits, and you've just got to deal with it.
It's not wrong. RISC-V defines a mechanism by which 48/64 bit instructions might be used, but currently none are actually defined. All existing instructions are 16 or 32 bits. Without C all instructions are 32 bits. You don't have to deal with 48 bit instructions because there aren't any.
It's possible that they will add some in future, but I'm doubtful of that because a) it would be a huge pain, and b) they didn't for Vector which is where it would have been most useful.
> Just because Qualcomm acquired a company with a microarchitecture that could only deal with fixed length instructions is no reason to break the ecosystem.
Yeah it was too late to change but that doesn't mean it wasn't a mistake.
> Yes that's precisely the point of excluding it from the RVA profiles. It would mean that Linux distros don't compile code with C enabled, so chips are free to not support C and therefore can achieve higher performance (probably). And it opens 3/4 of the instruction encoding space for use by other things.
The debate was between 16/32/48/64-bit instructions vs naturally aligned 32-bit and 64-bit instructions + new more complex instructions that require cracking to regain code size (things like load/store pair).
> RISC-V defines a mechanism by which 48/64 bit instructions might be used, but currently none are actually defined
The long-instruction-SIG just started a few weeks ago, and they are working on defining 48/64-bit encodings for instructions that could be used in future RVA profiles (so with high perf implementations in mind). If you are knowledgeable about this stuff, please get involved, so they don't mess it up. (not "you" specifically, but in general)
Compressed is necessary to reduce code size which is important for performance.
A bunch of vendors have done high performance server chips which support compressed (Rivos, Ventana, some Chinese vendors), so in actual reality this was only a problem for Qualcomm. And that's only because Qualcomm bought Nuvia and they wanted to do the cheap thing (minimally change the front end) rather than the right thing.
Of course you can make compressed work. E.g. you fetch 66 bytes instead of 64. Hell, Intel/AMD manage to make x86 fairly fast.
But it's definitely more awkward and has costs throughout the CPU.
I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned. Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).
Not really, you would fetch fewer bytes with RVC [2, page 9], because the code density is better.
> I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned.
This is very hard to quantify.
> Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).
I've liked the back and forth slides bellow.
Though I want to bring up to things regrading the Qualcomm slides:
> [RVC] Performance benefit is modest
> • Best case: 2-3% speedup
I recently benchmark compiling programs with a rva23 clang build and clang compiled for rva23-without-C and got a 10% performance improvement from RVC on the SpacemiT X100.
I also have no idea how they got those numbers. (not that they are wildly implausible, it's just not transparent)
> Improving Android Code Size
In the last presentation they show how you can add a +-64M 32-bit long jump instruction to improve codesize in large binaries, like those in android.
You don't really fetch 66 bytes instead of 64, what real implementations do is read cache lines (of whatever size) and hold on to 2 bytes from the previous cache line if there was 1/2 a 32-bit instruction at the end of the previous cache line (the ISA has the 16/32-bit tag in the lower byte so you know how big an instruction will be even if you've only seen half of it)
> […] and hold on to 2 bytes from the previous cache line if there was 1/2 a 32-bit instruction at the end of the previous cache line […]
Well, and that is the worst case scenario from the performance standpoint since, if a 32-bit instruction is spans a page boundary, it will result in a page fault stalling the instruction decoder.
It might be acceptable in implementations not sensitive to such an overhead (e.g. embedded solutions) but is wholly unacceptable in high performance scenarios.
And how is an instruction spanning a page boundary and causing a page fault any worse than an instruction NOT spanning a page boundary and the next instruction causing the page fault instead?
As Paul said, if a 4 byte instruction spans a cache line/page boundary then you just hang on to the last 2 bytes of the page (first 2 bytes of that instruction) and decode them along with the instructions in that next cache line / page.
The only time it could possibly make a difference is if that spanning instruction is a jump to somewhere else AND that instruction could somehow have fit entirely in the previous page.
If there was no C extension then that next instruction would NOT be entirely in the previous page, it would be somewhere well into the next page, and that next page would have been required to be fetched much sooner. The C extension typically allows 30% to 50% more functionality to fit in each VM page.
Also, Qualcomm's proposed new instructions did not in fact use the freed-up space from not having C. They fit into other unused parts of the ISA.
I don't object to the new instructions Qualcomm suggested. I'd be perfectly happy to see them ratified and added to a future standard (even to RVA23 if they'd chosen to pursue that, but they didn't).
What I and others objected to was dropping the C extension from RVA23, or any future RVA-series, overnight given that RVA20 and RVA22 already existed with the C extension.
There will come a time when some RISC-V extensions will be retired and replaced, and it's entirely possible that C might be one of them, but there is currently no mechanism to do that, and when there is I'd expect that it would be done with a 10 or 12 year deprecation period, minimum.
NEVER overnight between one standard and the next one.
Which wouldn't have helped Qualcomm with their Nuvia core anyway.
Anyway, Qualcomm had now bought Ventana, which has engineers who know how to support the C extension with high performance, and they already had high performance RISC-V cores doing so.
x86 is an ancient design mired in legacy and problems, so Intel/AMD Intel and AMD had to make it work for a modern world even if that involved kludges, band-aids, and crutches. Whilst you do have a point there, personally I do not find x86 particularly interesting to discuss.
I did not have Qualcomm and their latest bout of theatrical shenanigans concerning C in mind, either.
Back onto C.
– C demonstrably improves code density;
– Improved code density is conducive of better instruction cache utilisation and reducing the pressure on the TLB;
– Mixed-width decoding (a trade-off) demonstrably adds front-end work (especially in pathological cases[0]);
– No publicly benchmarked RISC-V processor is sufficiently contemporary and wide (or very wide) to impart the net effect of that trade-off at the highest performance tier;
– Performance targets (aarch64 and x86-64) are moving faster than publicly demonstrated performance of existing RISC-V implementations in silicon, and the gap is not closing in.
So purported performance benefits of C may or may not materialise – it remains to be seen and proved, and claims that a future wide RISC-V core will validate design choices such as C remain not yet falsified projections rather than demonstrated engineering results – at this stage.
[0] The second page is not resident, the decoder can't proceed because the second half-word can't be obtained, the access generates a page fault, the CPU eventually vectors to the page-fault handler. Genuine page faults are extremely expensive.
English is not my native language and I wrote a bit too fast the message: I wanted to say that "everything pushing forward RISC-V is good".
I code RISC-V assembly, I don't use C machine instructions (I don't even use the pseudo-instructions, ABI register names and dodge nearly all ISA extensions, I try to stick to core as much as I can). I run my code on x86_64 linux with a small interpreter written in x86_64 assembly (thx to the 'R' in RISC).
I wonder if there are some 'broad and not niche, real-life' speed benchmark numbers to show how much C machine instructions are worth.
For the moment, I see those C machine instructions more as a marketing extension to match their arm equivalent: you know, for those key deciding people who care more about the amount of features and not their contextual pertinent usage.
To say an ISA is "good" is related to some set of technical sweet spots based on compromises based on projected usages.
RVA from my point of view is mostly preparing RISC-V hardware for some level of x86_64/arm compatibility.
I wonder if there are RISC-V implementations using the latest silicon process from TSMC.
I don't think you're going to find a single benchmark on the effectiveness of compressed instructions since it really depends deeply on both the workload and the whole system. For example, memory bandwidth and cache pressure are both important for whether smaller text sizes matter, and that may depend on what else is running at the same time.
Note your assembler may be automatically compressing instructions without you asking. You'll have to disassemble the binary to find out.
Maybe the best approach is to remove C from RVA while keeping it around in the specs for niche applications where text size _really_ matters (with current silicon processes, I wonder how weird those niche applications have to be to require C). But it seems some would remove C even from the specs to free some ISA space. If arm removed thumb...
Don't worry, I would know if the assembler is producing C machine instructions, my rv64 interpreter on x86_64 does not support the C instructions at all.
You can't remove C from future RVA because a large part of the value of RVA is that each version can run all the shrink-wrapped (binary distribution) code built for the previous versions.
Well, I said that because based on the documents provided here, it seems there are key people considering its removal even from the specs.
From my point of view, just do like all the others: clearly deprecate it, namely say that "from RVAx, don't create new machine code with the C extension". It is like in the linux kernel, it will then be removed very far in the future. But RISC-V is all about the far future, it can only be better to fix it asap.
After reading the comments and documents provided here, I am the first to be suprised by how much doing 'performant C' is not that easy and has a significant hardware cost. "arm removing thumb" should have been a strong signal.
Again, I am coding rv64 assembly almost every day, a good part could be C-ized to shrink text size, but based on various numbers provided here, why bother, better keep the 'R' of RISC as faithfull to its goal than anything else.
Excellent find, an academic paper announcing the book is here
https://peer.asee.org/57147.pdf
Harris and Harris (no relation) have an excellent book on digital design using RISC-V as the domain problem, https://pages.hmc.edu/harris/ddca/ddcarv.html
https://pages.hmc.edu/harris/ddca/
Their books are perfect, and I hope this textbook gets adopted by thousands of colleges. Our RISC-V future is bright, now we need one on SoC bringup and getting your OS running on that SoC.
and the associated github https://github.com/openhwgroup/cvw
I re-took Computer Architecture recently, and we used their earlier book "Digital Design and Computer Architecture: ARM edition", and it was also excellent.
Why do you say (no relation) when the authors are exactly the same?
Not sure about "David Harris" and "Sarah L. Harris" being exactly the same...?
They mean between the authors. It's a common added expression when discussing two or more people whose names suggest a familial relationship but there isn't one.
Based on description it doesn't sound like SoC design, it sounds like a book about RISC-V microprocessors. To the untrained eye, that sounds similar, but a microprocessor is one part of an SoC, and sometimes it can be a very small part based off the role the microprocessor plays.
Disclaimer up front: I've only read ~10/23 RVSoC draft chapters that were made available as a part of SP2025 E154, so don't take me as any kind of authority on the remaining 13, which I can't wait to get my hands on!
In the preface on xx-xxi:
```
This book took three years of development and another year of production. There are many more important topics in computer architecture and SoC design that were omitted from this edition for schedule reasons; we hope to address them in a future volume:
* Multicore
* Microarchitecture
* RISC-V Extensions
* Verification
* SoC Design
* SoC Implementation
```
It's definitely processor-centric but I wouldn't say "about RISC-V microprocessors" catches it either. The book is certainly structured around the core, but arguably so too is SoC design, at least at an introductory level. RVSoC uses a real SoC design (CORE-V Wally), and each aspect is covered at a length more or less proportionate to the complexity of its implementation in Wally. Admittedly, Wally's peripherals are fewer and simpler than you might find out in the wild. Wally itself is 80-90% core by lines of RTL (horrible complexity metric I know, sorry).
Another way to look at the book is that it picks up where Digital Design and Computer Architecture (by the same Harris and Harris) leaves off. DDCA is used to teach the E85 course at Harvey Mudd; RVSoC is used to teach E154 (SoC design). DDCA builds up to a simplified RV32I-subset pipelined core. If RVSoC started with peripherals without fully elaborating the core, it would leave both readers of both books and students of both courses with a gap in coverage on core design compared to the depth of the remainder of both books.
Both are very detailed. With RVSoC at 859 pages in print and 1135 after the digital supplement, the core-related chapters are not by any means stealing airtime from the other components of the SoC, you could strip out every core-related page and still have a modestly-sized textbook. While not by any means an encyclopedic reference for SoC design, I found it to be a wonderful bridge from more elaborated microarchitecture into SoC.
I hope they are able to get that future volume out!
(edit: quote formatting)
Uh, I don't know what's still in there. Based on your exclusion list you've dropped all the core SoC topics...
Like how do you even build a SoC if you don't talk about how to build the peripherals or how to wire them up?
Judging by the authors, I'm sure the book will be excellent. Hopefully it will be available through O'Reilly Online, because the price is a bit steep.
A couple of sample chapters are available here https://pages.hmc.edu/harris/ddca/rvsocd.html
Andy Tanenbaum style cover.
Ooof. €109.70 in paperback
I just pre-ordered this book and think it's definitely worth it.
Full disclosure: I have no affiliation with the author, but I'm sharing because I genuinely believe in the work.
Why do you say it's worth it before you've even read it, let alone seen it?
It’s worth (for me paying that amount of money for) it.
We all do this kind of value judgement before paying for a product we haven’t yet evaluated.
You can get it direct from Elsevier for ~78 euros: https://shop.elsevier.com/books/risc-v-system-on-chip-design...
For the ebook
Use FOOD30 for 30% off.
“The promo code "FOOD30" is not valid.”
Might be a region-specific promo code? Worked in the US for me.
Works only on the paperback. I had added the bundle to my cart.
With or without DRM?
It's available as a PDF. I think Elsevier puts the buyer's name (email address?) into the file as a watermark of sorts, but that is it.
Maybe it's just a regional thing, but it's showing 78 euros for the paperback for me. Plus I bought the paperback recently at that price too.
You know what. I feel like it’s a fair price.
What are some good books/resources on overall System-On-Chip Design?
There is a surprising paucity of material on SoC design which are comprehensive and complete. Application-specific tailored features, Cost, Performance, Area, Power etc. all go into SoC design and yet there does not seem to be a comprehensive resource bringing everything together. Even wikipedia isn't detailed enough - https://en.wikipedia.org/wiki/System_on_a_chip
I know of only two decent books viz. Computer System Design: System-on-Chip by Michael Flynn and Wayne Luk (this is pretty good) and the older ARM System-on-Chip Architecture by Steve Furber.
There's also Modern System-on-Chip Design on Arm textbook by David J. Greaves and it's available as a free download [1].
[1] https://www.arm.com/resources/education/books/modern-soc
Nice; thanks for the pointer.
Searched Amazon for other books on SoC design and found a series of books by Dr. Veena S. Chakravarthi which seem quite comprehensive - https://www.amazon.com/s?k=Veena+S.+Chakravarthi&i=stripbook...
Everything RISC-V is good (even the mistakes which is making it more robust and more mature).
I like RISC-V (it's been my job for the last 7 years) but this is nonsense. Not everything RISC-V is good. CLIC was awful (thankfully it has been abandoned). The spec is not especially well written - the style is inconsistent due to being written by many authors, and it is waaaay too much of a textbook rather than a proper spec. (There is some ongoing work to improve this tbf.)
There's a practically unending list of undefined/implementation defined behaviours, which is great if you want to implement an ultra minimal microcontroller with 100 flops, but pretty awful otherwise.
Requiring the C (compressed) extension in the RVA profiles was definitely a mistake. The lack of true 16/64kB pages and conditional moves are probably a mistake (though fixable).
I don't know how any of these make it more robust and mature.
(But to be clear, I still think it's pretty good overall.)
I broadly agree with your points except one.
Requiring C (compressed) is necessary to avoid splitting the Linux ecosystem. Chips lacking C would never be able to run binaries compiled with C. There's no practical way for such binaries to detect this and work around it at runtime as they can with other extensions. And emulation would be super-slow given a large proportion of instructions are compressed.
Also the excuse given by Qualcomm - that it would make all instructions fixed length and so much easier to decode - is just wrong. RISC-V supports variable length instructions, even much longer than 32 bits, and you've just got to deal with it. Just because Qualcomm acquired a company with a microarchitecture that could only deal with fixed length instructions is no reason to break the ecosystem.
Also interested in the problems you see in Zicond. It claims at least to give you most of the benefit of conditional moves using only two instructions, but I've not actually tried using it. (https://docs.riscv.org/reference/isa/extensions/zicond/_atta...)
> RISC-V supports variable length instructions, even much longer than 32 bits, and you've just got to deal with it.
...no, not really? There is nothing like 9 byte-long MOVABS instruction of x64 that exists on RISC-V.
The main difficulty in decoding is that 32-bit instructions are not required to be 4-byte aligned, this means that naïve decoders will spend 2 cycles fetching such split instructions. It's possible to add a 4-byte ring buffer but all in all, efficiently supporting the C extension is non-trivial.
RISC-V definitely does support instructions longer than 32 bits, starting at 48 bits (ie. 32 + 16), and going much longer. They are much easier to decode than x86 because the length is evident from the first byte. No ratified extension uses them now, but you're going to need to deal with them as the extension space gets more crowded. Including dealing with instructions split across cache lines and pages, and instructions aligned to 16 bits.
I'm not sure what point you're making TBH.
My point is that fixed-length instructions are supposed to be easier to decode than variable-length ones, right?
If not, then why even bother with fitting immediates and inventing LUI/AUIPC, just have a 48-bit long LI instruction. The same goes for 64-bit, an 80-bit LI.W is still shorter than the piecemeal construction with several instructions.
If yes, then the small cores are arbitrarily given a burden of supporting variable-length instructions, supposedly efficiently: if your instruction fetch is 16-bit wide, you need two fetches to fetch a single 32-bit instruction, which sucks; if it's 32-bit wide, you need to conditionally stash the upper half for the next fetch cycle, and still prefetch yet more 32-bits because that upper half may contain only a half of a full 32-bit instruction; alternatively, you can fetch 32-bits at alternated aligned/misaligned addresses and ignore the inefficiency of throwing away re-fetched bits — again, all of this sucks.
Yes, fixed-length instructions are easier to decode, but that also means a hard upper limit on the number of instructions that could ever be supported. Which is obviously a problem for a future-proof architecture.
The rationale for this and also for confining the base set to 32 bit is explained here: https://docs.riscv.org/reference/isa/v20250508/unpriv/extend...
I've read that rationale, and it's, well, I'm not going to say it's lying, but it's insincere. By the time it was written, they already settled on 16-bit alignment, and fetching (and then decoding) 16-bit aligned 32-bit instructions is either inefficient, or hard, or requires extra circuitry (or an instruction cache).
High performance RISC-V chips exist from Rivos, Ventana and others, and high performance variable length chips also exist in general (AMD, Intel). So in actual reality it increases complexity somewhat, but is not a problem.
sighs This kind of discussion is so annoying... I start with "RISC-V's decision to make 32-bit instructions only 16-bit aligned complicates instruction fetch and decoding", and the response is "For high performance RISC-V implementations, it's a trivial matter" (which is true), I response with "But then why even bother with mostly-fixed-but-not-quite instruction length, just make a properly variable length ISA, it'd even simplify the instructions", and the reply is "the low-end implementations would struggle with decoding that efficiently" — but they already struggle with instruction fetch when they implement C extension! Nah, it's fine, the high-end chips can cope with that.
And round and around this discussion goes... Apparently, RISC-V has no downsides at any end of the price spectrum, what a marvelous ISA.
If you have some specific question I may be able to answer it, since I've been involved with RISC-V for over a decade, dealt with all the main companies involved, written papers, etc. but so far I see no actual question or concrete objection.
> also means a hard upper limit on the number of instructions that could ever be supported. Which is obviously a problem for a future-proof architecture.
Yup, aarch64 is doomed. /s
You can see the encoding limitation it in the design on SVE, which only has destructive operations, but MOVPRFX, which is a round about way of doing 64-bit instructions, without doing 64-bit instructions.
When the top perf per watt or perf per MHz machine is RISCV, we'll talk. Until then, lol.
Self-evidently, you therefore won't be the person building this machine.
Many here wish for the non IP-locked RISC-V to get performant micro-achitectures for embedded/server/desktop/mobile that on the latest silicon process (without that, you can have a very good micro-architecture, that won't probably make the difference).
If some RISC-V high performance CPU manufacturers are being bought by big hardware actors: either they are scared of its competition and want to scrap it or they want to be part of RISC-V.
> small cores are arbitrarily given a burden of supporting variable-length instructions
Even the smallest commercial microcontroller cores e.g. the CH32V003, support the C extension. They strip out other things, such as half the integer registers, but they keep C.
And that's in a market where you can use literally any combination of extensions you want, because the customers compile all their own code, and you just tell them what ISA string to use.
There are two options when designing an ISA to achieve competitive code size, add variable length instructions or add more complex fixed-length instructions which require cracking (2W instructions). The other option is: maybe codesize don't matter?
For high performance implementations both decoding variable length instructions and decoding/cracking fixed-length instructions into uops, are rather analogous in terms of the work hardware needs to do.
However, I think the advantage of fixed-length instructions, is that you can do further tricks, like pre-decoding in Icache. With RVC, you can also do pre-decoding, but now you need twice the amount of pre-decoding data, unless you find other tricks.
Still, in a reasonable variable-length ISA and fixed-length ISA, the variable-length one will get better code size. There are also a lot of other things to consider, RVC is self synchronizing, cracking is challenging for decode, but also keeps the backend better fed, how more instruction starts impact branch predictors, instructions crossing cache-lines...
I benchmark compiling programs with a rva23 clang build and clang compiled for rva23-without-C and got a 10% performance improvement from RVC on the SpacemiT X100. The X100 is a 4-wide out-of-order core and afaik doesn't do anything special for RVC, except for expanding the 16-bit to 32-bit instructions.
It's hard to quantify the real impact on a CPU design, but going the fixed-width route seems to enable more optimizations (not so much the decoding it self).
> maybe codesize don't matter?
Well, instruction cache still has limited size, and you still need to get your code into it. Paging in 512 KiB from the disk is faster than paging in 1 MiB from the disk.
> like pre-decoding in Icache.
I'm fairly certain x64 also does that?
> RVC is self synchronizing,
No, not really. You can still jump into the middle a 32-bit instruction, and it's possible it can be reinterpreted as a valid 32/16-bit instruction. Remember when people complained about how "overlapped instructions"/"hidden instruction streams" on x64 enable even more ROPs/gadgets than meets the eye? Don't worry, RISC-V has those too!
> No, not really. You can still jump into the middle a 32-bit instruction, and it's possible it can be reinterpreted as a valid 32/16-bit instruction. Remember when people complained about how "overlapped instructions"/"hidden instruction streams" on x64 enable even more ROPs/gadgets than meets the eye? Don't worry, RISC-V has those too!
Sure, it's a probabilistic thing. Whenever you see a 2-byte block starting with 0b11, you know there is an instruction start after those 2 bytes.
When I last looked at it, I got synchronize 99% of the time, when looking at a 8-byte block. In one qemu trace I empirically got that only 626 out of 70479 8-byte blocks don't contain synchronizations.
This certainly seems like something you could exploit quite well, if you are doing things like 8+ wide decoding. (maybe have a fast path that safes one cycle of latency)
> Requiring C (compressed) is necessary to avoid splitting the Linux ecosystem. Chips lacking C would never be able to run binaries compiled with C.
Yes that's precisely the point of excluding it from the RVA profiles. It would mean that Linux distros don't compile code with C enabled, so chips are free to not support C and therefore can achieve higher performance (probably). And it opens 3/4 of the instruction encoding space for use by other things.
> Also the excuse given by Qualcomm - that it would make all instructions fixed length and so much easier to decode - is just wrong. RISC-V supports variable length instructions, even much longer than 32 bits, and you've just got to deal with it.
It's not wrong. RISC-V defines a mechanism by which 48/64 bit instructions might be used, but currently none are actually defined. All existing instructions are 16 or 32 bits. Without C all instructions are 32 bits. You don't have to deal with 48 bit instructions because there aren't any.
It's possible that they will add some in future, but I'm doubtful of that because a) it would be a huge pain, and b) they didn't for Vector which is where it would have been most useful.
> Just because Qualcomm acquired a company with a microarchitecture that could only deal with fixed length instructions is no reason to break the ecosystem.
Yeah it was too late to change but that doesn't mean it wasn't a mistake.
Zicond looks good - I forgot that exists.
> Yes that's precisely the point of excluding it from the RVA profiles. It would mean that Linux distros don't compile code with C enabled, so chips are free to not support C and therefore can achieve higher performance (probably). And it opens 3/4 of the instruction encoding space for use by other things.
The debate was between 16/32/48/64-bit instructions vs naturally aligned 32-bit and 64-bit instructions + new more complex instructions that require cracking to regain code size (things like load/store pair).
> RISC-V defines a mechanism by which 48/64 bit instructions might be used, but currently none are actually defined
The long-instruction-SIG just started a few weeks ago, and they are working on defining 48/64-bit encodings for instructions that could be used in future RVA profiles (so with high perf implementations in mind). If you are knowledgeable about this stuff, please get involved, so they don't mess it up. (not "you" specifically, but in general)
Compressed is necessary to reduce code size which is important for performance.
A bunch of vendors have done high performance server chips which support compressed (Rivos, Ventana, some Chinese vendors), so in actual reality this was only a problem for Qualcomm. And that's only because Qualcomm bought Nuvia and they wanted to do the cheap thing (minimally change the front end) rather than the right thing.
Of course you can make compressed work. E.g. you fetch 66 bytes instead of 64. Hell, Intel/AMD manage to make x86 fairly fast.
But it's definitely more awkward and has costs throughout the CPU.
I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned. Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).
> E.g. you fetch 66 bytes instead of 64
Not really, you would fetch fewer bytes with RVC [2, page 9], because the code density is better.
> I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned.
This is very hard to quantify.
> Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).
I've liked the back and forth slides bellow. Though I want to bring up to things regrading the Qualcomm slides:
I recently benchmark compiling programs with a rva23 clang build and clang compiled for rva23-without-C and got a 10% performance improvement from RVC on the SpacemiT X100.
I also have no idea how they got those numbers. (not that they are wildly implausible, it's just not transparent)
In the last presentation they show how you can add a +-64M 32-bit long jump instruction to improve codesize in large binaries, like those in android.
I want to point out, that the JAL opcode has enough space left (7/8th) to encode a long jump of a same range and there is a proposal for a 32-bit +32M -12M 32-bit long jump: https://github.com/riscv/riscv-isa-manual/blob/zijfal/src/un...
[1] https://lists.riscv.org/g/tech-profiles/attachment/321/0/A%2...
[2] https://lists.riscv.org/g/tech-profiles/attachment/353/0/RIS...
[3] https://lists.riscv.org/g/tech-profiles/attachment/378/0/Res...
[4] https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS...
You don't really fetch 66 bytes instead of 64, what real implementations do is read cache lines (of whatever size) and hold on to 2 bytes from the previous cache line if there was 1/2 a 32-bit instruction at the end of the previous cache line (the ISA has the 16/32-bit tag in the lower byte so you know how big an instruction will be even if you've only seen half of it)
> […] and hold on to 2 bytes from the previous cache line if there was 1/2 a 32-bit instruction at the end of the previous cache line […]
Well, and that is the worst case scenario from the performance standpoint since, if a 32-bit instruction is spans a page boundary, it will result in a page fault stalling the instruction decoder.
It might be acceptable in implementations not sensitive to such an overhead (e.g. embedded solutions) but is wholly unacceptable in high performance scenarios.
x86 seems to get by.
And how is an instruction spanning a page boundary and causing a page fault any worse than an instruction NOT spanning a page boundary and the next instruction causing the page fault instead?
As Paul said, if a 4 byte instruction spans a cache line/page boundary then you just hang on to the last 2 bytes of the page (first 2 bytes of that instruction) and decode them along with the instructions in that next cache line / page.
The only time it could possibly make a difference is if that spanning instruction is a jump to somewhere else AND that instruction could somehow have fit entirely in the previous page.
If there was no C extension then that next instruction would NOT be entirely in the previous page, it would be somewhere well into the next page, and that next page would have been required to be fetched much sooner. The C extension typically allows 30% to 50% more functionality to fit in each VM page.
Also, Qualcomm's proposed new instructions did not in fact use the freed-up space from not having C. They fit into other unused parts of the ISA.
I don't object to the new instructions Qualcomm suggested. I'd be perfectly happy to see them ratified and added to a future standard (even to RVA23 if they'd chosen to pursue that, but they didn't).
What I and others objected to was dropping the C extension from RVA23, or any future RVA-series, overnight given that RVA20 and RVA22 already existed with the C extension.
There will come a time when some RISC-V extensions will be retired and replaced, and it's entirely possible that C might be one of them, but there is currently no mechanism to do that, and when there is I'd expect that it would be done with a 10 or 12 year deprecation period, minimum.
NEVER overnight between one standard and the next one.
Which wouldn't have helped Qualcomm with their Nuvia core anyway.
Anyway, Qualcomm had now bought Ventana, which has engineers who know how to support the C extension with high performance, and they already had high performance RISC-V cores doing so.
So problem solved.
x86 is an ancient design mired in legacy and problems, so Intel/AMD Intel and AMD had to make it work for a modern world even if that involved kludges, band-aids, and crutches. Whilst you do have a point there, personally I do not find x86 particularly interesting to discuss.
I did not have Qualcomm and their latest bout of theatrical shenanigans concerning C in mind, either.
Back onto C.
So purported performance benefits of C may or may not materialise – it remains to be seen and proved, and claims that a future wide RISC-V core will validate design choices such as C remain not yet falsified projections rather than demonstrated engineering results – at this stage.
[0] The second page is not resident, the decoder can't proceed because the second half-word can't be obtained, the access generates a page fault, the CPU eventually vectors to the page-fault handler. Genuine page faults are extremely expensive.
Huh?
There are RISC-V "performant" implementations on the best TSMC silicon process like x86-64 and aarch64?
There are not.
English is not my native language and I wrote a bit too fast the message: I wanted to say that "everything pushing forward RISC-V is good".
I code RISC-V assembly, I don't use C machine instructions (I don't even use the pseudo-instructions, ABI register names and dodge nearly all ISA extensions, I try to stick to core as much as I can). I run my code on x86_64 linux with a small interpreter written in x86_64 assembly (thx to the 'R' in RISC).
I wonder if there are some 'broad and not niche, real-life' speed benchmark numbers to show how much C machine instructions are worth.
For the moment, I see those C machine instructions more as a marketing extension to match their arm equivalent: you know, for those key deciding people who care more about the amount of features and not their contextual pertinent usage.
To say an ISA is "good" is related to some set of technical sweet spots based on compromises based on projected usages.
RVA from my point of view is mostly preparing RISC-V hardware for some level of x86_64/arm compatibility.
I wonder if there are RISC-V implementations using the latest silicon process from TSMC.
Aarch64 dropped thumb instructions.
I don't think you're going to find a single benchmark on the effectiveness of compressed instructions since it really depends deeply on both the workload and the whole system. For example, memory bandwidth and cache pressure are both important for whether smaller text sizes matter, and that may depend on what else is running at the same time.
Note your assembler may be automatically compressing instructions without you asking. You'll have to disassemble the binary to find out.
You can benchmark stuff with and without RVC. Once there is faster hardware I want to do such a comparison with a full gentoo build for both sides.
However, quantifying what the result will actually mean is nearly impossible, because you don't know what the hardware cost was.
Maybe the best approach is to remove C from RVA while keeping it around in the specs for niche applications where text size _really_ matters (with current silicon processes, I wonder how weird those niche applications have to be to require C). But it seems some would remove C even from the specs to free some ISA space. If arm removed thumb...
Don't worry, I would know if the assembler is producing C machine instructions, my rv64 interpreter on x86_64 does not support the C instructions at all.
You can't remove C from future RVA because a large part of the value of RVA is that each version can run all the shrink-wrapped (binary distribution) code built for the previous versions.
Well, I said that because based on the documents provided here, it seems there are key people considering its removal even from the specs.
From my point of view, just do like all the others: clearly deprecate it, namely say that "from RVAx, don't create new machine code with the C extension". It is like in the linux kernel, it will then be removed very far in the future. But RISC-V is all about the far future, it can only be better to fix it asap.
After reading the comments and documents provided here, I am the first to be suprised by how much doing 'performant C' is not that easy and has a significant hardware cost. "arm removing thumb" should have been a strong signal.
Again, I am coding rv64 assembly almost every day, a good part could be C-ized to shrink text size, but based on various numbers provided here, why bother, better keep the 'R' of RISC as faithfull to its goal than anything else.
> CLIC was awful (thankfully it has been abandoned)
Could you expand a little on what made it a bad design? I'm not much up on RISC-V.