Strange ddr controller bugs.

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

Translate This Thread From English to

Threaded View
Hi all:
I am meet a very strange ddr controller bugs on board.
since system power up. I turn on the ddr controller tester to test the
DDR interface of FPGA(virtex5), after a long time run it appers just
fine.
but when I reset the FPGA. and run the tester again, I got errors when
read back data from DDR.
and I want to know does reset FPGA can cause the unstable working of
DDR controller?
someone can analysis it for me?
Thanks and Best Regards.
Buley

Re: Strange ddr controller bugs.
Quoted text here. Click to load it

A little more information would help.  When you say "reset the FPGA"
do you mean re-load the configuration, i.e. pretty much the same
as power-on reset?

When you say "errors on read back data", did you read data from
the first session or data you wrote after resetting the FPGA?

Regards,
Gabor

Re: Strange ddr controller bugs.
Quoted text here. Click to load it

sorry for the confusion.
I will clearify it.
the reset is a global reset for the FPGA logic. just the reset pin
connect to all the logic blocks. not reload configuration.
and the error is bit error. after the reset, I wrote to the address
0x70A data 0x4E2F693C
but the read back data from 0x70A is 0x4E2E691A, some bit errors. and
almost every read back data has bit error. and in the different
position.
I think maybe caused by the DQS sampleing or the DDR initial process
problem.
is this problems seems like DDR SDRAM problem or The DDR Controller
problem?
Thanks.

Re: Strange ddr controller bugs.

Quoted text here. Click to load it

It could be a read problem (like sampling at the wrong time) or a write
problem.  You need to perform timing analysis.  In any case, it's most
likely not a problem with the DDR Controller logic itself.  Do a thorough
timing analysis.

KJ



Re: Strange ddr controller bugs.
On 7E6%9C88%13E6%97A5%, E4%B88A%E58D%881E6%97B6%02E5%8886%, "KJ" <kk=
snipped-for-privacy@sbcglobal.net> wrote:
Quoted text here. Click to load it
Thanks for your advice.
I use osilliscope analysis the timing wave on board and find the
timing for DATA and DQS are good.
and DDR works good when system power up, error just happend after I
reset all logic.
and I also did timing analysis inside FPGA, there is a good setup/hold
time for data and dqs.
this is just a strange thing for me.

Re: Strange ddr controller bugs.

Quoted text here. Click to load it

Then apparently the outputs of the FPGA are causing data to be overwritten
when you 'reset all logic'.  How long of a reset is this anyway?  Long
enough that the DDR is not getting properly refreshed perhaps?

The only way the contents of the memory can change is by writing to it
(maybe during a reset the controller outputs appear to the DDR as a memory
write) or by lack of refresh...or a faulty memory device, but if this is
happening only under certain specific conditions that wouldn't seem likely.
There are no other reasons.
KJ



Re: Strange ddr controller bugs.
Thanks all and I am already solve this problem, below is the report:
I use vertex5
The main problem happens at the reset of the IDELAYCTRL block and DCM.
the DCM generated the clk and clk_270 which is 270 degree shift of
clk.
The IDELAYCTRL controlls the IODELAY component in the DDR Controller
Datapath.
so when manage the reset of these 2 component should be more careful.
the reset of IDELAYCTRL should release after the DCM locked. otherwise
it may cause the IODELAY works abnormally.
also the DCM in my design is cascaded, I used 2 DCM, so the reset for
the 2nd DCM should released after the first DCM locked.
since I changed the strategy of the reset, this strange problem has
been solved. and Special Thanks to WYL.  and thanks to you all also.

Site Timeline