* 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.
Superpages create the possibility that two entries in the TLB may match.
This corresponds to a software bug, but we can't return complete garbage;
we must return either the old translation or the new translation. This
isn't compatible with the Mux1H approach. So, flush the TLB and report
a miss on duplicate entries.
This is simpler, reduces what would have become a critical path in
the commit stage, and will make it easier to support the mbadinst
CSR if it is implemented.
Fundamental new features:
* Added tile package: This package is intended to hold components re-usable across different types of tile. Will be the future location of TL2-RoCC accelerators and new diplomatic versions of intra-tile interfaces.
* Adopted [ModuleName]Params convention: Code base was very inconsistent about what to name case classes that provide parameters to modules. Settled on calling them [ModuleName]Params to distinguish them from config.Parameters and config.Config. So far applied mostly only to case classes defined within rocket and tile.
* Defined RocketTileParams: A nested case class containing case classes for all the components of a tile (L1 caches and core). Allows all such parameters to vary per-tile.
* Defined RocketCoreParams: All the parameters that can be varied per-core.
* Defined L1CacheParams: A trait defining the parameters common to L1 caches, made concrete in different derived case classes.
* Defined RocketTilesKey: A sequence of RocketTileParams, one for every tile to be created.
* Provided HeterogeneousDualCoreConfig: An example of making a heterogeneous chip with two cores, one big and one little.
* Changes to legacy code: ReplacementPolicy moved to package util. L1Metadata moved to package tile. Legacy L2 cache agent removed because it can no longer share the metadata array implementation with the L1. Legacy GroundTests on life support.
Additional changes that got rolled in along the way:
* rocket: Fix critical path through BTB for I$ index bits > pgIdxBits
* coreplex: tiles connected via :=*
* groundtest: updated to use TileParams
* tilelink: cache cork requirements are relaxed to allow more cacheless masters
* [rocket] Refactor Tile into cake pattern with traits
* [rocket] cacheDataBits &etc in HasCoreParameters
* [rocket] pass TLEdgeOut implicitly rather than relying on val edge in HasCoreParameters
* [rocket] frontend and icache now diplomatic
* [rocket] file name capitalization
* [rocket] re-add hook for inserting externally-defined Cores
* [rocket] add FPUCoreIO
* [groundtest] move TL1 Config instances to where they are used
* [unittest] remove legacy unit tests
* [groundtest] remove legacy device tests
PLRU wasn't implemented correctly for the BTB, since it wasn't
increasing the priority on replacement, only on usage. Regardless,
this should be a second-order effect, so using FIFO always is fine.
* [rocket] file capitalization
* [rocket] cacheDataBits &etc in HasCoreParameters
* [rocket] pass TLEdgeOut implicitly rather than relying on val edge in HasCoreParameters
* [rocket] frontend and icache now diplomatic
A lot of utility code was just being imported willy-nilly from one
package to another. This moves the common code into util to make things
more sensible. The code moved were
* The AsyncQueue and AsyncDecoupledCrossing from junctions.
* All of the code in rocket's util.scala
* The BlackBox asynchronous reset registers from uncore.tilelink2
* The implicit definitions from uncore.util
A chip's power-up sequence, or awake-from-sleep sequence, may wish to
set the reset PC based upon dynamic properties, e.g., the settings of
external pins. Support this by passing the reset vector to the Coreplex.
ExampleTop simply hard-wires the reset vector, as was the case before.
Additionally, allow MTVEC to *not* be reset. In most cases, including
riscv-tests, pk, and bbl, overriding MTVEC is one of the first things
that the boot sequence does. So the reset value is superfluous.
Rocket's QoR has improved enough that the FMAs are on the critical
path. This change seems to keep the integer pipeline's logic
paths balanced with the FPU.
The old value 62 seems to have been a typo introduced over 2 years ago
in commit 63bd0b9d2a. The intent was to
fit the dhrystone working set (rofl) which the new value of 40 does.
They fit in the same part of the address space as DRAM would be, and
are coherent (because they are not cacheable).
They are currently limited to single cores without DRAM. We intend
to lift both restrictions, probably when we add support for
heterogeneous tiles.
This usually shouldn't be used in Tiles that are meant to be P&R'd once
and multiply instantiated, as their RTL would no longer be homogeneous.
However, it is useful for conditionalizing RTL generation for
heterogeneous tiles.
The previous approach used ex_reg_valid to determine whether to
source data from the FPU or RoCC. Thus, when the RoCC was not
present, it was still creating muxes. Using ex_cp_valid instead
gets rid of them.
