cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ADGio
Visitor
Visitor
510 Views
Registered: ‎07-01-2020

ethernet 10G/25G reset

Hello!

I have the following problem.

I use an external reference 161 MHz clock for my Ethernet 10/25G core instance.

 

If the ref clock is present before the ending of bitstream charge, it works perfectly.

But, if I program the clock by a I2C core from the FPGA, that is, if the clock is not active when the core is initialized, but it starts after, the core does not work.

The problem is that, if I reset the core with the soft system reset, it does not work.

It is like the sys_reset does not perform a complete reset: for example, it's like the GTY is not resetting correctly, but I don’t understand, because with in functional simulations it works.

 

In the core instance, I found the following reset ports: sys_reset, tx_reset_0 , tx_reset_1, rx_reset_0 , rx_reset_1, and they are all connected to the general system_reset.

Any suggestion?

Thank in advance

Regards

Andrea

0 Kudos
6 Replies
guozhenp
Xilinx Employee
Xilinx Employee
491 Views
Registered: ‎05-01-2013

GT will fail to work if its reference clock isn't stable.

So if the reference clock has not been ready, we suggest hold GT reset and release it after the clock is stable.

0 Kudos
ADGio
Visitor
Visitor
467 Views
Registered: ‎07-01-2020

Hello Guozhenp,

thank you for your answer.

>So if the reference clock has not been ready, we suggest hold GT reset and release it after the clock is stable.

Yes, that was the idea.

I'm holding the system reset for a while, until the clock is established. But it seems not to work.

In my design, the system reset signal controls:

  • Sys_reset,
  • rx_reset_0 and rx_reset_1
  • tx_reset_0 and tx_reset_1

Is there any input port needed to reset GTYs?

I have the "include shared logic in core" option selected.

Thank you

Andrea

0 Kudos
guozhenp
Xilinx Employee
Xilinx Employee
463 Views
Registered: ‎05-01-2013

sys_reset should be OK.

If you check the codes inside the IP core .xci, you can see sys_reset is connected to sys_reset.

assign gtwiz_reset_all_in_0 = sys_reset | master_watchdog_barking_sync_0;

 

1. When the failure happens, do you have any way, e.g. doing some specified reset to recover the issue now?

2. When the failure happens, could you check the details on which part fails to work? GT QPLLLOCK asserted? GT TX/RXRESETDONE asserted?

0 Kudos
guozhenp
Xilinx Employee
Xilinx Employee
459 Views
Registered: ‎05-01-2013

Could you also check the issue in the board "Serial Transceivers"?

We need some GT engineers' suggestions on it instead of Ethernet IP core.

Maybe reset is not enough in the case. You've to download the bitstream after the reference clock is stable.

0 Kudos
ADGio
Visitor
Visitor
449 Views
Registered: ‎07-01-2020

Thanks, for the help

I'll check these signals ASAP.

And I'll write to the other group also.

 

Guozhenp, I have another doubt about 10/25 core.

There are two sets of output clock: rxoutclk_out* and txoutclk_out*.

In simulation I observed that rxoutclk_out is delayed w.r.t txoutclk_out, furthermore, it seems that the received data are aligned with txoutclk_out.

I suppose I should use rxoutclk_out for clocking a Ingress Buffer FIFO for received data. And, in the same way,  I should use txoutclk_out for clocking an Egress buffer FIFO for data to send.

Is it correct? Could you confirm?

 

Thank you very much

Andrea

0 Kudos
guozhenp
Xilinx Employee
Xilinx Employee
436 Views
Registered: ‎05-01-2013

In simulation, you may not see the frequency difference between TXOUTCLK and RXOUTCLK while the phase difference is not important here.

TXOUTCLK is sync to TXDATA and RXOUTCLK is sync to RXDATA. If this is an Async system which means that the link partner has the different clock source, the 10G/25G RXDATA/RXOUTCLK is sync to the link partner clock and it has a little frequency difference (maybe only +/-100ppm) from TXDATA/TXOUTCLK which is sync to the lock reference clock.

So yes, you should use RXOUTCLK for RXDATA and TXOUTCLK TXDATA. Unless it's sync system and both ends have the same clock source. If it's the case, you can use TXOUTCLK for both TXDATA and RXDATA.

0 Kudos