Opencores DDR2 SDRAM controller with spartan3e starter board

Ok, tried it for weeks, now I give up and ask for help...
I have a Spartan S3E starter kit board with a 46V32M16 DDR2 SDRAM on
it. My design needs to read and write 32 bit words to SDRAM. I tried
MIG 2.2 from the Xilinx coregen tools, but couldn't get it to work.
Finally I found a controller design originally written by Markus Lemke
and then modified for the Spartan S3E by David Ashley at Opencores.org
(thanks to both!). The testbench included was simulated and
synthesized fine, and works with the board as well, as far as I can
tell from the LEDs.
However, when used in my design, it fails. The design is first
writing, then reading several hundred words of data from the SDRAM.
The first word reads back ok, but all others are zero. I can see this
in the simulation as well as when stopping the clock and examining the
registers of my design.
Has anybody successfully used the Opencores DDR2 SDRAM controller on
the S3E starter board?

On Jul 26, 5:36 pm, blinkenlights <Klaus.Rindto...@gmail.com> wrote:
> Ok, tried it for weeks, now I give up and ask for help...
> I have a Spartan S3E starter kit board with a 46V32M16 DDR2 SDRAM on
> it. My design needs to read and write 32 bit words to SDRAM. I tried
> MIG 2.2 from the Xilinx coregen tools, but couldn't get it to work.
> Finally I found a controller design originally written by Markus Lemke
> and then modified for the Spartan S3E by David Ashley at Opencores.org
> (thanks to both!). The testbench included was simulated and
> synthesized fine, and works with the board as well, as far as I can
> tell from the LEDs.
> However, when used in my design, it fails. The design is first
> writing, then reading several hundred words of data from the SDRAM.
> The first word reads back ok, but all others are zero. I can see this
> in the simulation as well as when stopping the clock and examining the
> registers of my design.
> Has anybody successfully used the Opencores DDR2 SDRAM controller on
> the S3E starter board?

I would think if you can see this in simulation you could get to
the bottom of it fairly quickly.  I assume you are using the
Micron simulation model for the SDRAM part?  With the debug
option set you can see what the memory model thinks you are
writing or reading.  If it says zeroes are going in, then it makes
sense zeroes would come out.  If it shows something more
like you expected going in, then either you should see the same
thing coming out or some indication that you're not accessing
the data you thought you were.  If the memory model seems
to be reading the data correctly, something is broken further
up the food chain (in the opencores module).

Any more on why the MIG core didn't work?  I would think
that should be pretty easy to get running.

Regards,
Gabor

Yes, I am using the MICRON model, but I didn't expect the memory to be
simulated as well. You mentioned a debug option. Am I missing
something?
I am seeing tristate Z values in the simulation instead. The hint on
the zeros in the simulation is that just before the high and low parts
of the data are latched they change their value to zero. Sounds easy
to spot, but didn't help me to find the reason. In the implementation
I can trace the incoming zeros using my own debug mode in the
processor design.
The MIG generated controller was just too complicated, and the S3E
board reference design in VHDL had the wrong burst length for my
design.

And of course the MT46V32M16 is DDR SDRAM, not DDR2.

On Jul 27, 6:20 am, blinkenlights <klaus.rindto...@googlemail.com>
wrote:
> And of course the MT46V32M16 is DDR SDRAM, not DDR2.

What I meant about the debug option is actually a debug parameter
in the model.  If set to 1 it turns on a lot of $display stuff to let
you know what operations are being performed on the memory.
With debug set to zero, you only get error messages.

I agree that the MIG core is much more complex than it needs
to be, however if it just works (which seems to be the case for
many users) you can just think of it as a big black box.  By the
way I assume you actually used the correct settings (DDR vs
DDR2) when you tried it out?

In the simulation you say the data changes just before it is latched.
You mean that the correct data was on the DQ lines and suddenly
went low just before the clock edge on DQS?

Thanks Gabor, I will look for the debug parameter.
Your first question already sent me on the right way I believe. After
looking for the data signals in the simulator output again, I realized
that there might be a pipeline bug in the Opencores code, at least for
the way I use it. It looks like the data is latched one clock too
late, just when the data lines go to tristate again. I have modified
that and I now see it working in the simulation. In the implementation
it does work as well, but only if I single-step through my read
operations. If I run it at full speed, it fails again. Could be some
strange effect from my single-step logic. Anyhow, at least I know that
the write operation works fine.