Контроллер памяти DDR2 для Altera Cyclone, размышления на тему о предельной частоте Опции

[Hoodwin]

Вот хочу поднять тему о принципах построения контроллера DDR2 памяти для Altera Cyclone. На данный момент делаю его для Cyclone 3. Но суть то как раз в том, что в отличие от альтеровских коров он написан просто на VHDL с использованием только IEEE.numeric_std. И поэтому он в принципе универсален, может применяться для Spartan, например.

Собственно интерес возник вот по какой причине. С самого начала продвижения DDR в FPGA альтеровцы нагородили там какую-то специальную поддержку DDR прямо в IOE. И вот, апофеоз всех их страданий, в Cyclone 3 руководство по применению контроллера - увесистый документ, объясняющий, в частности, что для реализации правильной времянки памяти нужно чуть ли не 5 выходов PLL, причем для простого циклона -С8 можно рассчитывать на тактовую частоту только около 133 МГц (По крайней мере визард больше не дает). И это при том, что максимальная частота самого Cyclone III (и даже Cyclone II) ограничена значением в 402 МГц. А, следовательно, даже лобовое решение, когда DDR эмулируется на удвоенной частоте, должно дать реализацию в 200 МГц даже для speed grade 8. Причем для этого потребуется весьма простая PLL с тремя выходами, и в настройке такое решение весьма неприхотливо. Фазы можно двигать с помощью настроек PLL, а на выводах не нужны никакие DDR опции, что освобождает от мучительного размещения выводов по группам DQ/DQS, как это было раньше.

Ну вот исходя из этих соображений я и сел рисовать такой контроллер, с целью проверить, какова будет в итоге у него предельная частота. Ограничения собственно два.
1) Удастся ли логику всего контроллера реализовать с частотой 200 МГц.
2) Удастся ли реализовать входную и выходную часть шины данных с переходом 32бита*200МГц в 16бит*400МГц.

Еще до конца не доделал, но предварительно удалось. Проект бегает в ModelSim'е с двумя моделями, от Micron и от Samsung, правда данные там пока автосинтезируемые, но в правильных местах. При этом квартус собирает это и дает нормальные частоты даже для C8, 201 МГц для контроллера и 402 для данных (и то, - это программное ограничение, без указания явных проблемных путей).

Уже недолго осталось, чтобы на железке проверить, но все-таки кажется странным, что же это за столбовая дорога у Альтеры такая, что столько возни, столько правил и такой чахлый результат.
"Гора родила мышь!"

У кого какие мысли?

[Hoodwin]

Интерфейс такой:

Код

  ready     : out std_logic;  -- controller is ready to accept command
  ad        : in  std_logic_vector(CTL_WIDTH_ADDR-1 downto 0);
  wr        : in  std_logic;  -- write strobe
  wr_tag    : in  std_logic_vector(TAG_WIDTH-1 downto 0);
  di        : in  std_logic_vector(MEM_WIDTH_DATA*2-1 downto 0);
  di_ena    : in  std_logic_vector(MEM_WIDTH_DATA/4-1 downto 0);
  di_get    : out std_logic;  -- input data read (e.g. from FIFO)
  di_tag    : out std_logic_vector(TAG_WIDTH-1 downto 0);
  rd        : in  std_logic;  -- read strobe
  rd_tag    : in  std_logic_vector(TAG_WIDTH-1 downto 0);
  do        : out std_logic_vector(MEM_WIDTH_DATA*2-1 downto 0);
  do_put    : out std_logic;  -- output data vaild
  do_tag    : out std_logic_vector(TAG_WIDTH-1 downto 0);

