• State Not Answered
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 7 replies
  • Subscribers 90 subscribers
  • Views 13530 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 locked access

spark spark
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?
  • 0
    Note: This was originally posted on 2nd June 2008 at http://forums.arm.com

    Thank for your reply.

    >> if both channels have been locked, whether a read unlock access also can complete the whole locked sequence?

    >It would have to as you can't have the slave WRITE locked but READ unlocked.

    It means that if a master request a loced sequence, this sequence will be all WRITE transaction or otherwise? Master will ensure this?
  • 0
    Note: This was originally posted on 5th June 2008 at http://forums.arm.com

    Thank you, I have got more clear about LOCKED access.

    I have ohter questions about write data channel.
    1. In AXI spec 1.2.1 it said that Write data channel information is always treated as buffered, so that the master can perform write transactions without slave acknowledgement of previous write transactions.
    I dont know why write data is always treated as buffered, is the interconnect must buffer all the write data to let master need not wait slave acknowledgement of previous write transactions? But I think this is not reasonable.

    2. In 1.3.2 there is an overlapping burst read example, but no overlapping burst write, does not allow overlapping burst write or interleave write is include overlap write already?

    3. In 3.3 it said that WREADY can be asserted before AWVALID. In a mulitlayer interconnect, if AWVALID is low how the interconnect know which slave will be the desitiny? In this case is WREADY will after AWVALID but can before AWREADY?
  • 0
    Note: This was originally posted on 11th June 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.
    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.
  • 0
    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.  :)
  • 0
    Note: This was originally posted on 6th June 2008 at http://forums.arm.com

    I have ohter questions about write data channel.
    1. In AXI spec 1.2.1 it said that Write data channel information is always treated as buffered, so that the master can perform write transactions without slave acknowledgement of previous write transactions.
    I dont know why write data is always treated as buffered, is the interconnect must buffer all the write data to let master need not wait slave acknowledgement of previous write transactions? But I think this is not reasonable.


    The buffering term is with respect to the write data channel. I.e, you don't have to receive a response for every write data transfer. Instead, the destination will "buffer" up all of the write data, and give back a single response, informing the source as to whether everything was transferred successfully or not. From a transaction point of view, you can still set the transaction to be bufferable or not by setting the AxCAHCE[0] signal.

    2. In 1.3.2 there is an overlapping burst read example, but no overlapping burst write, does not allow overlapping burst write or interleave write is include overlap write already?


    AXI does support the overlapping of write addresses. Proof of this can be seen when looking at the attributes of an AXI master interface, specifically the write issuing capability. It states how many active write transactions that interface can have. An active write transaction is one for which an address or item of data has been transferred, but for which a write response has not been seen. As such, if you have a write issuing capability of more than 1, you have the possibility to overlap write transactions.

    Interleaving is a step on from this. A master interface's write interleaving capability is the number of active transactions for which it can send write data (from the earliest transaction). Hence, if you had a write issuing capability of 4, but a write interleave depth of 1, you could overlap all four transactions, but the data would have to appear in the order that the addresses were issued.

    3. In 3.3 it said that WREADY can be asserted before AWVALID. In a mulitlayer interconnect, if AWVALID is low how the interconnect know which slave will be the desitiny? In this case is WREADY will after AWVALID but can before AWREADY?


    I would imagine that an interconnect would not assert WREADY until it knows the destination. The reason for this is as you said, it will not know which slave to route that data to. I suppose an exception to this would be an interconnect that had a buffering peripheral of some kind on the slave interface. This peripheral could then hold the data until the address has been seen, freeing up the write data channel between the interconnect and the source. Remember that AXI is a point to point architecture, hence the connection from the master to the interconnect is not the same as the connection from the interconnect to the slave...although the interconnect will appear transparent to the master or slave.

    I think this statement was probably included in the specification to cover the generic scenario. I.e, a simple connection from a master to a slave, between which there is no interconnect.

    HTH

    :(
  • 0
    Note: This was originally posted on 4th June 2008 at http://forums.arm.com

    > It means that if a master request a loced sequence, this sequence will be all WRITE transaction or otherwise?

    No, locked sequences can be (and usually are) made up of both read and write accesses.

    I think LOCK was originally intended for access sequences like the SWP instruction in the ARM instruction set, where you want to guarantee that the master can perform a single read access followed by a single write access to the same address, without any other master being able to access that address.

    However the AMBA specs try not to be too ARM-specific, so I guess the use of LOCK was left a bit less restrictive to allow other master designers to implement their own required locked access sequences, possibly with all READ or all WRITE sequences.

    But to support this in AXI you would need to ensure that both READ and WRITE channels get locked at the same time by either a read or write transaction, and similarly are unlocked by a read or write transaction.

    JD
  • 0
    Note: This was originally posted on 30th May 2008 at http://forums.arm.com

    Hello spark,

    > Does a locked request on either the read or write channel cause both channels to be locked?

    It would have to, otherwise another master could access the "locked" slave on the other data channel, and thus mean the slave is not completely locked.

    The AXI spec states in section 6.3 "...the interconnect must ensure that only that master is allowed access to the slave region...", so it doesn't state read or write access, just any access.

    > For example, one master request a locked write transaction to a slave, the read channel also will be locked?

    Yes, once all pending read or write transfers the slave has accepted have been completed.

    > if both channels have been locked, whether a read unlock  access also can complete the whole locked sequence?

    It would have to as you can't have the slave WRITE locked but READ unlocked.

    JD