I am trying to test a variant of RocketChip and currently I am trying to understand the provided Scala codes.
However I have few questions concerning the memory and the bootloader. To test the generated verilog I am using an Altera DE2-115 FPGA.
Comparing to the E300ArtyDevKitTop verilog output the rocket chip verilog output shows clear separation for srams from the rest of modules. Which is the wanted outcome, since in altera FPGA the srams are generated separately using memory IPs. Since the E300ArtyDevKitTop verilog procedure is a complete verilog with all the peripherals, I am using it to learn the details of the implementation but I can’t tell the srams module apart. doesn’t the Arty FPGA need an IP module for the srams ?
for E300ArtyDevKitTop bootrom (e300artydevkit.img), is it the compilation of freedom/bootrom/xip/xip.S ?
if so, a linker is not needed here ?
if not, is it possible to have the source code ? Then what’s the use of xip.S ?
and is jumping to 0x20000000 its only functionality ?
For Rocket Chip there is bootrom.S and linker.ld can I use them instead of e300artydevkit.img if I could possibly add the jumping to spi flash address ?
Is a startup code necessary while compiling C codes to download and run on either Arty FPGA or HiFive board or the bootloader can replace it ?
Comparing to the E300ArtyDevKitTop verilog output the rocket chip verilog output shows clear separation for srams from the rest of modules. Which is the wanted outcome, since in altera FPGA the srams are generated separately using memory IPs. Since the E300ArtyDevKitTop verilog procedure is a complete verilog with all the peripherals, I am using it to learn the details of the implementation but I can’t tell the srams module apart. doesn’t the Arty FPGA need an IP module for the srams ?
Most FPGA synthesis flows are able to infer block RAMs from behavioral. This is what we use in this flow. There are wrappers generated which, for FPGAs, instantiate simple behavioral SRAMs. We rely on the FPGA synthesis flow to infer the proper SRAMs. This keeps the generated Verilog vendor-independent.
for E300ArtyDevKitTop bootrom (e300artydevkit.img), is it the compilation of freedom/bootrom/xip/xip.S ? if so, a linker is not needed here ? if not, is it possible to have the source code ? Then what’s the use of xip.S ?and is jumping to 0x20000000 its only functionality ?
Yes, it is the compiled version of that code. We have pre-compiled it and included the bootrom/xip/xip.S as reference. Yes, its only functionality is to jump to the SPI Flash.
For Rocket Chip there is bootrom.S and linker.ld can I use them instead of e300artydevkit.img if I could possibly add the jumping to spi flash address ?
You can replace the spiflash.img with any file you want. You can generate the ELF file through the usual compilation and linking processes, then generate the .img file from that.
Is a startup code necessary while compiling C codes to download and run on either Arty FPGA or HiFive board or the bootloader can replace it ?
I’m not sure I quite understand the question. But, the downloading process does not require any bootrom code. The debugger assumes nothing about the code running on the HiFive1 or Arty FPGA when it downloads the program.
Hi,
I would like to move forward with this effort, so I am here to help in anything needed. I’ve started few months ago trying to enable an Altera kit with both e300 and u500. At this point, my Xilinx’ SP605 and ML605 are able to run both systems but there are few things we need to care about for Altera:
Reset module in e300 is an Vivado IP, not too complex to transform into a Verilog specification (this IP obviously is not in the Megawizard).
Tri-state IO buffers in e300 are Xilinx primitives: Also here is easy to map the primitive to an $architecture_ibuf/obuf from Altera.
External memory controllers. This can be challenging.
I would like to know how to modify and recompile the e300artydevkit.img. When you run the Chisel Verilog generator, it creates a memory content based on that bootrom. Before going to enable the JTAG, it would be more easy to have a FW that doesn’t jump to an specific external memory and just do something like a blink. Once that is done, we can focus on point 3.
I’ve tried to recompile the bootrom with a dummy code using freedom sdk, but in the moment I ran again chisel, it fails in that stage. I am pretty sure is because I did it wrong (not specified any memory region or data linker to the compiler), so I am looking to have this info first.
