Interpreting logic resource usage

[Altera_Forum]

Hi, 

I've been working on a large Stratix III design for some time now and it is nearing completion but I am concerned about logic resource usage ( i have a good handle on memory and multiplier usage). I may consider moving up to a larger device but it will probably be more than double the price so it's a serious concern all round. Space for expansion is obviously an issue also.   Anyway the question relates to the interpretation of all the statistics on logic resource usage (see fitter report below). The "bottom line" as reported in the compilation summary is 85% usage (I think this leaves a reasonable margin) but worryingly, 94% of ALMs are used, and 99% of LABs (partially or completely). On the other hand only 60% of combinatorial and 60% of registers are used.  From experience, which statistic should I be most worried about? I wouldn't like to find that by adding a simple function, my usage of 85% goes to 100% and it doesn't fit. I have noticed in recent updates that the usage seems to be quite "spongy" i.e. I have added some large functions and the bottom line has gone up by less than I would have anticipated. Is this a good sign?  The design currently fits comfortably in just over a couple of hours and meets timing OK.  Any input would be appreciated. Thanks, Dave.  Resource Usage  ALUTs Used 51,196 / 85,200 ( 60 % ) -- Combinational ALUTs 50,544 / 85,200 ( 59 % ) -- Memory ALUTs 652 / 42,600 ( 2 % ) -- LUT_REGs 0 / 85,200 ( 0 % ) Dedicated logic registers 50,057 / 85,200 ( 59 % )   Combinational ALUT usage by number of inputs  -- 7 input functions 764 -- 6 input functions 10425 -- 5 input functions 8602 -- 4 input functions 4446 -- <=3 input functions 26307   Combinational ALUTs by mode  -- normal mode 35004 -- extended LUT mode 764 -- arithmetic mode 12274 -- shared arithmetic mode 2502   Logic utilization 72,182 / 85,200 ( 85 % ) -- Combinational ALUT/register pairs used in final Placement 74104 -- Combinational with no register 24047 -- Register only 22908 -- Combinational with a register 27149 -- Estimated pairs recoverable by pairing ALUTs and registers as design grows -7963 -- Estimated Combinational ALUT/register pairs unavailable 6041 -- Unavailable due to Memory LAB use 1088 -- Unavailable due to unpartnered 7 LUTs 677 -- Unavailable due to unpartnered 6 LUTs 2675 -- Unavailable due to unpartnered 5 LUTs 204 -- Unavailable due to LAB-wide signal conflicts 997 -- Unavailable due to LAB input limits 400   Total registers* 50903 -- Dedicated logic registers 50,057 / 85,200 ( 59 % ) -- I/O registers 846 / 4,288 ( 20 % ) -- LUT_REGs 0   Memory LAB cells by mode  -- 64-address deep 24 -- 32-address deep 628   ALMs: partially or completely used 40,140 / 42,600 ( 94 % )   Total LABs: partially or completely used 4,216 / 4,260 ( 99 % ) -- Logic LABs 4,129 / 4,216 ( 98 % ) -- Memory LABs 87 / 4,216 ( 2 % )   User inserted logic elements 0 Virtual pins 0 I/O pins 633 / 744 ( 85 % ) -- Clock pins 9 / 16 ( 56 % ) -- Dedicated input pins 4 / 12 ( 33 % ) Global signals 30 M9K blocks 533 / 639 ( 83 % ) M144K blocks 12 / 16 ( 75 % ) Total MLAB memory bits 10828 Total block memory bits 4,800,748 / 8,248,320 ( 58 % ) Total block memory implementation bits 6,681,600 / 8,248,320 ( 81 % ) DSP block 18-bit elements 387 / 896 ( 43 % ) PLLs 3 / 8 ( 38 % ) Global clocks 16 / 16 ( 100 % ) Quadrant clocks 11 / 64 ( 17 % ) Periphery clocks 0 / 88 ( 0 % ) SERDES transmitters 18 / 88 ( 20 % ) SERDES receivers 18 / 88 ( 20 % ) JTAGs 1 / 1 ( 100 % ) ASMI blocks 1 / 1 ( 100 % ) CRC blocks 0 / 1 ( 0 % ) Remote update blocks 0 / 1 ( 0 % ) Impedance control blocks 1 / 8 ( 13 % ) Average interconnect usage (total/H/V) 28% / 29% / 27% Peak interconnect usage (total/H/V) 40% / 41% / 40%   Programmable power technology low-power tiles 2,150 / 2,897 ( 74 % ) -- low-power tiles that are used by the design 1,985 / 2,150 ( 92 % ) -- unused tiles (low-power) 165 / 2,150 ( 8 % ) Programmable power technology high-speed tiles 747 / 2,897 ( 26 % )   Programmable power technology low-power LAB tiles 1,985 / 2,130 ( 93 % ) -- low-power LAB tiles that are used by the design 1,985 / 1,985 ( 100 % ) -- unused LAB tiles (low-power) 0 / 1,985 ( 0 % ) Programmable power technology high-speed LAB tiles 145 / 2,130 ( 7 % )   Maximum fan-out node Main_PLL:pll0|altpll:altpll_component|altpll_4be2:auto_generated|clk[0]~clkctrl Maximum fan-out 34841 Highest non-global fan-out signal BussApp:inst|cpu1:the_cpu1|A_ci_multi_stall Highest non-global fan-out 5016 Total fan-out 382938

