Традиционно, говоря о косимулиции, имеют в виду моделирование  систем, разные части которых представлены на разном уровне абстракции или написаны на разных языках. Например, SystemC-модели + RTL код, TLM-модели + RTL. При этом моделирование RTL-части может быть исполнено на симуляторе или в реальном времени на FPGA-прототипе. В последнем случае подразумевается существование некоторого интерфейса для транзакций между FPGA-платформой и хост-машиной, моделирующей остальную часть.

В «Байкал Электроникс»  для FPGA-прототипирования используют платформы Synopsys HAPS®-80, позволяющие в процессе разработки микросхемы реализовать такие сложные сценарии, как загрузка ОС, что было бы невозможно выполнить RTL-моделированием в приемлемые сроки.

Но FPGA-прототипирование не может заменить RTL-моделирование в процессе полноценной верификации отдельных подсистем, так как на FPGA невозможно во всех нюансах воспроизвести поведение таких элементов будущей микросхемы, как, например,  PHY-контроллеров интерфейсов. Также проблематично  реализовать на FPGA работу количества частотных доменов, характерного для современных систем на кристалле.

Итак, в ряде случаев полноценное RTL-моделирование незаменимо, но как быть с огромными рантаймами? Например, моделирование программного кода трейнинга DDR4 может занимать 2 недели. Перед инженерами «Байкала» встал вопрос: а нельзя ли в этом верификационном окружении выделить ту часть, которая может быть полноценно синтезирована на FPGA-платформе, и осуществить косимуляцию несинтезабельной части на симуляторе  с исполнением в real-time на FPGA синтезабельной части? Ведь очевидно, что львиная доля времени симуляции уходит на воспроизведение switching activity высокопараллельных структур, отлично портируемых на FPGA.

      Критерии, которым должен удовлетворять маршрут гибридной косимулиции RTL + FPGA (если целью ставится ускорение процесса разработки), формулируются весьма очевидно:

- косимуляция должна демонстрировать значительное превосходство над чистой RTL-симуляцией по времени исполнения;

- исходное верификационное окружение должно подвергаться минимальной и четко формализованной доработке, иначе выигрыш во времени моделирования «съедается» временем донастройки окружения. То же касается и доработки части FPGA-прототипа.

      Исходной точкой для разработки инженерами «Байкала» нового маршрута косимуляции послужила имеющаяся у фирмы Synopsys инфраструктура связи платформы HAPS-80  c хост-машиной – проприетарная шина Synopsys UMR-Bus®, связывающая платформу с хостом посредством PCIe-кабеля. Synopsys поставляет в виде дополнительных IP-блоков  набор транзакторов, позволяющих связать HAPS-80 с виртуальной платформой, при этом на виртуальной части такого гибридного прототипирования моделируемое устройство представлено в виде TLM или SystemC-модели. Нам же, по нашей идее, необходимо было сопрячь HAPS c RTL-симулятором, конкретно – c Synopsys VCS® simulator.

      Такого рода переходники прямо «из коробки» у  Synopsys отсутствовали, однако нам было очевидно, что инфраструктура UMR Bus имеет все для этого необходимое. Тогда «Байкал» связался с группой разработчиков Synopsys из Эрфурта,  которой были изобретены концепция гибридного прототипироания и собственно шина UMR Bus. Наши надежды оправдались: коллеги любезно предоставили нам скрипты, позволяющие посредством вызова DPI-функций перенаправлять потоки данных из симулятора VCS в шину UMR Bus. Другую часть шины UMR Bus, заходящую в платформу HAPS,  байкаловцы разобрали на атомы сами, благо коллеги из Эрфурта хорошо документировали основу инфрастукруты UMR Bus – так называемые модули CAPIM.

       Казалось бы, теперь у нас есть транспорт для разработки собственного переходника между HAPS и VCS, осталось поделить моделируемую подсистему на  несинтезабельную VCS-часть и FPGA-синтезабельную, затем лишь запустить тестбенч на VCS -стороне. Но как синхронизовать два мира – RTL-симуляцию и FPGA, если в FPGA процессы моделируются в тысячи раз быстрее? Необходимо городить сложный программно-аппаратный интерфейс , выравнивающий потоки данных и буферизирующий сигналы переходника VCS-HAPS. А мы, напомним, отнюдь не собирались из академического интереса изобрести причудливый стенд косимуляции, а хотели ускорить вполне конкретные бизнес-процессы с довольно ограниченными ресурсами. Поэтому критерий минимальности усилий по доработке существующего верификационного окружения являлся ключевым.

       Идея, благодаря которой «Байкал» вышел из этого затруднения, не была, как потом выяснили, новаторской. Похожие принципы использовались в интерфейсе коэмулиции SCE-MI, видимо они лежали на поверхности. Но мы изобрели этот велосипед применительно к нашим условиям, и даный подход в использовании конкретных инструментов от Synopsys – тулов, IP и аппаратной платформы прототипирования – стал безусловным новаторством.

       Решение состоит в том, чтобы по восходящму фронту каждой системной частоты останавливать симцуляцию, далее посредством вызова DPI-функций  отправить на FPGA-сторону все сигналы «жгута», соединяющего VCS- и HAPS-части  моделиремого дизайна. После установки переданных управляющих воздействий на тактируемые элементы HAPS-части производится один пульс системной частоты, далее изменившиеся после пульса клока сигналы отправляются обратно в «жгут» на VSC-сторону и моделиролвание продолжается. Фактически именно VSC-симуляция является «бутылочным горлышком» производительности всей  гибридной косимуляции, а обмен данными между VSC- и HAPS-сторонами  за один такт по «жгуту» происходит быстрее, чем моделирование одного такта VCS-части. Именно VCS-тестбенч занимается частотообразованием для HAPS-стороны, прозводя для HAPS пульсы клока большой скважности, между которыми моделирование схемы на HAPS «замораживатся» до переключения нового фронта клока на  VCS. Этим достигается абсолютная синхронность косимуляции с точностью до периода клока.

       На Рисунке 1 показаны потоки данных и сопоставлены временные диаграммы VCS-моделирования и FPGA-прототипирования. Красным конусом выделен разворот времени, протекающего в FPGA между моментами остановки VCS-моделирования. UMR Bus-интерфейс позволяет достичь скорости обмена между аппаратной и симуляционной частями в 400 Мбайт. Частота UMR Сlock на рисунке – 100 МГц, а у  шины UMR Bus 32 разряда, поэтому требуются сериализация входных данных (интерфейсный блок CAPIM1) и десериализация выходных (CAPIM3) данных нашего «жгута», который обычно состоит из нескольких тысяч сигналов. На Рисунке 1 представлен пример «времянки» для небольшого «жгута» из 128 входных и 128 выходных сигналов.

