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

41–50 of 135 posts

Re: VRoom A high end RISC-V implementation

#41

Post by sitkack »

minroot wrote: post #28
tsmi wrote: post #23

Earlier quoted context omitted.

If you're at the point in your career where you're not sure which is the right textbook then "A Quantitative Approach" is likely to be really tough to get through. Computer Organization and Design, by the same authors, is considered a better choice for a first book. I personally loved it and couldn't put it down the first time I read it. https://www.elsevier.com/books/computer-organization-and-des...

Any recommendation for books on (System)Verilog

You might like "Digital Design and Computer Architecture, RISC-V Edition" by Harris and Harris.

https://www.google.com/books/edition/Digital_Design_and_Comp...

This book definitely skews pragmatic, hands on and doesn't assume much. Covers both VHDL and Verilog. Has sections on branch prediction, register renaming, etc.

Re: VRoom A high end RISC-V implementation

#42

Post by Taniwha »

tsmi wrote: post #25
Taniwha wrote: post #16

Author here (Paul Campbell) - AMA

Have you considered making an ASIC of your design? https://efabless.com/open_shuttle_program

It's likely too big for those programs - I am (just now) starting a build with the Open Lane/Sky tools not with the intent of actually taping out but more to squeeze the architectural timing (above the slow FPGA I've been using for bringing up Linux) so I can find the places where I'm being stupidly unreasonable about timing (working on my own I can't afford a Synopsys license)

Re: VRoom A high end RISC-V implementation

#43

Post by db65edfc7996 »

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…

>But microkernels tend to have poor performance.

Citation needed. What kind of hit are we talking about? 5%? 90%? We have supercomputers from the future that have capacity to spare. I would be willing to take an enormous performance hit for better security guarantees on essential infrastructure (routers, firewalls, file servers, electrical grid, etc).

Re: VRoom A high end RISC-V implementation

#44

Post by camtarn »

tsmi wrote: post #23
Symmetry wrote: post #10

Earlier quoted context omitted.

Computer Architecture: A Quantitative Approach[1] is the textbook that gets recommended the most on the topic, I believe.

If you're at the point in your career where you're not sure which is the right textbook then "A Quantitative Approach" is likely to be really tough to get through. Computer Organization and Design, by the same authors, is considered a better choice for a first book. I personally loved it and couldn't put it down the first time I read it. https://www.elsevier.com/books/computer-organization-and-des...

Definitely recommend this textbook as a great read - it remains one of the very few textbooks I've read end-to-end and genuinely enjoyed.

Re: VRoom A high end RISC-V implementation

#45

Post by Taniwha »

sitkack wrote: post #34
Taniwha wrote: post #16

Author here (Paul Campbell) - AMA

What does your benchmarking workflow look like? I am interested in * From a high level what does your dev iteration look like? * Getting instruction traces, timing and resimulating those traces * Power analysis, timing analysis (do you do this as part of performance simulation) ? * Do you benchmark the whole chip or specific sub units? * How do you choose what to focus on in terms of performance enhancements? * What…

At the moment I'm just starting working my way up the hierarchy of benchmarks, dhrystone's been useful though it's nearing the end of its use - I build the big FPGA version (on an AWS FPGA instance) to give me a place to run bigger things exactly like this.

I currently run low level simulations in Verilator where I can easily take large internal architectural trace, and bigger stuff on AWS (where that sort of trace is much much harder)

I haven't got to the power analysis stage - that will need to wait until we decide to build a real chip - timing will depend on final tools if we get to build something real, currently it's building on Vivado for the FPGA target.

Mostly I'm doing whole chip tests - getting everything to work well together is sort of the area I'm focusing on at the moment (correctness was the previous goal - being together enough to boot linux), the past 3 months I've brought the performance up b y a factor of 4 - the trace cache might get me 2x more if I'm lucky.

I spend a lot of time looking at low level performance, at some level I want to get the IPC (instructions per clock) of the main pipe as high as I can so I stare at the spots where that doesn't happen

I'm using open source tools (thanks everyone!)

Re: VRoom A high end RISC-V implementation

#46

Post by gary_0 »

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?

Re: VRoom A high end RISC-V implementation

#47

Post by tsmi »

Taniwha wrote: post #42
tsmi wrote: post #25

Earlier quoted context omitted.

Have you considered making an ASIC of your design? https://efabless.com/open_shuttle_program

It's likely too big for those programs - I am (just now) starting a build with the Open Lane/Sky tools not with the intent of actually taping out but more to squeeze the architectural timing (above the slow FPGA I've been using for bringing up Linux) so I can find the places where I'm being stupidly unreasonable about timing (working on my own I can't afford a Synopsys license)

Gotcha. Did you run into any issues with yosys given that it has limited system verilog support?

Ibex needed to add a pass with sv2v https://github.com/lowRISC/ibex/tree/master/syn

Re: VRoom A high end RISC-V implementation

#48

Post by kragen »

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 microcontrollers have no MMUs but do have MPUs to keep a user task from cabbaging the memory of the kernel or other tasks. Not sure if any of them use the PDP-11-style base+offset segment scheme you're describing to define the memory regions.

Protected-memory multitasking on a multicore system doesn't need to involve context switches, especially with per-core memory.

Even on Linux, context switches are cheap when your memory map is small. httpdito normally has five pages mapped and takes about 100 microseconds (on a 2.8GHz amd64 laptop) to fork, serve a request, and exit. I think I've measured context switches a lot faster than that between two existing processes.

Multiple register banks for context switching go back to the CDC 6600's peripheral processor (FEP) or maybe the TX-0 on which Sutherland wrote SKETCHPAD; it has a lot of advantages beyond potentially cheaper IPC. Register bank switching for interrupt handling was one of the major features the Z80 had over the 8080 (you cn think of the interrupt handler as being the kernel). The Tera MTA in the 01990s was at least widely talked about if not widely imitated. Switching register sets is how "SMT" works and also sort of how GPUs work. And today Padauk's "FPPA" microcontrollers (starting around 12 cents IIRC) use register bank switching to get much lower I/O latency than competing microcontrollers that must take an interrupt and halt background processing until I/O is complete.

Another alternative approach to memory protection is to do it in software, like Java, Oberon, and Smalltalk do, and Liedtke's EUMEL did; then an IPC can be just an ordinary function call. Side-channel leaks like Spectre seem harder to plug in that scenario. GC may make fault isolation difficult in such an environment, particularly with regard to performance bugs that make real-time tasks miss deadlines, and possibly Rust-style memory ownership could help there.

Re: VRoom A high end RISC-V implementation

#50

Post by kragen »

Taniwha wrote: post #35
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…

These days there are few caches that need to be flushed at context switch time - RISCV's ASIDs mean that you don't need to flush the TLBs (mostly) when you contect switch. VRoom! largely has physically tagged caches so they don't need to be flushed, the BTC is virtually tagged, but split into kernel and user caches, you need to flush the user one on on a context switch (or both on a VM switch) - also the trace cache…

Thanks, this is really informative.
Post reply on HN