MIG DDR2 controller does not work (reset problems?)

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

Translate This Thread From English to

Threaded View
Hi,
I build a DDR2 controller using the Mig 1.5.

In functional simulation everything works without problems (as
alwayys). In the hardware implementation it does not work. I used the
synthesizable testbench which is provided by the Mig. My design is
driven by a 200Mhz Refclock and 125MHz system clock. I used chipscope
and oscilloscope to figure out the following:
-All clocks (200, 90, 50) work properly. Also clk0 which controlls most
part of the ddr2controller module.
-I can messure the correct RAM clock on the PCB
-After the reset WDF FIFO is empty and the internal writeWDF signal
toggles untill the WDF almost full signal goes active. It stays high
forever.
- The other signals on the PCB (or on chip using chipscope) especially
(ras, cas, we, cs) do not toggle at all.

SO data is never written to the ram and never read out. The FIFO just
runs full.

Did anybody experience similar problems and can help?
The xilinx design only uses synchronous resets. These are regarded like
normal signals by the router and hence do not meet the timing (high fan
out probably). Is this ok? How are resets treated in FPGAs anyway? I
always use asynchronous reset so they dont interfere with timing
issues. Can i tell XST in anyway that it should treat reset signals
properly? How to tell XST to make a reset tree synthesis?
Could it be due to the FIFO16 bug? I dont think so, as it doesnt run at
all. The controller should at least try to access the RAM several
times, right?


Re: MIG DDR2 controller does not work (reset problems?)
Did you check whether the reset is performed or not
in hardware ?
Rgds
AndrE9%

Quoted text here. Click to load it


Re: MIG DDR2 controller does not work (reset problems?)
snipped-for-privacy@gmx.de schrieb:

Quoted text here. Click to load it

check that the iodelay calibrate block get locked if not it will
disable everything else

Antti


Re: MIG DDR2 controller does not work (reset problems?)
Quoted text here. Click to load it

1. Check the map report to make sure that all your IOs go to the pins
that you want.

2. I found that the controller doesn't start up correctly from power-on,
but it can be reset by driving the SYS_RESET_IN signal high, then low.

3. If you can look at the command signals (RAS, CAS, WE) going to the
SDRAM, you should be able to see the INIT commands. After init, the
controller issues many read commands and looks at the strobe signals to
calibrate the iodelay. This should be obvious from the scope if you can
look at a datastrobe or two.

4. After the iodelay is calibrated, the controller writes a pattern to
memory then tries to read it back. If you have a chipscope, look at
COMP_DONE. When it is high, the memory is ready to use. I took this
signal out to the top of the hierarchy and have it as a register bit
that my PPC can look at to see the health of the memory.

5. Consider fixing the FIFO16s, at least the ones that hold the memory
addresses. The ones that hold the write data are clocked by the MClk and
MClk90, so they may be OK.


---
Joe Samson
Pixel Velocity

Re: MIG DDR2 controller does not work (reset problems?)
Hi thanks for all the responses

@alupin: The reset is driven by an externel jumper on the board. It
seems to work.

@antti: Do you mean the RDY_STATUS signal in the ddr2_8x4_idelay_ctrl
module? Yes it goes high shortly after reset.

@joseph: Ich double checked all pins, ok. I played with the reset. I
observed the design a little bit more using chipscope getting the
following results: Ras, Cas and ddr2_we toggle right after reset
deassertion, i think this is the initialisation of the ddr2. I dont
know whether the ddr2 behaves correct but the init sequence is
completed after about 500 clock cycles. THe COMP_VALID signal never
goes high and also the read enable signals for the write and address
FIFOs stay zero all the time, so I guess the init sequence fails.

Does anybody know how I could check whether the RAM behaves correctly?

We have no external termination on the board. Do I have to configure
ODT somehow? Icant find anything about ODT in the Mig however there is
the RTT option. I cant find any information about this option I guess
it is related to termination resistors? Should I choose 75 or 150 ohm
RTT?

heiner


Joseph Samson schrieb:

Quoted text here. Click to load it


Re: MIG DDR2 controller does not work (reset problems?)
Quoted text here. Click to load it

I don't think that the lack of termination is causing this problem. I
inadvertently had my Vtt turned off and was still able to read and
write. In your original post, you said:
Quoted text here. Click to load it

Is this still true - if you put a scope on the PCB signals,can you see
the RAS CAS and WE forming the Load Mode command? If you can't see this,
then you have to start by figuring out why you're not driving those
signals (since you've said that you can see them toggling internally
with ChipScope).

If you're looking at RAS, CAS and WE with ChipScope, figure out the
sequence of commands that MIG is sending to the RAMs. You can download a
  DDR2 datasheet from Micron; they have a table that gives the command
nanes for the combinations of RAS,CAS and WE. You'll probably have to
start looking at the state machine in the ddr2_controller module to
figure out where you're hanging up and what conditions are stopping your
progress.


