grantslape/cs3339-mips32

5 stage, pipelined MIPS32 processor in myHDL and Verilog

cs3339-mips32's Issues

Byte Addressing vs. Word Addressing

Typically in the MIPS architecture instruction memory and data memory come from the same general main memory. For the purposes of this pipeline however, the instruction memory and data memory buffers are separate.

This creates an issue with how we access instructions. We increment the PC by 4 each cycle in the pc_adder, but the next sequential instruction differs in address by 1.

I believe the fix here will be to take actual_index = incoming_instruction_address % 4 inside the instruction memory itself, since that module is what differs from the typical architecture.

This will involve updates to the following:

• inst_mem.py
• inst_mem.v
• inst_mem_tb.v
• test_inst_mem.py

TestInstMemPython fails intermittenly

The build fails unit test TestInstMemPython seemingly randomly. This is difficult to reproduce, which seems to be caused by the PRNG not being seeded in a consistent manner.

======================================================================
ERROR: testInstMemDynamicPython (test.test_inst_mem.TestInstructionMemory)
Testing regular operation Python
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/app/test/test_inst_mem.py", line 45, in testInstMemDynamicPython
    Simulation(stim, self.dut).run(quiet=1)
  File "/usr/local/lib/python3.6/site-packages/myhdl/_Simulation.py", line 152, in run
    waiter.next(waiters, actives, exc)
  File "/usr/local/lib/python3.6/site-packages/myhdl/_Waiter.py", line 172, in next
    clause = next(self.generator)
  File "/usr/local/lib/python3.6/site-packages/myhdl/_always_comb.py", line 83, in genfunc
    func()
  File "/app/src/python/inst_mem.py", line 25, in logic
    inst_out.next = raw_mem[inst_reg//4]
IndexError: list index out of range```  

Main Issues

• Verilog Main still doesn't work. Possibly hierarch design to figure out where the issue is. converting project to 0.10 style fully may help with this as well.

Support for Arbitrarily Long Simulations

Issue

Currently our processor is limited to 1M (2 ^ 20) instructions via a static array size. Our project requirements need us to support an arbitrarily long simulation, with numbers in the several million being thrown around.

Given these parameters, eventually we are going to reach the last instruction in our array, and we need to ensure that we do not step out of bounds and cause the simulation to fail.

Implementation

We can get around this by always generating an unconditional jump to the beginning as the last instruction. in assembly this instruction would be j 0x0

This will work as follows:

• When we shift left 2 the jump immediate, it goes from 26 bits of 0 to 28 bits of 0.
• We only have 2^20 instructions so the top 12 bits of the program counter are never used. This means that the top 4 bits that we concatenate with the 28 bit address immediate is always 0000
• Altogether this gives us a memory address of 0x00000000 which when we floor divide by 4 gives us the index of the first instruction in memory, 0.

Supporting JAL

We're going to have to add a pathway for the 32 bit PC+4 address to route into the Reg WB pathway, and set the register to write back to as $ra to support the jal Lbl style instructions. We can achieve this by activating writeback reg signals and adding the value of this immediate to zero, or otherwise dropping it into the Reg WB pathway after the ALU output.

Main Driver Structure

Summary

Here's where we can hash out the main driver structure. We had some good conversations in class, and here is where we can turn those ideas into a functioning implementation. Given the time we have left, I think that we should start minimal with just the necessary checks and then build up other assertions that would be nice to have.

Driver Structure

I'm envisioning a script that will run on the command line, and will use the instruction generator and config file to generate instructions. If the config file is malformed, default values will be used.

We don't want to end execution if there is a mismatch in the finished product. We should probably print it out and/or log it to a file for analysis. This may benefit us as we inevitably run into issues building the driver.

Some good resources from the myHDL docs, obviously ignore the @block decorators: http://docs.myhdl.org/en/stable/manual/structure.html

Other Modifications

• The instruction generator config should be used as a generic config file. we should add a key/value here for the number of cycles the simulation should run for. Then we can pipe that directly in as the duration keyword argument of Simulation.run()
• The instruction generator will also need documentation on accepted values for config values as well as how to run it standalone. This will be @TitansMM

Remove the example.txt file in the bin folder?

Is the example.txt file needed for anything? if not this is just a note that we should probably remove it soon.