Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16597 Discussions

synthesis mapping more DSP blocks than device has for Cyclone V

Altera_Forum
Honored Contributor II
1,263 Views

I have a DSP-heavy design that started in a Cyclone IV E, but to get the number of DSP blocks needed in Cyclone IV we would be forced into a package that is too large for the board. So I ported the design to Cyclone V. In Cyclone IV the design used 86 18x18 multipliers, so I initially targeted the Cyclone V 5CEA4, which has 132 18x18 multipliers. But the Quartus synthesis tool mapped the design to 72 of the Cyclone V DSP blocks (the 5CEA4 only has 66, with 2 18x18 multipliers each depending on the mode). The fitter then failed because it could't fit 72 DSP blocks. If I target a larger device the design compiles fine. Or if I target the 5CEA4 and change a Quartus setting to disable mapping any logic to DSP blocks the design also compiles fine, although the ALM utilization balloons from building all the DSP logic out of the fabric. 

 

In Cyclone IV if the design exceeded the number of 18x18 multipliers then Quartus would use all available and build the rest out of LEs, and the fitter would complete normally. When targeting Cyclone V Quartus maps to more DSP blocks than the target device has. I believe this is a bug in Quartus. So far I've tried Quartus II 15.0 and Quartus Prime Standard 17.0. Both behave the same (synthesis maps to 72 DSP blocks and the fitter fails). 

 

In the Quartus advanced synthesis settings there is a setting called "Maximum DSP Block Usage". The default is "-1 (UNLIMITED)". I changed this to 66 (the number of DSP blocks available in the 5CEA4) and synthesis still mapped 72 DSP blocks, so it obviously ignores the setting. The description of this setting in Quartus says: 

 

"Allows you to specify the maximum number of DSP blocks that the DSP block balancer will assume exist in the current device for each partition. this option overrides the usual method of using the maximum number of dsp blocks the current device supports.

 

So it looks like the normal behavior should be to never exceed the number of DSP blocks in the target device, which is what I would hope/expect. 

 

The other setting I played with is called "Auto DSP Block Replacement". If I change this to "Off" synthesis does not map any DSP blocks and the design fits, but the logic use is too high. 

 

I'm pursuing this with our local FAE, but I won't hear back from him until next week. Trying to get a quicker answer. Has anyone seen this behavior? If so, did you find a workaround that forces synthesis to use all available DSP blocks without exceeding that limit? 

 

Any help appreciated. 

 

Thanks, 

Bob
0 Kudos
0 Replies
Reply