DDR2 VHDL Simulation model for Altera DDR2 controller

[Altera_Forum]

Hi, 

 I am looking for a DDR2 simulation model in VHDL (due to license restrictions) that will work with the ALtera DDR2 controller. The controller was implemented by somebody else, is verified to work in hardware, now I want to get the simulation working. I used a Hynix model which worked fine in another project with the Xilinx MIG DDR2 interface (though I had to tweak it a bit). With the Altera controller the calibration process is performed, obviously, signals like "local_ready" and "init_done" are asserted and refreshes are triggered periodically but when the memory is read out the rdata_valid signals are never asserted. The Altera functional simulation model simply is too complex to find out, what's the problem and fix it in the model.  Can someone recommend a DDR2 VHDL simulation model for the core?  Best regards flintstone

[Altera_Forum]

Meanwhile I tried with a Free Model Foundry Model and it does not work either, but the error symptoms are different, now during calibration only one write and one read is performed. I have no idea how to debug this issue but I will try further. The whole algorithm that I am trying to develop relies scheduling DDR2 readout vs sending the data over an external interface. I need a working DDR2 memory model to verify this. 

 Really, this might not be the right place for mourning, but these things belong to a working ecosystem for a developer. And it can't be too hard to provide some generic memory model to be able to simulate a standard system without paying high license fees just to be able to include the state of the art memory component in the development process.  Best regards, flintstone

[Altera_Forum]

Ok, got it working with the Free Model Foundry Model mt47f256m4, though there was an error in write burst timing that I had to fix.  

 If you try the same look out for this assignment:  In_data <= '0', '1' AFTER 3*CK_period/4 - 0.5 ns;  and change it into this assignment:  In_data <= '0', '1' AFTER 7*CK_period/4 - 0.5 ns;   I did not think about it in greater detail, maybe the problem does not arise with higher clock frequencies than the 156.25 MHz I use.  flintstone