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

91–100 of 135 posts

Re: VRoom A high end RISC-V implementation

#91

Post by Symmetry »

phkahler wrote: post #90
Taniwha wrote: post #40

Earlier quoted context omitted.

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?

Modern CPUs have a structure called the bypass network that lets different ALUs forward their outputs to another's inputs without having to hit the register file. It's not exactly like a local accumulator but it's something in the same direction.

Re: VRoom A high end RISC-V implementation

#92

Post by tsmi »

phkahler wrote: post #90
Taniwha wrote: post #40

Earlier quoted context omitted.

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?

Modern OoO CPUs solve the need for more physical registers than logic registers with renaming. https://docs.boom-core.org/en/latest/sections/rename-stage.h...

Re: VRoom A high end RISC-V implementation

#93

Post by mastax »

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…

Since this was a bit hard to google:

ASID = Address Space Identifier. It's a tag that uniquely identifies each processes' entries in the TLB. This ensures that your TLB lookups can be limited to the valid entries for the process, so you don't need to flush the TLB on context switch.

Re: VRoom A high end RISC-V implementation

#94

Post by webmaven »

Taniwha wrote: post #71
Taniwha wrote: post #33

Earlier quoted context omitted.

Well (author here) - this is a private project - typically such a project would be very propriety - people don't get to show their work. But I'm looking to find someone to build this thing, it's been a while since I last built chips (last CPU I helped design never saw the light of day due to reason that had little to do with how well it worked). So I need a way to show it off, show it's real. So GPLing it is a great…

One other comment about why GPLing something is important for some like me - publishing my 'secrets' are a great way to turn them into "prior art" - you read it here first, you can't patent it now - I can protect my ideas from becoming part of someone else's protected IP by publishing it. I spent a few years working on an x86 clone, I had maybe 10 (now expired) patents on how to get around stupidly obvious things tha…

> One other comment about why GPLing something is important for some like me - publishing my 'secrets' are a great way to turn them into "prior art" - you read it here first, you can't patent it now - I can protect my ideas from becoming part of someone else's protected IP by publishing it.

This is a great strategy!

> I spent a few years working on an x86 clone, I had maybe 10 (now expired) patents on how to get around stupidly obvious things that Intel had patented - (or around ways to get around ways to get around In tel that other's had patented) - frankly from a technical POV it was all a lot of BS, including my patents

It might be worthwhile to GPL implementations of those expired patents if they are at all likely to be useful. And perhaps then do a bit of procedural generation of various combinations of them for release under the GPL as well (because those would be newly patentable).

Prior art FTW!

Re: VRoom A high end RISC-V implementation

#97

Post by snvzz »

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.

Before we learned how to make them fast, perhaps. They do now tend to be very fast[0][1].

>One of the reasons for this could be high context switch latency.

As multiserver systems pass a lot of messages around, the important metric is IPC cost. Liedtke demonstrated microkernels do not have to be slow, with L3 and later L4. Liedtke's findings have endured fairly well[2] through time. It helps to know that seL4[3] has an order of magnitude faster IPC relative to Linux.

You'd need it to do a lot (think thousands of times) more IPC for the aggregated IPC to be slower than Linux.

>So I was thinking what could be done here.

I don't have a link at hand, but there's some involvement and synergy between seL4 team and RISC-V. I am hopeful it is enough to prevent the bad scenario where RISC-V is overoptimized for the now obsolete UNIX design, and a bad fit to contemporary OS architectures.

0. https://blog.darknedgy.net/technology/2016/01/01/0/

1. https://news.ycombinator.com/item?id=10824382

2. https://sigops.org/s/conferences/sosp/2013/papers/p133-elphi...

3. https://sel4.systems/About/seL4-whitepaper.pdf

Re: VRoom A high end RISC-V implementation

#98

Post by Taniwha »

tsmi wrote: post #92
phkahler wrote: post #90

Earlier quoted context omitted.

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?

Modern OoO CPUs solve the need for more physical registers than logic registers with renaming. https://docs.boom-core.org/en/latest/sections/rename-stage.h...

Yes VRoom! with renaming has as many registers as it has commitQ entries plus the architectural ones. So 64/32 + 31 (integer) + 32 (fp) + 32 (vector)

Re: VRoom A high end RISC-V implementation

#99

Post by Taniwha »

panick21_ wrote: post #95
Taniwha wrote: post #16

Author here (Paul Campbell) - AMA

Is this a hobby? Is there a way to support the project? What your view on that kind of design for a laptop/phone/tablet processor?

It's a personal project, but an expensive one (with very large AWS bills some months), needs a commercial sponsor to end up as a real chip you could put in real platforms and a real chip design team to build it

Re: VRoom A high end RISC-V implementation

#100

Post by feffe »

mastax wrote: post #93
Taniwha wrote: post #35

Earlier quoted context omitted.

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…

Since this was a bit hard to google: ASID = Address Space Identifier. It's a tag that uniquely identifies each processes' entries in the TLB. This ensures that your TLB lookups can be limited to the valid entries for the process, so you don't need to flush the TLB on context switch.

RISC-V really is the heir of MIPS as it had those TLB tags as well.
Post reply on HN