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

VRoom A high end RISC-V implementation

moonbaseotago.github.io

Post reply on HN
Print view View original

81–90 of 135 posts

Re: VRoom A high end RISC-V implementation

#81

Post by avianes »

Taniwha wrote: post #70
avianes wrote: post #5

Earlier quoted context omitted.

Yes, there is a huge lack of open and approachable information sources in micro-architecture. Be aware though, the micro-architecture used here is very interesting but differs in many ways from state of the art industrial high-end micro-architectures for superscalar out-of-order speculative processor. I am quite curious about how the author came up with these choices

Well, everyone was building tiny RISCVs, I kind of thought "can I make a Xeon+ class RISCV if I throw gates at the problem ?" :-) Seriously though I started out with the intent of building a 4/8 instruction/clock decoder, and an O-O execution pipe that could keep up - with the end goal of at least 4+ instruction s/clock average (we peak now at 8) - the renamer, dual register file, and commitQ are the core of what's p…

Yes, the "dual register file" is probably the most intriguing to me.

This looks like a renaming scheme used in some old micro-architecture (Intel Core 2 maybe) where ROB receives transient results and acts as a physical regfile, at commit reg value are copied to a arch regfile. But in your uarch the physical regfile is decoupled from ROB, which must correspond to your commitQ.

I wonder if this solution is viable for a very large uarch (8 way) because read ports to copy reg value from pysical regfile to arch regfile are additional read ports that can be avoided with other (more complex) renaming scheme. These additional read ports can be expensive on a regfile that already has a bunch of ports.

Any thoughts about this?

But I haven't read much of your code yet, that's just a raw observation

Re: VRoom A high end RISC-V implementation

#82

Post by foobiekr »

kinghajj wrote: post #39
codedokode wrote: post #27

The presentation was interesting; but I would like to write an idea that is tangentially related to this CPU. I noticed that modern CPUs are optimized for legacy monolith OS kernels like Linux or Windows. But having a large, multimegabyte kernel is a bad idea from a security standpoint. A single mistake or intentional error in some rarely used component (like a temperature sensor driver) can get attacker full access…

You should look into the Mill CPU architecture.[0] Its design should make microkernels much more viable. * Single 64-bit address space. Caches use virtual addresses. * Because of that, the TLB is moved after the last level cache, so it's not on the critical path. * There's instead a PLB (protection lookaside buffer), which can be searched in parallel with cache lookup. (Technically, there's three: two instruction PLB…

I was also going to mention the Mill, but it's become a bit of a Flying Dutchman that people tell tales of but which probably doesn't exist.

Re: VRoom A high end RISC-V implementation

#83

Post by Taniwha »

avianes wrote: post #81
Taniwha wrote: post #70

Earlier quoted context omitted.

Well, everyone was building tiny RISCVs, I kind of thought "can I make a Xeon+ class RISCV if I throw gates at the problem ?" :-) Seriously though I started out with the intent of building a 4/8 instruction/clock decoder, and an O-O execution pipe that could keep up - with the end goal of at least 4+ instruction s/clock average (we peak now at 8) - the renamer, dual register file, and commitQ are the core of what's p…

Yes, the "dual register file" is probably the most intriguing to me. This looks like a renaming scheme used in some old micro-architecture (Intel Core 2 maybe) where ROB receives transient results and acts as a physical regfile, at commit reg value are copied to a arch regfile. But in your uarch the physical regfile is decoupled from ROB, which must correspond to your commitQ. I wonder if this solution is viable for…

the commitQ entries are smart enough to 'see' the commits into the architectural file and request the data from it's current location

It does mean lots of register read ports .... but you can duplicate register files at some point (reducing read ports but keeping the write ports) (you want to keep them close to the ALUs/multipliers/etc) - in some ways these are more implementation issues rather than 'architectural'

Re: VRoom A high end RISC-V implementation

#84

Post by avianes »

Taniwha wrote: post #83
avianes wrote: post #81

Earlier quoted context omitted.

Yes, the "dual register file" is probably the most intriguing to me. This looks like a renaming scheme used in some old micro-architecture (Intel Core 2 maybe) where ROB receives transient results and acts as a physical regfile, at commit reg value are copied to a arch regfile. But in your uarch the physical regfile is decoupled from ROB, which must correspond to your commitQ. I wonder if this solution is viable for…

the commitQ entries are smart enough to 'see' the commits into the architectural file and request the data from it's current location It does mean lots of register read ports .... but you can duplicate register files at some point (reducing read ports but keeping the write ports) (you want to keep them close to the ALUs/multipliers/etc) - in some ways these are more implementation issues rather than 'architectural'

I see, there are indeed solutions like regfile duplication to handle large port number but it's expensive when physical regfile becomes large. I still think that the uarch's job is to ensure minimal implementation cost ;).

Thank you for your opinion and thought process, it's very valuable !

Re: VRoom A high end RISC-V implementation

#85

Post by Taniwha »

dzaima wrote: post #78
titzer wrote: post #69

Earlier quoted context omitted.

Note I was talking about a conditionall call instruction, which is very useful for, e.g. safety checks.

I imagine something like that might be viable in the to-be-designed RISC-V J extension, as safety checks (mostly in JITs) would be close to the only thing benefiting from this. Though, maybe instead of a conditional call, a conditional signal could do, which'd clearly give no expectation of performance if it's hit, simplifying the hardware effort required.

