1. Home
  2. Field-Programmable Gate Arrays
  3. Xilinx core generator MIG module generates a slow timing for a DDR2 SDRAM controller

Xilinx core generator MIG module generates a slow timing for a DDR2 SDRAM controller

Hello.

I've used the Xilinx core generator MIG module to generate a DDR2 SDRAM controller. The design supports generics for the ram timings. E.g. 15000 ps for the precharge-command delay (tRP). When I simulate the interface and measure the tRP it is much longer (in my case 26350 ps). This problem also occurs with all other timings e.g. ras-to-cas delay (tRCD) should be also 15000 ps (generic value) but I measured

33750 ps.

These long timing values reduce the maximum throughput for short write and read burst extremely. Does anybody know why the interface values differ from the generic values?

thx DaMicha.

Reply to
damicha
Loading thread data ...

Hi,

Do you have the same clock period in the simulation as you have specified for the MIG core?

Göran

Reply to
Göran Bilski

Yes, I have. They are the same: 3750 ps for 266.67 MHz. I set the clock frequency with the MIG and the clock period in the test bench (constrain CLK_PERIOD) and I measured the clock period in the simulation wave form.

DaMicha.

Reply to
damicha

Yes the generated timings are miscomputed ... They forgot to take several thing into account ... You can modify the _parameters.vhd file yourself and change the value. There is only

4 or 5 important ones. To redure the wtp and wr to their minimum I think you'll have to modify the _ddr2_controller.vhd file and force them ...

To understant how to compute the delay, look at their state machine and how they use the value you specify.

Sylvain

Reply to
Sylvain Munaut

Hello.

OK, my target FPGA is the Virtex5 (I forgot to mention that). The designs generated by the core generator are different for Virtex5, Virtex4 and Spartan3. For the Virtex5 I found the timing calculations in the mem_interface_top_V5_ctrl_0.vhd file. There are some deviations between the comments and the code. e.g. for tRP:

-- TRP: PRECHARGE->COMMAND interval - 2 constant TRP_CYC : integer := (TRP/CLK_PERIOD) + 1;

When I change the calculation for TRP_CYC in the code like this:

constant TRP_CYC : integer := (TRP/CLK_PERIOD) - 2;

the tRP time will be shorter in the simulation (less clock cycles are used).

This seems to be better but I'm not sure about the reason of the original code. Maybe my "corrected" design with the new timing will doesn't work with real hardware.

Is there any official information for my problem or has anybody a hint for me?

thx DaMicha.

Reply to
damicha

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.