Close

RISC-V (rv32i) on the netpp node

A project log for netpp node

Networked remote control on FPGA SoC

MartinMartin 10/04/2019 at 07:370 Comments

Time for a change: The Berkeley RISC-V architecture has gone from a hype to a pretty mature architecture which performs very well on an FPGA as well as on hard silicon, as SiFive and others have demonstrated.

So, what's the reason to try anything else besides the running system? The ZPUng has been extensively verified for stability, but being a stack machine, its GCC port was never fully optimized for it, and actually, it's hard to. So, it would have been time to actually tackle a compiler update. Not much is being done on that front, and after all it turns out: Code density from RISC-V (compressed) gets very close to the compact ZPU instruction set, in some cases it performs even better.

So I've tried a few open RISC-V designs, but run into quirks:

As I've had an optimized RISC design (called PyPS, as written in Python) in the drawer, but not explored any further due to lacking compiler optimization, I gave it a go to make it RISC-V compatible. Naive thinking: Just swap out the decoder module. Ok, it got pretty close, but after all, I went for a complete rewrite anyhow. It's kinda sad, but with a well implemented compiler as working reference, it's easier to bash out a new hardware design than adapting the GCC RTL.

So after all it turns out: This design, including all netpp server code, actually fits on the netpp node (without requiring the SPI overlay program ROM cache). With some memory reorganisation there's just that small gain of free block RAM sufficient to free more space for a program so that the current architecture can be maintained.


Now the hard part comes in:  the full verification scenario has not been tackled yet. On the ZPUng with its eight byte opcodes and therefore limited combination scenarios, verification can be done in a few hours on a standard PC. The full dance for the 'pyrv32' is way more complex and it's likely that some scenario might slip.

The tests passed so far (Update):

The full coverage dance is likely a number to big for me to tackle, it will be left at "works for me" for now.

There are some alternative regress tests still to be looked at, I'm gladly accepting hints.

So, looks like a release can be rolled out in the next weeks - as a virtual chip.

Discussions