Later we may decide to start up the cpu that we will implement automatically and execute code that is stored in a rom, but for now the ability to inspect memory and start programs from any location is a big advantage when developing the cpu.
Monitor commands
The monitor itself as implemented in hardware can be very simplistic as it will be augmented by a more user friendly program that acts like a front end (in Python, like we did for the puck cpu on the iCEStick). It will offer chiefly these three commands:- load, to fill memory locations with bytes,
- dump, to show the contents of memory locations,
- exec, to execute machine code at a given location.
The LOAD command is followed by as many bytes as specified in the LENGTH field. The ADDRESS field is 24 bits, which is way larger than the block ram we will be using at first but later we may want to add the 128KB single port ram on the iCEbreaker board and may even the flash memory so it is a good idea to allow for some expansion. The cpu will be big endian so that is the convention we use for the ADDRESS and LENGTH fields as well. For the EXEC command the LENGTH field is interpreted as an arbitrary value that will be made available at memory locations 0 + 1
State machine
The monitor program will be implemented with a state machine as shown below. Currently I have implemented just the DUMP and LOAD commands, the EXEC command will follow as soon as I have implemented a bare bones cpu.
The state machine is depicted in the diagram below. Note that all six command bytes will be echoed and the extra wait state in the DUMP branch is necessary because the UART core I use will overrun my transmit line even when the code carefully watches the is_transmitting flag. The problem could also be caused by something on the receiving end of the line of course but adding a few wait cycles between every character solved the problem without too much hassle.