OZ-3: General Update

Well, I can’t say I’ve had much more luck with the hardware testing, but I did create a second version of my assembler that allows for much more readable, capable code.

A couple of the main features of the assembler that I wanted to touch on were that I included labels and a lot of syntax/error checking. The assembler takes two passes at the code, one for collecting the labels and the addresses they represent, and the other for going through all of the instructions and generating their machine code. While coding this, I was toying with the idea of how to easily include things like subroutines in the assembly code.

OZ-3: The Assembler and First Hardware Test

So, I took a break from fussing around with the memory bus controller to write an assembler for the OZ-3. I wrote it in C++, and it will make my life much easier (I really didn’t enjoy coding purely in machine code). As of yet, it doesn’t check for errors at all, and the output is machine code formatted so that I can just copy and paste it into my Flash programmer’s VHDL file. I made it so comments can be added in, both in line with instructions and on their own line, denoted by a ‘#’ character. One major thing that I’d like to add that I haven’t yet is the ability to set labels, so I wouldn’t have to mess with jump and branch addresses. At some point in the program, I could say “lbl: FRED” and then when I say “jp FRED” the assembler would figure out where in the program the label “FRED” represents, and set the jump address to that place in the program. This would make for much easier editing of code, making things a bit faster for me. Jump and branch addresses have to be manually figured out right now.

OZ-3: The Instruction Decoder

The instruction decoder was probably the most error-prone part of the OZ-3, and, to be frank, I’m surprised I got it done. During the writing of this stage, I learned more about the importance of commenting your code and updating version logs than during any other code I’ve written. There are comments absolutely everywhere; just about every line has an explanation, although some of them aren’t that great.

OZ-3: A Pretty Big Update

So, it’s been about a month since I last updated my blog, but that’s not to say much hasn’t gotten done. I’ve been in the “work on it, don’t talk about it” mode with the OZ-3, and I’m very close to starting hardware tests. The next few posts will all be on progress in the last month, and what I can remember about issues I ran into while coding these pieces.

The big things I got done were: the instruction decoder and all the associated testing, I created a test environment of sorts that had simple instruction and data RAM modules that I used to test more complex program structures in simulation, and I just finished the memory bus controller yesterday. Or would that be today? I was up pretty late.

Ben Oztalay

OZ-3: MEMIO is Complete

I finished the memory and I/O stage the other day, and I wanted to get a post up on it before I go too far with the instruction decoder.

In the code, I have five main processes, then a couple registers instantiated for the two-stage buffer for control signals coming from the instruction decoder. As I said, I would have three processes for handling three different tasks: input/output pin management, input/output port management, and memory control. The two other processes are a data mixer and a multiplexer that goes at the end of the stage to control which data get sent to the writeback stage.

OZ-4 Speculation

I know that I have yet to finish the OZ-3, but I couldn’t help but to start looking further down the line.

I had aspirations for the OZ-3 that I realized it simply isn’t capable of. First, I wanted to have it run a basic OS with a command-prompt-based interface, with a keyboard as the input. It would use the flash for permanent storage–both programs and data–and run the programs off of its RAM. The problem with the first one: it isn’t powerful enough. Without things like an instruction and data cache to let it run faster than the memory, or a stack, the finished product would be crippled and slow. The issue with the second has to do with a couple things: that the OZ-3 has no way of pulling data from the Flash and putting it on the RAM, and also that the memory resources don’t exist. I would want separate data and program memory for the sake of speed and simplicity (it needs an instruction every cycle, but stores and reads data every so often. A complex memory controller would have to be made, and it would be slow). But I don’t have the ability to do that with my development board.

OZ-3: Memory Troubles and IF Stage

In the past couple of days, I finished the instruction fetch stage and moved on to the memory stage. Before I get into the memory side of things, let’s get into instruction fetching.

So, I explained the issue with 16-bit Flash and 32-bit instructions. My first fix was to clock the instruction fetch stage twice as fast as the rest of the processor, which is a viable solution. Either way, though, I’m going to lose half the productivity of the OZ-3. I’ve looked further into making my own expansion board with another StrataFlash module on it, and that also seems feasible. For now, though, I’m going with the method of doubling the clock speed of the IF stage.

Intel StrataFlash Programmer

I finished the programmer for the on-board Intel StrataFlash on my FPGA development board today. It was much more of a hassle than I thought it was going to be. Digilent, the manufacturer  of my FPGA development board, had done a fantastic job on their user manuals on every topic except for the memory resources, which was disappointing. I had to dig my way through a couple datasheets before I got all the information I needed to operate the Flash device.

Coding Has Begun

I began coding certain elements of the OZ-3 in the last couple of weeks. It’s been going alright; I had to look back at my Logisim schematics to remember just how some parts work! I coded the smaller components, such as generic falling- and rising-edge triggered registers that can be sized according to their purpose. Also, I’ve done the ALU and condition block. Unfortunately, since I made up the schematics, I’ve forgotten the reasons behind various buffers that keep everything timed correctly (i.e., an instruction’s data doesn’t get to a stage in the pipeline too soon). This caused confusion on my part when programmed these buffers into the EX and WB stages.

Test CPU 1 – FPGA Implementation

As I mentioned in my previous post, the next step that I wanted to take after designing the OZ-3 in simulation was to design and implement a simple CPU in an FPGA, just to get used to complex systems. Ironically, a couple days before I made that post, I had finished that CPU. It’s called Test CPU 1.

I said “simple CPU,” and by that, I mean a single-cycle, 16-bit RISC. The instruction set is ten instructions total; only the essentials. It doesn’t have any input capabilities, and all output capabilities are in 32 individual output pins, so data transfers would be rather difficult. Also, there are eight 16-bit registers. It can address 256 bytes of dRAM, and programs are limited to 4 MB, organized as 2Mbits x 16bits. The ALU is capable of addition and subtraction only, and it can only branch on zero. Here’s the full instruction set: