MIG (Memory Interface Generator)

[haul]

I inherited a working design that uses an DDR2 memory controller generated by ISE 10.1.03i, MIG 2.3. The original coregen project seems to have been lost, and I had to upgrade to ISE 12 because of a bug which was causing some of my logic to get to incorrectly get optimized away. Everything works fine post-synthesis, and simulation works fine, too, except that the design I have doesn’t have a memory model, so I can write, but every time I do a read I just get 0s. As you can imagine, this makes things difficult to verify.

I tried to generate a matching ddr2_model.v by using the current MIG (3.5), and I couldn’t quite get something to match up, using everything I know about the design. When I simulate with my new ddr2_model.v., I get the following error:

top_test.\gen_bytes[0].u_mem0 .cmd_task: at time 274896100.0 ps ERROR: Activate  Failure.  Initialization sequence is not complete.

Even though I ran the initialization command, and the memory controller reports that initialization finished:

at 272044 ns(5): Note: INITIALIZATION_DONE (/top_test/uut/ddr2/controller/).

I think I’m not be generating the exact same thing, because my parameters file is different, but editing it to match doesn’t seem to fix things. Below are the original parameters for the project, and what I ended up with when I tried generating ddr2_model to match. I’m only listing the parameters that differed (or didn’t exist), to save space.

Original:

`define   EXT_LOAD_MODE_REGISTER                   13'b0000001000100

`define   MAX_REF_WIDTH                            11

`define   MAX_REF_CNT                              10'b10000000001

New:

`define   EXT_LOAD_MODE_REGISTER                   13'b0000000000000

`define   RAS_COUNT_VALUE                          5'b00101

`define   RP_COUNT_VALUE                           3'b001

`define   MAX_REF_WIDTH                            10

`define   MAX_REF_CNT                              10'b1111100111

The module I'm trying to model is a Micron 32Mx8 DIMM. Any suggestions?

[haul]

To answer my own question, getting Micron's provided DDR module to work (http://download.micron.com/downloads/models/verilog/sdram/ddr2/256Mb_ddr2.zip) was pretty easy.

I'm still curious to know if there's a way to 'restore' an MIG project from just the controller, though, so I can convert the VHDL controller to Verilog. I'd like to do that because I've run into two mixed-language bugs already. One was fixed by moving from ISE 10 to ISE 12, but the other exists even in ISE 12.2 (and there's nothing in the changelog for 12.3 indicating that it's been fixed).

[gszakacs]

I'm not sure what you mean by "just the controller", but if you have the .xco file from the

previous CoreGen session, you can change your project options to provide Verilog

instead of VHDL and then "regenerate under current project settings".

Regards,

Gabor

[haul]

Unfortunately, I don' have the xco file. By "just the controller", I mean the VHDL for the top* components and the infrastructure_top* components.

Even more unfortunately, I think I've hit another mixed-language bug. I normally assume that my tools are correct and that bugs are my fault, but considering how many mixed-language bugs I've seen, I'm suspicious of this. When I do a read, the debug messages in the memory module show that the correct data is being read:

top_test.sdramddr2.data_task: at time 259301350.0 ps INFO: READ @ DQS= bank = 0 row = 1020 col = 000000c0 data = 11

top_test.sdramddr2.data_task: at time 259305100.0 ps INFO: READ @ DQS= bank = 0 row = 1020 col = 000000c1 data = 00

top_test.sdramddr2.data_task: at time 259308850.0 ps INFO: READ @ DQS= bank = 0 row = 1020 col = 000000c2 data = 33

top_test.sdramddr2.data_task: at time 259312600.0 ps INFO: READ @ DQS= bank = 0 row = 1020 col = 000000c3 data = 22

However, user_output_data from the memory controller always reads out 0. In particular, it seems like the FIFOs in interface_data_read somehow don't get connect correctly: The ddr_dq_in, wclk0, wclk1, and we signals are always X

On the bright side, the design works when I put it on the board, so at least this is "only" a simulation bug, and not another synthesis bug.

Thanks for the suggestion, though!