Simulation with VexRISC is so slow

[M0stafaRady]

The simulation with the riscV (VexRISC) cpu is way slower than swift2. Swift2 is faster more than 4 times. This may be because riscV (VexRISC) cpu doesn't have cache memory and it's using SPI rather than QSPI.

[RTimothyEdwards]

First off, "riscV" is an instruction set, not a CPU. If by that you mean the VexRISC, then I agree with you. I have stated from the beginning that I do not like the VexRISC, that it is not appropriate for a microcontroller, and although it is pipelined, it cannot take advantage of the pipelining because there is not enough room for a useful instruction cache in the limited space available to Caravel. The PicoRV32 (which is also RISC-V) was a much better implementation for a microcontroller. It had no instruction cache at all, but it could run at quad SPI + DDR + CRM, and it implemented compressed instructions. On average, it ran 10x faster than the VexRISC. I had to slow all the testbenches down between MPW-one (PicoRV32) and MPW-two (VexRISC) or else they would fail. Also: It is very difficult to predict the timing of any instructions on the VexRISC, due to its continually switching between cache and SPI, which also makes it a poor choice for a microcontroller that is supporting a user project. The goal of the Caravel processor is not to demonstrate a modern CPU; it's to support user projects. And when it is nearly impossible to create timed sequences of events to pass to the user project, then it has failed in that goal.

[RTimothyEdwards]

Also, I don't think this is specifically a LiteX issue, although part of the problem is the SPI flash controller (which cannot switch between single and quad SPI modes), I don't know if the picoRV32 implementation on LiteX used the wonderful, fully-featured flash controller implementation written by Claire Wolf, or the poorly-written, hobbled crippleware one used by the VexRISC. That would make a huge difference. The MPW-one version of Caravel used Claire's code unchanged except for the substitution of the OpenRAM SRAM module.

[M0stafaRady]

updated the title and issue description to VexRISC instead of litex or riscV

[RTimothyEdwards]

My original version of Caravel used GPIO pins 36 and 37 for the QSPI IO2 and IO3 pins, and depended on the ability of the controller to switch between single and quad modes. The idea was that the user could decide if the need for two additional pins was more important than running the processor at 8x speed. This feature is still implemented in the housekeeping module, but since all of my detailed documentation was removed from the repository, nobody knows about it.

[mithro]

Which SPI controller are you using?

LiteSPI supports single/dual/quad/octal modes both without DDR and with DDR.

The older spi_flash.py module also supports Dual and Quad mode.

[mithro]

The team at Antmicro also did a bunch of analysis of the VexRISCV execution from SPI Flash as part of the CFU Playground and ChromeOS HPS Sensor project. You can ask them about what they found.

[RTimothyEdwards]

To my knowledge, the SPI controllers in LiteX cannot switch instantly between the different modes by writing to a configuration register, so they cannot be used in a "safe" configuration that powers up in single mode and switches to fast mode on demand.

[RTimothyEdwards]

@mithro : What you get from analyzing the VexRISC depends on what parameters you use. I'm not saying it's a piece of junk; I'm saying that it's not designed to be used in a low-memory-overhead, minimalist microcontroller context.

[mithro]

@RTimothyEdwards - I believe you are correct about the switching aspect as LiteX has historically been mainly used on FPGAs and that extra configuration / switching costs precious resources. It shouldn't be a difficult thing to add.

[RTimothyEdwards]

@mithro : The FPGA is also spec'd to run at some rate and you can always reprogram it, so there's no harm in designing your system to come up and run in quad DDR mode. But if you want to design silicon that works, especially silicon that might be put on custom designed boards with different loading characteristics, then you had better be able to start up in a state that has the highest chance of success, but configurable enough to accommodate whatever the various user projects might demand.