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.
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...)
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.
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.
You know what. I feel like it’s a fair price.
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...)
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...
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.
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.