- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 appreciatedLink Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page