partial data corruption while DDR3 read.

[sraza]

hello every one,

I have a strange result obtained from DDR3 while performing write and read. The operation seems to be good enough, but the results seems to be a-bit, misleading. please follow the post below. Note the following specs first 

DDR3: 16x, for BL8 transfer, Data_width = 4x16,

So the first thing is as follows. First of all I generate sequence of write commands and then sequence of read commands and I have shown the results in image.

I am cheking the results in chipscope.

So in both the cases,  I generated address 0,8,16,24.... i.e. for BL8 transfer and the data that I put for sequence of write command are 0x0003_0002_0001_0000 , 0x0007_0006_0005_0004 for adrress 0->7 and similarly increasing the data...

Now the thing is when I should read, I should get the same data back. But waht I am getting back is +1 data...which is quite strange...

i.e.  0x0004_0003_0002_0001 , 0x0008_0007_0006_0005 for adrress 0->7 which is really really strange and confusing for me.

I cannot understand why... I can think of following possible reasons:

1. becasue of some internal (unknown to me) DDR3 or MIG specification, while reading it is reading 1 data bit ahead, i.e. instead of 0->7, it is reading from 1->8 and similarly increasing. But in my point of view this should not be the case, since it does not make any sense as far as I have understood DDR3 and MIG

2. there is miscaliberation while may be reading or wiring, But in my point of view, if that is the case, even then the data that I receive should be randomly sequenced, where as when I read, it is only increment of +1 which follows a proper pattern so I think this hypothesis is also rejected.

please check the captured image as well as the .vcd files attached

.

Thank you. 

[vsrunga]

Hi,

In your waveforms I see you are issuing write command before write data is filled in teh FIFO please check if you are doing this knowingly, this may cause zeros to be written in those address locations.

Please go through UG586 write, read and command path timing diagrams and change your logic accordingly.

Command and Data can be delayed by 1 or 2 clocks but not more than that, try to issue write command at the instance you started data writing with app_wdf_wren = '1' and recheck the behavior.

Hope this helps.

Regards,

Vanitha.

[sraza]

Hi again

I see your point.

Will try to improve, I guess I must take app_wdf_* set signals 1 or 2 latencies earlier than their current starting point.

May be this helps.

Thanks

[sraza · Accepted solution]

ok..

So it was quite starnge I found out that the clock frequency changing give me nice results to begin with.

Now I am getting what was expected. Which is quite exciting for me.

Previoulys I was using clk_mem = 260 Mhz, and clk = 130 Mhz

Now I changed the clock frequency for clk_mem to 300 Mhz and clk=150 Mhz. and lo and behold, I atleast get one set of data all right, now testing for more and complete algorithm. But I have one more question arrising now...But cannot ask here coz of forum policy. But any ways My question is how???  btw. I also tested it over 170 Mhz as well. it works fine till now

I have shown the image as well

Although for now I dont exactly know the reason, but thanks for help anyways.

[vsrunga]

Hi,

MIG core is expected to work over the frequency range specified in the GUI for the selected FPGA/DDR3 part provided the write/read and command timings specified in the UG were followed properly.

If those timings were not met data shift might occur as the data would not match the respective address location.

With frequency change data shift is not supposed to resolve, if it does there is a high chance that the issue arises with differnt set of frequencies,  if you are fine to go haead with the working frequencies then good Luck!

Regards,

Vanitha.

[sraza]

Ultimately it was found out my design had some problem when it was sending commands and data for WRITE to DDR3, after resolving which every thing went right