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.
Signal |
Type |
Direction |
Description |
|
logic |
output |
Compressed request valid. Request to uncompress a compressed instruction. |
|
logic |
input |
Compressed request ready. The transactions signaled via |
|
x_compressed_req_t |
output |
Compressed request packet. |
|
x_compressed_resp_t |
input |
Compressed response packet. |
Issue interface
Table 9 describes the issue interface signals.
Signal |
Type |
Direction |
Description |
|
logic |
output |
Issue request valid. Indicates that CV32E40X wants to offload an instruction. |
|
logic |
input |
Issue request ready. The transaction signaled via |
|
x_issue_req_t |
output |
Issue request packet. |
|
x_issue_resp_t |
input |
Issue response packet. |
Commit interface
Table 10 describes the commit interface signals.
Signal |
Type |
Direction |
Description |
|
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 |
|
x_commit_t |
output |
Commit packet. |
Memory (request/response) interface
Table 11 describes the memory (request/response) interface signals.
Signal |
Type |
Direction |
Description |
|
logic |
input |
Memory (request/response) valid. Indicates that the coprocessor wants to perform a memory transaction for an offloaded instruction. |
|
logic |
output |
Memory (request/response) ready. The memory (request/response) signaled via |
|
x_mem_req_t |
input |
Memory request packet. |
|
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.
Signal |
Type |
Direction |
Description |
|
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
|
|
x_mem_result_t |
output |
Memory result packet. |
Result interface
Table 13 describes the result interface signals.
Signal |
Type |
Direction |
Description |
|
logic |
input |
Result request valid. Indicates that the coprocessor has a valid result (write data or exception) for an offloaded instruction. |
|
logic |
output |
Result request ready. The result signaled via |
|
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