RISC-V evaluating on FPGA board - Page 1
Forum section: electronics / general

author: FlyingDutch
author_rank: Regular Contributor
timestamp: December 27, 2018, 11:13:04 am
content: Hello,last time many news is appearing aboutRISC-VISA and example architecture of CPU. TheHiFive1board from SiFive is to expensive for me so I decided to evaluate RISC-V ISA on a FPGA board. My trials were based on Github project calledVexRiscv, because trhere is a documentation for this project:https://github.com/SpinalHDL/VexRiscvAfter installation all of needed packages and dependencies:1) Java 82) Scala 2.11.x3) Scala SBT4) SpinalHDL4) VerilatorSee: #Dependencies in this link:https://github.com/SpinalHDL/VexRiscv#area-usage-and-maximal-frequencyI was able to generateVexRiscvin minimal and full configuration. I am attaching these generated CPUs (Verilog):VexRiscv.v.zipandVexRiscvFull.zipThese files are syntetising OK in Xilinx ISE 14.7 (Webpack). The only problem is that tis design has few 32-bits wide buses, on FPGA boards there aren't so much I/O buffers. So I decided to generate"Briey SoC"which has a bridge to AXI bus. In this"Briey SoC"there were two GPIO ports A and B (three 32-bit buses each), so I decided to remove all GPIO B port and shortened A GPIO to 4 bits.Here is ISE 14.7 project with this altered"Briey SoC"design. It synthetisies OK for Spartan6 FPGA (XC6SLX9). I am attaching ISE 14.7 project in file: BrieySoC01.zipSorry I just has realized that attachements size limits for this forum, not enabled to attache these files, so I am giving links to my dropbox:https://www.dropbox.com/s/jgj6fq8axjdfcf5/VexRiscv.v.zip?dl=0https://www.dropbox.com/s/n68dvm3599zbadf/VexRiscvFull.zip?dl=0https://www.dropbox.com/s/irfg0vfe3d92haw/BrieySoC01.zip?dl=0I would like to run this"Briey SoC"(RISC-V CPU) on this FPGA board with Spartan6:https://numato.com/product/mimas-v2-spartan-6-fpga-development-board-with-ddr-sdramI installed "GCC Toolchain for RISC-V" and "Freedom Studio" and I compiled some example programs.And there is a difficulty I encountered: "How to load binary (elf or hex) file with machine code for RISC-V (program) to FPGA configuration memory"How can one realize this task? I don't know by generating SPI-Flash memory image (FPGA configuration memory), by JTAG or by other ways.Thanks in advance for your expertise,and Regards

author: rstofer
author_rank: Super Contributor
timestamp: December 27, 2018, 10:32:46 pm
content: Maybe this will helphttps://www.xilinx.com/support/documentation/user_guides/ug161.pdfLook up how to use data2mem - a utility that jams code into BlockRAM initial contents.When you define BlockRAM you can a) initialize the contents at the declaration or b) add initialization statements to the .ucf file (which shortens recompile time considerably over choice 'a' or c) use data2mem utility to write the contents of BlockRAM to an existing .bit file. Option 'c' is probably the best but it takes some studying to find the coordinates of the BlockRAM.https://www.xilinx.com/support/documentation/sw_manuals/xilinx11/data2mem.pdf

author: FlyingDutch
author_rank: Regular Contributor
timestamp: December 28, 2018, 08:38:31 am
content: Hello @rstofer,thanks for your answer - it is useful for me (especialy the second document "dat2mem"). I am reading it now, but it comes into my mind one question:"Can I use directly SDRAM which is onboard of FPGA "Mimas V2" as a program memory for "Biery SoC""?On this FPGA board I am using, is 512Mb DDR SDRAM available, and also in Verilog design of "Briey SoC" this bus for SDRAM is available. I am wonder if for "Briey SoC" (RISC-V) is available some kind of 'bootloader' which can be used in purpose to load program to memory and execute it?Link to Mimas V2. FPGA board:https://numato.com/product/mimas-v2-spartan-6-fpga-development-board-with-ddr-sdramThese "dat2mem" document describes using rather internal BRAM memory for storing program to "Briey SoC".Kind Regards

author: legacy
author_rank: Super Contributor
timestamp: December 28, 2018, 10:01:30 am
content: Quote from: FlyingDutch on December 28, 2018, 08:38:31 amof course, yes.

author: FlyingDutch
author_rank: Regular Contributor
timestamp: December 28, 2018, 10:37:48 am
content: Hello,I am studying documents at these links:https://github.com/riscv/riscv-wiki/wiki/RISC-V-Software-Status#boot-loaders-and-monitorshttps://github.com/riscv/riscv-pkhttps://www.lowrisc.org/docs/untether-v0.2/bootload/I hope I would be able to adapt some of that bootloaders to work with "Mimas V2" FPGA board and "Briey SoC" implemented on it.Regards

