DDR2 Controller Write Error

Altera_Forum · ‎10-16-2009

I'm getting an odd write error with a DDR2 high-performance controller. After performing a large number of reads/writes in a memory test program, the controller gets into a mode where one byte lane's data is delayed by one write.

The system consists of a 3C120 dev board with a 64 bit DDR2 interface using a DDR2 HP controller in full-rate Avalon-MM interface mode. The controller is connected to a custom arbiter with two access ports. One port connects to a VGA video generator, which reads out video data into a line buffer for display. The other port connects to a Nios II system so the CPU can access the RAM.

During a test where the CPU writes 1MB of pseudo-random data to the RAM and reads it back for error checking, the DDR2 controller gets into a state where every write to one of the 16 byte lanes is delayed by one write. This problem starts after an average of about 2 billion write operations. See the example below of what the CPU sees after the error occurs:

Example (all accesses are char size):

*(DDR2_BASE_ADDRESS + 0xf) = 0x11;

*(DDR2_BASE_ADDRESS + 0xf) = 0x22;

result = *(DDR2_BASE_ADDRESS + 0xf); //result gets 0x11

*(DDR2_BASE_ADDRESS + 0xf) = 0x33;

result = *(DDR2_BASE_ADDRESS + 0xf); //result gets 0x22

All other byte lanes (0x0 to 0xE) work fine. It seems like a byte was written into a data FIFO in the controller but was never removed for some reason. The problem always starts during a write to the first address in memory, and usually happens on the 16th byte lane (0xF). According to SignalTap, the command sent to the controller is correct on the very first write command that is not executed correctly.

I have a suspicion that it's some problem with my arbiter, but I can't find anythign wrong with it. Is there any invalid command that would cause the controller to get into this mode?

Regards,

David

Altera_Forum · ‎02-21-2011

Did you ever find a solution to your DDR2 intermittent write error? I'm having a similar problem, except that I have one byte of four that will get behind about .00001% of transfers.

Timing analysis says everything should run fine (@125 MHz)

Thanks