Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

SDRAM setup violation when reading

Hi,

I am using a Cyclone 4 FPGA running at 100Mhz.

My design has a SDRAM interface also running at 100Mhz.

Currently the PLL is generating 1 clock, which is used to clock the SDRAM data registers and is directly driven out off the FPGA (via non dedicated routing).

I am not using any ALTDDIO buffer.

After synthesis, I have a setup timing violation of ~0.1ns when reading.

In Timequest, the path is reported as follow: ~2.9ns clock delay + 6ns input delay + ~1.1ns data delay.

I've been reading several documents (including AN433), looking in the forum, but I am still a bit confused what is the best way to fix this.

I read that the ALTDDIO output buffer improves the skew. But when I tried to use it, it also degrades the timing (clock delay is bigger).

So it does not look like the solution for me.

Now, I am thinking about using a new clock from the PLL that I can compensate to meet my timing.

In such a case, should I also use the ALTDDIO buffer ?

Or should I use the PLL dedicated output pin as sdram clock ?

But in such a case I can’t control the phase.

Or is there another solution ?

Thanks for letting me know what you think is the best solution to fix this.

Thanks,

Frederic

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Are you sure the analysis is correct? Note that a lot of that 2.9ns clock delay(which I assume is the path for the clock to get off chip so it can be sent to the sdram), should cancel out with the Data Required Path, whose latch clock goes through a similar delay(it doesn't go through an output buffer). Attach the timing report if you want, but be sure to do "report_timing -setup -npaths 1 -detail full_path ..."

    6ns is the external round-trip delay, correct? That's what is really chewing up a lot of you margin.

    Using another phase of the clock to transmit or receive should work. Another option is to clock data in on the falling edge, and then add a multicycle to tell timeQuest you're shooting for the next edge:

    set_multicycle_path -setup -from [get_ports {sdram_data_in[*]}] 2

    That should make the setup relationship 15ns on these paths and the hold relationship 5ns. If your external -min delay is relatively large, say 3ns, then meeting that min requirement should be pretty easy.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Thanks for your fast reply!

    note that a lot of that 2.9ns clock delay(which i assume is the path for the clock to get off chip so it can be sent to the sdram), should cancel out with the data required path, whose latch clock goes through a similar delay

    This is only valid when writing. Or am I missing something?

    When reading, the memory spec. gives a 6ns access time. I don't have a lot of margin...

    As I don't want to modify the SDRAM controller, I will go for a second clock with another phase. Does it make sense to use an ALTDDIO buffer ?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Altddio for the clock? It can make a slight difference, but it's not significant.

    Clocking on the falling edge is the same thing as shifting 180 degrees, just saves a clock tree. But if they're available, shifting gives you more granularity. Just be sure to note where you might need a multicycle.