Concurrent HPTW access fault with IFU bus fetch

[rosethompson]

Issue #412 exposed a bug in Wally with a concurrent I$ miss and DTLB miss. The HPTW makes a request which generates an access fault during an inflight I$ bus request. This Trapped during a bus access violating the atomic nature of the bus request.
A simulation solution was to suppress the fault in trap.sv...

assign TrapM = (ExceptionM & ~CommittedF) | InterruptM; // *** RT: review this additional ~CommittedF with DH and update priv chapter.

However this creates the potential hazard of missing exceptions. This warrants careful review and a better solution.

Ideally we allow the exception and find a way to either delay it or abort the ifu transaction.

Probably need to record the exception during the walk. Abort the walk. Wait for the ifu to finish, then replay the exception and take the trap.

Could also think more deeply about the entire exception architecture.

[rosethompson]

Confirmed this is a bug. I extended the hptwAccessFault.S test to create the specific condition above and the HPTW walks the page table multiple times while the IFU stalls the CPU. Fortunately it still produces the same exception, but it is wasting power and cycles.

[rosethompson]

I have several thoughts about how to fix this.

1. Easy. We an ignore since the bug is only performance.
2. Simple. Use CommittedF to keep the hptw FSM in the Fault state. Some extra work is required to keep asserting the exception. I don't like that CommittedF or StallF now has to come into the hptw.
3. Hard. The underlying problem is the IFU is performing a bus read while the hptw running. If it generates an exception, PCNextF needs to immediately point to the trap handler. We could decouple the bus controller from PCF/PCNextF. This would allow us to update PCF on a trap and still finish the bus transaction. We'd have to keep holding the CPU stalled during the trap which requires changing some PC muxes. Another advantage of this version is it would allow us to remove CommittedF from the TrapM logic for both exceptions and interrupts.

I think for now we should ignore the problem since it's just a performance bug, but do option 3 as we build the Wally enhancements.