[Altera_Forum]

I assume you want to move because you want to add more functionality. 

 Then it depends on resource type needed for these new functions.  You need to treat resource sections independantly as: memory logic registers DSP others(pins,pll...)  you can sometimes trade off functionality between memory and logic but at expense of redesign.

[Altera_Forum]

I've sometimes found with densely packed Cyclone I and II designs that I can have a few free LEs but no (or not enough) LABs. This is usually because the design is limited by routing requirements. 

 Basically you end up with the problem that you make a really minor change and the design can't route - there is enough logic space to add that extra LE (or ALM) but no way to get the signal in and out because all the LABs have their routing resources (carries, clks etc) already taken up.    --- Quote Start ---  I have added some large functions and the bottom line has gone up by less than I would have anticipated. Is this a good sign?  --- Quote End ---    It depends - if those large functions are closely related to other stuff that is already in then you might be able to infer that there isn't a huge impact on the routing. If you try adding something completely unrelated then you might find you have a problem.  The key here is risk analysis:  You don't necessarily have a problem. How complete is your design and what is the likelihood of having to make a change? If you've done tonnes and tonnes of simulation and the design has been through all its testing phases and accepted by customers then you might decide the cost saving of sticking with the smaller device outweighs the risk of a change leading to the design not fitting.  You said you meet timing OK - is this a large margin? - if it is a tight margin then you may have to consider that design tweaks may impact the timing and you end up having to insert a whole new level of pipelining which pushes you over the edge. If on the other hand you've easily met the timing requirements then this probably isn't a worry.  What synthesis / fitter settings have you used?  Optimise for timing / size Resource sharing automatically removing duplicate logic and registers (reduces logic count but can impact routing) Register packing (same comment) Auto insert logic / registers (can aid routing at the expense of using more logic)  One of my designs I ended up having to set all the logic reduction settings to maximum and then tell the compiler to add in more where it needed. This slight paradox meant that it packed the design as tightly as it could but then added just what it needed in order to get the routing done.  Have a contingency plan - sk what you are going to do if you suddenly find that the design won't fit:  Is the next device up pin compatible? (I think yes from the info you provided)  Are there any bits of the design that you could rip out if need be? - e.g. do you have some debugging logic that is useful for development but can come out of the production issue?  Rather than jumping in price to the next biggest Stratix is there some function(s) that you could pull out into a much smaller (and cheaper) FPGA, PLD or micro? (probably not given the size of the device that you have).  If you're at the design stage and just building a couple of boards you could build them with the bigger device just so you can get the design done without worrying about space - prove your design and your function and then try to get it to fit in the smaller device for production which (hopefully) would mean not changing the board layout.  Hope this helps.

[Altera_Forum]

Thanks for your replies. I've got the next Stratix III in reserve if I need it but it's a very costly beast indeed! I'm not sure the company would be very happy using it as it would push up the price of the product. 

 The logic side of things seems to be reasonably absorbent at the moment and I'm not far off completion so I'm not overly depressed about the situation.  Of course, I can always cut the specification back in certain places if need be.  Regards, Dave.