DDR2 Timing Problem in Nios System on Stratix III dev.board

[Altera_Forum]

Hey ... 

 I am a student and relatively new to the FPGA topic. I have an Altera DSP development board wit a Stratix III FPGA. I'm trying since a while to create a Nios II System which uses the DDR2 DIMM Memory of the board. The used Qsys System is attached.   Last Friday I got finally the Nios Processor to respond, but only if i set all Linker regions to the OnChip-Memory. The Memory Test it selves gives no answer, after 15 minutes running for an small address range it still gave no result.   So I think the external memory is not working properly. I also got a critical warning about Timing. My input clock of the board is the problem. The image is also attached. How can I get rid of this problem? Has anybody a solution.  I am also not sure if i constrained well the DDR2 dq and dqs signals the were unconstrained at first so I constrained them using a virtual clock and setting maximum and minimum delays to zero. The Errors disappeared but i am not sure if it was it the right way to do it. But I had trouble to find real values for this in the documentation.   Thanks for your time and help. Greetings from Spain. fabs

[Altera_Forum]

Look offcourse as evident you are not meeting timing. 

You have a setup failure for clk_in with a Worst case of 3.256 that means some path are violating timings. However one interesting point to see is the TNS is around 9.4ns. Well a rough guess leads me to think that there are some false paths which needs to be set because your worst case slack ie 3.2 ns is quite high comapred to your TNS. How many paths are failing in your design? Use timequest timing analyzer's report_timing option to report all the paths, because i really dont get the relation between WNS & TNS for clk_in. As you must be knowing that TNS is just the summation of all the negative slack of the failing paths. As a rough guess some 3 or 4 paths must be failing which is absurd, because quartus wont P&R in such a way that the whole design is meeting and some paths are failing that too with a -ve slack of -3.25ns. But its really hard for me to comment on the number of paths failing. Check for false paths in the design and also do report_timing and see how many paths are failing and what are the launch and latch edges (for asynchronous clock transfers)

[Altera_Forum]

Although I am also a newbie but still what i can think from i knowledge makes me to comment so. :)

[Altera_Forum]

Thanks a lot for your answer. 

 I focused now a little bit more on the timing analyses. I checked the false paths and the reported the timing of my clock source.  The problems are caused by the status output of the UNIPHY Controller with the outputs phy_cal_fail, phy_cal_sucess and init_reg_done. And finally in my design these outputs are connected to LEDs.  I think the problem is that the Latch and Launch clock are not the same. The Launch clock is a PLL of the UniPhy Controller whereas the Latch Clock is my 50MHz Input Clock.  Can you maybe give a hint how to change that? Or do you think thats may be not the reason for the problem.

[Altera_Forum]

Yup if your lauch and latch clock are different specially different in frequency then you are bound to violate timings. 

You can set clock groups between the clocks like exapmle set_clock_groups -exclusive -group [get_clocks virtual_clk] -group [clk_in] -group [copy and paste the name of the pll generated clock exactly as reported with the hierarchy] i dont think the clock groups for virtual clock is required as it doesnt feeds any port but i am not 100 % sure so just keep it to be on the safer side.

[Altera_Forum]

Thanks for the hint. 

I am compiling right now and then i will try it on the board and will let you know it resolved the problem.

[Altera_Forum]

Yup no probs. 

GOOD LUCK :)

[Altera_Forum]

Hmm.. Timing Analysis results are good but the DDR2 Memory is still not working in the NIOS 2 Eclipse environment. 

At the moment I dont know what can be the reason. This morning I tried the same system with the discrete Memory chips on the board and it worked quiet fine.  Do you can think of a possible reason?

[Altera_Forum]

Can anybody tell me why this sdc command is ignored. 

  --- Quote Start ---  set_false_path -to [get_pins -compatibility_mode -nocase *|alt_rst_sync_uq1|altera_reset_synchronizer_int_chain*|aclr]  --- Quote End ---    I checked the filter and its in fact empty. But why the Qsys is generating the command if its ignored at the end? Can this be a possible reason for my problems?

[Altera_Forum]

Try this 

 set_false_path -to [get_pins -compatibility_mode -nocase *|alt_rst_sync_uq1|altera_reset_synchronizer_int_chain|aclr*]   2 stars enclose the total filter.

[Altera_Forum]

I dont know why a space is being inserted in the word chain in my post. 

Please omit the space.