Verilog | The Moxie Blog

Posts Tagged ‘verilog’

Fetching instructions

Tuesday, September 7th, 2010

Moxie requires some interesting instruction fetch logic.

For my initial implementation I’m assuming a 32-bit path to instruction memory. But moxie has both 16- and 48-bit instructions, so it’s not like simple RISC cores that can feed the pipeline on every cycle. My solution is to feed 32-bit instruction memory words into a Instruction FIFO. 16- and 48-bit instructions pop out of the other end of the FIFO on every cycle (or a NOP bubble when we’re waiting for the last 16 bits of a 48-bit instruction). My initial Instruction FIFO is 64-bits long. From my simple testing it looks like this does a reasonable job of keeping the instruction memory path busy, and issuing instructions as often as possible (I’m just eyeballing the gtkwave output, reproduced below). I can experiment with a longer Instruction FIFO later.

This image shows a few signals from the Instruction FIFO. valid_o tells us that we’re popping off a valid instruction from the FIFO, whereas full_o tells us not to write any data to the FIFO because it’s full. So far, so good – decoupling the fetching of instruction memory from the rest of the pipeline is obviously the right thing to do.

One more complication that I’m going to punt on for now is PC tracking. Eventually we’ll want to pass the PC down the pipeline so we get accurate exception addresses. Tracking the PC through the Instruction FIFO is just one more little complication that I’ll tackle after I make more progress on the rest of the microarchitecture.

I’ve only done some behavioral simulation so far, but I believe the code is synthesizable. The code is in github here: http://bit.ly/9yVQ7U. Running make should build everything, then just run “a.out”.

Note that I’m using magic instruction memory: an array populated with a hello world app built like so…
$ moxie-elf-gcc -o hello.x -O2 hello.c -Tsim.ld $ moxie-elf-objcopy -O verilog hello.x hello.vh
And the verilog simulator reads hello.vh directly. Pretty cool!

(I just realized I wrote about fetching instructions almost 18 months ago – that took too long!)

Tags: architecture, verilog
Posted in moxie | View Comments

Summer is over, so put away the white pants and start submitting patches!

Thursday, September 10th, 2009

It’s been a while since my last update. What can I say… summer was nice.

But now, back to business! I’ve just committed some long overdue patches to the upstream GNU tools:

Add a device tree blob to the gdb simulator. This lets us describe the gdb sim target to our single kernel image as described in this posting.
A GCC size optimization. Load 0 into a register via xor.
Improve function prologue code generation, and a corresponding gdb change.
Use 6 registers to pass function arguments as described here.

This gets us to booting the kernel, loading BusyBox, running some shell code and… crashing on the first fork. No problemo. Nothing a small matter of programming can’t fix. However, there are some other distractions…

Verilog is lots of fun! It looks like regular programming, but it feels more like building a kinetic sculpture.

There’s also the small matter of not having an interrupt controller! So there’s some work here to design an interrupt controller, implement it in verilog, simulate it qemu (and possibly the gdb sim), and port the kernel over to using it. This should be interesting…

Tags: gcc, gdb, linux, qemu, verilog
Posted in moxie | View Comments

Loading programs into the verilog simulation

Wednesday, April 22nd, 2009

The moxie newlib port was just accepted. The GCC port will take a little longer to review, but I hope that it will get accepted early next week. Already there has been some useful feedback resulting in a few improvements. For instance, the moxie libgcc.a now provides the soft-fp floating point emulation library instead of the fpbit one. Apparently it’s harder/better/faster/stronger, and other ports are starting to adopt it. See the “Improving Software Floating Point Support” paper from the 2006 GCC Summit Proceedings for details.

On the verilog front, I have what I believe is a first pass at the Instruction Fetch and Decode (IF/ID) units. In order to test these, you actually need real code loaded into the simulated memory. Verilog provides a handy function, $readmemh(), that sucks ASCII hex codes from a text file into a register array (fake memory). The trick is that the input file has to be in a very special format. To that end, I’ve written a new BFD write-only backend called ‘verilog’ that generates this hex dump output. So now…

  $ moxie-elf-gcc -o hello.x hello.c
  $ moxie-elf-objcopy -O verilog hello.x hello.vh

…produces a useful hello.vh, which verilog can load directly into memory like so…

module memory();
  reg [7:0] my_memory [0:64000];
  initial begin
    $readmemh("hello.vh", my_memory);
  end
endmodule;

I just submitted this to the binutils list for review. Keep your daft fingers crossed!

And this means I’m just about to start testing my IF/ID units on real code.

Tags: binutils, gcc, newlib, verilog
Posted in moxie | View Comments

A Verilogical Place To Start *

Tuesday, April 7th, 2009

I’ve written my first bit of verilog tonight. It’s not much, really, but it’s a start. I’m using Icarus Verilog (iverlog) to compile and simulate the code. I also plan on using GTKWave to examine timing dumps from the iverilog simulator. Both of these tools are part of my development platform, Fedora.

Rather than plan everything out to the last detail, I’m going to wing it for a while and explore the language. To start with, I’ve decided to try to hack the core together as a simple pipelined processor consisting of the following four stages: Instruction Fetch, Instruction Decode, Execute and Write.

The first complication comes from Moxie’s long instructions. Moxie is not RISC processor, in that it does not have fixed width instructions that can be fetched in a single go. Most of the instructions are 16-bits, but several of them are 48-bits, the last 32-bits being some kind of immediate value. We’re going to have a 32-bit path to instruction memory, which means we may have to fetch twice in order to read a single instruction. This involves state machinery and some tricky back and forth between the Instruction Fetch and Instruction Decode pipeline stages. It’s taking a while to get straight in my head, so I don’t know when my next update will be.

* Blog entry title borrowed from this great book

Tags: verilog
Posted in moxie | View Comments

A Tiny Computer

Friday, March 13th, 2009

Lambda the Ultimate today posted a interesting blog entry on A Tiny Computer. It refers to 2007 paper by Chuck Thacker at Microsoft Research describing a tiny 32-bit processor. Appendix A of the paper includes the entire synthesizeable verilog implementation in just a page and a half of code! Here’s a direct link to the PDF: http://www.bottomup.co.nz/mirror/Thacker-A_Tiny_Computer-3.pdf.

I plan on using verilog for my initial moxie implementation. I’m told that it’s the clear choice from a tools perspective. There’s even a free software implementation already packaged for Fedora: Icarus Verilog. As far as eduction is concerned, I’ve mainly been using the two terrific books show below. Do you have any better suggestions? I’d love to hear them.

Now, however, I’m still debugging GDB’s interaction with qemu. It mostly involves watching remote protocol traffic, looking up the packet codes, and then trying to understand why the simulator is not behaving as expected. Good times…