Close

Time flies when you accomplish nothing of value.

A project log for Kestrel Computer Project

The Kestrel project is all about freedom of computing and the freedom of learning using a completely open hardware and software design.

samuel-a-falvo-iiSamuel A. Falvo II 07/13/2016 at 16:000 Comments

Well, it's July, and the 4th RISC-V workshop is well underway. I could not attend as it conflicted with my planned vacation, but it is a constant reminder that I really, really wanted to have working hardware by at least November. I can honestly say, that's not going to happen. Not even close.

Thanks to a total disaster of a chain of unfortunate events relating to bringing up the Kestrel-3 in hardware, I'm basically left in a position where I was when I first started hacking the Kestrel-2 years ago: zilch. I'm literally starting the project, essentially, over from scratch. In the process, I'm building everything up from scratch.

Here's a recap of my misfortune:

  1. Xilinx Webpack ISE refuses to license on my platform. Thus, I cannot use my fully functional Digilent Nexys-2 board as a development platform. Ironic, really; the last thing I flashed it with was the bitstream for the Kestrel-2, so in essence, it's now stuck as a Kestrel-2. (And, no, I cannot run Vivado; this product does not support the XC3S1000E).
  2. I couldn't even get to the point where I could download Linux compatible Altera IDE software from their website, so that rules out using Altera-based products. Plus, depending on the website you visit, the programmer for these devices are at least as much as the dev boards themselves. No thanks.
  3. So that leaves only iCE40 devices and the Yosys toolchain (which works spectacularly, I might add). No devices using this FPGA even compares, flatly, with the most minimal FPGA-based-computer dev boards on the market (even the Oberon Station!), so I was left trying to build my own. Inspired by the RC2014 computer, I started designing a custom backplane and set of CPU and I/O boards that meets my needs. I placed an order for the backplane. When I got it, that order was severely botched, and I need to basically redesign the backside of the board, due to Gerber-rendering bugs on the part of their fabricator. Still a bit miffed that *I* have to compensate for this, but whatever. I've been meaning to do this for a week or two now, but goddammit, life just won't let me! (Sorry, OSH! It's coming, I promise!)
  4. To serve as a stop-gap interim solution, I've placed an order for a icoBoard 1.x with 1MB SRAM installed. However, I haven't heard back from my contact there yet. However, even if this board arrives, it will still lack all the components I need to make a functional Kestrel-3 computer with. A single iCE40HX-8K will not fit everything I need to make a Kestrel-3 -- that much is certain. It also won't have any flash ROM to run eForth out of, and the RAM is 1/16th that in the emulator, so I'll need to create custom images just to run on this restricted board. At an estimated cost of 120 EUR, it's quite expensive for me. Recall, I wanted the total cost of Backbone, plus three FPGA plug-in cards for it, to not exceed US$200. So, yes, getting this board is an act of desperation for me.
  5. The CPU microarchitecture is, I'm confident, now sized appropriately for the iCE40HX-4K FPGAs, although at the expense of it never being portable to wider bus widths. However, I've been pretty confident about things before, so we'll see where this new, hard-wired microsequencer takes us. With the register file taken out of logic cells, this leaves the ALU and supporting circuitry to contend with. I predict I'll need to dedicate one entire FPGA just to the CPU. This is fine; it's why I created the Backbone project, to serve as a backplane for connecting several different FPGA circuits together which cooperate and comprise the total Kestrel-3 computer.

The CGIA is currently on-hold, as I work through the CPU. I thought at one point that the CGIA was the highest risk device in the system; only when I discovered how badly I botched the CPU sizing estimate did I realize how wrong I was. Yes, the CGIA will also be a big circuit to fit into an FPGA; I'll probably need to move the line buffers into block RAM as well. However, looking at MGIA components leads me to believe that CGIA won't be nearly as much of a monster as the CPU, so I'm confident working on that after I get some more CPU work invested. I want evidence that the CPU design is realizable and practical before going back to the CGIA.

If worse comes to worse, I can just synthesize an MGIA in the mean-time. The emulator already provides MGIA support. This is perhaps the best decision I've made so far.

The KIA and GPIA will be used as-is. Since the Kestrel-3 will run on a 16-bit wide data path, these do not need modification. I do need to make changes to the emulator and system software though: I got register address offsets wrong. E.g., the KIA addresses appear at $0100000000000000 and $0100000000000001, when the true addresses are $0100000000000000 and $0100000000000002. The e emulator provides a 64-bit GPIA variant, while the real computer will continue to use the 16-bit variant. Whether or not I can play address decoding tricks with the GPIA to make it "look" like a 64-bit equivalent part remains to be seen. I suspect it's possible (unlike with the KIA).

So, yes, I'm in a bit of panic right now, as it looks like I'm going to blow my deadline like an overfilled balloon. :/

Discussions