Issue with updating ARIA 10 PCIe core to 20_1_1

Regenerating the PCIe core from scratch didn't help. I still get random results. We have done many builds, due to design enhancements and bugs, in Quartus 17.1. We have never had PCIe issues on any of our builds.

To summarize where we are right now:

All three of the Quartus 17.1 Gen 3 x 8 designs moved to Quartus 22.3 build fine and work fine on our hardware.

Two Quartus 17.1 Gen 2 x 8 designs moved to Quartus 22.3 build fine but fail to run on our hardware.

I thought I had some success with Quartus 19.2 with PCIe core version 19_1 but a slight change in the design caused failures with PCIe DMA.

Thanks,

Mike

Hi Wincent.

The failure varies build to build. I am looking at the most obvious error which is the FPGA enumerates okay in the PCIe but all host to FPGA accesses return 0xffffffff. What I just noticed in the lab is the LEDs seem to indicate a good portion of the FPGA is not working. It programmed and loaded okay but more than just PCIe appears to be broken.

Other failures include lockups, DMA (device to host failures), and host to FPGA access returning wrong data (other than 0xffffffff).

I performed a DSE run and out of 11 builds:

3 - work okay

4 - experience the 0xfffffff problem

4 - have other issues as listed above.

I did a DSE run on our other design which is Gen 3 x 8 and targets the exact same board. All 11 builds work fine.

I will continue to look at one of failing builds.

Thanks,

Mike

Hi Wei.

On the Gen 2 x 8 design 7 out of 11 builds fail to run correctly on the hardware.

On the Gen 3 x 8 design all 11 builds run correctly on the hardware.

Just to reiterate the same board was used to test all builds.

This is our own hardware design so it doesn't have a dip switch. I am not sure what you want me to check.

Thanks,

Mike

Hi. Can you explain further about the dip switch? I am sorry but I have no idea what you are referring to.

Thanks,

Mike

I don't have a development board. This design targets our own custom hardware.

1. We are not migrating a design from Gen 2 x8 to Gen 3 x 8. By the way that works fine but is not part of this discussion. I can move freely from Gen 2 x 8 with a 125 mhz 256 bit internal bus to a Gen 3 x 8 with a 250 mhz 256 bit bus. That is not the issue here. This issue is when we migrated a Gen 2 x 8 design from Quartus 17.1 to Quartus 22.3 it stopped compiling correctly. A Gen 3 x 8 design migrated from 17.1 to 22.2 works fine.

2. That could be an option but what is the point in using 6 year old software on a design that has a production part on it.

3. Sigh, that is what this entire thread is about. We recomplied a design in the newest version of Quartus and it stopped compiling reliably.

Hi Wincent. I did another scrub of the differences between the designs, specifically the .qsf and source files. Nothing stood out. I then compared the .sdc files and found a flase path constraint in the Gen 2 x 8 design that was not present in the Gen 3 x 8 design. Once I removed the constraint, which was a bit heavy handed, the design runs fine on the hardware.

Thanks for your assistance,

Mike