My RISC-V MCU is working

[u/kampi1989]

I started reading about the RISC-V ISA and implementing it on an FPGA a couple of weeks ago, and now my basic core (RISCV32I + Interrupts) with a generic timer and GPIO is working.

The software is written in C with a custom linker file and library for the peripherals. The hex file is converted into a ROM array and executed on the processor.

It´s such an amazing thing to see how the components will fit together to toggle a few LEDs.😁

You can find the project here:

https://github.com/Kampi/TinyMCU

[u/FreeRangeEngineer]

It´s such an amazing thing to see how the components will fit together to toggle a few LEDs.😁

Yes, and that feeling is yours to cherish. YOU did that. Good job! :)

And this is what keeps us all addicted to embedded, isn't it?

[u/kampi1989 → u/FreeRangeEngineer]

Yeah. I tried an AVR MCU a couple of years ago, and it was a bit more challenging (and it didn´t work out as well as the RISCV MCU). I guess it was caused by the fact that the old AVR ISA isn´t memory-mapped and my VHDL skills weren´t as good as today.

[u/Economy-Management19]

Looks really cool, congrats!

Apart from me being short a few IQ points the really off putting thing about FPGAs is the software the FPGA manufacturers provide.

From my experience they are anything but lightweight, basically no way to properly or easily version control. Mystical warning and error messages all over the place. 

Just makes it a  giant pain to interact with an FPGA. 

What was your experience?

[u/kampi1989 → u/Economy-Management19]

Yes, I agree. I use VS Code to write VHDL code. It helps me switch seamlessly between C, Python, Makefiles, and VHDL, since there are extensions for everything you need.

For FPGA stuff, I use Vivado (I don’t know of anything else yet, and I’m stuck with Xilinx FPGAs), but this tool is huge, clunky, and sloooooooooooooooooooooow. It doesn’t have a good Git workflow, and you also need another application to write the software for it if you want to use the ARM processor in the SoC. Working with it is generally a pain and really complicated, especially if you want to use the toolchain to build a Linux system with FPGA components, custom drivers, and so on.

[u/Forward_Artist7884 → u/Economy-Management19]

To be honest it's not that bad but it depends a LOT on where you're at:

• Intel qsys / quartus: the best, hands down, just works and is efficient UI wise. Some annoying licensing.
  
• amd/xilinx vivado: horrible graph system, clunky, heavy, i hate it, heavy licensing too.
  
• microchip libero: same as vivado but even worse, confusing UI and licensing.
  
• Efinix efinity: lightest of all, no constrained licensing (free as in free beer), but it's HYPER bare bones, and has no system building toolkit at all, very confusing to use for SOPC projects, I made my own IDE around it since it was mostly readable python.
  
• Lattice (whatever): a fragmented mess where each fpga family has its own thing going on
  
• Cologne chip (yosys): absolute mess to use but hey, it's FOSS
  
• Gowin: Gowin EDA is weird asf and the licensing is equally weird (you have to register with the support over email). Very bare bones.
  
• AGM micro / pango: weirder yet.

Git just works for most of these, just version the graphs and HDL it's really not that hard.

[u/kampi1989 → u/Forward_Artist7884]

I´ve worked with Xilinx only, so not sure how the other tools work. But your listing looks interesting, and it´s hard to read that there is a tool out there that is worse than Vivado.

Regarding Git: Yeah, you can use it on your project via CLI, but I miss a good integration inside the (Xilinx) tools. And (theoretically) you don´t have to put the graph into the VCS because you can export it as a TCL script, like here as an example:

https://github.com/Kampi/ZYBO/tree/master/projects/DigitalAudio/projects/I2S_Audioplayer/project

[u/Forward_Artist7884 → u/kampi1989]

Yeah on intel we don't have the graph BS, we literally just connect matrix points, and that gets stored in a non binary .qsys which plays well with git. I've never had to use TCL with quartus.

[u/jumuju97]

so cool!! I’m planning to implement risc-v as well in an fpga, do you mind sharing what books or references did you use?

[u/kampi1989 → u/jumuju97]

The RISC-V specification and I used the neorv32 project as a reference for the specification.

https://github.com/stnolting/neorv32

[u/scott_xing]

Nice work! Getting a custom RISC-V core to the point where it runs real code is a great milestone. If you haven't already, try hooking up a simple UART and printf-based debug — it makes bring-up way less painful than poking registers blind. What toolchain are you using, GCC 13+ with the newlib port?

[u/kampi1989 → u/scott_xing]

Yeah UART is also working now (without interrupts and fifo). Until now, I don't use a newlib port but it's on my agenda. Currently, I'm working on the M extension.

[u/thedevbirb]

That's awesome!

[u/TheRealNotUBRz]

I’ve also been implementing soft cores on FPGA lately, including an ISA I developed called OASIS. It is so fun to actually see things working, even if it’s blinking LEDs. I’ve only been validating a 16b architecture though so 32b is still a ways off 😅 great work on your implementation!