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

AMBA AXI Write response

I am just going through the specs of AMBA AXI.
I've few questions.It will be great if anybody clarify
1) Why there was no Write response for each beat in burst Write. But there is a seperate Read response for each beat in a Read burst ?
2) How to terminate A read/write burst ? Specification says we can not stop bursts intermittantly.
         i) Can A master can give WLAST in middle of a burst transfer ?
         ii) in the same way if slave assersts RLAST before the completion of a busrt read?
If WLAST and RLAST can not do the above cases, then what is the special use of WLAST and RLAST because we are getting individual beat responses anyway?
3) Whats the exact use of Exclusive Read and Write Pair transaction? Where exactly these will be used?

Thanks in advance..
Regards,
Sai Krishna
Parents
  • Note: This was originally posted on 30th January 2007 at http://forums.arm.com

    Hello Sai,
    ==> Thanks for your comments
    > 1) Why there was no Write response for each beat in burst Write. But there is a seperate Read response for each beat in a Read burst ?

    All of the AXI channels pass information in only 1 direction (only the xREADY signal goes against the channel direction), so for a slave to give a response back to the master for a write transaction, would need a separate channel.

    I guess this channel could have been defined to include a BRESP for each write data item, but this would increase the bandwidth requirement for this channel, and as in most applications you will just repeat the complete transaction for a non-OKAY response, few applications would make use of the additional detail of which transfer in a write burst caused a failure.

    You do give a RRESP response for each read data item because the higher bandwidth channel is already there,
    ================================================================
    ==> I didn't get  "the higher bandwidth channel is already there ". Because even for write there is separate write response channel. ================================================================
    but again, most applications will just repeat the entire failed read transaction.

    > 2) How to terminate A read/write burst ? Specification says we can not stop bursts intermittantly.

    Simple answer, you cannot.

    As soon as the AXI master indicates that it will perform X number of transfers in a transaction, it must complete X transfers. There is no "Early Burst Termination" concept like there was in AHB.

    For write transactions the master could complete the burst, but driving the WSTRB bits all to logic '0' (dummy accesses) so that no data is actually being transferred to the slave, but for read transactions there is no equivalent, and so "real" read accesses will be completed.

    >         i) Can A master can give WLAST in middle of a burst transfer ?

    No. WLAST can only be asserted while WVALID is high when the final WDATA of a burst is being transferred. Indicating WLAST (and WVALID) too early in a burst would be a protocol violation.

    Also, many slave designs will not use the WLAST input, and will simply count data items coming in, so this would not be a safe (or legal) method of terminating a burst.

    >         ii) in the same way if slave assersts RLAST before the completion of a busrt read?

    If the slave drives RLAST (and RVALID) too early, this too is a protocol violation, and just as for the WLAST signal, some masters might not be monitoring RLAST, so this illegal use could be missed anyway.

    >If WLAST and RLAST can not do the above cases, then what is the special use of WLAST and RLAST because we are getting individual beat responses anyway?

    WLAST and RLAST can be used by masters and slaves that need to be told when the final data in a burst is being transferred.

    Most masters and slaves will count the data coming in against how many transfers were indicated on AWLEN and ARLEN, so in these designs the xLAST inputs would not be required.

    However to support all master and slave designs, masters must always drive WLAST when appropriate, and slaves must drive RLAST.

    > 3) Whats the exact use of Exclusive Read and Write Pair transaction? Where exactly these will be used?

    Semaphore passing.

    Semaphore passing is a software requirement, whereas my background is hardware, so please forgive any vagueness in the following answer.

    If you have a shared area of memory used for passing control information between masters (or processes running on a master), you want to make sure that you complete the READ/WRITE sequence without another master changing the shared location.

    If your master read the shared memory location, and it was changed by another master before your master could complete the subsequent write to that location, the interim write from the other master would be lost, which could have an impact on how your system works (control information lost)

    So Exclusive Accesses are a hardware mechanism to support the software, indicating to the master when it did have uninterrupted access to the shared location, meaning that no write accesses from other masters will be accidentally overwritten.

    ==> Again Thanks for the explanation. My doubt is, Normally there will be cases like where you'll write into some shared memory and monitor that it has not been changed by any other master. (Which is Write -> Read sequence) And the specification provides the other-way(Which is Read  -> Write sequence) which is not so common(I feel..)

    Hope that all makes sense,

    Colin.


    ==> I've one more question,

    ==> 3) Is there a possibility that A Read transaction can complete in One Cycle ?
    Section 3.1.4 on 3.4 says that "A default ARREADY value of LOW is possible but not recommended, because it implies that the transfer takes at least two cycles, one to assert ARVALID and another to assert ARREADY"
