2.1. Installation and Licensing for LL 40GbE IP Core for Stratix® V Devices
2.2. Installing and Licensing Intel® FPGA IP Cores
2.3. Specifying the IP Core Parameters and Options
2.4. IP Core Parameters
2.5. Files Generated for Stratix V Variations
2.6. Files Generated for Arria 10 Variations
2.7. Integrating Your IP Core in Your Design
2.8. IP Core Testbenches
2.9. Compiling the Full Design and Programming the FPGA
2.10. Initializing the IP Core
2.7.1. Pin Assignments
2.7.2. External Transceiver Reconfiguration Controller Required in Stratix V Designs
2.7.3. Transceiver PLL Required in Arria 10 Designs
2.7.4. Handling Potential Jitter in Intel® Arria® 10 Devices
2.7.5. External Time-of-Day Module for Variations with 1588 PTP Feature
2.7.6. Clock Requirements for 40GBASE-KR4 Variations
2.7.7. External TX MAC PLL
2.7.8. Placement Settings for the LL 40GbE Core
2.8.2.1. Generating the LL 40GbE Testbench
2.8.2.2. Optimizing the IP Core Simulation With the Testbenches
2.8.2.3. Optimization in the 40GBASE-KR4 Testbench
2.8.2.4. Simulating with the Modelsim Simulator
2.8.2.5. Simulating with the NCSim Simulator
2.8.2.6. Simulating with the VCS Simulator
2.8.2.7. Testbench Output Example
3.2.1. LL 40GbE IP Core TX Datapath
3.2.2. LL 40GbE IP Core TX Data Bus Interfaces
3.2.3. LL 40GbE IP Core RX Datapath
3.2.4. LL 40GbE IP Core RX Data Bus Interfaces
3.2.5. External Reconfiguration Controller
3.2.6. External Transceiver PLL
3.2.7. External TX MAC PLL
3.2.8. Congestion and Flow Control Using Pause Frames
3.2.9. Pause Control and Generation Interface
3.2.10. Pause Control Frame Filtering
3.2.11. Link Fault Signaling Interface
3.2.12. Statistics Counters Interface
3.2.13. 1588 Precision Time Protocol Interfaces
3.2.14. PHY Status Interface
3.2.15. Transceiver PHY Serial Data Interface
3.2.16. Low Latency 40GBASE-KR4 IP Core Variations
3.2.17. Control and Status Interface
3.2.18. Arria 10 Transceiver Reconfiguration Interface
3.2.19. Clocks
3.2.20. Resets
3.2.2.1. LL 40GbE IP Core User Interface Data Bus
3.2.2.2. LL 40GbE IP Core TX Data Bus with Adapters (Avalon-ST Interface)
3.2.2.3. LL 40GbE IP Core TX Data Bus Without Adapters (Custom Streaming Interface)
3.2.2.4. Bus Quantization Effects With Adapters
3.2.2.5. User Interface to Ethernet Transmission
3.2.3.1. LL 40GbE IP Core RX Filtering
3.2.3.2. LL 40GbE IP Core Preamble Processing
3.2.3.3. IP Core Strict SFD Checking
3.2.3.4. LL 40GbE IP Core FCS (CRC-32) Removal
3.2.3.5. LL 40GbE IP Core CRC Checking
3.2.3.6. LL 40GbE IP Core Malformed Packet Handling
3.2.3.7. RX CRC Forwarding
3.2.3.8. Inter-Packet Gap
3.2.3.9. Pause Ignore
3.2.3.10. Control Frame Identification
2.8.1. Testbench Behavior
The non-40GBASE-KR4 testbenches send traffic through the IP core in transmit-to-receive loopback mode, exercising the transmit side and receive side of the IP core in the same data flow. These testbenches send traffic to allow the Ethernet lanes to lock, and then send packets to the transmit client data interface and check the data as it returns through the receive client data interface.
The 40GBASE-KR4 testbench sends traffic through the two IP cores in each direction, exercising the receive and transmit sides of both IP cores. This testbench exercises auto-negotiation and link training, and then sends and checks packets in data mode.
Figure 8. LL 40GbE non-40GBASE-KR4 IP Core Testbench The top-level testbench file consists of a simple packet generator and checker and one IP core in a loopback configuration.
Figure 9. 40GBASE-KR4 LL 40GbE IP Core TestbenchTo support the simulation of auto-negotiation, the testbench for 40GBASE-KR4 variations uses two instances of the IP core instead of configuring the IP core in loopback mode. For each IP core there is a packet generator to send traffic on the TX side of the IP core and a packet checker to check the packets it receives from the other IP core. The two IP cores communicate with each other through their Ethernet link, in which the testbench injects random skew. The 40GBASE-KR4 testbench connects each IP core to a transceiver TX PLL, and exercises auto-negotiation, link training, and data mode.
Figure 10. Typical LL 40GbE Traffic on the Avalon-ST InterfaceShows typical traffic from the simulation testbench created using the run_vsim.do script in ModelSim. In Stratix V variations the script is found in <instance_name> _example_design/alt_eth_ultra/example_testbench/run_vsim.do and in Arria 10 variations the script is found in <example_design_directory> /example_testbench/run_vsim.do.
Note: Client logic must maintain the l4_tx_valid signal asserted while asserting SOP, through the assertion of EOP. Client logic should not pull this signal low during a packet transmission.
The markers in the figure show the following sequence of events:
- At marker 1, the application asserts l4_tx_startofpacket, indicating the beginning of a TX packet.
- At marker 2, the application asserts l4_tx_endofpacket, indicating the end of the TX packet. The value on l4_tx_empty[4:0] indicates that the 2 least significant bytes of the last data cycle are empty.
- At marker 3, the IP core asserts l4_rx_startofpacket, indicating the beginning of an RX packet. A second transfer has already started on the TX bus.
- At marker 4, the 40GbE IP core deasserts l4_rx_valid, indicating that the IP core does not have new valid data to send to the client on l4_rx_data[255:0]. l4_rx_data[255:0] remains unchanged for a second cycle, but because the l4_rx_valid signal is deasserted, the client should ignore the value on the RX signals.
- A marker 5, the 40GbE IP core asserts l4_rx_valid, indicating that it has valid data to send to the client on l4_rx_data[255:0].
- At marker 6, the 40GbE IP core deasserts l4_rx_valid, indicating that it does not have new valid data to send to the client on l4_rx_data[255:0]. l4_rx_data[255:0] remains unchanged for a second cycle.
- At marker 7, the 40GbE IP core asserts l4_rx_valid, indicating that it has valid data to send to the client on l4_rx_data[255:0].
- At marker 8, the 40GbE IP core deasserts l4_rx_valid, indicating that the 40GbE IP core does not have new valid data to send to the client on l4_rx_data[255:0]. l4_rx_data[255:0] remains unchanged for a second cycle.
- At marker 9, the IP core asserts l4_rx_endofpacket, indicating the end of the RX packet. l4_rx_empty[4:0] has a value of 0x1D, indicating that 29 least significant bytes of the last cycle of the RX packet empty.
Note: The ready latency on the Avalon-ST TX client interface is 0.
Related Information