Before we changed to vendoring in our RAM primitives from OpenTitan,
there was an SRAM_INIT_FILE define that you could stick in your core
file. That's now gone away, replaced by a parameter (MemInitFile). If
we want to plumb that in, we need to pass it properly through the
wrappers.
Fix all remaining issues reported by Verible lint.
It turns out that #965 undid some of the fixes in `ibex_alu.sv`
that were done in #980 around the `SHUFFLE_*`/`FLIP_*` signals.
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.
ram_1p is almost a copy of the single-port RAM primitive we have in
OpenTitan, called prim_ram_1p, with its generic implementation
prim_generic_ram_1p. Instead of having a copy of that file in Ibex,
consistently use the OpenTitan one.
Unfortunately, ram_1p has slightly different semantics around some
signals, especially rvalid. This commit adjusts the meanings of the
signals for now, since I don't have a way to test the Arty board
which also uses this primitive (together with the compliance test
suite). With the testing in the compliance suite I'm reasonably certain
that the Arty board will work as well.
- Adds a new module in the IF stage to inject dummy instructions into
the pipeline
- Control / frequency of insertion is governed by configuration CSRs
- Extra CSR added to allow reseed of the internal LFSR useed for
randomizing insertion
- Extra logic added to the register file to make dummy instruction
writebacks look like real intructions (via the zero register)
Signed-off-by: Tom Roberts <tomroberts@lowrisc.org>
When xprop is enabled various case and if/else constructs will propagate
X leading to failures in ASSERT_KNOWN. This introduces enable terms to
various ASSERT_KNOWN uses that would otherwise fail without them.
prim_assert.sv changes copied across from OpenTitan respository.
- Bring in a version of ram primitive with configurable width similar to
the OT RAM primitive.
- Change the RAM banking structure to be a single bank of LineSize (64
bits) to match the upcoming ECC granularity.
Signed-off-by: Tom Roberts <tomroberts@lowrisc.org>
Assert macros in prim_assert.sv report the asserted property as part of
the error message if the assertion fails. Doing that requires us to
stringify the property. If the property is multi-line in the source
code, this produces a multi-line string. According to the
SystemVerilog standard, a multi-line string requires a backslash (`\`)
at the end of a line. Adding this backslash through a macro is not
possible (at least to my knowledge), giving us no way to produce a
standards-compliant implementation of the `ASSERT` macros that report
the property as string.
This commit therefore removes the property from the error message if an
assertion fails. It makes these messages less useful, but the
information can still be recovered in a less convenient way through the
name of the assertion, and the file and line numbers. File and line
number were missing from the non-UVM code path before, this commit adds
them there as well.
Fixes#669
This commit adds a separate memory ports for instruction and data
fetches to the Simple System example.
* Add Dual-Port RAM with 1 cycle read/write delay, 32 bit words.
* Introduce parametric signal width definitions for bus implementation
to work with a single host / device.
* Modify Simple System top module to instantiate the new dual-port RAM.
prim_assert.sv is a file containing assertion macros (defines).
Previously, prim_assert.sv was compiled as normal SystemVerilog file.
This made the defines available for the whole compilation unit as soon
as they were defined. Since all cores using prim_assert depended (in
fusesoc) on the lowrisc:prim:assert core, prim_assert was always
compiled first, and the defines were visible in subsequent files.
All of that is only true if all files end up in one comilation unit. The
SV standard states that what makes up a compilation unit is
tool-defined, but also states that typically, passing multiple files (or
a file list/.f file) to a single tool invocation means that all files
end up in one compilation unit; if the tool is called multiple times,
then the files end up in separate compilation units.
Edalize (the fusesoc backend) doesn't guarantee either behavior, and so
it happens that for Vivado, Verilator, Cadence and Synopsys simulators,
all files are compiled into a single compilation unit. But for Riviera,
each file is a separate compilation unit.
To avoid relying on the definition of compilation units, and to do the
generally right thing (TM), this commit changes the code to always
include the prim_assert.sv file when it is used in a source file.
Include guards are introduced in the prim_assert.sv file to avoid
defining things twice.
This commit replaces all X assignments in the RTL with defined
values. In addition, SystemVerilog Assertions are added to catch
invalid signal values in simulation. A new file containing the
corresponding assertion macros is added as well.
Signed-off-by: Pirmin Vogel <vogelpi@lowrisc.org>
All functions in simutil_verilator return booleans to indicate
success/failure, where 1 == true, and 0 == false.
simutil_verilator_set_mem() returns an int due to DPI interface
restrictions. Before, 0 meant success, and 1 meant error.
To keep things nice and consistent, turn things around and align with
the bool meaning.
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.
This commit removes a copy of the dummy clock gating primitive from
tree previously used for UVM-based DV. There is another, identical copy
of the same primitive in `shared/rtl` that can be used instead.
This resolveslowRISC/ibex#213.
Signed-off-by: Pirmin Vogel <vogelpi@lowrisc.org>
Move Xilinx specific code into shared folder so it can be re-used by
different examples.
Use the shared RAM code and make use of byte enable signal.
Fixeslowrisc/ibex#144
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
