DDR2 reading errors on last two words

[Altera_Forum]

Hi, 

 I've some problems with my ddr2 design. I use Altera DDR2 high performance IP on pci express dev board (Stratix II GX).  I build some logic around my memory controler in order to test it. I write some knows patterns and I try to read them back. After a couple of writes successful (local_ready and local_wdata_req have good behavior), I read my datas back.  My problem is that when I read memory, the two lasts words are bad and all others are good. Every time. If my pattern is 10 words long, I read back 8 good words and the last two words are bad. Whatever the patterns I use (eg different length), it's always the same...  I've tested two methods for memory address generation : - Contiguous (eg 0h, 1h, 2h, 3h, 4h...) in order to stay in the same bank and same row. Just like a burst. - Randomly generated in all the banks, in different rows to force controller to precharge rows.  Results are exactly the same, whatever the method I use...   All my timing constraints are good. I met all requirements. Terminations, drive strength, output load ... are good too. All seems to be ok. All memory signals at local side have correct behaviour.  Someone have got an idea of what's it's going on ? What can I check in my design ?  I'm lost, I don't know what to do to fix that. Please help me! Thanks in advance for you help.  Fabrice.

[Altera_Forum]

Did you also try with the Altera provided test driver for DDR2 HP core? Just to assure, that it isn't a problem of wrong interface handling? In case of signal quality issues, you rather get accidental faults at different locations because of the pseudo random data used by the test driver.

[Altera_Forum]

Yes, I try the example driver.  

 And with it, I see a lot of differences between write datas and read back datas in signal tap II. But the test complete signal goes high after reading pattern back so I think errors I see are just a display bug from signal tap.  But there is one difference between the example driver "errors" and mines. Because with the provided driver, when read back datas are not equal to write datas, just some bits in the word are different.  And with my driver, when I read back a bad word, the word is fill up with 00's and FF's (randomly). I don't know why...  Note that I reuse the working example design, remove the example driver and put mine. So configuration of ddr ip is the same (pinout, terminations...).  Thanks for your further help!   Edit: I've checked the example driver and the test complete signal who tell that all reading datas back are ok is not going high at all the time. One time is goes high, another time not. Maybe 50% of fault test. But in both of case, I've got differences between write and read datas! Any help would be appreciated!

[Altera_Forum]

If you don't get timing errors related to SignalTap, you can basically trust it's results. As far as I understand, SignalTap shpws read faults as the missing pnf output does. If it occurs at accidental positions in the test, it's most likely a signal quality or timing issue. If we can assume, that the Dev. Board hardware is O.K., it must be related to your settings.

[Altera_Forum]

Actually, no timing erros with or without signal tap. 

 But after checking example driver results, something is not clear for me. does the pnf output need to be at '1' or at '0' to indicate good comparison ?  Because in my case, pnf output is always at low level. And pnf_per_byte outputs are all low when writing and all high when reading. Except sometimes where some bits are low when reading!  Well, I join two screenshots in order to help you to visualize example driver behaviour. Maybe it will be usefull for you.   If the problem comes from my settings, I don't understand. Because I met all recommandations from altera (with the AN328). All timing requirements are good too.  Maybe can you tell me more precisly which settings can cause this kind of fault ? (drive strength, output load, clock phase of pll...).  I thank to you for all your help!

[Altera_Forum]

I have not use the ddr2 HP core, but i have used the ddr sdram controller. In that core ,the test_complete signal always goes high when reading is finished. It does not indicate the test is passed. pnf is short for pass no fail, 1 is passed and 0 is failed. I think it's the same for ddr2 HP controller. 

If i'm correct, pnf should always be high before reading starts, I can't understand why yours is low. You may check your core for detail information.

[Altera_Forum]

pnf_per_byte is indicating the momentary check result, pnf_persist should go high at begin of each test pass and optionally low, when a verify error occurs. Cause pnf_per_byte is high during (at least most of) the verify phase, it looks rather like a problem of overall operation of the core than an accidental data error, contradicting some of your previousls reported observations. 

 But I don't remember all details of test driver operation and don't have a hardware at hand to check it now. Also, some details may have changed from V7.2 that I used.   A detailed analysis must check the signal tap results exactly and can't be done on the screenshots. The test driver top design is almost simple, you should be able to trace it to the point where pnf_persist should go high but doesn't.

[Altera_Forum]

--- Quote Start ---  Hi,  My problem is that when I read memory, the two lasts words are bad and all others are good. Every time. If my pattern is 10 words long, I read back 8 good words and the last two words are bad. Whatever the patterns I use (eg different length), it's always the same...  Someone have got an idea of what's it's going on ? What can I check in my design ?   Fabrice.  --- Quote End ---    I've also conquered the same problem with the high speed DDR2 controller of the SOPC builder. Depending of the size of the FIFO's you use, the more data is buffered. Have you already tried to do some dummy accesses to the RAM? In my case, I was writing with a NIOS processor to a video frame buffer and every time the transfer was completed, the last pixels (the last written words) stay unchanged. Doing some dummy writes resolved my problem (words in the FIFO are placed to RAM after some dummy writes)...  Hopes this helps?

[Altera_Forum]

Sounds to me like an unaligned memory access issue.  

Check the data width of your controller, the address locations you can access are only multiples of the data width.  For example, a 64-bit data width, addressing can only happen at these addresses : 0x0, 0x64, 0x128, 0x192, 0x256...etc  Cheers, Thean Charn