Forum Discussion
New ContributorStratix 10 fPLL is cascade source mode doesn't lock
New ContributorHello.
Let's concentrate on test project that I can share. It can reproduce the issue that I am talking about.
I changed the project (see the one attached to the message). Now it can reconfigure transceiver fPLL (xcvr_tr_fpll) and it use either reference fixed clock or clock from cascade source fPLL (xcvr_cs_fpll).
After power-up, XCVRs and xcvr_tr_fpll are calibrated using fixed reference clock (100MHz). xcvr_cs_fpll is calibrated using clock from RX XCVR but it is not stable, so lock signal is not stable too.
The steps to reconfigure using clock from xcvr_cs_fpll:
- Set lock to ref. for RX XCVR.
- Assertiong of reset to TX XCVR.
- Recalibration of xcvr_cs_fpll
- Reconfiguration of xcvr_tr_fpll (setting pre-reconfig bit, changing reference clock muxer, changing dividers, etc.)
- Recalibration of xcvr_tr_fpll.
- Deassertiong of reset to TX XCVR
If project was compiled with Quartus Pro 21.2, after step 6, lock signals of fPLLs are stable, clock that comes from TX XCVR is equal to expected value (156.25MHz)
If project was compiled with Quartus Pro 23.4 or 25.3 there are no lock on fPLLs outputs and as a consequence no stable clock from TX XCVR.
So, the result depends on Quartus version.
cs_fpll_controller.sv recalibrates xcvr_cs_fpll.
tr_fpll_controller.sv reconfigures and recalibrates xcvr_tr_fpll (the registers used for reconfiguration can be found as localparams).
Regular ContributorHi,
I am not aware of the way to check the netlist. That will require a configuration expert.
However, I reviewed the current TR FPLL reconfiguration flow against the IP-guided procedure in the user guide. The current design is only partially aligned with the documented sequence.
- Step 1, wait for PLL calibration to be idle, is mostly implemented correctly by checking pll_cal_busy before starting.
- Step 2, disable background calibration, appears to be missing. I do not see any explicit write to the background-calibration control registers such as the 0x540 / 0x542 family in the current design.
- Step 3, request reconfiguration bus ownership, is implemented correctly with 0x000 = 0x02.
- Step 4, program the selected profile, is not fully implemented. The controller currently writes only a small hand-coded subset of registers in tr_fpll_controller.sv, while the generated IP profile contains 49 register writes.
- Step 5, return bus ownership, is implemented correctly with 0x000 = 0x01.
- Step 6, wait for calibration completion, is partially implemented. The design waits on pll_cal_busy, but only with simple edge-based logic and no timeout or final lock confirmation.
The main file to change is tr_fpll_controller.sv. If you want the background-calibration disable step implemented at the PHY/IP level, then xcvr_phy.ip and regenerated PHY collateral may also need attention. If the IP configuration itself changes, xcvr_tr_fpll.ip should be regenerated rather than hand-edited.
Recommended fix:
- Replace the hand-written 5-register sequence in tr_fpll_controller.sv with the full generated IP profile sequence.
- Add the missing background-calibration disable step before reconfiguration.
- Keep pll_cal_busy for completion monitoring, but add a timeout/error path.
- Optionally check pll_locked after calibration completes.
Regards,
Altera Tech Support
dncmrc1Occasional Contributor
Hi Ash,
> Replace the hand-written 5-register sequence in tr_fpll_controller.sv with the full generated IP profile sequence.
We use the reconfiguration report files from IP generation to find the register differences between reconfiguration profiles. The few registers which are changing between profiles are the ones used in tr_fpll_controller.sv. This is a well established, old practice used by Altera as well.
> Add the missing background-calibration disable step before reconfiguration.
Background calibration is a transceiver feature not fPLL and it is used only for rates more than 17Gbps. In test project background calibration is not used because rate is 10Gbps.
> Keep pll_cal_busy for completion monitoring, but add a timeout/error path. Optionally check pll_locked after calibration completes.
In the test project we manually launch recalibration/reconfiguration and check pll_locked status using Signaltap. I do not think that we need to add some logic to check it automatically at this stage. We will certainly add it in the final design.
Overall, in test project we have fPLL cascade connection. cs_fpll (cascade source fpll) and tr_fpll (transceiver fpll). I would shift the focus to cs_fpll, because if cs_fpll does not assert lock, it is clear why tr_fpll does not have lock too.
Regards,
Marco
