JonWay_altera
Frequent ContributorJoined 7 years ago
User Profile
Frequent Contributor
User Widgets
Contributions
Re: 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. :)3Views0likes0CommentsRe: 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 parameter15Views1like0CommentsRe: Configurable transceiver enable
My understanding of "board‑level transceiver parameters are static at power‑up", implied they are compile‑time only. In practice, changing these parameters would require IP regeneration and a full FPGA recompilation, rather than being something that can be altered dynamically at runtime (i.e., they behave similarly to localparam settings). With that in mind, let me rephrase my understanding of a possible implementation approach: Only 2 channels would be active in normal operation. The remaining channels would be treated as unused channels Only 1 bitstream Based on the transceiver reset architecture described in the Cyclone 10 GX Transceiver PHY User Guide, you may want to consider this conceptual approach to instantiate a 4‑channel transceiver, and control which channel is active using the four independent reset ports per channel: tx_analogreset tx_digitalreset rx_analogreset rx_digitalreset For the unused channels, the handling would be: Assert TX analog reset Assert RX analog reset Keep TX and RX digital reset asserted as well This would prevent the unused channels from calibrating, transmitting, or receiving data, while keeping the configuration static and avoiding any runtime reconfiguration complexity.9Views1like2CommentsRe: IBIS models GTS banks agilex 5E
hi ohfpga1 We do not receive any response from you to the previous question/reply/answer that I have provided. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Altera experts.13Views0likes0CommentsRe: Configurable transceiver enable
How about compiling two separate bitstreams; it would be a clean solution since the board parameter is static at power‑up and there is no requirement to switch channel groups at runtime. Each bitstream instantiates only two transceiver channels, using the Raw (Native) PHY, all operating at the same line rate and reference clock. For each build, the fitter simply needs to be rerun with placement constrained to either channels 1–2 or channels 3–4.30Views0likes4CommentsRe: Configurable transceiver enable
Hi Julia, Could you send back the information for the following clarifying questions to make sure the problem is fully understood and to avoid proposing the wrong solution. Which Altera device family and part number are you using, and which transceiver type (e.g., FGT, FHT, GTS)? Is the board parameter static for the entire power‑up, or can it change dynamically after FPGA configuration? Do channels 1–2 and 3–4 operate at the same line rate and reference clock, or do they have different requirements? Are these channels used for a specific protocol (e.g., PCIe, Ethernet, JESD204, Aurora), or are they raw PHYs?40Views0likes6CommentsRe: IBIS models GTS banks agilex 5E
ohfpga1 You can get the IBIS-AMI model from this link once you have login into your MyAltera account: https://docs.altera.com/v/u/resources/772261/agilextm-5-transceiver-ibis-ami-model Or, you can search as below keywords once login. if you did not find the models after login in, please let me know.26Views0likes0Comments