4
\$\begingroup\$

I am working with some NetFPGA-SUME boards and I have an issue that is bothering me. This board contains a Xilinx Virtex-7 690T FPGA, a part that loads a configuration file into internal configuration RAM.

When the FPGA loads the configuration file, the FPGA works all right, but when I leave the board turned on for a while (let's say, a whole night) and use the board, the FPGA seems to lose its configuration and I have to reload the configuration file and restart the computer.

Example: I program the FPGA with a NIC design, I ping other machine and it sends the message. But when I come back the following day and I ping the same machine, it is not send by the NIC.

I don't know if it is a normal behavior of an FPGA. Is it possible that I forgot to configure something on the board? I don't thing the FPGA is defective, as I tested it on other NetFPGA-SUME boards and found the same problem.

Has anybody any insight in what could be happening?

Thank you

Edit: as some people talked about it in the comments and answers, I have also tried to load the bitfile from one of the flash files the board has. The result is the same, and I have to turn off the system so the bitfile is loaded again from flash.

Edit 2: due to one of the comments, I add this piece of information. I have tested the boards with two different power supplies and hosts, with the same exact result.

\$\endgroup\$
16
  • 3
    \$\begingroup\$ Unstable power? \$\endgroup\$
    – Eugene Sh.
    Commented Oct 29, 2021 at 17:03
  • \$\begingroup\$ Maybe the FPGA bitstream was never stored in EEPROM config memory? Xilinx Virtex-7 FPGA chip itself does not store its own configuration. At power-on, depending on its Configuration Mode Pins, either the FPGA reads the bitstream from an external memory (probably a N25Q128A), or the FPGA waits for some other device to send it a bitstream through JTAG. See Xilinx Virtex-7 FPGA Configuration UG470, chapter 2. \$\endgroup\$
    – MarkU
    Commented Oct 29, 2021 at 17:21
  • \$\begingroup\$ @EugeneSh. It is connected as indicated in the reference manual. It is connected to the host PC via PCIe and a 2x4 connector to the power supply. \$\endgroup\$
    – anmomu92
    Commented Oct 29, 2021 at 17:30
  • \$\begingroup\$ @MarkU I forgot to mention that (I'll edit the question to include it). I also tried to load the bitstream from one of the flash memories on the board, but the issue persists. Anyways, the idea is to leave the board plugged in for long periods of time \$\endgroup\$
    – anmomu92
    Commented Oct 29, 2021 at 17:34
  • \$\begingroup\$ @anmomu I'm assuming you are using the same power supply for all the boards you tried. Together with the board design itself, that seems to be your common factors. I don't imagine that your long-delayed next communication attempt (ping) would have some new reason to behave differently just because of the stretched out time delay between pings. Though that seems to be the only remaining question -- is there something about the time duration between pings that lead to different behaviors. Do you see any other factors to consider? \$\endgroup\$
    – jonk
    Commented Oct 29, 2021 at 17:37

1 Answer 1

Reset to default
1
\$\begingroup\$

This sounds like unstable power supply, but it could be something else, eg a glitch on the reset pin if the chip has one.

FPGA devices usually do not have non-volatile memory for the bitstream. Note that some do have it however. When you program it via PC the program goes directly to RAM.

This means that program will run until power cycle or some other reset.

In order to retain the program after reset, you would normally add an external memory (EEPROM or Flash) that is compatible with the FPGA and put program there.

In the datasheet you could probably find some suggestions for the external memory. The FPGA loads data from external memory automatically on power-up, that is why it needs to be “compatible”.

\$\endgroup\$
6
  • \$\begingroup\$ Yes, I tried to load it from an on-board flash memory, but the issue persists. I'll check what you said about the power cycle or other resets. As I don't know much about electricity/electronics, I'm quite lost in that topic. Thank you \$\endgroup\$
    – anmomu92
    Commented Oct 29, 2021 at 17:36
  • \$\begingroup\$ Are you sure the program gets loaded from the Flash? Have you tested it? Even if you confirm that program gets loaded, you need to debug why does it reset. If you have an oscilloscope, you could monitor the supply rail and set a single trigger. Monitor also a (dummy) digital output, in that way you can see what happens with FPGA when supply voltage dips. \$\endgroup\$
    – Marko Gulin
    Commented Oct 29, 2021 at 17:38
  • \$\begingroup\$ Yes, I turn off the system, turn it on again, and I can ping between hosts. \$\endgroup\$
    – anmomu92
    Commented Oct 29, 2021 at 17:42
  • \$\begingroup\$ Are you sure that program gets erased? Is it possible that you have a bug in your program? Eg a communication driver stucks after some time.. \$\endgroup\$
    – Marko Gulin
    Commented Oct 29, 2021 at 17:44
  • \$\begingroup\$ That the program gets erased I cannot confirm (I don't know how, yet). I have also thought that maybe the problem is in the driver. I have used the default ones provided (sume_riffa) by the open source project I'm working with, so I haven't touched the driver. \$\endgroup\$
    – anmomu92
    Commented Oct 29, 2021 at 17:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.