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.
Hi Sai,> 3) Is there a possibility that A Read transaction can complete in One Cycle ?No.It would take a minumum of 1 clock cycle to pass the address from the master to the slave (assumes ARREADY was high when ARVALID was asserted), and then a minimum of 1 clock cycle to pass the data from the slave to the master (assumes RREADY was high when RVALID was asserted).>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"Yes. If ARREADY is initially low when an address is signaled on ARVALID, it will take one clock cycle for the slave to sample this ARVALID and then assert ARREADY (if it can accept the address), and the address handshake then completes on the next clock rising edge (when both ARREADY and ARVALID are high). So 2 clock cycles just to pass the address from master to slave if ARREADY defaults to LOW.It would then take at least a further clock cycle before the read data could be returned to the master.>> Thank you very much for your explanation.>>Did u gone through my comments in the previous post ? (Those starts with ==>)Colin.