---
Joe Samson
Pixel Velocity

Re: MIG DDR2 controller does not work (reset problems?)
Hi ive got some news,

the init and calibration process seems to be succesful as tap_sel_done,
data_tap_select and init_memory signals toggle at the end of the
calibration process.

However the init_done signal which is driven by COMP_DONE is not
asserted. As COMP_DONE is generated by the pattern compare module, it
seems to me that the read out data is corrupted.

Could this be right?
Am I right with my conclusions?
What to do know?

thx, regards Heiner

Joseph Samson schrieb:

Quoted text here. Click to load it


Re: MIG DDR2 controller does not work (reset problems?)
Quoted text here. Click to load it

I'm assuming that this is a board of your own design, and not a
prototyping board you bought off the shelf, because my first guess would
be that there is either a mis-wiring problem (my board had the
differential clock signals miswired + to -, even though we checked the
schematic about a hundred times) or a signal integrity problem (like
those missing terminators). You can try turning on ODT. You can either
change the parameters_0.v file, or regenerate the design from CoreGen,
clicking on the 'Set Mode Register" button and setting RTT to 75 ohms.

There are two lines of attack:
1. Is the command and address correct?
2. Is the data correct?

There are indirect ways to see if the commands are correct. Earlier, I
said that part of the calibration is to issue read commands and
calibrate the idelay by examining the datastrobes. If you are getting
through that phase and you see datastrobes being generated, then the
commands (RAS, CAS, WE, CKE, CS) are probably OK, or at least I'd look
elsewhere.

It's hard to tell if the address bus is OK without using a scope on the RAM.

You can use ChipScope to see what the data looks like coming from the
RAM, but be sure that you aren't accidentally connecting to signals that
go to the IOB. The address and command signals go go IOB flipflops, but
chipscope will happily move them out of the IOB so you can look at them,
and as a bonus, you'll get lots or routing delay to confues the issues.

If this is your own design, did you pay attention to the routing delays?
My first design spec'd that signals had to be length matched to 200ps.
In my second design, I spec'd 20ps. You could have everything correct,
but the difference in path length could prevent the calibration circuit
from aligning all the bits.


---
Joe Samson
Pixel Velocity

Re: MIG DDR2 controller does not work (reset problems?)
Hi Joseph,

thanks a lot I will check all the thing you suggested and yes its a
board made by us.

Still I have some questions:

The Calibration process with the dummy reads can be definitely observed
using chip scope and it seems to be ok as the tap_select signal is
asserted. Does that mean that at least the control and the DQS signals
should be fine. The question I have is the following in the init
sequence the controller just writes data to the RAM, the Ram itself
does practically nothing. SO assuming the RAM wouldnt consist at all
would the init and calibration sequence still be succesfull?


I tried a board without RAM assembly and it didnt do anything so I
assume not..
As I said before the data compare module fails so it could be a signal
inttegrity problem which casuses the read out data to be corrupt.

heiner


Joseph Samson schrieb:

Quoted text here. Click to load it


Re: MIG DDR2 controller does not work (reset problems?)
Quoted text here. Click to load it

I would assume for the moment that the RAM is decoding the control
signals correctly.

Quoted text here. Click to load it

in the init sequence, the controller just READS the RAM, so that the RAM
  will send back DQS signals so the controller can tweak the input delays.

Quoted text here. Click to load it

No, because the controller needs those DQS signals back from the RAM in
order to se the delays.

Quoted text here. Click to load it

Or, the read could be correct and the write could be wrong. It's kind of
hard to tell that if you aren't getting past Comp_Done. You should
probably look at the data going to and from the RAM, to see what's going
on. Maybe there's a stuck bit, or maybe data from one bank is wrong but
the rest are right. There are a lot of possibilities. It will take some
investigating with ChipScope to figure out what's going on.

---
Joe Samson
Pixel Velocity

Re: MIG DDR2 controller does not work (reset problems?)

Quoted text here. Click to load it

Be aware than when putting chipscope and looking at we / cas / ras ...
you might prevent the tools to put the last register into the IOB and
then you have bad timings ...

So if it's the case, you are actually creating a problem with chipscope
and not debugging the real one ...

Checkout the timing report to see if the clock-to-out of the ddr_clk and
the control signals and the address leads to a valid timing.



    Sylvain

Re: MIG DDR2 controller does not work (reset problems?)
We have the same problems and have traced it to the IOB not latching valid read
data back, from the working DDR memory IC, in the rise and fall registers. We
can see the read data enter the Xilinx part correctly and never exit the capture
registers. All clocks and resets, tap calibration, etc look great. We believe
the read data is not getting through the Idelay block so it never gets captured
and Comp_Done fails. My partner wants to switch to an Altera chip after he stops
screaming ...

Bob

Site Timeline