Agilex7 F-TILE ethernet hard IP 200G - Agilex7 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? Replies: Re: Agilex7 F-TILE ethernet hard IP 200G than you for replay！ according to you suggestion, after fixing the reference clock pin assignment, the sys pll lock can be asserted and rx_pcs_ready is also asserted base on the Ftile 200Gx4 hard ip. But for Ftile 400Gx4 hard ip， sys pll lock can be asseted, but rx_pcs_ready is not asserted. Replies: Re: Agilex7 F-TILE ethernet hard IP 200G Hi , Based on the status signals shared: * tx_lanes_stable = 0 * sys_pll_locked = 0 * tx_pll_locked = 1 the 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 initialization 2. SYS PLL calibration or configuration issue * Invalid PLL sharing or lane configuration * Unsupported PLL/channel placement combination 3. FGT lane bonding or placement issue * Invalid lane grouping for 200Gx4 configuration * PLL routing/placement legality issue 4. 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 status The 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 Replies: Re: Agilex7 F-TILE ethernet hard IP 200G yes, I test the example design with 200G. And the F-tail hard ip enable auto negation feature. when we test on board, the debug status: o_sys_pll_locked=1 o_tx_pll_locked=1 o_tx_lanes_stable=0 o_rx_pcs_ready=0 the tx lanes stable signal of hard IP is 0. so what should we do for the next step? Replies: Re: Agilex7 F-TILE ethernet hard IP 200G Hello, Good day!!! Are you observing this in example design or this is your custom design? Regards, Pavee