LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

compile error when using DRAM

I am using the NI PCIe-1473R Framegrabber on Labview 2010 SP1. I would like to do some image processing on the FPGA. I started off with the 10-Tap 8-Bit Camera with DRAM example. I am trying to replace the DRAM FIFO with DRAM circular buffer. I need to be able to address different parts of the image, not simply stream the image, so I can't use it as a FIFO. I created a control that is a cluster with 2 U64 elements to be able to interface with the Pack80To256 CLIP. I changed the properties of the FPGA to access the DRAM banks through Labview FPGA Memories, then added 2 memories (one for each bank) using the 128-bit control described earlier. If I do not connect anything to the output of the DRAM (Memory Retrieve Data function, Data output), the VI builds fine. However, when I connect anything such as an indicator I get an error during compilation.

 

ERROR: Place:836 - Not enough free sites available for the components of the
  following type(s).
     BLOCKRAM    Number of Components 104    Number of Sites 96

Although the symptoms are not exactly the same, they are similar, so I tried using the patch here http://digital.ni.com/public.nsf/allkb/8A46A432EA47D261862577B300779F41 and the one here http://digital.ni.com/public.nsf/allkb/BBD7A87F2ADC2028862577FB005F6B19
But I get the same error.

I am not in front of the development computer right now; I will add the VI and anything else that may be useful to debug this.

0 Kudos
Message 1 of 15
(3,220 Views)

Adding Attachments. I would appreciate quick replies.

 

Thanks

0 Kudos
Message 2 of 15
(3,210 Views)

Hi elsayed03,

From the summary.txt file you posted, the program that doesn't compile requires more DRAM than your FPGA has available.  Realistically, you can try to minimize the amount of block memory you are using and the number of FIFOs you are using, or you may need to do less computation on your FPGA.  Additionally, if you can't optimize your code, you may want to consider moving to a larger FPGA, which it looks like for your application may require moving to a FlexRIO platform.  This will allow you to use an FPGA with more logic gates which will help with your percent utilization.

 

You may also want to consider minimizing the total number of front panel objects you have, and additionally look into optimizing your subVI's as well.  In short, look into decreasing redundancies of front panel objects, and if that doesn't work, it's possible you may want to consider using a larger FPGA.

0 Kudos
Message 3 of 15
(3,174 Views)

Hi Ben,

 

Thanks for replying.. Before I go on, are you a sales man? Great strategy "throw more money at it"!

 

First, I did some research on the issue. "optimize your code" is not very useful... You also seem to ignore the fact that there is one that compiles. The only difference between the compiling version and the non-compiling version is the fact that the DRAM output is connected to an indicator. So it has nothing to do with reducing the amount of block memory, fifo's or less computation. I tried looking for an article that discusses resource usage of front panels, but I couldn't.

Some more information: The first time I got the error, I had the DRAM output ("Data" terminal on the "Retrieve Memory Data" function) I had it connected to a CLIP and another time a subvi. For demonstration purposes, I posted one with simply an indicator. Little did I know that a connection to a CLIP is not much different, in terms of resources, than an front panel object. But if I connect the output to anything else (say I add it to something), it compiles fine. So one more thing to add to this article: http://digital.ni.com/public.nsf/allkb/311C18E2D635FA338625714700664816 is to avoid using external CLIPs / sub-vis. 

 

Once again, thanks for the reply. Your suggestions did not help but I think I've found a way (re-write the CLIP using labview...). If labview comes up with a more efficient way to integrate code, please let me know. Or a way to modularize the code in an efficient manner. If I use sub-vis, they have to have front panel objects to talk to the main vi... more resources there...

0 Kudos
Message 4 of 15
(3,168 Views)

Hi elsayed03,

I'm sorry you didn't find my response in my post or our conversation on the phone yesterday as informative as I meant for it to be.  Let me try to be more clear.

In the VI that you are working with, you appear to be monitoring the data stored in your DRAM banks.  The DRAM is a large memory location that can store a significant amount of data in it.  If this memory was stored on the FPGA fabric (logic gates), it could take up a considerable amount of space and significantly limit what else could be done on the FPGA.  This is the reason that the DRAM is used.  Because you have an indicator attached to the DRAM bank, the FPGA fabric is being forced to store a copy of this value as well.  In short, you are using the DRAM bank to store the data, then after reading it, storing it again in the logic gates.  Additionally, DRAM is a destructive read type of memory, so once you've read the value through the logic gates, the DRAM is destroyed.  So in effective, by adding an indicator, you are using DRAM as a transport medium from the FPGA to the FPGA with single read capabilities, which is probably not what you were looking to do.  A FIFO would be better suited for this type of data handling.

The two clusters that you are pulling out of DRAM are clusters of unsigned quad numbers.  This data type is fairly large in terms of memory usage and is avoided in most instances on FPGAs.  However, since it appears that this is the format that the data type you are working with, it appears that you are limited to using this data type.  As a rule, you will typically want to use fixed-point number to limit resource usage.  Since you can't in this instance, the best way to minimize the effect of using this data type is to avoid displaying these values on the front panel as this uses additional resources on your FPGA.  You correctly found this written in the KnowledgeBase you linked in your last post.  Performing manipulation of the data from the DRAM will not require the same resources as creating front panel objects for that same data, and that is why you can manipulate the data and compile as long as you do not display this data using an indicator.  I apologize if I was not clear in our first interactions.  In short, the fewer objects you have on your front panel, including the front panels of SubVIs the less blockram you will be utilizing.

