• State Accepted Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 350 subscribers
  • Views 6365 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

AXI4 - Data before address - why?

af_23

Hi all.

I have general questions on why certain features of the AXI4 protocol are the way they are.

AXI4 allows a master to send the data beats before sending the address information.

I'm curious to know if this is advantageous, either in systems with a single pair of Master-Slave, or in larger systems with AXI interconnect.

It is not that the write data and write address are completely independent - The master has to know the address before sending the data - because the correct byte lanes on the data bus and the wstrb signal has to match the address alignment. 

So if the master already knows the address, why not send it?

Thanks.

Parents
  • +1

    As well as the valid scenario described by  (where to answer your latest question the address translation is very unlikely to change the address LSBs, and so affect the data positioning and strobes), another scenario where W leads AW is when you add more registering on the AW path compared to the W path between the source and destination of the transaction. This registering would be added to ease timing on long paths, and isn't always the same requirement for all channels.

    As to why allowing W before AW is advantageous, in most master designs I can think of the W data will come out at the same time as the AW, or after it (although it is feasible you might know the data to send before you have worked out the address).

    In any interconnect logic the address decoders will need to know the address before they can route the data, so any early W transfer could be stalled by holding WREADY low until the interconnect has decoded the AW transfer. But after the address decode, as I described it is possible to see timing isolation registering on the AW channel such that the W transfer could come out of the interconnect ahead of data.

    So the protocol doesn't have any reason to restrict W before AW, and if any component needs a specific ordering it can stall any transfer using the xVALID/xREADY handshakes.

Reply
  • +1

    As well as the valid scenario described by  (where to answer your latest question the address translation is very unlikely to change the address LSBs, and so affect the data positioning and strobes), another scenario where W leads AW is when you add more registering on the AW path compared to the W path between the source and destination of the transaction. This registering would be added to ease timing on long paths, and isn't always the same requirement for all channels.

    As to why allowing W before AW is advantageous, in most master designs I can think of the W data will come out at the same time as the AW, or after it (although it is feasible you might know the data to send before you have worked out the address).

    In any interconnect logic the address decoders will need to know the address before they can route the data, so any early W transfer could be stalled by holding WREADY low until the interconnect has decoded the AW transfer. But after the address decode, as I described it is possible to see timing isolation registering on the AW channel such that the W transfer could come out of the interconnect ahead of data.

    So the protocol doesn't have any reason to restrict W before AW, and if any component needs a specific ordering it can stall any transfer using the xVALID/xREADY handshakes.

Children