Strange ddr controller bugs.

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

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.

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

's most

rough

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.

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

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.