[BUG] RF write enable is driven by issue interface instead of the result interface

[inigodiezulzu]

Bug Description

I was reviewing the CVE2 ID stage implementation and had a question regarding the use of the writeback signal for writing to the register file.

According to the documentation, the writeback signal is asserted by the co-processor to indicate that it will write a result into the register file. We initially assumed this signal is only driven during the issue handshake, and expected that the result interface's write enable signal would control the actual write into the register file.

However, in the code (see cve2_id_stage.sv#L504), it appears that the writeback signal is used again to enable writing, even though no data exchange occurs at that point.

Could you clarify why the design uses the writeback signal here instead of the result interface’s write enable? Is there a timing or architectural reason that makes the writeback signal necessary at this stage?

Thanks in advance for the clarification!

[MikeOpenHWGroup]

@FrancescoDeMalde-synthara, can you have a look?

[FrancescoDeMalde-synthara]

In the current CV-X-IF integration for CVE2, when an offloaded instruction needs to write back to the register file, the core is stalled until the coprocessor produces the result. During this time, the same instruction stays in the ID stage, and the issue response (including the writeback signal) remains valid. Because of this stall, we can safely use the writeback signal to enable the register file write once the result becomes available — there’s no ambiguity about which instruction is being written.

In a more complete implementation where multiple offloaded instructions could be in flight or the core doesn’t stall while waiting for results, it would make more sense to use the write-enable signal from the result interface instead. That would align better with the CV-X-IF specification, where issue and result are decoupled and identified by instruction IDs.

So, in short, using writeback here works correctly for this first version because of the stall-based flow, but future revisions could move to using the result interface’s write-enable for a more general implementation

[MikeOpenHWGroup]

Thanks @FrancescoDeMalde-synthara. Hi @inigodiezulzu, if you are satisfied with the above, please close this Issue.

[inigodiezulzu]

Thanks for your quick response!

In our implementation, we used the CVA6 cvxif_example coprocessor, which is compatible with the CV-X-IF 1.0 specification. In this setup, the writeback signal is only active during the instruction decode stage to inform the core that the instruction will perform a writeback operation. It does not remain active while the coprocessor result is pending.

When the coprocessor finishes the operation, it returns the result_valid and result.we signals through the result interface, notifying the core that the instruction has completed.

For this reason, we propose using result.we instead of writeback to enable the register file here cve2_id_stage.sv#L504. Otherwise with this cvxif_example the interface is not compatible.

Out of curiosity, which coprocessor did you use to test the interface?

[MikeOpenHWGroup]

Out of curiosity, which coprocessor did you use to test the interface?

The CV-X-IF is a recent addition to the CVE2 and has yet to be fully verified. We are currently focused on the CV32E20 configuration, which does not support the extension interface. Full verification of the CV32E20X is future work.

Let's leave this Issue open for now as it seems to me that the differences in the way the CVA6 and CVE2 implement the extension interface may expose previously unknown behaviour.

[inigodiezulzu]

Understood, thanks for the clarification. We'll keep the issue open until the CV32E20X verification process is complete, at which point we can revisit the differences in interface behaviour.