I modified cpu.v's PC register to use varReg2 which resets to -4. This helps us on the board where it skips the first instruction after reset.
Right now its a cosmetic flaw that we show 0xfffffffc.
However, in Jason's testHazardFull1.v which is the current version of instBoardram, our simulator and board both die at line 0x1b8, the beq comparison.
Brian, if you can see why its doing it in simluation, and fix it, it should be fine on the board. Right now, the board mimics the simulator pretty well.
As a note, Jason should've scheduled our checkoff at 4pm. Be there, or we're dead for real. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We never tested reading out of 0xfff8 which is the io INTO the board.
That might be a problem.
Here's a description of the dip switches. With Highest priority first.
~SW10[8] outputs what we're placing into the IO.
SW10[1] controls single step mode or not.
SW10[2] toggles between showing internals and IOOUT.
While sw10[2] has the iO out being displayed. SW7 toggles between DP0 and DP1
While SW10[2] is low, sw10[3] switfches between PC and instruction coming in at that time.
SW6 is reset, SW4 is step, SW8 is break.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
did we try to insert sw statement to figure out the value of $12, before the final loop.
We need to isolate and identify where the problem is.
Is the problem in the io? Or is the problem in our forwarding, branching or stall logic? Is there is any bug, it will be our stall or dataForwarding, since we know our basic datapath works fine, and we didn't test hazardDetect and dataForwarding rigourously as we intend to. We also need a test bench to test io.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I modified cpu.v's PC register to use varReg2 which resets to -4. This helps us on the board where it skips the first instruction after reset.
Right now its a cosmetic flaw that we show 0xfffffffc.
However, in Jason's testHazardFull1.v which is the current version of instBoardram, our simulator and board both die at line 0x1b8, the beq comparison.
Brian, if you can see why its doing it in simluation, and fix it, it should be fine on the board. Right now, the board mimics the simulator pretty well.
As a note, Jason should've scheduled our checkoff at 4pm. Be there, or we're dead for real. :)
Ok found bug in testHazardFull1.v, Jason's beq's registers were not the right value.
Also fixed a bug in monitor, RegB was getting RegA's value.
Now its the mem0 thing, so if we can figure out a good fix, besides the -4 thing.
So as of now, its just the mem0 thing.
We never tested reading out of 0xfff8 which is the io INTO the board.
That might be a problem.
Here's a description of the dip switches. With Highest priority first.
~SW10[8] outputs what we're placing into the IO.
SW10[1] controls single step mode or not.
SW10[2] toggles between showing internals and IOOUT.
While sw10[2] has the iO out being displayed. SW7 toggles between DP0 and DP1
While SW10[2] is low, sw10[3] switfches between PC and instruction coming in at that time.
SW6 is reset, SW4 is step, SW8 is break.
Bug as of now, is corner.s which they provide.
We pass simulation and die on the board.
did we try to insert sw statement to figure out the value of $12, before the final loop.
We need to isolate and identify where the problem is.
Is the problem in the io? Or is the problem in our forwarding, branching or stall logic? Is there is any bug, it will be our stall or dataForwarding, since we know our basic datapath works fine, and we didn't test hazardDetect and dataForwarding rigourously as we intend to. We also need a test bench to test io.