Small change causes LE count to change from 108 to 2660

[Jorgeb]

Whenever I connect SampleNow, in the Baud generator.v file to the SAMPLENOW port, the LE count goes from 108 to 2660?

If I connect OversamplingTick (from which SampleNow is generated), no problems occur.  I've shut off clock mux protection, as the SAMPLENOW port connects to a clock mux in serial_trigger.v.

I can trigger this problem without routing SampleNow to SAMPLENOW, but just making SAMPLENOW a reg, and initializing it to *anything* in the reg line?

If I route SampleNow to SAMPLENOW, ignore the fitting error, and simulate, everything works as advertised (other than it doesn't fit...).

Pretty baffled.

[Jorgeb]

Fixed, in my case.  The problem was the line:

LogBitsize(ClkFrequency/baud) was implying an lpm_divide Megafunction.  Changed to (LogBitsize(ClkFrequency) - LogBitsize(baud)), and problem resolved.  Completely.

I say that the problem resolved completely because two lpm_div megafunctions were being implied, the second by a different line, according to Quartus.  But they *both* went away with the changes above?  This highlights the fact that there doesn't seem to be any documentation at what 'implies' an lpm_div Megafunction (or any other megafunction).  Nor is there any dox on how to *not* imply these explicitly in Quartus.  In general, this was huge waste of time because Quartus inferred something that wasn't there and made a 32 bit barrel shifter.

How do I stop Quartus from wasting my time?  It would be much useful if Quartus *asked* if that was my intention...

[SyafieqS]

Thanks for you feedback and this can be a for Quartus enhancement.