12-10-2019 10:46 PM
I have question with AXI interconnecor Xilinx' IP
As a result of latency measure, AXI interconnector's latency dealy is about 20 clk from input to output. I think it's too long
Do anybody know how to optimize axi interconnector under 5clk or another axi interconnector which have short latency delay IP
12-12-2019 01:15 AM
There are multiple parameters to take in account. If you expend the AXI interconnect IP, you will see that it is composed from mutltiple sub-IPs and this configuration will change depending on the master and slave interfaces which are connected to it.
So you might want to give more details about the interfaces connected:
You might want to provide the ILA or simulation for the latency you are seeing as well
There is no easy answer based on the description you are providing
PS: The PG059 has a latency section which is detailing the latency for the AXI interconnect. You might want to go through it
12-12-2019 11:23 AM
The AXI specification has a rule that there be no combinatorial paths between inputs and outputs within either slaves or masters.
Given that an interconnect is both an AXI slave and an AXI master, this means that you'll be stuck with a minimum of three clocks of latency:
1. One clock to accept the request from one of the interconnect's slave interfaces and to forward it to a slave
2. A second clock for the slave to process the request and return the result to the interconnect
3. A third clock to return the result to the master.
Sadly, if you want any kind of high speed operation, you'll need to pipeline some of the logic within the interconnect as well. As an example, in this open source design, two other clocks are used to ...
4. Decode the address to reference the slave, and
5. Arbitrate among multiple masters attempting to reference the same slave.
As a result, this interconnect will return a minimum latency of 5 cycles.
Even that, however, isn't the full story. What happens when a master requests an operation from slave 1, slave 2, and then slave 1 again? The open source interconnect above will wait for slave 1's acknowledgment before it offers arbitration to access slave 2, and then again wait for slave 2's response. This can add more latency to each of these additional requests, and this is only the *minimum* latency--assuming all of the xREADY lines are high other than AxREADY.
(Note: Despite my best attempts to redraw these "to-scale" to match a trace, it looks like there are still some subtle errors within these--for example, ARVALID should be *low* following a reset, and the latency should start counting from the time ARVALID is first high, etc.)
Xilinx's interconnect supports several modes. One is a single-address, single data mode where all of the slave address lines, read and write, are shared. This is meant for low-logic implementations. The problem with this mode is that it turns an N:M interconnect into an N:1:M interconnect. Well, even that's not quite right, since this simplified mode merges read and write channels together. Hence N masters might have N read channels and N write channels, and connect to M slaves with M read and M write channels. In order to be able to share address and data lines across all channels, this becomes more of a (2N):1:(2M) interconnect where only one master will ever get access to any slave at a time. All other masters must wait.
AXI also supports a second interconnect methodology whereby the interconnect routes requests to slaves, and then arbitrates and routes those requests back to the master. Xilinx's interconnect also supports this mode in it's full N:M read and N:M write crossbar configuration. This isn't the panacea that it sounds like, however, since you can't route a packet with a given AXI ID to slave one, and then a second packet with the same AXI ID to slave two, only to have the second slave respond first. I haven't tested to see how Xilinx's interconnect prevents this from happening--but suffice to say that this operation would of necessity create even more latency.
It's worse than that even. Because any return routing algorithm based upon AXI IDs of necessity would create back pressure in the slave, as in dropping the RREADY or BREADY signals for slaves that haven't won arbitration, slaves that haven't been tested against backpressure might now fail and lock the bus up hard for the rest of the connected designs. Classic examples are the IP Packager designs (both the demonstration AXI and AXI-lite slaves) and even the AXI ethernet lite designs--both of which will drop returns (and lock your design) in the presence of any backpressure.
12-15-2019 10:21 PM
Thank you for your replay and I'm answering your questions.
12-16-2019 12:17 AM
Do you have an ILA capture or simulation waveform showing the latency?
12-16-2019 12:56 AM
Well... this will be hard to give much more advise if we do not know exactly what is happening.
I would have checked on the tready signals on the slave side (i.e. Master interface of the interconnect) to make sure this is not a backpressur from the downstream IPs
And also if there is a delay between the address and the data for write transaction which can be improved on the upstream IPs
12-17-2019 06:36 PM
Thank you for your replay
I can send our waveform and simulation enviroment for receving your inform.
Could you give me your email? (as alrealy I iform, I can't attach our data because of our security poicy, but I can send email to you )