Visible to Intel only — GUID: bhc1410931819968
Ixiasoft
1. About Triple-Speed Ethernet Intel® FPGA IP for Agilex™ 5 devices
2. Getting Started
3. Parameter Settings
4. Functional Description
5. Configuration Register Space
6. Interface Signals
7. Design Considerations
8. Timing Constraints
9. Testbench
10. Triple-Speed Ethernet Intel® FPGA IP User Guide Archives
11. Document Revision History for the Triple-Speed Ethernet Intel® FPGA IP User Guide: Agilex™ 5 FPGAs and SoCs
A. Ethernet Frame Format
B. Simulation Parameters
4.1.1. MAC Architecture
4.1.2. MAC Interfaces
4.1.3. MAC Transmit Datapath
4.1.4. MAC Receive Datapath
4.1.5. MAC Transmit and Receive Latencies
4.1.6. FIFO Buffer Thresholds
4.1.7. Congestion and Flow Control
4.1.8. Magic Packets
4.1.9. MAC Local Loopback
4.1.10. MAC Reset
4.1.11. PHY Management (MDIO)
4.1.12. Connecting MAC to External PHYs
6.1.1. 10/100/1000 Ethernet MAC Signals
6.1.2. 10/100/1000 Multiport Ethernet MAC Signals
6.1.3. 10/100/1000 Ethernet MAC with 1000BASE-X/SGMII PCS Signals
6.1.4. 10/100/1000 Ethernet MAC with Internal FIFO Buffers, and 1000BASE-X/SGMII 2XTBI PCS with Embedded PMA (GTS) Signals
6.1.5. 10/100/1000 Multiport Ethernet MAC with 1000BASE-X/SGMII PCS Signals
6.1.6. 1000BASE-X/SGMII PCS Signals
6.1.7. 1000BASE-X/SGMII 2XTBI PCS Signals
6.1.1.1. Clock and Reset Signals
6.1.1.2. Clock Enabler Signals
6.1.1.3. MAC Control Interface Signals
6.1.1.4. MAC Status Signals
6.1.1.5. MAC Receive Interface Signals
6.1.1.6. MAC Transmit Interface Signals
6.1.1.7. Pause and Magic Packet Signals
6.1.1.8. MII/GMII/RGMII Signals
6.1.1.9. PHY Management Signals
Visible to Intel only — GUID: bhc1410931819968
Ixiasoft
6.1.1.5. MAC Receive Interface Signals
Name | Avalon Streaming Signal Type | I/O | Description |
---|---|---|---|
Avalon Streaming Signals | |||
ff_rx_clk (In Platform Designer: receive_clock_connection) |
clk | I | Receive clock. All signals on the Avalon streaming receive interface are synchronized on the rising edge of this clock. Set this clock to the frequency required to get the desired bandwidth on this interface. This clock can be completely independent from rx_clk. |
ff_rx_dval | valid | O | Receive data valid. When asserted, this signal indicates that the data on the following signals are valid: ff_rx_data[(DATAWIDTH -1):0], ff_rx_sop, ff_rx_eop, rx_err[5:0], rx_frm_type[3:0], and rx_err_stat[17:0]. |
ff_rx_data [(DATAWIDTH-1):0] | data | O | Receive data. When DATAWIDTH is 32, the first byte received is ff_rx_data[31:24] followed by ff_rx_data[23:16] and so forth. |
ff_rx_mod[1:0] | empty | O | Receive data modulo. Indicates invalid bytes in the final frame word:
This signal applies only when DATAWIDTH is set to 32. |
ff_rx_sop | startofpacket | O | Receive start of packet. Asserted when the first byte or word of a frame is driven on ff_rx_data[(DATAWIDTH-1):0]. |
ff_rx_eop | endofpacket | O | Receive end of packet. Asserted when the last byte or word of frame data is driven on ff_rx_data[(DATAWIDTH-1):0]. |
ff_rx_rdy | ready | I | Receive application ready. Assert this signal on the rising edge of ff_rx_clk when the user application is ready to receive data from the MAC function. |
rx_err[5:0] | error | O | Receive error. Asserted with the final byte in the frame to indicate that an error was detected when receiving the frame. See rx_err Bit Description for the bit description. |
Component-Specific Signals | |||
ff_rx_dsav | — | O | Receive frame available. When asserted, this signal indicates that the internal receive FIFO buffer contains some data to be read but not necessarily a complete frame. The user application may want to start reading from the FIFO buffer. This signal remains deasserted in the store and forward mode. |
rx_frm_type[3:0] | — | O | Frame type. See rx_frm_type Bit Description for the bit description. |
ff_rx_a_full | — | O | Asserted when the FIFO buffer reaches the almost-full threshold. |
ff_rx_a_empty | — | O | Asserted when the FIFO buffer goes below the almost-empty threshold. |
rx_err_stat[17:0] | — | O | rx_err_stat[17]: One indicates that the receive frame is a stacked VLAN frame. rx_err_stat[16]: One indicates that the receive frame is either a VLAN or stacked VLAN frame. rx_err_stat[15:0]: The value of the length/type field of the receive frame. |
Bit | Description |
---|---|
3 | Indicates VLAN frames. Asserted with ff_rx_sop and remains asserted until the end of the frame. |
2 | Indicates broadcast frames. Asserted with ff_rx_sop and remains asserted until the end of the frame. |
1 | Indicates multicast frames. Asserted with ff_rx_sop and remains asserted until the end of the frame. |
0 | Indicates unicast frames. Asserted with ff_rx_sop and remains asserted until the end of the frame. |
Bit | Description |
---|---|
5 | Collision error. Asserted when the frame was received with a collision. |
4 | Corrupted receive frame caused by PHY or PCS error. Asserted when the error is detected on the MII/GMII/RGMII. |
3 | Truncated receive frame. Asserted when the receive frame is truncated due to an overflow in the receive FIFO buffer. |
2 11 | CRC error. Asserted when the frame is received with a CRC-32 error. This error bit applies only to frames with a valid length. Refer to Length Checking. |
1 11 | Invalid length error. Asserted when the receive frame has an invalid length as defined by the IEEE Standard 802.3. For more information on the frame length, refer to Length Checking. |
0 | Receive frame error. Indicates that an error has occurred. It is the logical OR of rx_err[5:1]. |
11 Bits 1 and 2 are not mutually exclusive. Ignore CRC error rx_err[2] signal if it is asserted at the same time as the invalid length error rx_err[1] signal.