Hi all,I am working with DDR2 SDRAM and I have built a DDR2 SDRAM Controller in Startrix IV (an UniPHY IP) using MegaWizard Plug-In Manager Tool of Quartus 11.1. I have also written a simple testbench for checking this IP's functions. Everything is OK, when I run the testbench and the DDR2 Controller (UniPHY IP) in RTL. Thus, I have compiled the DDR2 Controller to get its gate-level model for gate-level simulation, but the result is not good. in details, ddr2 controller (in gate-level simulation) does not initialize correctly. So, my question is "what is the way to run my DDR2 SDRAM Controller simulation in gate-level?" I am looking forward to all your contributions. Finally, thanks for all your supports.
how can DDR2 controller does not instantiate correctly in gate-level simulation? you said it was ok in RTL simulation, but remember RTL is just functional simulation that does not take care of delays in the hardware. If it worked in RTL but not in gate simulation, you might wanna check your timing constraints in SDC file (or see your timing analyzer if the timing fails)
Hi jacklsw86,Firstly, thank you for your comment. I run synthesis the DDR2 controller and generate its post-fit model (.vo and .sdo file). When run this post-fit model with my testbench, the PLL block in the controller give the right output signal, but the others do not. Command signals to memory (like: mem_cs_n, mem_cas_n, mem_ras_n, mem_we_n,...) is not the same with functional simulation. In functional simulation, DDR2 Controller will automatically generate a sequence of commands that will initialize and calibration the memory. However, with gate simulation, the command remains at No Operation. It means that the initialization fails. Can you talk more about timing constraints in SDC file? I think that we only need .vo and .sdo file to run gate-simulation. How to make the SDC file and put it into the testbench or .do file?
Yes, you only need .vo and .sdo files to run gate-level simulation but SDC file affects your implementation (fitter). constraint your clock so that the quartus can fit the design properly. (eg. say you are using 100MHz clock, specify the clock period in .sdc file). run timing analyzer to see whether there are any timing violations (setup or hold error).most likely your design does not meet timing closure if you said it is working in functional simulation but not in gate-level simulation. try to look for the timequest analyzer tutorials in altera website for more details.
Hi jacklsw86,Thanks for your reply. I found the reason why the gate level simulation behaved uncorrectly. This is the fault of Quartus II. So if we want to verify the timing, we have to use the TimeQuest Timing Analyzer tool.