Not enough LABs after small change

[Altera_Forum]

I have a project that uses a system built by the SOPC builder. We weren't getting the perf we wanted, and the critical paths were through an adder in the "burst" wrappers added. So, we made our own burst units to eliminate that path, and created an sopc builder component with our own burst code and an altsyncram. We also had a component that was big endian, and we added a change that should have only changed wiring to make it little endian and remove all of the endian blocks created by the sopc builder for conversion. 

 Now it doesn't fit. I've tried reducing the number of memory blocks we have (previously had two rams we were using as caches, reduced it to 1), played with all of the Resource Optimization Advisor recommendations, and we are consistently about 500 LABs over the max according to the error from the fitter.  Part of the fit report is below. It looks like the problem is due to routing, however the new burst blocks we added only require 65 LC combinationals and 32 registers according to the synthesis report. I don't know what the size of the burst blocks that the sopc builder added were, but I would think this isn't much of a change. The flow use to finish with about 83% utilization - now it's clearly over.  Anyone have any suggestions? I'm surprised the results varried this wildly. I've attached a number of the report/message files. We're using partitions, but if I remove partitions it doesn't improve the results.  Thanks, baver  ; Logic utilization ; 81,778 / 72,768 ( 112 % )   ; ; -- Combinational ALUT/register pairs used in final Placement ; 71030   ; ; -- Combinational with no register ; 23894   ; ; -- Register only ; 22686   ; ; -- Combinational with a register ; 24450   ; ; -- Estimated pairs recoverable by pairing ALUTs and registers as design grows ; 0   ; ; -- Estimated Combinational ALUT/register pairs unavailable ; 10748   ; ; -- Unavailable due to unpartnered 7 LUTs ; 1252   ; ; -- Unavailable due to unpartnered 6 LUTs ; 6772   ; ; -- Unavailable due to unpartnered 5 LUTs ; 185   ; ; -- Unavailable due to LAB-wide signal conflicts ; 2351   ; ; -- Unavailable due to LAB input limits ; 188   ; ; ;   ; ; Total registers* ; 47,761 / 77,026 ( 62 % )   ; ; -- Dedicated logic registers ; 47,136 / 72,768 ( 65 % )   ; ; -- I/O registers ; 625 / 4,258 ( 15 % )   ; ; ;   ; ; ALMs: partially or completely used ; 39,793 / 36,384 ( 109 % )   ; ; ;   ; ; Total LABs: partially or completely used ; 5,150 / 4,548 ( 113 % )

[Altera_Forum]

Look at the resource utilization by design entity before and after the changes to see where you are getting the 30% increase in LE usage on a 70K device. Seems like it should be obvious.

[Altera_Forum]

--- Quote Start ---  Look at the resource utilization by design entity before and after the changes to see where you are getting the 30% increase in LE usage on a 70K device. Seems like it should be obvious.  --- Quote End ---     Hi,  can you say which of this three numbers changed dramatically ?   Combinational with no register ; 23894  ; ; -- Register only ; 22686  ; ; -- Combinational with a register ; 24450   Kind regards  GPK

[Altera_Forum]

Fitter is running on the previous design so I don't have GPK's answer yet. 

 Gmpstr, I looked at a few units. Overall, everything seems bigger. I went and compare settings between the old and new projects, and for analysis & synthesis made them the same. I'm running synthesis on the new design again.  Something odd I did notice was that in the old design, four altshift_taps megafunctions were inferred in the ddr2 high performance controller. In the new design, two are, and a divider is inferred. This doesn't count for the overall increase in area usage, but it's not clear to me why there would be that difference and makes me wonder if something similar is happening elsewhere.

[Altera_Forum]

Ok, found the problem. One of the arbitrators created by the sopc builder uses an abnormally huge amount of space - 3339 LC's and 13424 registers. It use to use 59 and 42, respectively. 

 Not sure how to fix yet. There was a burst width mismatch, but after fixing that the same amount of area is still required.

[Altera_Forum]

--- Quote Start ---  Ok, found the problem. One of the arbitrators created by the sopc builder uses an abnormally huge amount of space - 3339 LC's and 13424 registers. It use to use 59 and 42, respectively.  Not sure how to fix yet. There was a burst width mismatch, but after fixing that the same amount of area is still required.  --- Quote End ---     Hi,  happy new year.  In order to find out which of your changes causes the problem, can you remove your own "burst" wrapper block from the design and run Quartus again. When the problem is gone then, we can be sure that your own block is the real root cause. Maybe you did some other small changes which have unintended effects.  Kind regards  GPK

[Altera_Forum]

Hi pletz, 

 Happy new year to you too.  Found the problem. One of the custom components I have for the sopc builder had the number of pending read requests set to 1024. One of the other signals was also incorrectly identified (sopc builder thought it was inverted), so I'm guessing that when I opened the component to update it, some of those fields were "automatically" updated.   Thanks for the help all.  baver

[Altera_Forum]

--- Quote Start ---  Hi pletz,  Happy new year to you too.  Found the problem. One of the custom components I have for the sopc builder had the number of pending read requests set to 1024. One of the other signals was also incorrectly identified (sopc builder thought it was inverted), so I'm guessing that when I opened the component to update it, some of those fields were "automatically" updated.   Thanks for the help all.  baver  --- Quote End ---    Good to hear that you could solve your problem. Hopefully icould help you a little bit.  Bye  GPK