Electronic – How to identify areas of a FPGA design that use the most resources and area

fpgaoptimizationspartanvhdlxilinx

I am working on a large FPGA design, and I am very close to the resource limits of the FPGA that I am currently using, the Xilinx LX16 in the CSG225 package.

The design is also almost complete, however at the moment it will no longer fit in the FPGA. I can turn off parts to get it to fit, however I need to reduce the resource usage in order to complete the design and have it meet timing and size requirements.

I would like to know if there are any tools our reports that can help me identify which parts of my design are consuming the most resources. My design is not partitioned, and is split over about a dozen or more VHDL modules.

Xilinx timing reports are fantastic, but now I need to know where I can get my best bang-for-buck in terms of space saving.

I also have a hard time telling which type of resources I'm running out of, or what effects those resources.

Another annoyance is that as the design gets larger, components that used to meet timing are starting to fail because their placement is no longer as ideal.

Currently, I use the Post-Place and Route Static timing reports, and I use SmartXplorer. I'm using design strategies to optimize for timing.

After turning off part of my design to get it to fit, here are some of the results:

slice register utilization: 42%
slice LUT utilization: 96%
number of fully used LUT-FF pairs: 38%
Does this mean I'm light on registers, but heavy on gate usage?

Are there tools to help developers optimize for area, or at least give them more insight into their code?

Update:
After looking at the Module Level Utilization, I found out that I had small glue async fifos all over the place that take up about 30% of the total LUTs. I am using them as cross-clock-domain glue for high speed buses. I should be able eliminate these, since the clocks are tightly related. (120 MHz input, produces 100 MHz and 200 MHz through DCMs)

Best Answer

I cross posted this question on the Xilinx Forum here: http://forums.xilinx.com/t5/Implementation/How-to-determine-what-part-of-the-design-consumes-the-most/td-p/393247

This answer is largely based on the comments there. Thanks to Deepika, Sikta and Gabor.

First, enable 'Generate Detailed MAP Report' in the map process properties (-detail).

Then, open the Design Summary, and navigate to Module Level Utilization. Here is the complete hierarchy, showing exclusive and inclusive design utilization.

Each line will show a number pair like 0/5392. This means that that module contains zero of that specific element, but that module and all of its sub-modules contain a total of 5392 elements.

Here is my output (partially expanded)

When working on reducing the size, Gabor recommends switching to a larger FPGA in the synth tools so that it can completely map even when it's too large to fit in your current FPGA, and it will make the tools run faster.

Related Solutions

Electronic – Pipelining and clock frequency issue

Your design will not function correctly if it runs at 100 MHz but is only spec'd (by the tools) to run at 50 MHz. If it does, then it's a one-off miracle that wouldn't work when you make a change and rerun the tools. Don't do it. Don't even do it if your clock is 100 MHz and the tools tell you the design can run at 99.5 MHz.

To solve your problem you can either write a simple 'divide by power of 2' clock divider to reduce the clock frequency (something like this in Verilog):

reg [n:0] count; 

always @(posedge CLK_100) begin
  count <= count + 1;
end

BUFG bg_0 (.I(count[m]), .O(CLK_DIV));

(where 'm' <= 'n' and 'bufg' is a global clock buffer, and must be used for synchronous designs) or use a Digital Clock Manager (DCM).

Hopefully that solves your pipelining issues as well unless you absolutely have to run the entire design at 100 MHz. Other than pipelining you can consider using FIFOs if you have part of the design running at 50 MHz and the other at 100 MHz, but you'll have to say a bit more about what you're doing to get more meaningful help here.

Electronic – Design doesnot work properly when clock net delay is slightly higher in spartan3a fpga

I have been using Xilinx chips and tools for a very long time. The first version I used was Foundation 2.1, about 20 years ago. I do a LOT with FPGAs. So needless to say that I have learned a few things along the way.

One thing that I have learned is that if your timing constraints are set up correctly, and the timing analyzer says that you don't have a timing problem then you don't have a timing problem. Funny how that is-- a tool that actually works correctly!

This means that if you do have a timing problem then it is likely that either your constraints are not set up correctly, or you are doing something wrong with regard to signals that are asynchronous to your clock.

Doing a post PAR simulation (with timing data) does not guarantee proper operation. In fact, I would argue that for most designs with simple timing requirements that a post PAR timing simulation does nothing than what can be achieved with a behavioral simulation. These days I don't do timing simulations at all because of that, and I have never been burnt by that decision.

Anyway, the point is this: Odds are that either your timing constraints is wrong or you are doing something wrong with async signals.

Debugging this type of problem is difficult, but here's some tips on how to approach it:

Be meticulous and methodical in your debugging. Focus on what you know about the problem and follow it to the source. Don't take a shotgun approach and try lots of different things scattered around. Focus on the known problem (output signals are wrong) and follow that back to the bug. Don't just go hunting for anomalies in the many Xilinx report files-- since there are lots of things there to worry about and almost none of them are really problems. Anomaly hunting will just frustrate you.

Best Answer

Related Solutions

Electronic – Pipelining and clock frequency issue

Electronic – Design doesnot work properly when clock net delay is slightly higher in spartan3a fpga

Related Topic