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: 
Visitor mtrovato
Visitor
8,467 Views
Registered: ‎12-31-2014

Aurora 64b/66b latency measurement

Dear all,

 

I'm using Vivado 2014.1 and I generated

 

1) Aurora 64b/66b example design (V9.2) [1]

2)  7 series FPGAs Transceiver Wizard example design (V3.2) follwing the instructions in Appendix D of [2]

 

for xc7k325tffg900-2.  I measure the latency on a Kintek7 FPGA in  NE PMA loopback, where the latency * is defined as the difference in user_clk cycles between the same packet in tx and rx, as seen in ila. I obtain

 

1) ~ 50 clks 

2) ~ 30 clks 

 

Why such a large difference? By looking a Fig 2.2 of [1] and at the F/Ws in 1) and 2) I can guess that the AXI4-stream+PE add a consistent amount of user_clk cycles because it has to deal with asynchrounous clks, as described in [2]. Am I mistaken?

 

If my guess is correct, I'd like to ask you

  • whether 1) or 2) is more appropriate for my future projects, which target exchange of data beween two Kintek7 FPGA's with the lowest possible latency. Each FPGA will be sourced by a different clk;
  • are all the extra clks added by AXI4-stream+PE are targetting the clock compensation? If not, can I save some clks anyhow for the projects described above

 

 

Last but not least, notice that a similar behavior (but relatively smaller difference) is seen in Aurora 8b/10b, where I get

 

1) 38 ckls

2) 31 clks

 

 

Thanks a lot 

Best,

Marco

 

 

-----

 *: I also estimated the latency according to definition in [2] (difference in user_clk cycles between 

the first assertion on s_axi_tx_tvalid and s_axi_tx_tready to m_axi_rx_tvalid): I obtain about 46 clks, which is somehow consistent with [1] (slightly smaller because of the different loopback mode, I guess)

 

[1]: http://www.xilinx.com/support/documentation/application_notes/xapp1192-aurora-64b66b-on-kc705.pdf

[1]: http://www.xilinx.com/support/documentation/ip_documentation/aurora_64b66b/v9_2/pg074-aurora-64b66b.pdf

[2]: http://www.xilinx.com/support/documentation/ip_documentation/axis_infrastructure_ip_suite/v1_1/pg085-axi4stream-infrastructure.pdf

0 Kudos
3 Replies
Moderator
Moderator
8,418 Views
Registered: ‎02-16-2010

Re: Aurora 64b/66b latency measurement

You cannot compare GT wizard design with Aurora. With Aurora IP, it has protocol implemented in data path along with transceiver interface.

Along with latency, compare the number of GT blocks used by 8B10B and 64B66B cores. With 8B10B, most of the required blocks are available from GT but with 64B66B some functionality of the protocol is needed to be implemented in fabric.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
Visitor mtrovato
Visitor
8,403 Views
Registered: ‎12-31-2014

Re: Aurora 64b/66b latency measurement

 


@venkata wrote:
You cannot compare GT wizard design with Aurora. With Aurora IP, it has protocol implemented in data path along with transceiver interface.

Along with latency, compare the number of GT blocks used by 8B10B and 64B66B cores.
Thanks for your answer: I understand now why the Aurora 64b/66b example design has a larger latency wrt the gt wizard example design. I also understand why such a difference is not as large in the 8b/10b case
With 8B10B, most of the required blocks are available from GT but with 64B66B some functionality of the protocol is needed to be implemented in fabric.


Concerning the last part of your answer I still have some doubts. The GT wizard design works properly when sending packet from one FPGA to another: doesn't this mean that it works fine in fabric?

 

One more question: is the extra logic of the Aurora example design targetting only the clock compensation? Or is there something else?

 

0 Kudos
Moderator
Moderator
8,391 Views
Registered: ‎02-16-2010

Re: Aurora 64b/66b latency measurement

Please check the protocol spec for more details of the IP implementation.
http://www.xilinx.com/products/design_resources/conn_central/grouping/aurora.htm
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos