Dependencies between request channel and response channel?

[Silabs-ArjanB]

For an accelerator agnostic core, what (if any) are the dependencies between the request channel and the response channel?

I see in the documentation that it is allowed that for a given request transaction no response transaction happens at all; what is the benefit of allowing this? I would assume that the reverse is not allowed, i.e. a response transaction should only be allowed to happen (earliest the cycle after or maybe the same cycle as) a corresponding request transaction?

Will the request transactions be guaranteed to arrive in-order (i.e. in the same order as the corresponding request transactions were sent out)? If there is no such guarantee, then more information needs to be provided at the interface of an accelerator agnostic core in order to reconstruct the correct ordering.

Is there any limit on the difference between the number of accepted request transactions and returned response transactions?

[ganoam]

Hi Arjan,

For an accelerator agnostic core, what (if any) are the dependencies between the request channel and the response channel?

Certainly offload_valid must not depend on offload_ready.
We could allow offload_ready to depend on offload_valid, but I don't think this would really be needed. What do you think?

I see in the documentation that it is allowed that for a given request transaction no response transaction happens at all; what is the benefit of allowing this?

This facilitates instructions that do not impact the integer register file. So for example for the F extension, the F register file will be hosted by the accelerator subsystem in some form. Therefore for any operations with source and destination in the F register file, we do not need to write back anything to the offloading core.

I would assume that the reverse is not allowed, i.e. a response transaction should only be allowed to happen (earliest the cycle after or maybe the same cycle as) a corresponding request transaction?

Yes, this is correct. Every response transaction writes back to a destination register in the offloading core which has previously been reserved in the course of issuing the according request.

Will the request transactions be guaranteed to arrive in-order (i.e. in the same order as the corresponding request transactions were sent out)? If there is no such guarantee, then more information needs to be provided at the interface of an accelerator agnostic core in order to reconstruct the correct ordering.

Our Idea is to guarantee the response order for requests to the same accelerator from the same core. This approach can be implemented by the accelerator subsystems only and does not impact the interconnect or the cores.
Accross requests to multiple accelerators, we would not enforce any ordering. I think this is fine, because any requests impacting the state of the offloading core are ordered through the scoreboard.

Is there any limit on the difference between the number of accepted request transactions and returned response transactions?

No. A request can always be issued as soon as all operands are available and the accelerator interface can accept a new request. An accelerator may block a request if it is not ready to accept, but that should be up to the designer of the accelerator.

[Silabs-ArjanB]

Hi Noam,

Hi Arjan,

For an accelerator agnostic core, what (if any) are the dependencies between the request channel and the response channel?

Certainly offload_valid must not depend on offload_ready.
We could allow offload_ready to depend on offload_valid, but I don't think this would really be needed. What do you think?

My question was not about valid/ready. It is about what dependencies exist between the request channel (q) and the response channel (p)? For example, can there be 10 complete Q channels transfers followed by the corresponding (up to) 10 P channel transactions?

I see in the documentation that it is allowed that for a given request transaction no response transaction happens at all; what is the benefit of allowing this?

This facilitates instructions that do not impact the integer register file. So for example for the F extension, the F register file will be hosted by the accelerator subsystem in some form. Therefore for any operations with source and destination in the F register file, we do not need to write back anything to the offloading core.

I would assume that the reverse is not allowed, i.e. a response transaction should only be allowed to happen (earliest the cycle after or maybe the same cycle as) a corresponding request transaction?

Yes, this is correct. Every response transaction writes back to a destination register in the offloading core which has previously been reserved in the course of issuing the according request.

Will the request transactions be guaranteed to arrive in-order (i.e. in the same order as the corresponding request transactions were sent out)? If there is no such guarantee, then more information needs to be provided at the interface of an accelerator agnostic core in order to reconstruct the correct ordering.

Our Idea is to guarantee the response order for requests to the same accelerator from the same core. This approach can be implemented by the accelerator subsystems only and does not impact the interconnect or the cores.
Accross requests to multiple accelerators, we would not enforce any ordering. I think this is fine, because any requests impacting the state of the offloading core are ordered through the scoreboard.