Reply
  • Note: This was originally posted on 30th January 2007 at http://forums.arm.com

    Hello Sai,
    ==> Thanks for your comments
    > 1) Why there was no Write response for each beat in burst Write. But there is a seperate Read response for each beat in a Read burst ?

    All of the AXI channels pass information in only 1 direction (only the xREADY signal goes against the channel direction), so for a slave to give a response back to the master for a write transaction, would need a separate channel.

    I guess this channel could have been defined to include a BRESP for each write data item, but this would increase the bandwidth requirement for this channel, and as in most applications you will just repeat the complete transaction for a non-OKAY response, few applications would make use of the additional detail of which transfer in a write burst caused a failure.

    You do give a RRESP response for each read data item because the higher bandwidth channel is already there,
    ================================================================
    ==> I didn't get  "the higher bandwidth channel is already there ". Because even for write there is separate write response channel. ================================================================
    but again, most applications will just repeat the entire failed read transaction.

    > 2) How to terminate A read/write burst ? Specification says we can not stop bursts intermittantly.

    Simple answer, you cannot.

    As soon as the AXI master indicates that it will perform X number of transfers in a transaction, it must complete X transfers. There is no "Early Burst Termination" concept like there was in AHB.

    For write transactions the master could complete the burst, but driving the WSTRB bits all to logic '0' (dummy accesses) so that no data is actually being transferred to the slave, but for read transactions there is no equivalent, and so "real" read accesses will be completed.

    >         i) Can A master can give WLAST in middle of a burst transfer ?

    No. WLAST can only be asserted while WVALID is high when the final WDATA of a burst is being transferred. Indicating WLAST (and WVALID) too early in a burst would be a protocol violation.

    Also, many slave designs will not use the WLAST input, and will simply count data items coming in, so this would not be a safe (or legal) method of terminating a burst.

    >         ii) in the same way if slave assersts RLAST before the completion of a busrt read?

    If the slave drives RLAST (and RVALID) too early, this too is a protocol violation, and just as for the WLAST signal, some masters might not be monitoring RLAST, so this illegal use could be missed anyway.

    >If WLAST and RLAST can not do the above cases, then what is the special use of WLAST and RLAST because we are getting individual beat responses anyway?

    WLAST and RLAST can be used by masters and slaves that need to be told when the final data in a burst is being transferred.

    Most masters and slaves will count the data coming in against how many transfers were indicated on AWLEN and ARLEN, so in these designs the xLAST inputs would not be required.

    However to support all master and slave designs, masters must always drive WLAST when appropriate, and slaves must drive RLAST.

    > 3) Whats the exact use of Exclusive Read and Write Pair transaction? Where exactly these will be used?

    Semaphore passing.

    Semaphore passing is a software requirement, whereas my background is hardware, so please forgive any vagueness in the following answer.

    If you have a shared area of memory used for passing control information between masters (or processes running on a master), you want to make sure that you complete the READ/WRITE sequence without another master changing the shared location.

    If your master read the shared memory location, and it was changed by another master before your master could complete the subsequent write to that location, the interim write from the other master would be lost, which could have an impact on how your system works (control information lost)

    So Exclusive Accesses are a hardware mechanism to support the software, indicating to the master when it did have uninterrupted access to the shared location, meaning that no write accesses from other masters will be accidentally overwritten.

    ==> Again Thanks for the explanation. My doubt is, Normally there will be cases like where you'll write into some shared memory and monitor that it has not been changed by any other master. (Which is Write -> Read sequence) And the specification provides the other-way(Which is Read  -> Write sequence) which is not so common(I feel..)

    Hope that all makes sense,

    Colin.


    ==> I've one more question,

    ==> 3) Is there a possibility that A Read transaction can complete in One Cycle ?
    Section 3.1.4 on 3.4 says that "A default ARREADY value of LOW is possible but not recommended, because it implies that the transfer takes at least two cycles, one to assert ARVALID and another to assert ARREADY"
Children
No data