На Рисунке 2 предствален пример программно-аппаратного брижда, разработанного «Байкалом» с использованием инфраструктуры шины UMR Bus. Очевидно, что чем больше сигналов в «жгуте» между аппаратным и симуляционным мирами, тем медленнее косимуляция и больше времени занимают сериализация и десериализация.

Теоретически точность разработанного метода гибридной косимуляиции может достигать гранулярности VCS симуляции – достаточно добавить соответсвующий сигнал в список чувствительности аппаратной части бриджа, и по нему будет происходить сэмплирование сигналов «жгута». Простейший пример  на Рисунке 1: в списке чувствительности клок одного частотного домена. Этот список можно расширить до двух доменов – см. Рисунок 3.

       В данном случае мы добавляем дополнительное условие остановки симуляции и сэмплирования сигнлов «жгута» – фронт еще одного клока. Понятно, что двухдоменный переход существенно затормозит косимулияцию по сравнению с однодоменным. Необходимым условием возможности эффективной многодоменной косимуляции является наличие опции автоматического gated clock conversion в программе синтеза проекта для HAPS от Synopsys – пакете Synopsys ProtoCompiler.

       Отдельной задачей в гибридной косимуляции является выделение тех частей  DUT (Device Under Test), которые пригодны для синтеза на FPGA и переноса их на в HAPS-проект. Они далеко не всегда находятся на одном уровне иерархии аппаратных модулей. Здесь нам на помощь приходит XMR (Cross Mudule Reference) – существующий в Verilog способ обращения к сигналам внутри модулей разной иерархии без необходимости «протягивать» их через порты модулей.

Поскольку XMR-синтаксис поддерживается обоими инструментами от Sysnopsys – VCS и Protocompiler, мы можем легко разделить DUT на VCS-  и HAPS-части без нужды модифицировать исходный RTL-код. На Рисунке 4 представлен пример применения XMR, когда заштрихованные части  DUT перенесены с помощью XMR из разных уровней VSC-проекта на один уровень HAPS-проекта без ручной модификации исходного RTL-кода и с сохранением абсолютной логической эквивалентности.

        Описанная технология была применена для прототипирования и ранней разработки ПО в проектах Baikal-M и Baikal-S, и ускорение по сравнению с RTL-симуляцией  в среднем составило 2,5 раза. Например, для моделирования одной итерации отладки ПО процедуры трейнинга DDR4 это 6 дней против 2 недель.

        На Рисунке 5 представлен предельный пример ускорения RTL-симуляции в проекте Baikal-M, когда весь DUT был FPGA-синтезабелен. Было взято поставочное окружение IP-интерконнекта от ARM, и весь DUT (т.е. без отделения синтезабельных частей) был отправлен в HAPS, где занял 2 чипа FPGA. На VCS-стороне транзактор CHI-интерфейса эмулировал запросы от кластера ARM Cortex-A57 в интерконнект на HAPS-стороне.

Наибольшее достигнутое ускорение RTL-симуляции составило 20 раз, отладочная итерация моделирования заняла полчаса вместо полусуток.

Описанная технология была представлена на конференции SNUG, регулярно проводимой фирмой Synopsys по всему миру, и получила высокие оценки коллег из области верификации и прототипирования.

Обычно для задач косимуляции используются такие аппаратные эмуляторы как, например, Synopsys ZeBu® Server. Эти платформы весьма дороги. Инженеры «Байкал Электроникс» использовали имеющиеся у них платформы HAPS-70/80 по нестандартному сценарию для решения данных задач, серьезно сократив свои расходы. Снова русские Левши блоху подковали.