From 11:00 PM CDT Friday, Nov 8 - 2:30 PM CDT Saturday, Nov 9, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 11:00 PM CDT Friday, Nov 8 - 2:30 PM CDT Saturday, Nov 9, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
12-30-2013 07:21 PM
Hello,
I'm trying to compile a VI on the PXIe-7965R (FPGA). The VI is listed below.
I've tried altering the overall structure to be more efficient, resulting in the VI below.
It uses 2 DSPs and several high throughput blocks. The error I receive is that it uses too much memory to compile (397.3% of the Slice Registers and 248.7% of the Slice LUTs)
I'm not sure if there is an error with regards to the DSP implementation that is causing a large memory pileup.
I'd be happy to elaborate, if necessary.
Thanks,
Richie
12-31-2013 12:53 PM
Hi Richie,
I estimated the resource usage with your code and got nearly identical results as you. From there, I started removing portions of the algorithm and have determined that the DSP48E node is what is causing the large memory usage. I am not very familiar with the Goertzel Algorithm, but one thing I would suggest is reducing the amount of bits you are using for the fixed-point calculations. If you're able to do so, the resource usage should decrease significantly. This is not a hard guideline, but typically a fixed-point number of size X will require X^2 resources (i.e. logic gates) or worse. If you're able to decrease the size of the number, you should be able to recover quite a few of those resources back.
Hope that helps!
Best Regards,
01-07-2014 06:50 PM
Matthew,
There is a recursive nature to the Goertzel Algorithm. If the large memory usage stems from the number of bits I am using for the fixed point calculations, then I think that this would trace back to the DSP48E node since there is a fixed 48-bit width output. There is definitely flexibility with the bit width for the inputs to the DSP48E; but the loop would naturally fixate me back to 48 bits due to the type of the output. I suppose there is no way to alter this?
Many thanks,
Richard
01-08-2014 05:59 PM
Hi Richard,
After some more thought, we find it strange that you are running out of memory with the PXIe-7965R. Is this the error that you are receiving as well?
If that is the error you are receiving, that means that the system that is compiling the code has run out of memory. Are you compiling on a local machine or a remote machine? For the compile machine, what OS is it, is it 32- or 64-bit, and how much RAM does the machine have available?
Regards,
01-09-2014 04:33 PM
Matthew,
The following image is the what I see as a result of the compile.
I have tried this with the local compile worker and a remote compile worker.
The local compile worker is a Windows XP (32 bit) (2002) with 3.17GB of RAM.
The remote compile worker (Xilinx 13.4 & 13.4 w/ 64-bit) is on a Enterprise Linux Client 5.6 (Tikanga) with 7.441GB of RAM.
However, for the remote compile worker, the GPIB error shows after completing the resource estimation process.
Both resource estimation processes have equivalent results, as was the case with your compile.
Thanks,
Richard
01-10-2014 03:41 PM
Hi Richard,
I am communicating with our R&D Department to see if we can determine why compiling this code fails. When I hear back from them, I will post back on here.
Best Regards,
01-28-2014 11:55 AM
Has there been any news regarding this issue?
Thanks,
Will
01-29-2014 04:32 PM
Hi Will,
This slipped my mind - sorry about that. Let me follow up on this with R&D.
Regards,
01-31-2014 09:46 AM
Hi Richard,
The reason you are running out of memory is because your front panel arrays are massive. You may need to either reduce the size of the arrays or consider using an alternate method to store that data such as streaming data via DMA FIFOs or block memory.
Regards,