- Add the UART receiver to the microcontroller
- Instruction set: add support for subroutines. This will require 2 new instructions and a stack.
- Instruction set: more registers and addressing modes? I don't want to overcomplicate the internal structure, but indexing and/or indirection would be useful. Think I'll wait until I have a definite requirement.
- Bootloader: so I can run new code on the board without rebuilding the processor.
Another quick update, while I wait for dinner.
The UART receiver is working in stand-alone mode. It's been tested at 9600/8N1 and 115200/8N1 speeds, and all seems good. There are lots more things I want to do, so perhaps a quick list is in order: Once the above is accomplished I envisage a code cleanup and possible redesign of the instruction set and the internal architecture. I know I don't need maximum efficiency and speed at this point, but pipelining would be cool. But that's for another day.
4 Comments
A partial screenshot, just to prove that one can write an assembler in Microsoft Excel.
The assembler supports labels for the branch and jump instructions and quite extensive error checking, including highlighting of:
There's even an ActiveX control that writes the output data to a file as raw bytes, plus optionally converts the raw bytes into an Intel HEX format file via a free 3rd party bin2hex utility. The next evolution for my CPU will be the introduction of extra "addressing modes" for certain OpCodes. So far I can only load the accumulator with actual values ("immediate") or get from a specified memory location. There is no indirection or offsetting available. There's also currently only a single register, the accumulator. It will be interesting to see how easy to is to implement these extensions in the assembler. The VHDL won't be a problem! As described in the previous post, the internals of the CPU changed. It now uses an Altera "Megafunction" called "altsyncram" to implemnent the onboard code ROM. An advantage is that the initial contents, i.e. the program, can be loaded at synthesis time from a separate file.
Two file formats are supported - Altera's Memory Initiation File ("MIF") and industry-standard Intel HEX format. Both are quite easy to use but the simulator only supports Intel HEX, so I went with that. Quite a bit of progress, at least up the learning curve, leading to the electronic equivalent of the ubiquitous "Hello World!" program, flashing LEDs. Time to start interfacing with the real world. This means that the CPU needs the ability to write data out and read data in. Put another way, it must be able to set pins How about:
I'm not convinced that the above is particularly flexible. For instance, I'll probably want to read and write whole bytes. But this highlights one of the huge advantages of using an HDL such as VHDL. It is very quick and easy to add, remove and modify features based on real world experiences. Of course, the proper approach is to start with a set of requirements, but that smacks far to much of my day job ;-) What do I do next? Decisions, decisions. I hate making decisions, too much like hard work ;-) This blog stalled slightly due to external interrupts (Note to self - add interrupts to the CPU?), including a promotion at work that has me temporarily juggling two roles while we effect a handover. I The other aspect is the CPU itself. So far, its only existed as a simulated model. I do have an FPGA dev board, with input and output options ranging from switches & LEDs through to VGA, RS232 and an SD card slot. I'm sure that, as I start to target these features, the CPU will evolve. For instance, the instruction set is currently somewhat small. Whilst it is possible to have a Turing-complete system implemented using only 8 commands, it's certainly not "user friendly". Then again, if I wanted "user friendly" I wouldn't be doing this in the first place. So, dear reader, I promise that I will post more updates. Soon. Ish ;-) |
AuthorJust another hobbyist starting out with FPGAs. Archives
September 2013
Categories
All
|