LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

clean memory of fpga card

Hi:

 

I am trying to compile an FPGA code on a PCI 7833R card but the code cannot compile because the amount of Block RAM it requires is more than what is available. Specifically, in the compilation summary window the number of RAMB16s is 160 out of 96 (overmapped). 

 

I am not sure what is going on because I have compiled this code previously (with trivial changes) with no problem. It was suggested to me to "clean out" my FPGA and try again. I assume this means there is other FPGA code that is taking up space which is why my code in question doesnt have the space to compile, but then again I also thought only one FPGA VI could run at once, which seems to conflict. 

 

Anyways, I am not sure how to "clean" my FPGA card and start with a clean slate which would hopefully allow me to compile my code of interest. I imagine it should be an easy thing to do, but I have been unable to locate any info on this subject.

 

Thanks in advance.

 

B

0 Kudos
Message 1 of 6
(2,445 Views)

I am not sure what "clean out" would mean either. When you download an image to the FPGA, it reprograms the entire chip so there is no problem with other images taking up space. If you have successfully compiled this design in the past as you said and you think the changes really are "minimal" and don't require more memory blocks, you can try forcing a new compile and see if it succeeds. You can do that from the right-click menu of the build specification.

 

If, however, your changes do require more memory than is available, you'll need to refactor your design a bit to use less memory. Also, what version of LabVIEW FPGA are you using?

0 Kudos
Message 2 of 6
(2,443 Views)

Thanks for the reply Dragis. 

 

I tried to recompile like you mentioned but am having the same issue. I am using LV 2010 and FPGA version 10.0.1. 

 

I will use an older version of the software that does work for now, until I can figure something else out. 

 

Thanks for your help.

0 Kudos
Message 3 of 6
(2,432 Views)

Hi Briana,

To chime in real quick, the message you got doesn't make any sense at all.  You can only have one bit file flashed to the FPGA at a time... there isn't a "clean out FPGA memory" option because it isn't a thing.  It doesn't make sense.

 

Anyway, you mentioned you made some changes, and now it won't compile. Jumping to ~50% overmapped is a pretty significant jump. Did you add front panel objects, or a few arrays or anything?  Can you post the code for us to look at?

NukeB | CLD
0 Kudos
Message 4 of 6
(2,399 Views)

@NukeB wrote:

Hi Briana,

 

Anyway, you mentioned you made some changes, and now it won't compile. Jumping to ~50% overmapped is a pretty significant jump. Did you add front panel objects, or a few arrays or anything?  Can you post the code for us to look at?


Front panel objects can take up alot of space on an FPGA.  They take considerably more if they represent more than 32 bits of information on a single control.  An array with 32 booleans on the front panel will take up some space, but an array of 33 booleans, or an array of 2 U32 numerics will take considerably more.

 

Overmapping a little isn't a big deal.  I've seen compilations that start at 120% fit because of the optimization that goes into place.  Of course the compiler will continue to retry to make it fit for several hours until that happens so it may take a while.  I've never seen one greater than 140% fit but I think the threshold is right around here.  You may have been on the bubble before and not known it, and by making the few changes that you did, pushed it over the edge.  I'd recommend going back to what you had and try again.

 

EDIT: And as others have said there is not cleaning out, your FPGA runs one program at a time and the older program is overwritten.

0 Kudos
Message 5 of 6
(2,374 Views)

Are you sure the target you are compiling for is the same as previously?

 

If the hardware target in the project definition changes, then the compilation will assume whose hardware limits to be active meaning that this kind of difference could explain sudden huge overmappings.

 

Shane.

0 Kudos
Message 6 of 6
(2,364 Views)