Found some bugs while running regression for SV48

Addresses the problem faced in PR #1532. @davidharrishmc @rosethompson

The test sv48_res_global_pte_U_mode.S normally passes but fails when sv48_pte_reserved_field_S_mode.S is executed prior to it. This seemed really strange. I looked into it and have found some bugs.

It seems like BTB is the root cause of the problem.

Normal Execution:

If sv48_pte_reserved_field_S_mode.S is executed prior to it:

Initially, I observed that there was a branch misprediction, but the instruction in fetch stage was lw. Therefore, seemed strange. I then checked the other test (pte_reserved_field) and it has a jalr at that address.

[1603] [S]: 0x0000030080000EC0 (0x000780E7) jalr x1, 0x0(x15)
x1 <- 0x0000030080000EC4

This is not being cleared from the BTB and it's messing with the other test. This is causing BPJumpF to go high and jump to an address from the BTB despite having lw instead of a control flow instruction in fetch stage. Wally wasn't supposed to make this prediction but it eventually recovers and jumps back to the correct address. But due to this bug I have encountered 2 other bugs which were the reason for signature mismatch.

When we get the (buggy) misprediction due to lw in fetch stage, there is a sw in memory stage. The sw causes a DTLBmiss while at the same time we get an ITLBmiss as well. The HPTW first calculates physical address for sw and as soon as the walk finishes and 0x40 (desired value) is going to be stored in DCache, the ITLBmiss causes a HPTW flush which in turn flushes LSU.

assign HPTWFlushW = (WalkerState == IDLE & TLBMissOrUpdateDA) | (WalkerState != IDLE & HPTWFaultM);

Due to LSUFlushW, CacheEn goes low and sw is unable to write the desired value to DCache.

As 0x40 is not written we're supposed to get back 0x30 when we execute lw at that address. But we are getting beefcaf2. The program initially had beefcaf2 at that address, but it was overwritten by 0x10 then 0x20 and then 0x30. Then why does lw gives us beefcaf2? During lw, we get a Cache Hit at way0, and also a victim cache hit and it's reading value from victim cache and therefore giving us beefcaf2.

I don't exactly know what's causing this one. It could a consequence of that unwanted branch misprediction bug such that Wally is not correctly recovering from the misprediction.

Here, it we can see that a NOP at address 0x28080000400 hasn't been flushed from the pipeline. Maybe fixing the BTB bug will fix this one as well but the bug due to ITLBmiss is something different and needs a separate solution.