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, BarryConfusion 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
Agilex5: XVCR Toolkit
I am trying to use the XVCR Toolkit on the Atum A5 by following the user guide SPEC: In Section 3.7.2 the clock connections are defined: I am using PMA clocking, with a Phase Compensation FIFO and 2x Width transfer, which implies the use of o_tx/rx_clkout2, the Word clock and a 2x division factor. Table 61 also suggests we do not need custom cadence gen. In Section 3.9.6 the reset sequence is defined: Which implies this snippet should be used at the top level HDL: always @(posedge system_clk_100) begin if (system_reset) begin gts_i_tx_reset <= 1'b1; gts_i_rx_reset <= 1'b1; end else begin if((gts_o_tx_reset_ack==1'b1) && (gts_o_rx_reset_ack==1'b1)) begin gts_i_tx_reset <= 1'b0; gts_i_rx_reset <= 1'b0; end end end In Section 3.11.1, the JTAG connection to the GTS is defined: Which suggests to define the following snippet in the HPS definition: .intel_directphy_gts_0_reconfig_address (address_bridge[17:0]) DESIGN: All of this combines into the following GTS configuration and system definition: GTS PMA/FEC PHY settings changed from default: ------------------------------ Datapath clocking mode : PMA TX/RX PMA interface FIFO mode : Register TX/RX clock clock source : Word Clock Enable TX/RX_clkout2 port : YES TX/RX clkout_2 clock source : Word Clock TX/RX _clkout2 div by : 2 Enable Avalon Memory Mapped interface : YES Enable Direct PHY soft CSR : YES Enable Debug Ednpoint on Avalon interface : YES With the following Qsys connections, and top level RTL connections: module golden_top(...); ... // GTS signals reg gts_i_tx_reset, gts_i_rx_reset; wire gts_o_tx_reset_ack, gts_o_rx_reset_ack; wire gts_o_tx_clkout, gts_o_rx_clkout; wire [79:0] gts_i_tx_parallel_data; wire [79:0] gts_o_rx_parallel_data; // jtag bridge wire write_bridge, read_bridge; wire [31:0] address_bridge; wire [31:0] writedata_bridge; wire [31:0] readdata_bridge; wire [3:0] byteenable_bridge; wire waitrequest_bridge; wire readdatavalid_bridge; // reset always @(posedge system_clk_100) begin if (system_reset) begin gts_i_tx_reset <= 1'b1; gts_i_rx_reset <= 1'b1; end else begin if((gts_o_tx_reset_ack==1'b1) && (gts_o_rx_reset_ack==1'b1)) begin gts_i_tx_reset <= 1'b0; gts_i_rx_reset <= 1'b0; end end end qsys_top soc_inst ( ... .intel_directphy_gts_0_i_rx_cdr_refclk_p_clk (REFCLK), .intel_directphy_gts_0_i_tx_pll_refclk_p_clk (REFCLK), .intel_directphy_gts_0_i_tx_reset_tx_reset (gts_i_tx_reset), .intel_directphy_gts_0_i_rx_reset_rx_reset (gts_i_rx_reset), .intel_directphy_gts_0_o_tx_reset_ack_tx_reset_ack (gts_o_tx_reset_ack), .intel_directphy_gts_0_o_rx_reset_ack_rx_reset_ack (gts_o_rx_reset_ack), .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), .intel_directphy_gts_0_reconfig_write (write_bridge), .intel_directphy_gts_0_reconfig_read (read_bridge), .intel_directphy_gts_0_reconfig_address (address_bridge[17:0]), .intel_directphy_gts_0_reconfig_byteenable (byteenable_bridge), .intel_directphy_gts_0_reconfig_writedata (writedata_bridge), .intel_directphy_gts_0_reconfig_readdata (readdata_bridge), .intel_directphy_gts_0_reconfig_waitrequest (waitrequest_bridge), .intel_directphy_gts_0_reconfig_readdatavalid (readdatavalid_bridge), .gts_jtag_master_0_master_address (address_bridge), .gts_jtag_master_0_master_readdata (readdata_bridge), .gts_jtag_master_0_master_read (read_bridge), .gts_jtag_master_0_master_write (write_bridge), .gts_jtag_master_0_master_writedata (writedata_bridge), .gts_jtag_master_0_master_waitrequest (waitrequest_bridge), .gts_jtag_master_0_master_readdatavalid (readdatavalid_bridge), .gts_jtag_master_0_master_byteenable (byteenable_bridge), ... ); ... endmodule The boot output: TFTP from server **bleep**.**bleep**.xx.x; our IP address is **bleep**.**bleep**.xx.x Filename 'fpga/soc_system_base.rbf'. Load address: 0x90000000 Loading: ################################################################# ################################################################# ######### 2 MiB/s done Bytes transferred = 2031616 (1f0000 hex) ... FPGA reconfiguration failed!Command 'load' failed: Error -110 FPGA not ready. Bridge reset aborted! Did I overlook something? Any help would be greatly appreciated! Many thanks!
Status Enguiry_Intel
Good morning, I would like to ask whether the CYCLONE II and CYCLONE III series products are still being manufactured but not recommended, or whether they have been discontinued and are obsolete. The question concerns the following components: EP2C35F484C8N EP3C25F256I7 EP3C25F324I7 EP2C20F484C8N EP2C5F256C8N EP2C35F484I8N EP2C5F256I8N EP2C20F256I8N EP2C8F256I8N EP2C15AF484I8N EP3C25E144I7N EP3C25F324C7N If they are being discontinued, is there a replacement for them and do they have a Last Time Buy date? I would appreciate any information. Best regards, Katarzyna Mokwa
Multi-rate Ethernet valid signal behavior
I'm working with the 1G/2.5G/5G/10G Multi-rate Ethernet PHY IP Core on an Arria V device. https://www.intel.com/content/www/us/en/docs/programmable/683171/current/introduction-to-the-protocol-specific.html#joc1445401896251 I fixed my IP to 2.5G and have a question about the gmii16b_rx_dv signal. The datasheet explains that this signal marks which of the 2 bytes are valid: Is it possible for one of the bits of gmii16b_rx_dv to be '0' in the middle of a packet ? Or it can happen ONLY in the last byte ?Agilex 5 GTS PMA/FEC Direct Loopback
Say I need to connect an oscillating component (with parallel data) to the GTS from the fabric, and then loop it back to via serial in fabric, and then read the output parallel data. To set this up, can I simply: 1: Set the "TX/RX Common PMA Options Loopback mode" to "parallel" 2: Route `i_rx_serial_data` back to `o_tx_serial_data` assign gts_i_rx_serial_data = gts_o_tx_serial_data; assign gts_i_rx_serial_data_n = gts_o_tx_serial_data_n; 3: Connect an oscillating component to the `rx_parallel_data`? Of course I have omitted many signals here, but is it along the right lines? Many thanks!
