Samuel A. Falvo IIJust a quick update before I rush into the office.
I've been working on the KCP53010 CPU's pipeline stages on and off over the last couple of weekends. Overall, I'm happy with the results so far. You might say that the pipeline fully recognizes STORE and OP-IMM instructions, although supporting more than these (especially LOAD, OP, OP-IMM-32, and OP-32) is quite easily implemented with only a handful of Verilog lines of code.
Last night, I wrote the very first lines of code that integrates these different stages together into a real pipeline. It does not work yet, but its current behavior is very promising indeed. I haven't had the time to implement a real integration test for it yet, so I just relied on the RESET behavior and how it pipes a NOP (ADDI X0, X0, 0) instruction through the queue. After looking at the waveforms manually, I'm pleased at the results so far.
Some things which need to be done include (but isn't limited to):
- Clock the register file's source addresses on the falling clock edge, instead of on the rising edge. ALTERNATIVELY, take the source addresses from the instruction register's inputs instead of from the instruction register itself. Either one of these approaches allows me to deliver the contents of the register file concurrently with the instruction decoder outputs, thus letting me keep a 5-stage pipeline. Otherwise, I'd need to introduce a separate "register fetch" pipeline stage.
- Move SEL_O signal generation into the memory stage (load/store unit). Right now, it's an explicit input; however, since its value depends on the output of the ALU in the execute stage, there's no way to precompute it at any earlier stage.
- Make use of BUSY_O and related pipeline stall signals to control instruction flow through the pipeline. Right now, instructions just flow synchronously with the clock.
- Implement register bypass/feedback logic. This would prevent pipeline stalls or erroneous computations when the source of an instruction I comes from the destination of the previous instruction I-1.
There's a lot of work that needs to happen yet; but, I think I can swing it. I just need to take this slowly, one step at a time.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Do you use textual debug output from verilog at all? I wonder if that would help visualise the pipeline behaviour.
Are you sure? yes | no
I do not; I use gtkwave and trace well-known bit patterns through the system. Once I have a visual confirmation that things work more or less the way I expect, I then take the effort to encode my expectations as assertions (in the TDD sense, not the formal methods sense). That way, if I change some code and it breaks some expectation from another module, the whole build breaks with a noticeable error trace.
Are you sure? yes | no