Ко-симуляция для дизайнов Zynq SoC: ускорение верификации Hardware–Software

Гетерогенные System-on-Chip (SoC) устройства, такие как Xilinx Zynq-7000 и Zynq UltraScale+ MPSoC, соединяют высокопроизводительную processing system с передовой программируемой логикой. Эта интеграция позволяет дизайнерам строить системы, балансирующие CPU-драйвенный контроль с PL-based, низколатентными пайплайнами — идеальными для обработки изображений, промышленной автоматизации и обработки сигналов в реальном времени.

PS-to-PL соединение построено на наборе memory-mapped Advanced eXtensible Interface (AXI) ссылок, поддерживающих как мастер, так и слейв роли, обеспечивая надежную двунаправленную коммуникацию между софтом, запущенным на ARM ядрах, и кастомной логикой в FPGA ткани.

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

Когда PS обрабатывает конфигурацию или контроль, general-purpose AXI Master на процессоре пишет в регистры внутри PL IP ядер, направляя их поведение. Для данных-интенсивных задач — таких как стриминг видеокадров от PL в PS память — используются высокопроизводительные AXI интерфейсы, требующие более изощренного софта для настройки DMA передач и управления когерентностью буферов.

Верификация PS-PL взаимодействий известна своей сложностью. 2015 Embedded Markets Survey подсвечивала отладку как топовый дизайн-челлендж и подчеркивала необходимость лучших инструментов верификации. В то время как bus-функциональные модели могут предоставить первоначальный sanity check, они часто не имеют глубины, необходимой для валидации реальных софт-драйверов и приложений. Полные функциональные модели существуют, но могут быть запредельно дорогими.

Традиционная верификация разделяет поток: каждый блок валидируется изолированно, и только после прибытия первого железа PS и PL сшиваются вместе. Софт-команда обычно проверяет, что Linux-ядро несет необходимые драйверы и device-tree записи, запуская QEMU, open-source гипервизор, эмулирующий ARM архитектуру. И наоборот, логическая команда последовательно выполняет команды, имитирующие софт-инициированные транзакции для подтверждения PL функциональности.

Оба подхода упускают истинный PS-PL handshake, делая тонкие интеграционные баги трудными для обнаружения и дорогими для исправления позже в цикле. В то время как development board может предоставить stop-gap, отладка на реальном железе требует вставки инструментальной логики, регенерации битстрима и риска поведенческого дрейфа.

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

HW & SW Ко-симуляция

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

Рисунок 2. Мост между HW и SW верификационными средами (Источник: Aldec)

Мост использует SystemC Transaction-Level Modelling (TLM) для экспозиции AXI каналов между QEMU и Riviera-PRO, обеспечивая двунаправленный обмен данными. Инженеры могут затем применять передовые техники отладки, такие как HDL breakpoints, data-flow tracing и code-coverage анализ внутри Riviera-PRO, в то время как софт-сторона использует GDB для пошагового прохождения ядра и драйверов в QEMU.

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

PWM Пример

Для иллюстрации рабочего процесса рассмотрим PWM IP ядро, помещенное в PL и соединенное с PS через general-purpose AXI интерфейс. Софт конфигурирует регистр для установки duty cycle между 0% и 100%, затем триггерит ядро. Верификация ядра в изоляции упускает PS-инициированный контрольный путь; полная ко-симуляция гарантирует, что ширина импульса генерируется корректно, когда Linux-приложение запускается.