• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 350 subscribers
  • Views 24743 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

AXI Master dependencies between xREADY and xVALID on different transactions

Flanter

Hi,

The AXI spec notes the dependencies between xREADY and xVALID for a Master as follows:

  • the master must not wait for the slave to assert AWREADY or WREADY before asserting AWVALID or WVALID

And even adds an important note:

  • It is important that during a write transaction, a master must not wait for AWREADY to be asserted before driving WVALID. This could cause a deadlock condition if the slave is conversely waiting for WVALID before asserting AWREADY.

However, I tried to figure out if this dependency is also true for 2 different consecutive Write transactions and I couldn't find any thing about it in the spec.

Consider the following example for implementing a Master that handles a single transaction at a time and doesn't advance to the next transaction till previous transaction is fully transmitted: 

1st transaction is a burst with AWLEN>0. It starts with AWVALID and WVALID asserted and AWREADY and WREADY de-asserted. At a certain point AWREADY is asserted but WREADY remains de-asserted.

Can I stall AWVALID assertion for the 2nd transaction till WREADY is asserted for all beats of the 1st transaction? Doesn't it violate the guideline "master must not wait for the slave to assert AWREADY or WREADY before asserting AWVALID or WVALID"?

Same question is valid for a case where WREADY is asserted but AWREADY remains de-asserted, so WVALID for 2nd transaction is kept de-asserted till AWREADY assertion for 1st transaction.

Parents
  • 0

    The reason for the xVALID/xREADY handshake dependencies is to avoid potential deadlocks. If there are no rules specified you could have two transfers waiting for the other to complete before they themselves complete.

    So looking at your first example sequence, YES, you can stall AWVALID assertion for the second transaction until all the WDATA transfers of the first transaction have completed, and you could also delay AWVALID assertion until after the B channel response has completed for the first transaction.

    This scenario wouldn't be risking a system deadlock as there is no reason for the slave to not accept WDATA transfers for the first transaction until it has received the next transaction AWVALID indication. The handshake dependencies you describe only apply to transfers within the same transaction.

    Looking at your second example sequence, yes again this would be a valid thing to do, as a simpler master will probably want the address transfer for the first transaction completed before it starts thinking about generating data for a second transaction.

    Neither of your suggested scenarios would result in a system deadlock, the slave being accessed is just being slow to accept AW or W transfers from the master, but eventually they will be accepted, and the master can then move on. If the slave needs to know the address for the next transaction before it accepts all data for a first transaction, or it needs to see data for a second transaction before it accepts the address for a first transaction, then you seriously need to look at your slave design !

Reply
  • 0

    The reason for the xVALID/xREADY handshake dependencies is to avoid potential deadlocks. If there are no rules specified you could have two transfers waiting for the other to complete before they themselves complete.

    So looking at your first example sequence, YES, you can stall AWVALID assertion for the second transaction until all the WDATA transfers of the first transaction have completed, and you could also delay AWVALID assertion until after the B channel response has completed for the first transaction.

    This scenario wouldn't be risking a system deadlock as there is no reason for the slave to not accept WDATA transfers for the first transaction until it has received the next transaction AWVALID indication. The handshake dependencies you describe only apply to transfers within the same transaction.

    Looking at your second example sequence, yes again this would be a valid thing to do, as a simpler master will probably want the address transfer for the first transaction completed before it starts thinking about generating data for a second transaction.

    Neither of your suggested scenarios would result in a system deadlock, the slave being accessed is just being slow to accept AW or W transfers from the master, but eventually they will be accepted, and the master can then move on. If the slave needs to know the address for the next transaction before it accepts all data for a first transaction, or it needs to see data for a second transaction before it accepts the address for a first transaction, then you seriously need to look at your slave design !

Children