Tool for identifying resource consumption

[Altera_Forum]

Hi all ...  

 I've got a project that's been built in Quartus II for a Cyclone III chip written in verilog.  I'm trying to get a better handle on what's driving my LE consumption so that I can shrink the design a bit.   I can see in the Project Navigator the number of logic cells (and within that that number LUT only, Register only and LUT/Reg combo) by each code block ... but some of these are still "large" (800-1,400). What I'm looking for is a way to drill in a bit deeper so that I could see that the X register or the Y line of verilog code is instantiating Z logic cells so that I could focus efforts.  I've used the Resource Optimization Advisor and that's helped me shave some gates but I'm sure that more experience users know other tricks to helping ID where the big hitters are.  Thanks for your help,  V

[Altera_Forum]

The Project Navigator is based on hierarchies, so if you want more detail, you would need more hierarchies. To a certain level you can only get so detailed though. For example, if you had something based on processes, well logic is often shared/combined across processes and your count would get off. 

It's really at this point that you should be looking through your code and seeing what's implemented. If you have wide logic, then the counts can go up quickly. If you have lots of logic, then the counts go up(duh). But it really requires understanding what your code is doing and a rough approximation of what it should synthesize to in size. Note that you're looking for two things: 1) Synthesis isn't doing what you want. For example, if you think your code should infer a RAM, and use a single RAM block, but it tends to use a lot of registers and logic, then it didn't go into the RAM and is made out of... logic and registers. This is by far the most common issue I've seen(and usually because the code isn't what it needs to be, or has an asynch reset on the RAM or something). Most other things are hard to find. 2) Inefficient code. This is often the best thing to look for. For example, you may load 16 bytes of registers simultaneously into storage registers. But if you could singly put them into a RAM and access them one-by-one, you'd save a lot of logic.  One last thing to look at is the View -> Utility Windows -> Node Finder. Look for post-fit registers and wildcard to one of these hierarchies. This basically tells you ever register in your hierarchy. This often helps get a handle of where a lot of it is getting synthesized too. It's not perfect as it's only one side of the equation(combinatorial logic being the other), but it's not a bad place to look. Oh, and if you're not comfortable with reading HDL, the RTL viewer might help you visualize what's going on.

[Altera_Forum]

Rysc -  

 Thanks for the reply.  Actually the register side of the equation is making sense for me ... in fact the fitter doesn't seem to be generating as many duplicates as I would have thought.  The place where it seems to be using too many resources is on the LUT side. I have one module that's compiling to 1473 LUT Only, 23 Register Only and 449 LUT/Register combined LEs. The register side makes sense and there a number of adders and comparisons but the 1,473 still seems too large.  The code works fine. I'm just looking for a way to figure out what's consuming the LUTs short of breaking the module into a series of smaller ones just to figure where the resources are going.   I'm sure I've done some inefficient coding somewhere in there ... just looking for a way to narrow down where it is!  :)  V

[Altera_Forum]

I guess what you need is a high-level breakdown of the logic in your design, e.g. number of operators, N:1 muxes, basic logic gates. As Rysc points out, you can browse through your design in the RTL Viewer, but the same information in a tabular format would be much more convenient. I don't think this feature exists in Quartus II, so you may want to file an enhancement request.

[Altera_Forum]

Hello, 

 to my opinion, you can see already a lot in the Project Navigator / Hierarchy view, particularly if the design has some modularity. Another interesting view is the Resource Utilization by Entity in Compilation Report / Analysis & Synthesis. Combining both information, you see in detail what the resources are spent for, also the effect of design changes can be monitored.   Basically, you have to get an understanding of the resource costs of typical HDL constructs in your design. Once you got it, you'll know in advance how many LEs e. g. a 32 bit adder or a businterface will consume.  Regards,  Frank