Examples and IP for Software-Designed Instruments and NI FlexRIO

cancel
Showing results for 
Search instead for 
Did you mean: 

Tri-Mode (10M/100M/1G) Ethernet on the NI 7932R/7935R/PXIe-6592R

Overview

 

The example projects attached to this document provide Tri-Mode (10M/100M/1G) Ethernet connectivity on the SFP+ ports of the NI PXIe-6592R High Speed Serial Instrument, and the NI 7932R/7935R Controller for FlexRIO. The example projects support the 1000BASE-X and the SGMII standards on the SFP connectors, with 10M/100M/1000M speeds in case of SGMII. Connecting to an Ethernet network requires a media-specific SFP transceiver module installed in the SFP connector, supporting the 1000BASE-X and/or the SGMII standard on the SFP connector.

 

History

 

2021-07-20: Fixed the data reception errors on Port 1 and Port 3, caused by the improper clocking of the IP cores in the Ethernet CLIP.
2020-08-27: Some false path constraints were missing from the Ethernet CLIP, causing the FPGA compilation to fail timing when compiling with LV2020. The attached example projects were updated to include these constraints.

 

Hardware and Software Requirements

 

Hardware

  • The following modules are supported:
    • NI PXIe-6592R
    • NI 7932R
    • NI 7935R

 

Software

  • LabVIEW 2016 SP1 (32-bit)
  • LabVIEW FPGA 2016
  • NI PXIe-6592R: NI LabVIEW 2016 Instrument Design Libraries for High Speed Serial Instruments 16.1
  • NI 7932R/7935R: FlexRIO Support 16.1

 

Implementation

 

The example projects use a custom FPGA CLIP. The CLIP implements the Ethernet MAC and the interface between the MAC and the SFP connector using the Xilinx Tri-Mode Ethernet MAC IP and the Xilinx Ethernet 1000BASE-X PCS/PMA or SGMII IP (refer to the CLIP top-level vhdl file comments for the IP versions used, and the configuration options used for these IPs). The projects also contain logic implemented on the FPGA for accessing the installed SFP transceiver modules through the SFP Serial ID interface (described in the SFP MSA Appendix B4). The Serial ID interface can be used to identify the installed transceiver module, and depending on the transceiver module, to configure/monitor ASICs located on the transceiver module, such as the physical layer IC (PHY) translating the data between the SFP connector and the optical or copper cable (the example projects demonstrate the configuration of the Marvell 88E1111 PHY in case it is accessible through the SFP Serial ID interface at the device address 0xAC).

 

The projects also include a host support library (TriModeEthernet support.lvlib) providing VIs for initializing, configuring and monitoring the status of the ports, accessing the registers of the IPs used in the CLIP, and accessing the SFP Serial ID interface. For more information refer to the context help of the library and the library VIs.


The projects are created from the 1G and 10G Ethernet sample projects shipping with the NI LabVIEW 2016 Instrument Design Libraries for High Speed Serial Instruments 16.1, therefore the project structure is almost the same.

There are three top-level FPGA VIs:

  • TriModeEthernet_FPGA.vi: Implements transmit/receive on all ports of the device.
  • FPGA Top - Packet RX Only.vi: Implements only the packet reception on Port 0 of the device.
  • FPGA Top - Packet TX Only.vi: Implements only the packet transmission on Port 0 of the device.

There are five top-level host VIs:

  • Getting Started (Loopback Test).vi: Loopback test using the FPGA personality provided by the TriModeEthernet_FPGA.vi top-level FPGA VI.
  • Getting Started (RX on FPGA).vi: Packet reception only using the FPGA personality provided by the TriModeEthernet_FPGA.vi top-level FPGA VI.
  • Getting Started (TX on FPGA).vi: Packet transmission only using the FPGA personality provided by the TriModeEthernet_FPGA.vi top-level FPGA VI.
  • Packet TX Only.vi: Packet transmission only using the FPGA personality provided by the FPGA Top - Packet TX Only.vi top-level FPGA VI.
  • Packet RX Only.vi: Packet reception only using the FPGA personality provided by the FPGA Top - Packet RX Only.vi top-level FPGA VI.

 

Additional Information or References

 

The examples were tested using the following SFP transceiver modules:

