Problem with SDRAM Timing

Question

Why does my design only work with the “syn_keep” attribute and the delay chain “clk_sdram <= sdram_clk”?

My project is the design from a Digital Camera. I just constrained my clocks, see sdc file. As a result I don’t get any corrupted data. I can’t see white spots in my test pattern image.

When I remove only the attribute “syn_keep” I get white spots in my test pattern image. Without any doubt this comes because the SDRAM timing is violated.

When I remove only the delay chain “clk_sdram <= sdram_clk” I get white spots in my test pattern image. Without any doubt this comes because the SDRAM timing is violated.

Can anybody explain what’s happens when I remove the attribute or the delay chain. What is the best way to analyze my design to find out what happens? What is the best way to constrain my design/ SDRAM.

I just constrained my clocks because every time I assign input and output delay’s (setup and hold time) for the SDRAM I completely messed up my design so that nothing worked anymore.

following my .sdc file:

# **************************************************************

# Create Clock

# **************************************************************

create_clock -add -name {IFCLK_IN}

-period 20.83

-waveform {0 10.416}

[get_ports {IFCLK_IN}]

derive_pll_clocks -use_tan_name

following parts of my top level:

attribute syn_keep: boolean;

attribute syn_keep of clk_sdram : SIGNAL is true;

.

DCM1 : PLL1

PORT MAP

(

areset => '0', -- pll_reset,

inclk0 => IFCLK_IN, -- 48MHz

c0 => clk_pixel, -- 24MHz,

c1 => sdram_clk, -- 96MHz

c2 => clk_sample, -- 192MHz,

locked => nlock1

);

clk_sdram <= sdram_clk; -- keep delay chain doesn't work without ???

Tks!

altera_forum · Answer

I wonder if you constrained your design in a way, that defines the complete SDRAM timing. Probably you didn't.

But anyway, the timing driven place and route process wouldn't modify the timing more than selecting between available alternatives. It will not add additional delay elements or assign fast input- or output registers where they are needed. It will at best (if constrained completely) report, that the timing isn't met, if it's limited means of correction are exhausted.

In other words, apart from constraining the design, timing adjustments may be necessary. For existing SDRAM reference designs, a lot of different measures have been suggested, including defining phase shifts for individual PLL clocks.

altera_forum · Answer

Thanks for the answer!

The posted SDC file is all what I constrained.

The timing violation is repeatable. I know where it happens (SDRAM) but how can I can confirm the timing violation. How can I explain what happens with the attribute or without , with the delay chain or without?

altera_forum · Answer

Note that the output of a PLL always drives a global. My guess is that your keep is basically telling it to keep that subsequent net, so it gets off that global and then probably gets back onto another global. So that's a really long delay being added to clock tree. To a certain degree, this counters the benefit of having a PLL. Plus, it's probably just luck that it happens to work. I would almost ignore that for now, and concentrate on your constraints.

Basically, you've constrained the internals but not the I/O ports, and therefore the SDRAM interface is not constrained. Are you sending a clock to the SDRAM, or is it a board level clock being used? Anyway, make sure you understand the I/O timing and start adding constraints.

altera_forum · Answer

That's right, I haven't constrained the I/O's.

I' am sending a clock to the SDRAM. The clock clk_sdram, see previous post, is directly connected to the SDRAM.

Do you suggest that I delete the attribute and the delay and then start to constrain my design?

Is there any possibility to confirm the long delay or to find out if the clock is a global clock or not.

altera_forum · Answer

I would delete the attribute, as it's not common practice to delay the clock. report_path -to clkout_name should get you the timing(although I'm not positive, as it might not since it's a clock and not data, but I think it should work). You can look in the fitter report at global usage too.

Since you're forwarding a clock, the big question is if you're accessing data on every clock cycle? If that's the case, you probably have somewhat tight timing requirements(depending on clock frequency). Most likely you're doing something more simple, like setting the address, data and control one one clock cycle, then turning on the enable the next cycle, then turning off the enable, and then changing the data/address, etc. If that's the case then you have multicycles to play with.

Also, you need to no your board delays and SDRAM access timing. I/O timing is one of the more difficult things to do, but it should be since it's a complicated thing. Have you studied the I/O timing constraints set_input_delay and set_output_delay? Just put some in with a value of 0ns as a starting point. Also, on your outputs, you need to put a generated_clock on your output to use for your clock. Look at the source synchronous output examples at:

http://www.altera.com/support/examples/timequest/exm-timequest.html

Forum Discussion

Problem with SDRAM Timing

6 Replies

Recent Discussions

USB-BlasterII mounts as "USB-Blaster variant"

Quartus Dark Theme on Linux - Solution

Error(23098) when using IPM_IOPLL on Agliex 7

Quartus 13.1 License

Highlight similar instances of a selected word fails when scrolling