As well as completely removing the existing non-cosim flow, this commit
significantly refactors the build system to be less reliant on the makefile.
While we still use the Makefile, it is relegated to only providing scheduling
and dependency calculations between the different build steps.
This is possible by moving all of the build metadata into a file on-disk, which
is populated at the start of a new regression, then read and written to by the
different scripts executing the build. Each build step only needs to be passed
the location of this metadata at the top-level, and it can then import all
the information it requires to calculate and perform the next build stage.
This allows better observability into the build, as it is trivial to add new
data to this file, which is also provided as a human-readable yaml version.
It should also allow easier integration into different build systems, as the
dependency on Make is much weaker.
The file metadata.py and test_run_result.py contain the definitions for
these metadata objects. metadata.py defines an object for the whole
regression, while test_run_result.py defines objects for each individual test
performed.
The file riscvdv_interface.py has been created to better isolate the interface
with that project.
The file setup_imports.py has been created to centralize the importing of
python modules from other projects (riscvdv/ot_lowrisc_ip etc.).
Existing python code has been tidied to better conform to PEP8 standard
formatting, and to be more python in general such as using pathlib.Path.
Updated the parameters with respect to top_earlgrey.hjson in OpenTitan
repository. For other builds, kept the previously undeclared parameters
as their default values.
Signed-off-by: Canberk Topal <ctopal@lowrisc.org>
This didn't quite work properly for Xcelium (giving strings with an
embedded space: '-define IBEX_CFG_RV32M=ibex_pkg::RV32MSingleCycle').
It turned out not to matter because we were evaluating one time too
often in the shell, but we're about to stop doing that.
This comes from OpenTitan and can't currently be vendored in
properly (because it doesn't live in its own directory). We'll sort
that out eventually but, for now, copy in some recent changes by hand.
This PR adds functionality to filter out tests during regressions for a
particular config.
e.g. if a full regression is kicked off using the `small` config, we
don't want to attempt to run any PMP and bitmanip tests as the RTL
parameter-set will not support it.
To do this, a new YAML field called `rtl_params` is added to relevant
test entries, to indicate what parameters (if any) are required to be
able to run the particular test, along with the required value of said
parameters.
`sim.py` will then parse this field (if it exists), and using
information from `ibex_configs.yaml` pertaining to the current config,
will remove tests from being run on-the-fly.
This also gives us the convenient side effect of not having to re-run
instruction generation if there is a parameter/config mismatch, we can
just rerun the RTL compilation and simulation stages safely.
Signed-off-by: Udi Jonnalagadda <udij@google.com>
Instead of using copies of primitives from OpenTitan, vendor the files
in directly from OpenTitan, and use them.
Benefits:
- Less potential for diverging code between OpenTitan and Ibex, causing
problems when importing Ibex into OT.
- Use of the abstract primitives instead of the generic ones. The
abstract primitives are replaced during synthesis time with
target-dependent implementations. For simulation, nothing changes. For
synthesis for a given target technology (e.g. a specific ASIC or FPGA
technology), the primitives system can be instructed to choose
optimized versions (if available).
This is most relevant for the icache, which hard-coded the generic
SRAM primitive before. This primitive is always implemented as
registers. By using the abstract primitive (prim_ram_1p) instead, the
RAMs can be replaced with memory-compiler-generated ones if necessary.
There are no real draw-backs, but a couple points to be aware of:
- Our ram_1p and ram_2p implementations are kept as wrapper around the
primitives, since their interface deviates slightly from the one in
prim_ram*. This also includes a rather unfortunate naming confusion
around rvalid, which means "read data valid" in the OpenTitan advanced
RAM primitives (prim_ram_1p_adv for example), but means "ack" in
PULP-derived IP and in our bus implementation.
- The core_ibex UVM DV doesn't use FuseSoC to generate its file list,
but uses a hard-coded list in `ibex_files.f` instead. Since the
dynamic primitives system requires the use of FuseSoC we need to
provide a stop-gap until this file is removed. Issue #893 tracks
progress on that.
- Dynamic primitives depend no a not-yet-merged feature of FuseSoC
(https://github.com/olofk/fusesoc/pull/391). We depend on the same
functionality in OpenTitan and have instructed users to use a patched
branch of FuseSoC for a long time through `python-requirements.txt`,
so no action is needed for users which are either successfully
interacting with the OpenTitan source code, or have followed our
instructions. All other users will see a reasonably descriptive error
message during a FuseSoC run.
- This commit is massive, but there are no good ways to split it into
bisectable, yet small, chunks. I'm sorry. Reviewers can safely ignore
all code in `vendor/lowrisc_ip`, it's an import from OpenTitan.
- The check_tool_requirements tooling isn't easily vendor-able from
OpenTitan at the moment. I've filed
https://github.com/lowRISC/opentitan/issues/2309 to get that sorted.
- The LFSR primitive doesn't have a own core file, forcing us to include
the catch-all `lowrisc:prim:all` core. I've filed
https://github.com/lowRISC/opentitan/issues/2310 to get that sorted.
Fix a deprecation, to be removed in Python 3.10.
See https://docs.python.org/3/library/collections.html:
"Deprecated since version 3.3, will be removed in version 3.10: Moved
Collections Abstract Base Classes to the collections.abc module. For
backwards compatibility, they continue to be visible in this module
through Python 3.9."
We need this specific edalize version because recent verilators have
got pickier about string parameter passing, breaking the
"MultiplierImplementation" parameter.
As well as teaching check_tool_requirements.py to get the edalize
version from pip3, this patch also does a bit of tidying up, coping
better if tool_requirements.py is missing or malformed.
Define supported tool versions in tool_requirements.py, and check them
in a fusesoc run. If an unsupported tool version is found, fusesoc
outputs an error like this:
```
$ fusesoc --cores-root . run --target=lint lowrisc:ibex:ibex_core
INFO: Preparing lowrisc:ibex:check_tool_requirements:0.1
INFO: Preparing lowrisc:prim:assert:0.1
INFO: Preparing lowrisc:ibex:sim_shared:0
INFO: Preparing lowrisc:ibex:ibex_core:0.1
INFO: Setting up project
INFO: Running pre_build script check_tool_requirements
ERROR: verilator is too old: found version 4.010, need at least 4.028
ERROR: Tool requirements not fulfilled. Please update the tools and retry.
ERROR: Failed to build lowrisc:ibex:ibex_core:0.1 : pre_build script 'check_tool_requirements' exited with error code 1
```
The only version checked at this point is Verilator, which is set
somewhat arbitrarily to the version used by me (and I know it works). CI
uses a slightly newer version. As we are about to merge changes soon
which require a newer Verilator version, there's not much point in
finding the oldest supported version right now.
