Совместное моделирование для проектов на основе Zynq

Гетерогенные устройства «система на кристалле» (SoC), такие как Xilinx Zynq 7000 и Zynq UltraScale + MPSoC, сочетают в себе высокопроизводительные системы обработки с современной программируемой логикой. Эта комбинация позволяет спроектировать систему так, чтобы обеспечить оптимальное решение. Пользовательские интерфейсы, связь, управление и конфигурация системы могут обрабатываться процессорной системой (PS). Между тем, программируемую логику (PL) можно использовать для реализации детерминированных функций с малой задержкой и конвейеров обработки, которые используют ее параллельную природу, такую ​​как те, которые используются обработкой изображений и промышленными приложениями.

Связь между PS и PL обеспечивается несколькими интерфейсами с отображением в память. Эти интерфейсы используют расширенный расширяемый интерфейс (AXI) для обеспечения связи как главного, так и подчиненного устройства в каждом направлении.

Рис. 1. Архитектура Zynq, демонстрирующая соединение AXI между PS и PL (Источник:Xilinx)

В случаях, когда функции конфигурирования и управления выполняются PS, общий интерфейс AXI Master используется от PS к PL. Это позволяет программному обеспечению (SW) настраивать регистры и, следовательно, желаемое поведение IP-ядер в PL. В более сложных операциях может возникнуть желание передать большие объемы данных из PL в пространство памяти PS для дальнейшей обработки или передачи данных. Эти передачи будут использовать высокопроизводительные интерфейсы, что потребует значительно более сложного программного обеспечения для настройки и использования.

Проверка взаимодействия между PS и PL представляет проблему для команды разработчиков. Обзор рынка встраиваемых систем за 2015 год определил отладку как одну из основных проблем проектирования, с которыми сталкиваются инженерные группы, а также выявил необходимость в улучшенных инструментах отладки. Хотя функциональные модели шины могут использоваться на начальном этапе, эти модели часто упрощены и не позволяют одновременно проверять разработанные драйверы ПО и приложение. Доступны полнофункциональные модели, но они могут быть непомерно дорогими. При реализации разнородной конструкции SoC должна быть стратегия проверки, которая позволяет одновременно проверять как элементы PL, так и элементы PS, как можно раньше.

Традиционно проверка первоначально выполнялась для каждого элемента (функционального блока) в проекте изолированно; проверка всех блоков вместе происходит, когда приходит первое оборудование. Команда разработчиков программного обеспечения, разрабатывающая приложения для работы на PS, должна гарантировать, что ядро ​​Linux содержит все необходимые модули для поддержки его использования и имеет правильный большой двоичный объект дерева устройств; это обычно проверяется с помощью QEMU (сокращение от Quick Emulator), который представляет собой бесплатный гипервизор с открытым исходным кодом, который выполняет виртуализацию оборудования.

Между тем, для правильной проверки конструкции PL требуется, чтобы группа проверки логики сгенерировала и упорядочила команды, подобные тем, которые выдает прикладное программное обеспечение, для проверки того, что логика функционирует должным образом. Однако оба этих подхода не отражают истинного взаимодействия программного обеспечения с оборудованием, что затрудняет обнаружение ошибок, связанных с этим взаимодействием. Это задерживает график разработки и увеличивает затраты на разработку, поскольку проблемы, возникающие на более поздних этапах процесса разработки, всегда дороже решать и исправлять.

Можно использовать отладочную плату в качестве промежуточного шага для проверки взаимодействия аппаратного и программного обеспечения до прибытия окончательного оборудования. Однако отладка на реальном оборудовании может быть сложной, требуя добавления дополнительной инструментальной логики в оборудование. Эта вставка требует дополнительного времени, так как битовый файл необходимо регенерировать, чтобы включить в него логику инструментария. Конечно, это изменение в реализации может также повлиять на поведение, лежащее в основе дизайна, тем самым маскируя проблемы или создавая новые проблемы, которые проявляются только в отладочных сборках.

Таким образом, возможность проверки проектов SW и HW с помощью совместного моделирования дает несколько существенных преимуществ. Это может быть выполнено на более раннем этапе цикла разработки и не требует ожидания прибытия оборудования для разработки, что снижает стоимость и влияние отладки. Кроме того, такой подход также обеспечивает большую прозрачность в отношении регистров и взаимодействий между PS и PL, что помогает обнаруживать и удалять ошибки на более ранних этапах процесса.

Совместное моделирование аппаратного и программного обеспечения

Совместное моделирование между SW и HW требует, чтобы инструмент логического моделирования, используемый для проверки проекта HW, мог взаимодействовать со средой эмуляции SW моделирования.

Выпуск Aldec's Riviera-PRO (2017.10) позволяет только это совместное моделирование аппаратного и программного обеспечения путем предоставления моста между Riviera-PRO и QEMU, тем самым обеспечивая выполнение разработанного программного обеспечения для разработок Zynq на базе Linux.

Рис. 2. Соединение сред проверки аппаратного и программного обеспечения (Источник:Aldec)

Этот мост был создан с использованием SystemC Transaction Level Modeling (TLM) для определения каналов связи между QEMU и Riviera-PRO. Одновременная проверка SW и HW обеспечивается способностью моста передавать информацию в обоих направлениях.

В этой интегрированной среде моделирования команда инженеров может использовать стандартные и расширенные методологии отладки для решения любых проблем, которые могут возникнуть в процессе проверки. В случае Riviera-PRO это включает в себя такие возможности, как установка точек останова в HDL, изучение потока данных и даже анализ покрытия кода и путей, которые используются приложением SW, запущенным в QEMU. В случае QEMU команда SW может использовать Gnu DeBugger (GDB), чтобы настроить как ядро, так и драйвер для пошагового выполнения кода с использованием точек останова.

Преимущество такого подхода к совместному моделированию заключается не только в обеспечении большей наглядности и возможностей отладки в среде моделирования оборудования, но и в том, что он позволяет использовать то же ядро ​​Linux, разработанное для целевого оборудования, в QEMU. Опять же, это обеспечивает более раннюю проверку того, что ядро ​​правильно содержит все необходимые пакеты и элементы для поддержки разрабатываемого приложения.

Пример ШИМ

Чтобы продемонстрировать эту среду совместного моделирования, был создан простой пример. В этом примере IP-ядро помещается в PL и подключается к Zynq PS через универсальный интерфейс AXI. Когда доступ AXI к его регистровому пространству разрешен, ядро ​​IP будет генерировать выходной сигнал с широтно-импульсной модуляцией (PWM). Длительность сигнала ШИМ выбирается в диапазоне от 0 до 100% и снова определяется регистром в регистровом пространстве IP-ядра. Поэтому типичный вариант использования этого ядра требует, чтобы на Zynq PS работало программное обеспечение для включения и настройки IP-ядра. Простое изолированное моделирование IP-ядра не приведет к адекватной демонстрации желаемой работы ядра. Чтобы правильно проверить IP-ядро, нам необходимо иметь возможность включить и проверить ширину выходного импульса от PS при работе в операционной системе Linux.