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

61–70 of 135 posts

Re: VRoom A high end RISC-V implementation

#61

Post by thechao »

Taniwha wrote: post #56
thechao wrote: post #54

Earlier quoted context omitted.

Synthesizable verilog is a very small language compared to system verilog — especially in the 90s. Off the top of my head I know of six "just real quick" verilog simulators that I've worked with (one of which I wrote). I'm not sure how I feel about them. On one hand, I hate dealing with licenses; on the other hand, now you've got to worry that your custom simulation matches behavior with the synthesis tools. A lot of…

It was more than simple synthesisable verilog, but not a lot - it was also a compiler rather than an interpreter - at the time VCS was just starting to be a thing, verilog as a language was not at all well defined (lots of assumptions about event ordering that no-one should have been making) I was designing Mac graphics accelerators I'd built it on a some similar infrastructure I'd built to capture trace from people'…

This is why I think Moore (LLHD), Verilator, and Yosys are such awesome tools. They move a lot more slowly than (say) GCC, but I personally think they're all close to the tipping point.

Re: VRoom A high end RISC-V implementation

#62

Post by Taniwha »

titzer wrote: post #49
Taniwha wrote: post #16

Author here (Paul Campbell) - AMA

As a language VM implementor, I would really love to have a conditional call instruction, like arm32. AFAICT this would be a relatively simple instruction to implement in the CPU. Is that accurate?

yes and no - there's a few issues here:

1 - architectural - RISCV has a nice clean ISA, it's adding instructions quickly, CMOV is contentious issue there - I'm not an expert on the history so I'll let others relitigate it - it's easy to add new instructions to a RISCV machine, unlike Intel/ARM it's even encouraged - however adding a new instruction to ALL machines is more difficult and may take many years. But unlike Intel/ARM there IS a process to adopt new instructions that doesn't involve just springing them on your customers

2 - remember RISCV is a no-condition code architecture - that would make CMOV require 3 register file ports (the only such instruction that also requires an adder [for the compare]) - register file ports are extremely expensive, especially for just 1 instruction

3 - micro-architectural - on simple pipes CMOV is pretty simple (you just inhibit register write, plus do something special with register bypass) I'd have to think very hard about how to do it on something like VRoom! with out of order, speculative, register renaming - I can see a naive way to do it, but ideally there should be a way to nullify such an instruction early in the pipe which would mean some sort of renaming-on-the-fly hack

Re: VRoom A high end RISC-V implementation

#63

Post by Taniwha »

thechao wrote: post #61
Taniwha wrote: post #56

Earlier quoted context omitted.

It was more than simple synthesisable verilog, but not a lot - it was also a compiler rather than an interpreter - at the time VCS was just starting to be a thing, verilog as a language was not at all well defined (lots of assumptions about event ordering that no-one should have been making) I was designing Mac graphics accelerators I'd built it on a some similar infrastructure I'd built to capture trace from people'…

This is why I think Moore (LLHD), Verilator, and Yosys are such awesome tools. They move a lot more slowly than (say) GCC, but I personally think they're all close to the tipping point.

I wrote a second, much more standard Verilog compiler (because by then there was a standard) with the intent of essentially selling cloud simulation time (being 3rd to a marketplace means you have to innovate) - sadly I was a bit ahead of my time ('cloud' was not yet a word) the whole California/Enron "smartest guys in the room" debacle kind of made a self financed startup like that non-viable

So in the end I open sourced the compiler ('vcomp') but it didn't take off

Re: VRoom A high end RISC-V implementation

#64

Post by codedokode »

kragen wrote: post #48
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…

SASOSes are interesting, sometimes extending a 64-bit address space to cover a whole cluster, but they aren't compatible with anything that calls fork(). The various variants of L4 have pretty good context-switch latency even on traditional CPUs, and seL4 in particular is formally proven correct on a few platforms. Spectre+Meltdown mitigation was painful for them, but they're still pretty good. Lots of microcontrolle…

What I would like to have is a context switch latency comparable to a function call. For example, if in a microkernel system bus driver, network card driver, firewall, TCP stack, socket service are all separate userspace processes, then every time a packet arrives there would be a context-switching festival.

