03-03-2015 03:14 PM
I was using Synplify pro for RTL synthesis.
I am using 2 xilinx coregen PLLs, one to generate 125MHz, one to generate 80MHz.
When I use a clock of 125MHz, then the timing report comes out showing about 105MHz.
However when I use 80MHz in place of the 125MHz, then for some reason the timing report comes out showing a max. of about 30MHz.
I did check the synplify reports and for the 125MHz case, it shows requested period as 8ns. – which is correct for 125MHz.
But for 80 MHz case, the report starts to show a requested period of 1.2ns! – I am not sure how this can happen.
I have checked my PLL and it is generating the proper freq. I am only constraining the PLL input.
could there be a situation where if the freq falls below a certain value then the RTL code would get synthesized out or something?
In what case would a 80MHz speed give 30MHz in best case freq but 125MHz give 105MHz?
Do let me know …
Thanks and regards,
03-03-2015 03:18 PM
Ignore Synplify's timing estimates. The only numbers that matter are those generated by the post-place-and-route timing analyzer.
03-03-2015 03:25 PM
even if i target the specific xilinx FPGA, do i still not reply on the synplify timing estimate?
i agree that the final say is xilinx post PAR report, but as a first pass, can we not rely on synplify reports at all?
03-04-2015 01:02 PM
I'm surprised Synplify is getting this wrong. All the tools I've used for Xilinx FPGAs - Synplify/ISE/Vivado - all have always managed to time correctly through the PLLs/MMCMs/etc. It's always just worked, without me having do to anything.
If it were me, I spend a few minutes investigating the log files/etc. to try and puzzle out what's going on. You're not doing anything "creative" beyond just constraining the input clock period?
But from your description it sounds like a Synplify problem.