FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP

DDR3 controller issue

Altera_Forum
Honored Contributor II
1,435 Views

I am working on a project in which 8Gb data is to be written in DDR3 memory. I am using Altera Uniphy DDR3 controller. After filling DDR3 memory with data we tried to read back our DDR3 memory to verify data is written correctly. After some reads DDR3 controller shows some misbehavior. First the data we received didn't match with the expected pattern also the address that we have read previously (with correct data pattern) shows mismatches. For example once data start mismatching the address 0 show different values at different reads. Some facts: 

 

1. we are using 256-bit interface and our data pattern is a simple 32-bit counter 

2. we are using linear addressing for reading and writting with write burst size = 128x256 and read burst size = 16x256 maximum burst size is set to 256x256 

3. some times we see bit mismatches but we are not using the byte enables 

 

What can be the issue? Any hint/clue will be much appreciated
0 Kudos
3 Replies
Altera_Forum
Honored Contributor II
712 Views

Too few information. What type of DDR3 controller do you use? Is it one from megawizard, or third party core? Does it meet timing constrains? It's more likely auto refresh command does no assert or not meet ddr3 timing requirements. Personally, I would rather find exact memory model and simulate the controller using modelsim.

0 Kudos
Altera_Forum
Honored Contributor II
712 Views

Thanks for helping out  

1. Its one generated from megawizard. 

2. Yes all timing constraints meet. 

 

Another issue; once the controller starts troubling, the data which is supposed to be on address 0 appears at address 1 and the data that should be on address 1 appears at address 2 

 

For example If I assert burst begin for a cycle with read req, transfer size of 16 256-bit words with address equal to zero. I receive an unexpected value at first valid beat and the second beat contains the word that should be on the first beat. 

 

I doubt that it may be due to unstable burst-begin signal that deasserts before avl_ready. I haven't captured that scenario in signalTap but once I get the first wrong data I always get the wrong data. I have tried 100s of read 

 

I will try to get the DDR3 model and simulate it in Modelsim 

 

Thanks CoworthRS
0 Kudos
Altera_Forum
Honored Contributor II
712 Views

Did you resolve your problem yet? 

Could you tell me how to resolve it? 

Ah, my skype ID is : hoai_viet_83 

Please reply me as soon as possible. 

 

Thanks and best regards.
0 Kudos
Reply