Clarification for usage scenarios for FCFETCH and FCBOOT CSRs

Placeholder Ayush Mewati
2025-08-12T05:26:26Z

Hi `@MikeOpenHWGroup`,

The intent for this issue is to seek clarification on some registers and pins, and their functionality, in the Core-V MCU SoC.
Registers: `FCBOOT `and `FCFETCH `in the APB SoC Controller
Pins: `fetch_enable_i `and `boot_addr_i `in the Core-Complex (cv32e40p core).

As per the Core-V MCU specifications:
https://docs.openhwgroup.org/projects/core-v-mcu/doc-src/ip-blocks/apb_soc_ctrl.html#apb-soc-controller-csrs

`FCBOOT` and `FCFETCH `are memory-mapped CSRs in the APB SoC Controller with default values of **FCBOOT:0x1A000080** and **FCFETCH:0x1**.

And as per the cv32e40p specifications:
https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/cv32e40p_v1.8.3/integration.html

- `fetch_enable_i`: The first instruction fetch after reset de-assertion will not happen as long as this signal is 0. fetch_enable_i needs to be set to 1 for at least one cycle while not in reset to enable fetching. Once fetching has been enabled the value `fetch_enable_i `is ignored.

- `boot_addr_i`: First program counter after reset = `boot_addr_i`. Must be half-word aligned. Do not change after enabling core via `fetch_enable_i`.

Since, there are default values in the FCBOOT and FCFETCH registers, which drive the pins for the core-complex (as mentioned above), **we would like to understand that under what circumstances can the FCBOOT/FCFETCH registers be written before the Core actually starts execution.**

From what we understand, usually, the memory-mapped CSRs will be read/written via a memory load/store operation. For Core-V MCU, this operation can be issued on the TCDM interconnect by:

1. The Core-Complex
2. The Debug Module

If it's the core-complex that's issuing the CSR write, it needs to happen via a **bare metal code (FW)** for which, the **default values** of FCFETCH and FCBOOT would already have been utilized by the core (as FCFETCH is 0x1 by default, core starts fetching immediately after reset) and the **fetch_enable_i will be ignored afterwards** (as per cv32e40p specs). Only way to do that will be to apply another reset, upon which the APB SoC controller registers will also be reset to default values as APB SoC controller and the Core-Complex share a common reset hence discarding the modifications done to the CSRs.

If it's the debug module, there can be a possibility where an external-debugger modifies the CSRs before it lets the Core start the execution and hence, effectively utilizing the modifications to the CSRs.

This will mean that modifications to FCBOOT and FCFETCH **are applicable only when the core is intercepted before it starts execution via the debug module**, i.e., with an external-debugger attached, otherwise the default values will be used in the simulation.

We would like to understand if there are any other scenarios we might have missed where we can write FCFETCH=0x0, modify FCBOOT and enable fetching by writing FCFETCH=0x1.

Looking forward to hearing from you.

Best Regards.