Suppose you have 1 CPU with 2 accelerators and the CPU sends a transaction with destination X2 to accelerator 1 eventually followed by another transaction also with destination X2 but meant for accelerator 2. If the fabric does not guarantee that the writeback from accelerator 1 happens first, how do you envision a scoreboard in the CPU to take care of this?

Is there any limit on the difference between the number of accepted request transactions and returned response transactions?

No. A request can always be issued as soon as all operands are available and the accelerator interface can accept a new request. An accelerator may block a request if it is not ready to accept, but that should be up to the designer of the accelerator.

[ganoam]

For an accelerator agnostic core, what (if any) are the dependencies between the request channel and the response channel?

Certainly offload_valid must not depend on offload_ready.
We could allow offload_ready to depend on offload_valid, but I don't think this would really be needed. What do you think?

My question was not about valid/ready. It is about what dependencies exist between the request channel (q) and the response channel (p)? For example, can there be 10 complete Q channels transfers followed by the corresponding (up to) 10 P channel transactions?

Ah ok, thanks for the clarification. There are no dependencies between the two. The channels are completely decoupled.

Will the request transactions be guaranteed to arrive in-order (i.e. in the same order as the corresponding request transactions were sent out)? If there is no such guarantee, then more information needs to be provided at the interface of an accelerator agnostic core in order to reconstruct the correct ordering.

Our Idea is to guarantee the response order for requests to the same accelerator from the same core. This approach can be implemented by the accelerator subsystems only and does not impact the interconnect or the cores.
Accross requests to multiple accelerators, we would not enforce any ordering. I think this is fine, because any requests impacting the state of the offloading core are ordered through the scoreboard.

Suppose you have 1 CPU with 2 accelerators and the CPU sends a transaction with destination X2 to accelerator 1 eventually followed by another transaction also with destination X2 but meant for accelerator 2. If the fabric does not guarantee that the writeback from accelerator 1 happens first, how do you envision a scoreboard in the CPU to take care of this?

So the scoreboard makes sure we do not use stale register entries, i.e. we don't use a register as source before the entry has been updated by an outstanding writeback from an accelerator.

In your example, the same register is used twice as destination register.
Assuming the register is not used as source for any instruction in between those two instructions, we indeed have no control over which response will arrive first back at the core. However this sequence does not make much sense, as the result of the first would be overwritten by the second without ever being used anyways. - This situation should not occur, I think. If it does I don't have a solution at this point.

If the result of the first offloaded instruction is actually used, i.e. X2 is the source of some instruction before again being the destination of the second offload instruction, we have to make sure it's scoreboard entry is clean before continuing, and thus order is enforced.

[Silabs-ArjanB]

In your example, the same register is used twice as destination register.
Assuming the register is not used as source for any instruction in between those two instructions, we indeed have no control over which response will arrive first back at the core. However this sequence does not make much sense, as the result of the first would be overwritten by the second without ever being used anyways. - This situation should not occur, I think. If it does I don't have a solution at this point.

I believe that either the 'accelerator adapter' or the 'accelerator interconnect' should guarantee that write backs to the same destination register will appear in-order at the interface to an accelerator agnostic core. This should also be guaranteed in the slightly hypothetical situation that no instruction in between uses the stated destination as its source.

[ganoam]

yes, I see that could be a problem. I will think about a solution and present it at the next meeting. - Sorry, I completely forgot about this for this week.

[Silabs-ArjanB]

No problem. You could also argue that the core should prevent WAW hazards, but an accelerator agnostic core does not really know exactly when this would happen as only the 'accelerator adapter' knows whether write back will happen. This adapter could probably simply keep offload_ready = 0 when it sees a potential WAW hazard.

The core could also detect the WAW hazards, but then it needs to know 'offload_wb' and possibly retract its offload_valid based on that (which is a bit weird conceptually as offload_wb is then not allowed to depend on offload_valid)

[ganoam]

Yes, that would probably be the easiest solution. We could expose the offloading core's scoreboard to the predecoder and prevent any new offloads to the same destination register from being accepted.