Add VexRISCV configuration suitable for iCE40 sized devices

[mithro]

The current VexRISCV configuration works well on big FPGAs like the Artix-7 and Spartan 6 but is too big for the tiny iCE40 based devices.

It would be good to add a variant which works well on the iCE40, two options seem to exist;

VexRiscv small and productive (RV32I, 0.82 DMIPS/Mhz)  ->
  Artix 7    -> 327 Mhz 698 LUT 558 FF
  Cyclone V  -> 158 Mhz 524 ALMs
  Cyclone IV -> 146 Mhz 1,061 LUT 552 FF
  iCE40      -> 55 Mhz 1541 LC

VexRiscv small and productive with I$ (RV32I, 0.72 DMIPS/Mhz, 4KB-I$)  ->
  Artix 7    -> 331 Mhz 727 LUT 600 FF
  Cyclone V  -> 152 Mhz 536 ALMs
  Cyclone IV -> 156 Mhz 1,075 LUT 565 FF
  iCE40      -> 54 Mhz 1686 LC

It probably good to steal the VexRISCV configuration from the MuraxSoC configuration;

Depending the CPU configuration, on the ICE40-hx8k FPGA with icestorm for synthesis, the full SoC has the following area/performance :

RV32I interlocked stages => 51 Mhz, 2387 LC 0.45 DMIPS/Mhz RV32I bypassed stages => 45 Mhz, 2718 LC 0.65 DMIPS/Mhz Its implementation can be found here: src/main/scala/vexriscv/demo/Murax.scala.

[Dolu1990]

The only issue is that it will require to port uncached iBus dBus to wishbone. currently only the cached versions have their bridge. Nothing difficult, but it require testing. You need them with wishbone right ?

[mithro]

Yes, LiteX uses wishbone internally if I understand correctly. A small 1k or 4k instruction cache might still make sense, even on an ice40?

[mithro]

Btw would you like me to send you some iCE40 hardware like the TinyFPGA BX?

[Dolu1990]

hmm, having a 4KB 2-way instruction cache could be realy usefull if the ROM is on a external SPI chip, then keeping the remaining of the ram-blocks as a data scratchpad. I was already thinking about it as a cool Murax SoC extention to extends the ROM without to much performance downside :)

About the TinyFPGA BX, i'm realy interrested by the board, also, the bootloader system is realy cool, i didn't know that it was possible to have a USB support directly on the pin of the FPGA :D But currently i'm realy busy, i probably have for 1-2 months to flush my todo queue XD

Anyway thanks :)

[cr1901]

hmm, having a 4KB 2-way instruction cache could be realy usefull if the ROM is on a external SPI chip, then keeping the remaining of the ram-blocks as a data scratchpad.

Running all code on the SPI chip is the intent; I think a 2kB cache one-way is more reasonable, plus 2kB of block RAM for peripherals/other gateware. I really want 12kB (out of 16kB) free for block RAM usage so micropython can run on it.

The only issue is that it will require to port uncached iBus dBus to wishbone. currently only the cached versions have their bridge. Nothing difficult, but it require testing.

Ack. I wish I saw this earlier :P.

[Dolu1990]

I can add the wishbone dBus bridge, i just need to unqueue all my tasks XD

[xobs]

I'm also interested in uncached ibus/dbus. What would it take to port those to Wishbone?

[Dolu1990]

@xobs I would not take much, also, the testbench is already there.

[Dolu1990]

About wishbone, is there some support of its pipelined version in the opensource space ? Or it's something that most peripheral/memories don't support ? (for instance in migen/LiteX) ?

[xobs]

The implementations I'm familiar with are very limited. LiteX doesn't do anything with the ERR line, for example. And there is no STALL signal in the LiteX implementation.

Most Wishbone uses I've seen implement DAT, CLK, STB, CYC, and ACK. Some implement ERR, and some do something sane with SEL. But no, pipelining is not a thing I've seen used often.

[Dolu1990]

I updated VexRiscv to have wishbone bridges for uncached versions (0255f51cc53be867a513a0ef3b088a6fced5d97e) It pass regressions. Juste one thing, it is likely that wishbone will slow down the CPU (IPC=0.5), especialy if you have not instruction cache, unless your memory is asyncronus/use falling edge to "be" asyncronus :) You can also enable RVC, which will improve this, as the instruction bandwidth is 25 % smaller.

I will add some configuration in this repo soon

[Dolu1990]

It's commited on this repo, there is an example to get a tiny core :

sbt "run-main vexriscv.GenCoreDefault --iCacheSize=0 --dCacheSize=0 --mulDiv=false --bypass=false --prediction=none"

Note that the CSR in this configuration aren't the smallest possible.

[cr1901]

@mithro With PR #3 being merged, this is effectively done. Of course, still need to test them all :). Also note that the Min core does not have a multiplier/divider so the compiler must target rv32i instead of rv32im.

[xobs]

The module has an invalid name -- it's called "VexRiscv-Min", which at least yosys is complaining about. Should the name s/-/_/?

[Dolu1990]

@xobs fixed it in 023f1603aa22be0b772651b782819a0591bdd58d

[cr1901]

@Dolu1990 ~We still need the actual module name inside the output Verilog file to be Vexriscv, even if the output filename changes for each configuration. Could you add a moduleName option to VexRiscv-Verilog, that names the output module to module VexRiscv(...) in all configurations (and update the Makefile)?~

EDIT: Ignore the above for now- I missed something important.

[Dolu1990]

@cr1901 Hooo do d7bbc2c should be reverted ? In this commit all generated file have as module name VexRiscv

[cr1901]

@Dolu1990 Since you already committed, let's keep d7bbc2c and not revert it. Looking at MiSoC/LiteX, all other CPU cores in MiSoC/LiteX expect the name of the module to stay consistent, regardless of what features are enabled/disabled! :)

When I said "ignore" my last comment, it was because I figured out a workaround. But since you did the work already, it makes life easier :).

[olofk]

Just stumbled across this. From my point of view as packaging this repo for FuseSoC I would prefer different module names and perhaps just add a wrapper in migen litex that exposes a consistent name upwards