LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Large Increase in BRAM Usage for same WDP FFT settings from LabVIEW FPGA 2017 to 2019

Solved!
Go to solution

While updating FPGA VIs from LV 2017 to LV 2019 for my customers' multi-year projects, I have run into a trouble in that LV FPGA WDP FFT IP consumes much larger amount of Block RAM in Vivado 2017.02 than it does in Vivado 2015.04, for exact the same settings.  

 

The setting is as shown in the picture below.  

01.png

  • FFT Length: 65536
  • Input Data: 2 Samples Per Cycle (signed,18, 18 FXP)
  • Goal: Accuracy
  • Clock Rate: 128MHz

Just placing the WDP FFT with the above settings and connected its input and output, the FPGA VI is compiled on LabVIEW 2017 (Vivado 2015.4) and LabVIEW 2019 (Vivado 2017.2).  FPGA is xc7k410t (Hardware is NI-7935R) The compilation results are as shown below.  

 

On LV 2017 (Vivado 2015.4), total amount of Block RAM used is 540 out of 795 (67.9%).

02.png

 

On LV 2019 (Vivado 2017.2), total amount of Block RAM used is 668 out of 795 (84.0%).

03.png

This is a significant increase in Block RAM usage for the same design.  This increase of Block RAM usage for WDP FFT leads top-level design to shortage in Block RAM, and FPGA VIs generate compilation errors on LabVIEW 2019.  

 

Is this something officially recognized by NI?  Regardless it is or not, is there any workaround for this circumstance?  I have multiple customers's projects where WDP FFTs are used.  The amount of increase in BRAM usage for WDP FFT is significant and cannot be ignored for most of the users of WDP FFT. 

 

I come up with some relatively easy workarounds for this situation, such as

  • use bitfile compiled on 2017 for 2019
  • use multiple instances of Xilinx LogiCore FFT IP and make them work in parallel

but ideally WDP FFT should consume the same amount of Block RAM both versions in Vivado compilation tool.  

 

Please help us.  

 

 

Osamu Fujioka
TRIONIX Inc.

CLED/CLA
LabVIEW FPGA and Software Designed Instrument Expert

0 Kudos
Message 1 of 7
(2,435 Views)

In cases like this I would recommend checking the Xilinx IPCore version int he configuration dialog and searching for topics on that on the Xilinx web site.  Sometimes that's the only way (like the CIC filter change between LV 2015 and 2019) where the interface changed completely.

0 Kudos
Message 2 of 7
(2,349 Views)

Hi Intaris, thanks for the comment.  What I am having a trouble is not the one of Xilinx IP, but the one on LabVIEW FPGA (https://zone.ni.com/reference/en-XX/help/371599P-01/lvfpga/fpga_fft/).  I feel you in that we always have some pains to update interface with the Xilinx IP whenever their versions are updated by Xilinx, especially when interfaces were integrated to AXI4-stream.    

0 Kudos
Message 3 of 7
(2,332 Views)

Ah OK. Sorry for that. I don't do FFT, so no experience of that here.

 

Have you compiled an empty (not really empty, but practically empty) VI in both LV versions?

 

Maybe it's not the FFT but something in the background of the FPGA code.

0 Kudos
Message 4 of 7
(2,321 Views)
Solution
Accepted by topic author UMASO

CAR has been filed and its fix is planned to be 2020.  

Message 5 of 7
(2,195 Views)

Does that BRAM issue fixed in 2020?

I noticed NI switched to Vivado 2019.1, does that help?

0 Kudos
Message 6 of 7
(2,048 Views)

Hi, thanks for the follow up.  NI support recently updated the status and it has been fixed in LabVIEW 2020.  

0 Kudos
Message 7 of 7
(2,030 Views)