This commits adds basic spike testing using llvm-snippy random code
generator. This initial testing runs spike on random valid code snippets and
checks that it doesn't fail.
Co-authored-by: Ksenia Dobrovolskaya <ksenia.dobrovolskaya@syntacore.com>
Building of spike-based simulator with memory sanitizer reports leaking
pointers if custom extension are used. This is because existing
facilities do not have a proper destructor procedure, so the objects
representing custom extentions are leaked. This commit implements
quick-and-dirty fix for the problem.
Since 92e4f02 moved logging logic into store_slow_path function it has
been logging stores even if actually_store parameter is false. Because
of that logging is broken for all atomic instructions. Function "amo" calls
store_slow_path with nullptr argument and actually_store equal to false
while callee uses reg_from_bytes independently from actually_store value
All of that causes dereferencing of nullptr. This commit logs memory
access only if it actually happened
Adds an optional --instructions=N CLI argument which will stop the simulation after N instructions.
This is useful for benchmarking and profiling and sometimes debugging.
Currently in riscv-isa-sim there's no way to make a custom extension
that adds new CSRs. This simple patch makes it possible via new
virtual function in extension_t class.
As proposed in #1652, we made the following changes to MMIO device (factory)
plugin API, to mitigate current limitations and facilitate factory reuse.
- removed `sargs` from `device_factory_t`, and introduced a new type alias
`device_factory_sargs_t` to capture `<device_factory_t *, sargs>` pairs,
this is used to instantiate sim_t instances;
- changed the signature of `device_factory_t::generate_fdt` and
`device_factory_t::parse_from_fdt` to take on an extra `sargs` argument,
for instantiating devices with per-device arguments;
- made `device_factory_t` const and potentially resuable across multiple
`sim_t` instances.
RISC-V ISA states (21.1):
"A standard-compatible global encoding can also use standard prefixes
for non-standard extensions if the associated standard extensions are
not included in the global encoding."
Currently all the instructions (either from standard or custom
extensions) are all being inserted into a single std::vector which is
then being sorted. An instruction matching process performs linear
search on that vector. The problem is that when a custom extension uses
the same opcode as standard one (i.e. match and mask are equal to the
standard counterparts) it is undefined which instruction will be picked.
That is because in std::sort "The order of equal elements is not
guaranteed to be preserved". That being said it is impossible to define
custom extension (via customext) that would use the prefix of a disabled
standard extension.
In this change I separate custom and standard extensions in two separate
std::vector's. By default we report an error if they have common
elements (There're an additional processor_t constructor's argument that
skips this check). If this error is disabled during instruction matching
we first trying to find it among custom instructions. If it has been
found the search is stopped and custom instruction is executed,
otherwise we look for it among standard instructions. Overall this
change does not completely fix the problem but at least makes it
possible to use the feature of RISC-V ISA.
PMP Granularity is made available as a command line option. The default
value is 4 Bytes. The value can be changed by passing the option
--pmp-granularity=<value> to spike.
Signed-off-by: Karthik B K <karthik.bk@incoresemi.com>
This change allows to create custom implementations of `abstract_mem_t`
and inject them when constructing `sim_t`. The current `mem_t`
implementation remains unchanged.
Fixes#1408.
Plugins should now implement and register a device_factory_t to
configure how that device should be parsed from a FDT, and an optional
default DTS string.
This drops support for command-line flag-based device configuration
The addition of Svadu support and removal of --mmu-dirty
command line flag results in the dirty_enabled configuration state
no longer being used. Remove the remnants of this state.
To avoid long CI times, keep the program in binary form.
To avoid storing binary files in this repository, store the binaries as
an asset on a github release.