Questions regarding custom instruction extension using the CFU interface

[Kyrie-T]

Subject: Inquiry about the best practices for implementing custom instructions via CFU

Hello NEORV32 Team,

I am a beginner exploring the NEORV32 processor, and I am planning to implement a custom instruction extension using the CFU (Custom Functions Unit). I have a few questions regarding the integration process:

1. Scope of Modification: Aside from implementing the logic in neorv32_cfu.vhd and enabling RISCV_ISA_Zxcfu in the top entity, are there any mandatory modifications required in the core pipeline (e.g., neorv32_cpu_control.vhd) to support new custom-X opcodes?
2. Pipeline Latency: If my custom logic requires multiple clock cycles, how should I properly handle the cfu_done_o signal to ensure the CPU pipeline stalls correctly? Is there a recommended maximum latency?
3. Software Toolchain: For a beginner, is it recommended to use the neorv32_cfu.h intrinsic functions, or should I define my own inline assembly macros to trigger the CFU?
4. Verification: Is there a specific testbench or a minimal software example you recommend for verifying that the CFU is correctly communicating with the register file?

Thank you for your time and for this great open-source project!

[stnolting]

Hey @Kyrie-T.

I am planning to implement a custom instruction extension using the CFU

That sounds cool. Can you tell what kind of extension(s) you are planning?

1. Scope of Modification: Aside from implementing the logic in neorv32_cfu.vhd and enabling RISCV_ISA_Zxcfu in the top entity, are there any mandatory modifications required in the core pipeline (e.g., neorv32_cpu_control.vhd) to support new custom-X opcodes?

The CFU is responsible for doing all the "this is a valid CFU instruction" decoding. So, no. You just need to integrate your code into the CFU.

Btw, we have renamed the CFU ISA extension from Zxcfu to Xcfu to comply with the RISC-V naming scheme for custom extensions: #1487

2. Pipeline Latency: If my custom logic requires multiple clock cycles, how should I properly handle the cfu_done_o signal to ensure the CPU pipeline stalls correctly? Is there a recommended maximum latency?

Good question! The CFU is just another ALU co-processor unit (like the FPU). So, multi-cycle operations are already supported by default. The CPU pipeline will stall until your CFU has completed operation. However, there is an upper limit on the number of execution cycles (see https://stnolting.github.io/neorv32/#_cpu_arithmetic_logic_unit):

Note

The CPU control will raise an illegal instruction exception if a multi-cycle functional unit (like the Custom Functions Unit (CFU)) does not complete processing in a bound amount of time (configured via the package's alu_cp_tmo_c constant; default = 512 clock cycles).

3. Software Toolchain: For a beginner, is it recommended to use the neorv32_cfu.h intrinsic functions, or should I define my own inline assembly macros to trigger the CFU?

This is up to you. If the standard instruction formats are sufficient for you, then I would recommend to start with the pre-defined intrinsics.

4. Verification: Is there a specific testbench or a minimal software example you recommend for verifying that the CFU is correctly communicating with the register file?

The default CFU from this repo implements the XTEA block cipher as illustrative example (see rtl/core/neorv32_cpu_alu_cfu.vhd). There is a demo program that uses this XTEA CFU to do some HW/SW encryption and decryption: sw/example/demo_cfu/main.c

Maybe you use that as starting point.

Don't worry too much about the communication. We have built a kind of proxy logic around the CFU. This prevents the CFU from disrupting the pipeline if there are any flaws in the CFU operation / handshake.

Just make sure the NEORV32 Runtime Environment (RTE) is enabled and a UART is available. If the CFU goes, the RTE will notify you. 😉