Adding a new Verilator processor model

[oscarlparra]

Adding a new Verilator processor model

[mortbopet]

I'm a Computer Science Engineering student in Spain and I'm using RIPES for my final degree's project. My aim is to add a new processor model, which is described in System Verilog.

Awesome!

Which is the state of this implementation?

It has not changed since that work was done.

Is it fully working?

Based on the tests that i ran back then, yes, everything seemed to be working as expected.

Do you think that the page I am following is the best one to follow in this case or do you have any new documentation?

That is the best documentation available. However, it's been a while since that branch has been touched, so i'd recommend rebasing https://github.com/mortbopet/Ripes/tree/picorv32 to the master branch and submitting a PR to effectuate the rebase.

In general, i'd recommend getting https://github.com/mortbopet/Ripes/tree/picorv32 up and running and getting a feel for how verilator is called during the build process, as well as ripes_picorv32.h/.cpp; those are the files which constitute the bulk of the integration with a Verilator - and which probably should be more built out to be a generic "verilator" simulation wrapper, if you're also aiming at getting this stuff upstreamed.

[oscarlparra]

Hello again. Sorry for the delay replying.

I have been playing a bit with Ripes, consulting the sources for the master branch and for the one of PicoRV32.
I have not seen any layout for PicoRV32, so how can I visualize its functionality? Based on the inspection of the description files for the processor in verilog (in its own repository) I have detected that it is a multicycle processor, not pipelined, but still did not find any layout.
If there is not layout available, would you be able to give me a hint on how to send the signals from the verilated processor to the frontend of Ripes? I already have the backend, and have understood the interface for wrapping it into a Ripes processor, but I do not see how this is sent to the frontend.

Thank you very much in advanced for your time! :-)

[mortbopet]

See that is the difficult thing here, and i'm not sure that there actually is a way to do this neatly.

In short, to support visualization, the simulator needs to:

1. provide a mapping between the hardware units in the original design, i.e. modules and ports, such that a visualization engine can reflect this.
2. Provide a mapping between signals in the design, the hardware units and ports, and which values these correspond to in the simulation. I.e. the simulator needs to be capable of signaling to the visualization that a given port/signal has changed value.

VSRTL (the simulation and visualization framework used in Ripes) was built to support the above. That is, VSRTL contains three things:

1. Graphics visualization (https://github.com/mortbopet/VSRTL/tree/master/graphics)
2. A circuit simulator (and accompanying "HDL-like" C++ DSL which the Ripes processor models are described in) (https://github.com/mortbopet/VSRTL/tree/master/core)
3. An interface for coupling backends with the VSRTL graphics visualization library (https://github.com/mortbopet/VSRTL/blob/master/interface/vsrtl_interface.h)

The idea is then that other users should be able to bring their own backends to hook up to VSRTL, provided that they can fulfill the requirements of the VSRTL interface.

The Verilator experimentation-in-Ripes that you've been investigating completely skips VSRTL. Hence, it doesn't do anything to adhere to the VSRTL interface, and hence, there is no visualization. It does adhere to the Ripes interface, which means that you can use essentially all other Ripes features which doesn't pertain to visualization (program loading, register and memory inspection, ...).

Now, is it then possible to hook up Verilator to comply with the VSRTL interface? I think it's going to be difficult. I remember experimenting with Verilator's XML output to be able to gather this information, but without much success; maybe you want to look into that.
But in general, i think it's going to be a very uphill battle, mainly because Verilator doesn't necessarily guarantee that it's simulation (hierarchy) looks anything like what the input Verilog looked like. It simply isn't built for that - i.e. supporting visualization, where we'd expect to maintain as much of the original structure of the verilog as possible.

Another avenue which i think is much more promising is to look into whether CIRCT IR(https://github.com/llvm/circt)` can be hooked up to VSRTL (Possibly as a front-end to VSRTL core, that is, converting CIRCT IR into VSRTL core circuits, which are simulateable and visualizeable). CIRCT doesn't yet have a SystemVerilog front-end, but that would allow users to have visual simulation of e.g. Chisel circuits, which in and of itself is a massive win.