As I understand, in microkernel OSes most system calls are simply IPCs - for example, network card driver passes incoming packet to the firewall. So there is almost no kernel work except for context switch. That's why it has to be as fast as possible and resemble a normal function call, maybe even without invoking the kernel at all. Maybe something like Intel's call gate, but fast.

> they aren't compatible with anything that calls fork().

I wouldn't miss it; for example, Windows works fine without it.

Re: VRoom A high end RISC-V implementation

#65

Post by ncmncm »

blacklion wrote: post #37
Taniwha wrote: post #22

Earlier quoted context omitted.

I think that we need lots of trace before we decide which ops make sense to combine

As far as I understand, RISC-V proponents want to have "recommended" command sequences for compilers, to avoid situation when different RISC-V CPUs will need different compilations. If different RISC-V implementations have different "fuseable" command sequences, we will be in dreadful situation when you will need exact "-mcpu" for decent performance and binary packages will be very unoptimal. And such "conventions" a…

It is always frustrating when you have put in the work to optimize code, and turn out to have pessimized it for the next chip over.

The extremum for this is getting a 10x performance boost by using, e.g., POPCNT, and suffering instead a 10-100x pessimization because POPCNT is trapped and emulated.

Re: VRoom A high end RISC-V implementation

#67

Post by Taniwha »

gary_0 wrote: post #46
Taniwha wrote: post #16

Author here (Paul Campbell) - AMA

From what little I know about microarchitecture, this seems extremely impressive. Hopefully these aren't dumb questions: Are there GPL'd designs for PCIe, USB, etc, that could be used to incorporate this into a SoC design? If not, how much work is that compared to this? Also, what other kind of technical considerations would be involved to make this into a "real" chip on something like 28nm?

Great questions - I'm using an open source UART from someone else, an d for the AWS FPGA system I have a 'fake' disk driver plus timers/interrupt controllers etc

So far I haven't needed USB/ether/PCIe/etc I've sort of sketched out a place for those to live - I think that for a high end system like this one you can't just plug something in - real performance needs some consideration of how:

- cache coherency works - VM and virtual memory works (essentially page tables for IO devices) - PMAP protections from I/O space (so that devices can't bypass the CPU PMAPs that are used to man age secure enclaves in machine mode)

So in general I'm after something uniquer, or at least slightly bespoke.

I also think there's a bit of a grand convergence going on in this area around serdes's which are sort of becoming a new generic interface PCIe, high speed ether, new USBs, disk drivers etc are all essentially bunches of serdes with different protocol engines behind them - a smart SoC is going to split things this way for maximum flexibility

Re: VRoom A high end RISC-V implementation

#68

Post by Taniwha »

ncmncm wrote: post #66
Taniwha wrote: post #16

Author here (Paul Campbell) - AMA

Are you making any attempt at a learning branch predictor? Is anything published about really-current methods?

Not yet - I have a pretty generic combined bimodal/global predictor - there's a lot of research on BTCs - it's easy to throw gates at this area - I can imagine chips hitting 20-30% BTC in area just to keep the rest running

My next set of work in this area will be integrating an L0 trace cache into the existing BTC - that will help me greatly up the per-clock issue rate

Re: VRoom A high end RISC-V implementation

#69

Post by titzer »

Taniwha wrote: post #62
titzer wrote: post #49

Earlier quoted context omitted.

As a language VM implementor, I would really love to have a conditional call instruction, like arm32. AFAICT this would be a relatively simple instruction to implement in the CPU. Is that accurate?

yes and no - there's a few issues here: 1 - architectural - RISCV has a nice clean ISA, it's adding instructions quickly, CMOV is contentious issue there - I'm not an expert on the history so I'll let others relitigate it - it's easy to add new instructions to a RISCV machine, unlike Intel/ARM it's even encouraged - however adding a new instruction to ALL machines is more difficult and may take many years. But unlike…

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

Re: VRoom A high end RISC-V implementation

#70

Post by Taniwha »

avianes wrote: post #5
nynx wrote: post #2

The Architectural presentation linked from the GitHub repository for this project is an incredibly good resource on how these kinds of things are designed.

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 probably different here

Post reply on HN