cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
awhyte
Visitor
Visitor
9,840 Views
Registered: ‎02-13-2012

Two Aurora 8B/10B Cores on Virtex-6 Quad GTX Tile

I want to implement two Aurora 8B/10B Cores on a single Virtex-6 Quad GTX Tile. I have read user guide ug353, and it explains in Appendix A, Pg113, how to achieve this using the Virtex-5 family dual GTX tiles but not for Virtex-6 family.

 

I know that it is possible to use two Aurora 8B/10B cores in a single quad GTX tile of the Virtex 6 SX315t. However when you generate an Aurora 8B/10B core in LogiCore, the GUI only allows for one Aurora 8B/10B core per quad GTX tile. I know that modifications need to be made to the generated core files, and I need to know exactly what modifications need to be made.


Should I generate two aurora 8B/10B cores in LogiCore, create a new top level and instantiate the two aurora cores in the top level file? But then, how do I merge the two cores?

 

Should I run the Virtex-6 FPGA GTX Transceiver Wizard in LogiCore, create the top level and map new ports to another Aurora 8B/10B core?

0 Kudos
12 Replies
dann
Xilinx Employee
Xilinx Employee
9,815 Views
Registered: ‎03-23-2010

http://www.xilinx.com/support/answers/47672.htm

check this out and see if it helps. its more generic, but should cover all of the bases necessary.
0 Kudos
9,740 Views
Registered: ‎09-06-2012

I have the same need.

I have to implement 4 independent Aurora channel - single lane - on a single GTX Quad.

My question is: Should I need one MMCM per each Aurora channel, in order to create independent USER_CLK and SYNC CLK per each channel?

I already implement a similar design on a Spartan 6 (2 independent channel on a GTP Dual). In Spartan 6, the two GTP can share the PLL, which is used both for TX and RX. So I used only one PLL_ADV to create one USER_CLK and one SYNC_CLK supplied to both GTP.

But, from user guide ug366, this seems not to be the same for Virtex 6: The TX PLL and RX PLL can't be shared among GTX on the same Quad. May the use of only one MMCM for 4 GTX be problematic for clock compensation or this kind of issue?

Has anybody successfully implemented multiple Aurora cores on a single GTX Quad on a Virtex 6?

0 Kudos
gguasti
Moderator
Moderator
9,728 Views
Registered: ‎11-29-2007

Hello Leonardo,

please where in UG366 is written that you cannot share the MMCM between GTX in the same quad, or between TX and RX of the same GTX? Please can you elaborate your concern? Maybe I am missing something.

If TX and RX are working at the same nominal frequency, and if clock correction is in place at RX side, it should be possible to use one MMCM (i.e. synchronous with the TX) because the clock correction in the RX compensates for ppm differences.
UG366, figure 3-6 shows an MMCM shared between multiple TX
You need however to place the MMCM in the same clock region of the driving GTX.

thanks

Giovanni

0 Kudos
9,698 Views
Registered: ‎09-06-2012

Thanks Giovanni for your reply! This is my first project with GTP/GTX so I'm not fully familiar with them.

 

Actually not the MMCM, but the RX PLL (or TX PLL) can not be shared with other transceiver (PLL section in the Shared Transceiver Features chapter of ug366).

Since this leads to a sligthly different architecture compared to the Spartan 6 project (where one PLL is shared between TX,RX of both GTP transceiver in a tile), I have had some doubts about the proper operation of clock compensation.

 

My doubts come from the fact that in my design the four GTX have to communicate with four distinct devices with independent clocks, but all with the same frequency. For this reason I talked about four single-lane channels.

I saw figure 3-6, but I was not sure that it was my case because in the title of the section there is written "Multiple lanes".


So, a single channel with 4 lanes work similarly to 4 single-lane independent channels with respect to clock compensation. Is this right?

In the Spartan 6 design I implemented two clock compensation modules, one per each channel. So, should I do the same in the Virtex 6 design? (4 clock compensation modules in this case)

0 Kudos
gguasti
Moderator
Moderator
9,693 Views
Registered: ‎11-29-2007

Hello Leonardo,

yes there is an important difference between the S6 Dual and V6 GT Quad architecture: in V6  for any transceiver there are two PLLs (called TX PLL and RX PLL). For applications where the TX and RX datapaths run at the same rate , the RX PLL can be shared between the TX and RX (powerdown the TX PLL to save power). It is true, the internal PLL in one GTX transceiver cannot be shared with other GTX transceivers.

 

