fpga-systems-magazine

Заметка о проблеме с контроллером памяти LPDDR2 Xilinx 7 Series MIS

Главная » Статьи » Xilinx » Xilinx Vivado
alexeyshashkov
14.01.2019 09:05
3419
0
0.0
Думаю, что при разработке систем на базе FPGA или ASIC многие сталкивались с проблемами, возникающими при подключении сторонних IP-ядер (IP-ядер не собственной разработки): это затруднения, связанные с неполной или недостоверной документацией, ошибками интерфейса конфигурации ядра, параметрами конфигурации с непонятным назначением. Однако иногда возникают и проблемы, которые стоят гораздо большего количества времени, чем вышеназванные препятствия.
Так случилось и в моей практике при подключении контроллера памяти LPDDR2 Xilinx 7 Series MIS для FPGA Artix-7. Проект, в котором использовался данный контроллер памяти, создавался и синтезировался в последней на тот момент версии Xilinx Vivado 2018.2. Так сложилось, что память LPDDR2 уже давно не являлась приоритетной для Xilinx, и этот тип памяти уже давно не получал никаких обновлений в этом контроллере памяти. Так, например, для LPDDR2 у контроллера Xilinx MIS нет такого варианта интерфейса пользователя, как AMBA AXI, но есть нестандартный интерфейс под названием User Interface. С этим интерфейсом и был связан системный сбой, который я пытался устранить вместе с коллегами на протяжении нескольких месяцев (разумеется, я всё это время занимался не только этим сбоем, но, тем не менее, решение не находилось довольно долго).
В течение нескольких месяцев проект, в котором использовался контроллер LPDDR2 от Xilinx, как это обычно и бывает, находился в стадии инкрементальной разработки и отладки, и очередная новая прошивка загружалась в чип FPGA напрямую. После такой загрузки прошивки проект всегда работал без каких-либо сбоев со стороны контроллера памяти. Но как только прошивка уже была достаточно стабильна, чтобы хранить её во внешней конфигурационной памяти (SPI Flash), после загрузки прошивки из этой памяти и начались странные отказы системы. После многих итераций поиска источника проблемы с помощью установок IP-ядра анализатора Xilinx ILA в самые разные места кода RTL выяснилось, как казалось, невероятное: сбой был именно на интерфейсе пользователя Xilinx MIS User Interface. Затем была собрана тестовая версия проекта с только контроллером памяти и очень простой логикой тестирования User Interface. Так, убрав всё лишнее, и было подтверждено наличие проблемы именно с Xilinx MIS.
Суть сбоя заключалась в следующем. Управляющий контроллером памяти модуль с User Interface отправлял одну команду чтения, и до отправки следующей команды ожидал прихода от контроллера двух слов по 128 бит, одно за другим, как это и должно было бы быть по спецификации Xilinx MIS. Однако в случае загрузки конфигурации из именно внешней конфигурационной памяти SPI Flash, User Interface, по существу, выходил из строя. Так, ещё до отправки первой команды интерфейс присылал одно слово на 128 бит (и даже не два, обычно этот контроллер и делает). Затем контроллер работал какое-то время нормально, но изредка он мог ответить на команду чтения одним 128-битным словом вместо двух.
Я многократно проверил подключение контроллера в проекте, менял все возможные настройки контроллера, даже пересобрал проект на основе проекта-примера для данного контроллера от Xilinx, но это ничего не изменило. Далее возникло предположение, что, возможно, проблема заключалась в питании FPGA, подключении и разводке на плате памяти LPDDR2. Плата с данной FPGA совместно с коллегами была приведена к идеалу по питанию, были перепроверены связи LPDDR2 с FPGA, но проблема так и не решилась. Далее я адаптировал проект под другие наши похожие платы с такой же памятью LPDDR2 и таким же чипом FPGA. И на тех платах проблема наблюдалась в точно таком же виде! А на одной из плат сбой контроллера присутствовал даже при загрузке прошивки напрямую в FPGA минуя конфигурационную SPI Flash.
Однако для вышеупомянутых других плат у моего коллеги уже были проекты с таким же контроллером памяти, и у него всё работало без каких-либо сбоев. Мы начали смотреть, что у нас с коллегой отличается, и выяснилось, что отличается у нас именно версия Vivado: у меня была установлена версия 2018.2, а у коллеги была версия 2016.3. Я пересоздал проект на Vivado 2016.3 на виртуальной машине под Windows 10, но сбой сохранился. Я попросил коллегу выслать мне его проект (он работал на Windows 7), я удалил из этого проекта всё, кроме контроллера памяти, перенёс туда без каких-либо изменений свой RTL-код, и проблема была полностью решена: проект работал стабильно при всех случаях на всех платах. Затем я открыл данный работающий без сбоев проект в Vivado 2018.2 на своей рабочей станции, обновил в этом проекте все ядра, включая ядро контроллера до последней версии, и всё по-прежнему работало без сбоев! Я даже удалил из этого проекта настроенный контроллер памяти, снова его добавил и перенастроил, и сбоев по-прежнему не наблюдалось. Единственное, что отличается в этом проекте от проекта, изначально созданного в Vivado 2018.2 – это настройки синтеза и имплементации, которые и сообщают, что они перенесены из проекта версии 2016.3.
Подводя итог могу сказать, что проблема, на мой взгляд, заключалась именно в неверном синтезе и имплементации старого ядра Xilinx MIS в новой версии Vivado. Однако подтвердить эту гипотезу весьма затруднительно: это потребовало бы кропотливого реверс-инжиниринга контроллера Xilinx MIS и анализа результатов синтеза и имплементации, чем я не занимался. Почему на стабильность работы контроллера влиял именно способ загрузки конфигурационной прошивки FPGA так и осталось загадкой.
3419
0
0.0

Всего комментариев : 0
avatar

FPGA-Systems – это живое, постоянно обновляемое и растущее сообщество.
Хочешь быть в курсе всех новостей и актуальных событий в области?
Подпишись на рассылку

ePN