SFP transceiver module Notes
MikroTik S-RJ01 Copper, supports SGMII with auto-negotiation only.
Intellinet Gigabit RJ45 Copper SFP Transceiver Module P/N: 523882 Copper, uses the Marvell 88E1111 PHY, 1000BASE-X/SGMII with or without auto-negotiation is supported.
FINISAR FCLF8522P2BTL Copper, uses the Marvell 88E1111 PHY, 1000BASE-X/SGMII with or without auto-negotiation is supported.
Extralink EX1GRJ45 Copper, uses the Marvell 88E1111 PHY, 1000BASE-X/SGMII with or without auto-negotiation is supported.

 

Comments
muhammad.kamran.ayub
Member
Member
on

@TDavid,

 

To support a customer who needs 100MbE, I was trying to compile the IP on LV 2020. It seems like the VHDL code is having timing violations. Though all the clock rates are met, despite this, on one path, there is always a timing violation. I already had 5 parallel compiles and none was successful.

 

Attached are the related screenshots and Xilinx logs. Can you advise?

 

Five Compilations in parallel, all failed with same final timing:

 

1.PNG

This is what investigate timing violation windows show:

2.PNG

 

Double Clicking timing violation:

 

3.PNG

 

4.PNG

-Kamran

Best Regards,
________________________________________
Muhammad Kamran Ayub, M.Sc.
Senior Technical Support Engineer | CTD | CLA
UK & Ireland

 

 

 

 

TDavid1
Member
Member
on

Hi Kamran,

 

Thank you for the feedback! Some false path constraints were missing from the Ethernet CLIP that is why the FPGA compilation was unable to meet timing when compiling with LV2020. I've updated the examples to include these missing constraints, just download again the projects, they should compile fine now!

Regards,

David

muhammad.kamran.ayub
Member
Member
on

Thanks David,

 

I was able to compile 6592R example for LV 2020 and LV 2019. This is indeed massive help. A little trouble was: missing CLIP XML file. For anyone following this example, here are the steps to get over error message of missing CLIP file when building bitfile:


>Right click FPGA Target>>Properties>>Component Level-IP>>Click '+'>>Navigate to downloaded folder '/CLIP/<TrimodeEthernet_6592R_2x2.xml'

>Remove the missing file with a similar name as above.

 

Thanks,

Best Regards,

Kamran
________________________________________
Muhammad Kamran Ayub, M.Sc.
Senior Technical Support Engineer | CTD | CLA
UK & Ireland

AndyJD
Member
Member
on

Using Intellinet SFP transceivers (P/N: 523882) plugged into a 6592 I've been successful in getting this Tri-Mode example working, thank you.

Using the Tx Only, Rx Only, or wrap examples I can use a Windows UDP listener and see the expected traffic, as well as see expected data at the FPGA receiver end from a Windows UDP transmitter on the network.

 

I need to strip out all UDP header and IPV4 header information, so that I have bare 802.3 Ethernet frames being transmitted. These frames will be going between 2 devices on a 'single wire' network (one end the 6592) and source and destination MAC addresses are to be hardwired. The Ethernet Frame 'Type' will contain the size for the raw payload, and there will be no fragmentation meaning all messages will fit within a 1500 MTU.

I am struggling with just stripping out UDP and IP header information, and 'UDP Fragmenter' etc. and getting transmit working at all. I am using the same Simulated Source data from the Tx Only example to fill the 64kB target scoped FIFO, which my transmitter SCTL is using.

 

I have successfully updated the receiver SCTL to remove all UDP/IP filtering so that raw packets are received ok.

 

Does the IP contained in the CLIP with this example support what I am trying to do with simple raw Ethernet Frames, or do I need do do some VHDL work here please?

 

Thanks.

TDavid1
Member
Member
on

Hi AndyJD,

 

The receivers in the example can return the raw Ethernet data stream instead of the UDP payload. Just set the "Port N RAW Mode" (where N can be 0, 1, 2 or 3) FPGA control to true when working with the "TriModeEthernet_FPGA.vi", or set the "tap point" control to "Raw" when working with the "FPGA Top - Packet RX Only.vi".

 