Пояснения
- ready - сигнал готовности интерфейса к приему команды rd или wr. При любый условиях после приема команды ready пропадает как минимум на один такт, что позволяет делать мультиплексор входной команды и адреса, дающий задержку в 1 такт. Такая задержка неизбежно возникнет. если будет потребность в скоростном многопортовом доступе к памяти.
- ad - адрес текущей операции.
- wr - признак команды записи. Не должен выдаваться одновременно с rd.
- rd - признак команды чтения. Не должен выдаваться одновременно с wr.
- wr_tag - метка команды записи. См описание меток ниже.
- rd_tag - метка команды чтения. См описание меток ниже.
- di - данные для записи. Считываются при активном стробе чтения di_get.
- di_ena - признаки разрешения на обновление данных. Управляют маской при записи. значение '1' разрешает запись соответствующего байта.
- di_get - строб чтения. Возникает через некоторое время после того, как контроллер принял команду записи. Длится два такта для BL=4, и 4 такта для BL=8.
- di_tag - метка входных данных. Выдается синхронно с di_get и позволяет установить, от какого источника фактически нужны данные в данный момент.
- do - данные, прочитанные из памяти, активны под стробом do_put.
- do_put - строб готовности данных чтения. Возникает некоторое время после того, как контроллер принял команду чтения. Длится два такта для BL=4, и 4 такта для BL=8.
- do_tag - метка выходных данных. Выдается синхронно с do_put и позволяет установить, кому предназначаются данные в данный момент.

Общий принцип работы такой. Контроллер устанавливает сигнал ready и ожидает команды. Команда считается принятой, если в одном такте либо ready='1' и rd='1', либо ready='1' и wr='1'. В этом такте должны вместе с командой должны быть указаны также адрес ad, метка чтения rd_tag (rd='1') или метка записи (wr='1'). Приняв команду контроллер снимает ready и планирует команду на внешнем интерфейсе, параллельно проверяя всякие внутренние события: необходимость делать precharge, активацию новой строки, ожидание на переключение направления шины, регенерацию и т.п. Как только внутреннее состояние контроллера доберется до выдачи непосредственной команды на шину, контроллер формирует сигнал di_get для команды записи и забирает данные пользователя, которые затем попадают на шину. При команде чтения с некоторой задержкой формируется строб do_put.

Метки
Пролистывал документ от Altera, не видал у них такой фичи. Но себе сделал. потому как удобно. Часто память требует разделения между разными потребителями. Например, у меня видеопамять требует доступа на чтения со стороны подсистемы формирования развертки, полного доступа стороны процессора, а также, в перспективе, доступа на запись со стороны видео-ускорителя. Конвейерный характер доступа к памяти, а также довольно большие задержки конвейера приводят к тому, что команды разных потребителей порождают непредсказуемо задержанные фазы передачи данных и для чередования потребителей в такой ситуации приходится ждать, пока контроллер полностью освободит не только командную шину (rd, wr, ad), но и шины данных (di и do). Проверка этих условий весьма утомительна, так как, вообще говоря, занятость шины данных неизвестна. Можно было бы учитывать, сколько команд выдано. и сколько потом фаз данных состоялось, но это муторно, это не наш метод. Вместо этого контроллер позволяет метить команды с помощью тегов и гарантирует, что система тэговых задержек синхронизирована с шиной самой памяти, так что в итоге разные потребители могут просто свалить в кучу все команды и получат назад пакет данных, в котором выходные данные помечены ровно так же как и входная последовательность команд. например, если читатель выдал команду rd='1', rd_tag=2, то его данные пойдут под стробом do_put and do_tag=2, причем совершенно не важно, с какой задержкой возникнет строб. Это достаточно удобно. Вам просто достаточно сделать автомат, планирующий команды и правильно подключить источники/приемники данных. В особенности это хорошо сочетается с FIFO, поскольку там нет явного адреса, но и с чтением в память тоже сочетается без сложностей.

В заключение привожу времянку, как это выглядит. Обратите внимание на движение rd_tag -> do_tag & do_put и на wr_tag -> di_tag & di_get.

Эскизы прикрепленных изображений

 

[Timmy]

Может быть, имеет смысл разделить на отдельные модули командный блок и блок передачи данных? Иначе этот контроллер будет Cyclone 3 only. Блок передачи данных нельзя нормально сделать архитектурно независимым, зато он достаточно тривиален по логике и его можно спокойно портировать. А командный блок по логике нетривиален, зато архитектурно независим.
Если контроллер не изменяет порядок выполнения команд относительно порядка запросов, то стоит также вынести в отдельный модуль управление тэгами.
Полезно предусмотреть команды с автозакрытием банка - так будет работать быстрее, например, для каналов DMA, делающих запросы не очень часто.
Что касается подключения к шинам типа Avalone, Wishbone и тд, то мосты для них могут написать те, кому это больше всех надо, и потом можно добавить к проекту.