UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
839 Views
Registered: ‎11-09-2016

AXI4 Stream Interconnect : strange round robin

Hello,

 

I have a strange behaviour with an AXI4 Stream Interconnect. I worked with Vivado 2016.4, I upgrade to 2017.4 but the issue is still here.

 

I have 16 slaves/input channels and 1 master/output channel. In my simulation test bench I use only the 8 first channels.

The arbitration is configured as follow:

 AXI4S_Interco_ArbConf.PNG

 

The tvalid signal on input channels is set high channel after channel. At a moment, all tvalid signals are high, except the slave channel 0 where sometime it goes low:

AXI4S_Interco_tvalid.PNG

 

The strange behavior is on the tready signal: the round robin gives priority to channels 0 and 1. The channels 2, 3, 4, 5, 6 and 7 got tready signal 1 time each 5 times for channels 0&1:

AXI4S_Interco_tready.PNG

 

Here is the tlast behaviour:

AXI4S_Interco_tlast.PNG

 

I tried to arbitrate on a maximum of tranfers (1, 128, 1024), with no success or any change behaviour.

I didn't find any tips about this in PG35. Have you got any tip or idea to avoid this behaviour and make the tready signal is fairly shared between all input channels?

 

Thanks for your help!

Regards

0 Kudos
2 Replies
Highlighted
Xilinx Employee
Xilinx Employee
736 Views
Registered: ‎02-10-2015

Re: AXI4 Stream Interconnect : strange round robin

TL;DR: In the 2017.4, there is a new arbiter called True Round-Robin that should give you the behavior you desire. 

 

The reason why you are seeing the behavior below is because the regular Round-Robin arbiter will simply rotate through 16 priority slots every cycle it re-arbitrates. In slot 0, port 0 will have highest priority, followed by port 1, then port 2, and so on with port 15 having the lowest priority. In slot 1, port 1 will have the highest priority followed by port 2, then port 3, ..., port 15 will have the second lowest priority and port 0 will have the lowest priority. At slot 8, port 8 will have highest priority, followed by port 9, ..., port 7 will have the lowest priority.  In your design, since ports 8-15 are inactive (no asserted tvalid), when slots 8-15 of the arbitration scheme are reached, port 0 will effectively have the highest priority until all those slots are cycled through and we arrive back at slot 1.  Ports that are requesting arbitration will also back off for 1 cycle once an arbitration cycle has been granted, that will prevent port 0 from requesting back to back arbitrations and thus the reason you see the alternating arbitration requests between port 0 and port 1 when the arbiter is operating on slots 8 through 15.  

 

The True Round-Robin arbiter type will advanced the slot to (port + 1) of the last arbitrated port.  In your diagram below that means when the arbiter gets to slot 8, port 0 will win arbitration and send it's transfer, the arbiter will advanced to slot 1 for the next arbitration cycle, thus giving you the behavior you desire despite having inactive ports. If you had all ports active, then the Round-Robin arbiter type would also behave fairly. 

 

0 Kudos
724 Views
Registered: ‎11-09-2016

Re: AXI4 Stream Interconnect : strange round robin

Hello,

 

Thanks for your reply and explanations.

 

Indeed, I tried with a AXI4-Stream Interconnect without the ports 8-15, the arbitration is correct on all active ports.

 

The True Round-Robin option is not accessible with the AXI4 Stream Interconnect RTL (choice is between regular Round-Robin and Fixed), is there a way to enable it through tcl?

A solution could be to use the AXI4 Stream Switch directly but we lose some AXI4 Stream Interconnect features.

0 Kudos