Forum Discussion
New ContributorF-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.
New ContributorHello, paveetirrasrie_Altera ,
I read through your response yesterday and went through some of the troubleshoot steps you mentioned.
I upgraded the project and IPs to Quartus 26.1 and ensured the jtag version was also consistent with the 26.1 version. After recompiling the project and resetting the board, I reran the internal serial loopback test (run_test) and this appeared to resolve the issue and the test reported as passing.
However despite passing the test, the register reads at clk_tx_khz (0x128) and clk_rx_khz (0x12C) reported similar values to the ones shown in the log I posted initially (TX: ~402.8 MHz, RX: 161.1 MHz).
One thing I understood by reading the F-tile Ethernet Hard IP user guide is that i_reconfig_clk values other than 100 MHz may cause the wrong register values to be reported, so there was a equation to compensate for a different i_reconfig_clk. In my project, the clk is constrained to 250 MHz. That doesn't seem to address why the values are totally different though.
Beyond that I checked the rest of the clock connections according to the user guide and they appear to match the following diagram. The F-Tile Reference and Systems PLL IP is configured for a System PLL frequency = ~805.66 MHz while PMA reference frequency = 156.25 MHz. The Hard IP itself should output o_clk_pll and loopback into the i_clk_rx and i_clk_tx inputs. I noticed o_clk_pll is equal to the System Frequency PLL frequency divided by 2. I also noticed from F-tile Ethernet Hard IP register map, clk_tx_khz and clk_rx_khz appear directly to read i_clk_rx and i_clk_tx.
If those are both the case, the 402.832 MHz value reported for TXCLK in system console would appear to follow. I then am a little confused when you say that the RXCLK should be 156.25 MHz when that is the PMA reference frequency and not derived from the System PLL frequency.
I appreciate the help you've given so far; I would like to figure out this clk mismatch before I am confident, so any suggestions would be helpful.
Frequent ContributorHello,
Glad that the suggestion helped!!
To answer to your follow up question:
Why TX reads ~402.8 MHz, this is correct for your configuration
o_clk_pll is a clock derived from the F-Tile Reference and System PLL Clocks IP associated with the Ethernet IP port, and its frequency is equal to the PLL frequency divided by 2. F-Tile Ethernet Hard IP User Guide With your System PLL at 805.6640625 MHz, o_clk_pll supports 402.83203125 MHz or higher for all Ethernet modes without FEC, with IEEE 802.3 BASE-R Firecode (CL74), or IEEE 802.3 RS(528,514) (CL91), and the system PLL must be 805.6640625 MHz or higher. F-Tile Ethernet Hard IP User Guide So o_clk_pll = 805.664 / 2 = 402.832 MHz, and since i_clk_tx is fed from o_clk_pll, a TX reading of ~402.8 MHz (after correction) is exactly right.
Why RX reads ~161.1 MHz, and why this is NOT 156.25 MHz
This is the key point of confusion. The ~161.1 MHz you're seeing for RX is not the PMA reference clock (156.25 MHz). It is the o_clk_rec_div64 recovered clock frequency for 10GE. The proper frequency for o_clk_rec_div64 (shown as rx_clkout in timing reports) is 161.1328125 MHz for 10G and 40G designs, and 402.83203125 MHz or 415.0390625 MHz for other rates. Why are the o_clk_rec_div and o_clk_rec_div64 ports improperly constrained when examining the timing reports of the F-tile Ethernet Intel® FPGA Hard IP?
This tells me that in your design, i_clk_rx is being driven by o_clk_rec_div64 (the recovered clock), not by o_clk_pll. That is actually a valid and documented clocking arrangement. In IP version v5.0.0 (Quartus 24.1), the F-Tile Low Latency 50G Ethernet IP switched to using o_clk_rec_div64 (recovered clock) in the Rx PMA interface instead of o_clk_pll (system PLL clock) for the Rx MAC interface (i_clk_rx) here the system clock PLL output is used instead of the recovered clock. F-Tile Low Latency 50G Ethernet IP Release Notes So depending on which IP variant and version you're using, i_clk_rx may intentionally be sourced from the recovered clock rather than o_clk_pll.
Summary of what you're seeing:
TX ~402.8 MHz: i_clk_tx ← o_clk_pll = System PLL (805.664 MHz) / 2. Correct.
RX ~161.1 MHz: i_clk_rx ← o_clk_rec_div64 (10GE recovered clock). Also correct for 10GE,this is not the PMA reference clock of 156.25 MHz; it is a separate recovered clock output at 161.1328125 MHz.
The asymmetry between TX and RX clocks is expected in this topology. The 156.25 MHz PMA reference clock feeds the transceiver CDR/PLL hardware, it is not the same signal as i_clk_rx. 156.25 MHz is the recommended PMA reference frequency, supported when using FHT PMA or when auto-negotiation and link training is enabled. F-Tile Ethernet Hard IP User Guide It drives the PMA, not the MAC datapath clock.
If you want both TX and RX to run from o_clk_pll (402.832 MHz), you would need to verify that i_clk_rx is connected to o_clk_pll rather than o_clk_rec_div64 in your design. Both are valid depending on your use case, but the register readings will reflect whichever source is actually connected.
