Correct way to configure the RGMII input and output pins on a MAX10 FPGA
Greetings ALTERA Expetrs, I am using an ALTERA Triple Speed Ethernet IP core configured n MAC only mode, which talks to a MARVELL 88E1111 PHY. Actually for this example i am using an ALTERA MAX10 10M50-C Development kit. I am having trouble understanding exactly HOW to configure the DDR RGMII input and output pins. After instantiating the Triple Speed Ethernet IP in a top level System Verilog file and connecting up Avalon MM, Avalon Tx/Rx ST interfaces etc, and connecting up clocks and resets, do i need to to connect up my RGMII DDR outputs using altddio_out IP and my RGMII DDR inputs to FPGSA pins using altddio_in IP blocks ? This is how i am thinking i need to connect my DDR RGMII FPGA pins up to my Triple Speed Ethernet RGMII tx in and rx in busses on the IP: Connect the TX Clock output : altddio_out #(.width(1), .INTENDED_DEVICE_FAMILY("max10")) altddio_out_a_txc (.outclock (clk_125MHz), .datain_h (1'b1), .datain_l (1'b0),.dataout (RGMII_ETH_TXC), // TSE clock TX PORT A .oe (1'b1), .outclocken (1'b1), .aclr (1'b0), .aset (1'b0) ); Connect the RGMI TX data outputs : altddio_out #( .width(4), .INTENDED_DEVICE_FAMILY("max10") ) altddio_out_a_txd ( .outclock (clk_125MHz), // 125 MHz Transmit clock for RGMII .datain_h (rgmii_out_ddr), // rising edge .datain_l (rgmii_out_ddr), // falling edge .dataout (rgmii_out), .aclr (1'b0), .aset (1'b0), .oe (1'b1), .outclocken (1'b1) ); Where in the above code rgmii_out wires are going to FPGA DDR RGMI TX output pins, and rgmii_out_ddr is from the Triple speed IP core. For the RX side for the INPUT DDR RGIM Rx data bus: altddio_in #(.width(4), .INTENDED_DEVICE_FAMILY("max10")) altddio_in_a_rxd ( .inclock (RGMII_ETH_RXC), .datain (rgmii_in), .dataout_h (rgmii_rxd), .dataout_l (/* unused */) ); Do these sort of DDR interface IP instantiations looks correct ? All help gratefully received ! Thanks, Dr Barry HConfusion for TX Clock direction for Triple Speed 1G Ethernet IP?
Hello ALTRA IP experts, Can anybody please explain to me why, when i set the Triple Speed Ethernet IP up for RGMII mode, the tx clock for the MAC is set as an input? eth_tse_0_pcs_mac_tx_clock_clk : in std_logic := 'X'; -- clk I was expecting this signal to be an output for the Transmit MAC section to to the PHY TX block ? Here are all of the signal connections i get when i setup in RMII mode for the Triple Speed 10/100/1000 Ethernet IP core (its easier to see directions and sizes using the VHDL instance template) : eth_tse_0_mac_status_set_10 : in std_logic := 'X'; -- set_10 eth_tse_0_mac_status_set_1000 : in std_logic := 'X'; -- set_1000 eth_tse_0_mac_status_eth_mode : out std_logic; -- eth_mode eth_tse_0_mac_status_ena_10 : out std_logic; -- ena_10 eth_tse_0_mac_rgmii_rgmii_in : in std_logic_vector(3 downto 0) := (others => 'X'); -- rgmii_in eth_tse_0_mac_rgmii_rgmii_out : out std_logic_vector(3 downto 0); -- rgmii_out eth_tse_0_mac_rgmii_rx_control : in std_logic := 'X'; -- rx_control eth_tse_0_mac_rgmii_tx_control : out std_logic; -- tx_control eth_tse_0_receive_data : out std_logic_vector(31 downto 0); -- data eth_tse_0_receive_endofpacket : out std_logic; -- endofpacket eth_tse_0_receive_error : out std_logic_vector(5 downto 0); -- error eth_tse_0_receive_empty : out std_logic_vector(1 downto 0); -- empty eth_tse_0_receive_ready : in std_logic := 'X'; -- ready eth_tse_0_receive_startofpacket : out std_logic; -- startofpacket eth_tse_0_receive_valid : out std_logic; -- valid eth_tse_0_transmit_data : in std_logic_vector(31 downto 0) := (others => 'X'); -- data eth_tse_0_transmit_endofpacket : in std_logic := 'X'; -- endofpacket eth_tse_0_transmit_error : in std_logic := 'X'; -- error eth_tse_0_transmit_empty : in std_logic_vector(1 downto 0) := (others => 'X'); -- empty eth_tse_0_transmit_ready : out std_logic; -- ready eth_tse_0_transmit_startofpacket : in std_logic := 'X'; -- startofpacket eth_tse_0_transmit_valid : in std_logic := 'X'; -- valid eth_tse_0_mac_mdio_mdc : out std_logic; -- mdc eth_tse_0_mac_mdio_mdio_in : in std_logic := 'X'; -- mdio_in eth_tse_0_mac_mdio_mdio_out : out std_logic; -- mdio_out eth_tse_0_mac_mdio_mdio_oen : out std_logic; -- mdio_oen eth_tse_0_mac_misc_magic_wakeup : out std_logic; -- magic_wakeup eth_tse_0_mac_misc_magic_sleep_n : in std_logic := 'X'; -- magic_sleep_n eth_tse_0_mac_misc_ff_tx_crc_fwd : in std_logic := 'X'; -- ff_tx_crc_fwd eth_tse_0_mac_misc_ff_tx_septy : out std_logic; -- ff_tx_septy eth_tse_0_mac_misc_tx_ff_uflow : out std_logic; -- tx_ff_uflow eth_tse_0_mac_misc_ff_tx_a_full : out std_logic; -- ff_tx_a_full eth_tse_0_mac_misc_ff_tx_a_empty : out std_logic; -- ff_tx_a_empty eth_tse_0_mac_misc_rx_err_stat : out std_logic_vector(17 downto 0); -- rx_err_stat eth_tse_0_mac_misc_rx_frm_type : out std_logic_vector(3 downto 0); -- rx_frm_type eth_tse_0_mac_misc_ff_rx_dsav : out std_logic; -- ff_rx_dsav eth_tse_0_mac_misc_ff_rx_a_full : out std_logic; -- ff_rx_a_full eth_tse_0_mac_misc_ff_rx_a_empty : out std_logic; -- ff_rx_a_empty clk_out_5_clk : out std_logic; -- clk eth_tse_0_pcs_mac_tx_clock_clk : in std_logic := 'X'; -- clk eth_tse_0_pcs_mac_rx_clock_clk : in std_logic := 'X'; -- clk eth_tse_0_mac_clkena_rx_clkena : in std_logic := 'X'; -- rx_clkena eth_tse_0_mac_clkena_tx_clkena : in std_logic := 'X' -- tx_clkena These all make sense to me EXCEPT for the eth_tse_0_pcs_mac_tx_clock_clk signal which i thought would be an OUPUT and NOT and INPUT ! Thanks for your help, Barry
MSGDMA: Is Linux Driver Mandatory? Using devmem2 & F2SDRAM Bridge
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?Ticket Update
Hi - I have posted a follow up question on an old thread an would appreciate any help! I am making this post, as it is not clear where I can submit an official ticket otherwise. Can be seen here: Transceiver data corruption | Altera Community Please do feel free to delete this post when somone is assigned to the issue. Thanks.Transceiver 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!
Fitter cannot ...
I am trying to set up a basic SDI transmitter on an Agilex 5. Currently, my setup is a 148.5 MHz refclk, a GTS PMA Direct PHY IP configured for 12G SDI, a GTS Reset Sequencer, and a GTS System PLL configured to take in the refclk and output 742.5 MHz (this is based on the minimum system PLL frequency recommendation in the SDI II IP documentation). I have my serial output differential pair on pins BE129 and BE126 which are the GTS Left 1B TX 0 channels, and my refclk coming in as a differential pair on pins AY120 and AY115 which are the refclk pins for GTS Left 1B. According to the documentation for the SoM, these refclk pins should be configured to 148.5 MHz. For some reason, when I try to compile, the fitter fails in the plan stage with error 14566 "The Fitter cannot place 1 periphery component due to conflicts with existing constraints (1 I/O pad). Fix the errors described in the submessages, and then rerun the Fitter." The submessages read, "Illegal constraint of I/O pad to the location PIN_AY115" (175019), "No legal location could be found out of 1 considered location. Reasons why each location could not be used are summarized below:" (16234), "There is no routing connectivity between the I/O pad and the destination I/O input buffer" (175006), "The I/O pad could not be placed in any location to satisfy its connectivity requirements" (175022), and "The destination I/O input buffer could not be placed in any location to satisfy its connectivity requirements" (175022). There isn't very much logic surrounding the system (basically just a counter to create some dummy input data), so I'm not sure why it wouldn't be able to connect specifically the n side of the refclk. Has anyone encountered similar issues/errors and could maybe point me in the right direction? Any help would be appreciated.Agilex 5: Connecting multiple AXI Masters to DDR without explicit Interconnect IP
Hi all, I'm developing on the Agilex 5 platform and need two AXI4 masters to access the DDR. I noticed there isn't a standalone IP similar to Xilinx's axi_interconnect. Is it correct to simply connect two AXI masters directly to the single DDR AXI slave port (as shown below)? Will the interconnect fabric generate the necessary arbitration and routing logic in this case？Creating a design with a 1G Ethernet IP for Synthesis
Hello QUARTUS IP experts, I need to build a project which has a Triple Speed Ethernet IP in using QUARTUS Standard edition and Platform Designer. I can create an example design and i have been able to simulate that in QUESTA. But what is the best method to create a design which has the correct AVALON MM and AVALON ST modules connected up for the Control, Status, MDIO, and TX and RX paths ? Is there an ALTERA Github somewhere which already has this kind of test design built ? I am using a MAX10 FPGA and System Verilog. My aim is to be able to synthesise and implement this test design so that i can see the LUT and memory utilizations a couple of different configuration, using the 1G speed. Thanks for your help, BarryALT 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, Barry
COLLINS AEROSPACE- Request for Material Declaration<171424>INTEL CORP
This is regarding Collins Aerospace material declaration request. We need few clarifications and data on 2 parts. Please see below comments. EM2140P01QI:- FMD document has 7(a) exemption but Lead (Pb) content is not >85% by weight. Please advise. ES1030QI:-In FMD, Substance name is 'Tin' but CAS number "7440-32-6" is related to Titanium substance. Please provide updated FMD document. Please note:- I am unable to find the appropriate channel for these products in Intel website. Kindly guide me. Regards, Santosh
