[1891ВМ12Я 0]

Добрый день!
Осваиваю DDR3 память на платформе Xilinx, на плате Digilent Arty с ПЛИС Artyx-7. Удалось правильно всё подключить, пример успешно заработал этот https://numato.com/kb/simple-ddr3-interfacing-on-nereid-using-xilinx-mig-7/ пример адаптированный для платы, даже вывожу в UART прочитанные данные - всё как надо. Также мне удается успешно симулировать стандартный пример traffic generator, вижу тайминги что как, тест в модели успешно проходит.

 

В чем собственно вопрос. Я не могу понять суть интерфейса записи. Использую не-AXI интерфейс (кажется native зовется он). Есть отдельно аля-FIFO с командой и адресом (app_cmd), и отдельно с данными app_wdf (write data fifo). У них отдельные очереди, отдельные сигналы готовности.

 

Пожалуйста, подскажите, в чем смысл такого разделения, как это понимать? Разве это не усложняет и не ухудшает работу, разве не удобнее чтобы адрес "ехал" вместе с данными? Я бы понял, если мы инициируем команду с адресом, а дальше толкаем данные в этот write data fifo и оно само инкрементирует адрес по мере записи.

 

Вопрос: для чего сделано разделение команды+адреса, и данных для записи. Я запутался в этом полностью. Должен быть какой то смысл этого разделения. Как же мне отслеживать, чтобы всё корректно клалось по нужному адресу, и читалось по нужному адресу. Или я не уловил принципы работы.

[RobFPGA 27]

Приветствую!

 

IMHO cмысл  такого разделения  как раз в выделении потока команд (с адресами), так как он обрабатывается в контроллере  отдельно и  фактически  является  основным управляющим потоком.
Нет особого смысла чтобы  адрес "ехал"  вместе с данными, да и для чтения это ведь "тяжеловато" сделать . 
А так  вы шлете поток команд (с адресами) и  в соответствии с этим потоком обеспечиваете  требуемое число слов данных для записи  и/или  получаете  запрошенное число слов данных чтения. 
На сколько помню  вы можете как заранее записать данные записи в FIFO  или даже с небольшой задержкой  после команды.  Главное чтобы  число записываемых слов данных соответствовало числу команд записи.  Тоже касается и числа  команд чтения и числа вычитываемых данных из FIFO чтения. 

 

Удачи! Rob.

[1891ВМ12Я 0]

1 hour ago, RobFPGA said:

А так  вы шлете поток команд (с адресами) и  в соответствии с этим потоком обеспечиваете  требуемое число слов данных для записи  и/или  получаете  запрошенное число слов данных чтения. 

На сколько помню  вы можете как заранее записать данные записи в FIFO  или даже с небольшой задержкой  после команды.  Главное чтобы  число записываемых слов данных соответствовало числу команд записи.  Тоже касается и числа  команд чтения и числа вычитываемых данных из FIFO чтения

Для чтения - согласен, но к чтению у меня претензий нет. Правильно я понимаю, что вся магия в том, чтобы пользователь ядра сам трясся, как бы у него не разъехались команды и данные? А еще я увидел режим back-to-back write режим, где данные и адреса едут вместе и каждая запись помечается как last, т.е. не burst.

 

У чтения аналогично, тоже надо вручную отслеживать, чтобы подать N команд чтения с N адресами, и чтобы в ответ было ровно N app_rd_data_valid?

 

т.е. вся суть в том что я просто должен смириться с таким интерфейсом, и делать обвязку так, чтобы следить за этими всеми числами, отслеживать команды, записи и чтения? Это конечно усложняет работу, контроллер выглядит "недоделанным", буду считать что "иначе сделать было никак" без потери какой то универсальности.

[vitzap 0]

Да, и есть особенность - команда считается достоверной, если в течении этого такта сигнал Rdy высокий. То есть могут быть такие случаи:

Анализируем сигнал Rdy - он высокий, т.е. все нормально, выставляем команду+адрес, а как раз в это время Rdy "упал". Поэтому мы должны держать эту команду, пока он снова не будет высоким. Но мы должны держать команду только один такт после фронта Rdy, иначе это будет уже две команды :)

Изменено 1 июня, 2021 пользователем vitzap

[RobFPGA 27]

Приветствую!

39 minutes ago, AVR said:

Правильно я понимаю, что вся магия в том, чтобы пользователь ядра сам трясся, как бы у него не разъехались команды и данные?

А  как по другому?  Вы  же  правите балом  а контроллер лишь "музыку играет"   По  любому при native интерфейсе вам надо делать арбитраж между  каналами чтения, записи и отслеживать правильное соотношение числа команд и данных.  
 

39 minutes ago, AVR said:

А еще я увидел режим back-to-back write режим, где данные и адреса едут вместе и каждая запись помечается как last, т.е. не burst.

