Hi, I have a SDRAM controller running at 133MHZ which is currently violating the setup requirements of the RAM. I have a register connected to an I/O pin which tri-states the data bus when the FPGA OE is un-asserted. The timings for the register are: Clock delay (2.7) + oe signal delay (0.2) + register delay (3.3) + RAM setup time (1.5) = 7.7ns This results in a violation of 0.2NS. I'm not sure what to do as the delay is completely within one cell, there are no other routing delays except for the global clock. I have taken the following measures to avoid this problem: - Ensured the clock of the tri-stating register is global - Enabled "Fast Output Register" - Enabled "Fast Output Enable Register" - Enabled "Speed Optimization Technique for Clock Domains" - Registered the databus signal with the system clock - Fitter effort set to 3 The Cyclone II i'm using is about half full and i'm just about out of ideas. Any advice would be greatly appreciated! Evan

The output delay chain is probably already at its fastest setting, but that's something to check. Consider using a PLL to shift the clock of the output registers to reduce the FPGA tco.

Hi Brad, Thanks for your suggestion, I've checked the output pin delay in the resource property editor and it was already on the lowest (105ps). Unfortunately I'm already using all available PLLs. Is this an inherent limitation of the Cyclone II device? I would have thought 133MHz would have been reasonable, but perhaps i'll have to consider running the memory at 100MHz. Anyone else had experience with a SDRAM controller running at this speed on a Cyclone II or similar devices? Thanks, Evan.

If you can't use a PLL, perhaps it would just happen to work out to invert the clock for the output registers to adjust the timing by a half period. You might then have to slow the output delay chain if the half period is too much. Are you certain you have the I/O timing constrained correctly? You should use both maximum and minimum output delay constraints (preferred for either timing analyzer) or both tco and min tco (OK for the Classic Timing Analyzer). If you are just calculating the timing manually, you might have missed something.

If anything, the limitation is on the number of PLLs. All devices have long clock tree delays, and they actually get longer in the higher-end parts, but the PLLs are designed to counteract this. At those speeds, you may want to take the clock off a global, especially if the source is anywhere near the SDRAM interface. Local routing can actually be faster, getting you a faster output, but you will get more skew across the bus since local routing is not de-skewed like a global tree. This output skew may be perfectly acceptable though.

Thanks for the advice Brad and Rysc, I've gone back and reviewed my timing constraints in my SDC file. I think i've incorrectly put the setup time where the max tco should be. Here's what i've got now: set_output_delay -add_delay -clock [get_clocks {clk_133}] -reference_pin sclk_p -min -0.800 [get_ports md_p*] set_output_delay -add_delay -clock [get_clocks {clk_133}] -reference_pin sclk_p -max 6.000 [get_ports md_p*] With a system clock of 133MHz (7.5ns period), would these would correspond to the RAM requirements of a hold time of 0.8ns and a setup time of 1.5ns? If so then i don't have any timing problems and I'd be very happy!

Clock network delay + internal cell delay > Minimum timing requirement

26 Replies

Altera_Forum
Honored Contributor
18 years ago
--- Quote Start ---
Looking at the first picture i posted:

http://img120.imagevenue.com/img.php..._122_747lo.jpg

The clock network delay + data delay values should ensure that the hold and setup times are met.
--- Quote End ---

That link didn't work for me, but it sounds like you're looking at the same timing report to look at both tco (setup) and min tco (hold). Did you do report_timing for both setup and hold for the device output pins?
Altera_Forum
Honored Contributor
18 years ago
Sorry, here's that link that didn't work:

http://img120.imagevenue.com/img.php?image=89373_timing_diagram_122_747lo.jpg

Here's the timing report for hold time:

http://img144.imagevenue.com/img.php?image=11386_hold_slack_122_723lo.jpg
Altera_Forum
Honored Contributor
18 years ago
Well I believe I've found a solution, though I had to mod the board. I've re-routed (externally) the system synchronous clock to a Dual-Purpose DPCLK/DQS pin (previously using a LVDSCLK input). These pins have "dedicated DQS phase shift circuitry" that can be used to delay the clock. I've played around with the delay parameter and can achieve a global clock network delay anywhere from 2.7ns to 6.5ns. Since the period of my clock is 7.5ns, neither of these delays is great enough to solve my problem, and so i've used a delay value of ~4ns and inverted the clock, to achieve an effective phase shift that should negate the global clock network delay.

My only problem now is how to configure time quest to report based on the new delayed + inverted clock. Time quest has obviously detected i'm using an inverted clock and is now reporting everything based on the falling edge of the original clock. Does anyone know how i can avoid this? I'd like it to treat the new clock as if it was an external input, and not derived from the original clock input.

Thanks for your time, esp Brad and Rysc.
Altera_Forum
Honored Contributor
18 years ago
I don't know whether you'd have to make an adjustment for the clock inversion. In most cases TimeQuest does what you need automatically, but in some situations you need to tell TimeQuest the clock edge you care about.

