09-13-2020 11:55 PM
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.
Thank in advance
09-14-2020 01:19 AM
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.
09-14-2020 11:22 PM
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:
Is there any input port needed to reset GTYs?
I have the "include shared logic in core" option selected.
09-14-2020 11:37 PM
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?
09-14-2020 11:55 PM
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.
09-15-2020 05:04 AM
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
09-15-2020 07:23 PM
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.