Using GTX transceivers

Hi there,

The IBERT design incorporates all the necessary items in that one core.  You will want to run a protocol as that encapsulates error detection / correction.  That is what the numbers after Aurora stand for, data vs payload.  The type of data transactions. 

The best advice I can give you is look at an Aurora design.  That will give you an idea what you need to do as a minimum to make this work for you.  I would not suggest designing you own.  There is a LOT that goes into a design like that.

Aurora is designed to be about as lightweight as something like this can be. 

Constraints are necessary for your design, although maybe not as necessary JUST for the transceivers.  If your design as a WHOLE is not properly constrained, you will likely have issues at places in your design that eventually trickles to the transceivers.  That is, even IF the transceivers are working, you might not be able to get data to the SERDES in time or with enough robustness to function properly (which is where using IBERT comes in to validate THAT portion of your design by tuning the configuration that your AURORA design would be using).

--Dan

Many thanks for your reply!

I have been studying the Aurora core using "Aurora 64B/66B v11.2 LogiCORE IP Product Guide". I now have fair understating of the core and I managed to run the simulation successfully with the Aurora example design generated by Vivado using the "Open IP Example Design..."  option. I'm using the core in TX-only Simplex mode for the SMA connectors (MGT1 or GTXE2_X0Y1).

My instantiation of the example design uses two differential clocks: gt_refclk1_p/gt_refclk1_n and init_clk_p/init_clk_n and one singe-ended clock: drp_clk_in. These clocks should be driven from User I/O ports GTXQ0_P, GTXQ0_N, INIT_CLK_P, INIT_CLK_N and DRP_CLK_IN respectively. In the simulation the desired clocks are generated by the testbench aurora_6466b_0_TB but now I'm having trouble to write proper constraints to get this working in real hardware.

It seems that the GTX reference clock is already taken care of in the automatically generated .xdc constraints file: 

   create_clock -period 4.000 [get_ports GTXQ0_P] 

But for the INIT_CLK and the DRP_CLK I have not yet managed to find proper sources. In a design tutorial  "Designing a System Using the Aurora 64B66B Core (Duplex) on the KC705 Evaluation Kit" the INIT_CLK is just connected to pins supplying a 200 MHz differential clock using the LOC command as with the GTXQ0. But my board doesn't have this kind of a clock source. And the reference design doesn't have DRP_CLK at all.

So my question is that where can I get these clocks and how should they be constrained? The differential INIT_CLK should be between 50-200 MHz and the DRP_CLK should be from 50 to x MHz ("where x is device and speed grade dependent." -LogiCORE IP Product Guide). In the IP customize options I now have selected the default values of 50 MHz and 100 MHz for these clocks. I have been trying to genetare the INIT_CLK from the GTXQ0 clock using create_generated_clock command but yet with no luck. It also came to my mind that could I use the Zynq processing system clock FCLK_CLK0 somehow? It might be trivial but I have not yet understood how can I interface with this clock from the constraints file..

I would like to avoid using the IDT programmable clock source offered by the FMC Carrier Card V2 because the final product is only using the PicoZed board.

All the help is much appreciated!
-Jan

I have now been experimenting with MMCM module to derive demanded clocks from gt_refclk for the Aurora example design. Vivado then complains that the instantiated MMCM resides in different clock region than the the reference clock source GT Refclk. Also the Aurora example design uses a MMCM internally (in aurora_64b66b_0_clock_module.v) again in a another clock region. This resulted in critical warnings so I decided to try using of Zynq PL Fabric Clocks using the ZYNQ7 Processing System core.
 

Solution for using PL Fabric clocks wasn't so hard in the end: I created a block design from Vivado IP Integrator, instantiated a ZYNQ7 Processing System core and form the core options enabled two PL fabric clocks FCLK_CLK0 and FCLK_CLK1 with desired frequencies. After that I created two output ports to the design and attached the clock outputs of the Zynq core to these output ports. Now I just needed to generate a hdl wrapper from the block design using "Create HDL Wrapper..." option. That wrapper I then instantiated into the aurora example design and connected the clock signals.

I wonder why I couldn't find this solution anywhere..

Now I'm able to set up a channel (CHANNEL_UP and LANE_UP goes high) using one Aurora core for one GTX transceiver MGT_X0Y1 (SMA) with the example design when connecting the SMA connectors in a loopback with SMA cables. Instantiating a second Aurora core for the SFP+ interface (MGT_X0Y2) has not yet been succesfull. I'm trying a setup shown in the Aurora 64B/66B v11.2 LogiCORE IP Product Guide figure 3-17. For some reason the transceiver core MGT_X0Y2 is not instantiated at all when looking at the implemented design "Device" view. This is probably out of scope for Avnet support so I will move the issue to Xilinx forum if I'm unable to figure it out.

It took some time and experimenting but I now have a working solution with two PicoZed FMC Carrier Card V2 cards connected with optical fibre. I instantiated the Aurora64B66B core with following options:

Line Rate (Gbps): 6.25
GT Refclk (MHz): 250.000
INIT clk (MHz): 50.0
GT DRP clk (MHz): 100.0

Dataflow Mode: Duplex
Interface: Framing
Flow Control: None

DRP Mode: AXI4 Lite

GT Selections:
Lanes: 1
GTXQ0: GTXE2_X0Y2 (SFP+)

Shared Logic:
Include Shared Logic in the core

I then created the example design and used it as a reference to make my own reset and control modules and the constraint file. When I managed to get the channel up (Aurora channel_up signal connected to PL LED) I created a data module writing AXI4 Stream data to the Aurora core via AXI4-Stream Data FIFO. This is because the USER_DATA_S_AXIS_TX interface is clocked by the user_clk_out clock that is asynchronous to the FCLK_CLK0 system clock I use to create the stream. Same thing with receiving the data from the core (USER_DATA_M_AXIS_RX).

For the GT Refclk I used the onboard oscillator generating 250 MHz clock. Init clk and GT DRP clock I took from ZYNQ Processing System FCLK_CLK0 and FCLK_CLK1.