Constraining SDRAM

[Altera_Forum]

Hello, 

I have a very strange issue on my EP3C55F484, when sometimes Nios II processor works, sometimes - not. One minute I am able to upload the binary, it works fine for a half of a day even if I do a dozen times of re-upload and debug, but suddenly *bam*, it doesn't allow to upload a new binary:  Pausing target processor: not responding. Reseting and trying again: FAILED Leaving target processor paused   Sometimes it happens on the beginning of a day, sometimes at the end of the day, but there are no tendencies - completely random issue. I've checked hardware - everything should be fine, all voltages are correct. PLL working fine, no lock losses.  My constraints are not complete or bad, I am not sure where I am doing a mistake, so let's look what I have: SDRAM chip: Micron MT48LC4M16A2P-75 - datasheet here. (http://www.micron.com/parts/dram/sdram/~/media/documents/products/data%20sheet/dram/47264msdram.ashx) The Qsys design runs on 62.5MHz, clocked from PLL output 0. The SDRAM chip itself, is clocked @ 62.5MHz -3ns phase shift, PLL output 1. TimeQuest reports Fmax of 71.5MHz  The first thing to do is to define timing parameters from datasheet:  set SDRAM_PCB_DELAY 0.10 set SDRAM_ACCESS 5.40 set SDRAM_DATA_OUT_HOLD 3.00# CS#, RAS#, CAS#, WE#, DQM, ADDRESS - will be named as MISC set SDRAM_MISC_HOLD 0.80 set SDRAM_MISC_SETUP 1.50   Then, I need to define a clock and its output delay:  create_generated_clock -name sdram_sys_clk_pin -source {PLL0|altpll_component|auto_generated|pll1|clk} set_output_delay -clock sdram_sys_clk_pin $SDRAM_PCB_DELAY   Now, constrain I/Os:  set_input_delay -clock sdram_sys_clk_pin -min }] set_input_delay -clock sdram_sys_clk_pin -max }] set_output_delay -clock sdram_sys_clk_pin -min sdram_sys_ba sdram_sys_dqm sdram_sys_ras_n sdram_sys_cas_n sdram_sys_cs_n sdram_sys_we_n}] set_output_delay -clock sdram_sys_clk_pin -max sdram_sys_ba sdram_sys_dqm sdram_sys_ras_n sdram_sys_cas_n sdram_sys_cs_n sdram_sys_we_n}]   Set relationship between clocks:  set_min_delay -0.60 -from {PLL0|altpll_component|auto_generated|pll1|clk} -to {sdram_sys_clk_pin} set_max_delay 0.52 -from {PLL0|altpll_component|auto_generated|pll1|clk} -to {sdram_sys_clk_pin}   At this point, I should constraint all paths using multicycles, but I am not sure, how multicycles would work in this case. If I add set_max_delay, then the delays are way too long: TQ says I need to add almost 10ns delay, which is strange..? I am attaching result of: report_timing -setup -npaths 100 -detail full_path -file "TQ_100worstpaths.txt"  You'll see, that I am using 5 SDRAM controllers: 1 for Nios and 4 buffer for data, but the issue is the same for all. It fails timing between I/O pin and first data register (qsys_system|etc|some|controller|stuff|za_data [*])  P.S. I don't get any hold/removal/recovery violations for that particular clock.  Maybe someone could point me how to solve that setup violation problem and what am I doing wrong? Thank You.

[Altera_Forum]

I'm not a TQ expert, but I guess your problem is the 2.9ns setup relationship between the clocks; I think it will never be met with the specified delays. 

Did you try to compile and run the design without all those constraints? Does it work? I have a similar design with same SDRAM device but never had such problems.  The only major difference is that my sdram clock shift is only -0.75ns.

[Altera_Forum]

Hm, why did You choose -0.75ns? 

According to datasheet page 23, data out hold time (tOH) is 3ns, that's why I am using another PLL output with the same frequency, but different phase shift for the SDRAM chip itself. Afaik it is a common approach to use such clocking method or I am missing something here?  Design without constraints does work exactly the same. Or... I would say doesn't work exactly the same. Completely random. One upload the same binary works, try to upload again - it doesn't...

[Altera_Forum]

The 0.75ns shift was actually already calculated when I started working on that design. I have somewhere the documentation which explains how it has been calculated. If I can find it I'll tell you. 

The use of another pll output is correct, That's what I do, too. Do you mind trying to recompile with no i/o constraints and clock phase shift reduced to -0.75ns and check if this way the design works?

[Altera_Forum]

Yes, I can test that, but if it will work today, it could fail tomorrow, so the test will take some time. 

 Could You post the memory chip model please?  EDIT: I've tested with -0.75ns phase shift and it doesn't work. Since I've commented out all the constraints, there are no SDRAM violations in TQ.

[Altera_Forum]

Random thoughts 

