VRoom A high end RISC-V implementation

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 not being attractive enough, or maybe Verilog is just good enough?

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 way to do that - as is showing up on HN (thanks to whoever posted this :-).

In practice the RTL level design of a processor is only a part of making a real processor - a real VRoom! would likely have hand built ALUs, shifters, caches, register files etc those things are all in the RTL at a high level but are really different IP - likely they'd be entangled with GPL and a manufacturer might feel that to be an issue.

However I'm happy to dual license (I want to get it built, and maybe get paid to do it).

Also about half the companies building RISCVs are in China (I've been building open source hardware in China for a decade or so now, so I know there's lots of smart people there) - they have a real problem (in the West) building something like this - all the rumors about supply chain/etc stuff - having an open sourced GPL'd reference that's cycle accurate is a way help build confidence.

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 (L0 icache) will also be virtually tagged. VRoom! also doesn't do speculative accesses past the TLBs.

Honestly saving and restoring kernel context is small compared to the time spent in the kernel (and I've spent much of the past year looking at how this works in depth).

Practically you have to design stuff to an architecture (like RISCV) so that one can leverage off of the work of others (compilers, libraries, kernels) adding specialised stuff that would (in this case) get in to a critical timing path is something that one has to consider very carefully - b ut that's a lot of what RISCV is about - you can go and knock up that chip yourself on an FPGA and start trialing it on your microkernel

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" are bad idea, like comments in code, IMHO. It can not be checked by tools, etc.

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 PLBs and one data PLB.)

[0]: https://millcomputing.com/