Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Book: RISC-V System-on-Chip Design

amazon.com

Post reply on HN
Print view View original

41–50 of 80 posts

Re: Book: RISC-V System-on-Chip Design

#41

Post by rwmj »

sylware wrote: post #38
timhh wrote: post #9

Earlier quoted context omitted.

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…

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 assembl…

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.

Re: Book: RISC-V System-on-Chip Design

#42

Post by camel-cdr »

rwmj wrote: post #41
sylware wrote: post #38

Earlier quoted context omitted.

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 assembl…

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 automaticall…

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.

Re: Book: RISC-V System-on-Chip Design

#43

Post by sylware »

rwmj wrote: post #41
sylware wrote: post #38

Earlier quoted context omitted.

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 assembl…

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 automaticall…

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.

Re: Book: RISC-V System-on-Chip Design

#44

Post by Taniwha »

timhh wrote: post #36
rwmj wrote: post #28

Earlier quoted context omitted.

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…

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)

Re: Book: RISC-V System-on-Chip Design

#45

Post by dmitrygr »

rwmj wrote: post #25
Joker_vD wrote: post #24

Earlier quoted context omitted.

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 supportin…

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...

[flagged]

Re: Book: RISC-V System-on-Chip Design

#46

Post by flopsamjetsam »

genxy wrote: post #18

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 o…

I re-took Computer Architecture recently, and we used their earlier book "Digital Design and Computer Architecture: ARM edition", and it was also excellent.

Re: Book: RISC-V System-on-Chip Design

#47

Post by flopsamjetsam »

timhh wrote: post #9
sylware wrote: post #7

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…

> 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.

Re: Book: RISC-V System-on-Chip Design

#48

Post by camel-cdr »

dmitrygr wrote: post #45
rwmj wrote: post #25

Earlier quoted context omitted.

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...

[flagged]

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.

Re: Book: RISC-V System-on-Chip Design

#49

Post by oumua_don17 »

rramadass wrote: post #21

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/…

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

Re: Book: RISC-V System-on-Chip Design

#50

Post by dmitrygr »

camel-cdr wrote: post #48
dmitrygr wrote: post #45

Earlier quoted context omitted.

[flagged]

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.
Post reply on HN