Опять же  насколько помню  (с native интерфейсом года 3 назад работал ) как такового burst  режима нет на native интерфейсе.  Каждая транзакция (команда) на нем это всегда полный burst  на шине DDR.  Просто при некотором  соотношении  длинны DDR burst и  разрядности и частоты шины может понадобится 2 слова данных на шине для полного burst на DDR.  Отсюда  и наличие app_*_end. Но это соотношение фиксировано и определяется при конфигурации контроллера. 
 

39 minutes ago, AVR said:

У чтения аналогично, тоже надо вручную отслеживать, чтобы подать N команд чтения с N адресами, и чтобы в ответ было ровно N app_rd_data_valid?

Да,  так и есть.  Но с учетом кратности соотношения  длины burst DDR  и  разрядности шины (см выше)

 

39 minutes ago, AVR said:

т.е. вся суть в том что я просто должен смириться с таким интерфейсом, и делать обвязку так, чтобы следить за этими всеми числами? Это конечно усложняет работу, буду считать что "иначе сделать было никак" без потери какой то универсальности.

Не  хотите мирится  можете  сделать свой лог. контроллер шины со своей логикой и  состыковать его к  DDR PHY.    Модульность  контроллера и открытость исходников это обеспечивает. 
На  самом же деле  интерфейс и логика native довольно универсальна прозрачна и проста. И легко позволяет адаптировать под протоколы разных шин.   
Ну а для быстрого старта адаптации можете за основу  посмотреть интерфейс AXI4 <-> native. Там  фактически  и делается арбитраж и  конверсия обычного шинного burst.    

Удачи! Rob.    

[1891ВМ12Я 0]

12 minutes ago, RobFPGA said:

Ну а для быстрого старта адаптации можете за основу  посмотреть интерфейс AXI4 <-> native

С этого я начинал, но видимо структура документа меня запутала, в документации app_ сигналы описываются сразу в начале раздела после AXI, из за отсутствия нумерации у меня это вызвало путаницу, я переключил на UI интерфейс. Теперь уже с UI наверное буду работать.

 

В общем, спасибо за пояснения. Тема решена. Вывод: надо следить за записями и чтениями самостоятельно, аккуратно подсчитывая их количества, правда выглядит на первый взгляд ненадежно, что вызвало сомнения, породившие данную тему.

[quato_a 3]

21 minutes ago, AVR said:

надо следить за записями и чтениями самостоятельно, аккуратно подсчитывая их количества, правда выглядит на первый взгляд ненадежно, что вызвало сомнения, породившие данную тему.

Просто выделите два счетчика в своем арбитре транзакций: один под команды, второй под данные. Нужно вам записать 100 слов, то отправляйте команды записи с адресами с X по X+100 и параллельно данные с инкрементом каждого из счетчиков. Иногда rdy адресов и данных будут не активны (счетчик не инкрементируется). Какой-то из счетчиков (команд или адреса) дойдет по окончания раньше. Когда оба счетчики дошли, значит пачку из 100 слов записали.

[Flood 12]

9 часов назад, AVR сказал:

после AXI, из за отсутствия нумерации у меня это вызвало путаницу, я переключил на UI интерфейс. Теперь уже с UI наверное буду работать

Если это единственная причина использования native interface - посоветовал бы переключить контроллер на AXI4 и осваивать эту шину. Там также могут возникать вопросы синхронизации потоков записи/чтения/подтверждения, но шина AXI4 универсальнее и изучать ее было бы полезнее, в том числе и на перспективу. 

[1891ВМ12Я 0]

Работая с моделью контроллера DDR4 на UltraScale, я заметил проблемы. Например, я записал 5 слов по 512 бит, учитывая сигнал app_rdy и app_wdf_rdy. Но когда я читаю 5 слов, учитывая что app_rdy у меня в 1, то читается всего 4 слова, и хотя нужное слово выдается на шину, я вижу отсутствие строба app_rd_data_valid.

Постоянно вижу что на N команд чтения приходит существенно меньше стробов app_rd_data_valid, т.е. оно теряет команды, хотя не должно, ведь я учитываю готовность контроллера. При малом числе читаемых слов - оно вообще теряет первое слово - не дает строб. Иногда приходят неверные данные, я каждые 512 бит записывал повторяющиеся паттерны 01010101 020202 030303 и так далее. Например, на картинке я пишу слова 05050505 060606 070707 и так далее - всего 5. В ответ лишь 4 слова. Иногда верные данные проскакивают через адрес, будто сам адрес доходит до модели неверно.

Часто получаю FFFFFFFF при чтении, пришлось даже убрать uninitialized address read в настройках модели. Пробовал выставлять app_wdf_end лишь на последнее слово - так оно вообще нули стало читать.

Не прошу разбираться вместо меня. Лишь один вопрос, что хочу понять. А эти DDR4 модели, контроллер памяти в симуляторе - это рабочий инструмент???

Не могу понять, так как же мне работать с этим. Это я что-то делаю не так, или симуляция настолько ненадежна? Или я что-то не учитываю? В самом деле, попробую AXI интерфейс, и быть может подсмотрю тайминги внутрях, если они доступны.

