User Profile
JonWay_altera
Frequent ContributorJoined 8 years ago
User Widgets
Contributions
Re: Inconsistent Eyes with S10 E-tile Transceiver.
Channel: External Loopback (Tx+ to Rx+ Rx- via single ended to differential converter, Tx- terminated with 50 Ohms) Your setup is not a true differential channel: Tx+ carries the signal Tx− is terminated with 50 Ω A single-ended-to-differential converter reconstructs the differential signal received by Rx+/Rx− This can introduce several impairments that do not exist in a normal differential link.28Views0likes0CommentsRe: Agilex5 o_tx_ready and o_rx_ready not asserting
Because both TX and RX ready remain low, I would first suspect a shared clock/reset prerequisite—i_system_pll_lock, i_refclk_ready, o_pll_lock, or missing/incorrect core clocks—rather than the IEEE_FLEXE_66 payload interface. Probe these signaltap (with power up trigger). Set to Transitional. i_refclk_ready o_pll_lock i_system_pll_lock i_tx_coreclkin o_tx_clkout (you cannot tap on clk signals. Instead use it to drive some counters, then tap on the counter to check for toggling activity) o_tx_pll_locked o_tx_reset_ack i_tx_reset i_src_rs_req o_src_rs_grant i_src_rs_grant o_tx_ready21Views0likes1CommentRe: Unable to Generate Valid PAM4 Eye Diagram and BER Measurements on Stratix 10 SI E-Tile Native PHY
TTK in Quartus 18.1 Eye Viewer is really old and the newer Quartus would resolved most of the problem. I would advise to use the latest Quartus. The E-Tile PAM4 link must use true differential TX+/TX− and RX+/RX− signaling; terminating RX− with 50 Ω and applying only 20 mVpp to RX+ is not sufficient for reliable 51-Gbps reception. A locked PLL/CDR does not guarantee valid PAM4 eye separation, so use direct differential SMA loopback first, PRBS13Q/PRBS31Q, initial adaptation with valid traffic, and disable continuous adaptation before BER/Eye Viewer. A full-red heatmap and undefined eye dimensions usually indicate invalid/weak differential data, incorrect mapping/equalization, or a Toolkit issue—not simply insufficient captured bits.24Views0likes0CommentsRe: Guidance on Enabling USB Mode in F-Tile PMA Direct PHY IP – Quartus Prime 26.1
In Quartus Prime Pro 26.1, USB is no longer a supported selectable value for FGT PMA Configuration Rules in the F-Tile PMA Direct PHY IP. The current supported values are Basic, OTN, CPRI, GPON, SDI, SONET, HDMI, SATA/SAS, PCIe, and PCIe_Phase2; USB is not listed. There is no documented Tcl command or QSF assignment that restores the former USB configuration. The USB-specific ports and simplified TX interface were generated by the old USB protocol rule; they cannot be reliably recreated by manually setting ordinary PMA parameters.29Views0likes0CommentsRe: about cyclone 10gx transceiver
Before using block synchronization, your original approach relied on sending a custom training word like 0x12345678 together with tx_control flags and then manually bit-slipping until the receiver matched that pattern. This method can work only if the word boundary remains stable after alignment, which is not true in your current configuration because the RX phase‑compensation FIFO can shift the data grouping internally. As a result, even if you successfully match 0x12345678 at one moment, the FIFO may later realign the data by bytes, breaking your alignment silently and causing rx_control to appear to rotate or change unpredictably. Moreover, 0x12345678 is not a strongly structured or repetitive pattern, so the receiver has no inherent way to verify long-term consistency of the alignment. Without block synchronization or a robust detection mechanism, this leads to a fragile system where alignment appears to work briefly but cannot be maintained. Suggestion: Enable the RX block synchronizer, and transmit a simple, highly repetitive training pattern such as 0xBCBCBCBC with tx_control held at zero (so all bytes are treated as normal data), allowing the receiver to observe a stable, structured bitstream; the RX block synchronizer continuously scans different bit offsets and monitors for consistent block delineation, and once it detects a stable boundary it asserts rx_enh_blk_lock, indicating that word alignment is achieved; only after this lock signal becomes stable should the transmitter switch from the training pattern to real payload data (for example, a counter), while the receiver begins accepting data, and during normal operation the design should continue to monitor rx_enh_blk_lock and revert to the training phase if lock is lost, ensuring robust and self-correcting alignment without relying on manual bitslip or tx_control markers. At minimum, capture these signals on the RX side: rx_parallel_data[31:0] → verify actual data pattern / counter rx_control[19:0] → observe byte control movement (debug only) rx_enh_blk_lock → MUST go high to indicate alignment achieved rx_enh_data_valid → ensures data coming from FIFO is valid rx_bitslip → confirm no unintended slipping (should stay low when using block sync) rx_is_lockedtodata → confirms CDR has locked to incoming data rx_ready → indicates RX path is initialized and stable What to look for in SignalTap: During training: rx_parallel_data → becomes steady repeating BCBCBCBC rx_enh_blk_lock → transitions from 0 → 1 After lock: rx_enh_blk_lock = 1 (stable) rx_parallel_data follows transmitted data correctly rx_control remains stable (no rotation) If failure occurs: rx_enh_blk_lock drops to 0 rx_parallel_data becomes inconsistent rx_control starts rotating again Suggest that if you see correct data but rx_enh_blk_lock = 0, you are NOT aligned yet, even if it “looks right” for a few cycles. A little lengthy but hope it helps. :)11Views0likes0CommentsRe: Question about VGA parameter in Transceiver Toolkit (Quartus Std 23.1)
In some contexts and device families, “VGA” (Variable Gain Amplifier) is used more generically to describe an analog gain stage, which can overlap with what is referred to as DC gain at the register level. Because the scripting API exposes a parameter named dcgain, and there is no visible VGA control in the API, it is a reasonable (but incorrect) inference that both refer to the same control. However, as clearly shown in your Transceiver Toolkit screenshot: VGA and DC gain are separate parameters They can be set independently in the GUI They do not map to each other I have checked the transceiver toolkit command documentation: https://docs.altera.com/r/docs/683552/18.1/intel-quartus-prime-standard-edition-user-guide-debug-tools/transceiver-toolkit-commands There is no documented API for VGA, and it is not mapped to any exposed scripting parameter35Views1like0Comments