- The datasheet refers a "no-load" data out hold time of 1.8 ns. Try using that value instead of 3.0 ns.  - You're always adding 0.100 ns delay for the PCB. But the PCB delay isn't the always 0.10 and isn't the same for all signals. In particular, the clock may be delayed more or less than the other signals. Also, for signals coming from the SDRAM, you need not only to account for the PCB delay the signals suffer between the SDRAM and the FPGA but also the delay the clock suffers between the FPGA and the SDRAM.  So, I'd use something like this  set_input_delay -clock sdram_sys_clk_pin -min }] set_input_delay -clock sdram_sys_clk_pin -max }] set_output_delay -clock sdram_sys_clk_pin -min sdram_sys_ba sdram_sys_dqm sdram_sys_ras_n sdram_sys_cas_n sdram_sys_cs_n sdram_sys_we_n}] set_output_delay -clock sdram_sys_clk_pin -max sdram_sys_ba sdram_sys_dqm sdram_sys_ras_n sdram_sys_cas_n sdram_sys_cs_n sdram_sys_we_n}]   A final matter I didn't get: with these constraints alone, do you get timing violations in TQ or not?

[Altera_Forum]

I do, the report was attached. The only violation is between data pin sdram_dq 

[*] and controller output register za_data [*].  I will attach a screenshot later.

[Altera_Forum]

Here it is: http://i46.tinypic.com/13zvqy9.png 

 Basically, it's the same, I've attached before. Other setup/hold timing violations are not related to memory, so I want to fix this place first.

[Altera_Forum]

Ok. So, from what can see the problem is as follows 

 The SDRAM launches data at the rising edge of sdram_sys_clk_pin (@13 ns) and the register captures it at the next rising edge of pll|c0 (@16 ns). So, you only have 3 ns to absorb the delays. Which, as Cris said, will never work. $SDRAM_ACCESS eats up 5.40 ns alone. Plus pin to register delay, clock skew and uncertainty. All in all, you're 7.256 ns short.  What you need to to is change the -3ns phase shift value into something else, in order to have more time. -10.256ns does look promising.   But 0 is probably the best starting point.

[Altera_Forum]

Hm, that's strange, but looks interesting. Anyway, if I use phase shifted clock method, I know that I need to use multicycles. If I understand correctly, if I set multicycle 2 for setup, then the data should be sampled on the second rising edge of the pll|c0, which should give me additional 16ns? 

 Sorry, I am not exactly sure what multicycle does.  Actually, it is strange, that in my case, I need to use such a long delay, when Cris told, that he use way smaller phase difference.   EDIT: I've tried to set phase difference to -10.2ns. This obviously helps TimeQuest to show me, that there are no setup violations made, but if I try to upload Nios design (at least it allows to try to upload!), it says that verify has failed between some addresses... Now trying other options.

[Altera_Forum]

Setting multicycle 2 would give you additional 16ns, as you said, but that's not what you need. 

Infact this assumes the sampling device waits one more cycle before latching the data into the register. So you can use multicycles where the system really perform multicycle accesses, for example if it explicitly requires delays or waitstates. Otherwise TQ would tell you the design meets timing but actually it will NOT work.  In general, setup violations are frequency dependent, while hold violations are not; so you can get rid of negative setup slack if you reduce frequency. Going back to your original post, you can try to reduce system frequency from 62.5 to 50MHz: if the random problem still remains the same, it's probably not a setup timing issue.  Last remark: did you try a sdram clock shift reduced to about -1ns as I suggested? I checked your memory datasheet and it matches mine. Moreover I use a EP3C40, so I guess what is good for me should probably be good for you. With the -0.75 phase shift I could always operate my design without problems from 50 to 100MHz.

[Altera_Forum]

I did try with -1ns, but that didn't help. 

 I am observing interesting thing. I've routed sys_clk signal to debug output pin and set the PLL phase difference between sys_clk and sdram_chip_clk to -6ns. The scope shows me, that the difference between these two signals is -3.2ns. I didn't check that before, but if there's such a huge difference, then I believe I had way much smaller phase difference, when used PLL settings for -3ns. So far, the design is working fine with -6ns @ PLL settings, but as You may know, I still see problems in TQ. Maybe adding max delays will help.

[Altera_Forum]

--- Quote Start ---  I've tried to set phase difference to -10.2ns. This obviously helps TimeQuest to show me, that there are no setup violations made, but if I try to upload Nios design (at least it allows to try to upload!), it says that verify has failed between some addresses... Now trying other options.  --- Quote End ---    And no hold violations either?  If you get a clean bill from TQ and it still fails, then it gets exotic a) the constraints aren't correct (can't see how, though...) b) TQ is missing something (very rare but not impossible) c) the datasheet is wrong d) the hardware is faulty and doesn't meet the datasheet  At this point, I'd just try to add a bit of safety margin into my constraints and shift the PLL clock a bit more.

[Altera_Forum]

I don't know if it matters and how TQ calculates all delays, but I use ALT_DDRO to output the clock.

[Altera_Forum]

ALT_DDIO_OUT? Why? 

  That said, TQ can model all the delays inside the FPGA. Though.. ALT_DDIO_x might have some kind of embedded false path exceptions (rising to fall and fall to rising).