Remove DmHaltAddrInRange_A and DmExceptionAddrInRange_A assertions

These assertions were a little too strong. While in practice the halt and
exception vector addresses would likely be within the range of the debug_module,
this is not mandated by the specification.
We actually do this is the current testbench configuration. The halt and
exception vectors are parameterized to `BOOT_ADDR and `BOOT_ADDR + 0x4
respectively, and the riscv-dv generated test binaries insert jump handlers
at those locations that target the .debug_rom and .debug_exception sections
somewhere else in the monolithic test binary. The assertions only worked because
the current parameterizations for Debug Module addresses put the debug module
right at the BOOT_ADDR parameter, which doesn't really make much sense.
  .DmBaseAddr (32'h`BOOT_ADDR)
  .DmAddrMask (32'h0000_0007 )
MTVEC is reset to `BOOT_ADDR, so this memory region would normally be used for
the mmode trap handler vector table.

Signed-off-by: Harry Callahan <hcallahan@lowrisc.org>
This commit is contained in:
Harry Callahan 2025-05-13 16:04:45 +01:00
parent f0a57f0c7c
commit 0e5611edfd
1 changed files with 0 additions and 4 deletions

View File

@ -1139,10 +1139,6 @@ module ibex_top import ibex_pkg::*; #(
assign alert_major_bus_o = core_alert_major_bus | lockstep_alert_major_bus;
assign alert_minor_o = core_alert_minor | lockstep_alert_minor;
// Parameter assertions
`ASSERT_INIT(DmHaltAddrInRange_A, (DmHaltAddr & ~DmAddrMask) == DmBaseAddr)
`ASSERT_INIT(DmExceptionAddrInRange_A, (DmExceptionAddr & ~DmAddrMask) == DmBaseAddr)
// X checks for top-level outputs
`ASSERT_KNOWN(IbexInstrReqX, instr_req_o)
`ASSERT_KNOWN_IF(IbexInstrReqPayloadX, instr_addr_o, instr_req_o)