DDR SDRAM Controller

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi there,

unfortunately I have problems with DDR SDRAM Controller. I have an Avne
board with Xilinx Virtex-II FPGA (xc2v4000-ff1152)and Micron DDR SDRA
DIMM (MT4VDDT1664HG). I am using opencores DDR SDRAM controller. I hav
already adapted it and simulation with ModelSim works fine but I have rea
problems with the board. I synthesize and implement my design with Xili
Project Navigator 7.1 and upload it to my FPGA, also I used ChipScope t
track signals. The controller just does not work. All signals seem t
drive as they should during writing. During reading I see all zeros o
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



Re: DDR SDRAM Controller

Quoted text here. Click to load it

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.


Re: DDR SDRAM Controller

Quoted text here. Click to load it

Thanks for your answer.

As far as I know I can not look at clock signals with Chipscope (I als
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
could not implement my design (translate or map was failed due t
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 externa
parts as expected and I do not have a real oscilloscope to check it.
could only hope than it's not a case.

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

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

Best,
 Ada



Re: DDR SDRAM Controller

[snip]
Quoted text here. Click to load 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.


Quoted text here. Click to load it


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



Rgds
AndrE9%


Re: DDR SDRAM Controller
snipped-for-privacy@web.de,
Related to DQS and DQ. I can not really know! I could just guess. I thin
it was clear from my previous post.

2Gabor,
Thanks.
I am using an Avnet Xilinx Virtex II Development Board-XC2V4000-FF115
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.


Re: DDR SDRAM Controller
Quoted text here. Click to load it

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

Re: DDR SDRAM Controller

Quoted text here. Click to load 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




Re: DDR SDRAM Controller
Hi All,

This post pertains to a DDR SDRAM controller that works perfectly for 95% of
DIMMS used, and is part of a test system that contains a 2+ GHz oscilloscope
monitoring the clock, command, and dqs signals at the DIMM pins.

Several DIMMs seem to operate incorrectly only occassional (possibly
temperature dependent), and I suspect that the issue is some type of timing
requirement that is on the edge of met and violated.  When the incorrect
behavior is seen the scope verifies that write cylces are operating
correctly but that the read cycles are not operating correctly.  Durring the
read cycles the active command is issued, then the read command (satisfying
Trcd) and accordingly the DQS signals are provided by the DIMM.  Here is the
catch; bursts of 8 was specified durring initialization and the DQS signals
durring correct operation correspond to this choice; however, but durring
the failing read cycles I will see sometimes 1 DQS rising edge, sometimes 2
and sometimes even 5 rising edges!  My questions are as follows:

1) Has anyone with DRAM exprience seen any behavior like this before?

2) **  What might cause a DDR module to provide a varying number of DQS
strobes?   **

Recall that the design has no blatent errors since for most DIMMs no errors
are ever seen.

Thanks for any thoughts,

Brendan Illingworth



Re: DDR SDRAM Controller
Hi All,

This post pertains to a DDR SDRAM controller that works perfectly for 95% of
DIMMS used, and is part of a test system that contains a 2+ GHz oscilloscope
monitoring the clock, command, and dqs signals at the DIMM pins.

Several DIMMs seem to operate incorrectly only occassional (possibly
temperature dependent), and I suspect that the issue is some type of timing
requirement that is on the edge of met and violated.  When the incorrect
behavior is seen the scope verifies that write cylces are operating
correctly but that the read cycles are not operating correctly.  Durring the
read cycles the active command is issued, then the read command (satisfying
Trcd) and accordingly the DQS signals are provided by the DIMM.  Here is the
catch; bursts of 8 was specified durring initialization and the DQS signals
durring correct operation correspond to this choice; however, but durring
the failing read cycles I will see sometimes 1 DQS rising edge, sometimes 2
and sometimes even 5 rising edges!  My questions are as follows:

1) Has anyone with DRAM exprience seen any behavior like this before?

2) **  What might cause a DDR module to provide a varying number of DQS
strobes?   **

Recall that the design has no blatent errors since for most DIMMs no errors
are ever seen.

Thanks for any thoughts,

Brendan Illingworth




Re: DDR SDRAM Controller
Quoted text here. Click to load it

Most DDR problems are on the read cycle.

When you do a read, DDR (unlike other memory) drives not only the bus
but also the strobes (as you are clearly know). What you may not know
is the amount of variance there can be between devices on the DQS <->
data jitter and DQS (read) - clock variance.

For those DIMMs you are having problems with, the issue is very likely
that DQS is being asserted outside your timing window (so the device
is, in fact, asserting a burst of 8 - you simply are not catching it).

I have seen this behaviour using commercial parts with DDR controllers
built in - the programmable parameters such as DQS skew being there to
get around issues just such as this.

The causes for this are usually either poor clock/data termination (and
in DDR you have to have something even if it's only series, which is
do-able in point to point), excessive round trip delay on the clock,
excessive added data skew (across D0-Dn vs. DQS) or excessive skew on
DQS vs. clock (which moves DQS as received away from the clock) as seen
at the receiver.

