Fixes bug 203 and linux/ImperasDV mismatch at 571M instructions

Created by: rosethompson

• Trying to figure out why the parameterization slowed down modelsim so much.
• Updated a large number of the source files to use parameters rather than `defines. Based on Lim's work. So far there is no simulation slow down.
• More parameterization. Copied Lim. Still no slow down.
• More parameterization. Based on Lim's work. EBU, IFU (except bpred), and IEU done.
• MDU and hazard unit now also parameterized. Based on Lim's work. Again I want to clarify this their work. Not mine. I'm just doing this because the merge had an issue.
• Partial parameterization into mmu.
• PM(P/A) checkers parameterized based on Lim's work.
• Updated mmu's tlb and hptw to use Lim's parameterization.
• Progress on LSU.
• PMA checker's address decoder is now parameterized. I did not see bit slicing in Lim's code. I'm not sure how they got around this issue.
• Subwordread now parameterized.
• Completed LSU parameterization based on Lim's changes.
• The privileged unit is parameterized using Lim's method.
• Update top level parameterized. Simulation slowed down to 4.5 minutes.
• I think I've solved the slow down issue. Parameters can't be mixed with cvw_t and other types.
• Parameterized fpu's unpack and fma using Lim's method.
• fdiv is now parameterized using Lim's method.
• Finished fpu parameterization using Lim's method.
• Got the branch predictor parameterized using Lim's method. Also had to add a global enum included in both cvw.sv and the configs which defines the branch predictor types. This should be synthesizable, but I'll need to double check.
• Uncore is now parameterized.
• Possible fix for Linux bug and bug 203. ImperasDV mismatches in linux boot around 571M instructions after the login prompt. This bug occurs when there are back to back HPTW requests and the first generates an access fault during the walk. The old implementation uses a delayed version of the fault to prevent the HTPW fsm from transitioning out of the IDLE state. Because the first request generates the fault and the second request is pipelined the second request appears as if it also faults so the FSM does not perform the walk. The new implementation adds a FAULT state. When the HPTW generates an access fault it transitions to this state removes the HPTWStall and then transitions to IDLE. There may still be a remaining bug here if the pipeline is stalled for another reason. However I don't think it is possible by construction. The only possible sources of stalls at this point would be IFU and LSU stalls and both are required to make this condition happen.