To decouple the development of accelerators and cores, it may be beneficial separate the handling of offloaded instructions from the rest of the core's operation.
The interaction with the accelerator interface does not necessarily need to originate from the offloading core itself. Optimally, no change to the HDL of a core would be necessary in order to support custom ISA extensions. In order for the accelerator interface to be used with an accelerator-agnostic core, the necessary signals need to be generated outside of the core. An external pre-decoder structure may be implemented to facilitate this use case.
One possible implementation of such a structure is sketched below.
The core exposes the source registers which are eligable to be used for accelerator operands, as well as the RISC-V instruction data. The accelerator predecoder consists of a wrapper module, containing an immediate value decoder, operand multiplexers, handshaking logic for communication with the core and the accelerator interface and a dedicated predecoder for each implemented accelerator. Each of the dedicated predecoders generates a signal indicating an offload candidate instruction on its accelerator (offl_accept) as well as operand selection signals.
Once the core detects an unimplemented instruction, it initiates a handshake with the predecoder wrapper. If the instruction is an offload candidate for any of the accelerators, the offload request is accepted and forwarded via the accelerator interface. In parallel with the offload_accept signal, the predecoder wrapper must specify to the core if a writeback is to be expected from this operation.* The accelerator address is determined by which of the predecoders has accepted the operation. The operands are selected as specified by the winning predecoder and may come from the source registers or an encoded immediate value.
* A simpler scheme to indicate an expected writeback would be to require the destination address for fire-and-forget instructions to be zero. However, this precludes the possibility to offload S- and B-Type register-immediate instructions as the rd address field is part of the immediate encoding. To generate a separate signal indicating an expected writeback only marginally complicates the accelerator predecoder.
To decouple the development of accelerators and cores, it may be beneficial separate the handling of offloaded instructions from the rest of the core's operation.
The interaction with the accelerator interface does not necessarily need to originate from the offloading core itself. Optimally, no change to the HDL of a core would be necessary in order to support custom ISA extensions. In order for the accelerator interface to be used with an accelerator-agnostic core, the necessary signals need to be generated outside of the core. An external pre-decoder structure may be implemented to facilitate this use case.
One possible implementation of such a structure is sketched below.
The core exposes the source registers which are eligable to be used for accelerator operands, as well as the RISC-V instruction data. The accelerator predecoder consists of a wrapper module, containing an immediate value decoder, operand multiplexers, handshaking logic for communication with the core and the accelerator interface and a dedicated predecoder for each implemented accelerator. Each of the dedicated predecoders generates a signal indicating an offload candidate instruction on its accelerator (
offl_accept) as well as operand selection signals.Once the core detects an unimplemented instruction, it initiates a handshake with the predecoder wrapper. If the instruction is an offload candidate for any of the accelerators, the offload request is accepted and forwarded via the accelerator interface. In parallel with the
offload_acceptsignal, the predecoder wrapper must specify to the core if a writeback is to be expected from this operation.* The accelerator address is determined by which of the predecoders has accepted the operation. The operands are selected as specified by the winning predecoder and may come from the source registers or an encoded immediate value.* A simpler scheme to indicate an expected writeback would be to require the destination address for fire-and-forget instructions to be zero. However, this precludes the possibility to offload S- and B-Type register-immediate instructions as the
rdaddress field is part of the immediate encoding. To generate a separate signal indicating an expected writeback only marginally complicates the accelerator predecoder.