The ic_scr_key_valid field indicates whether the ICache scrambling key
is valid.
CPUCTRL is also renamed CPUCTRLSTS as it contains both control and
status bits.
- Enable epmp in riscv_core_settings.sv
- Bump CI and Spike version in `ci/vars.yml`
- Enable full random PMP test
- Create tests for machine mode lockdown (MML)
- Code execute only, rest read/write
- All regions execute only
- All regions read only
- Create test for machine mode whitelist policy (MMWP)
- Create test for rule lock bypass (RLB)
Signed-off-by: Marno van der Maas <mvdmaas+git@lowrisc.org>
This will only have an effect on our private CI, which picks up this
spike build from the toolnas. The build is the ibex_cosim branch,
which contains the stuff we need for the recent cosim support. It's
also new enough to support the v1.0+0.93 bitmanip flavour that we
support in the RTL.
This commit creates a new top level wrapping the core, register file and
icache RAMs. The tracing top level is also renamed to ibex_top_tracing
to match. This new top level is intended to enable a dual core lockstep
implementation of Ibex.
There are no functional changes in this commit, only wiring.
Signed-off-by: Tom Roberts <tomroberts@lowrisc.org>
In the past, we did explicitly install pyyaml through PIP to get a
version newer than the one provided in Ubuntu 18.04. Since then we
changed the calling code to not rely on newer pyyaml features and
are thus able to rely on an older version of pyyaml.
The distro-provided version of pyyaml is built with C bindings, which
are significantly faster than the pip-installed version, which uses a
pure Python-implementation of the parser/dumper.
Turns out, just having a nice error message with the correct tool
invocation isn't enough: you actually need to call the tool with the
arguments you document.
Let's do that and actually run Verilator lint and Verible lint, and not
just Verilator lint twice.
There's a long and painful discussion on the setuptools issues
list (I count 9 issues raised the day after the release). This is all
to do with how Debian/Ubuntu installs stuff with pip.
There's an "official" workaround that involves setting things in your
environment, but that looks a bit fiddly with the Azure pipelines
stuff and this has been such a disaster that I'm pretty certain the
setuptools maintainers will release something more sensible soon.
See e.g.
https://github.com/pypa/setuptools/issues/2350#issuecomment-683512526
for a careful description of what's going on.
The ci/azp-private.yml file is a skeleton and only used to trigger an
Azure Pipelines run which integrates into the ibex repository. All real
job description is in a private repository for licensing reasons.
Put all build dependencies into a CI-specific script
(ci/install-build-deps.sh). No effort has been made to make this script
suitable for non-CI users.
Add a script to convert the contents of ci/vars.yml to Azure Pipelines
logging commands, which effectively set runtime variables in a pipeline.
We need this script as a workaround for a missing Azure Pipelines
feature: variables are not inherited in extended templates, and reading
the vars.yml file in a "extends" template isn't possible either (at
least not if we want to use the exact revision of the ibex repository
which triggered CI).
Multi-config CI wasn't actually trying multiple configurations. This
fixes that issue and uses a less fragile method of producing fusesoc
options. They are generated once and stored in a variable so we cannot
accidentally break one or more steps by using an incorrect
ibex_config.py command in one step whilst using a correct
ibex_config.py in the display step (which is also intended to check the
ibex_config.py command is correct).
