DDR SDRAM Controller

Hi there,

unfortunately I have problems with DDR SDRAM Controller. I have an Avnet
board with Xilinx Virtex-II FPGA (xc2v4000-ff1152)and Micron DDR SDRAM
DIMM (MT4VDDT1664HG). I am using opencores DDR SDRAM controller. I have
already adapted it and simulation with ModelSim works fine but I have real
problems with the board. I synthesize and implement my design with Xilix
Project Navigator 7.1 and upload it to my FPGA, also I used ChipScope to
track signals. The controller just does not work. All signals seem to
drive as they should during writing. During reading I see all zeros or
just rubbish on data bus. 
I tried to change timing parameters but they don't affect. 

Any suggestions as to what I might have missed?

Best, 
 Ada

ada wrote:
> Hi there,
>
> unfortunately I have problems with DDR SDRAM Controller. I have an Avnet
> board with Xilinx Virtex-II FPGA (xc2v4000-ff1152)and Micron DDR SDRAM
> DIMM (MT4VDDT1664HG). I am using opencores DDR SDRAM controller. I have
> already adapted it and simulation with ModelSim works fine but I have real
> problems with the board. I synthesize and implement my design with Xilix
> Project Navigator 7.1 and upload it to my FPGA, also I used ChipScope to
> track signals. The controller just does not work. All signals seem to
> drive as they should during writing. During reading I see all zeros or
> just rubbish on data bus.
> I tried to change timing parameters but they don't affect.
>
> Any suggestions as to what I might have missed?
>
> Best,
>  Ada

The first thing I would check is your clock distribution.  Make sure
the clock
to the DIMM and the FPGA have the same phase.  Use a scope.  Chipscope
is O.K. for FPGA internals debug, but a real oscilloscope is the only
way
to make sure your signals reach the external parts as expected.

Also make sure your FPGA pinout matches the Avnet board.  Are you
using a UCF file provided with the board?

Also, the Micron models don't all check the initialization sequence
required
to start up the memory.  Be sure your code provides the correct warm
up period before your initial SDRAM access.  This is especially
important
if the FPGA is driving the clock to the SDRAMs.

>The first thing I would check is your clock distribution.  Make sure
>the clock
>to the DIMM and the FPGA have the same phase.  Use a scope.  Chipscope
>is O.K. for FPGA internals debug, but a real oscilloscope is the only
>way
>to make sure your signals reach the external parts as expected.
>
>Also make sure your FPGA pinout matches the Avnet board.  Are you
>using a UCF file provided with the board?
>
>Also, the Micron models don't all check the initialization sequence
>required
>to start up the memory.  Be sure your code provides the correct warm
>up period before your initial SDRAM access.  This is especially
>important
>if the FPGA is driving the clock to the SDRAMs.
>

Thanks for your answer. 

As far as I know I can not look at clock signals with Chipscope (I also
can not track DQS signals because they rise only for half a clock period).
I tried to do it and I got warnings from Chipscope. I ignored them but I
could not implement my design (translate or map was failed due to
Chipscope module). After I read somewhere it's impossible with Chipscope.
Am I missing something?

You are right I could not be sure that my signals reached the external
parts as expected and I do not have a real oscilloscope to check it. I
could only hope than it's not a case.

My FPGA pinouts match the Avnet board indeed. Sure I am using a UCF file
provided with the board. I also checked memory initialization sequence
before I posted the first message:) It works as it should according to
Micron's data sheet. 

I am just a bit confused - among all nets in original UCF file I have
CLK_DDR_FB_IN and CLK_DDR_FB_OUT. In my design I am using only
CLK_DDR_FB_IN for giving my feedback signal to DDR. Should I use both? I
do not see any reason for it.

Best, 
 Ada

ada wrote:
[snip]
>
> I am just a bit confused - among all nets in original UCF file I have
> CLK_DDR_FB_IN and CLK_DDR_FB_OUT. In my design I am using only
> CLK_DDR_FB_IN for giving my feedback signal to DDR. Should I use both? I
> do not see any reason for it.

