To make this work, we will need a good plan of attack and I will need everyone's cooperation to make it happen. I think we can do it.
Alan, since you are the expert in memController, I will need you to clean up memController of the unnecessary logic using the async fifo. I briefly modify memController this morning to interface with the wideBuffer. I will probably rename it wideBuffer. Basicly wideBuffer should be emptied out once it getss full. It should send a signal of 1 proc cycle to the cache. I am sure you will find a lot of wiring errors and unneccary logic, since I did it in a hurry this morning. I want you to make it run in simulation and get rid of all the wiring errors and minor bugs.
Brian, I need you need to write test cases to test the cache and memory system. The test cases should start out from simple cases to more nasty cases. It should produce a verifiable result at the end, so it's easy to check for correctness. It should use the same register and lw or sw or beq or whatever else you can think base on that value, so if it didn't follow the correct behavior, it will output an incorrect result, much like the test cases they gave us.
Jason, can you please hook victim cache inside twoWayCache and write a test bench for victim cache? The victim cache behave the same as the regular cache, except it's much faster the regular 2 way cache. In fact, I should be able to replace twowayCache with victim cache, it will just miss a lot more.
I wonder how fast will our new processor run with the greatest and finest improvement, can we beat their clock cycle number if we can make it run in simulation?
Brandon, while driving home I thought of one thing that we didn't simulate very well. We need to simulate the clock the same way we will have it on the board. I suggest we get rid of dll, we can do our own clock divider by using a counter or by using some registers as we learn from 150. We need to simulate if the processor clock and dram clk are both 27 mhz, and the dram clk is always 2 ns behind the posedge of processor clk. This should expose a lot of bugs if we add the approriate delay in all our simulation models.
The dram clk is always a constant multiple of processor clk with some delay due to the combinational logic.
I will be monitoring and check this forum frequently and my aim is mikejmc415.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's not a problem it's just we can't simulate dll very well in simulation. I will rather simulate something I know exactly what's going on. Right now, we aren't exactly sure the relationship between the 2 clks on the board. It can be a potential problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To make this work, we will need a good plan of attack and I will need everyone's cooperation to make it happen. I think we can do it.
Alan, since you are the expert in memController, I will need you to clean up memController of the unnecessary logic using the async fifo. I briefly modify memController this morning to interface with the wideBuffer. I will probably rename it wideBuffer. Basicly wideBuffer should be emptied out once it getss full. It should send a signal of 1 proc cycle to the cache. I am sure you will find a lot of wiring errors and unneccary logic, since I did it in a hurry this morning. I want you to make it run in simulation and get rid of all the wiring errors and minor bugs.
Brian, I need you need to write test cases to test the cache and memory system. The test cases should start out from simple cases to more nasty cases. It should produce a verifiable result at the end, so it's easy to check for correctness. It should use the same register and lw or sw or beq or whatever else you can think base on that value, so if it didn't follow the correct behavior, it will output an incorrect result, much like the test cases they gave us.
Jason, can you please hook victim cache inside twoWayCache and write a test bench for victim cache? The victim cache behave the same as the regular cache, except it's much faster the regular 2 way cache. In fact, I should be able to replace twowayCache with victim cache, it will just miss a lot more.
I wonder how fast will our new processor run with the greatest and finest improvement, can we beat their clock cycle number if we can make it run in simulation?
Brandon, while driving home I thought of one thing that we didn't simulate very well. We need to simulate the clock the same way we will have it on the board. I suggest we get rid of dll, we can do our own clock divider by using a counter or by using some registers as we learn from 150. We need to simulate if the processor clock and dram clk are both 27 mhz, and the dram clk is always 2 ns behind the posedge of processor clk. This should expose a lot of bugs if we add the approriate delay in all our simulation models.
The dram clk is always a constant multiple of processor clk with some delay due to the combinational logic.
I will be monitoring and check this forum frequently and my aim is mikejmc415.
As of now, I see nothing wrong with using the dll. Just because Greg's group doesn't use it, I can't see any reason to get rid of it.
It's not a problem it's just we can't simulate dll very well in simulation. I will rather simulate something I know exactly what's going on. Right now, we aren't exactly sure the relationship between the 2 clks on the board. It can be a potential problem.