Rocket Chip on Non-Zynq FPGAs

Question

I want to port the rocket chip to a non-Zynq FPGA (an altera Stratix V), a board which doesn't contain an ARM core used to run the riscv-fesvr. How can I go about starting the port? Also, has anyone attempted to run the rocket chip on such a board? Can I pointed to some resources for that?

Ka

Answer 1

This is mainly an issue of interfacing, as Rocket Chip does not use anything Zynq specific internally. If this interfacing is done properly, you should not need to change pk/linux or Rocket Chip itself. You will need to both wrap Rocket Chip for the target FPGA and interface to it with a Frontend Server (fesvr).

For wrapping Rocket Chip, I would look at the top level IO it expects (RocketChip.scala), which most importantly includes HostIO (for HTIF) and MemIO (for DRAM). For additional information on those interfaces, I would consult the slides from the first workshop. Our current wrapper (rocketchip_wrapper.v) multiplexes those interfaces over AXI to the host ARM core that is running fesvr.

Your proposal sent to the mailing list of running fesvr on a NIOS II core and communicating to it via AXI could work. This will require modifying (fesvr-zedboard.cc) to match the AXI interface NIOS provides to software. This approach may require the least new development, but the soft-core will consume FPGA resources and may be slower.

Another way to accomplish this would be to run the front-end server on a PC attached to the board via ethernet. You would need to make a bridge between Rocket Chip's MemIO and the on-board DRAM. You will also need to run HTIF over ethernet, which will require another bridge between HostIO and the board's ethernet MAC. Years ago fesvr supported this (fesvr-eth.cc), but that code has not been maintained and will almost certainly need to be updated.

This all assumes you want to run the processor in a tethered fashion. To make it self-booting will require more work. There is work on a platform specification that will standardize this, but until then you will need to design your own or continue to use Rocket Chip tethered.

Tropine

The host interface on the ARM core is mapped as a general memory mapped IO. The interface creates the file /dev/mem on the ARM core and then the rocket core will access this physical memory. Am I right? So I dont think there is any AXI specific access provided by it. So what do I need to modify in the fesvr codes? Also, how to I get the offset used in mmap (dev_paddr)? – Ka

Also, once I have the make install the modified fesvr, I generate certain files in the build directory. How am I to use this new fesvr? Where to include it to be able to use it? – Ka

All I can find is : When installing fesvr-zynq, don't forget to copy the library as well (build/libfesvr.so to /usr/local/lib on the board). Can you please elaborate on this? – Ka

Correct, much of the complexity is abstracted away with memory mapped IO. The dev_paddr is this mapping (so you will need to find this for your platform). – Tropine

For examples in using fesvr, I would look at the four examples we have already posted (ISA simulation with spike, ISA simulation with QEMU, C++-emulation of Rocket Chip, and running on the Zynq). For some of those platforms the fesvr is implicit, but it is used for all of them. The usage for Zynq is probably the most similar. – Tropine

The makefile for fesvr generates multiple binaries that all use the same shared library (libfesvr.so). That will need to be available to your new binary, or you will need to change the compilation to statically link. – Tropine

Hi, I have a few questions: 1. How can I get the dev_paddr necessary to make the mapping for my board? 2. The rocket chip wrapper uses AXI to connect to the physical memory /dev/mem right? The fesvr doesn't have any AXI component to it? 3. I modified the fesvr, and built it, and now I have fesvr-stratixv and libfesvr.so. Where do I put this on the arm core (in my case the nios II core) to run? (I have linux running on the nios II) 4. And lastly, is the rocketchip_wrapper.v generated automatically from RocketChip.scala? Or can I manually modify this verilog code and customise it for my FPGA? – Ka

1/2. Yes, we use memory-mapped IO to communicate over AXI. dev_paddr is the IO address. For the Zynq boards, we not only set that within fesvr, but also the board configuration. 3. This can be changed, but typically fesvr can go anywhere and libfesvr.so should go in /usr/local. 4. Yes. You can probably pull off the modifications you need without changing anything inside Rocket-Chip itself or any Chisel code. – Tropine

Answer 2

I've ported single-core Rocket-chip on Non-Zynq FPGA (boards: ML605 and KC705) and I'm interested to port it on other targets (see message above 'https://github.com/sergeykhbr/riscv_vhdl'). So if you'd like to use proposed vhdl design and ready to collaborate I think I can help you with that and as result add Quartus project file into the repository.

Additionally there's possibility to re-use the GPL licensed peripheries implemented in 'grlib': http://www.gaisler.com/index.php/downloads/leongrlib. such as MAC, SD-controller and many others.

Dawson

Answer 3

Take a look at the example of using Rocket-chip core inside of the portable VHDL top level. That project has very similar structure to the Leon3 that maybe very easy ported for any FPGA board. See:

https://github.com/sergeykhbr/riscv_vhdl

Dyslogistic