In the documentation for the PMA, it says

Non-aligned transactions are not supported in I/O regions.

What action is taken if a non aligned Load/Store occurs ?
In the exceptions I do not see support for
Code(4) - Load Address Misaligned, or
Code(6) - Store/AMO address misaligned

Thx
Lee

• Make irq_ack_o, irq_id_o local in the top level
• Remove all mentions of above signals from the User Manual (no need to add the core local signals in the User Manual)
• Add 'debug ack' pulse (and implement similar to IRQ ack in controller FSM)
• core-v-verif or the wrapper will have to probe these signals into the top level of the core (discuss with Steve what is best)

Further requirements (to be checked with assertions (some have to be at wrapper level I expect):

• NMI will not be reported on irq_ack
• Every irq_ack pulse must lead to rvfi_intr (but rvfi_intr is allowed to become 1 without a preceding irq_ack (in case of synchronous exceptions)
• Every dbg_ack pulse must lead to rvfi_dbg <> 0x0
• Every rvfi_dbg <> 0x0 must be preceded with dbg_ack pulse

cv32e40x_core.sv will look like the following:

module cv32e40x_core (
…
)

logic irq_ack; // Used (only) by verification environment
logic [4:0] irq_id; // Used (only) by verification environment
logic dbg_ack; // Used (only) by verification environment

assign irq_ack = ctrl_fsm.irq_ack; // Used (only) by verification environment (do not remove)
assign irq_id = ctrl_fsm.irq_id; // Used (only) by verification environment (do not remove)
assign dbg_ack = ctrl_fsm.dbg_ack; // Used (only) by verification environment (do not remove)

…

endmodule

Component

Component:RTL

Steps to Reproduce

Please provide:

1. Use this fork: https://github.com/strichmo/core-v-verif.git branch strichmo/temp/issue_197
2. 2d1908351bc9df5ee0020e91bb5074c032f529bc
3. makeuvmt comp_corev-dv gen_corev-dv test TEST=corev_rand_debug_ebreak SEED=1092908718
4. Xcelium 21.07.a001 was used to reproduce

The instruction at 0x12x is a write to MEPC:

     128:	022d0d13          	addi	x26,x26,34 # 146 <init>
                  csrw mepc, x26
     12c:	341d1073          	csrrw	x0,mepc,x26

The RVFI is showing that debug mode is entered after 0x128, but MEPC is reported as showing the updated value from x26 (0x146).

UVM_ERROR @ 456.300 ns : uvme_cv32e40x_core_sb.sv(370) uvm_test_top.env.core_sb [CORESB] CSR Mismatch, order: 13, csr: mepc, rvfi = 0x00000146, rvvi = 0x00000000

Note that it might be that the 0x12c instruction did indeed execute but it was missed on RVFI.

Now that NMIs have been added also the dcsr.nmips bit must be implemented and documented

The cv32e40x documentation regarding the core-v-x interface should only contain references to the official spec: https://docs.openhwgroup.org/projects/openhw-group-core-v-xif/ .

In addition, it may specify what is supported and what not, which signals are hardwired, etc which are related to implementation details

Following should be added to the PMA:

input logic misaligned_access_i,

Misaligned accesses to I/O should be forbidden.
On the instruction side: If attempting to execute from I/O and the access is misaligned as well, then the error related to the failed execute attempt has highest priority (so exception code 1).

The RVFI trace output format (https://cv32e40x-user-manual.readthedocs.io/en/latest/rvfi.html#trace-output-format) should be more nicely formatted itself. Make sure that the columns line up (e.g. by using tabs or tables).

Once okay, the same fix should be done in the 40S.

rvfi_dbg and rvfi_intr signals should be mutually exclusive; currently they can be signaled at the same time because of this code:

On the verification side the following code lib/uvm_agents/uvma_rvfi/uvma_rvfi_instr_mon.sv even assumes that intr is signaled when dbg is signaled (due to the nested if), and this should get corrected as well.

  if (mon_trn.intr) begin
             bit [XLEN-1:0] csr_mcause = mon_trn.csrs["mcause"].get_csr_retirement_data();

            if (mon_trn.dbg) begin
               bit [XLEN-1:0] csr_dcsr = mon_trn.csrs["dcsr"].get_csr_retirement_data();
               if (csr_dcsr[8:6] == 3'h3)
                  mon_trn.insn_dbg_req = 1;
            end
            else if (cfg.nmi_handler_enabled && mon_trn.pc_rdata == cfg.nmi_handler_addr)
               mon_trn.insn_nmi = 1;
            else if (csr_mcause[31]) begin               
               mon_trn.insn_interrupt    = 1;
               mon_trn.insn_interrupt_id = { 1'b0, csr_mcause[XLEN-2:0] };
            end
         end

The following line of code seems to mask an RTL bug:

This was allowed in commit 4a7e7e9 and should be investigated. Why can't pc_wdata[STAGE_ID] be trusted? It seems that the RTL updates that signal when it should not.

The e40x RTL defines at least one SystemVerilog Interface, if_c_obi which is used in several modules. It is my understanding that OpenHW has standardized on the Ibex Style Guide for RTL and this guide lists SV interfaces as problematic and their use is discouraged.

The Ibex team does not provided a rationale for that decision, and I have a pending question about it.

Is there a reason that we are using SV Interfaces in the RTL? I notice that packed structs are used in other areas of the RTL and perhaps it makes sense to standardize that.

The CLZ/CTZ instructions depend on the DIV operator, see

This operator is however not update for ALU instructions, see here:

#213 was merged before we had clarity on the supposed meaning of rvfi_mode (whether mprv needs to factor into this signal or not).

The current implementation is not aligned with Ibex.

This needs to be checked and if needed the RVFI + documentation needs to be adapted accordingly.

Hey!
I think there is a possible race between disable_iff and assertion. CLK signal which triggering assertion is set earlier than RST, so assertion will be executed and fail. Maybe good idea is change disable iff (!rst_n) to disable iff (rst_n != 1) in this way we will disable assertion when rst_n = x

LRM 1800-2017 chapter 16.12:

If the disable condition is true at anytime between the
        start of the attempt in the Observed region, inclusive, and
        the end of the evaluation attempt, inclusive, then the overall
        evaluation of the property results in disabled.

All counter (e.g. mcycle, cycle, cycleh, etc.) CSRs and the MIP CSR are updated autonomosly irrespective of instruction retirement. RVFI needs to report the _rdata values such that they match the value that a CSR read instruction would see them (so basically these values need to propagate through the RVFI pipeline starting in EX).

The RVFI interface connection to the core currently does not have _n and _we signals for the performance counters and mip. These CSRs are RW CSRs and should have these signals (even though there currently is not a single writeable bit in mip).

With respect to mcycle/minstret the RVFI spec says:

Incrementing those counters should happen "between instructions", this means for example that an instruction that isn't a CSR write to mcycle should always have rvfi_csr_mcycle_rdata == rvfi_csr_mcycle_wdata.

This also implies that rdata and wdata can be different for CSR writes to such counters.

From what I can see, the user manual lacks a description of the following:

• Valid number of PMA regions
• How non-matching regions should be treated

Additionally, I'm wondering if it would be a good idea to define a value for the atomic attribute in case of a lacking A-extension to facilitate assertion re-use. In other words, always tied high for main memory, as rv-spec requires main memory to support whichever atomic operations the core itself supports.

The CORE-V-Docs Documentation states in section 7.2 (Main memory vs I/O):

An attempt to perform a non-naturally aligned load access to an I/O region causes a precise load access fault (exception code 5). An attempt to perform a non-naturally aligned store access to an I/O region causes a precise store access fault (exception code 7).

Can I just quickly confirm that these should not be load address misaligned (4) and store/AMO address misaligned (6)? Thanks.

I tried to build the cv32e40x_core as checked into Git today (no modifications) and hit a compile error:

Error-[TFIPC-L] Too few instance port connections
/user/trs/work/trefor.southwell_SWANN/volcanic/MAIN/design/gen_PULAR_CONFIG21_VCS_sim_rgx_rogue4_tb/import/cv32e40x/rtl/cv32e40x_core.sv, 359
cv32e40x_core, "cv32e40x_id_stage #(.USE_PMP(USE_PMP), .A_EXTENSION(A_EXTENSION)) id_stage_i( .clk (clk), .clk_ungated_i (clk_i), .rst_n (rst_ni), .scan_cg_en_i (scan_cg_en_i), .fetch_enable_i (fetch_enable), .ctrl_busy_o (ctrl_busy), .is_decoding_o (is_decoding), .instr_req_o (instr_req_int), .branch_decision_i (branch_decision), .jmp_target_o (jump_target_id), .clear_instr_valid_o (clear_instr_valid), .pc_set_o (pc_set), .pc_mux_o (pc_mux_id), .exc_pc_mux_o (exc_pc_mux_id), .exc_cause_o (exc_cause), .halt_if_o (halt_if), .id_ready_o (id_ready), .ex_ready_i (ex_ready), .wb_ready_i (lsu_ready_wb), .id_valid_o (id_valid), .ex_valid_i (ex_valid), .if_id_pipe_i (if_id_pipe), .id_ex_pipe_o (id_ex_pipe), .current_priv_lvl_i (current_priv_lvl), .csr_c ... "
The above instance has fewer port connections than the module definition,
There are 70 port(s) in module "cv32e40x_id_stage" definition, but only 68
port connect(s) in the instance.
input port 'data_err_i' is not connected,
output port 'data_err_ack_o' is not connected.

Note - this is compiled outside the scripts in GIT using an alternative EDA flow.

Can I confirm from the documentation that dcsr[nmip] is always 0
If this is the case then when in debug mode (NMI Disabled), a load/store bus fault error condition cannot be detected ?

Some (but not all) of the type definitions use upper case symbols. Make all of them lower case only.

There are the ones I spotted (maybe there are more):

PrivLvl_t;
Status_t;
PrivLvl_t
Dcsr_t;
Mcause_t;
Mtvec_t;

Steps to Reproduce

Compile the head of master of the cv32e40x RTL on Metrics DSIM.

With the default PMA_NUM_REGIONS setting of 0, the PMA_CFG array is configured with a -1:0 range.

This needs to be fixed to ensure a 0:0 range via a conditional in the range derivation.

For reference a similar fix was applied to the CV32E40S to fix the same issue with DSIM.
openhwgroup/cv32e40s#38

This is blocking a PR on the core-v-verif so please let @strichmo know when this is ready to be tested. openhwgroup/core-v-verif#822

Non-naturally aligned half-word load/stores to PMA defined I/O regions do not trigger PMA access faults

PMA/LSU

Half-word accesses with address bit[1:0] = 01 to PMA I/O regions (including memory not covered by any PMA-region, i.e. I/O by default) does not trigger an access fault, as this is not considered misaligned by the LSU.
Only misaligned half-words that triggers another load/store operation is flagged as misaligned (i.e. bit[1:0] = 11 for halfword accesses).

The User Manual and RTL should be updated with the following:

• Allow atomic operations when PMA_NUM_REGIONS = 0
• Disallow atomic operations if PMA_NUM_REGIONS > 0, but the access does not match any region

Component

Component:RTL: For issues in the RTL (e.g. for files in the rtl directory)

Steps to Reproduce

1. Use the strichmo fork: https://github.com/strichmo/core-v-verif.git
2. Use this branch: strichmo/pr/common_mk_fw_rule_cleanup
3. Use this bash (Should be head of branch): 2fa98e975aba2fae9660d9d93c3ff23b4c0f2ddd
4. makeuvmt comp_corev-dv gen_corev-dv test TEST=corev_rand_interrupt_debug SEED=1638053781

The instruction retirement at 9451.8 is a debug handler entry due to debug entry request. However an interrupt is also acknowledge (30) at this instruction retirement. Therefore the core will save the entry of the next interrupt (0x6954) in DPC. The current RVFI monitor considers interrupts and debug request in a mutually exclusive manner. Therefore the RVVI/ISS never sees the interrupts and CSRs start mismatching.

Attempted fix

I added code to the RVFI monitor (in UVM) to allow an interrupt request and debug request in the same cycle. These are signaled to the RVVI in order of interrupt request, debug request, instruction retirement. This fixes the current condition above.

However when running this fix across other tests, I see the same conditions on RVFI for debug entries where there has not been an interrupt request.

The RVFI signals are (rvfi_valid == 1, rvfi_intr == 1, rvfi_dbg_mode == 0, rvfi_dbg == 3, mcause[31] = 0x1). Because mcause may be left over from a previous interrupt, the above combination of signals is not a guarantee that we are seeing an interrupt + debug "instruction". It appears that we need another signal to truly communicate that an interrupt handler was "taken" by the core (even if the actual PC jump is deferred by debug request).

Component

Component:RTL

The RTL appears to issue a mcause of 0x18 (24) instead of the quoted 48 from the CV32E40X User Manual.
https://cv32e40x-user-manual.readthedocs.io/en/latest/exceptions_interrupts.html?highlight=bus%20fault#exceptions

Steps to Reproduce

1. Use cv32e40x/dev branch of core-v-verif
2. 28591cf6860c20d03355b1df3944b95f73a619f7
3. makeuvmt test TEST=instr_bus_error SEED=1 CV_CORE=cv32e40x USE_ISS=0

Note the ISS is not quite ready so please run without it for now

The test should get in an infinite loop and will need to be interrupted with ctrl-c.

In the word-aligned bus error func
CV32E40X BSP: unknown exception handler entered

CV32E40X BSP: unknown exception handler entered

CV32E40X BSP: unknown exception handler entered

CV32E40X BSP: unknown exception handler entered

CV32E40X BSP: unknown exception handler entered

I am synthesizing the core in lattice radiant tool.

I am able to synthesize without cv32e40x_wrapper.sv file and it does fail in mapping as PIO's % is having more, So I am trying to synthesize with cv32e40x_wrapper.sv file. There I am getting the below errors.

I had included the source file as given in manifest file but I am getting an error as SVA's are not included and then when I include them(SVA) , getting an error as uvm_pkg is not declared.
Error:
analyzing included file /home/saqlinahamad.m/akhil/cv32e40x/git_subtrees/cv32e40x/sva/cv32e40x_alignment_buffer_sva.sv. VERI-1328
ERROR - synthesis: /home/saqlinahamad.m/akhil/cv32e40x/git_subtrees/cv32e40x/sva/cv32e40x_alignment_buffer_sva.sv(23): uvm_pkg is not declared. VERI-1128

Does uvm_pkg required? I don't think it required.
and I am not able to find the pkg file.

The current B decoder causes a register file read for both operands for all bit manipulation instructions:

decoder_ctrl_o.rf_re[0]         = 1'b1;
decoder_ctrl_o.rf_re[1]         = 1'b1;

This is not correct; for example CLZ only uses RS1 as source. All instructions should be checked and corrected if needed.

The user manual describes mtval as being RO hard-wired to zero.
https://cv32e40x-user-manual.readthedocs.io/en/latest/control_status_registers.html#machine-trap-value-mtval
This should be updated to match 40X/S plans.

Halting of execute stage

Commit 436d2b1 incorporates the ctrl_fsm.halt_ex into the execute stage's local instr_valid signal. This was done to be able to stall the execute stage to read the correct minstret value.

The SEC status of this change is currently not know, as the tool is running for a very long time. This must be revisited and updates once the run completes.

Component

Component:Other

The tracer in the RVFI (cv32e40x_rvfi_trace.svh) is emitting $fwrite calls with a filehandle of x. There should either be a proper file opened for this or a switch added to enable/disable rvfi tracing.

Steps to Reproduce

Run any test. In the debugger you should be able to see that the $fwrite calls are using an X filehandle.

You can also run Indago post-processing mode. In SmartLog, the stdout message contains these extra RVFI trace messages. Ideally these should be in their own file for easier filtering.

The address range specification in section 7.1? This doesn't look right. It says:

The address boundaries of a PMA region are set in word_addr_low/word_addr_high. These contain bits 33:2 of 34-bit, word aligned addresses. To get an address match, the transfer address addr must be in the range word_addr_low <= addr < word_addr_high.

As far as I can see this definition means that the address of the very top word of physical memory (0x3fffffffc) can never match a PMA region address. Is this right? Perhaps the comparison should be:

{word_addr_low,2'b00} <= {addr[33:2],2'b00} < {word_addr_high,2'b11}

In the RVFi module the following signals flow through the RVFI pipe in a non-standard (and non-commented) manner:

is_debug_entry_if;
is_debug_entry_id;
debug;

In particular the following should not be needed:

Can the IF stage be modeled with its handshake signals such that the 'debug' entry signal can flow through the RVFI pipeline in a standard manner?

A recent addition to the CV32E40X (sha 4206fff on 2021-04-27) introduced "negative indexes" for the PMA_CFG parameter. An example of this is bhv/cv32e40x_wrapper.sv:

module cv32e40x_wrapper
  import cv32e40x_pkg::*;
#(
  parameter NUM_MHPMCOUNTERS             =  1,
  parameter int unsigned PMA_NUM_REGIONS =  0,
  parameter pma_region_t PMA_CFG [PMA_NUM_REGIONS-1:0] = '{default:PMA_R_DEFAULT}
)

The default value of PMA_NUM_REGIONS is zero which means the range of PMA_CFG is [-1:0]. Most SV simulators will accept this, but Metrics DSIM interprets SV parameters as unsigned values (which, I believe is correct) and therefore the size of PMA_CFG is (2**31)-1 which exceeds a built-in DSIM limit.

In the documentation for bus load/store faults, these are described as Non Maskable, however in the interrupts section 14.2 it says

After reset, all interrupts are disabled.

To enable interrupts, both the global interrupt enable (MIE) bit in the mstatus CSR and the corresponding individual interrupt enable bit in the mie CSR need to be set

I am guessing this is ambiguous and that
A. load/store bus fault is NOT disabled after interrupt
B. load/store bus fault is NOT enabled by the global interrupt enable (MIE)

Also, the document says the following

All interrupt lines are level-sensitive

Is this correct ?
If NMI is truly level-sensitive AND it cannot be disabled by the interrupt enable MIE, then immediately upon taking the NMI it will trigger another NMI if it is still (level) active, creating a lockup, unable to execute any code.

Thx
Lee

In the ID stage csr_en is not suppressed for nullified instructions. This leads to the possibility that csr_en in ID is 1 while alu_en in ID is 0, such that the ALU operands into EX will not get updated (these are also used for CSR instructions). This doesn't cause a functional issue, but it causes different stall cycles and therefore SEC issues. It would be best to suppress csr_en (similar to how alu_en is suppressed) (a first attempt however led to timing issues).

The following line

Commit fc8f68d introduced decoding logic into the ALU that really belongs in the decoder, for example:

Now we are first encoding in the decoder and then again decoding in the ALU. Please check the effect of this transformation area wise relative to this commit.

Component

Component:RTL

Steps to Reproduce

Please provide:

1. Use this fork: https://github.com/strichmo/core-v-verif.git strichmo/temp/issue_197
2. 2d1908351bc9df5ee0020e91bb5074c032f529bc
3. makeuvmt comp_corev-dv gen_corev-dv test TEST=corev_rand_debug_ebreak SEED=-668398650
4. Xcelium 21.07.a001 was used to reproduce

After instruction 0x168a an external debug request is entered. Note this instruction is an illegal CSR access.

    168a:	39f07673          	csrrci	x12,0x39f,0
                  csrrc      tp, 0x35f, s8

When the debug handler is entered, the RTL (and RVFI) report that mscratch is updated to 0xf564, but the RVVI claims mscratch should still be 0x18204

238053.000 ns: Illegal instruction (core 0) at PC 0x0000168a:
UVM_ERROR @ 238128.300 ns : uvme_cv32e40x_core_sb.sv(370) uvm_test_top.env.core_sb [CORESB] CSR Mismatch, order: 10235, csr: mscratch, rvfi = 0x0000f564, rvvi = 0x00018204
UVM_ERROR @ 238161.300 ns : uvme_cv32e40x_core_sb.sv(370) uvm_test_top.env.core_sb [CORESB] CSR Mismatch, order: 10236, csr: mscratch, rvfi = 0x0000f564, rvvi = 0x00018204
UVM_ERROR @ 238179.300 ns : uvme_cv32e40x_core_sb.sv(370) uvm_test_top.env.core_sb [CORESB] CSR Mismatch, order: 10237, csr: mscratch, rvfi = 0x0000f564, rvvi = 0x00018204
UVM_ERROR @ 238197.300 ns : uvme_cv32e40x_core_sb.sv(370) uvm_test_top.env.core_sb [CORESB] CSR Mismatch, order: 10238, csr: mscratch, rvfi = 0x0000f564, rvvi = 0x00018204

Component

Component:RVFI
**Component:Doc **: For issues in the Documentation (e.g. for User Manual or README.md files)
Component:Other: For any other issues

Steps to Reproduce

Please provide:

1. e422fa37d0f5c50e526dbfddb01f927c7d1fd513 (cv32e40x/dev branch)
2. Using Xcelium 21.07.a001

%  makeuvmt test TEST=debug_test WAVES=1 ADV_DEBUG=1 SEED=1680260209 CV_CORE=cv32e40x

The RVFI will report the dpc CSR updating to the "next" instruction during the instruciton retirement of the stepped instruction (0xca94). However the ISS will always wait until the first instruction retirement in the debug handler before updating dpc to the next instruction (0xca98). This behavior is intermittent-not all single-stepped instructions show this behavior on RVFI.

Hi @Silabs-ArjanB ,

I did review your updated eXtension interface. In general, this looks good and I think the main limitation of the original CVXIF spec on back to back memory ops etc. are mitigated with your proposal.

Below, I have a list of remarks/questions regarding your proposal. I've posted them here as your proposal currently lives in this repo. Ultimately, it would be great if your proposal got merged into the CVXIF spec.

Compressed Instructions:

1. In case of compressed instructions, why does the core need the uncompressed instruction in the first place? Isn't it possible to to identify the rs/rd indices already from the compressed instruction?
2. Your proposal says "The instruction is originally compressed and the coprocessor accepted the compressed instruction and provided a 32-bit uncompressed instruction. In this case the 32-bit uncompressed instruction will be attempted for offload even if it matches in the core’s non-compressed instruction decoder." Does that mean it would be legal for a coprocessor to have instructions with uncompressed encodings overlapping with other instructions, e.g., of the base instruction set? Isn't that dangerous? Is this really necessary or did I misunderstand something?
3. Signal dependencies: In your proposal you note that CV32E40X splits the compressed/uncompressed decoders with a pipeline stage to avoid outputs depending directly on inputs. For simpler and configurable cores like Ibex and if one doesn't target max frequency, this might not be worth the complexity. Meaning such cores wouldn't comply with the spec. Should we make an exception here for simple cores? Or weaken the requirement into a recommendation?

Memory Transactions:

1. Should we specify load/store support on the core side as optional feature for the extension interface? Obviously for CV32E40X you will have it but I can imagine that the most simple cores/coprocessors don't need this.
2. For unaligned loads/stores (split into two aligned transactions) a PMP look-up is required for both aligned transactions. This means a synchronous PMP fault can happen in at least two cycles. I think the proposal and also the original spec currently can't handle this. Your proposal assumes that the fault is signaled in x_mem_resp_t during the x_mem_valid/ready handshake. We should probably discuss this.

Handshakes:

1. Some typos "The signals in x_issue_resp_i are valid when x_issue_req_o and x_issue_resp_i are both 1. There are no stability requirements." I think this should read "The signals in x_issue_resp_i are valid when x_issue_req_o and x_issue_ready_i are both 1. There are no stability requirements."
2. Two interfaces don't have a proper handshake: x_commit_valid_o/x_mem_result_valid_o. I assume this is to not make the core overly complex and I agree with this choice. But maybe we should discuss this in the working group and think if this can cause difficulties in the coprocessor that we didn't think of yet.
3. In the Handshake rules section (a space is needed between "with" and "``")
4. Your proposal specifies that valid can be dropped without ready in case an instruction gets killed (I agree with this). The next sentence then says: "A new transaction can be started by changing the id signal and keeping the valid signal asserted (thereby possibly terminating a previous transaction before it completed)." I would strictly specify that this is only possible due to the killl signal either. Or did you have some other scenario in mind here?

General remarks:

1. It's not 100% clear to me whether all interfaces are in-order or can be out-of-order. Your spec says "A coprocessor is allowed to provide results to the core in an out of order fashion." and at the same time "The transaction ordering on the result interface must correspond to the transaction ordering on the issue interface.".

Description

The link in the user manual for the cv32e40x that points to the relevant OBI doc in core-v-docs is incorrect.

Component

Indicate the component in which you found a problem (and we will add the appropriate label):

**Component:Doc **: For issues in the Documentation (e.g. for User Manual or README.md files)

Steps to Reproduce

Try the OPENHW-OBI link in this section of the user manul

https://cv32e40x-user-manual.readthedocs.io/en/latest/intro.html

The risc-v debug spec v 1.0.0-STABLE (33cd3a65f81f5bee710f204c1c6f70b46c818b31) states the following

If control is transferred to a trap handler while executing the instruction, then Debug Mode is re-entered immediately after the PC is changed to the trap handler, and the appropriate tval and cause registers are updated. In this case none of the trap handler is executed, and if the cause was a pending interrupt no instructions might be executed at all

The current RTL may execute the first instruction of the interrupt handler, and enter debug with dpc set to handler+1. According to the spec, the RTL should in this case not retire any instructions, and enter debug with dpc set to handler+0 instead.

If the interrupt comes when an LSU instruction has reached WB, or an LSU instruction stays in EX for more than one cycle waiting for gnt, the interrupt cannot be taken and debug is entered with dpc set to point at the instruction after the LSU instruction. The interrupt will then be taken during the next step.

Task Outcome

The current cv32e40x_wrapper module leaves the RVFI output signals from cv32e40x_rvfi are unconnected. When compiling in simulation a huge amount of unconnected output warnings are generated.

xmelab: *W,CUVWSP (/work/strichmo/ip_rad_riscv/mdx_e40x/modules/core-v-verif/core-v-cores/cv32e40x/bhv/cv32e40x_wrapper.sv,260|11): 162 output ports were not connected:
xmelab: (/work/strichmo/ip_rad_riscv/mdx_e40x/modules/core-v-verif/core-v-cores/cv32e40x/bhv/cv32e40x_rvfi.sv,152): rvfi_valid
xmelab: (/work/strichmo/ip_rad_riscv/mdx_e40x/modules/core-v-verif/core-v-cores/cv32e40x/bhv/cv32e40x_rvfi.sv,153): rvfi_order
xmelab: (/work/strichmo/ip_rad_riscv/mdx_e40x/modules/core-v-verif/core-v-cores/cv32e40x/bhv/cv32e40x_rvfi.sv,154): rvfi_insn
xmelab: (/work/strichmo/ip_rad_riscv/mdx_e40x/modules/core-v-verif/core-v-cores/cv32e40x/bhv/cv32e40x_rvfi.sv,155): rvfi_trap

Currently the RVFI Agent from core-v-verif binds directly to the cv32e40x_rvfi module and no output ports are required for simulation.

Since these outputs may be necessary for other contexts, I would like to see these cleaned up.

Background information

Compile the core-v-verif testbench to see warnings.
% makeuvmt clean comp CV_CORE=cv32e40x

Completion Criteria

Rerun the compilation above from clean and verify the warnings are not emitted.

Commit 4a7e7e9 should not have increased area so much; likely we need to register the minstret increment event before using it (and also increase the related minstret CSR read hazard)

Analyze effects of removing branch bypass and whether it affects design choices for the new controller.

The commit with bypass removed:
94c89ff

Currently, a trigger match is computed based on the ID stage PC.
If a trigger match occurs, all write enables out of the decoder is suppressed.

By changing to using the IF stage PC, we can avoid a few gates from the PC comparison into the 'deassert_we_special' signal used in the decoder.

On the current master, this change is not SEC equivalent though, as single step + interrupts are not handled correctly (issue #196).
Revisit changing to using IF PC for trigger match after issue #196 has been closed.