FPGA Central

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

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 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

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é

[email protected],
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.

ada wrote:
> [email protected],
> 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 ...

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.

ada schrieb:

> Thanks to all guys!
>
> For observing signals with an oscilloscope I really need a good one but I
> found just an ordinary one. It does not seem to be very useful. I also

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?

> tried different DCM's PHASE_SHIFT values. I read a different data but no
> correct one. So it was not the key.
>
> Could someone tell me about data IO's? I read that all data IO's must use
> both INFFs, OUTFFs and one of the Tristate-FFs (one could see it in mapper
> report). For me all data IO's use only OUTDDR...I am confused.

This is just fine, OUTDDR are OUTFFs.

Regards
Falk

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
André

>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 ...

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.

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
(.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
André

> I could perform only simulation using ModelSim. With ModelSim timings of
> all signals which you mentioned are correct. With a real FPGA I could look
> 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 clock
> (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 sure
> 8.0 CLKIN_PERIOD. After using FDDRRSEs I generate ddr_clks from clk. I
> tried to use different PHASE_SHIFT values but it did not really help.

[email protected] wrote:
> 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
> (.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
> André
>
> > I could perform only simulation using ModelSim. With ModelSim timings of
> > all signals which you mentioned are correct. With a real FPGA I could look
> > 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 clock
> > (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 sure
> > 8.0 CLKIN_PERIOD. After using FDDRRSEs I generate ddr_clks from clk. I
> > tried to use different PHASE_SHIFT values but it did not really help.

While you are at it, get the simualation files from DDR vendors (here,
for example, is a typical page at Micron)
http://www.micron.com/products/dram/...T46V128M4TG-5B

On the left, you'll see a range of available simulation models you can
integrate into your test bench.

Although this is not the same as a module, it's a lot closer than
nothing at all. A module will typically add some jitter and round trip
delay, but make sure your design works with a part used on the modules
first

Cheers

PeteS

Thanks to all!

I simulated my design indeed using Micron memory models (I us
mt8vddt1664a memory model for simulation - it's not exactly my model bu
seems to be closed enough for me) and as I wrote before it worked jus
fine. But I did not use the FPGA netlist in my simulation. So a
[email protected] said I'd simulated the VHDL description but not th
synthesis result. I am going to simulate the synthesis results (I'll do i
tomorrow because first I have to find out how to do it. I've never done i
before). Does somebody have a good link about it? So I'm googling around
I'll write about results tomorrow.

I am open to any other ideas.

Best,
Ada

ada wrote:
> Thanks to all!
>
> I simulated my design indeed using Micron memory models (I use
> mt8vddt1664a memory model for simulation - it's not exactly my model but
> seems to be closed enough for me) and as I wrote before it worked just
> fine. But I did not use the FPGA netlist in my simulation. So as
> [email protected] said I'd simulated the VHDL description but not the
> synthesis result. I am going to simulate the synthesis results (I'll do it
> tomorrow because first I have to find out how to do it. I've never done it
> before). Does somebody have a good link about it? So I'm googling around.
> I'll write about results tomorrow.
>
> I am open to any other ideas.
>
> Best,
> Ada

One thing I did not mention that *has* given me a great deal of grief
on DDR is Vref. DDR requires this to be V(mem) / 2 and the clock
crossings have to be within a tight range of this, to say nothing of
the other signals.

if Vref is produced by a resistive divider with a cap, you might have
an issue with just *some* memory sticks - they pull more from Vref than
the divider can stand (it's not stiff enough) and you'll get all sorts
of flaky (particularly read) behaviour. The standard behaviour of
devices is such that the current drawn from Vref is temperature
dependent, too, which you are seeing.

Stick a scope probe on Vref somewhere with a 'bad' stick and see if it
remains at the proper level (or if it even gets to the proper level).

Cheers

PeteS

PeteS wrote:
> One thing I did not mention that *has* given me a great deal of grief
> on DDR is Vref. DDR requires this to be V(mem) / 2 and the clock
> crossings have to be within a tight range of this, to say nothing of
> the other signals.
>
> if Vref is produced by a resistive divider with a cap, you might have
> an issue with just *some* memory sticks - they pull more from Vref than
> the divider can stand (it's not stiff enough) and you'll get all sorts
> of flaky (particularly read) behaviour. The standard behaviour of
> devices is such that the current drawn from Vref is temperature
> dependent, too, which you are seeing.
>
> Stick a scope probe on Vref somewhere with a 'bad' stick and see if it
> remains at the proper level (or if it even gets to the proper level).
>
> Cheers
>
> PeteS

Another point on using Virtex II and Vref. The tools will
automatically
determine whether Vref is required for a particular bank based on the
inputs to that bank. I have had a problem in the past where I did not
realize that my SSTL signals on one bank were all outputs (Address
and Control lines). For this bank, I had the Vref pins tied to a
source
with a relatively high impedance. The Vref pins were not required for
Vref on that bank and so the tools automatically defaulted them to
weak pullups. The half dozen "weak" pullups were enough to bring the
Vref up to almost 2 volts. This is worth checking if you are not using
all of the connections on the board, for example leaving out a feedback
input. If you inadvertently free up the Vref pins on a bank they could
get you in trouble. In my design I fixed the problem by setting the
BitGen defaults to "Float" for unused IOB pins.

Regards,
Gabor

Hi all,

sorry for keeping silence. I tried Post-Synthesis simulation with ModelSi
but I had an error:

# ** Error: Timing Violation Error : RST on instance * must be asserte
for 3 CLKIN clock cycles.
# Time: 8100 ps Iteration: 1 Process
/tbx_top/i_top/i_ddr_sdr/dcm0/dcm_inst1/check_rst_width File
C:/Programs/Xilinx/vhdl/src/unisims/unisim_VITAL.vhd

This problem is caused due to Xilinx libraries. In the testbench, the DC
Reset is initially defined as "x",then it changes to "1". This initia
transition is evaluated as a valid transition, and starts the DCM Rese
lenght check from this transition, therefore causing the ERROR.

So Xilinx proposes to update the software libraries. I did it but it di
not help. Does anyone have an idea how to fix it?
Any case I do not think I have to spend too much effort in order to brin
the simulation to work because it's just a simulation. Nobody coul
guarantee that even if simulation works it would work with the real board
So I have to concentrate on a real board.

I asked AVNET about connecting an oscilloscope to the board but no answe
till now. And I have not found anything related to their boards and osc
connections in Internet.

Does anyone have a working DDR SDRAM controller example? Or some othe
ideas related to my problem? I would really appreciate it.

And one more question. I am using 125MHz FPGA clock and I am giving clock
with the same frequency (generated with DCM primitives ) to the DDR SDRAM
I think it's ok but maybe I am mistaken. Does someone have othe
suggestions?

Best,
Ada

Hi ada,

>This problem is caused due to Xilinx libraries. In the testbench, the DCM
>Reset is initially defined as "x",then it changes to "1". This initial
>transition is evaluated as a valid transition, and starts the DCM Reset
>lenght check from this transition, therefore causing the ERROR.

How do you generate the Reset,
do you you generate it in the testbench ?



Rgds
André

>Any case I do not think I have to spend too much effort in order to bring
>the simulation to work because it's just a simulation. Nobody could
>guarantee that even if simulation works it would work with the real board.
>So I have to concentrate on a real board.

Yes, you are right.

But performing a timing simulation you can at least say that
your FPGA generates the timings correctly. For that
purpose I think it could be an advantage to use
a simple test case, for writing data to DDR memory and reading
it back (simplified data path)
Once proved you can concentrate on functional simulation
and static timing analysis.

Rgds
André

Hello,

there is a problem with the reset signal in DCMs but it's nothing to d
with my design. I define rst signal for dcm in my ddr_sdr module (not i
my testbench) and initialize it with '0' but it's not the point. The poin
is Xilinx libraries were buggy. Look her
http://www.xilinx-china.com/xlnx/xil...PagePath=18941
and here
http://www.xilinx.com/xlnx/xil_ans_d...ceihdffhdfjf.0

Any case I ignored this error and also changed some libraries and DC
locked. So now I could say that Post Synthesis looked ok. I have also jus
done Post-Place & Route Simulation (with -sdfmax parameter) and I had lot
of warnings:

1) for all CKEs
Warning: CKE Setup time violation -- tIS
2) for all ddr_sdr_data_lo1_q (it's a low part of buffered data bus)
Warning: /X_FF SETUP X VIOLATION ON I WITH RESPECT TO CLK;
# Expected := 0.182 ns; Observed := 0.129 ns; At : 207478.794 ns
3) for some ddr_sdr_data_hi_q (it's a high part of buffered data bus)
# ** Warning: /X_FF HOLD Low VIOLATION ON CE WITH RESPECT TO CLK;
# Expected := 0.028 ns; Observed := 0.016 ns; At : 207494.807 ns

I also saw lots of data glitches on data bus. But I have to look at th
simulation results more detailed and it's already too late. I think
could tell more tomorrow.

Till tomorrow.

Hi all,

Post-Place & Route Simulation is ok now (I had some warnings due to dat
glitches but I fixed it and everything works fine). Anyway there is n
progress with the board Do not know what I could possibly do. It seem
without an osci I am really lost. Or someone has an idea? I would b
really glad to hear any suggestions!

Best,
Ada

Hi Ada,

ask Avnet if there is some DDR controller IP core evaluation bit stream
available for the board so that you can check whether DDR memory
accesses are possible and correct
at all. If they are correct then you know at least that you have to
analyze
your own controller.

Rgds
André