Тайминги памяти для Spartan 7 4:1 Mig Generated DDR3 interface

Я пытаюсь понять тайминги записи в память для FPGa 7-й серии, используя пользовательский интерфейс для контроллера памяти, созданного MIG (работающего на скорости 4:1).

Я использую документацию ug586. от Ксилиникса. Особенно я пытаюсь понять рисунок 1:77, который воспроизводится здесь:

Изображение 1-77 из ug586_7Series_MIS.pdf

Насколько я понимаю, для первых нескольких циклов app_addr app_en app_wdf_data app_wdf_wren и app_wdf_end правильно утверждаются, и данные записываются. Смотрите синие линии.

Интересный момент наступает в (1), где app_rdy сбрасывается, что означает, что контроллер памяти занят. В этот момент app_addr удерживается по тому же адресу (2) до тех пор, пока app_rdy не будет повторно подтверждено по адресу (6). Все имеет смысл до сих пор.

Что меня смущает, так это то, что написано на адрес a30? Возможные варианты: данные (3), (4) или (5). Диаграмма и логика подразумевают, что (3) записывается в a30 (см. розовую пунктирную линию). Но я не могу понять, почему. Глядя на рисунок 1-75 в документах, вы можете дать данные для записи на один такт раньше, но данные в (3) на 2 такта раньше по сравнению с тем, когда app_rdy повторно включается на нарастающем фронте тактового сигнала в (7). Так что остается либо (4), либо (5). Но ни один из них, похоже, не имеет смысла в этой демонстрации. Так что же написано в a30 и как мне это обработать?

(Мне также интересно, что написано на последующих адресах, но как только я пойму a30, я смогу понять и их)


person Mike Vine    schedule 19.07.2018    source источник
comment
Больше похоже на вопрос для electronics.stackexchange.com, чем здесь. См. stackoverflow.com/help/on-topic.   -  person barny    schedule 19.07.2018
comment
Похоже, на это ответил здесь   -  person Mike Vine    schedule 19.07.2018
comment
Было бы полезно, если бы вы включили ссылку на UG586. которые на самом деле содержали цифры, указанные в вашем вопросе. Ссылка на ваш вопрос содержит разные рисунки, на которых не отображается одинаковая информация (см. рисунки с 1-47 по 1-48). Ваш рисунок взят из версии документа 2015–2018 годов, предоставленная вами ссылка 2011 версия.   -  person    schedule 20.07.2018
comment
@ user1155120 Извините, вы правы - обновил ссылку в вопросе.   -  person Mike Vine    schedule 20.07.2018


Ответы (1)


Я отвечу на свой вопрос, так как нашел почти идентичный ответ здесь.

В основном путаница заключается в том, что очередь команд (которая контролируется app_en и app_rdy) отделена от очереди записи (которая контролируется app_wdf_rdy и app_wdf_wren).

Это означает, что вы можете ставить данные в очередь для записи до фактического запроса на запись — на самом деле вы можете продолжать ставить данные в очередь на запись до тех пор, пока app_wdf_ready не будет отменено.

Вы должны поставить в очередь некоторые данные записи для каждой команды записи. Вы можете поставить данные записи в очередь перед командой записи, в то же время, что и команда записи, или на два часа позже. Данные для записи представляют собой очередь FIFO, поэтому вы можете поставить в очередь большое количество данных для записи даже до выдачи одной команды записи!

(Путаница возникает из-за примера в документах, который показывает данные очереди на один такт раньше, но если вы прочитаете текст, вы получите:

  1. Данные записи представлены вместе с соответствующей командой записи (вторая половина BL8).
  2. Данные записи представлены перед соответствующей командой записи.
  3. Данные записи представляются после соответствующей команды записи, но не должны превышать ограничение в два такта.

Обратите внимание, что в пункте 2 не упоминается ограничение того, насколько рано вам разрешено ставить данные в очередь.

Это означает, что в моем примере (3) записывается по адресу a30, как это было в очереди записи.

person Mike Vine    schedule 20.07.2018