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

61–70 of 80 posts

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

#61

Post by imtringued »

henrymerrilees wrote: post #30
chris_money202 wrote: post #8

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…

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?

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

#62

Post by sylware »

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

Earlier quoted context omitted.

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.

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.

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

#63

Post by inkyoto »

brucehoult wrote: post #56
inkyoto wrote: post #52

Earlier quoted context omitted.

> […] 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. embe…

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…

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.

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

#64

Post by whateverboat »

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…

Why do you say (no relation) when the authors are exactly the same?

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

#65

Post by sylware »

inkyoto wrote: post #63
brucehoult wrote: post #56

Earlier quoted context omitted.

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…

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

Huh?

There are RISC-V "performant" implementations on the best TSMC silicon process like x86-64 and aarch64?

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

#66

Post by gertrunde »

whateverboat wrote: post #64
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…

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

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

#67

Post by camel-cdr »

Joker_vD wrote: post #51
camel-cdr wrote: post #37

Earlier quoted context omitted.

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…

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

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

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

#68

Post by Jtsummers »

whateverboat wrote: post #64
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…

Why do you say (no relation) when the authors are 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.

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

#70

Post by inkyoto »

sylware wrote: post #65
inkyoto wrote: post #63

Earlier quoted context omitted.

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

Huh? There are RISC-V "performant" implementations on the best TSMC silicon process like x86-64 and aarch64?

There are not.
Post reply on HN