Usually the reason for a feadback net is to match board-level delays,
so
you can automatically adjust your clock phase.  Look at the board
schematic
and see how these nets are hooked up.  Maybe you need to drive
CLK_DDR_FB_OUT to the DIMM.  Which board are you you're using?
A quick look at the Avnet site turned up a lot of boards with FG456
package
Virtex-II parts, and some with Virtex-II Pro in the FF1152 package.


> 
> Best, 
>  Ada

Without real oscilloscope your are lost.
How can you see without osci if your DQS and DQ go tristate ?



Rgds
Andr=E9

2ALuPin@web.de,
Related to DQS and DQ. I can not really know! I could just guess. I think
it was clear from my previous post. 

2Gabor,
Thanks. 
I am using an Avnet Xilinx Virtex II Development Board-XC2V4000-FF1152
board (it has ADS-XLX-V2-DEV4000XP product code). 
I was running different tests but still can not get why it does not work.
I just read some kind of random data.

ada wrote:
> 2ALuPin@web.de,
> Related to DQS and DQ. I can not really know! I could just guess. I think
> it was clear from my previous post. 
> 
> 2Gabor,
> Thanks. 
> I am using an Avnet Xilinx Virtex II Development Board-XC2V4000-FF1152
> board (it has ADS-XLX-V2-DEV4000XP product code). 
> I was running different tests but still can not get why it does not work.
> I just read some kind of random data.
> 

I don't know the controller you're using, nor your board. But my
experience with ddr and ddr-controllers is that somewhere you have a DCM
to generate the read clock and that DCM has a phase-shift and you need
to adapt this timeshift according to your board (you can just try some
value, find the lowest for which it work, then the highest and finally
take a value in the middle ...)


	Sylvain

"ada" wrote:

>> CUT

> I am just a bit confused - among all nets in original UCF file I have
> CLK_DDR_FB_IN and CLK_DDR_FB_OUT. In my design I am using only
> CLK_DDR_FB_IN for giving my feedback signal to DDR. Should I use both? I
> do not see any reason for it.
>


As far as I know there are two main schemes for DDR controller mainly
adopted with virtex-4 (and virtex-2 , I think).
One is that with the delay compensation line made from the ddr_clk_p line,
fed back to fpga (in a clock bank): if I'm not wrong, this is the method
adopted in opencores controller (and also by microblaze opb bus ddr
controller with virtex-4).
The second scheme has a dedicated line for delay compensation: look at your
board schematics! From your citation or your board ucf file, I think this is
the scheme adopted by you dev board. There's an output pin (CLK_DDR_FB_OUT)
and an input pin (CLK_DDR_FB_IN): they are shorted with an appropriated
length net (for compensating delay). This is the method I found in xilinx
MIG.
I'm not very experienced with ddr controller, but I think that there are
hardware discrepancies between the two schemes (the delay length are
different, if I'm not wrong) and perhaps also hdl descriptions are not
directly reusable: perhaps they can be easily adjusted, but I don't really
know. Opencores controller, in my opinion, is quite well described and very
simple also for a newbie as me; but due to performances (I'm using on
virtex-4) I focused my attention to xilinx website designs (using mig 1.4
... poorly documented, in my opinion, for ddr - much better on ddr2).
The fact that with chipscope you experience read problems, let me think that
the problem is just in the feedback scheme/delay. If I've understood, this
is just the re-syncronization trick for readings.

Hope this may be useful to you and sorry if I've written some inaccuracies.
Regards,

stefano

 > All signals seem to
 > drive as they should during writing. During reading I see all zeros or
> just rubbish on data bus. 
> I tried to change timing parameters but they don't affect. 

you are convinced that your write operations are fine
just by looking at the signals with chipscope?

writing has no "success" feedback from the ram so if you mix up your 
enable signals or provide a faulty clock that would still look good on 
chipscope!

take a logic analyzer or an oscilloscope and check your setup/hold times 
and your clock at the ram ...


bye,
Michael

To observe DDR signals with a scope, you already need a good scope ...