[Review Comment]: ID for compressed_req

[AyoubJalali]

Comment

Hello I am working on the verification of CVA6, specifically on re-verifying the CVXIF interface after changing the specification. I have a couple of questions:

For the compressed interface, is it acceptable that the compressed_req does not have an ID field to specify the compressed transaction? The compressed response packet refers to an ID, but we currently don’t have one.
in the last version of the spec we had ID for compressed interface.

Regarding the commit interface, the specification mentions that commit_valid cannot be asserted for two clock cycles. Does this restriction apply to the same ID only, or is it also valid for back-to-back instructions with different IDs ? this was refers in #229

Thank you for your insights !

Proposed Resolution

Precise why we don't have ID for compressed interface ? is it useless in the version of the spec or in the implementation ?

Addition Info

No response

[AyoubJalali]

In a verification point of view, the lack of a unique identifier in the compressed_req transactions presents a significant challenge for monitoring and checking. Without an ID field or another distinguishing feature, the monitor cannot reliably differentiate between back-to-back transactions, especially if the compressed_valid signal remains high or if consecutive transactions have identical instr values. This ambiguity complicates transaction tracking, making it difficult to associate requests with their corresponding responses and to detect issues such as dropped or duplicated transactions. To ensure robust verification, it is crucial to incorporate a mechanism, such as a unique transaction ID, to unambiguously identify each request. This enhances the monitor's ability to match transactions, improves debug capabilities, and ensures accurate coverage metrics.

[silabs-robin]

Can this issue be closed now?

I view the "compressed interface" as a setup phase, or a "pre-stage".

The spec currently specifies the issue interface to be where offloaded instructions (with their IDs) become in-flight:
An id becomes in-flight in the first cycle that issue_valid is 1 for that id.

---

I understand that one might would want to check that... e.g. the expected instruction stream is only passed to the compressed interface once (not twice), etc, and there it would be helpful to have an ID.

Is this something that a specific processor implementation could keep track of itself?
It doesn't seem necessary for the operation of the XIF, so hence it might not be the best fit to mandate in the spec.

[silabs-robin]

Argument in favor of this ticket:

The same id value shall be used for all transaction packets on all interfaces that logically relate to the same instruction.
^ The spec says "all interfaces" when referring to the id.

There is no explicit excemption.

The section about the compressed interface even mentions the id directly: Is the offloaded compressed instruction (id) accepted by the coprocessor?.