ALTMEMPHY CycloneIII, bug ?

[Altera_Forum]

Hi all 

 I'm trying to get my DDR controller working, using ALTMEMPHY PHY on CycloneIII device, and I seems to get "data" misaligned by one DDR beat. I've following configuration:  1. ALTMEMPHY and custom DDR controller on CycloneIII device, running @ 150MHz, 16bits wide DDR, always 8beats burst access, CAS latency of 3.  2. FULL simulation is done at RTL level and validated the DDR controller, however, at ctl_wlat = 2 and ctl_rlat = 12. These numbers seems to be fixed for any RTL simulations. DDR controller do NOT use ctl_rlat, it qualify the read data returns with ctl_rdata_valid from PHY as suggested on the data sheet. However, DDR controller need to use ctl_wlat and is implemented for values for {1, 2, 3}. Also mutliple DDR vendor simulation modles, Micron and Hyx. And all is well.  3. On the real silicon, ALTMEMPHY has successfully done the DDR calibration, and come back with ctl_wlat = 3 and ctl_rlat = 19.  4. When I do the DDR memory test, it looks like DDR writes are "shifted by one beat". So when I do a write of sequence { 0x1234, 0x5678, 0x9abc, 0xdef1, 0x2345, 0x6789, 0xabcd, 0xef01 } and read back return { 0xFFFF, 0x1234, 0x5678, 0x9abc, 0xdef1, 0x2345, 0x6789, 0xabcd }.  5. I guess the first 0xFFFF is due to park stat of data bus, and this behaviour is consistance across ALL memory range.  6. My gut feels is there is something wrong with ctl_wlat calculation or the way I use the ctl_wlat number.  Any pointers, suggestions, comments much appreciated.

[Altera_Forum]

--- Quote Start ---  Hi all  I'm trying to get my DDR controller working, using ALTMEMPHY PHY on CycloneIII device, and I seems to get "data" misaligned by one DDR beat. I've following configuration:  1. ALTMEMPHY and custom DDR controller on CycloneIII device, running @ 150MHz, 16bits wide DDR, always 8beats burst access, CAS latency of 3.  2. FULL simulation is done at RTL level and validated the DDR controller, however, at ctl_wlat = 2 and ctl_rlat = 12. These numbers seems to be fixed for any RTL simulations. DDR controller do NOT use ctl_rlat, it qualify the read data returns with ctl_rdata_valid from PHY as suggested on the data sheet. However, DDR controller need to use ctl_wlat and is implemented for values for {1, 2, 3}. Also mutliple DDR vendor simulation modles, Micron and Hyx. And all is well.  3. On the real silicon, ALTMEMPHY has successfully done the DDR calibration, and come back with ctl_wlat = 3 and ctl_rlat = 19.  4. When I do the DDR memory test, it looks like DDR writes are "shifted by one beat". So when I do a write of sequence { 0x1234, 0x5678, 0x9abc, 0xdef1, 0x2345, 0x6789, 0xabcd, 0xef01 } and read back return { 0xFFFF, 0x1234, 0x5678, 0x9abc, 0xdef1, 0x2345, 0x6789, 0xabcd }.  5. I guess the first 0xFFFF is due to park stat of data bus, and this behaviour is consistance across ALL memory range.  6. My gut feels is there is something wrong with ctl_wlat calculation or the way I use the ctl_wlat number.  Any pointers, suggestions, comments much appreciated.  --- Quote End ---    I've got to the bottom of this, its Quartus 9.0 SP1 generate rubbish ALTMEMPHY IP. Upgraded to Quartus 9.1 SP2 and all works now.  Stay away from Quartus 9.0 if you are using ALTMEMPHY, at least for CycloneIII devices.