Yeah, I can imagine that being particularly easy to implement in VRoom! exceptions are handled synchronously at the end of the pipe (with everything before them already committed, and everything after flushed). Instructions that can convert to exceptions (like loads and store taking TLB misses) essentially hit two different functional units - a conditional exception would be tested in a branch/ALU unit and then transition into an effective a no-op or transition into an d exception and synchronise the pipe when they hit the commit stage

Re: VRoom A high end RISC-V implementation

#86

Post by Taniwha »

Taniwha wrote: post #21
Symmetry wrote: post #3

The architectural details here were pretty interesting: https://moonbaseotago.github.io/talk/index.html It would be nice to get actual performance numbers rather than just frequency scaled Dhrystone but I suppose we have to be patient.

Dhystone's just a place to start, it helps me make quick tweaks, and I'm at that stage of the process - it's particularly good because it's somewhat at odds with my big wide decoders - VRoom! can decode bundles of up to 8 instructions per clock, while Dhrystone has lots of twisty branches, only decodes ~3.7 instructions per bundle - it's a great test for the architecture by pushing at the things it might not be as go…

I'll add that freq scaled Dhrystone (DMIPS/MHz) is a particularly useful number because it helps you compare architectures rather than just clocks - you can figure out questions like "If I can make this run at 5GHz how will it compare with X?"

Re: VRoom A high end RISC-V implementation

#87

Post by Taniwha »

Taniwha wrote: post #40
tux3 wrote: post #31

Earlier quoted context omitted.

Any thoughts about higher level HDLs in embedded in software languages, like Chisel, nMigen, or others? Some other RISC-V core designers claim they've had increased productivity with those. It seems that despite a lot of valid criticism against (System)Verilog, nothing really seems to be a on trajectory to replace it today. I'm not sure if that's purely inertia (existing tooling, workflows, methodologies), other HDLs…

I think they're great - I earned my VLSI chops building stuff in the 90s and I can write Verilog about as fast as I can think so it's my goto language. I've also written a couple of compilers over the years so I know it really well (you can thank me for the ' ' in "always @( )"). That's just my personal bias. Inertia in tooling is a REALLY BIG deal - if you can't run your design through simulation, (and FPGA simulati…

err HN swallowed my * there as in: "(you can thank me for the '*' in "always @(*)")"

Re: VRoom A high end RISC-V implementation

#88

Post by Taniwha »

avianes wrote: post #84
Taniwha wrote: post #83

Earlier quoted context omitted.

the commitQ entries are smart enough to 'see' the commits into the architectural file and request the data from it's current location It does mean lots of register read ports .... but you can duplicate register files at some point (reducing read ports but keeping the write ports) (you want to keep them close to the ALUs/multipliers/etc) - in some ways these are more implementation issues rather than 'architectural'

I see, there are indeed solutions like regfile duplication to handle large port number but it's expensive when physical regfile becomes large. I still think that the uarch's job is to ensure minimal implementation cost ;). Thank you for your opinion and thought process, it's very valuable !

I think that one has to separate out architecture and implementation a bit, they're obviously a deeply intertwingled dance - but you have to start with the architecture and tweak from there to get the best result in the end - I'm probably halfway through that process now, starting to introduce deeper timing constraints to flesh out that stuff

BTW once great thing that sort of falls out of this architecture is that the commit register file gets shared between the integer and FP registers (and probably vector registers too), and duping just that may be an interesting architectural way to go

Re: VRoom A high end RISC-V implementation

#89

Post by HanyouHottie »

codedokode wrote: post #27

The presentation was interesting; but I would like to write an idea that is tangentially related to this CPU. I noticed that modern CPUs are optimized for legacy monolith OS kernels like Linux or Windows. But having a large, multimegabyte kernel is a bad idea from a security standpoint. A single mistake or intentional error in some rarely used component (like a temperature sensor driver) can get attacker full access…

Another approach is to never context switch by running all programs in kernel mode and vetting them with an interpreter/JIT compiler: https://www.destroyallsoftware.com/talks/the-birth-and-death... (only half joking)

Re: VRoom A high end RISC-V implementation

#90

Post by phkahler »

Taniwha wrote: post #40
tux3 wrote: post #31

Earlier quoted context omitted.

Any thoughts about higher level HDLs in embedded in software languages, like Chisel, nMigen, or others? Some other RISC-V core designers claim they've had increased productivity with those. It seems that despite a lot of valid criticism against (System)Verilog, nothing really seems to be a on trajectory to replace it today. I'm not sure if that's purely inertia (existing tooling, workflows, methodologies), other HDLs…

I think they're great - I earned my VLSI chops building stuff in the 90s and I can write Verilog about as fast as I can think so it's my goto language. I've also written a couple of compilers over the years so I know it really well (you can thank me for the ' ' in "always @( )"). That's just my personal bias. Inertia in tooling is a REALLY BIG deal - if you can't run your design through simulation, (and FPGA simulati…

Possibly crazy thought. With wider CPUs needing more ports (read and write) on the register file, would it make sense to use accumulators as registers so basic boolean and math ops could be done locally with a single read port that the alu could tap?
Post reply on HN