* Configs: use a uniform syntax without Match exceptions
The old style of specifying Configs used total functions. The only way to
indicate that a key was not matched was to throw an exception. Not only was
this a performance concern, but it also caused confusing error messages
whenever you had a match failure from a lookup within a lookup. The
exception could get handled by an outer-lookup that then reported the wrong
key as missing.
This bug is ancient. I don't understand how it never mattered before.
Anyway, in processors with a custom CacheBlockBytes, this value is wrong!
The symptom is that TL1 components end up missing high address bits.
This causes, for example, a system to jump to 0 instead of RAM.
I don't understand how this very serious bug did not cause problems before.
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.
Unfortunately, I had to touch a lot of code, which weren't quite possible to split up into multiple commits.
This commit gets rid of the "extra" infrastructure to add periphery devices into Top.
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.
