A microprocessor built in verilog code
Niranjan Ramadas
Vikas Khurana
Sunwoo Kim
Our testing strategy essentially begins with smaller modules and works upwards towards the final pipeline. Each small module was tested and synthesized individually. Each module, when tested, used a separate testbench that used registers for inputs and measured the outputs using wires. After the individual modules were tested in this fashion, we grouped a few modules and tested the group. We then periodically added modules into this group and re‐tested it until the module group became the entire pipeline. At this stage, we started using the test programs provided in the test_progs folder to test the whole pipeline.
We used several tools to find bugs. The simplest was to add display statements to the code to dump the value of registers into an output. This proved especially useful when trying to determine a value inside a register array, like the PRF or ROB. In addition, we modified our testbench.v file to display the cycle count in our writeback.out file. That way, when there was a difference in register values, we knew the cycle at which it happened. We also used the waveform viewer that came with the VCS compiler. When used in conjunction with the cycle count information provided in the writeback.out file, the waveform viewer helped us pinpoint exact outputs or inputs that were incorrect.
After we passed all the test programs given, we modified the virtual cycle time to values between 7ns and 100ns and re‐tested everything.
At submission time, all the features of our processor worked as planned. However, there were several issues that we encountered along the way. The following are important bugs and issues we found, and our fixes for them.
Ships Passing in the Night
‘Ships passing in the night’ was a big problem for us. We added logic to fix the ‘ships’ problem in the LSQ, the ROB, and the RS. However, there was an additional location that we had not anticipated ships to be a problem in. When an instruction leaves the rename/issue stage, the registers are renamed, and all receive values from the PRF. This instruction is then stored in a pipeline register. In the case of a stall, these values are prevented from leaving their pipeline register and entering the out‐of‐order core. This presented a problem in a very specific case. When there was an instruction stuck in the pipeline register whose register values are updated by the CDB, the new values would not enter the out‐of‐order core. Usually, we would check for ‘ships’ when something is being issued into the core. So we expected that if values change while an instruction was entering the out‐of‐order core (OOC), the modules that grab that instruction would simply grab the values from the CDB instead. However, in this case, the instructions were being held and not allowed to enter the OOC, but the values still changed. So, we needed a sort of pipeline register ‘ships’ implementation. We solved the situation by adding logic to the pipeline register.
Critical Path and Clock Cycle
When we first synthesized our pipeline, our clock period was around 8ns. We thought this ideal, and so never bothered with our critical path. However, after adding some more complexity to our pipeline to improve our CPI, our clocked period jumped drastically to 10.3ns. We expected the problem to be with some of the new modules we added. In particular, we believed the non‐blocking cache was the cause of the issue. No amount of code changing, however, seemed to fix the problem. When we re‐examined the synthesis outputs, we realized that the critical path could be in our multiplication unit. We altered the multiplier to use 8 stages instead of 4, and our clock period was once again around 8ns.
All team members contributed significantly to the overall design. Exact contributions are given below:
Vikas Khurana (33%): Caches, Execution Units, Rename/Issue, CDB, Fetch (33%), Decode, Test & Debug (33%)
Niranjan Ramadas (33%): LSQ, RS (50%), ROB (50%), Pipeline Module, Fetch (33%), Test & Debug (33%)
Sunwoo Kim (33%): RS (50%), ROB (50%), BTB, Out‐of‐order Core Module, Fetch