Jump to content
MikaelH

Running out of LUTs on Zynq 7020

Recommended Posts

Hi FPGA expert.

When I try “my way†of implementing a simple FPGA Analog Out VI, I run out of FPGA fabric (too may LUTs used).

So what better way can I do this (if there is one), that don’t overuse my LUTs.

My task is to:

Make one analog measurement and control 2 analogue outputs that should be clocked out every time I get a digital trigger in.

 

I’m running a sbRIO-9637 (Zynq7020)

I’ve attached the simple application and I’m puzzled of what needs so many Look Up Tables (LUTs).

Any suggestions?

FPGATest.zip

Share this post


Link to post
Share on other sites

Here are some suggestions. Sorry I don't have time to understand your code and rewrite some of it to illustrate these ideas.

- Wherever possible, read from and write to IO and memory in a single location, to avoid arbitration, even if the code logically can't possibly execute multiple occurrences in parallel. It's fine to read memory in one location and write it somewhere else, but for each memory block I would try to have a single instance of the memory read, even if that means you read and discard the data most of the time. Likewise, move reading the digital inputs outside the case structure.

- In order to move the digital inputs outside the case structure, you'll need to restructure your state machine. I would create a lot more states, replacing the nested while loops with their own states where you don't proceed to the next state until the trigger occurs.

- Once you've done that, you can probably make the upper loop into a single-cycle timed loop (unless the analog outputs don't support it, which you could work around by putting them in their own loop and setting their value through a register). That should save you some FPGA space.

 

I would also check your logic. As far as I can tell, both TriggerPulses and the shift register value to which it's compared in the "Wait for Falling Trigger" case never change, so I don't see how you would ever move on from that case, unless the host updates the TriggerPulses value.

Share this post


Link to post
Share on other sites

Thanks, I'll see what I can do to follow your tips, if anybody else see something strange please let me know.

post-941-0-83658700-1458608003.png

//MIke

 

Share this post


Link to post
Share on other sites

Both of your FIFOs are massive, both to and from the FPGA.  They can be MUCH smaller.

 

What does your compile report look like, can you post a screenshot?


Yeah, problem seems to be distributed RAM LUT cells, of which you only have 11000 ont he device.

 

Your two FIFOs to and from the FPGA can be way way smaller, like 50 elements.

 

You have set them to use Block RAM but I don't think the compiler is doing that.

  • Like 2

Share this post


Link to post
Share on other sites

You're correct.

It looks like I'm running out of memory.

I have enough Block Memory, but it looks like it’s using LUTs instead, so yes by reducing the FIFO sizes it starts to compile.

The error message I get is: “The Design requires more LUT as Memory cells…This design requires 19337 of such cell types but only 17400 compatible sites are available in the target device.â€

I just reduce the FIFO to the FPGA and that solved it.

The problem was that I made the FIFO size to the FPGA too big, that design would make the SW easier just One Write on the RT, but now I need to do something like this in the RT:

post-941-0-44646800-1458673783.png

Share this post


Link to post
Share on other sites
The problem was that I made the FIFO size to the FPGA too big, that design would make the SW easier just One Write on the RT

That's not necessary. The FIFO size on the host side is independent of the FIFO size on the FPGA. You can configure the host-side buffer to be much larger and then do a single write as you originally intended. The DMA automatically copies data from the host buffer into the FPGA buffer as space becomes available.

Share this post


Link to post
Share on other sites

Way to go and mark your own answer rather than the dude that actually solved it. :angry:

Not even a like for Shoneill? :shifty:

Sorry about that, both are marked as the solution now. He pointed me in the right direction and my solution just showed how I had to implement it to get it working.

 

That's not necessary. The FIFO size on the host side is independent of the FIFO size on the FPGA. You can configure the host-side buffer to be much larger and then do a single write as you originally intended. The DMA automatically copies data from the host buffer into the FPGA buffer as space becomes available.

Interesting idea.

So you can configure the FIFO in RT with the "Requestes Depth" to a much larger number that the FIFO on the FPGA supports, and the DMA will take care of the rest?!!?

If so that is a very nice solution.

Share this post


Link to post
Share on other sites

Yes, the transfers can be buffered nicely from the RT to the FPGA.  You only need very small FIFOs on the FPGA itself.  It is indeed a nice solution.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.