Author Topic: RISC-V evaluating on FPGA board  (Read 4588 times)

0 Members and 1 Guest are viewing this topic.

Offline FlyingDutchTopic starter

  • Regular Contributor
  • *
  • Posts: 147
  • Country: pl
RISC-V evaluating on FPGA board
« on: December 27, 2018, 11:13:04 am »
Hello,

last time many news is appearing about RISC-V ISA and example architecture of CPU. The HiFive1 board 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 called VexRiscv, because trhere is a documentation for this project:

https://github.com/SpinalHDL/VexRiscv

After installation all of needed packages and dependencies:

1) Java 8

2) Scala 2.11.x

3) Scala SBT

4) SpinalHDL

4) Verilator
See: #Dependencies in this link:

https://github.com/SpinalHDL/VexRiscv#area-usage-and-maximal-frequency

I was able to generate VexRiscv in minimal and full configuration. I am attaching these generated CPUs (Verilog): VexRiscv.v.zip and VexRiscvFull.zip

These 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.zip

Sorry 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=0
https://www.dropbox.com/s/n68dvm3599zbadf/VexRiscvFull.zip?dl=0
https://www.dropbox.com/s/irfg0vfe3d92haw/BrieySoC01.zip?dl=0


I 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-sdram

I 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

« Last Edit: December 27, 2018, 11:37:43 am by FlyingDutch »
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9935
  • Country: us
Re: RISC-V evaluating on FPGA board
« Reply #1 on: December 27, 2018, 10:32:46 pm »
Maybe this will help
https://www.xilinx.com/support/documentation/user_guides/ug161.pdf

Look 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
 
The following users thanked this post: FlyingDutch

Offline FlyingDutchTopic starter

  • Regular Contributor
  • *
  • Posts: 147
  • Country: pl
Re: RISC-V evaluating on FPGA board
« Reply #2 on: December 28, 2018, 08:38:31 am »
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-sdram

These "dat2mem" document describes using rather internal BRAM memory for storing program to "Briey SoC".

Kind Regards
« Last Edit: December 28, 2018, 08:40:08 am by FlyingDutch »
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: RISC-V evaluating on FPGA board
« Reply #3 on: December 28, 2018, 10:01:30 am »
 

Offline FlyingDutchTopic starter

  • Regular Contributor
  • *
  • Posts: 147
  • Country: pl
Re: RISC-V evaluating on FPGA board
« Reply #4 on: December 28, 2018, 10:37:48 am »
Hello,

I am studying documents at these links:

https://github.com/riscv/riscv-wiki/wiki/RISC-V-Software-Status#boot-loaders-and-monitors

https://github.com/riscv/riscv-pk

https://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
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4532
  • Country: nz
Re: RISC-V evaluating on FPGA board
« Reply #5 on: December 28, 2018, 11:01:44 am »
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.
 
The following users thanked this post: FlyingDutch

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: RISC-V evaluating on FPGA board
« Reply #6 on: December 28, 2018, 11:39:28 am »
A lot of time ago (5-7 years ago) I bought a MIPS development board which arrived with the ROM completely wiped :palm:

I used a jtag to program it, but I needed to write this monitor 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  :-//
 
The following users thanked this post: FlyingDutch

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: RISC-V evaluating on FPGA board
« Reply #7 on: December 28, 2018, 11:46:15 am »
(isn't really there a similar Monitor for RISCV? I would be surprised not to see it already implemented by someone)
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4532
  • Country: nz
Re: RISC-V evaluating on FPGA board
« Reply #8 on: December 28, 2018, 11:58:49 am »
(isn't really there a similar Monitor for RISCV? I would be surprised not to see it already implemented by someone)

Sure, 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.
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: RISC-V evaluating on FPGA board
« Reply #9 on: December 28, 2018, 12:25:32 pm »
(isn't really there a similar Monitor for RISCV? I would be surprised not to see it already implemented by someone)

Sure, 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.

umm, basically they are not a full BSP, just a monitor, therefore what you should consider is
  • where can I save an uploaded program? You end up writing/adapting the linker script and the software for programming the onboard flash
  • from 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 controller

so basically, having a skeleton of a working Monitor, it *should be* really simple to customize it.
« Last Edit: December 28, 2018, 12:34:49 pm by legacy »
 

Offline FlyingDutchTopic starter

  • Regular Contributor
  • *
  • Posts: 147
  • Country: pl
Re: RISC-V evaluating on FPGA board
« Reply #10 on: December 28, 2018, 12:51:25 pm »
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

 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2827
  • Country: ca
Re: RISC-V evaluating on FPGA board
« Reply #11 on: December 28, 2018, 06:11:52 pm »
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.
 
The following users thanked this post: FlyingDutch

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: RISC-V evaluating on FPGA board
« Reply #12 on: December 28, 2018, 07:39:03 pm »
evaluate RISC-V ISA on a FPGA board

which is the board you are using?
 

Offline FlyingDutchTopic starter

  • Regular Contributor
  • *
  • Posts: 147
  • Country: pl
Re: RISC-V evaluating on FPGA board
« Reply #13 on: December 29, 2018, 07:59:30 am »
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-sdram

I 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
« Last Edit: December 29, 2018, 08:23:29 am by FlyingDutch »
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9935
  • Country: us
Re: RISC-V evaluating on FPGA board
« Reply #14 on: December 29, 2018, 10:27:43 pm »
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.

« Last Edit: December 31, 2018, 12:29:17 am by rstofer »
 
The following users thanked this post: FlyingDutch


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf