RISC-V on an FPGA, pt. 5

I’ve learned a few things about this process. These are just my random thoughts in no particular order:

  • You need the heavily proprietary Xilinx Vivado to compile the Verilog source code to a bitstream. However you can use free tools to write the bitstream to the FPGA (eg. xc3sprog). Edit: There is another option: You can write the bitstream onto the SD-card and switch the jumper JP1 to SD-card. On boot the FPGA will load the bitstream from the SD-card. This is actually much nicer because it means you don’t need to manually reprogram the FPGA every time you power it up.
  • The core lowRISC CPU is free, but that’s not everything that goes into the bitstream. Also in the bitstream are some peripherals, such as the UART, and those are Xilinx proprietary IP. So the bitstream isn’t fully free and more importantly isn’t redistributable. (Note, according to this talk there is a plan to fix this).
  • This is a nice summary of the v0.2 architecture, esp. page 4

3 Comments

Filed under Uncategorized

3 responses to “RISC-V on an FPGA, pt. 5

  1. I’m glad to see you got everything working Richard.

    By my reading of the Xilinx license agreement, the bitstream is redistributable actually. See 3.(3).C in http://www.xilinx.com/support/documentation/sw_manuals/end-user-license-agreement.txt

    Low-speed peripherals like SPI and UART will be handled by the minion cores in a future release. I believe there are a few FPGA-ready open DRAM controllers around, and it might be a good starter project for someone to try to switch out the Xilinx controller.

    • rich

      (More about minion cores)

      It seems like almost a waste to have a whole core doing something like a UART. I suppose transistors are cheap (not so much in FPGAs though) that we might use cores for everything. Is there a reason to use cores for this, or is it just because software is easier to develop?

      • Also see http://www.lowrisc.org/docs/memo-2014-001-tagged-memory-and-minion-cores/ for more on minions.

        A UART is so trivial it probably is a waste, but it wouldn’t require dedicating a whole core – the ‘shim’, the layer between the core and the I/O pins will provide offloading for things it would be very inefficient to naively bit-bang (e.g. shifting out a register). Often when using SPI, I2C etc you have at least soft real-time constraints. Doing that on your main application core can be a pain, which is why so many Raspberry Pi projects end up adding an external microcontroller. Have the minion core may also be more energy efficient overall (it’s better to do pre-processing on a microcontroller-like core and wake up the power-hungry Linux core only when needed). As you point out transistors are incredibly cheap, at least when it comes to a modern ASIC.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.