Search code examples
fpgaxilinxspartan

Write memory timings for Spartan 7 4:1 Mig Generated DDR3 interface


I'm trying to understand the write memory timings for 7 Series FPGa's using the UI for a MIG generated memory controller (running at 4:1).

The documentation I'm following is the ug586 document from Xilinix. I'm particularly trying to understand Figure 1:77 which is replicated here:

Image 1-77 from ug586_7Series_MIS.pdf

My understanding is that for the first few cycles, app_addr app_en app_wdf_data app_wdf_wren and app_wdf_end are correctly asserted and data is written. See the blue lines.

The interesting point comes at (1) where the app_rdy is deasserted which means the Memory Controller is busy. At this point the app_addr is held on the same address (2) until app_rdy is reasserted at (6). All makes sense so far.

What I'm confused by is what is written to address a30? The choices are data (3) or (4) or (5). The diagram and logic implies that (3) is written to a30 (see dotted pink line). But I cant work out why. Looking at figure 1-75 in the docs you can give the write data one clock early but the data at (3) is 2 clocks early when compared to when app_rdy is re-enbled at the rising edge of the clock at (7). So that leaves either (4) or (5). But neither of those seem to make sense in this demo. So what is written to a30 and how do I work this out?

(I'm also interested whats written to the subsequent addresses but once I understand a30 I should be able to understand those too)


Solution

  • I'll answer my own question as I found an almost identical answer here.

    Basically the confusion is that the command queue (which is controlled by app_en and app_rdy) is seperate from the write queue (which is controlled by app_wdf_rdy and app_wdf_wren).

    This means that you can queue up the data for writes in advance of actually asking for the write - infact you can keep queueing write data until app_wdf_ready is deasserted.

    You must queue some write data for each write command. You can queue the write data in advance of the write command, on the same clock as the write command or up to two clocks later. The write data is a FIFO queue so you can queue lots of write data even before issuing a single write command!

    (The confusion comes from the example in the docs which show queuing data a single clock early - but if you read the text you get:

    1. Write data is presented along with the corresponding write command (second half of BL8).
    2. Write data is presented before the corresponding write command.
    3. Write data is presented after the corresponding write command, but should not exceed the limitation of two clock cycles

    Note that in point 2. there is no limitation mentioned of how early you're allowed to queue the data.

    This means that - in my exmaple - (3) is written to address a30 as it was in the write queue.