Instruction Fetch Requests Generate X's during Fuzz Testing

Placeholder Christopher Nokes
2025-01-27T13:35:17Z

## Instruction Fetch Requests Generate X's during Fuzz Testing
During fuzz testing, instruction requests (instr_req_o and instr_reqpar_o) can have X's.

This seems to be because of a cyclic path of unclocked signals across stages:
lsu_ready_i (execute stage) controls wb_ready_o (execute stage)
wb_ready_o (execute stage) controls wb_ready_i (controller)
wb_ready_i (controller) controls lsu_ready_o (controller)
lsu_ready_o (controller) controls ready_0_i (load/store stage)
ready_0_i (load/store stage) controls ready_0_o (load/store stage)
ready_0_o (load/store stage) controls lsu_ready_i (execute stage)

In cases where instr_req_o is not X, it is because this path is cancelled out (IE: OR'd with 1, AND'd with 0) by additional logic somewhere along the way.

Additionally, if the PMP is enabled and configured, the X may occur during a cycle where instr_addr_o should not be accessible by the core (EX: if MMWP is set, the core may set instr_req_o = X while instr_addr_o is not covered by the PMP).

### Component
Issue seems to span multiple RTL components, namely cv32e40s_ex_stage.sv, cv32e40s_controller.sv, cv32e40s_load_store_unit.sv, and cv32e40s_core.sv.

### Steps to Reproduce
1. Use [this fuzz test](https://github.com/cnokes14/CV32E40S-Fuzz-Integrity-Checking-TB/blob/main/cv32e40s_fuzz_tb.sv).
2. X's seem to occur relatively frequently.

![Image](https://github.com/user-attachments/assets/9228a689-c387-4d00-929a-09034d9b7bb2)
This screenshot is from running the test I provided. Of note, the X that occurs at 185ns occurs alongside an instruction address which should be blocked by the PMP.