Clarification for usage scenarios for FCFETCH and FCBOOT CSRs

[cst-ayushm]

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.

[MikeOpenHWGroup]

Yes, this confused me as well, @cst-ayushm, so I am glad you are looking at this. The MCU User Manual should explain this.

The short answer to your question is that while it is possible to modify FCBOOT, in the MCU application doing so is not supported. As you have seen, FCBOOT is a RW register, so it is possible for software running on the core to modify it, thereby changing the value of boot_addr_i. However, the core will not use that new value unless it is reset and doing so will also reset the value of FCBOOT to 0x1A000080.

We could change this, but I don't think we should. This implies that the Configure Boot Parameters sub-section of the current User Manual is incorrect, and needs to be updated.

[cst-ayushm]

Hi Mike,

Thanks for your response!

Just wanted to check (out of curiosity) if FCFETCH defaulting to 0x0 will fix this (and make sense, at this point)? In order to provide opportunity for the FW to configure FCBOOT (if required) and then enable fetching by writing FCFETCH=0x1.

Or do we want to keep this functionality applicable for debug simulations only (in that case, the "Configure Boot Parameters" section can be omitted from the FW guidelines)?

Best regards.

[MikeOpenHWGroup]

I do not see how this will work. If the reset value of FCFETCH register is 0x0, the CV32E40P core will attempt to read an instruction from 0x0. As spec'ed in the Memory Map, there is nothing at that address.

In the CORE-V-MCU, the hardware implementation places the boot ROM at 0x1A00-0000, and there is no mechanism in the hardware to change that. So we should leave the reset value of FCFETCH where it is.

[cst-ayushm]

Hi Mike,

To avoid any misunderstanding, please let me rephrase and elaborate.

FCFETCH is register responsible to drive fetch_enable_i pin of the CV32E40P, which is the pin that controls "when" the core starts fetching.
The other register is FCBOOT, which drives the boot_addr_i pin of the core, controlling "where" the fetching starts from.

And I wanted to understand if having FCFETCH default to 0x0, leaving FCBOOT as it is (defaulting to 0x1A000080) would be helpful i.e., the core has a default address to fetch from, but if required, can be modified before enabling the fetch.

In the CORE-V-MCU, the hardware implementation places the boot ROM at 0x1A00-0000, and there is no mechanism in the hardware to change that. So we should leave the reset value of FCFETCH where it is.

Assuming you meant FCBOOT here, yes I do agree.
So, in this case do we really want FCBOOT to be a RW register?

Please let me know your thoughts.

Best Regards.

[MikeOpenHWGroup]

Sorry, yes I meant to say "we should leave the reset value of FCBOOT where it is". Also, I do not see any benefit of keeping FCBOOT as a RW register - as far as I am aware, there is no capability for the core to fetch boot code from any other non-volatile memory region or peripheral.

[cst-ayushm]

Hi Mike,

Thanks for your inputs!

To summarize, the User Manual for APB SoC Controller should be updated to reflect the intent better.
This will cover the following:

1. Update the FCFETCH and FCBOOT registers to be Read-Only.
2. Remove the sub-section Configure Boot Parameters from the manual.

Please let me know your thoughts.
If this makes sense, and sounds complete, we can proceed and make the required updates to the APB SoC Controller docs.

Best regards.

[MikeOpenHWGroup]

I fully agree with you, this is what we should do. However, now we are making changes to the User Manual that are not reflected in the RTL:

1. The FCFETCH and FCBOOT CSRs are currently RW, so we would need to change apb_soc_ctrl.sv to make them RO.
2. Looking a second time at the RTL, it appears that is should be possible to execute the scenario discussed in the Configure Boot Parameters from the debug unit, so we would need to change that also.

I would rather not change the RTL unless we have to, so I suggest we update the Configure Boot Parameters sub-section of the User Manual to the following:

It is possible to force the CV32E40P core to reboot from a user-specified address from the debugger, via the following procedure:
- Write the desired boot address to the FCBOOT CSR at offset 0x04.
- Force a reset of the core from the debugger.

The fetch enable bit of FCFETCH CSR at offset 0x08 is enabled by default i.e. the Fabric Control/Core-Complex will start fetching instructions from the provided address.

Give me some time to confirm that the above is 100% correct.

[cst-ayushm]

Hi Mike,

Hope you're doing well.
Following up on our previous discussion - could you please share your thoughts on the best direction forward?

Best regards.

[MikeOpenHWGroup]

Hi @cst-ayushm, I have not forgotten about this. The person I need to speak with about this is currently unavailable, but I will ensure this Issue gets resolved as soon as they return.

[cst-ayushm]

Thank you for checking on this!
Looking forward to hearing from you and getting this issue resolved.

Best regards.