LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Export for Vivado problem

Hi all,

 

I am having issues with exported LabVIEW FPGA projects for the PXIe-5764. After successfully exporting to Vivado, I run a build and two pins related to the DRAM consistently fail to place. This causes the build to fail the DRC check after implementation and so I cannot generate a bitstream, despite meeting timing. This is using LabVIEW 2017, FlexRIO drivers 18.7, and Vivado 2015.4 on Windows 7 (SP1), with a fresh unaltered copy of the NI example "Getting Started 5764" project demonstrating the problem.

 

I have attached the Vivado log files. The specific errors are around "dr0DramTestMode_OBUF_inst" and "dr1DramTestMode_OBUF_inst". It looks like the error relates to some of the constraints: there are a lot of "set property PACKAGE_PIN" related to the DRAM, and for "dr0DramTestMode" it refuses to set this property and throws some critical warnings in the implementation. This leads to the later failure.

 

The project does generate a bitstream successfully when built from LabVIEW, so it seems to be specifically the export which must be causing problems.

 

Any ideas how to get this working? Obviously the relevant files are encrypted, so I can't have a full look at what is going on.

Download All
0 Kudos
Message 1 of 4
(2,411 Views)

This is certainly a strange situation, the compilation kicked off from LV FPGA should be very similar to generating the bitstream from the Vivado export. A couple of things come to mind to try and narrow things down/sanity check.

 

First, it looks like this is the case but to be certain, are you opening up the exact Vivado instance installed by LV FPGA when you do the project export? From the logs I can see all the patches applied which makes me think it is right, but just want to be 100% certain.

 

After you do the project export, if you are making any changes at all in Vivado just skip those and try to generate a completely unchanged export. To further test this, try generating a project export from a completely blank LV FPGA diagram and see if that can compile. Not clear yet if the DRAM pins that are the problem are tied to diagram code or if they're entirely in the CLIP.

 

Last question, for the working compiles from LV FPGA, are those local compiles or are the going to the cloud/a server? If you haven't, test a local compile from LV FPGA and see what happens.

Cassandra Longley
Senior Technical Support Engineer - FlexRIO, High Speed Serial and VRTS
0 Kudos
Message 2 of 4
(2,384 Views)

Hi Cason,

 

I was going for a completely clean example, so the logs I posted match what you suggested. The Vivado instance is the same one used by LV FPGA - I even launched Vivado by right clicking on the project export build spec and selecting launch, just to be sure it hadn't missed a script. I made no changes in Vivado. The working compiles from LV FPGA are local compiles. I've also run Vivado builds on a Windows 10 and a CentOS 6.7 machine and had the same error, if that helps at all.

 

An export of a completely blank FPGA diagram does build in Vivado and generate a bitstream successfully. From the log of this successful build, it looks like it simply hasn't implemented anything DRAM related, as you might expect: "No black box instances found for design checkpoint" for MacallanBank0Dram_ku060.dcp, and the same for Bank 1. The only mentions of dram in the log are along the lines of no nets/cells/pins found, and "dr0DramTestMode" isn't mentioned at all.

 

I actually first ran into this error on my own 5764 project (commercial so can't be posted), which handles the DRAM in the FPGA vi through Memory Method Nodes rather than through the DRAM FIFO vis supplied in the Getting Started 5764 example. I haven't drilled down completely into whether these are the same under the hood, but it does lead me to think that the problem isn't just some strange quirk of the particular FPGA diagram. This other project also exhibited the same behaviour of building fine from LV but not when exported.

 

Thanks for your help.

0 Kudos
Message 3 of 4
(2,359 Views)

Update: I think I may have solved it.

 

In Vivado, I had been running synthesis and implementation in one, and then later clicking generate bitstream. This is visible around line 2335 of the implementation log: Vivado tries to open the routed checkpoint, and throws a handful of warnings about not being able to create certain constraints due to nets not being connected to top level ports. The same warnings show up at the beginning of the implementation log as well, but don't seem to be a problem there.

 

If I reset all runs and just click generate bitstream, so that synthesis, implementation and generate bitstream run one after the other, then Vivado does not have to close and reopen the routed checkpoint, and none of these warnings occur after implementation. It passes DRC with no errors and successfully generates a bitstream. 

 

I don't know why stopping before moving onto the next stage should be a problem - I thought that was the whole idea of checkpoints! So perhaps there is some deeper issue with the constraints. I'll have to run a few more builds to confirm, but this seems to be it.

 

I still have a minor issue on other machines where Vivado fails to find CreateBitfile.bat in the PostGenerateBitfile.tcl script, but this seems reasonably fixable, so with a bit of luck I'll be good to go 🙂 

Message 4 of 4
(2,344 Views)