My suggestion regarding using a larger FPGA in my previous response was in response to what seemed to be a need to display the data set to a front panel object. I assumed you were going to use a Read/Write Method perhaps to post to a Host vi.  If that was the case,  using a Target to Host FIFO might be a better way to forward this information back to the host.  Either way, you are limited by the available resources on the FPGA to do this sort of communication.

If you have additional questions, don't hesitate to let us know and we will be glad to help.  There are limitations to the physical resources on an FPGA that can't be worked around, and depending on your requirements, you may be limited in what you can do with a specific piece of hardware. If we can help you more, let us know.

0 Kudos
Message 5 of 15
(3,156 Views)

Thanks for the clarification. I apologize if I sounded too aggressive, didn't mean it that way.  I didn't realize you were the same person on the phone conversation! It's just that the last post focused a lot on getting a different FPGA, that's why I made that comment. I found the phone conversation useful, you mentioned how I should avoid using sub-vis. I can manipulate the data output, but just not through any CLIP or sub-vi.

 

The U64 is simply a way to combine many pixel values, just a packing method. It shouldn't take more resources than 8 U8s. I do not do any manipulation / math on the U64 itself. In later stages, I split the U64 into 8 U8s. Now, if I try connecting that output (U8) to any sub-vi, the same issue happens, even if it is through a FIFO. Thanks for clarifiying the reasons behind that. So I have resorted to not using any sub-vis at all. The diagram looks huge, ugly, and quite difficult to follow what is going on. But I haven't found another way. I am attaching an update (it's a work in progress...) to demonstrate. Look particularly at the 350MHz SCTL. Let me know if you know of a way to modularize this code that does not use more resources than necessary. When using sub-vis in fpga target, i cannot find the "Inline sub-vis" checkmark under "File -> VI Properties -> Execution", unlike host vis. I would think if this option is available, it will not create ports (what I understood is taking up resources) for all the sub-vis, but rather just connect them using wires.

 

The project deadline is nearing and I don't think we have time to get another fpga. Besides, I would have to be absolutely certain that this FPGA will not work before suggesting to my supervisor to get another one. So I'm stuck to working with this one.

0 Kudos
Message 6 of 15
(3,152 Views)

Hey elsayed03,

So after looking at your code again, I realized a few things.  If you notice in your code you are creating the address for your DRAM using an unsigned 32 bit integer.  Since you do not prespecify the number of addresses you are using because you are incrementing the address by 1 each time, the compiler is accounting for the possibility that you might use over 4 billion memory locations, so it creates a block of memory that can hold all of those addresses.  In this way, the compiler assumes the worst.

 

However, the compiler is also "smart" enough to realize that if you don't ever display or pass the data from the DRAM, or use it to modify anything that will displayed or passed, that it doesn't need to be compiled at all.  In short, it will just ignore your request to create the DRAM. So, even though you see it on your block diagram, it doesn't do anything at all.  In effect, it's like not being there at all.  However, as soon you put an indicator down on the VI, the compiler is forced to allocate that memory block, which is why the usage jumps so signifcantly when you add that indicator.  If you know how many addresses you will need to use, select an integer of appropriate size.  If you can use a U16 instead of a U32, I would be willing to bet that you will have enough available resources to add those indicators back to the diagram.

 

I looked at your most recent VI, and think that the pixel handling should probably be done in a subVI.  While it could take up a marginal amount of additional space, it will be trivial and will make your code far easier to work with.  In short, you may want to start from one of the first examples you posted to make the address modification.  It will make the code easy to browse through again, and will be a very minor if not trivial resource requirement.

 

Additionally, I wanted to warn you in advance that the 350 MHz loop you currently have will not be able to compile.  I wouldn't count on being able to compile that loop at faster than 40MHz without some testing.  A compilation should tell you the maximum loop rate for your code, and it will definitely be less than 350 MHz.  Without compiling, I can't tell you about the other loops necessarily, but the loop rates you are looking for are pretty fast, and I just wanted to put it on your radar.

0 Kudos
Message 7 of 15
(3,137 Views)

Thanks. This makes sense. I chose U32 because the address is expected to be that type. I will try and let you know.

 

So when I use a sub-vi, the issue has nothing to do with resources that the sub-vi's front panel is taking up, it is about the compiler this time not ignoring the DRAM. Again, I will try using sub-vis and will let you know.

 

Thanks

0 Kudos
Message 8 of 15
(3,133 Views)

Nope. I tried changing it to U16. Still same error.

 

ERROR:Place:836 - Not enough free sites available for the components of the
following type(s).
BLOCKRAM Number of Components 107 Number of Sites 96
Phase 2.7 Design Feasibility Check (Checksum:573140b6) REAL time: 8 mins 1 secs
Total REAL time to Placer completion: 8 mins 1 secs
Total CPU time to Placer completion: 7 mins 52 secs
ERROR:Pack:1654 - The timing-driven placement phase encountered an error.
Mapping completed.
See MAP report file "NuecesRTop_map.mrp" for details.
Problem encountered during the packing phase.
Design Summary
--------------
Number of errors : 2
Number of warnings : 113
Process "Map" failed

Start Time: 12:36:36 PM
End Time: 1:04:14 PM
Total Time: 00:27:37

0 Kudos
Message 9 of 15
(3,129 Views)

I'm thinking it might be because of this: there is a red coercion dot at the Address terminal. So the U16 gets coerced to U32. So the Address terminal sees a U32 anyway and still thinks I want 4 billion addresses. Is there a way to avoid that?

 

I am sure people have been able to read / write from DRAM. What I'm trying to do doesn't seem too specialized.

0 Kudos
Message 10 of 15
(3,122 Views)