Cyclone 10 GX Transceiver Power-Up Calibration Time (~353 ms) Analysis Request

Hi,

Thank you for filing this case and sharing the details. I appreciate your patience. Please allow me some time to review the information, and I’ll get back to you as soon as possible. 

Hi,

From my understanding, you have a few questions related to transceiver (XCVR) power‑up calibration on the Cyclone® 10 GX device. To make sure we’re aligned, could you please share with me how you are measuring the calibration time in your setup (for example, which signals you are monitoring and from which point to which point the time is measured)?

Below are my responses to your questions:

1. Is a ~353 ms calibration time expected when using all 12 transceivers on this device family?

Based on available documentation, there is no specific, fixed calibration-time specification for Cyclone 10 GX devices. As stated in the Cyclone 10 GX Transceiver User Guide, calibration duration can vary by device.

Assuming:

• All clocks are stable & free-running prior device configuration, within specification, and
• All *_cal_busy signals deassert cleanly,

a ~353 ms calibration time would generally be considered expected behavior, rather than an anomaly.

2. Is transceiver calibration executed sequentially across multiple quads, or is full parallel calibration supported?

I do not have explicit visibility into whether calibration is fully parallel or strictly sequential across quads. However, based on general understanding, the calibration process appears to be a combination of parallel and sequential operations across different internal blocks.

As a result, designs using fewer channels (for example, 1 or 6 channels) would be expected to have shorter overall calibration times compared to designs using all 12 channels.

3. Are there recommended design practices to reduce power‑up calibration latency?

If you are currently using CLKUSR at 100 MHz, you may try increasing it to 125 MHz to see whether it helps reduce calibration time.

In addition, please ensure that:

• CLKUSR and all reference clocks are stable and free‑running before FPGA configuration begins

Please let me know if you have any follow-up questions. I’ll be happy to assist further.

Thank you.

Below an update on the questions

could you please share with me how you are measuring the calibration time in your setup (for example, which signals you are monitoring and from which point to which point the time is measured)?

We use an internal Signal Tap with a 1 kHz clock (1 ms per tick). The measurement is triggered immediately after FPGA configuration is completed (Power-Up Trigger)

We track: ATX pll_lock, ATX cal_busy and rx_cal_busy and tx_cal_busy for each transceiver channel

We would like to focus specifically on SGMII (GbE) now, which is why the latest communication only addresses this case.

a ~353 ms calibration time would generally be considered expected behavior, rather than an anomaly.

Out of curiosity, how is it possible to meet the ~100 ms PCIe enumeration requirement if these calibration times are expected (especially without even considering FPGA configuration time)?

If you are currently using CLKUSR at 100 MHz, you may try increasing it to 125 MHz to see whether it helps reduce calibration time.

    In addition, please ensure that: CLKUSR and all reference clocks are stable and free‑running before FPGA configuration begins

Sure we can try increasing CLKUSR from 100 MHz to 125 MHz, although based on our current measurements we do not expect a significant improvement.

We have ensured that CLKUSR and all reference clocks are stable and free-running before FPGA configuration begins. Additionally:

We tested triggering a reconfiguration after sufficient time has elapsed (ensuring full system stability), and observed similar timing results.

We also repeated the test using a Cyclone 10GX Evaluation Kit (validated Altera hardware), and obtained comparable results.

Thank you