joanlluch wrote:
I am curious about what are you using for your instruction decoder. It looks to me that the typical ROMs are totally out of specs for your speed requirements, so what are you using instead?
Yes, ROM is out of the question. It’s a choice between using GALs or Decode RAM. The time-critical bit is to figure out the Addressing Mode of the opcode so we can know which registers are to be loaded into the next pipeline stage. I am using a 32-bit wide RAM for microcode and quickly running out of control bits. A second microcode RAM would tilt the decision since I will have lots of spare control bits there. I might as well use them for decoding the opcode. An advantage of using RAM is that it will then be much easier to accommodate alternate instruction-sets (more on that later).
Quote:
(It would also be great if at some time you eventually post a CPU diagram showing the modules you listed for your critical path calculations)
Yes, agreed ... it’s on my To Do list.
Quote:
I'm intrigued about self modifying code in relation to your cpu implementation, because I suppose that it is only problematic if it happens to an instruction that is already in the pipeline, which should be relatively rare in real life code. So maybe it can generally be ignored (?). How this subject fits in your pipelined processor?, are you supporting this in some way?
Remember that this is a
microinstruction pipeline so the issue does not arise. Self-modifying code is a real nuisance in an
instruction pipeline, where the pipeline has to be flushed if self-modifying code is detected. For a more detailed description of a 6502
instruction pipeline, see
this thread.. That design is a closer analogue to a traditional RISC pipeline, and self-modifying code was a problem (not only in the Dormann suite but also with FORTH and BASIC. I chose to add NOPs into the instruction stream manually rather than instrument the pipeline to detect self-modifying code).
Edit: Here is a relevant post on the thread that you might find interesting. It specifically discusses Self-Modifying Code (SMC).