Electronics > FPGA
Why does my macrocell count increase?
BrianHG:
--- Quote from: rea5245 on September 28, 2022, 07:36:44 pm ---So my immediate problem of fitting everything into a CPLD is solved (thank you Brian!). But my original question remains a puzzle: why did narrowing down the opcode field cause the number of macrocells to increase? I hoped it would reduce their usage, and at worst, I would've expected it to have no effect.
Is this something an experienced Verilog programmer could've predicted?
--- End quote ---
It's just a fluke where having the extra input terms may have entered into a final solution, or, the compiler found a means of making the design have a higher FMAX output by using less inputs, but by adding a few extra macrocells to compute the output. Unless you are specifying strict boolean logic for each output cell, this happens more often than you think as the compiler tries to get the highest output speed possible.
If you clocked your design and specified you only need 50mhz performance, then Quartus may have automatically simplified the system down to the smallest gate/macrocell count instead of striving for >200MHz performance.
Foxxz:
--- Quote from: BrianHG on September 28, 2022, 07:44:48 pm ---
--- Quote from: rea5245 on September 28, 2022, 07:36:44 pm ---So my immediate problem of fitting everything into a CPLD is solved (thank you Brian!). But my original question remains a puzzle: why did narrowing down the opcode field cause the number of macrocells to increase? I hoped it would reduce their usage, and at worst, I would've expected it to have no effect.
Is this something an experienced Verilog programmer could've predicted?
--- End quote ---
It's just a fluke where having the extra input terms may have entered into a final solution, or, the compiler found a means of making the design have a higher FMAX output by using less inputs, but by adding a few extra macrocells to compute the output. Unless you are specifying strict boolean logic for each output cell, this happens more often than you think as the compiler tries to get the highest output speed possible.
If you clocked your design and specified you only need 50mhz performance, then Quartus may have automatically simplified the system down to the smallest gate/macrocell count instead of striving for >200MHz performance.
--- End quote ---
Can you set a timing constraint without resorting to clocking to get the same effect?
Edited: NM I think we're thinking the same thing using different terminology
BrianHG:
--- Quote from: Foxxz on September 29, 2022, 12:11:45 am ---
--- Quote from: BrianHG on September 28, 2022, 07:44:48 pm ---
--- Quote from: rea5245 on September 28, 2022, 07:36:44 pm ---So my immediate problem of fitting everything into a CPLD is solved (thank you Brian!). But my original question remains a puzzle: why did narrowing down the opcode field cause the number of macrocells to increase? I hoped it would reduce their usage, and at worst, I would've expected it to have no effect.
Is this something an experienced Verilog programmer could've predicted?
--- End quote ---
It's just a fluke where having the extra input terms may have entered into a final solution, or, the compiler found a means of making the design have a higher FMAX output by using less inputs, but by adding a few extra macrocells to compute the output. Unless you are specifying strict boolean logic for each output cell, this happens more often than you think as the compiler tries to get the highest output speed possible.
If you clocked your design and specified you only need 50mhz performance, then Quartus may have automatically simplified the system down to the smallest gate/macrocell count instead of striving for >200MHz performance.
--- End quote ---
Can you set a timing constraint without resorting to clocking to get the same effect?
Edited: NM I think we're thinking the same thing using different terminology
--- End quote ---
You are now getting into the realm of creating a proper .sdc (Synopsys Design Constraints) file where you specify input and output setup, delay, and hold times. At least, for the larger FPGAs, this is how I would go about it.
The problem here is if you specify a time too large or too small in the .sdc file, the FPGA compiler may add logic cells to mimic the effect of your requested input to output delays. For small PLD designs of the MAX7000 series, unless you wish to mimic a peculiar timing of some old logic ICs or even old GAL/PAL cplds, setting the compiler's optimization technique is the quickest way to see a large effect on the macrocell usage.
My 'Black Magic' trick achieving 62 macrocells was achieved by defining a final single full signed adder with 2 extra bits which Quartus could easily chew on, utilizing the upper 2 output bits to represent the carry and negative flags. To make all the calculations which 'rea5245' requested, I only switched the input values to that adder based on the function requiring nothing more than some XOR and AND terms modifying the adders A & B inputs. However, when we had 'Speed' set for the optimization technique, all 3 versions of the source code would hit the same ~135 required macrocells, yet, the 'Area' optimization technique had varying final result sizes from 101 macrocells to my last version at 62 macrocells. I guess you can say that everything contributed into the final size.
I guess you should always set the compiler to optimize for 'Area', and define a .sdc file where the compiler always tries for a small result, but adds logic as nessary to improve output performance if you so have it set in the .sdc file.
Navigation
[0] Message Index
[*] Previous page
Go to full version