GeneSys2 board with NI Labview

[EngineerHW]

We have implemented Xilinx Tri-Mode Ethernet IP in the Digilent GeneSys2 board. We have built our own wrapper with some of the Xilinx supplied example codes. We encounter some issues when running with the NI Labview:

System: Windows 10, LabVIEW 2019. VISA Timeout is 2000ms.
Devices are Digilent Genesys2 boards. Using Xilinx Tri Mode Ethernet IP.
TCPIP0::169.254.20.20::7::SOCKET, and/or TCPIP0::169.254.20.30::7::SOCKET. Troubleshooting using a single Digilent Genesys2 board.
•    Devices will operate for minutes or hours, then will Timeout on Read. This leaves unread data in the Genesys2 buffer.
The unread buffer data will offset all subsequent Read data. Board must be power cycled or Boot from Memory and close the Labview application and restart to recover.
Sometimes after a Timeout, the Genesys2 will also fail to respond to ping.

Process:
                VISA Open, Ethernet
                Loop()

* Also, the Labview applications will fail to connect to the hardware. The only way to re-connect is by re-programming the FPGA and re-starting the LabView. It can run for minutes and then in the middle of the test it could loose connection after a few minutes.

* On the earlier versions of WIN 10 STE (Windows 10 v 1809), the board can run for 10 hours without getting the timeout. The problem is exasperated with newer versions of Windows. 

The attached file is a depiction of how are test is being performed.

Any thoughts or recommendations are greatly appreciated.

Test_Scenario.docx

[zygot]

Your description of your setup makes it seem so simple. The reality is that there's a lot of layers of software happening on both sides of the Ethernet connection. You understand this as you suspect that the version Win10 affects reliability.

The quickest way to solve very complex systems is to simplify the problem and establish some level of confidence in the basic parts. Is it an issue with the FPGA hardware, the switch, Win10, or a combination?

One nice thing about an Ethernet client on an FPGA platform like the Genesys2 is that you can instrument the design. If a board expects to send or receive a packet every 500 ms or so then you can detect a failure of that happening and query the Ethernet MAC or PHY for statistics and possible fault conditions. Rx and Tx PHY errors can be detected outside of your Microblaze system. Faced with such a problem I would certainly want to know if the Ethernet physical layer was robust over a 24 hour period before trying to investigate other causes.

One simplification of your setup would be to remove the switch and just work with 1 Genesis2 board to see what happens.

You could also load the Genesys2 boards with an application that just echos incoming packets and create a custom test application that sends out packets and checks that a matching packet is returned.

Timing for the Genesis2 Ethernet PHY is pretty straight-forward. I've never had to resort to IDELAY unlike other platforms that I've worked with. Still, it's not impossible that timing could be a problem over time; not likely though unless the boards are in a stressful environment.

It's not unreasonable to consider whether there might be some sort of electrical power event that might be causing an issue. This could be handled by various means.

Intermittent failures are difficult to debug even for a simple system; so try and remove potential suspects as best you can.

Perhaps, everything I've mentioned is obvious.. perhaps helpful. It's unlikely that anyone reading this post will have a similar setup. No one really wants to embark on a whole new project to work out issues on the one that's needed, but sometimes this is the quickest way to do it. Edited April 15, 2022 by zygot