TMP: Master Plan

I spent a lot of time debating which ISA to base this on. MIPS has the advantages of being easy to explain, being a good example of RISC, and I’ve implemented large sections of it before for class. However, that last bit makes me wary, because it means that more students in a similar situation will need to implement a MIPS-like processor. I don’t want to just give away final projects here, so anything resembling MIPS enough to allow people to literally copy large sections of the code I release is undesirable. The other option that comes to mind is something based on ARM’s ISA. ARM is well-established and is a very common platform for embedded systems, but at the same time. So I’ll use a handful of the really interesting features available in ARM’s ISA, such as conditional execution of instructions. Finally, it’s never fun to blindly implement someone else’s ISA, it’s much more interesting to create your own design, so ultimately I will draw on both MIPS and ARM, as well as my own intuition, and create something that incorporates what I think are important features from both, while at the same time lending itself well to explanation of key features.

The Master Plan, then, loosely resembles the following, with many stages happening in parallel:

• Design Instruction Set Architecture (ISA)
  • Should be Load-Store and adhere to basic RISC principles.
  • Should make it easy to explain and demonstrate basic design principles, while allowing for powerful features and extensibility.
• Create a Simulator
  • Written in C
  • Will require an additional, simple assembler to convert instruction mnemonics to a binary execution image
  • Initially command line based (or ncurses frontend), with the possibility of adding a GUI if it seems worthwhile
• Design ALU
  • This part, and everything leading up to the actual processor implementation connecting everything together, can happen in parallel with simulator programming
• Create Register File
• Miscellaneous Processor Structures
  • Memory interface (initially, an ideal memory, so this will just decode/translate requests)
  • Forwarding/Hazard Detection and Handling
  • Pipeline Registers
• Assemble the Microprocessor
  • This includes pipelining
  • Support for multiply and divide instructions
    • Requires significant pipeline extensions and an additional parallel processing unit
  • Support for interrupts
    • This is necessary for implementing any reasonable, albeit basic, operating system
    • Also necessary for I/O, which is quite reasonable for anyone using integrated FPGA development boards (which often have a lot of I/O and the necessary support circuitry already implemented)
    • Not covered/explained often in microprocessor courses, yet integral to the functionality of all modern computers (interrupts are used to make system calls in both Windows and Linux).
  • A basic OS
    • Flat memory model, without memory protection (dangerous, but simple)
    • Cooperative Multithreading (because it’s easy to implement)
    • Implements basic system calls to provide common sets of functionality for user programs

  With this list of central goals complete, a few additional features seem quite reasonable and would serve to be important in understanding the functionality of a much more advanced processor. Therefore, these are secondary targets, to be completed once the basic design is done:

  • Instruction and Data Cache
  • Branch Predictor

  I’ve even got some genuinely crazy ideas, but I’ll keep them to myself for now (most fall into the realm of “not existent on 99% of available commercial microprocessors/microcontrollers”). If this can be established as a platform on which I can test less mainstream concepts and designs, then this will be a success for me.

  All that said, I may have missed a few features that won’t be apparent until the time comes, but I think this is a good starting point. Next time, the ISA will be unveiled (hopefully a week), or at least the first revision of it. Design flaws will always become apparent through actually working with it (something a lot of software library designers haven’t realized, but I digress), and so things will be amended as time goes on.

  Like

  Unlike