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.
DPI access is suggested and more generic than Verilator direct signal
access. This changes the access to the performance counters from the
Verilator testbench to use DPI instead of directly accessing the
array.
Signed-off-by: Stefan Wallentowitz <stefan.wallentowitz@hm.edu>
The VerilatorSimCtrl class was always intended to be used only once in
an application, since it sets up a global signal handler and needs to be
accessible from DPI modules. This accessibility was achieved through a
global variable `simctrl`.
With this commit the VerilatorSimCtrl is switched to a singleton class.
The instance is accessible through `VerilatorSimCtrl::GetInstance()`.
The downside of that approach is that we loose the constructor
arguments, and need to deal with a class which potentially hasn't top or
the clock and reset signals set.
Support initialization of memory by loading content from ELF files.
All segments of the ELF file with the type `PT_LOAD` are merged into a
temporary buffer and then forwarded to a predefined memory.
This is an addition for setting the memories with VMEM files.
Memories must implement `simutil_verilator_set_mem` to support the
setting of values with a width of 32 bits. A return value of 0 must
indicate a successful operation and 1 an error.
Memories are defined by a call to `RegisterMemoryArea()` before the
execution of the simulation, at which point the arguments are parsed and
the initialization is started. The memories are identified by unique
name. The design specific location is used to set the SystemVerilog
scope.
Registered memories can be printed by using `-l list`. The unique name
is used for `-l name,file.elf` together with the file path.
An optional part of the argument is the type of the file, `elf` or
`vmem`, and if not provided it is attempted to detect the type by
looking at the file extension.
The memory specific arguments which already existed accept now also ELF
files. They use predefined names and are included to keep the interface
stable.
Contents of an ELF segment which has a bigger memory size than file size
are not set. This is typically required for BSS sections for zero-ing
the memory.
Simple system is a basic verilator top-level testbench for running
executables. It has functionality for outputting text to a log file
and for the software to terminate the simulation