author: brucehoult
author_rank: Super Contributor
timestamp: December 28, 2018, 11:01:44 am
content: It should be pretty easy to store a program in the SPI Flash, assuming it's not all needed to hold the FPGA bitstream.Can you memory map the SPI Flash and execute directly from it? (very slow if you don't have an icache)If not then, yes, you could build a tiny bootloader into the FPGA image that reads the SPI Flash and copies part of it into RAM execution.

author: legacy
author_rank: Super Contributor
timestamp: December 28, 2018, 11:39:28 am
content: A lot of time ago (5-7 years ago) I bought a MIPS development board which arrived with the ROM completely wipedI used a jtag to program it, but I needed to writethismonitor in assembly. It came from an existing project, I don't remember what/where/how, I remember the source was cleaned and adapted for the new purpose.Since the MIPS assembly is similar to the RISCV's one .. maybe you can adapt the source code

author: legacy
author_rank: Super Contributor
timestamp: December 28, 2018, 11:46:15 am
content: (isn't really there a similar Monitor for RISCV? I would be surprised not to see it already implemented by someone)

author: brucehoult
author_rank: Super Contributor
timestamp: December 28, 2018, 11:58:49 am
content: Quote from: legacy on December 28, 2018, 11:46:15 amSure, there are lots of them. But if you've configured your own core in an FPGA then they're going to have to be configured for how you've set things up, what peripherals you have, where everything is in the memory map etc.

author: legacy
author_rank: Super Contributor
timestamp: December 28, 2018, 12:25:32 pm
content: Quote from: brucehoult on December 28, 2018, 11:58:49 amumm, basically they are not a full BSP, just a monitor, therefore what you should consider iswhere can I save an uploaded program? You end up writing/adapting the linker script and the software for programming the onboard flashfrom which device can I upload? You end up writing a the driver for the Uart (physical Uart, or USB-driven Uart, or whatever...)(optionally, *if* it's a real need) the proper initialization for the DRAM controllerso basically, having a skeleton of a working Monitor, it *should be* really simple to customize it.

author: FlyingDutch
author_rank: Regular Contributor
timestamp: December 28, 2018, 12:51:25 pm
content: Hello Guys,thank you all for answers. Looking at "Mimas V2" board description and schematics - there is "PIC18F14K50" uControler which dutyv is "boot" all board. The PIC is attached to SPI Flash which is used to configuration of Spartan 6 FPGA. The "bin" configuration file (from Xilinx iSE) is loaded by application written to this PIC uControler (USB).Answering to question:"Can you memory map the SPI Flash and execute directly from it? (very slow if you don't have an icache)"I have to check if I can map "Briey SoC" memory to SPI Flash of FPGA board (I rather think it is not possible)? So I think that tis second option isproper for me:"If not then, yes, you could build a tiny bootloader into the FPGA image that reads the SPI Flash and copies part of it into RAM execution."Kind Regards

author: asmi
author_rank: Super Contributor
timestamp: December 28, 2018, 06:11:52 pm
content: I know for fact that Vivado SDK can upload program for Microblaze and Zynq directly into DDR3 or BRAM-based OCM, which dramatically cuts down development time as it takes just a moment. So check if whatever debugger you're using is capable of doing this. Obviously these updates are volatile and will be gone on power cycle. Advantages are that it's fast and doesn't use up flash erase cycles, and you can always "burn in" your program into BRAM init part of your bitstream once the code "settles in" so to speak, and then program it into the flash so that it would persist over power cycles.

author: legacy
author_rank: Super Contributor
timestamp: December 28, 2018, 07:39:03 pm
content: Quote from: FlyingDutch on December 27, 2018, 11:13:04 amwhich is the board you are using?

author: FlyingDutch
author_rank: Regular Contributor
timestamp: December 29, 2018, 07:59:30 am
content: Hello,the FPGA board I am using is "Mimas V2" from "Numato Lab". Here is link to it's description:https://numato.com/product/mimas-v2-spartan-6-fpga-development-board-with-ddr-sdramI always read configuration file "bin" to the board by USB and dedicated application written by "Numato LAB", but this boartd has also JTAG interface.I find information, that "OpenOCD RiscV" can load elf file to the board by JTAG. I am going to check this option.Regards

author: rstofer
author_rank: Super Contributor
timestamp: December 29, 2018, 10:27:43 pm
content: Dat2mem would be used to program BlockRAM. It is possible, I suppose, to initialize SDRAM from the remaining space in the platform flash. I don't know how to do it.I would use the BlockRAM to hold a little boot loader and I would have a Compact Flash or SD card as a general file system. It would, of course, have the initial BIOS and such in boot sectors - just exactly the way CP/M implemented it. In fact, were I to write such a thing, I would use CP/M (MSDOS) as a model.I have attached a little BlockRAM initialization code provided by EEVblog's own hamster_nz. It reads a hex file at build time for initializing BlockRAM. Not as fast to use as Dat2mem but I don't need to know where the BlockRAM is physically placed.A few months back I implemented the relatively famous LC3 RISC CPU and I used that initialization code to load the initial program. It works very well. There's some code commented out that would be used if the memory width were not just 16 bits. But, remember, the hex file is read at build time. The hex code becomes a permanent part of the image file loaded into the platform flash.