I stopped by lab about a half-hour ago (around 8pm), but no one was there. So here's my plan:
Tonight, I'll be writing MIPS code at home that tests as thoroughly as possible the entire memory interface, meaning the cache, write buffer, and victim cache. As of right now, it appears the claim is that the mems (both inst and data I hope) correctly hold their inputs and/or outputs when stalls occur, so right now my tests will not extensively test this. If anyone thinks of anything that should be tested that I didn't say I'd test, let me know upon reading this post.
Tomorrow, whenever I wake up (which despite my best plans might not be until late morning or even early afternoon), I'll head to lab and run the MIPS I'll write tonight in simulation. Provided that works, or maybe even if it doesn't, I'll test it on board. If anyone plans on being in lab tomorrow during the day, reply to this post, so perhaps there can be more than one person present if bugs do come up.
That's my plan for the next ~24 hours.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bringing it to board has issues. Don't rely on that.
testCpu hasn't been updated to handle the latest incarnation of cpu.v which includes wires leading to the top for further debug.
Also, when you update from cvs, grab the workingVanilla revision so you have the non-developmental version.
"cvs update -r workingVanilla"
It takes about 1 hour to compile to board in cs150 lab, 152 was 40 - 50 minutes. I recommend testing extensively in simulation, but you'll probably need to use cs152's xilinx -> modelsim cause it seems to be the only one capable of loading the boardRam modules as opposed to the sram modules.
In reference to that, you should be using boardRam modules for running the simulations. Don't use the ram we can't take to board.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I stopped by lab about a half-hour ago (around 8pm), but no one was there. So here's my plan:
Tonight, I'll be writing MIPS code at home that tests as thoroughly as possible the entire memory interface, meaning the cache, write buffer, and victim cache. As of right now, it appears the claim is that the mems (both inst and data I hope) correctly hold their inputs and/or outputs when stalls occur, so right now my tests will not extensively test this. If anyone thinks of anything that should be tested that I didn't say I'd test, let me know upon reading this post.
Tomorrow, whenever I wake up (which despite my best plans might not be until late morning or even early afternoon), I'll head to lab and run the MIPS I'll write tonight in simulation. Provided that works, or maybe even if it doesn't, I'll test it on board. If anyone plans on being in lab tomorrow during the day, reply to this post, so perhaps there can be more than one person present if bugs do come up.
That's my plan for the next ~24 hours.
Bringing it to board has issues. Don't rely on that.
testCpu hasn't been updated to handle the latest incarnation of cpu.v which includes wires leading to the top for further debug.
Also, when you update from cvs, grab the workingVanilla revision so you have the non-developmental version.
"cvs update -r workingVanilla"
It takes about 1 hour to compile to board in cs150 lab, 152 was 40 - 50 minutes. I recommend testing extensively in simulation, but you'll probably need to use cs152's xilinx -> modelsim cause it seems to be the only one capable of loading the boardRam modules as opposed to the sram modules.
In reference to that, you should be using boardRam modules for running the simulations. Don't use the ram we can't take to board.