Index ¦ Archives ¦ Atom ¦ RSS

A simulation milestone for the Muskoka SoC!

A moxie-based SoC had it's first successful simulation run today....

gtkwave display of first code run

Pretty exciting! So, here's what's happening...

The SoC, code named "Muskoka", has three main components: the moxie core, a wishbone switch and a ROM device. The switch was easy to implement, as I just have a single bus master (moxie), and a single slave device (bootrom) for now. The boot ROM is populated with bits generated by assembling the code below like so:

moxie-elf-as -o bootrom.x bootrom.s moxie-elf-objcopy -O verilog bootrom.x bootrom.vh

.text
    xor $r0, $r0  # Zero out $r0
    xor $r1, $r1
    xor $r2, $r2
    xor $r3, $r3
    xor $r4, $r4
    inc $r0, 0x1  # Increment $r0 by 1
    inc $r1, 0x1
    inc $r2, 0x1
    inc $r3, 0x1
    inc $r4, 0x1
    inc $r0, 0x1
    inc $r1, 0x1
    inc $r2, 0x1
    inc $r3, 0x1
    inc $r4, 0x1
    inc $r0, 0x1
    inc $r1, 0x1
    inc $r2, 0x1
    inc $r3, 0x1
    inc $r4, 0x1

The moxie core itself is has 4 pipeline stages: Fetch, Decode, Execute and Write. The Fetch stage is probably the most complicated at this point. Remember that moxie has both 16- and 48-bit instructions. However, we're fetching instruction memory from the ROM device 32-bits at a time. The fetch logic feeds these 32-bits into an instruction queue and pulls out the right number of bits at the other end, depending on the instruction about to be decoded.

So far only NOP, XOR and INC have been implemented, and there's no pipeline hazard detection logic, but careful analysis of the simulation dumps in gtkwave show that everything is finally starting to work. Baby steps...

As usual, everything has been committed to moxiedev on github.

© Anthony Green. Built using Pelican. Theme by Giulio Fidente on github.