cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
1,091 Views
Registered: ‎11-23-2018

GTH Transceiver data fifo clock issue

Jump to solution

Hello Everyone,

Let me first introduce you with my design, Design has GTH transceiver & 2 FIFO, one FIFO at TX side & another at RX side.

DATA path:

40bit parallel data --> TXFIFO(40*256) --> GTH TX parallel data input port (40bit) -->  GTH transceiver serial line loopback (via FMC loopback)--> GTH RX parallel data output (40bit) --> RXFIFO 

TXFIFO :  WR clock is 125 MHz (KCU105 kit) & RD clock txuserclk output of transceiver(125MHz)

RXFIFO :  WR clock is txuserclk output of transceiver(125MHz) & RD clock is 125 MHz (KCU105 kit)

We are passing fix data to TX FIFO input port. 

Both FIFO gets reset with rx_reset_done signal comes from the GTH.

GTH starts to read from TX FIFO after 5 words written and in the same way at RX side design reads data from RX FIFO after GTH writes 5 words.

So the issue I am facing is both FIFO have the same clock frequency but the different source & we have taken care that after writing 5 words we start reading at both side of FIFO despite that the RXFIFO gets full frequently.

As per my understanding if the clock is the same for RD & WR than the ratio of 5 words should remain constant at RX SIDE.

Please guide me. Fill free to contact me for any requirement of further information. 

  

 

 

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
583 Views
Registered: ‎11-23-2018

Hello @eschidl 

I glad to know you that the issue with FIFO is resolved with the following clock scheme.

Clock scheme:

1. External clock(125M) => IBUFDS_GTE3/O => GTH (125M)

                                  IBUFDS_GTE3/ODIV2 => BUFG_GT => Fabric logic(TX_FIFO_WR CLK & RX_FIFO_RD_CLK) (125M).

2.125M free running for DRP only.

Thanks to @karnanl 

 

Thanks for the support in my issue. @andrewlan @behnam_2705new @archangel-lightworks   

Kudos!!!!!!!!

View solution in original post

19 Replies
Highlighted
1,082 Views
Registered: ‎07-23-2019

@verilog_bee 

If you read from the FIFO at 125M after 5 words are there but the GTH keeps on writing at higher speed, yes, you will fill it.

How are you testing this? Do you have an RX-TX loop, to make sure you send 5 and only 5 words?

Even though, some peripherals frame data, have you checked that?

What about (as a way of testing) increasing the buffer size to a few Kwords?

Cannot you handshake your GTH and pause writing the RX FIFO is near full?

0 Kudos
Highlighted
Adventurer
Adventurer
1,063 Views
Registered: ‎11-23-2018

How are you testing this? Do you have an RX-TX loop, to make sure you send 5 and only 5 words?

We have FMC loopback card for providing the loopback to the serial output of GTH lines. And it is a continuous process of data write & read as RX_reset_done signal comes from GTH. We have managed the 5 word logic on DATA COUNT output of Xilinx's FIFO IP. As GTH write data into FIFO, wr_data_count data on the output port of FIFO get incremented & after 5 wr_data_count we enable read input of FIFO. 

Even though, some peripherals frame data, have you checked that?

Yes, there is no issue with that.

What about (as a way of testing) increasing the buffer size to a few Kwords?

we tried to increased depth, almost double the size. still facing the same issue.

Cannot you handshake your GTH and pause writing the RX FIFO is near full?

No. as per design there is no such mechanism.

 

 

0 Kudos
Highlighted
1,051 Views
Registered: ‎07-23-2019

 

@verilog_bee 

If you don't have a handshake between the TX FIFO and the GTH, the transceiver will not know the buffer is empty after 5 words taken and sent and will carry on sending stuff (probably the last word forever). Could this be happening? 

0 Kudos
Highlighted
Adventurer
Adventurer
1,007 Views
Registered: ‎11-23-2018

Thanks for quick reply @archangel-lightworks 

We do not have an issue at TXFIFO with the EMPTY signal. TX FIFO is working fine with clock & data. we are worried about the FULL signal asserted at RX FIFO. 

0 Kudos
Highlighted
998 Views
Registered: ‎07-23-2019

Can you simulate it?

Highlighted
Adventurer
Adventurer
991 Views
Registered: ‎11-23-2018

After verifying the design in the simulation we moved to hardware test. Simulation is O.K no FULL signal detected at RX.

0 Kudos
Highlighted
Adventurer
Adventurer
990 Views
Registered: ‎11-23-2018

After verifying the design in the simulation we moved to hardware test. Simulation is O.K No FULL signal detected at RX.

0 Kudos
Highlighted
Adventurer
Adventurer
945 Views
Registered: ‎11-23-2018

I request to Xilinx's support employee  &  archangel-lightworks for the kind response & suggestions on the issue.

0 Kudos
Highlighted
Adventurer
Adventurer
924 Views
Registered: ‎11-23-2018

Can you please help me on this issue. @karnanl 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
907 Views
Registered: ‎03-30-2016

Hello

