AMO.aq should be implemented as AMO;FENCE, whereas AMO.rl should be
implemented as FENCE;AMO. These had been swapped. This error does
not affect cacheable accesses using the blocking D$, nor does it
affect accesses to the data scratchpad, nor does it affect accesses
to strongly ordered I/O regions (which is the default).
Cacheable accesses using the nonblocking D$ and accesses to weakly
ordered I/O regions may manifest memory-ordering violations. For
these accesses, the workaround is to use AMO.aqrl whenever AMO.aq
or AMO.rl had been used.
This proposal hasn't been adopted yet, but anything is better than the
current implementation, where clearing misa.C when the PC is misaligned
is effectively undefined.
In Rocket, debug triggers are supposed to happen before a store
occurs, rather than after. Previously, we reported the exception
on the store's PC, but the store occurred anyway. This probably
hasn't been problematic in practice because most stores are
idempotent.
The TL port can easily starve the processor, even at only 20% utilization,
because of a bad interaction with the pipeline. Giving the processor
static priority is OK in practice, since <50% of instructions are loads
and stores in typical workloads. Even if it executes 100% loads and stores,
it must eventually encounter an I$ miss, taken branch, or exception, so
even malicious code can't permanently starve the TL port.
When xLen > paddrBits, enforce that physical addresses are zero-extended.
This works by checking that the _virtual_ address is _sign_-extended, then
checking that its sign is positive.
After detecting a corrupted BTB, don't speculatively update it until
the next non-speculative fetch. This prevents the frontend from replaying
forever.
This esoteric bug manifests if a tag-read error occurs when a FENCE.I is
executed, even if the error was correctable. Subsequently, an attempt to
flush a dirty line may flush the wrong line's data.
Deallocation can change repl_way, which violates the assumption that it
remains constant throughout refill.
The workaround described in commit 3db066303b
still suffices, provided only the hart that owns the ITIM changes the ITIM
allocation.
This subsumes commit 3db066303b.
- Put correctness responsibility on Frontend, not IBuf, for improved
separation of concerns. Frontend must detect case that the BTB
predicts a taken branch in the middle of an instruction.
- Pass BTB information down pipeline unconditionally, fixing case that
screws up the branch history when the BTB misses and the instruction
is misaligned.
- Remove jumpInFrontend option; it's now unconditional.
- Default to one-bit counters in the BHT. For tiny BHTs like these, it's
more resource efficient to have a larger index space than to have
hysteresis.
Require and/or force vaddrBits to be bigger than paddrBits so there's
room to zero-extend a physical address by 1 bit, so that when the virtual
address is sign-extended, the sign is zero.
This fixes a deadlock (and possibly memory corruption, though that is
unconfirmed). The following sequence manifests it, assuming t0
is 32-byte aligned:
sw t0, 0(t0)
sw t0, 16(t0)
lw t1, 4(t0)
lw t2, 4(t0)
If the queue is not empty before a dirty miss, C could block D.
I haven't seen this in the wild, but it could happen because of
dirty probe responses backed up in the queue.
Don't examine a packet's xcpt signal if it might be invalid. In this case,
the correct fix is to not examine xcpt at all; the deleted code was vestigial.
(Note, the other use of xcpt(j+1) in this code is indeed safe.)
The following sequence would drop the first store when eccBytes=4:
sb x0, 0(t0)
nop
sb x0, 4(t0)
nop
sb x0, 1(t0)
Because the first and second store are to different ECC granules, the
hazard check correctly allowed the second one to proceed, but the third
was merged with the second, even though it conflicted with the first.
So, don't allow the third to be merged with the second, since the second
stored to a different ECC granule.
Andrew Waterman
