About Design Limitations and Known Issues
In the "GTS SDI II IP User Guide", section 8. Design Limitations and Known Issues states a known issue: "High bit error rates are observed in recovered data." It also states that there is no workaround in the current version of Quartus, but are there any plans to address this issue? https://www.intel.com/content/www/us/en/docs/programmable/823539/25-3/design-limitations-and-known-issues.html14Views0likes2CommentsEnabling DFE Adaptation on Cyclone 10 GX
Hello! I'm trying to set the DFE Mode to "Adaptation Enabled" on my Cyclone 10 GX processor using the NiosV processor I have in the Cyclone 10. I'm able to turn on the transceivers and detect error bits due to the fact that I'm running at max speed (12.5gbps), but I need to enable DFE adaptation in order to get my error bitrate to decrease. I've been testing using the transceiver toolkit, so I know it is possible, but I haven't been able to find any documentation on how to do this in the Cyclone 10. I have found this page for the Arria 10 (which is, from my understanding, very similar), but these steps have not enabled DFE Adaptation in my testing. I have been using a mix of the Arria 10 register map and the Cyclone 10 register map to get to this point. Any help or insight you have to help me enable DFE adaptation from the NiosV processor would be greatly appreciated!21Views0likes4CommentsTransceiver data corruption
I am trying to externally loopback a simple data-stream using the GTS on the Agilex 5, over an external QSFP loopback module. The GTS is configured as followed: External clock chip: Outputs 156.25 MHz clock verified using an oscilloscope. System PLL: Outputs 125 MHz to the GTS. GTS: Basic PMA Direct System PLL freq: 125 MHz PMA speed: 1250 Mbps PMA width: 10 TX/RX PLL/CDR: 156.25 MHz TX/RX core interface FIFO: single width TX/RX clock: System PLL clock /1 The RTL used to transfer data over TX: module top( input CPU_RESET_n, input REFCLK, output gts_o_tx_serial_data, output gts_o_tx_serial_data_n, input gts_i_rx_serial_data, input gts_i_rx_serial_data_n ); // gts logic gts_pma_cu_clk_i; logic gts_tx_reset, gts_rx_reset; logic gts_tx_reset_ack, gts_rx_reset_ack; logic gts_tx_ready, gts_rx_ready; logic tx_coreclkin, rx_coreclkin; (* noprune *) logic gts_tx_clkout, gts_rx_clkout; logic gts_rs_grant_i; logic gts_rc_rs_req_o; (* noprune *) logic gts_tx_pll_locked /* synthesis keep */; (* noprune *) logic gts_rx_is_lockedtodata /* synthesis keep */; (* noprune *) logic gts_rx_is_lockedtoref /* synthesis keep */; logic o_refclk2core; (* noprune *) logic [79:0] gts_i_tx_parallel_data /* synthesis keep */; (* noprune *) logic [79:0] gts_o_rx_parallel_data /* synthesis keep */; assign gts_pma_cu_clk_i = srcss_bank1_pma_cu_clk_o; assign tx_coreclkin = gts_tx_clkout; assign rx_coreclkin = gts_rx_clkout; assign gts_rs_grant_i = srcss_bank1_rs_grant_o; // reset sequencer signals logic srcss_bank1_rs_grant_o; logic srcss_bank1_rs_priority; logic srcss_bank1_rc_rs_req; logic srcss_bank1_pma_cu_clk_o; assign srcss_bank1_rs_priority = '0; assign srcss_bank1_rc_rs_req = gts_rc_rs_req_o; // system pll signals logic gts_systempll_refclk_rdy; assign gts_systempll_refclk_rdy = 1'b1; gts_top u0 ( // gts .gts_top_clock_bridge_rx_in_clk_clk (QSFP_REFCLK_p), .gts_top_clock_bridge_tx_in_clk_clk (QSFP_REFCLK_p), .intel_directphy_gts_0_i_pma_cu_clk_clk (gts_pma_cu_clk_i), .intel_directphy_gts_0_i_tx_reset_tx_reset (gts_tx_reset), .intel_directphy_gts_0_i_rx_reset_rx_reset (gts_rx_reset), .intel_directphy_gts_0_o_tx_reset_ack_tx_reset_ack (gts_tx_reset_ack), .intel_directphy_gts_0_o_rx_reset_ack_rx_reset_ack (gts_rx_reset_ack), .intel_directphy_gts_0_o_tx_ready_tx_ready (gts_tx_ready), .intel_directphy_gts_0_o_rx_ready_rx_ready (gts_rx_ready), .intel_directphy_gts_0_i_tx_coreclkin_clk (tx_coreclkin), .intel_directphy_gts_0_i_rx_coreclkin_clk (rx_coreclkin), .intel_directphy_gts_0_o_tx_clkout_clk (gts_tx_clkout), .intel_directphy_gts_0_o_rx_clkout_clk (gts_rx_clkout), .intel_directphy_gts_0_i_src_rs_grant_src_rs_grant (gts_rs_grant_i), .intel_directphy_gts_0_o_src_rs_req_src_rs_req (gts_rc_rs_req_o), .intel_directphy_gts_0_o_tx_serial_data_o_tx_serial_data (gts_o_tx_serial_data), .intel_directphy_gts_0_o_tx_serial_data_n_o_tx_serial_data_n (gts_o_tx_serial_data_n), .intel_directphy_gts_0_i_rx_serial_data_i_rx_serial_data (gts_i_rx_serial_data), .intel_directphy_gts_0_i_rx_serial_data_n_i_rx_serial_data_n (gts_i_rx_serial_data_n), .intel_directphy_gts_0_o_tx_pll_locked_o_tx_pll_locked (gts_tx_pll_locked), .intel_directphy_gts_0_o_rx_is_lockedtodata_o_rx_is_lockedtodata (gts_rx_is_lockedtodata), .intel_directphy_gts_0_o_rx_is_lockedtoref_o_rx_is_lockedtoref (gts_rx_is_lockedtoref), .intel_directphy_gts_0_o_refclk2core_o_refclk2core (o_refclk2core), .intel_directphy_gts_0_i_tx_parallel_data_i_tx_parallel_data (gts_i_tx_parallel_data), .intel_directphy_gts_0_o_rx_parallel_data_o_rx_parallel_data (gts_o_rx_parallel_data), // reset sequencer signals .intel_srcss_gts_0_o_src_rs_grant_src_rs_grant (srcss_bank1_rs_grant_o), .intel_srcss_gts_0_i_src_rs_priority_src_rs_priority (srcss_bank1_rs_priority), .intel_srcss_gts_0_i_src_rs_req_src_rs_req (srcss_bank1_rc_rs_req), .intel_srcss_gts_0_o_pma_cu_clk_clk (srcss_bank1_pma_cu_clk_o), // system pll signals .intel_systemclk_gts_0_i_refclk_rdy_data (gts_systempll_refclk_rdy) ); // syncronise reset logic gts_tx_system_reset; altera_reset_synchronizer #( .ASYNC_RESET (1), .DEPTH (2) ) gts_tx_rst_sync ( .reset_in (~CPU_RESET_n), .clk (gts_tx_clkout), .reset_out (gts_tx_system_reset) ); // generate test data stream logic [7:0] counter; logic [7:0] test_stream; always_ff @(posedge gts_tx_clkout or posedge gts_tx_system_reset) begin if (gts_tx_system_reset) begin counter <= 8'b0; test_stream <= 8'b0; end else begin counter <= counter + 1; case (counter) 8'd0: test_stream <= 8'h3C; 8'd1: test_stream <= 8'h7F; 8'd2: test_stream <= 8'h11; 8'd3: test_stream <= 8'h07; default: test_stream <= 8'h00; endcase end end // detect and transform idle data, and mark control symbols logic [7:0] idle_data_transform; logic control_symbol_detect; always_comb begin idle_data_transform = (test_stream == 8'h00) ? 8'hBC : test_stream; control_symbol_detect = (idle_data_transform == 8'h1C) || (idle_data_transform == 8'h3C) || (idle_data_transform == 8'h5C) || (idle_data_transform == 8'h7C) || (idle_data_transform == 8'h9C) || (idle_data_transform == 8'hBC) || (idle_data_transform == 8'hDC) || (idle_data_transform == 8'hFC) || (idle_data_transform == 8'hF7) || (idle_data_transform == 8'hFB) || (idle_data_transform == 8'hFD) || (idle_data_transform == 8'hFE); end // pipline combinational logic to ensure timings are met logic [7:0] idle_data_transform_r; logic control_symbol_detect_r; always_ff @ (posedge gts_tx_clkout or posedge gts_tx_system_reset) begin if(gts_tx_system_reset) begin idle_data_transform_r <= 8'b0; control_symbol_detect_r <= 1'b0; end else begin idle_data_transform_r <= idle_data_transform; control_symbol_detect_r <= control_symbol_detect; end end // --- 8b/10b Encoding --- // https://libsv.readthedocs.io/en/latest/encoder_8b10b.html logic [9:0] encoded_out; logic code_error; encoder_tx encoder_inst ( .i_clk (gts_tx_clkout), .i_reset_n (~gts_tx_system_reset), .i_en (1'b1), .i_8b (idle_data_transform_r), .i_ctrl (control_symbol_detect_r), .o_10b (encoded_out), .o_code_err (code_error) ); // pipeline encoded outputs to ensure timing is met logic [9:0] encoded_out_r; always_ff @(posedge gts_tx_clkout or posedge gts_tx_system_reset) begin if (gts_tx_system_reset) encoded_out_r <= 10'b0; else encoded_out_r <= encoded_out; end // send data over TX logic data_path_rdy_tx; always_ff @(posedge gts_tx_clkout or posedge gts_tx_system_reset) begin if (gts_tx_system_reset) begin gts_i_tx_parallel_data <= 80'b0; data_path_rdy_tx <= 0; end else begin data_path_rdy_tx <= gts_tx_ready && gts_tx_pll_locked; case (data_path_rdy_tx) 1: gts_i_tx_parallel_data <= {1'b1, 39'b0, 1'b0, 1'b1, 28'b0, encoded_out_r}; 0: gts_i_tx_parallel_data <= 80'b0; endcase end end endmodule This RTL passes timing standalone, but when signal tap is used, it does produce warnings. In SignalTap I take the following measurments: Instance TX: data: gts_i_tx_parallel_data[79:0] clock domain: gts_tx_clkout Instance RX: data: gts_i_rx_parallel_data[79:0] clock domain: gts_rx_clkout The issue I am seeing is intermitted failures upon bitstream-re-configure: On the TX side, after the encoder has encoded, the TX data reads as folowed: (EXPECTED): ... 283, 17C, 283, 17C, 183, 335, 0B1, 347, 283, 17C, 283, 17C, ... This is the expected pattern on the RX side (post-framing) However, in my experiments so far, I have found that it only sometimes works: Here are the framing results after 5 different re-flashes: (FAILURE): ... 283, 17C, 283, 17C, 383, 135, 0B1, 347, 083, 37C, 283, 17C, ... (FAILURE): ... 283, 17C, 283, 17C, 383, 135, 0B1, 347, 083, 37C, 283, 17C, ... (FAILURE): ... 283, 17C, 283, 17D, 183, 335, 0B1, 346, 283, 17C, 283, 17C, ... (SUCCESS): ... 283, 17C, 283, 17C, 183, 335, 0B1, 347, 283, 17C, 283, 17C, ... (FAILURE): ... 283, 17C, 283, 175, 1B1, 307, 083, 37C, 283, 17C, 283, 17C, ... If anyone has any idea of what else to try, it would be much appreciated!21Views0likes3CommentsStratix 10 100GBE streaming
Hi, Altera community forum, I am using the S10 board in Quartus Prime Pro 24.1 and Ubuntu 24. I want to configure 100 GBE data streaming. I have a Platform Designer file where I have designed my signal processing design. This design will produce a lot of data, and I want to stream it to 100GBE. I read the document about the Low-Latency 100Gbe Ethernet IP Core User Guide and the Low-Latency 100Gbe Ethernet Intel Stratix 10 FPGA IP Design Example User Guide. In User Guide 1.5, there is a simulation of the design example testbench, which is not working as expected. It is asking me for a license, which I already have; I even gave it the license path in the command line terminal. I already compiled this low-latency 100 GbE design in Quartus Prime Pro 24.1, and the compilation is successful. After that, I am lost. How can I integrate this IP into the platform designer? Please help. Thank you.37Views0likes4CommentsClarification on TX/RX P&N Invert feature support in TSE IP core
Hello, Based on the page below from the GTS Transceiver PHY User Guide: Agilex™ 5 FPGAs and SoCs (version 25.1, “Analog Parameter Options” section), the “Enable TX P&N Invert” and “Enable RX P&N Invert” options are described as preliminary and not supported in hardware: 3.3.11. Analog Parameter Options However, according to the updated page for version 25.1.1, those same features are now marked as supported in hardware: 3.3.11. Analog Parameter Options In the Analog Parameters tab of the Triple-Speed Ethernet (TSE) Intel FPGA IP, these TX/RX P&N Invert options also appear as configurable parameters. Could you please confirm whether these features are expected to function in Quartus Prime Pro 25.1.1 and Quartus Prime Pro 25.3 when used in the TSE IP core? Also, could you please let us know what happens if we enable these P/N inversion options in Quartus 25.1, since the documentation indicates that they are not supported in hardware in that release? Thank you in advance for your help and clarification. Best regards,Solved103Views1like8CommentsDelay in CDR recover
Hi friends, I hope this message finds you well. I am currently encountering some issues with the burst-mode CDR implementation using ALTGX. Test setup: In my setup, I am using an optical modulator to generate burst-mode optical signals. The burst-mode light (on/off) is sent directly to an SFP+ module mounted on a Terasic HSMC SFP daughter board, connected to a DE4 (Stratix IV) development board. Each burst frame consists of approximately 109 µs of light on and 109 µs off. To properly decode the received signals, the transceiver is supplied with a reference clock (`rx_cruclk`) that is phase-recovered from the transmitter. The ALTGX CDR is switched between `rx_locktoref` and `rx_locktodata` in synchronization with the optical signal transitions: * When the signal is **off**: lock to `rx_cruclk` * When the signal is **on**: lock to data **Observed issue:** Switching between `rx_locktoref` and `rx_locktodata` does help the CDR lock within the 109 µs burst duration, but the locking time is longer than expected. It takes around **1.3 µs** for the CDR and word aligner to fully synchronize with the received data stream. This is much slower than anticipated, considering that the reference clock provided to the ALTGX is quite stable, and the phase difference between `rx_cruclk` and the transmitter clock fluctuates within only about 3 degrees. We also experimented with manually delaying the start of the CDR locking process to better align it with the beginning of each burst frame, but the locking time consistently remained around 1.3 µs. Additionally, we tested by launching a continuous optical signal into the SFP while maintaining switching between rx_locktoref and rx_locktodata. In this configuration, the CDR synchronized to the incoming data within a few nanoseconds, as expected. We suspect that when the optical signal is absent, the CDR inside the SFP module drifts, causing the output serial stream to deviate significantly. As a result, the ALTGX receiver cannot lock onto the drifted signal. We tested several SFP modules and selected the one that delivered the best performance, achieving approximately 1.3 µs locking time. Would a 1.3 µs CDR locking time be expected under these conditions? Since our implementation uses a reference-assisted CDR with a phase-locked reference clock derived from the transmitter, we anticipated a faster locking response. The project is still ongoing, so I’m not yet certain whether I can share the source code, but please let me know if reviewing it would help with further debugging. Thank you very much for your assistance—it’s greatly appreciated. Best regards, Hank75Views0likes9CommentsAgilex 5 GTS Direct PHY RX simplex cold start issue
Hello, I have a design that instantiates the GTS Direct PHY in RX Simplex mode (1 lane). When the design is loaded from the configuration flash device, the PHY remains stuck in the “RX Data Loss / CDR Lock Loss (Auto-Recovery)” state indefinitely. Below is a transitional-mode power-on capture (greater than 10 s): And here is a zoomed-in view of the startup sequence showing the external resets: When I download the same configuration as a .sof file, the receiver starts up normally — no lock-loss events are observed. After rx_ready asserts, there are no further transitions, so the capture was stopped at that point. Any insight or suggestions on what might cause this difference between .jic(flash) and .sof (volatile) configuration behavior would be greatly appreciated. Thank you!23Views0likes2Comments