Occasional ContributorAgilex7 F-TILE ethernet hard IP 200G
Now we develop a project with agilex7 fpga. In the project we generate 200Gx4 ethernet hard ip.
during testing on-board, the reset flow of the ethernet IP failed to complete successfully:
The IP output signals o_rst_ack_n / o_tx_rst_ack_n / o_rx_rst_ack_n remain permanently High and never pull Low. This causes the input reset signals i_rst_n / i_tx_rst_n / i_rx_rst_n fed into the Ethernet IP to stay stuck in the Low-level reset state and never exit reset.
the following signal status as follow by read register:
tx_lanes_stable = 0
sys_pll_locked = 0
tx_pll_locked = 1
the IP reset sequence in the IP datasheet shows:
so what should we do for the next step? Do you have any suggestion?
Hi ,
Based on the status signals shared:
* tx_lanes_stable = 0
* sys_pll_locked = 0
* tx_pll_locked = 1the issue is most likely related to the system PLL/reference clock domain not achieving lock, which prevents the F-Tile Ethernet Hard IP reset sequence from progressing successfully.
Since `sys_pll_locked` remains deasserted, the internal reset controller continues to hold the IP in reset. As a result:
* `o_rst_ack_n / o_tx_rst_ack_n / o_rx_rst_ack_n` remain High,
* `i_rst_n / i_tx_rst_n / i_rx_rst_n` stay asserted Low,
* and `tx_lanes_stable` never transitions to 1.The fact that `tx_pll_locked = 1` indicates that the TX PLL itself is operational, while the system PLL domain required for PCS/reset sequencing is not locking properly.
Possible root causes include:
1. Incorrect or unstable reference clock
* Refclk frequency mismatch with IP configuration
* Refclk not connected to the intended FGT reference clock input
* Clock instability during initialization2. SYS PLL calibration or configuration issue
* Invalid PLL sharing or lane configuration
* Unsupported PLL/channel placement combination3. FGT lane bonding or placement issue
* Invalid lane grouping for 200Gx4 configuration
* PLL routing/placement legality issue4. Reset sequencing/timing issue
* Reset released before clocks become stable
At this stage, we would recommend checking:
* Actual reference clock frequency on board
* IP configuration versus supplied refclk frequency
* Quartus compilation reports for PLL/lane placement warnings
* Additional status signals such as `rx_pcs_ready`, `tx_pcs_ready`, and PLL calibration statusThe current symptoms strongly indicate that the reset sequence is being blocked due to the SYS PLL domain not locking successfully.
These are possible rootcause, please verify it and feel free to reach out if the issue persist.
Regards,
Pavee
