Arria 10 Native PHY 66:64 RX wrong word with valid asserted
I am using Arria 10 Native PHY in Basic Enhanced PCS mode at 12.5 Gbps for a custom protocol. The protocol layer is implemented in FPGA fabric. The Native PHY is intended to provide the serial transceiver path and the Enhanced PCS 66b gearbox only. The fabric provides one 66b block per clk_sys: 2-bit sync/control header + 64-bit payload The goal is a non-backpressure full-rate interface: one 66b TX block accepted every clk_sys, and one 66b RX block produced every clk_sys after RX lock. I've attached the .tcl to generate the core, but some of the key config parameters are: protocol_mode = basic_enh data_rate = 12500 enh_pld_pcs_width = 66 enh_pcs_pma_width = 64 TX 64b/66b encoder = disabled RX 64b/66b decoder = disabled TX scrambler = disabled RX descrambler = disabled RX block synchronizer = enabled TX FIFO mode = Phase Compensation RX FIFO mode = Phase Compensation double width = disabled 10GBASE-R insert/delete = disabled Interlaken deletion features = disabled Clocking: clk_sys <= tx_clkout(0); tx_coreclkin <= (others => clk_sys); rx_coreclkin <= (others => clk_sys); Controls: tx_enh_data_valid <= (others => '1'); rx_enh_fifo_rd_en <= (others => '1'); tx_pma_elecidle <= (others => '0'); 66b mapping: (inside a loop that iterates for every channel 'c') tx_parallel_data((c+1)*64-1 downto c*64) <= tx_data(c)(63 downto 0); tx_control((c+1)*2-1 downto c*2) <= tx_header(c)(1 downto 0); rx_data(c)(63 downto 0) <= rx_parallel_data((c+1)*64-1 downto c*64); rx_header(c)(1 downto 0) <= rx_control((c+1)*2-1 downto c*2); Observed in serial loopback simulation: With RX FIFO in RX Register mode, rx_enh_data_valid has periodic bubbles, apparently matching the 66:64 gearbox cadence. With RX FIFO in RX Phase Compensation mode, rx_enh_data_valid stays asserted, but rx_parallel_data periodically has a whole-word discontinuity. It looks like a 66b word is skipped/repeated, or the latency changes by one word. The event periodicity is about 160 ns, close to the expected 66:64 gearbox cadence. These two captures are from a sequence where I receive wrong data with rx valid asserted (the first is the tx'ed sequence and the second the received: To make the issue clear I mapped the word to a letter to make it easier to see the issue: In the capture above there is the tx and rx sequence, and can be seen where the pattern breaks compared to tx. My question is: For Arria 10 Native PHY Basic Enhanced PCS with enh_pld_pcs_width=66, enh_pcs_pma_width=64, and RX FIFO in Phase Compensation mode, is a continuous non-backpressure 66b RX stream supported? If yes, what configuration or clocking condition could cause a periodic one-word wrong while rx_enh_blk_lock, rx_enh_data_valid, and rx_control remain stable? Thanks in advance.
BER Degradation Observed When Enabling Multiple DFE-Adapted Channels on Arria 10 GX
Hello Altera Support Team / Forum Members, We are currently conducting a comprehensive transceiver channel test on our Arria 10 GX FPGA (part number: 10AX066K4F35M3SG and 10AX066K1F35I1SG). Our test setup and configuration parameters are as follows: Transceiver Configuration Rule: Basic (Enhanced PCS) PMA Configuration Rule: Basic Transceiver Mode: TX/RX Duplex Data Rate: 10 Gbps CDR Reference Clock Freq : 200MHz Number of CDR Reference clocks : 1 Selected CDR reference clock : 0 Test Pattern: External PRBS31 Measurement Tool: Transceiver Toolkit (Quartus Prime 20.2) Test Setup Description: Our system consists of a carrier board, an FPGA board, and a passive loopback connector. The carrier board contains no active components. The FPGA board is populated with various discrete interface components—including SDRAM, SRAM, FLASH, power sequencers, oscillators, clock buffers, and clock generators—to provide all necessary interfaces for the FPGA. The TX channels generated on the FPGA board are routed down to the carrier board, where they are looped back via the loopback connector and returned to separate RX channels on the FPGA. It should be noted that the TX and RX pairs are mostly located in different banks. The trace lengths of each channel along the loopback path vary between 8 inches and 11 inches. Reference Clock Architecture: We generate a 50 MHz signal using an on-board oscillator, pass it through a low-jitter clock buffer, and then feed the buffered output into a clock generator to produce the transceiver reference clocks. For the user clock, we apply a separate 100 MHz oscillator output directly to the Clkuser pin. Observed Behavior: During our test campaigns, we have achieved BER results on the order of 1e‑18 across many of the 36 looped‑back transceivers. In an effort to further minimize errors, we have selected pre‑emphasis, CTLE, and DFE settings within the Transceiver Toolkit that yield a zero‑error condition (i.e., no observed errors). Critical Issue: We are facing a significant inconsistency. When we test the 36 transceiver channels in four separate runs (9 channels per run), with VGA, EQ Control, and DFE parameters already set, we observe no errors for each channel during temperature cycling from 60 °C to 90°C (die temperature) and back down to 60 °C. Under these conditions, the BER remains zero. However, when we increase the number of channels with DFE adaptation enabled to the range of 12 to 15, we begin to observe errors on channels that previously exhibited no errors. Questions: What could be causing this degradation when the number of DFE‑adapted channels is increased? Are we exceeding some power, thermal, or resource limitation? Could there be an interaction between DFE‑enabled channels in adjacent banks or through the shared clocking/power distribution networks? Could this issue be attributed to silicon-level crosstalk between the DFE-adapted channels? More specifically, is it possible that enabling a larger number of DFE-adapted transceivers introduces additional noise coupling or interference within the FPGA silicon, potentially degrading the signal integrity of adjacent or nearby channels? If so, what would be the recommended approach to isolate or mitigate such effects in our current design and test environment? Additionally, we would like to ask: is there a known limitation on the number of transceivers that can reliably support a 10 Gbps data rate simultaneously across a wide temperature range ? Any guidance on debugging or resolving this issue would be greatly appreciated. Thank you in advance for your support. Regards, Onur
Arria 10 Transceiver rx_cal_busy always HIGH for 24s after programming
Troubleshooting 10G link native, the external TX is always ON. USRCLK 100MHz always ON. Every time the FPGA is loaded through JTAG or cold boot, there is a 24sec something wait until rx_clk_busy goes to LOW then the link starts functioning normal. According to Google AI, transceiver calibration module seems got stuck, and unfrozen by hardware watchdog to prevent brick. We has a different product that establishes link almost immediately with the same transmitter. Please suggest, thanksFPGA programming before XCVR's ref clock is ready
Hi, I use F-Tile Agilex 7 and Q24.2. On power cycle (P.C) my reference transceivers clock is not ready and stable, so I do the following reset sequence to the System PLL (created for no stable XCVR's ref clock, attached): When P.C, setting the refclock_ready, en_refclk_fgt_0, en_refclk_fgt_1 to 3'd0, 1'b0, 1'b0, respectively. Stabling the transceiver's input reference clock (loading its config parameters) Setting refclock_ready, en_refclk_fgt_0, en_refclk_fgt_1 to 3'd1, 1'b1, 1'b1, respectively. Then, waiting until refclock_status, refclk_fgt_enabled_0/1 and sys_pll_locked are asserted to 1'b1 Sometimes (not often), one of the statuses on section 4 are not asserted HIGH, and thus I need to do the reset sequence again and since it fails again and again I need to do P.C again. Is there a problem with my reset sequence? Is there a way not to P.C the FPGA and fixing this online? Should I synchronize between the assertion of refclock_ready, en_refclk_fgt_0 and en_refclk_fgt_1? Thanks a lot, ArikAgilex‑7 F‑Tile Dynamic Reconfiguration Conflict Between HDMI and SDI RX
Hello, I am working on a design targeting an Agilex‑7 device (AGFB014R24C2I2V) using Quartus Prime Pro 23.2. The design includes two video RX interfaces on the same F‑Tile, both configured as input-only: HDMI (TMDS only) SDI‑12G Both IP cores use dynamic reconfiguration to adapt the transceiver to the detected input frequency: HDMI: Mixed single-rate PHY (63 profiles) SDI: Multi-rate PHY (4 profiles) Since both IPs are located in the same F‑Tile, they share: A single dynamic reconfiguration block (through the arbiter from the provided IP example) The same System PLL Observed Behavior When only one RX IP is instantiated (either HDMI or SDI), the link comes up correctly and video is received as expected. When both RX IPs are instantiated simultaneously: HDMI link initializes and operates correctly. SDI PHY fails to lock to the input signal. Debug Observations Using SignalTap on the dynamic reconfiguration interface: The SDI reconfiguration state machine cycles through all profiles. Each reconfiguration completes successfully (no errors reported). Despite this, the SDI RX never achieves lock. Suspected Cause This appears to be potentially related to a resource conflict or incorrect sharing configuration within the F‑Tile, possibly due to QSF assignments or transceiver resource allocation. However, the exact root cause is unclear, and I may be overlooking a configuration requirement for: Shared dynamic reconfiguration usage Multi‑client arbitration F‑Tile resource partitioning Additional Information Below are the QSF assignments used to configure the dynamic reconfiguration IP. For brevity, only the first and last HDMI profiles (out of 63) are included. # Configure global assignments for SytemPLL set_location_assignment PIN_BH8 -to REFCLKIN_HDMI_13A -comment "Pin Function Name is REFCLK_FGTR13A_Q0_RX_CH0P" set_location_assignment PIN_BJ7 -to "REFCLKIN_HDMI_13A(n)" set_instance_assignment -name IO_STANDARD "CURRENT MODE LOGIC (CML)" -to REFCLKIN_HDMI_13A -entity iWave_HelloWorld set_location_assignment PIN_BP8 -to REFCLKIN_100M_13A -comment "Pin Function Name is REFCLK_FGTR13A_Q1_RX_CH3P" set_location_assignment PIN_BN7 -to "REFCLKIN_100M_13A(n)" set_instance_assignment -name IO_STANDARD "CURRENT MODE LOGIC (CML)" -to REFCLKIN_100M_13A -entity iWave_HelloWorld set_location_assignment PIN_CJ7 -to REFCLKIN_148M5_13A -comment "Pin Function Name is REFCLK_FGTR13A_Q3_RX_CH6P" set_location_assignment PIN_CH8 -to "REFCLKIN_148M5_13A(n)" set_instance_assignment -name IO_STANDARD "CURRENT MODE LOGIC (CML)" -to REFCLKIN_148M5_13A -entity iWave_HelloWorld set_instance_assignment -name IP_TILE_ASSIGNMENT Z1577B_X339_Y0_N0 -to U_VideoIn|U_MGT_SUPPORT.U_PLL|systemclk_f_0 -entity iWave_HelloWorld set_instance_assignment -name IP_BB_LOCATION FGT_REFCLK_0 -to U_VideoIn|U_MGT_SUPPORT.U_PLL|systemclk_f_0|x_hip|gen_refclk_fgt_bb_[0].enabled.inst -entity iWave_HelloWorld -comment "Device Location is x_z1577b|ux_refclk|ux_refclk0" set_instance_assignment -name IP_BB_LOCATION FGT_REFCLK_3 -to U_VideoIn|U_MGT_SUPPORT.U_PLL|systemclk_f_0|x_hip|gen_refclk_fgt_bb_[3].enabled.inst -entity iWave_HelloWorld -comment "Device Location is x_z1577b|ux_refclk|ux_refclk3" set_instance_assignment -name IP_BB_LOCATION FGT_REFCLK_6 -to U_VideoIn|U_MGT_SUPPORT.U_PLL|systemclk_f_0|x_hip|gen_refclk_fgt_bb_[6].enabled.inst -entity iWave_HelloWorld -comment "Device Location is x_z1577b|ux_refclk|ux_refclk6" # Configure global assignments for dynamic reconfig set_instance_assignment -name IP_TILE_ASSIGNMENT Z1577B_X339_Y0_N0 -to U_VideoIn|U_MGT_SUPPORT.U_Reconfig|dr_f_0 -entity iWave_HelloWorld set_global_assignment -name IP_RECONFIG_GROUP_TYPE "MASTER_DR:INCLUSIVE" -entity iWave_HelloWorld # HDMI DR set_global_assignment -name IP_RECONFIG_GROUP_PARENT "MASTER_DR:VIDEOINPUT0_DR" -entity iWave_HelloWorld set_global_assignment -name IP_RECONFIG_GROUP_TYPE "VIDEOINPUT0_DR:EXCLUSIVE:SHARED_SIP:CLK_MASTER" -entity iWave_HelloWorld set_instance_assignment -name IP_RECONFIG_GROUP_MASTER_CLOCK_CHANNEL PLD_PCS_RX_CLK_OUT1_DCM -to U_VideoIn|U_INPUT_0|U_HDMI_TMDS.U1|U_HDMI|gxb_rx_inst|u_rx_phy_0|rx_phy_12g|dphy_hip_inst|persystem[0].perxcvr[0].peraib[0].rx_aib.x_bb_m_hdpldadapt_rx -entity iWave_HelloWorld set_instance_assignment -name IP_RECONFIG_GROUP_STARTUP_INSTANCE ON -to U_VideoIn|U_INPUT_0|U_HDMI_TMDS.U1|U_HDMI|gxb_rx_inst|u_rx_phy_0|rx_phy_12g set_instance_assignment -name IP_RECONFIG_GROUP_SHARED_SIP ON -to U_VideoIn|U_INPUT_0|U_HDMI_TMDS.U1|U_HDMI|gxb_rx_inst|u_rx_phy_0|rx_phy_12g set_instance_assignment -name IP_RECONFIG_GROUP VIDEOINPUT0_DR -to U_VideoIn|U_INPUT_0|U_HDMI_TMDS.U1|U_HDMI|gxb_rx_inst|u_rx_phy_0|rx_phy_12g -entity iWave_HelloWorld ... set_instance_assignment -name IP_RECONFIG_GROUP VIDEOINPUT0_DR -to U_VideoIn|U_INPUT_0|U_HDMI_TMDS.U1|U_HDMI|gxb_rx_inst|u_rx_phy_62|rx_phy_0p300g -entity iWave_HelloWorld set_instance_assignment -name IP_COLOCATE F_TILE -from U_VideoIn|U_MGT_SUPPORT.U_Reconfig|dr_f_0 -to U_VideoIn|U_INPUT_1|U_HDMI_TMDS.U1|U_HDMI|gxb_rx_inst|u_rx_phy_0|rx_phy_12g -entity iWave_HelloWorld ... set_instance_assignment -name IP_COLOCATE F_TILE -from U_VideoIn|U_MGT_SUPPORT.U_Reconfig|dr_f_0 -to U_VideoIn|U_INPUT_1|U_HDMI_TMDS.U1|U_HDMI|gxb_rx_inst|u_rx_phy_62|rx_phy_0p300g -entity iWave_HelloWorld set_instance_assignment -name IP_RECONFIG_ID 101 -to U_VideoIn|U_INPUT_1|U_HDMI_TMDS.U1|U_HDMI|gxb_rx_inst|u_rx_phy_0|rx_phy_12g -entity iWave_HelloWorld ... set_instance_assignment -name IP_RECONFIG_ID 163 -to U_VideoIn|U_INPUT_1|U_HDMI_TMDS.U1|U_HDMI|gxb_rx_inst|u_rx_phy_62|rx_phy_0p300g -entity iWave_HelloWorld # SDI DR set_global_assignment -name IP_RECONFIG_GROUP_PARENT "MASTER_DR:VIDEOINPUT1_DR" -entity iWave_HelloWorld set_global_assignment -name IP_RECONFIG_GROUP_TYPE "VIDEOINPUT1_DR:EXCLUSIVE:CLK_MASTER" -entity iWave_HelloWorld set_global_assignment -name IP_RECONFIG_GROUP_PARENT "VIDEOINPUT1_DR:U_VideoIn|U_INPUT_1|U_SDI.U3|U_SDI|sdi_mr_rx_sys_inst|rx_phy|rx_phy/RG_A_E" -entity iWave_HelloWorld set_instance_assignment -name IP_COLOCATE F_TILE -from U_VideoIn|U_MGT_SUPPORT.U_Reconfig|dr_f_0 -to U_VideoIn|U_INPUT_1|U_SDI.U3|U_SDI|sdi_mr_rx_sys_inst|rx_phy|rx_phy -entity iWave_HelloWorld set_instance_assignment -name IP_RECONFIG_ID 164 -to U_VideoIn|U_INPUT_1|U_SDI.U3|U_SDI|sdi_mr_rx_sys_inst|rx_phy|rx_phy set_instance_assignment -name IP_RECONFIG_GROUP_MASTER_CLOCK_CHANNEL PLD_PCS_RX_CLK_OUT1_DCM -to U_VideoIn|U_INPUT_1|U_SDI.U3|U_SDI|sdi_mr_rx_sys_inst|rx_phy|rx_phy|U_base_profile|directphy_f_0|dphy_hip_inst|persystem[0].perxcvr[0].peraib[0].rx_aib.x_bb_m_hdpldadapt_rx -entity iWave_HelloWorld Generated Reconfiguration IDs After support logic generation, the IDs are correctly reflected: #define NUM_IP_INSTS 67 #define IWAVE_HELLOWORLD__U_VIDEOIN__U_INPUT_0__U_HDMI_TMDS__U1__U_HDMI__GXB_RX_INST__U_RX_PHY_0__RX_PHY_12G 101 ... #define IWAVE_HELLOWORLD__U_VIDEOIN__U_INPUT_0__U_HDMI_TMDS__U1__U_HDMI__GXB_RX_INST__U_RX_PHY_62__RX_PHY_0P300G 163 #define IWAVE_HELLOWORLD__U_VIDEOIN__U_INPUT_1__U_SDI__U3__U_SDI__SDI_MR_RX_SYS_INST__RX_PHY__RX_PHY__U_BASE_PROFILE__DIRECTPHY_F_0 164 #define IWAVE_HELLOWORLD__U_VIDEOIN__U_INPUT_1__U_SDI__U3__U_SDI__SDI_MR_RX_SYS_INST__RX_PHY__RX_PHY__U_SEC_PROFILE1__SEC_PROFILE_1 165 #define IWAVE_HELLOWORLD__U_VIDEOIN__U_INPUT_1__U_SDI__U3__U_SDI__SDI_MR_RX_SYS_INST__RX_PHY__RX_PHY__U_SEC_PROFILE2__SEC_PROFILE_2 166 #define IWAVE_HELLOWORLD__U_VIDEOIN__U_INPUT_1__U_SDI__U3__U_SDI__SDI_MR_RX_SYS_INST__RX_PHY__RX_PHY__U_SEC_PROFILE3__SEC_PROFILE_3 167 Any guidance on: Proper sharing of dynamic reconfiguration between multiple RX IPs on the same F‑Tile Known limitations or requirements for mixing HDMI (TMDS) and SDI PHYs QSF settings that could cause this behavior would be greatly appreciated. Thank you.
Stratix 10 fPLL is cascade source mode doesn't lock
Hello everyone. I use fPLL cascading with Stratix 10 FPGA: fPLL in cascade source mode is connected to fPLL in transceiver mode. In my design reference clock for fPLL in cascade source mode is not stable after power-up and I apply user recalibration to it. But after user recalibration when reference clock is stable, fPLL doesn't set lock signal. After some investigation of the issue, I found that my design works fine with Quartus Pro 21.2 but doesn't work with newer versions like Quartus Pro 23.4/25.1/26.1. Is there any known issue about fPLL is cascade source mode? Any suggestions about how to overcome this issue are welcomed.JESD204B Multi-Link Implementation with AD9695 ADCs Having Different Lane Counts (L=4 and L=2)
Hello Intel Community, I am currently working on a multi-chip ADC design using the AD9695 with the JESD204B interface on an Intel Stratix 10 FPGA. I am using the JESD204B Intel FPGA IP core and have been referring to the example design provided with the IP. I have also followed the guidelines mentioned in Intel Application Note AN 804: Implementing Analog-to-Digital Converter Multi-Link Designs with Intel Stratix 10 JESD204B RX IP Core. In my design, I have three ADC chips with the following configuration: ADC 1: 4 lanes (L=4) ADC 2: 4 lanes (L=4) ADC 3: 2 lanes (L=2) All other JESD204B parameters (such as F, M, S, N, N') are identical across all three ADCs. According to AN 804, it is mentioned that when adding multiple subsequent links within a single JESD204B IP core, all links must share the same set of JESD parameters, including the number of lanes (L). Since my third ADC has a different lane count, I am unsure about the correct implementation approach. I would appreciate your guidance on the following: Can I integrate all three ADCs into a single JESD204B IP core instance by configuring it as a multi-link design, even though the lane counts differ? If not, should I instantiate three separate JESD204B IP cores, each configured as a single link (L=4, L=4, L=2 respectively)? Alternatively, should I instantiate two IP cores — one for the first two ADCs (with L=4, using the multi-link feature) and a second core for the third ADC (with L=2)? Could you please suggest the correct and most efficient path forward? Also, if I use separate IP cores, what are the key considerations for ensuring proper synchronization (Subclass 1) and reliable operation across all three links? Any insights, reference designs, or best practices would be greatly appreciated. Thank you in advance for your support. Best regards, BALAMURuGAN V
Cyclone 10 GX Transceiver Power-Up Calibration Time (~353 ms) Analysis Request
We are observing a transceiver power-up calibration time of approximately 353 ms on a Cyclone 10 GX device (10CX220YF780I6G) using all 12 transceivers. The total system startup requirement is 250 ms (configuration + calibration + system boot constraints), and the calibration phase alone is currently a limiting factor. According to the Cyclone 10 GX Transceiver PHY User Guide, calibration is performed automatically during device configuration via the PreSICE engine and is dependent on reference clock stability, PLL lock conditions, and reset controller sequencing. The documentation does not specify a deterministic calibration duration. Please can you provide clarification on the following points: Is a ~353 ms calibration time expected behavior for a design using all 12 transceivers on this device family? Is transceiver calibration executed sequentially across multiple quads, or is full parallel calibration supported for all active transceiver banks in Cyclone 10 GX? Are there any recommended design practices (reset controller configuration, PLL topology, clocking architecture) that can reduce power-up calibration latency? Can calibration duration be significantly impacted by reference clock stabilization time or internal wait states prior to PreSICE execution? The goal is to determine whether the observed latency is inherent to the device architecture or if it can be optimized at system level.
Teransceiver & FPGA
Hello, We would like to transmit digital logic signals between multiple FPGA boards over optical fiber. Is it possible to use the FPGA transceivers with SFP or SFP+ modules for this type of application? In addition, would it be feasible to transmit these signals across multiple FPGA boards in a daisy-chain configuration, where each FPGA receives the data and then forwards it to the next FPGA through its transceivers? If so: Which FPGA families or devices would you recommend for this type of architecture? Which communication protocol would you recommend? Is it possible to implement our own custom protocol, or would you advise using a standard protocol instead? Thank you in advance for your feedback. Best regards,