If I correctly understood, in your design you have four independent lines. You assign a GTX to each line. You need one single local oscillator for the whole quad because all lines are working at the same line rate. Each GTX will share the RX PLL between TX and RX side, thus in total you power 4 PLLs. You will keep all four TX PLLs in powerdown.

 

When the four RX PLLs are all locked to the same local oscillator we can think to them as synchronous PLLs. What is different between your four lines is the ppm of the four far end transmitters, so each GTX RX will need independent clock correction activity. In V6, as in S6, the GTX has a built-in CC block. In most cases you do not need to implement your own CC in the fabric.

 

My best wishes for your first GTX experience. Please notice that the GTX Wizard (Core Generator) helps a lot, and a example design both for simulation and for HW is created.

 

best regards,

Giovanni

0 Kudos
9,684 Views
Registered: ‎09-06-2012

If I correctly understood, in your design you have four independent lines. You assign a GTX to each line. You need one single local oscillator for the whole quad because all lines are working at the same line rate. Each GTX will share the RX PLL between TX and RX side, thus in total you power 4 PLLs. You will keep all four TX PLLs in powerdown.

 

Yes, you perfectly depicted the situation.

 

When the four RX PLLs are all locked to the same local oscillator we can think to them as synchronous PLLs. What is different between your four lines is the ppm of the four far end transmitters, so each GTX RX will need independent clock correction activity. In V6, as in S6, the GTX has a built-in CC block. In most cases you do not need to implement your own CC in the fabric.

 

I'm implementing the Aurora core and the Core generator creates a clock compensation module connected to the TX interface of the Aurora lane.

Do you suggest to not use this CC module? Is it unnecessary for proper operation of the Aurora channel?

 

Thanks a lot for your support and best regards.

Leonardo

 

0 Kudos
gguasti
Moderator
Moderator
9,678 Views
Registered: ‎11-29-2007

hello Leonardo,

the Clock Compensation module in Aurora is needed in your case. I forgot you were using Aurora.

 

This module controls the clock correction words (/K23.7/K23.7/) density in the datastream, so that max +-100ppm is corrected.

This module uses the internal GT Clock Correction block: the CC words are then removed or replicated by the internal GT CC block. (in the GT module you should find CLK_CORRECT_USE=TRUE)

 

Please check the frequency precision of your oscillators.

best regards,

Giovanni

 

0 Kudos
9,670 Views
Registered: ‎09-06-2012

OK, thanks a lot!

 

With regard to the USER_CLK and SYNC_CLK of the Aurora core, I will implement a solution analogous to figure 3-6 of ug366 even if the 4 GTX aren't grouped into a single channel, but will connect to four independent devices.

In this way, I will use only one MMCM and the four Aurora Local Link interfaces will all have the same USER_CLk signal.

 

I'm going to make some tests as soon as we get the boards prototype.

 

Thanks again for your help!

Leonardo

0 Kudos
htehte
Visitor
Visitor
9,327 Views
Registered: ‎08-23-2010

I am interested in achieving the same results.

 

My understanding would be that I would have to create four separate corgens for the Aurora 8b10b but that I would use the same clock module to produce the user_clk_i (and sync_clk_i) ( and probably a single reset_logic) for all four Aurora modules.  This requires the tx_clock from one Aurora module (generated from the GT_CLK?) to be the clock input into the shared clock module?

 

How did this work for you because I am still not getting four separate channels to link up.

0 Kudos
hotrodtodd1968
Visitor
Visitor
4,258 Views
Registered: ‎03-24-2011

I have a similar question. I am using two Aurora single-lane 8b10b cores in a Kintex7 device in the same bank. Each core is connected to receivers on separate boards. I want to use a single clock for TXOUTCLK, or user_clock for both cores to simplify my design. However, I am measuring phase difference between the two user clocks - and the phase relationship seems to change each time I re-program the FPGA. My FAE says that a single clock should work, but I have not been able to get it to work. Has anyone out there had a successful experience with this? I am using 14.4. The whole experience has been very trying, starting with IES errata with 13.3 and now this issue with production parts. The Aurora core has not been easy to deal with. Files are arranged all over the place. To get the two cores in the same bank I had to modify the code to not instantiate two QPLLs, and then it turns out the core doesn't actually use the QPLL for the GT primitive anyways. Without help from my FAE, I'd be really stuck. But I'm still stuck...

0 Kudos
Anonymous
Not applicable
4,197 Views

Hi, leonardo!

Have you resolve the problem?

Thank you!

0 Kudos
Anonymous
Not applicable
4,196 Views

Hi, awhyte!

Have you resolve the problem?

Thank you!

0 Kudos