eXtension Interface

The eXtension interface, also called CORE-V-XIF, enables extending CV32E40X with (custom or standardized) instructions without the need to change the RTL of CV32E40X itself. Extensions can be provided in separate modules external to CV32E40X and are integrated at system level by connecting them to the eXtension interface.

The eXtension interface provides low latency (tightly integrated) read and write access to the CV32E40X register file. All opcodes which are not used (i.e. considered to be invalid) by CV32E40X can be used for extensions. It is recommended however that custom instructions do not use opcodes that are reserved/used by RISC-V International.

The eXtension interface enables extension of CV32E40X with:

Custom ALU type instructions.
Custom load/store type instructions.
Custom CSRs and related instructions.

Control-Tranfer type instructions (e.g. branches and jumps) are not supported via the eXtension interface.

Note

CV32E40X does for example not implement the F (single-precision floating-point), P (Packed SIMD) or V (Vector) extensions internal to the core. Such extensions are considered good candidates to be implemented as external coprocessor functionality connected via the eXtension interface.

CORE-V-XIF

The eXtension interface of complies to the [OPENHW-XIF] specification. The reader is deferred to [OPENHW-XIF] for explanation of the interface protocol and semantics. Here we only list the top level interface pins to clarify the mapping of CV32E40X’s SystemVerilog interfaces to CV32E40X signals.

Compressed interface

Table 8 describes the compressed interface signals.

Table 8 Compressed interface signals
Signal	Type	Direction	Description
`xif_compressed_if.compressed_valid`	logic	output	Compressed request valid. Request to uncompress a compressed instruction.
`xif_compressed_if.compressed_ready`	logic	input	Compressed request ready. The transactions signaled via `compressed_req` and `compressed_resp` are accepted when `compressed_valid` and `compressed_ready` are both 1.
`xif_compressed_if.compressed_req`	x_compressed_req_t	output	Compressed request packet.
`xif_compressed_if.compressed_resp`	x_compressed_resp_t	input	Compressed response packet.

Issue interface

Table 9 describes the issue interface signals.

Table 9 Issue interface signals
Signal	Type	Direction	Description
`xif_issue_if.issue_valid`	logic	output	Issue request valid. Indicates that CV32E40X wants to offload an instruction.
`xif_issue_if.issue_ready`	logic	input	Issue request ready. The transaction signaled via `issue_req` and `issue_resp` is accepted when `issue_valid` and `issue_ready` are both 1.
`xif_issue_if.issue_req`	x_issue_req_t	output	Issue request packet.
`xif_issue_if.issue_resp`	x_issue_resp_t	input	Issue response packet.

Commit interface

Table 10 describes the commit interface signals.

Table 10 Commit interface signals
Signal	Type	Direction	Description
`xif_commit_if.commit_valid`	logic	output	Commit request valid. Indicates that CV32E40X has valid commit or kill information for an offloaded instruction. There is no corresponding ready signal (it is implicit and assumed 1). The coprocessor shall be ready to observe the `commit_valid` and `commit_kill` signals at any time coincident or after an issue transaction initiation.
`xif_commit_if.commit`	x_commit_t	output	Commit packet.

Memory (request/response) interface

Table 11 describes the memory (request/response) interface signals.

Table 11 Memory (request/response) interface signals
Signal	Type	Direction	Description
`xif_mem_if.mem_valid`	logic	input	Memory (request/response) valid. Indicates that the coprocessor wants to perform a memory transaction for an offloaded instruction.
`xif_mem_if.mem_ready`	logic	output	Memory (request/response) ready. The memory (request/response) signaled via `mem_req` is accepted by CV32E40X when `mem_valid` and `mem_ready` are both 1.
`xif_mem_if.mem_req`	x_mem_req_t	input	Memory request packet.
`xif_mem_if.mem_resp`	x_mem_resp_t	output	Memory response packet. Response to memory request (e.g. PMA check response). Note that this is not the memory result.

Memory result interface

Table 12 describes the memory result interface signals.

Table 12 Memory result interface signals
Signal	Type	Direction	Description
`xif_mem_result_if.mem_result_valid`	logic	output	Memory result valid. Indicates that CV32E40X has a valid memory result for the corresponding memory request. There is no corresponding ready signal (it is implicit and assumed 1). The coprocessor must be ready to accept `mem_result` whenever `mem_result_valid` is 1.
`xif_mem_result_if.mem_result`	x_mem_result_t	output	Memory result packet.

Result interface

Table 13 describes the result interface signals.

Table 13 Result interface signals
Signal	Type	Direction	Description
`xif_result_if.result_valid`	logic	input	Result request valid. Indicates that the coprocessor has a valid result (write data or exception) for an offloaded instruction.
`xif_result_if.result_ready`	logic	output	Result request ready. The result signaled via `result` is accepted by the core when `result_valid` and `result_ready` are both 1.
`xif_result_if.result`	x_result_t	input	Result packet.

Integration

When integrating the eXtension interface, all parameters used by both CV32E40X, the SystemVerilog interface and the coprocessor/interconnect must match. Parameters or localparams should be used at the hierarchy level above CV32E40X as shown in Figure 11.

Timing

For optimal system level performance CV32E40X, the coprocessor(s) and the optional interconnect are advised to adhere to the timing budgets shown in Figure 12.

All eXtension interface signals not explicitly covered in Figure 12 should follow the generic timing budget that is outlined - 20% for the processor, 20% for the interconnect and 60% for the coprocessor.

The CV32E40X github repository contains a constraints file as seen from the processor: cv32e40x_core.sdc