CV-X-IF Interface and Coprocessor

The CV-X-IF interface of CVA6 allows to extend its supported instruction set with external coprocessors.

Applicability of this chapter to configurations:

Configuration	Implementation
CV32A60AX	CV-X-IF included
CV32A60X	CV-X-IF included
CV64A6_MMU	CV-X-IF included

CV-X-IF interface specification

Description

This design specification presents global functionalities of Core-V-eXtension-Interface (XIF, CVXIF, CV-X-IF, X-interface) in the CVA6 core.

The CORE-V X-Interface is a RISC-V eXtension interface that provides a
generalized framework suitable to implement custom coprocessors and ISA
extensions for existing RISC-V processors.

--core-v-xif Readme, https://github.com/openhwgroup/core-v-xif

The specification of the CV-X-IF bus protocol can be found at [CV-X-IF].

CV-X-IF aims to:

Create interfaces to connect a coprocessor to the CVA6 to execute instructions.
Offload CVA6 illegal instrutions to the coprocessor to be executed.
Get the results of offloaded instructions from the coprocessor so they are written back into the CVA6 register file.
Add standard RISC-V instructions unsupported by CVA6 or custom instructions and implement them in a coprocessor.
Kill offloaded instructions to allow speculative execution in the coprocessor. (Unsupported in CVA6 yet)
Connect the coprocessor to memory via the CVA6 Load and Store Unit. (Unsupported in CVA6 yet)

The coprocessor operates like another functional unit so it is connected to the CVA6 in the execute stage.

Only the 3 mandatory interfaces from the CV-X-IF specification (issue, commit and result ) have been implemented. Compressed interface, Memory Interface and Memory result interface are not yet implemented in the CVA6.

Supported Parameters

The following table presents CVXIF parameters supported by CVA6.

Signal	Value	Description
X_NUM_RS	int: 2 or 3 (configurable)	Number of register file read ports that can be used by the eXtension interface
X_ID_WIDTH	int: 3	Identification width for the eXtension interface
X_MEM_WIDTH	n/a (feature not supported)	Memory access width for loads/stores via the eXtension interface
X_RFR_WIDTH	int: `XLEN` (32 or 64)	Register file read access width for the eXtension interface
X_RFW_WIDTH	int: `XLEN` (32 or 64)	Register file write access width for the eXtension interface
X_MISA	logic[31:0]: 0x0000_0000	MISA extensions implemented on the eXtension interface

CV-X-IF Enabling

CV-X-IF can be enabled or disabled via the CVA6ConfigCvxifEn parameter in the SystemVerilog source code.

Illegal instruction decoding

The CVA6 decoder module detects illegal instructions for the CVA6, prepares exception field with relevant information (exception code “ILLEGAL INSTRUCTION”, instruction value).

The exception valid flag is raised in CVA6 decoder when CV-X-IF is disabled. Otherwise it is not raised at this stage because the decision belongs to the coprocessor after the offload process.

RS3 support

The number of source registers used by the CV-X-IF coprocessor is configurable with 2 or 3 source registers.

If CV-X-IF is enabled and configured with 3 source registers, a third read port is added to the CVA6 general purpose register file.

Description of interface connections between CVA6 and Coprocessor

In CVA6 execute stage, there is a new functional unit dedicated to drive the CV-X-IF interfaces. Here is how and to what CV-X-IF interfaces are connected to the CVA6.

Issue interface
- Request
  
  Operands are connected to issue_req.rs signals
  
  Scoreboard transaction id is connected to issue_req.id signal.
  
  Therefore scoreboard ids and offloaded instruction ids are linked
  
  together (equal in this implementation). It allows the CVA6 to do out
  
  of order execution with the coprocessor in the same way as other
  
  functional units.
  
  Undecoded instruction is connected to issue_req.instruction
  
  Valid signal for CVXIF functional unit is connected to
  
  issue_req.valid
  
  All issue_req.rs_valid signals are set to 1. The validity of source
  
  registers is assured by the validity of valid signal sent from issue stage.
- Response
  
  If issue_resp.accept is set during a transaction (i.e. issue valid
  
  and ready are set), the offloaded instruction is accepted by the coprocessor
  
  and a result transaction will happen.
  
  If issue_resp.accept is not set during a transaction, the offloaded
  
  instruction is illegal and an illegal instruction exception will be
  
  raised as soon as no result transaction are written on the writeback bus.
Commit interface
- Valid signal of commit interface is connected to the valid signal of
  
  issue interface.
- Id signal of commit interface is connected to issue interface id signal
  
  (i.e. scoreboard id).
- Killing of offload instruction is never set. (Unsupported feature)
- Therefore all accepted offloaded instructions are commited to their
  
  execution and no killing of instruction is possible in this implementation.
Result interface
- Request
  
  Ready signal of result interface is always set as CVA6 is always ready
  
  to take a result from coprocessor for an accepted offloaded instruction.
- Response
  
  Result response is directly connected to writeback bus of the CV-X-IF
  
  functionnal unit.
  
  Valid signal of result interface is connected to valid signal of
  
  writeback bus.
  
  Id signal of result interface is connected to scoreboard id of
  
  writeback bus.
  
  Write enable signal of result interface is connected to a dedicated CV-X-IF WE
  
  signal in CVA6 which signals scoreboard if a writeback should happen
  
  or not to the CVA6 register file.
  
  exccode and exc signal of result interface are connected to exception
  
  signals of writeback bus. Exception from coprocessor does not write
  
  the tval field in exception signal of writeback bus.
  
  Three registers are added to hold illegal instruction information in
  
  case a result transaction and a non-accepted issue transaction happen
  
  in the same cycle. Result transactions will be written to the writeback
  
  bus in this case having priority over the non-accepted instruction due
  
  to being linked to an older offloaded instruction. Once the writeback
  
  bus is free, an illegal instruction exception will be raised thanks to
  
  information held in these three registers.

Coprocessor recommendations for use with CVA6’s CV-X-IF

CVA6 supports all coprocessors supporting the CV-X-IF specification with the exception of :

Coprocessor requiring the Memory interface and Memory result interface (not implemented in CVA6 yet).
- All memory transaction should happen via the Issue interface, i.e. Load into CVA6 register file then initialize an issue transaction.
Coprocessor requiring the Compressed interface (not implemented in CVA6 yet).
- RISC-V Compressed extension (RVC) is already implemented in CVA6. User Space for custom compressed instruction is not big enough to have RVC and a custom compressed extension.
Stateful coprocessors.
- CVA6 will commit on the Commit interface all its issue transactions. Speculation informations are only kept in the CVA6 and speculation process is only done in CVA6. The coprocessor shall be stateless otherwise it will not be able to revert its state if CVA6 kills an in-flight instruction (in case of mispredict or flush).

How to use CVA6 without CV-X-IF interface

Select a configuration with CVA6ConfigCvxifEn parameter disabled or change it for your configuration.

Never let the CV-X-IF interface unconnected with the CVA6ConfigCvxifEn parameter enabled.

How to design a coprocessor for the CV-X-IF interface

The team is looking for a contributor to write this section.

How to program a CV-X-IF coprocessor

The team is looking for a contributor to write this section.