ALT PLL GUI MESSDED UP ON INVOCATION
Hi All ALTERA Experts, I have a problem setting up a new PLL due to the GUI looking like the mess you can see in my attached screenshot. I am using Quartus Standard edition Version 25.1 I am on a windows 10 machine and all of the other IP GUIs seem to work fine, its just this PLL IP GUI that seems to get messed up. I am using a MAX10 FPGA. Both my PC and Graphics card are working fine. Can anybody suggest why this occurs ? Thanks, BarryTransceiver 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!
Stratix 10 CKEXT Drive Level 32 GHz Clock
Hello, The S10 datasheet lists the CKEXT differential input power requirement as +1.9 to +7.9 dBm at 32 GHz. Is the lower limit required to meet all performance parameters or a hard limit where the S10 will not function if not met? If the differential clock power is 0 dBm, does the S10 operate with degraded performance or stop working altogether. On our assembly CKEXT will be borderline to meeting the minimum +1.9 dBm input level. I'm planning to test the input power after we receive our assemblies, but was looking for guidance on what to expect. Thanks, JohnMAX10 10M50 Development KIT Triple Speed Ethernet problem
Greetings to all of the ALTERA Experts, I have been trying to get a Gigabit Ethernet interface working on an ALTERA MAX10 10M50-C Development kit and keep hitting a bit of a brick wall when tying to communicate with the MARVEL ALASKA 88E1111 PHY. It does not appear to respond correctly when i try to read for example the PHY ID register (address x02) which should respond with the value 0x041 but instead sends back 0x7fff. I am using a System Verilog HDL approach to both instantiate the ALTERA Triple speed IP core in MAC only mode, with 2K word FIFOs, and full duplex 10/100/1000. The IP is set to work in Gigabit mode. When i connect the board to a windows 10 PC using an Ethernet cable i can see the Yellow LED lit up on the Dev KITS PHY connector and when i test the connection on the windows 10 PC it says it is up and connected. But when i try to send any Ethernet packets (i am using IPV4 + UDP as packet payload) nothing gets through to the PC. I have verified this as well using WIRESHARK which shows me no ethernet frames are coming in from the MAX10 Dev kits end. I have set the Triple speed Ethernet IP cores mac0/mac1 register to this random value: 48'h321C23174ACB I think this is OK and what the Triple Speed Ethernet User Guide says. Please correct me if my thinking is wrong though ? Questions: a) Does any body know of any errata / bugs with this Development KIT OR with the MARVELL PHY ? b) Can anybody point me to a Git Hub which has a known working example using this ALTERA Dev Kit along with this MARVELL PHY ? This can use either a HDL approach (like i am trying to use here) or a NIOSV softcore processor approach. c) The MAX10 Dev Kit has 2 Ethernet PHYS. A and B. I think that the MAX10 10M50-C Dev Kit sets its A MARVELL PHY Address to 0x0 and its B side MARVELL PHY Address to 0x1 BUT its not easy i found to figure out the PHY addresses. If somebody can please show me how to properly derive the PHY ADDRESSES for both the MARVELL 88E1111 devices for PHY A (ETHERNET A) and PHY B (ETHERNET B) on the MAX10 10M50-C Dev Kit Board Schematic) i will be very grateful ! Thanks for any help, Dr Barry H
NIOS does not start after SW download (timing issue?)
Hi, Recently I got an old Arria V design to update. It is in Quartus II 15.0 containing the following main components (in Qsys design): NIOS II soft processor 2x UniPHY DDR3 RAM controller (soft version, not hard), 72 bit wide data running at 400MHz clock (800Mb/s) 2x Triple Speed Ethernet with 4x SGDMA The design uses only 40k ALMs out of 190k so it fits well but I have timing issues (slack) on pll_afi_clk for one or both DDR3 controllers. I can reduce it by a lot of fine tuning on synthesizer and fitter settings but when I change a bit in the design timing results go wrong and tuning has to be started again. Both FW and SW are downloaded to SRAM by ByteBlaster. I found when the slacks are big (>0.1ns) NIOS never starts after downloading the SW. When it is small or completely eliminated, NIOS starts in most of the cases (but not always). Is this normal for such a design, or am I doing something wrong? I have never seen such behaviour before. Can this timing issue affect the NIOS processor on such a way or should I search in another direction to solve the problem?
Quartus Eda_Writer keeps crashing
Quartus Prime v25 keeps crashing at the eda_writer step during the flow on Windows 11. I have tried different Quartus versions (II v13.1, Prime Lite v25, Prime Standard v25). All of them crashed at this step multiple times. Is this an issue with the design that I am trying to implement? I searched for this error on Google and I found a message that said it was a bug that was fixed in version 21.1. Strange that its still occuring now in v25 standard. Problem Details Error: Internal Error: Sub-system: WSC, File: /quartus/neto/wsc/wsc_hierarchy_builder.cpp, Line: 1097 m_bp_manager != NULL Stack Trace: 0x48eca: WSC_HIERARCHY_BUILDER::build_map_from_partitions + 0x8a (NETO_WSC) 0x46dd5: WSC_HIERARCHY_BUILDER::build_hierarchy_from_partitions + 0x35 (NETO_WSC) 0x45e1b: WSC_HIERARCHY_BUILDER::build + 0x22b (NETO_WSC) 0x16282: QNETO_START::build_hierarchy_netlist + 0x242 (quartus_eda) 0x28548: QNETO_START::generate_simulation_files + 0x688 (quartus_eda) 0x1a1e3: QNETO_START::generate_eda_files + 0x43 (quartus_eda) 0x33fd0: qneto_execute + 0x210 (quartus_eda) 0xa79b: QNETO_FRAMEWORK::execute + 0x26b (quartus_eda) 0x10b5f: qexe_do_normal + 0x22f (comp_qexe) 0x16fa0: qexe_run + 0x420 (comp_qexe) 0x18012: qexe_standard_main + 0xb2 (comp_qexe) 0x10d17: qneto_main + 0x77 (quartus_eda) 0x12208: msg_main_thread + 0x18 (CCL_MSG) 0x13b18: msg_thread_wrapper + 0x78 (CCL_MSG) 0x15f13: mem_thread_wrapper + 0x73 (ccl_mem) 0x11a41: msg_exe_main + 0xa1 (CCL_MSG) 0x36423: __scrt_common_main_seh + 0x10b (quartus_eda) 0x2e8d6: BaseThreadInitThunk + 0x16 (KERNEL32) 0x8c53b: RtlUserThreadStart + 0x2b (ntdll) End-trace Executable: quartus Comment: None System Information Platform: windows64 OS name: Windows 10 OS version: 10.0 Quartus Prime Information Address bits: 64 Version: 25.1std.0 Build: 1129 Edition: Standard Edition
MSGDMA ST-to-MM: Linux Driver Necessity & F2SDRAM Path Feasibility
Hello everyone, I am currently working on an MSGDMA implementation. I have verified that I can read the MSGDMA CSR and Descriptor registers via the LWH2F bridge using devmem2. My setup is configured in Streaming-to-Memory-Mapped (ST-to-MM) mode. I have two specific questions regarding this setup: 1、Is configuring the MSGDMA Linux kernel driver a mandatory condition for the hardware to function correctly? Is it possible to bypass the driver and configure the MSGDMA to start data transfer directly using devmem2 (user-space access)? 2、I noticed that some implementations write to the PS-side memory via the FPGA-to-HPS bridge. However, my design utilizes the F2SDRAM link, as indicated by the numbered sequence in the attached diagram. Could you please confirm if this architectural approach is feasible?