I think your system diagram looks like this:
I believe you are transmitting 40bit RAW data since your I/F is 40 bits. ( Please correct me , if my understanding is wrong )

XC_VERILOGBEE_SYSTEM.jpg

My verdict:

This system will not work, since you are transmitting a raw 40 bits data using different clock domain.
There is no mechanism to absorb the clock frequency difference between domain in the system.

You should use clock correction mechanisim to absorb ppm difference between clock domain.
This features is not accesible with RAW data.



1. I believe the 125 MHz (clock A) and 125MHz (from TXUSRCLK) has a different frequency.
    # TXUSRCLK 125 MHz is faster so your RX FIFO is FULL.

2. [VB] After verifying the design in the simulation we moved to hardware test. Simulation is O.K no FULL signal detected at RX
    [LK] Your simulation seems to be okay , because ( I believe ) the 125 MHz (clock A) and 125MHz (from TXUSRCLK) has excatly the same frequency in the simulation.

3. [VB] We do not have an issue at TXFIFO with the EMPTY signal. TX FIFO is working fine with clock & data. we are worried about the FULL signal asserted at RX FIFO.
    [LK] Could you simulate your design with Clock A slightly slower than TXUSRCLK ( for example 123 MHz), and see the behavior of your TXFIFO.
           TXFIFO should say EMPTY or FULL if we have clock frequency difference between clock domain.


Regards
Leo

Highlighted
Xilinx Employee
Xilinx Employee
903 Views
Registered: ‎03-30-2016

Hello @verilog_bee 

You also put this question on the wrong board.
This is a Serial Transceiver topic.


Thanks & regards
Leo

Highlighted
Adventurer
Adventurer
895 Views
Registered: ‎11-23-2018

Thanks for the quick reply.

Your understanding is absolutely right except one thing which I have corrected in the attached design. To absorb the ppm difference we put FIFO in our design.

Can you suggest any other method to absorb PPM difference in reference to GTH transceiver?

XC_VERILOGBEE_SYSTEM.jpg
0 Kudos
Highlighted
Adventurer
Adventurer
894 Views
Registered: ‎11-23-2018

If this is not the right place for my query then please suggest me the name of Xilinx person or place where I can get support.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
876 Views
Registered: ‎03-30-2016

Hello @verilog_bee 

1. "Serial Transceiver" board should be better for Transceiver related discussion.
    https://forums.xilinx.com/t5/Serial-Transceivers/bd-p/transceivers

2. Propose to use the following connectivity, with a single clock domain.
    XC_VERILOGBEE_PROPOSAL.jpg

Regards
Leo

Highlighted
Adventurer
Adventurer
868 Views
Registered: ‎11-23-2018

I am very glad to have such a fast response from you. @karnanl 

Thanks once again to understand our situation.

We have our legacy IP core with FIFO design which I mentioned in the last reply. It is running smoothly on INTEL FPGA. At this moment, we are not able to change the whole IP core design as per your proposed clock scheme. 

Let me put my query to the related forum page of the transceiver as per your suggestion.

You will have further required information for this issue If it is possible for you to help me out. OR you can simply connect the right person to me. 

Thank you very much.

 

0 Kudos
Highlighted
Explorer
Explorer
853 Views
Registered: ‎06-25-2014

It seems your root problem is your 125 MHz (KCU105 kit) clock is slighly slower (e.g. PPM differences between crystals) than the GT clock causing the Rx FIFO to overflow.

How about speeding up your 125 MHz (KCU105 kit) clock to say 150Mhz? Now you can monitor the empy flag for valid data on the Rx FIFO and it will never overflow. You can either leave the Tx path as is or also use the 150Mhz clock to write data, but with flow control on the Tx FIFO full flag so you don't write to a full fifo.

Highlighted
Adventurer
Adventurer
825 Views
Registered: ‎11-23-2018

Thanks for your response @andrewlan 

Rest of the design is based 125MHz so It is not possible to change the clock to 150MHz.

Please share if you have other possible solution.

0 Kudos
Highlighted
Explorer
Explorer
762 Views
Registered: ‎03-16-2019

actually, you will not be successful until your Rx incoming clock MUST be recovered to have the same RX and TX clock. 

this is the only way that I know to do to catch your desired result.

I have seen some techniques to have the same RX and TX clock, but I cannot pass the loopback test with them. consider that if you have a slight difference in your RX and TX clock( even less than 1ppm), your test will not work properly.

----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
----------------------------------------------------------------------------

 

Highlighted
Adventurer
Adventurer
584 Views
Registered: ‎11-23-2018

Hello @eschidl 

I glad to know you that the issue with FIFO is resolved with the following clock scheme.

Clock scheme:

1. External clock(125M) => IBUFDS_GTE3/O => GTH (125M)

                                  IBUFDS_GTE3/ODIV2 => BUFG_GT => Fabric logic(TX_FIFO_WR CLK & RX_FIFO_RD_CLK) (125M).

2.125M free running for DRP only.

Thanks to @karnanl 

 

Thanks for the support in my issue. @andrewlan @behnam_2705new @archangel-lightworks   

Kudos!!!!!!!!

View solution in original post