Cyclone V speed is much slower

So I heard back from Altera support on this. It looks like the long clock delays are a fact of life on the Cyclone-V. To quote Altera support:

"Since the clock network structure of Cyclone V is different than the old device, we will expect a longer delay in the clock path."

I'm experimenting now with manually phase shifting the PLL to try to improve my timing, but it's a bit disappointing to find that the Cyclone-5 has so much more delay on it's clock network then the Cyclone-3 or 4 devices.

Yes, I think I've got the constraints right. The problem is that Quartus can't make the timing constraints on the Cyclone 5 while the identical project using a Cyclone 4 meets timing with no problems.

I've got a service request in with Altera now, so I'll post back if I can get to the bottom of this.

Thanks,

Steve

Hi Pete;

I've been playing with the PLL settings in qsys this morning, but so far can't find any setting that reduces the reported clock delay. Changing to source synchronous mode actually increased the reported clock delay to 5.7ns. From the PLL documents it sounds like normal mode should do the trick, but no luck there.

I haven't tried zero delay buffer yet since I don't have a clock output to connect to.

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

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

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

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!