* RocketTile: Create a wrapper for SyncRocketTile as well
There is no guarantee that debugInterrupt is synchronous
to tlClk, even though it is true in the current implementation.
It will not be true in future implementations, as decoupling
this allows the debugInterrupt to be asserted across tlClk
gating/reset scenarios.
Therefore, even for SyncRocketTile, the debug interrupt needs to be
synchronized to coreClk, and for RationalRocketTile, 1 cycle
of synchronization is not sufficient.
Even though other interrupts may be synchronized, we just
synchronize them all to simplify the code at the expense of
a few cycles latency.
It could still be nice to use a parameter vs hard coding "3".
* RocketTile: Actually use the SyncRocketTile wrapper to get properly synchronized resets.
If an exception occurs while a page-table walk is coincidentally in
progress (e.g., an illegal instruction executes during data TLB refill),
then the processor might enter M-mode. However, the PTW's accesses
should proceed without M privilege, to avoid bypassing PMPs.
Note, the same argument doesn't apply to the nonblocking cache's replay
queues, because those accesses have already been checked against the PMPs.
The cache correctly ignores access exceptions reported on replays,
provided no exceptions were reported on the initial access.
This one's a little invasive. To flush a specific entry from the TLB, you
need to reuse its CAM port. Since the TLB lookup can be on the critical
path, we wish to avoid muxing in another address.
This is simple on the data side, where the datapath already carries rs1 to
the TLB (it's the same path as the AMO address calculation). It's trickier
for the I$, where the TLB lookup address comes from the fetch stage PC.
The trick is to temporarily redirect the PC to rs1, then redirect the PC
again to the instruction after SFENCE.VMA.
