Synplify 8.1 vs. Quartus II 5.0 QoR

The report from Quartus is always reliable, as it is based on timing calculated from the final place and route information for your design. We always ask customers to base their performance decisions based on the Quartus timing report and not on estimates given by the HDL synthesis tools. Synthesis tools can at best estimate what the final place and route look like, and given the more advanced architectures today they may not be accurate unless they have the actual place and route engine built into their product. Also Quartus has the capability to perform physical synthesis optimizations as part of the fitting process, whose benefits cannot be estimated by the HDL synthesis tool.

Having said that, Quartus II 5.0 also has a feature called the Early Timing Estimator that provides timing information without doing a complete place and route. The accuracy of the results can be controlled by choosing one of three choices, Realistic, Optimistic or Pessimistic. This command takes less time than doing a full place and route.

This feature can be accessed through the Process->Start->Start Early Timing Estimate menu. More details can be found in the Timing Analysis section of the Quartus Handbook at

Hope this helps, Subroto Datta Altera Corp.

Please use the URL

The one I pasted was based on a answer search on "Early Timing Estimate", and clicking on the URL in my previous post will not work.

Hope this helps, Subroto Datta

I've always found Synplify to be over optimisitic for Xilinx and underoptimisitic for Altera. Maybe Xilinx slipped em a few quid? :)

Cheers, Jon

Subroto,

I think the link you wanted is to Volume 2, Chapter 7 of the Quartus II Handbook:

See the Early Timing Estimate section in that document.

Most users will want to use the default "realistic" estimate mode. This gives a best guess about the timing of a design with much lower CPU time than a full place and route. Error bars are +/-10% for a typical design vs. what you'll actually achieve after full place and route (and optionally physical synthesis). If you want bounds on "will the design almost certainly be this fast" and "is there any chance the design could be this fast", you can use the pessimistic and optimistic modes, respectively.

The Early Timing Estimate is integrated with the same place and route engine we use for full fitting of a design, and it also models the impact of physical synthesis. It also obeys any floorplan constraints, pin-out, etc, in your design. For both these reasons, it is considerably more accurate than the typical post-synthesis speed estimate. As well, you can view where it thinks your logic should go in the Quartus floorplan editor, so it can help you optimize a floorplan quickly as well.

Regards,

Vaughn Altera [v b e t z (at) altera.com]

Hi Wenchang,

Last wednesday though friday I ported a design to Stratix II. After I had finally converted all the technology-specific blocks to their Stratix II equivalents I compiled the design and got it to run at 55MHz. Bummer, I thought, my customer wants to have it running at 60MHz.

Then I remembered: as of Quartus 4.2, the fitter runs in Auto mode, which means that it will fit as long as timing constraints are not met, and as soon as timing constraints are met, will stop and produce results. And I hadn't put in any timng constraints yet.

So, Quartus had generated the netlist, semi-randomly emptied its bag of gates over the FPGA structure, did timing analysis, saw that the design was completely unconstrained, thought "Cool, I'm done", and reported 55MHz back to me. I already thought that 7 minutes of synthesis plus P&R for a 20.000 LE design was a bit fast...

So, I just put in a clock constraint of 60MHz on the main clock, and fitted again. Had some coffee, came back after 10 minutes, and had a design running at 85MHz.

So, it may very well be that you ran into the same trap. The adders are regular structures in the FPGA that are stitched together by hard-wired carry chains. These, by nature, will always be fast. I have no idea what the structure of an SRT Radix-4 divider looks like or what your pipeline level is, but if Quartus was in Auto-Fit mode and you hadn't put in any timing constraints, your end result would have been optimized for fastest fitter runtime, and not for best performance.

Thus, my suggestion is to set a timing constraint when you're fitting in Auto mode (putting in timing constraints is always a good idea, of course), or to set the fitter to "Standard effort". Both can be done from Assignments->Settings. Clock and IO constraints can then be set from the "Timing Requirements and options" page, and the fitter mode from the "Fitter Settings" page.

Hope this is useful to you.

Best regards,

Ben

I was about to post that you should check that Quartus P&R is being run with the same constraints that you synthesized with but Ben did it for me. Both tools are strongly timing driven so constraint differences can yield wildly different results.

Synplify produces a tcl file for you to source in Quartus that will import the Synplify constraints. My memory is that the file name is _cons.tcl .

Synplify is doing it's best to estimate a constrained Quartus run. Depending on the structure and routing load of your design, this estimate can be low or high. Synplify has a very useful constraint option for syncing up synthesis and P&R timing. the "-route " option to define_clock can be used to squeeze (or relax with a negative delay) the period of a clock for synthesis. This additional routing estimation adjustment for the clock domain is not passed through the _tcl.cons file so the P&R constraints remain correct. We recommend using up to about a 10% of period value for the -route option. -route can also be applied to individual paths using define_reg_{input,output}_delay.

- Ken McElva> Hi Wenchang,