It sounds like you now have a source-synchronous setup for which you can use the -reference_pin method. Instead of -reference_pin, you can create a generated clock on your new clock output device pin and use that generated clock in the set_output_delay constraints.
Altera_Forum
Honored Contributor
18 years ago
But i'm still using an external clock input? The only difference is now i'm phase shifting that input clock to counter the global clock network delay. Its still driving all the internal logic and launching the data.

While in principal this idea should have worked, i found through experimentation the delays given by time quest did not represent measured delays at the output. This meant the amount by which i was phase shifting the clock was unknown and was unreliable (data corruption resulted). So i've scrapped the whole idea and i'm back to square one.
Altera_Forum
Honored Contributor
18 years ago
I didn't think through your previous post well enough and got the wrong idea. I was thinking you meant that you rerouted the clock to a different pin to drive it out to the SDRAM.

Since you've already been willing to modify the board, maybe you should go ahead and change the clock to a source-synchronous output (what I wrongly thought you did). If the only thing connected to the SDRAM is the FPGA (SDRAM buses not also accessed by something else), if the board connections allow this kind of change, and if the timing analysis says that's better, it might be worth the trouble.
Altera_Forum
Honored Contributor
18 years ago
Can you attach a sample design and identify which pins the data is going out on? Please make it as similar as possible, i.e. the same device you're using, with clock and data pins assigned to the same pins, and the PLL configured the same way? Also, in a sentence or two, give a quick description of how the clock drives the FPGA, how it drives the upstream device, the upstream device's requirements, and the board delay from the FPGA to the upstream device? This shouldn't be too hard, but I think we're having difficulty trying to describe what's occuring with words rather than just doing an actual design. I'm out tomorrow, but will take a look at it the next day and get something back to you. This way we have something we can all work from. Thanks.
Altera_Forum
Honored Contributor
18 years ago
Thanks for your suggestion Brad, but unfortunately the clock is generated by the CPU, which also requires access to memory.

I have come to my conclusion, and that is there are only two solutions to this problem:

- Increase the track length of the clock from the FPGA to the RAM (to delay the clock by the required 200-300 ps relative to the data)
- Move to the next speed grade (-7)

I talked to my altera representative and he basically confirmed these timing problems are inherent limits with my device. He also suggested i ensure the global system clock only feeds into clock inputs of LEs, as otherwise this can increase the clock network delay substantially. So having done everything possible I'll have to ask my superiors what action to take.

So my advice to anyone implementing a system synchronous data bus, make sure you have a pll free!

Thanks for your suggestions Brad and Rysc.
Altera_Forum
Honored Contributor
18 years ago
Agreed. Going above 100MHz without a PLL is pretty fast. Another problem of not having a PLL is your variance over slow/fast timing models. Static timing analysis does a default slow model timing analysis, but you'll also want to run a fast model analysis, and now that all your delays can vary over this range with Process/Voltage/Temperature. The PLL not only removes the global clock tree delay, it removes it in a PVT invariant way, so that your timing analysis volitility is reduced.
Note that reducing the fanout shouldn't make much of a difference. The global trees are pre-laid out and rebuffered throughout, so most of the loading will be on side branches that have minimal capacitive affect.
Did you try taking the clock off a global? (You may have responded to this, but the thread is getting long.)
Also, if you're failing by 200-300ps, I can say almost without a doubt that your interface should work on a nominal board(you're not at the worst case PVT corner, so all the delays will be faster than the slow model reports). If you're seeing failures, I think something else is going wrong.
Altera_Forum
Honored Contributor
18 years ago
Sorry Rysc, i didn't see your reply. He's a simple drawing of my bus:

http://img120.imagevenue.com/img.php?image=01654_system_122_927lo.jpg

The delay between the CPU and FPGA is around 200ps.
The delay between the FPGA and RAM is also around 200ps.
The FPGA i'm using is the EP2C5F256C8.
There is no PLL (already both being used to generate audio clocks.)

I've uploaded an empty sample project, basically with the *.qsf assignments and the top level of vhdl (just a wrapper where i register the data outputs).

My timing problem occurs on the output of registered data on the I/O pins md_p[0 .. 31].

Basically all the delay is within the fast output register at the pin, and so theres simply nothing i can do to reduce that delay except make sure the clock gets there sooner (or equivalently to the ram later.)

Thanks for helping anyway, I think i'll be pushing for a faster speed grade.
Sample project.zip9 KB

Forum Discussion

Clock network delay + internal cell delay > Minimum timing requirement

26 Replies

Recent Discussions

Quartus 20.1std compilation fails for Quartus map - Device 10AS057K2F40I1SG

Is Quartus Prime Pro 22.4 Compatible with Stratix 10 NX Series Device?

Timing analysis - long combinational path

QuartusPro 25.3 Crashed after using the Signal Tap Logic Analyzer

Duplicate_hierarchy_depth / duplicate_register