order problem

I think you're mixing up two things:

• How software expresses what it wants.
• How the hardware achieves what software asked for.

Issuing a barrier is software saying that it wants ordering for these accesses.  It's up to the hardware to figure out how to achieve that (ideally efficiently).  With AXI, it could achieve the specified ordering by sending the first access then waiting for the BRESP before sending the other.  So your Q2 is how the hardware might deal with Q1.

Some other thoughts:

If you're working with a peripheral, typically I'd expect it to be mapped as Device with the nR (no re-order) attribute.  In which case software wouldn't need to use a DMB to ensure those accesses arrived in order.  See B2.10.2.2 Reordering in the rev L.b Arm Architecture Reference Manual for A-profile.

 The way DMB is described is in terms of what another observer (e.g. a thread on another core) could observe, not in terms of what the end device.  In your example, imagine that the slave is a memory and mapped as cacheable.  In which case the writes might only make it as far as a cache, rather than the device.  At some point the lines will be evicted from the cache, but there'd be no guarantee the lines would be evicted in the same order as they were filled.  If what you care about is the order of arrival at the device, then it's Device type with nR that you'd typically use.  Alternatively, software might use DSB - which has a different set of guarantees.

I think you're mixing up two things:

• How software expresses what it wants.
• How the hardware achieves what software asked for.

Issuing a barrier is software saying that it wants ordering for these accesses.  It's up to the hardware to figure out how to achieve that (ideally efficiently).  With AXI, it could achieve the specified ordering by sending the first access then waiting for the BRESP before sending the other.  So your Q2 is how the hardware might deal with Q1.

Some other thoughts:

If you're working with a peripheral, typically I'd expect it to be mapped as Device with the nR (no re-order) attribute.  In which case software wouldn't need to use a DMB to ensure those accesses arrived in order.  See B2.10.2.2 Reordering in the rev L.b Arm Architecture Reference Manual for A-profile.

 The way DMB is described is in terms of what another observer (e.g. a thread on another core) could observe, not in terms of what the end device.  In your example, imagine that the slave is a memory and mapped as cacheable.  In which case the writes might only make it as far as a cache, rather than the device.  At some point the lines will be evicted from the cache, but there'd be no guarantee the lines would be evicted in the same order as they were filled.  If what you care about is the order of arrival at the device, then it's Device type with nR that you'd typically use.  Alternatively, software might use DSB - which has a different set of guarantees.

Thanks for reply.

But If the master write transaction to slave -> wait brsp and then send read transaction to slave. it can not ensure that the slave must receive the write transaction first and then read transaction? because interconnect may send brsp to master first, and the delay (from master write -> interconnect-> slave) may not same as (from master read -> interconnect-> slave) . In this case, the slave will receive read transaction and then write transaction, the order is not same as master's?

Tom T said:

But If the master write transaction to slave -> wait brsp and then send read transaction to slave. it can not ensure that the slave must receive the write transaction first and then read transaction?

If what you have is one requester (master) connected directly to one completer (slave), then seeing BRESP would let the requester know that the transaction had reached the destination.  But that's not typically how things are arranged, there's typically an interconnect between the requester and the responder  Take the two example systems on this page:

https://developer.arm.com/documentation/102202/0300/AXI-protocol-overview

You have a set of requesters connected to an interconnect, with a set of completes also connected to the interconnect.  In these examples, the BRESP that the requesters see is coming from the interconnect.  Which leads to the question - when will the interconnect return BREP to the requestor?  Does it wait for end device to respond, or will it do it early?

When the requestor sets up the transaction it uses the AxCACHE signals to specify how the transaction should be treated.  See this page (scroll down to Cache support) https://developer.arm.com/documentation/102202/0300/Channel-signals for an overview.  If the requester specified that it didn't want an early acknowledgement, then the interconnect should wait for the end device to send BRESP before BRESP is sent to the requester. 

So there's a hardware and software side to the problem.  Software needs to correctly describe (using memory types, barriers...) the memory ordering it wants and who/what needs to see that ordering.  Hardware needs generate a set of traffic, using the options in AXI, that achieve what software asks for.

Q1: Can I make this conclusion: If master A sends write transcation -> interconnect -> slave , and wait brsp and send read transaction -> interconnect-> slave. Master use AXCACHE=4'b0000(device non-bufferable) to write/read transaction. Then,the order in slave's side must be same as master's side。Am I correct?

Q2: If master don't use  AXCACHE=4'b0000, the order in slave's side may not be same as master's side?

Thank a lot!! 

Broadly yes - but you should refer to the AMBA AXI specification (https://developer.arm.com/documentation/ihi0022/latest, A4.3 - Memory types) for the detailed description.  For example, there is also a Normal Non-cacheable Non-Bufferable type.