Guidelines for connecting more than one coprocessor

[MPEZZIN]

Comment

In current version of the document, we have the following note:

A coprocessor must be tolerant to any possible commit.id, whether this represents and in-flight instruction or not. In this case, the coprocessor may still need to process the request by considering the relevant instructions (either preceding or succeeding) as no longer speculative or to be killed. This behavior supports scenarios in which more than one coprocessor is connected to an issue interface.

This is the only place where this feature is explicitly mentioned, but it only gives recommendations for commit.id management

Proposed Resolution

A dedicated document section that gives guidelines on how to deal with more than one coprocessor connected to the same extension interface should be very useful. In particular:

• how to deal with multiple ready and accept signals that may have different latencies ?
• what is the expected behaviour when 2 coprocessors are able to accept the same request ?
  • Is there a precedence/arbitration rule ? How do we notify the second coprocessor that a request is being processed by the first one ?
  • should we simply generate an error ?
  • or should explicitly state in specification that instructions overlap is forbidden ?

Another option could also be not supporting multiple coprocessors in the first version of the specification and modify the above note to say that this is preparation work for a future release that will support this feature.

Addition Info

No response

[christian-herber-nxp]

The spec is a point-to-point specification, but it definitely contains elements that are intended to make the connection to multiple coprocessors easy. I actually agree that we may have to make this more explicit, e.g. by adding a section on that to the annex.

In particular:

• how to deal with multiple ready and accept signals that may have different latencies ?

Don't all signals have different latencies? They just need to be stable in time to be sampled the next clock cycle.

• what is the expected behaviour when 2 coprocessors are able to accept the same request ?

That is a bug that should be caught by verification. The behavior thereafter is undefined.

• Is there a precedence/arbitration rule ? How do we notify the second coprocessor that a request is being processed by the first one ?
• should we simply generate an error ?
• or should explicitly state in specification that instructions overlap is forbidden ?

As the specification is a point to point specification, the combination of coprocessors needs to behave like a valid coprocessor. This should be the leading requirement. What you do internally is your thing, but overlap does not seem useful or practical.

Another option could also be not supporting multiple coprocessors in the first version of the specification and modify the above note to say that this is preparation work for a future release that will support this feature.

We should be explicit, you are absolutely right.

[christian-herber-nxp]

@MPEZZIN thanks for your suggestions on the text. I think we need to drive a decision of either having the requirement for forcing 0 in all relevant interfaces, or having it in none (including issue), and putting this into the recommendations section. I am fine with the latter but would like to align this with the group. @Silabs-ArjanB : What's your opinion?

[Silabs-ArjanB]

@christian-herber-nxp The driving of 0 on some signals is not related to merging multiple coprocessors onto one interface. It is related to signals as 'write enable', etc. which are often timing critical to not need any further qualification (with for example the accept signal). As such I do not think a change is required here.

[christian-herber-nxp]

I have updated the proposal completely. No the change to the normative part of the specification is that there are consistently not requirements for anything to be 0 for non valid or non accepted etc. A note about this optimization is put into the recommendations.