Cyclone V speed is much slower

Just to clarify:

Do you still get the error "Critical Warning (332012): Synopsys Design Constraints File file not found: 'Flex01.sdc' ..." ?

Do note that Cyclone V using ALTERA_PLL ip instead of ALTPLL which is used for previous device family like Cyclone III and Cyclone IV.

Agree with nicejob comment, you may need to consider the speed grade of the device used. Do counter check the timing spec of Cyclone V device and compare to other previous series device timing spec in their I/O timing spreadsheet.

https://www.altera.com/content/dam/altera-www/global/en_us/others/literature/hb/cyclone-v/cyclonev-io-timing.xls

https://www.altera.com/content/dam/altera-www/global/en_US/others/literature/hb/cyclone-iv/cycloneiv_io_timing_qii10_0.xls

Post your TimeQuest report. It may be there are some cross clock domain paths that the tool is working hard on, then giving up on other paths.

Pete

I'm actually experiencing very similar problems with the Cyclone V. I have a number of designs that I've used for years on Cyclone III and Cyclone IV devices without any problems, and am now finding it impossible to make timing when creating an almost identical design on a Cyclone V.

I've spent some time looking at the timequest reports and the big difference between the older devices and the V seems to be the reported clock delay in the timing path.

For example, on both Cyclone III and Cyclone IV devices I typically see clock delays on the order of 0.2 to 0.3ns. On the Cyclone V the clock delay reported by timequest is more like 4.7ns. This is for the same portion of the design using the same clocks and constraints as the earlier designs.

I suspect that the source of the problem is a difference between the newer Altera PLL and the older ALTPLL. On the older PLL the clocks were generated such that the clock distributed on the global clock network was seen at roughly 0 delay, but the new PLL is introducing a long delay, at least from the perspective of timequest.

Any suggestions for improving this clock delay would be greatly appreciated!

sglow:

So is your problem from I/O to register or register to register?

The clock tree in the device should be balance so that all the I/O will have a similar clock insertion delay. So even if there is 4+ ns delay for the clock to register A, it should have a very similar delay for register B.

However the PLL will either compensate for IO delay or not. (I know the old default was to compensate for this but I'm wondering if this changed)

So if this is not compensated for IO timing can be difficult.

Can you attach a timing quest report?

Pete

Hi Pete;

Thanks for the reply.

I have attached a zip file containing two timing reports. One report is from an older design using a Cyclone IV and version 11.1 software, the other is from a Cyclone V using 15.0 software. The older design passes timing without any problems and the newer design fails primarily due to the long clock delay. Both designs are very similar.

I'm no expert on Timequest, but as far as I can tell the clock delay reported is from the rising edge of the clock input pin to the internal clock arriving at the nodes. This input clock is multiplied up from 25MHz to 100MHz using a PLL. On the older design the PLL seems to be compensating the output from the PLL so that it occurs on the clock distribution tree with a very short delay relative to the input clock. On the newer design there's a fairly long delay between the input clock edge and the clock seen in the device. I have explored different settings in the PLL module, but so far have not been able to get it to compensate the clocks in a way that's similar to the older PLL module used on the Cyclone IV.

As you suggest, the actual difference between the clocks seen at various nodes within the FPGA seem to be small for both designs. My initial assumption was that since the clock delays were uniform throughout the design they shouldn't matter. Unfortunately, the longer clock delay is not playing well with my timing constraints and the result is that the fitter is adding undesirable delay elements on some of my input pins to compensate for these clock delays.

Thanks,

Steve

Ok looking at the timing report, the paths in question are from CLK100 to RAMCLK.

Can you describe how these are related? Are they both 100 MHz from the the PLL?

Anyway It appears the "Default" mode of the Altera_PLL is now Direct mode instead of source synchronous or zero delay buffer. This is probably the root of the issue. Page 3 of the PLL doc talks about this:

https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/ug/altera_pll.pdf

I would play with the Operation Mode on your PLL and I'm sure you will find a setting that will zero out that delay.

Pete