Сегодня в некоторой русско-американской группе по QA (я не даю ссылку потому что она закрытая, хотя и многочисленная) некий молодой человек задал вопроc как войти в Quality Assurance Automation. Я сказал, что могу показать путь в Design Verification, который является фактически специализированным QA в области проверки функциональности цифровых аппаратных блоков, спроектированных с помощью синтеза из кода на языке описания аппаратуры SystemVerilog (я их собственно и проектирую). Так как получить ответ захотело еще человек десять, я понял, что нужно писать пост. К счастью, я об этом писал более 10 лет, так что можно делать выжимки из предыдущих постов.

Карьера Design Verification Engineer с писанием сред тестирования на SystemVerilog может понравится опытным программистам, которые хотят сменить карьеру с например писания программ на Джаве. В SystemVerilog есть элементы объектно-ориентированного и симулированно-многопоточного программирования. Суть деятельности заключается в создание фреймворков, которые тестируют хардверные дизайны на прочность, бомбардируя их превдослучайными транзакциями и учитывая покрытие интересных сценариев (functional coverage).

ASIC (application-specific integrated circuit, «интегральная схема специального назначения») — интегральная схема, специализированная для решения конкретной задачи.

Сейчас я интервьирую кандидатов которые приходят на позиции в RTL design / проектировщики микросхем на уровне регистровых передач. Но 5 лет назад я интервьировал студентов и других инженеров на позиции в DV / Design Verification / верификаторы блоков микросхем.

Моим стандартным вопросом было написать маркером на доске псевдокод для упрощенного драйвера модели шины (Bus Functional Model - BFM) для протокола AXI. На этом вопросе у ~80% кандидатов наступала агония - они как ужи на сковородке пытались натянуть сову на глобус - приспособить решение для последовательной шины а-ля APB, которое они прочитали в каком-нибудь тьюториале - к шине AXI, которая во-первых конвейерная, а во-вторых, допускает внеочередные ответы на запросы чтения с разными идентификаторами.

Аналогия из другой области: представьте, что кто-то пытается обходить дерево или решить "ханойские башни" - не зная концепций рекурсии и стека. Или написать GUI интерфейс, не зная концепции cобытийно-ориентированной архитектуры.

Если предыдущая статья про гибридное прототипирование https://habr.com/ru/company/baikalelectron/blog/582782/ описывала новаторское использование платформы HAPS, то сегодня мы расскажем в общем - что такое прототип, и какие традиционные подходы к  прототипированию используют инженеры Baikal Electronics.

В маршруте проектирование сложных System-on-the-Crystal (SoC) прототипирование на FPGA занимает промежуточное место между моделирование на симуляторах (VCS, ModelSim и др.) и эмуляцией.

 FPGA-прототипирование позволяет реализовать такие сложные сценарии системной валидации микросхемы как загрузка операционной системы (ОС). На прототипе операционная система может загрузиться за несколько часов, на симуляторе ОС грузилась бы в течении месяцев. При этом на FPGA с помощью встроенного логического анализатора мы можем увидеть поведение любого сигнала нашего дизайна в любой момент времени. А также, в отличие от кремния, можем переконфигурировать наш прототип произвольное количество раз.

Традиционно, говоря о косимулиции, имеют в виду моделирование  систем, разные части которых представлены на разном уровне абстракции или написаны на разных языках. Например, 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.