In addition, DDR is not specified to operate below certain speeds,
although *most* will. This is a classic gotcha where the internal DLLs
won't properly lock to generate read DQS appropriately.

The temperature dependency is perhaps to be expected - all logic
devices tend to operate a little slower (edge response in particular,
but propagation delay tends to increase as well), thus increasing the
amount of time before a return DQS is asserted.

My first place to look would be DQS skew timing (remembering that the
memory device will assert DQS at the leading edge of data - it's up to
the controller to determine how to use it to grab the data) in the
controller.

It took me almost as long, perhaps longer, to set the rules for laying
out DDR (I put down 3 independent 200/400 systems on one board) as it
did to get it laid out. Even then, my timing budget had about 200
picoseconds of guaranteed margin - just what the guaranteed margin is
on any particular DIMM is I can't say without a datasheet handy.

Cheers

PeteS


Re: DDR SDRAM Controller
Thank you for the response, it was reassuring.  I am in the process of
taking a closer look at the timing margins at the controller on our Agilent
infinium (2.25Ghz BW) scope and hopefully will be able to verify your
suspicion.  Additionally I have a comment; very rarely when the read cycles
fail I only see one single rising edge on DQS as opposed to the four I would
expect for an 8 burst read.  I know that I am "catching" all the DQS
transisitions as I am looking at the line over multiple read cycles.  Have
you seen this behavior before?

Regards,
Brendan


Quoted text here. Click to load it
95% of
Quoted text here. Click to load it
oscilloscope
timing
the
(satisfying
Quoted text here. Click to load it
the
signals
durring
sometimes 2
errors



Re: DDR SDRAM Controller
Quoted text here. Click to load it

If you are seeing only one (or less than  a burst) of DQS on reads,
then the cycle is being truncated by external command, one way or
another. One common problem that you have to be aware of is the clock
*at the DDR device* is defined by the CLK and #CLK crossing, not the
50% transition. Be sure you are within the spec for clock crossover.
The other possible culprits (according to my habdy DDR datasheet) are
the command bits (See
http://download.micron.com/pdf/datasheets/dram/ddr/512MBDDRx4x8x16.pdf
for a typical DDR part) - see table 6

is a possible burst terminate command (which would do precisely what
you are seeing). As the problem exacerbates with temperature, I would
be suspicious of this, and the timing from CLK/#CLK to the command bus.

Cheers

PeteS



Quoted text here. Click to load it


Re: DDR SDRAM Controller
 > All signals seem to
 > drive as they should during writing. During reading I see all zeros or
Quoted text here. Click to load it

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

Re: DDR SDRAM Controller
To observe DDR signals with a scope, you already need a good scope ...


Re: DDR SDRAM Controller
Thanks to all guys!

For observing signals with an oscilloscope I really need a good one but
found just an ordinary one. It does not seem to be very useful. I als
tried different DCM's PHASE_SHIFT values. I read a different data but n
correct one. So it was not the key.

Could someone tell me about data IO's? I read that all data IO's must us
both INFFs, OUTFFs and one of the Tristate-FFs (one could see it in mappe
report). For me all data IO's use only OUTDDR...I am confused.





Re: DDR SDRAM Controller
ada schrieb:

Quoted text here. Click to load it

Those terms are not quite tecnically. An ordinary scope of today was a
high end scope 5 years ago. What you need is some numbers. Last time I
had a look at a DDR RAM interface I was using a 1.5 GHz scope form
Agilent with 2.5 GHz active probes. Worked fine. Anyone had success
using less firepower?

Quoted text here. Click to load it

This is just fine, OUTDDR are OUTFFs.

Regards
Falk

Re: DDR SDRAM Controller
Hi Ada,

can you perform a timing simulation including timings and synthesis
results
of your FPGA ? You could at least see if timings of
DQS, DQ, RasN/CasN/WeN/CsN , ClkP, ClkN are correct when
coming out of the FPGA ...

Rgds
AndrE9%


Re: DDR SDRAM Controller
Quoted text here. Click to load it

I could perform only simulation using ModelSim. With ModelSim timings o
all signals which you mentioned are correct. With a real FPGA I could loo
only at RasN/CasN/WeN/CsN signals when they come out of the FPGA.

I think I did not mentioned my clocks. The board has 3 FPGA clocks
40MHz, 66MHz and 125MHz. Currently I am using 125MHz FPGA cloc
(input_clk). Then I have 2 DCMs from which I get clk, clk90 and clk270
They both have fixed CLKOUT_PHASE_SHIFT, low DLL_FREQUENCY_MODE and sur
8.0 CLKIN_PERIOD. After using FDDRRSEs I generate ddr_clks from clk.
tried to use different PHASE_SHIFT values but it did not really help.


Re: DDR SDRAM Controller
Hi ada,

yes, Modelsim is the point. You can perform a timing simulation using
Modelsim that is you have to include the FPGA timing information file
(2E%sdf)
and the FPGA netlist (.vho) in your simulation. You have simulated
the VHDL description but not the synthesis result, am I right ?
Try to find out how to perform a timing simulation because that kind
of simulation shows real behavior of your FPGA.

Rgds
AndrE9%

Quoted text here. Click to load it


Site Timeline