FPGA to SDRAM crash only after power boot

RocketBoards General
1

Hey all,

I’m posting here because I’m experiencing something really funky on an SoC (Cyclone V HPS + FPGA) running Linux on a DE10 Nano board. We are offloading some processing bits and pieces off to the FPGA, which pretty much freed up a complete ARM core and manages the task well. Results are consistent with timing and simulation

The approach to use the FPGA is:

  • Let the OS copy the incoming data to a specific memory space and specify the length
  • Signal the FPGA to start processing by setting a register start bit
  • Read a register every couple of ms to wait for the ready bit to be set.

The above works. The data is copied by the OS and the FPGA uses the SDRAM FPGA-to-HPS interface, taking care of wait times and such. I know for a fact the data processed is correct because I have a checksum that I can check against, and I can compare both numpy and FPGA processes, the result is the same. The SDRAM FPGA-to-HPS is configures as read/write, even though the FPGA only reads from it.

But…

If I boot the system by taking power away, the process doesn’t start after calling the script, not only that, it freezes the whole Linux OS without warning. SSH is lost, blinkys are lost, but two blinkys generated by the FPGA fabric still work. A power reboot later, same effect. No matter how often I power-boot, the whole OS crashes mercilessly after setting the “enable” bit, which is effectively reading with FPGA from SDRAM

Now, if I do a power boot and then I do a soft boot using the “reboot” command, the process starts and finishes and runs without issues. I have only tested it a few minutes at a time, long term tests will come later. I can “reboot” as often as I want and the script starts after setting the enable bit. To be clear, I do not run or set anything between hard power-on and reboot.

I checked the SDRAM register settings for before and after, they are the same. I’m guessing there must be something in the FPGA code that is initialised wrong, or tries to write something in memory, and kills it? But then after a reboot all is well?

If you’ve experienced something like that and remember more or less what you’ve done, I’d truly appreciate your comments.

Any ideas or additional questions are welcome. I can post some snippets of code and part of the IP Designer config if required.

Cheers,

Alberto

2

It’s solved! It took me a while, sifting through old and outdated documents, but eventually it clicked, in fact, there is a perfectly good instruction here which I had not gotten to yet.

From what I understood, the RBF design is loaded, and then the bridge needs to be enabled explicitly. Not only that, the applycfg bit of the staticcfg register needed to be set after enabling the bridges.

In the end, it was an additional line in the bootscript, and now it works all the time, both after cold or warm boots.

By the way, the “bridge_enable_handoff” command which is still available as solution on the Intel website is outdated, I think. I could not find anything related to that on uboot.

I hope this helps someone.

Cheers,

Alberto