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.
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.
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...)
> 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.
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.
> 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)
> 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).
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.
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.
A couple of sample chapters are available here https://pages.hmc.edu/harris/ddca/rvsocd.html
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.
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.
You know what. I feel like it’s a fair price.
Ooof. €109.70 in paperback
You can get it direct from Elsevier for ~78 euros: https://shop.elsevier.com/books/risc-v-system-on-chip-design...
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.
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.
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.
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...)
> 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.
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.
> 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)
> 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).