sodor-spinal a RISC V core in SpinalHDL.

Heater.

sodor-spinal is my attempt at creating my own RISC V processor core for FPGA.

As I have never attempted to create any kind of processor in hardware before sodor-spinal is about as simple as I could imagine making such a thing. It is based on the Sodor 1-Stage RISC V design that students build in their CS/EE Computer Architecture courses at Oakland, Berkeley, etc. Which is nicely described here: https://passlab.github.io/CSE564/notes/lecture08_RISCV_Impl.pdf

Rather than use Verilog or VHDL sodor-spinal is written in SpinalHDL. SpinalHDL is a hardware description language created by Charles Papon and based on the Scala language. Actually, more correctly, SpinalHDL is just Scala library, the design you create with it is just Scala code that uses the Spinal library. This is not exactly a translation of Scala to Verilog but rather when the Scala code is run in magically generates Verilog. If you prefer VHDL it can do that as well!

The upshot of all this is that writing SpinalHDL is much easier than Verilog or VHDL, a lot less ugly, and you can use all the power of a proper programming language to create your designs.
SpinalHDL is well documented here: http://spinalhdl.github.io/SpinalDoc/

sodor-spinal is mostly complete but has yet to be tested under simulation let alone get anywhere an FPGA.
If anyone is interested in kicking the wheels of Sodor source and installation/run instruction are here: https://github.com/ZiCog/sodor-spinal

This is the basic design it's aiming for:



None of this is very Parallax related, unless we want to mix it up with a P1V, but who else can I talk to about such things? Anyway, it's Chip's fault for getting us all interested in FPGA

ersmith

I haven't had time to actually do anything with it, but the source code looks interesting. Spinal looks like a pretty powerful way to describe hardware. I'm not a hardware guy (at all!) but it looks like these high level hardware description languages are making hardware more and more like software .

Heater.

Eric,

...it looks like these high level hardware description languages are making hardware more and more like software

That's right. I initially thought that kind of abstraction might be deceptive and confusing. For example when you see some lines of expressions they are not being executed sequentially, one after the other, as they are in a normal programming language. Rather they are all happening simultaneously. What you are doing is connecting a bunch of wires (the variables) to gates (the operators). They all work in parallel, it does not generally matter which order you write the statements in.

Unless of course the variables are declared as Reg(...) in which case they take on the values assigned to them only when the system clock makes a low to high transition. One does not see any clock signals in a Spinal design, that's all abstracted away, the use of a clock to trigger the registers is inferred from the fact that they are declared as Reg(...). Unlike Verilog and VHDL where one has to manually specify all the clock signals and how they trigger registers.

And then of course in Spinal you can include any amount of Scala code that is not ending up in the hardware design but is used to "generate" it. For example my use of Map in Sodor to determine the processor control signals.

Still, it turns out to be pretty easy to get used to. All those CS/EE undergrads at Berkeley and such are using a similar HDL, Chisel, in class and they seem to get on with it very easily.

Heater.

sodor-spinal runs it's first instructions!

Just now sodor-spinal is only a RISC V core with no memory. I can test it by writing a test harness that pokes instructions into its memory port, toggling it's clock and then checking all the internal data path and control signals get set correctly. And the correct result comes back out the memory port.

Turns out that SpinalHDL does some magic here. The test harness is written in Scala using the Spinal library, but now instead of just generating Verilog it compiles that Verilog into a runnable simulation into C++ using the Verilator simulator. It also generates some wrapper C++ code for the verilator simulation that sets and checks all the Verilog signals. Then it runs the simulation. All in one shot!

An example test case, for the program counter, looks like this:

    compiled.doSim("test_ProgramCounter") { dut =>

      // Fork a process to generate the reset and the clock on the dut
      dut.clockDomain.forkStimulus(period = 10)

      var modelPc = 0

      var idx = 0
      while(idx < 10){

        // Drive the dut inputs with NOP instruction
        dut.io.instructionMemory.data #= Integer.parseInt("00000000000000000000000000010011", 2)

        // Wait a rising edge on the clock
        dut.clockDomain.waitRisingEdge()

        // Check that the dut values match with the reference model ones
        assert(dut.programCounter.io.pc.toInt ==  modelPc)
        assert(dut.programCounter.io.pc4.toInt == modelPc + 4)
        assert(dut.io.instructionMemory.addr.toInt == modelPc)

        modelPc = modelPc + 4
        idx += 1
      }
    }

This is all built and run with one command

sbt "run-main Sodor.SodorSim".

Not only that it outputs a .vcd file so that one can view the signal waveforms of the test in gtkwave.

I thought this was all too complex to ever work, too many moving parts, but it has been working very well. Certainly a lot easier than writing a test harness in Verilog for Icarus or Verilator simulation.

Heater.

sodor-spinal now has a simulation wrapper that tests all data and control paths within the design and that all the functional blocks are, well, functioning. All with no need for Quartus or other gargantuan FPGA IDE.

Also yosys tuns it into a Lattice FPGA bit stream. All with Open Source tools.

The RISC-V core comes in at only 800 lines of SpinalHDL source code.

Which generates a 1000 lines of Verilog and nearly 2000 lines of VHDL !

Now to provide it with some memory and see if it can actually run programs...

https://github.com/ZiCog/sodor-spinal