The example requires modification if you want to have control over the transmitted Ethernet frames instead of the UDP payload. When working with the "TriModeEthernet_FPGA.vi" FPGA VI, you have to change the "Example TX.vi" FPGA sub-VI: this sub-VI uses the "Write IPv4 UDP Packets.vi" (look for the #4 on the block diagram) to create the Ethernet frames containing the UDP packets. You have to replace the "Write IPv4 UDP Packets.vi" VI with the "Write Frame Packets.vi" (these VIs are part of the FPGA Network API, located under instr.lib\_niInstr\Network\API\v1\FPGA). When working with the "FPGA Top - Packet TX Only.vi" FPGA VI, replace the "UDP Tx State Machine.vi" on the block diagram with the "Write Frame Packets.vi".

 

Hope this helps!

AndyJD
Member
Member
on

Thank you very much. Yes I have managed now to strip out all UDP header and filtering in my application and transmitting/receiving between ports of the PXIe-6592R.

 

Another question please is physical transmission bit rates.

In the Xilinx documentation for the 'Xilinx Tri-Mode Ethernet MAC IP' is states for tx_mac_aclk : "Clock for the transmission of data on the physical interface. 312.5 MHz at 2.5 Gb/s, 125 MHz at 1 Gb/s, 25 MHz at 100 Mb/s, and 2.5 MHz at 10 Mb/s."

 

tx_mac01_aclk and tx_mac23_aclk from the CLIP are both 125 MHz

These 125Mhz clocks are wired to the SCTLs within the example code, so I am assuming physical  speed is set to 1 Gb/s?

 

Would I need to create derived 25Mhz clocks in my FPGA project and use these for the SCTLs, or update the clock definitions to 25Mhz in the CLIP wizard to achieve 100Mb/s links ?

 

TDavid1
Member
Member
on

Hi AndyJD, the SFP transceiver module decides the link speed on the wire, there is no need to change the CLIP or the clocking of the CLIP. If the link partner is using auto-negotiation, then configure the SFP transceiver module to not advertise 1000Base-T, while if the link partner is not using auto-negotiation, then configure the SFP transceiver module to use 100Mb/s on the wire. Since you are using a Marvell 88E1111 based SFP transceiver module, you can achieve this easily by editing the TriModeEthernet support.lvlib:SubVIs\SFP Module PHY Configuration (no lock).vi. Change the register sequence used in the SGMII with auto-negotiation mode, there are comments in the VI describing what to use for 10BASE-T, 10/100BASE-T or 10/100/1000BASE-T advertising, and/or change the register sequence used when the auto-negotiation is disabled (when the Cu register bank is selected write the PHY Control register at 0x00 by 0xA100 instead of 0x8140).

AndyJD
Member
Member
on

TDavid1,

Thank you very much again for your help.

 

Andy

TDavid1
Member
Member
on

My comment about forcing the 100Mb/s link speed while not using auto-negotiation was not correct. It seems that in case of the Marvell 88E1111 to use 100Mb/s on the wire it is necessary to program the auto-negotiation advertisement registers just like in the auto-negotiation case even if the auto-negotiation is disabled. To use 100Mb/s without auto-negotiation use the SGMII interface and disable the auto-negotiation in the example. Modify the "SFP Module PHY Configuration (no lock).vi" to initialize the Marvell 88E1111 with the following configuration sequence:

TDavid1_0-1626805814623.png

Also make sure to configure the Xilinx TEMAC core for 100Mb/s MAC speed. When the auto-negotiation is disabled the example assumes 1Gb/s speed between the SFP transceiver module and the FPGA, this should be changed to 100Mb/s. This can be achieved by modifying the "Update Link State.vi", by changing the default link speed constant to 1 (from 2) for the auto-negotiation disabled case:

TDavid1_1-1626805872620.png

 

TDavid1
Member
Member
on

I have updated the attached examples to fix the data reception errors on Port 1 and Port 3. The cause was the improper clocking of the IP cores in the Ethernet CLIP, this is now fixed.

Cut1
Member
Member
on

For your update on 7/20/21, did any of the VIs change or was it just a CLIP update?

TDavid1
Member
Member
on

Hi Cut1, only the CLIP was updated. But for these changes to take effect, the FPGA bitfiles had to be recompiled and the top-level host VIs had to be updated as well with the new bitfiles.

JonasM
Active Participant
Active Participant
on

Hi TDavid,

 

I've bought two FINISAR FCLF8522P2BTL and tested the project for loopback. My results varied a bit from yours, I list my results below.

 

10/100/1000Base-X only auto-negotiation disabled

SGMII auto-negotiation enabled and disabled

 

In your table you had it working with auto-negotiation for Base-X. Do you have any idea what can go wrong for me?

 

Note: I used the loopback VI to test communication between port 0 and 1 and tested to swap which one was RX and TX.

Best Regards
Jonas Mäki
Systems Developer
Novator Solutions
Contributors