User Profile
Ash_R_Altera
Regular ContributorJoined 5 years ago
User Widgets
Contributions
Re: Stratix 10 fPLL is cascade source mode doesn't lock
Hi, 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 Support6Views0likes2CommentsRe: The DC_FIFO issue of Cyclone 10 GX devices
Hi, May I know which Quartus version is being used? Please share a smaller version of your design to replicate the issue on our side. Simulatable design is preferred. Parallely on your side, I would like to see the DC_FIFO ports in the signal tap. Please add as many signals at the FIFO level, including 'aclr' to the signal tap and send us a screen shot. Additionally add XCVR rx_ready signal as well. I didn't quite understood what you mean by "we don't open 'aclr' port". Do you mean you never assert and de-assert the 'aclr' port? Please clarify. Regards, Altera Tech Support40Views0likes3CommentsRe: The DC_FIFO issue of Cyclone 10 GX devices
Hi Minzhi, Thank you for providing the detailed description and waveforms. I assume that the FIFO is configured to Normal mode. This behavior typically occurs due to transceiver clock instability during power-up/reset or premature read requests before pointer synchronization is complete. Probable root cause & recommendations: 1. Transceiver Clock Stability & Reset Sequencing (`rx_ready`): - At power-up/reconfiguration, the transceiver CDR and PLL calibrate, during which `rx_clkout` can experience glitches or unstable frequencies before locking. - Ensure the DCFIFO `aclr` (asynchronous reset) is held asserted until the Transceiver PHY Reset Controller asserts `rx_ready` (and both `wrclk` and `rdclk` are stable). - After `aclr` is deasserted, wait at least 3 to 5 clock cycles before asserting `wrreq`. 2. Read Request (`rdreq`) Gating: - Do not tie `rdreq` permanently high (`1'b1`). Asserting `rdreq` while `rdempty` is high causes FIFO underflow: - In Normal Mode: Reading while empty results in invalid/zero data. - Always qualify your read logic: only assert `rdreq` when `rdempty == 1'b0`. 3. Is it possible to bring the DC_FIFO signals 'aclr' and 'wrclk' also in the signal tap? For more details on reset sequencing and timing requirements, please refer to the FIFO Intel FPGA IP User Guide on Altera.com. Best regards, Altera Applications Support11Views0likes5CommentsRe: Tranceiver Enhanced PCS Basic mode questions
Hi MinzhiWang, 1) There is a Word Aligner block in Cyclone 10 GX, instead of Byte Ordering. Refer Table 29 in https://docs.altera.com/r/docs/683054/20.1/cyclone-10-gx-transceiver-phy-user-guide/standard-pcs-parameters. 2) Typically both Tx and Rx and connected to other side Rx and Tx respectively. Then, you send a know response. Else, use general purpose IOs to communicate the Rx readiness. This will be your own custom logic. Hoep this clarifies. Regards, Altera Tech Support97Views0likes0CommentsRe: Tranceiver Enhanced PCS Basic mode questions
Hi Minzhi, For Cyclone 10 GX Enhanced PCS Basic mode, word alignment is typically achieved using the RX Synchronizer (word aligner) or the RX bitslip interface. A common approach is to transmit a known training/alignment pattern from the remote TX and allow the local RX to search for that pattern and adjust the word boundary until it is detected correctly. This is generally how serial links establish alignment before normal payload traffic begins. Regarding the initialization sequence, a typical flow is: Wait for TX/RX PLL lock and RX ready/calibration completion. Remote TX continuously sends a known alignment pattern. Local RX uses the RX Synchronizer or RX bitslip to achieve word alignment. Once the alignment pattern is detected consistently, switch to normal data transmission. Since your design uses a custom point-to-point link without a standard protocol, defining a unique training pattern during link bring-up is the recommended method for reliable synchronization and word-boundary alignment. The TX normally has no visibility into the RX word-alignment status. A common approach is for the TX to continuously transmit a known training pattern after link initialization, while the RX performs word alignment using the RX Synchronizer or RX bitslip. Once the RX reliably detects the training pattern, it can either: Signal alignment completion through a separate sideband/control channel, or Begin transmitting a known response pattern back to the far-end TX. After the TX receives the expected indication, both sides can transition to normal payload traffic. Regards, Altera Tech Support7Views0likes2CommentsRe: HSIO Differential Clock Output VOD and VOCM
Hi, For the FPGA receiver, the key parameters are VID and VICM. From the schematic, the 10 kΩ/30 kΩ divider biases both inputs to approximately 0.75 × VIO_BANK0 (≈0.9 V for a 1.2 V bank), which falls within the documented True Differential Signaling receiver common-mode range. Therefore, the bias network itself appears compatible with the Agilex 5 HSIO receiver requirements. The remaining check is that the incoming differential clock meets the specified VID range and uses the recommended differential termination. Regards, Altera Tech Support74Views0likes0CommentsRe: HSIO Differential Clock Output VOD and VOCM
Hi Jaykrishna, Thank you for the detailed question. Based on the Agilex 5 Device Data Sheet, the HSIO True Differential Signaling transmitter is only characterized and supported with VCCIO_PIO = 1.3 V. The datasheet table for HSIO Differential I/O Standards Specifications provides the following transmitter specifications for True Differential Signaling 1.3-V (LVDS-compatible) Tx/Rx: [docs.altera.com] VOD: 247 mV (min) to 454 mV (max) VOCM: 0.9 V (min), 1.0 V (typ), 1.1 V (max) Specifications assume a differential termination of approximately 100 Ω. [docs.altera.com] For 1.2 V HSIO banks, the datasheet only lists receiver support for the True Differential Signaling standard and does not provide transmitter VOD/VOCM specifications. Therefore, we cannot claim the same VOD/VOCM values for a differential output operating from a 1.2-V HSIO bank. [docs.altera.com] Looking at the schematic provided, the resistor network (10 kΩ pull-up and 30 kΩ pull-down on each leg) biases the differential pair to approximately 0.75 × VIO_BANK0. For example: If VIO_BANK0 = 1.3 V, the bias point is approximately 0.975 V, which is very close to the typical 1.0 V VOCM specified for the 1.3-V True Differential Signaling transmitter. However, this external bias network does not change the fact that the FPGA output driver characteristics (VOD, VOCM, output swing, etc.) are only characterized for the supported transmitter standard. Therefore, compatibility with the external PLL input should be verified against the FPGA's supported I/O standard and bank voltage configuration. For driving an external differential PLL reference clock, our recommendation is: Use a supported True Differential Signaling (LVDS-compatible) transmitter in a 1.3-V HSIO bank when VOD/VOCM compliance is required. Use a 100-Ω differential termination at the receiver as recommended by the differential signaling specification. AC-coupling or DC-coupling should follow the PLL vendor's input requirements; the Agilex 5 datasheet does not specify a unique coupling requirement for differential clock outputs. [docs.altera.com] At present, we are not aware of any additional restriction preventing the use of a supported HSIO differential output as an external PLL reference clock source, provided that the receiving device's common-mode and differential input requirements are met. Regards, Altera Tech Support8Views0likes2CommentsRe: Tranceiver Enhanced PCS Basic mode questions
Hi MinzhiWang, Thank you for the update. Switching to Standard PCS with 8b/10b encoding is the correct approach for your point-to-point application on Cyclone 10 GX — it gives you explicit access to the tx_datak/rx_datak ports, which function the same way as the tx_control/rx_control signals you used on Arria GX and Stratix IV GX. This is a well-supported path for custom, protocol-free transceiver links. Regarding the bit-shift patterns you saw with Enhanced PCS (0x55→0xAA, 0x33→0x66/0xCC, 0xFF00→0x01FE): These are consistent with a 1-bit boundary misalignment at the 64b/66b block level in the Enhanced PCS. Because the Enhanced PCS Basic mode does not send 64b/66b header bits in IEEE 802.3ae-compliant LSB-first order, the block synchronizer can lock to an incorrect bit offset, causing systematic bit shifts in the decoded data. This is a known behavior documented in the Knowledge Base article: Are the 64b/66b header bits compliant to the IEEE802.3ae standard when using Enhanced PCS with Basic Mode? Since you don't require a specific protocol and need per-byte control signaling, Standard PCS with 8b/10b is the cleaner solution — you have made the right decision. Regarding the byte mis-ordering issue in Standard PCS: When using Standard PCS with a parallel data width wider than 10 bits (e.g., 16-bit or 32-bit FPGA fabric interface), the byte ordering block is needed to ensure the correct byte position within the wider word. Here's what to check: Enable the Byte Ordering block in the Native PHY IP parameter editor. The byte ordering block uses a K28.5 (0xBC) comma character on a designated byte lane to establish the correct byte order. See: Byte Ordering — Cyclone 10 GX Transceiver PHY User Guide Transmit a K28.5 comma on byte lane 0 periodically (e.g., during idle or initialization) with tx_datak asserted for that byte. The receiver byte ordering block uses this pattern to determine which received byte corresponds to the LSByte of the wider word. Monitor rx_byteorderalignstatus — this signal asserts when the byte ordering block has successfully aligned the byte lanes. Only treat rx_parallel_data as valid after this signal is asserted. Verify the Word Aligner settings — ensure the word alignment pattern is set to K28.5 (the comma pattern) and that rx_syncstatus is asserted, indicating successful word alignment at the 10-bit boundary level. See: Word Aligner — Cyclone 10 GX Transceiver PHY User Guide Check Byte Serializer/Deserializer ordering — if you enabled the byte serializer (TX) and byte deserializer (RX) to widen the datapath, be aware that the byte serializer forwards LSByte first. Make sure the TX and RX byte serializer/deserializer configuration matches. See: Byte Serializer Byte Deserializer RX Byte Reversal — if you see a consistent MSByte/LSByte swap after addressing the above, you may toggle the "Enable RX byte reversal" option. This feature reverses the LSByte with the MSByte of the received data. See: Word Aligner RX Byte Reversal Feature Recommended initialization sequence: TX continuously sends K28.5 (0xBC) with tx_datak = 1 on all byte lanes Wait for RX rx_syncstatus = 1 (word alignment achieved) Wait for RX rx_byteorderalignstatus = 1 (byte ordering achieved) Begin sending user data with tx_datak = 0 The full Cyclone 10 GX Transceiver PHY User Guide is available here for additional reference: Cyclone 10 GX Transceiver PHY User Guide (683054) Please let us know if you need further assistance with the Standard PCS configuration. Best regards, Altera Technical Support0Views0likes4Comments