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 locked access

Note: This was originally posted on 29th May 2008 at http://forums.arm.com

Does a locked request on either the read or write channel cause both channels to be locked? For example, one master request a locked write transaction to a slave, the read channel also will be locked? if both channels have been locked, whether a read unlock  access also can complete the whole locked sequence?
Parents
  • Note: This was originally posted on 3rd July 2008 at http://forums.arm.com

    In spec 8.5 The order in which a slave receives the first data item of each transaction must be the same as the order in which it receives the addresses for the transactions.

    It does not tell the master must assure this or the interconnect must. If the master dont need obey this, the interconnect will buffer a lot of data.


    Remember that the AXI spec is written from the point of view of a master interface talking to a slave interface. Hence, in a multi-master, multi-slave system, one path could be:

    Master master interface -> Interconnect slave interface -> Interconnect master interface -> Slave slave interface

    As such, the statement you referenced from the AXI spec could either relate to the interconnect slave interface, or the slave slave interface. As the outputs from the interconnect master interface will mimic the outputs from the master's master interface, it implies that the restriction is on the master's master interface.

    For example, if a master requests 4 write transactiona and all accept by slave, but master sends the first data of first transaction after it sends all other 3 transaction's data. Now the interconnect need buffer all this 3 transaction's data.


    If the master was to send the first item of write data for the 4th address issued, before it had sent the first item of write data for the first 3 addresses, it would be a protocol violation. An interconnect designer would probably not cater for this scenario, because it would add extra gates and is not compliant with the AXI protocol.

    If you have a master in your system doing this, I would approach it's designer and inform them that it is not compliant with the AXI spec.  :)
Reply
  • Note: This was originally posted on 3rd July 2008 at http://forums.arm.com

    In spec 8.5 The order in which a slave receives the first data item of each transaction must be the same as the order in which it receives the addresses for the transactions.

    It does not tell the master must assure this or the interconnect must. If the master dont need obey this, the interconnect will buffer a lot of data.


    Remember that the AXI spec is written from the point of view of a master interface talking to a slave interface. Hence, in a multi-master, multi-slave system, one path could be:

    Master master interface -> Interconnect slave interface -> Interconnect master interface -> Slave slave interface

    As such, the statement you referenced from the AXI spec could either relate to the interconnect slave interface, or the slave slave interface. As the outputs from the interconnect master interface will mimic the outputs from the master's master interface, it implies that the restriction is on the master's master interface.

    For example, if a master requests 4 write transactiona and all accept by slave, but master sends the first data of first transaction after it sends all other 3 transaction's data. Now the interconnect need buffer all this 3 transaction's data.


    If the master was to send the first item of write data for the 4th address issued, before it had sent the first item of write data for the first 3 addresses, it would be a protocol violation. An interconnect designer would probably not cater for this scenario, because it would add extra gates and is not compliant with the AXI protocol.

    If you have a master in your system doing this, I would approach it's designer and inform them that it is not compliant with the AXI spec.  :)
Children
No data