F-tile 10GE Ethernet Reference Design ISSP Error

Hello,

The ISSP probe mismatch error is a consequence of those underlying failures — the probe is simply reporting that the aggregated status word doesn't match the all-pass pattern. Fixing the root causes below should resolve it.

Root cause #1: RXCLK vs TXCLK frequency mismatch

Your log shows:

TXCLK: 402,840 KHz (~402.8 MHz)

RXCLK: 161,130 KHz (~161.1 MHz)

These should be equal in internal serial loopback. The TX clock running at ~402 MHz while RX is at ~161 MHz is a strong indicator that the RX CDR has not locked, it is not recovering the clock from the looped-back serial data. This directly explains why Rx Frequency Lock Status = 0 and RX PCS Ready = 0.

rx_pcs_ready is an active-high asynchronous status signal for the RX datapath; it asserts when the RX datapath is ready to receive data, and deasserts when the reset signal asserts or during auto-negotiation and link training operation. Since your RX CDR hasn't locked, the datapath never becomes ready.

Root cause #2: jtagd version mismatch, this is likely your primary problem

You mentioned replacing the jtagd 24.1 executable with jtagd 25.1. This is a significant concern. The System Console TCL scripts in the 10GE reference design example were generated and validated against Quartus Prime Pro 24.1. Mixing a 24.1-compiled bitstream and 24.1 design scripts with a 25.1 jtagd can cause:

JTAG master path resolution failures (the service master path changes between versions)

Register reads returning sentinel/garbage values like 0xDEADC0DE , exactly what you see for Rx Frame Error and Rx AM LOCK

ISSP probe reads returning stale or incorrect values

I'd strongly recommend testing with a consistent toolchain: either use the full 24.1 jtagd with your 24.1 bitstream, or regenerate the design example entirely under 25.1 and use the 25.1 jtagd. The 0xDEADC0DE sentinel is a classic sign that a register read transaction did not complete successfully.

Root cause #3: Known issue with Quartus Prime Pro 24.1 and RX ready signals

There is a documented issue relevant to your exact Quartus version. Due to an unexpected behavior in the Agilex 7 F-tile Ethernet Hard IP 25G variant, there is a frequency mismatch between o_clk_rec_div and o_clk_revc_div64, which causes link loss for one clock reset sequence before o_rx_pcs_ready is available. This problem is fixed beginning with Quartus Prime Pro Edition software version 24.2. While that specific issue is documented for the 25G variant, the underlying reset sequencing sensitivity exists in 24.1 broadly and your 10GE design running on 24.1 may be hitting related reset-sequencing timing issues.

Recommended diagnostic and resolution steps

Restore jtagd 24.1 for your 24.1 bitstream and re-run the test. The 0xDEADC0DE register reads are the most urgent symptom to eliminate first, as they indicate the JTAG/System Console path is not communicating correctly with the IP.

Confirm the reference clock. 156.25 MHz is the recommended frequency for all Ethernet modes and is the only supported frequency when using FHT PMA or when auto-negotiation and link training is enabled. Your RXCLK reading of ~161 MHz is close but not exactly 156.25 MHz × any standard division factor — this warrants checking your board's reference clock source and the F-Tile Reference and System PLL Clocks IP configuration.

Upgrade to Quartus Prime Pro 24.2 or later if possible. The 24.1 → 24.2 fix for the reset/clock-recovery issue is directly relevant to your symptom of RX PCS ready not asserting after a soft reset.

In summary: the ISSP probe mismatch is a symptom, not the root cause. The primary suspects are (1) the jtagd version mismatch corrupting register reads, and (2) the RX CDR not locking due to either a reference clock issue or reset sequencing timing in Quartus 24.1. Address those two first and the rx_pcs_ready and ISSP probe issues should resolve together.