Description

When I simulate the MIG DDR2 or DDR3 SDRAM design, there are extra beats of data both at the beginning of a write command (prior to meeting the Write Latency - WL/CWL) and at the end of a write command. For example, when I request a single Burst Length=8 Write command from the user interface, 12 beats of data (instead of 8) are actually sent.

Is this the expected behavior of the core?

Solution

Yes, this is the expected behavior of the core.

The extra data seen at the beginning and end of the expected Burst Length Write are "don't cares" and do not affect the actual write that the memory device receives. The memory device accepts the write command. Wait until the WL (DDR2) or CWL (DDR3) is met to write the first valid data, and the number of words written is dictated by the burst length. The memory device then ignores anything else on the bus until the next command is received. To verify that the write command was received accurately, read back the data from the address location.

In MIG, the phy does not tri-state the DQS and DQ bus to the exact count because of a difference in path between the data and the tri-state. The data inputs of the OSERDES for DQS and DQ go through the IODELAY, whereas the tri-state inputs do not. Due to this difference, the design extends the tri-state a few CK cycles to ensure the bus is not tri-stated prematurely.

The MIG phy is responsible for sending the extra assertions on DQ/DQS at the beginning and end of the Write. The MIG controller is then responsible for properly timing the assertion of ODT to ensure overshoot on DQS/DQ does not occur during these additional assertions.

Linked Answer Records

Associated Answer Records