cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Explorer
Explorer
10,758 Views
Registered: ‎03-13-2012

partial data corruption while DDR3 read.

Jump to solution

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

 

 

.write_data.JPGread_data.JPG

 

Thank you. 

0 Kudos
Reply
1 Solution

Accepted Solutions
Explorer
Explorer
17,243 Views
Registered: ‎03-13-2012

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.

 

success_read_150Mhz_drawn.JPG

View solution in original post

0 Kudos
Reply
5 Replies
Xilinx Employee
Xilinx Employee
10,743 Views
Registered: ‎07-11-2011

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.

---------------------------------------------------------------------------------------------
Please do google search before posting, you may find relavant information.
Mark the post - "Accept as solution" and give kudos if information provided is helpful and reply oriented
Explorer
Explorer
10,732 Views
Registered: ‎03-13-2012

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

0 Kudos
Reply
Explorer
Explorer
17,244 Views
Registered: ‎03-13-2012

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.

 

success_read_150Mhz_drawn.JPG

View solution in original post

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
10,717 Views
Registered: ‎07-11-2011

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.

 

---------------------------------------------------------------------------------------------
Please do google search before posting, you may find relavant information.
Mark the post - "Accept as solution" and give kudos if information provided is helpful and reply oriented
Explorer
Explorer
10,623 Views
Registered: ‎03-13-2012

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

0 Kudos
Reply