Fitter is off by one or two ALUTs?

[Altera_Forum]

I'm using TCL to explicitly place and instantiate 48,352 of 48,352 ALUTs in an EP2S60 (Stratix II 60). There seems to be some roundoff error though, as I can only squeeze 48,350 ALUTs into the device without the fitter chewing me out. 

 If I instantiate 48,351 ALUTs, the fitter tells me that the design requires 3,023 LABs, but that the device only contains 3,022 of them. (Note that 48,352 / 16 = 3,022, so ceil(48,351/16) = 3,022.)  And if I instantiate 48,352 ALUTs, the fitter incorrectly tells me that the design requires 48,353 ALUTs but that the device only contains 48,352 of them.  However as long as I only instantiate only 48,350 ALUTs, fitting works just fine, and I can verify with Chip Editor that nothing is using the remaining 2 ALUTs that I had to avoid. If I try to add them from inside Chip Editor and re-fit, I get the same errors as with TCL. There's also nothing special about the particular ALUTs that I'm avoiding: I just have to leave any two unused.  Is this a bug, or perhaps a feature masquerading as a bug? (I do realize that a tool may think it's going to need an extra ALUT or two for some purpose, but I suspect this may actually stem from bounds that nobody has ever needed to test.)  Yes, I know this is irrelevant for most users. Chalk it up to unusual research needs. I've tried this with Quartus II 6.1 and 7.2, and I can provide the TCL script if anyone wants to verify the behavior.

[Altera_Forum]

This is most likely an issue with LAB-wide control signals. There are only so many per lab, and although the issue is usually due to clock enables, I'm guessing you're hand-controlling synthesis, and it could be due to about anything.  

 Anyway, for starters, look at the fitter report -> Resource Section -> Control Signals and see how many control signals are being used, just for a rough idea.  Does this design fit without any location constraints?   My concern is that, since you're seemingly able to pack full 48,350 ALUTs without problem, I'm guessing there is nothing special about those final two ALUTs that you're trying to pack. Don't know for sure though. One test to make sure is to remove some(or all) of the logic except for these two LABs that have the dedicated logic, and then pack them full. If they fit, then there shouldn't be anything illegal that you're trying to do.  Another thought is that the fitter may be packing before it gets to your location assignmnets, i.e. it packs everything as it thinks fit, and would then re-arrange those packings based on your assignmnets. If that were the case, this initial algorithm may have it's own no-fit(due to LAB control signals) and give this error, even if you theoretically had a viable packing/placement scheme that would work.  Finally, you'll probably find that this running out of labs message isn't the most detailed. The reason is that the user normally doesn't control the LAB packing or really understand it. So if the fitter over-runs the number of LABs required due to packing, it would need a detailed report on all 3023+ labs and what's in them and what control signals they use in order for a user to try and find a "better" packing that might reduce the LAB usage. On most designs(probably all designs except this one), the user wouldn't have any clue how to find a better packing, and their time would be much better spent taking out a few ALUTs of logic or trying to find a better synthesis.

[Altera_Forum]

Thanks for the response Rysc. You're trying to help me get a design working, and I feel bad because this is really a low priority issue. But let me shed some extra light on the situation anyhow. 

 I'm actually starting with an empty design (well, okay, it has a single input that goes nowhere -- I thought it would get trimmed, but it doesn't):  module mask_ffffffffffffffff (a); input a; endmodule   I push that through the entire flow, and come up with a design that uses 0 ALUTs and 0 LABs. I then invoke the TCL ::quartus::chip_editor::add_new_cell on every valid LCCOMB in the device, so the placement happens explicitly as part of the instantiation. Finally, my LUT values are all FFFF (or all 0000 in a different design), so the ALUTs have no inputs or outputs, and neither are there any control signals involved. In other words, there's essentially zero routing in the device.  All of that is what leads me to conclude that the fitter either feels it needs to hang on to an ALUT or two, or that there may be an instance of 0-based offset versus 1-based offset and/or < versus <= somewhere in the code. Regardless, as I said, this is not a high priority issue, and Rysc's contributions to this forum are too valuable to waste on this.