[RobFPGA 27]

Приветствую!

36 minutes ago, AVR said:

А эти DDR4 модели, контроллер памяти в симуляторе - это рабочий инструмент???

Модель котроллера это тот же код что и синтезируется.  Я работал с ними, вроде все ок было. 

Вы бы  целиком привели диаграмму записи и последующего чтения с указанием имен сигналов. А то гадай на зеленой гуще что тут и куда  

 

Удачи! Rob.

[kamil_yaminov 1]

А при симуляции Вы проверяете, что в память пишутся корректные данные? Во-первых, у модели памяти можно включить отладочные сообщения, если они по-умолчанию отключены, во-вторых, если посмотреть вериложную модель памяти, то в ней присутствуют task'и типа memory_read, которые можно дёрнуть из тестбенча. По крайней мере в микроновских моделях что-то такое было.

И ещё, кажется, в модели контроллера для 7го артикса, сигнал app_rdy выдавался на выход с небольшой задержкой относительно клока app_clk, но могу ошибаться. Есть в коде модулей параметр TCQ, или что-то в этом роде. Может быть из-за этого у Вас некорректно защелкиваются данные на запись.

[1891ВМ12Я 0]

On 10/12/2021 at 5:27 PM, RobFPGA said:

Модель котроллера это тот же код что и синтезируется.  Я работал с ними, вроде все ок было.

По идее есть там тестбенч traffic generator, и оно в симуляторе успешно проходит. Однако да, иногда оно фейлится, не проходит свой же тест, но очевидно что это гораздо лучше чем у меня, а может у меня воспроизводится в силу каких то причин. Но сам факт разного прохождения теста от запуска к запуску меня настораживает.

 

On 10/12/2021 at 7:04 PM, kamil_yaminov said:

если посмотреть вериложную модель памяти, то в ней присутствуют task'и типа memory_read, которые можно дёрнуть из тестбенча

Спасибо, это интересная подсказка. В самом деле, я ведь могу вычитать интересующие адреса из модели напрямую, не обращаясь к MIG. Чтобы как минимум узнать, а правильно ли я записал. Пока что не нашел таски для чтения...

 

UPDATE: Таски memory_write и memory_read мне удалось найти лишь в ddr3_model.sv однако ddr4_model зашифровано, и никаких заголовков и документации найти не удалось, буду конечно пытаться предполагать что эти таски совпадают по параметрам с учетом моих настроек и ширин.

 

On 10/12/2021 at 7:04 PM, kamil_yaminov said:

И ещё, кажется, в модели контроллера для 7го артикса, сигнал app_rdy выдавался на выход с небольшой задержкой относительно клока app_clk, но могу ошибаться. Есть в коде модулей параметр TCQ, или что-то в этом роде. Может быть из-за этого у Вас некорректно защелкиваются данные на запись.

Как ни странно, я замечал это, но почему то не придал этому значение, попробую пересмотреть, но сначала проверю что записалось. Что интересно, ведь данные то читаются нередко правильно, неужели оно может в тех же условиях записываться правильно, и тут же - не правильно.

[kamil_yaminov 1]

Вот как, оказывается. С DDR3 было проще.

Однакл скачал первую попавшуюся модель DDR4 с сайта микрона, у неё в описании сказано:

Quote

Use these +define parameters for debugging:
MODEL_DEBUG_MEMORY  // Prints messages for every read and write to the memory core.
MODEL_DEBUG_CMDS    // Prints messages for every command/clk on the dram bus.

Может это как-то поможет.

Еще у модели DDR3 хранение записанных даннхы можно было организовать как минимум двумя способами: в одном случае данные хранятся в ассоциативном массиве, в другом, когда нужно располагать в памяти большие объемы, - в файлах на диске, для каждого банка, свой файл. Если здесь есть такая же опция, то можно из файла вытаскивать данные, единственно, формат представления данных был немного необычный, т.к. нужно как-то кодировать неинициализированные данные (x или z)

 

UPD. Нашел в архиве с моделью некий memory_file.txt с описанием формата данных

[1891ВМ12Я 0]

4 hours ago, kamil_yaminov said:

Однакл скачал первую попавшуюся модель DDR4 с сайта микрона, у неё в описании сказано:

UPD. Нашел в архиве с моделью некий memory_file.txt с описанием формата данных

А где именно качать? Я находил темы англоязычные, там пишут типа найди любую модель, выбери ее, оттуда качать zip файл. Но я все вкладки даташиты модели - всё обсмотрел и не вижу verilog модель. Как файл называется, какой раздел?

[kamil_yaminov 1]

Первая попавшаяся по запросу "micron ddr4 system verilog model" ссылка https://www.micron.com/products/dram/ddr4-sdram/part-catalog/mt40a2g4trf-093e, на странице по ссылке справа вкладка Simulation Models. Но, насколько помню, модель должна поставляться "в комплекте", при генерации example design? По крайней мере так было с DDR3/