Debug spec says:
Because chain affects the next trigger, hardware
must zero it in writes to mcontrol that set dmode
to 0 if the next trigger has dmode of 1. In addition
hardware should ignore writes to mcontrol that
set dmode to 1 if the previous trigger has both
dmode of 0 and chain of 1. Debuggers must avoid
the latter case by checking chain on the previous
trigger if they’re writing mcontrol.
Previously, this was ignoring the write even if it was coming from
M-mode and therefore would have had dmode forced to 0. That should not
count as a "write to mcontrol that sets dmode to 1".
Maintain a shadow structure of isa_parser_t::extension_table,
processor_t::extension_enable_table, which tracks whether such
extensions have been dynamically enabled or disabled.
Sanity-check that `extension_enabled_const` honors its contract.
The use of `mutable` is somewhat unfortunate, but we think it's
acceptable here because the only thing that's mutating is this
sanity-checking code, not visible to any consumer of this class.
!dtb_enabled will now result in the following behavior:
* sim_t.dts and sim_t.dtb will be empty
* the dtb_file passed to sim_t will be ignored
* The default bootrom will not be instantiated
* Bus devices normally configured by parsing the dtb will not be added
This includes the CLINT/PLIC/UART
Before 3b26740, the reset was necessary because sim_t::get_dts would be
called before sim_t::make_dtb was called in reset(). This is no longer
necessary since now `make_dtb` is called in the constructor of sim_t
This implements the Zicond (conditional integer operations) extension,
as of version 1.0-draft-20230120.
The Zicond extension acts as a building block for branchless sequences
including conditional-arithmetic, conditional-logic and
conditional-select/move.
The following instructions constitute Zicond:
- czero.eqz rd, rs1, rs2 => rd = (rs2 == 0) ? 0 : rs1
- czero.nez rd, rs1, rs2 => rd = (rs2 != 0) ? 0 : rs1
See
https://github.com/riscv/riscv-zicond/releases/download/v1.0-draft-20230120/riscv-zicond_1.0-draft-20230120.pdf
for the proposed specification and usage details.
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.
Wade
Weiwei Li
Scott Johnson
Andrew Waterman
Jerry Zhao
Neel Gala
Philipp Tomsich
YenHaoChen
Aaron Durbin