Description
The Tilelink 1.9.3 specification states that for the following cases:
If the AXI Bus does not accept a request within a timeout, we need to insert a Tilelink error response
Unfortunately, older buses do not guarantee forward progress. When controlling these buses, it would violate TileLink’s ready rules if the bridge were to block TileLink traffic indefinitely while waiting for the legacy bus to accept a message. Therefore, bridges to buses like AXI must include a timeout, to fit within the auspices of the forward progress rules. If the legacy bus does not accept a request within this timeout, the request must be discarded and a TileLink error response inserted.
And, if the AXI Bus does not send a response back we must insert the Tilelink error response
If a legacy bus sends response messages, a bridge must also put a limit on how long it will wait for
those responses, unless the legacy bus can be verified to be deadlock free. If an unverified legacy bus exceeds the time limit, the bridge must cancel the outstanding request, inject a TileLink error
response, and if the original legacy response ever arrives, discard it. To put a limit on the memory
required to track discarded responses, it is acceptable for a bridge to completely disable a deadlocked legacy bus.
I see that the Bridge at scala/tilelink/ToAXI4.scala does not implement these timeouts.
Can you please let me know why?
Also, the TL-C section of the TL1.9.3 Specification reserves the d_denied and d_corrupt bits to 0 for the ReleaseAck.
Could you please comment on how a SLVERR from the Bus will be handled for a ReleaseData write error?
Thanks,
Sai Govardhan