Данная статья — это своего рода продолжение Верификация цифровых схем. Обзор.. В ней хотелось ��оказать некоторые типы тестовых окружений для функциональной верификации и особенности работы с ними.
Хотя у каждой компании/проекта есть свой маршрут функциональной верификации, возникший в определённых обстоятельствах — порождение опыта, ошибок и обстоятельств, — не всегда применяемые там решения являются предметом гордости.
И если вам случилась такая удача — разработать новое тестовое окружение или переработать существующее, — данный материал может подтолкнуть в сторону оптимального варианта в некоторых случаях. Может, и не подтолкнуть… или подтолкнуть не туда...
Хочу обратить внимание на слово функциональный: в данной статье я не буду затрагивать формальную верификацию и эмуляцию, т.к. эти темы довольно большие сами по себе.
Маршруты функциональной верификации
Маршрут функциональной верификации — это комплекс действий, направленных на всестороннюю проверку разрабатываемого устройства для выявления максимального количества функциональных ошибок и несоответствий спецификации, допущенных при проектировании.
Главный инструмент здесь — симулятор, в котором запускается тестовое окружение (ТО) с подключённым объектом верификации (ОВ).
Можно выделить следующие типы маршрутов:
Цифровой — когда объект верификации (ОВ) имеет только цифровые интерфейсы. Модель такого ОВ оперирует дискретными состояниями. Все содержащиеся в нём аналоговые подсистемы представлены замещающими моделями с цифровыми интерфейсами.
Цифро-аналоговый (смешанный) — когда ОВ имеет как цифровые, так и, возможно, аналоговые интерфейсы. Модель такого устройства — это комплекс из аналоговых и цифровых подсистем. Аналоговые подсистемы представлены замещающими моделями для работы в дискретном времени.
Аналоговый — когда ОВ имеет интерфейсы аналоговой природы или представляемые как аналоговые. Модель такого устройства оперирует непрерывным множеством состояний.
Про маршрут верификации аналоговых проектов могу сказать только коротко и жестами. В моём мире аналоговые блоки как овощи в супермаркете — помыты, отсортированы и упакованы. Картина в целом ясна, но сказать особо нечего.
Для первых двух типов ОВ тестовое окружение (ТО) по своей сути представляет собой программный комплекс. Очень грубо его можно назвать виртуальным испытательным стендом.
При его разработке помогут методы проектирования ПО.
Здесь бы я очень рекомендовал почитать «Совершенный код», хотя бы гл. 1 — Welcome to Software Construction [1, 2].
Далее, как пример, пункты из этой главы, которые, по моему мнению, применимы при создании верификационного окружения:
Problem definition (постановка задачи)
Requirements development (разработка требований)
Construction planning (планирование)
High-level design (проектирование архитектуры)
Detailed design (выработка требований на компоненты системы)
Coding and debugging (кодирование и отладка)
Типы объектов функциональной верификации
Для начала необходимо определиться, что именно мы собираемся проверять — тип ОВ. Подходы в верификации сильно зависят от этого и требуют различных навыков от инженеров.
Названия ниже — условные, предназначенные показать основную особенность. Инженер с хорошей фантазией и чувством юмора может придумать свои:
"Функции" - ОВ, представляющий собой реализацию математической функции, функции ЦОС, тракта обработки и т.п.
"Интерфейсы" - стандартный или проприетарный коммуникационный интерфейс. Как правило, это IP (СФБ) для использования в составе системы со стандартной системной шиной.
"Процессоры" - устройство исполняющее некотолрый набор инструкции, хранящихся в запоминающем устройстве. Это могут быть как ЦПУ, так и различные ускорители и т.п.
"Системы с программным управлением" - это вычислительная система, набор из IP (СФБ), объединённых системной шиной/шинами, управляемая одним или несколькими ЦПУ. Типовой пример — микроконтроллер, далее можно вспомнить различные SoC (СнК) для мобильных телефонов и т.п.
Особенности работы с ОВ типа "Функция"
Основной подход при верификации такого ОВ — это сравнение откликов ОВ
и "golden model" (GM)/референсной модели. Параллельно этому — анализ поведения ОВ в разных режимах его работы.
В большинстве случаев задача модели — генерация данных для контрольных точек.
Насколько поведение GM должно быть близко к реальному устройству, насколько она должна быть cycle-accurate и т.п. — определяется требованиями и задачами конкретного проекта.
GM обычно разрабатывается автором алгоритма. Язык стоит выбирать тот, с которым вашей команде удобно работать. Обычно — это C/C++, SystemC, Python и т.п. Можно и на языке ТО, но, как правило, он не самый оптимальный для написания и отладки подобных вещей и обычно используется тогда, когда инженер-верификатор сам занимается написанием модели.
Инженеру-верификатору также пригодятся знания языка, на котором написана модель. Если модель приходит к вам в готовом виде, её необходимо грамотно подключить и понимать её программный интерфейс (API). В случаях больших и сложных функций вам может потребоваться проверять ОВ частями; для этого надо выделить соответствующую часть в GM, разработать для неё обёртку и подключить в ТО.
Если ваше ТО написано на SystemVerilog, то ознакомьтесь с главами стандарта Direct Programming Interface и Programming Language Interface (PLI/VPI) overview. Что-то из этого вам точно потребуется, в зависимости от языка, на котором написана ваша GM. Для VHDL есть раздел VHDL Procedural Interface overview.
Не забудьте про базовую вещь — генератор входных данных для GM. Это может быть как отдельная утилита, так и функция в самом ТО. Вам необходимо согласовать с автором модели формат, в котором вы будете задавать конфигурацию, а также формат входных данных GM. Вы практически со 100-процентной вероятностью столкнётесь с тем, что вам и разработчику модели придётся повторять симуляцию и прогон модели для конкретных случаев.
Интерфейсы ОВ могут быть как стандартными, так и нестандартными. В последнем случае придётся разрабатывать UVC, в первом — можно взять готовые. При работе с готовыми UVC надо помнить о необходимости закладывать время на их освоение, интеграцию и настройку — и тем больше, чем сложнее интерфейс.
Для дополнительной остроты ощущений не забудьте про функциональное покрытие и возможность подать обратную связь от него в генератор воздействий. Целесообразно не всегда, но как только вы найдёте тот самый случай, вам понравится.
Для ОВ такого типа можно порекомендовать обратить внимание на CocoTB [3], если ваш маршрут и проект допускают это. Данная технология позволит проще работать с конфигурационными параметрами вашего ОВ, скорость отладки ТО может быть выше, чем при работе с парой SystemVerilog + UVM, и вы сможете использовать «свободные» САПР.
Типовое ТО:
Типовая последовательность теста:
Подготовка массива входных данных — на схеме это делает generator. Также массив данных может быть уже сгенерирован или предоставлен извне.
Подготовленный массив данных передаётся в GM, которая после вычислений передаёт в ТО массивы данных для "CPn".
Начинается основная программа тестирования ОВ. ОВ переводится в режим, определённый текущим тестом. Данные в контрольных точках сравниваются с данными, предоставленными GM.
Если в ходе тестирования все выборки во всех "CPn" совпали, то для выбранного режима тест считается пройденным.
Последовательность повторяется для всех запланированных массивов данных и режимов работы ОВ.
input data - входные данные
input UVC - UVC входного интерфейса.
output UVC - UVC выходного интерфейса.
GM - референсная модель.
CPn - контрольная точка - цепь внутри ОВ.
probe - монитор контрпольной точки, обеспечивает забор данных внутри ОВ, его преобразование в требуемый формат и предоставление данных для дальнейшей обработки
analyzer - анализатор, подсистема, где происходит сравнения результатов работы ОВ и GM, анализ поведения ОВ и формирование отчетов. Анализатор может быть распределенным, т.е. представлять собой множество отдельных, выполняющих свои специфические задачи.
generator - генератор входных данных. Его задача подготовить валидные входные данные. В некоторых случаях они согут состоять из сложных структур с множественными зависимостями.
test program - программа тестирования. Управляет компонентами ТО, определяет ход теста.
Особенности работы с ОВ типа «Интерфейс»
Такой ОВ обычно можно представить как функцию, у которой на стороне, обращённой к внешнему миру, находится интерфейс взаимодействия с физической средой, а со стороны системы — стандартный системный интерфейс типа AMBA, Wishbone, PCI-E и т.п.
Например: PCI-E или какой-нибудь радиоинтерфейс с цифровой модуляцией. В них, как правило, можно выделить следующие части: преобразователи среды, модуляторы/демодуляторы, протокольная часть и интерфейс системной шины.
Основной подход при работе с таким ОВ — проверка прохождения данных по коммуникационному тракту во всех возможных для интерфейса направлениях, конфигурациях и режимах. Сложные функции преобразования лучше тестировать отдельно, чтобы снизить сложность ТО и сократить время симуляции.
Для верификации некоторых интерфейсов с аналоговым каналом передачи данных требуется модель этого канала. Без неё такой ОВ качественно не проверить — невозможно корректно моделировать помехи, искажения и другие физические эффекты. Модель канала разрабатывается (или должна разрабатываться) авторами интерфейса, которые понимают физику процесса.
Со стороны системного интерфейса удобнее работать как программист системы, в которую встроен ОВ. В этом случае пишется ПО на C/C++, а входные воздействия в ТО подаются через DPI (в случае SystemVerilog). По этой теме рекомендуется посмотреть главу «Other Stimulus Techniques» в UVM Cookbook [4].
При правильной организации вы и команда ПО-инженеров сможете использовать единую кодовую базу, что значительно упростит жизнь всем участникам проекта. В плане генерации стимулов это продуктивнее, чем делать всё средствами одного только SystemVerilog.
Лучше потратьте время на создание хорошо организованного ТО на паре SystemVerilog+UVM, а формирование воздействий осуществляйте через C/C++.
Для системного интерфейса необходимо подобрать или разработать UVC. Качество проверки во многом будет зависеть от возможностей и гибкости выбранного UVC. Заложите достаточно времени на освоение стороннего UVC — оно может оказаться значительным (месяцы).
В большинстве случаев при проектировании и верификации таких ОВ остро встаёт проблема с регистрами.
Если регистров немного, то драматизм ситуации можно и не ощутить. Но когда их количество начинает превышать несколько десятков и стремится к сотням, синхронизация между командами разработчиков, программистов, верификаторов и т.п. легко превращается в хаос.
Для обуздания этой стихии разработчики САПР создали утилиты генерации представлений регистров. На выходе генератора можно получить: исходные файлы для дизайна на используемом языке, регистровую модель согласно UVM, а также *.h-файлы для C/C++ и т.п. Пользуйтесь этим, по возможности.
Типовое ТО
Типовая последовательность теста:
Если проверяется приём данных, запускается утилита media channel model, которая подготавливает массив выборок принимаемых данных для AFE (analog front end) на основе пакета, выбранного для отправки, и параметров среды передачи.
Дальнейшие шаги по настройке и конфигурации ОВ выполняются через ПО (SW).
В зависимости от направления передачи данных AFE подаёт или принимает выборки на входном интерфейсе.
Если проверяется передача данных, модель канала должна преобразовать выборки AFE обратно в пакет данных.
Если принятый пакет совпадает с переданным, тест считается пройденным.
media channel model - модель канала передачи данных от входа AFE передатчик до выхода AFE приемника.
afe i/f UVC - UVC цифровых интерфесов AFE.
system i/f UVC - UVC выходного системного интерфейса.
analyzer - анализатор - подсистема, где происходит сравнения результатов, анализ поведения ОВ и формирование отчетов. Анализатор может быть распределенным, т.е. представлять собой множество отдельных, выполняющих свои специфические задачи.
RAL - Registers Access Level. модель регистров.
DPI - интерфейс сопряжения ТО с программами и алгоритмами, написанными на языках программирования.
test program - алгоритмическая часть ТО, управляет всеми компонентами ТО, определяет ход процесса симуляции
transactions - пакеты данных и конфигурации канала передачи данных
SW - ПО. Алгоритм управления ОВ.
Особенности работы с ОВ типа «Процессор»
ОВ такого типа представляет собой потребителя инструкций и данных, хранящихся в памяти, продуктом работы которого является информация, которую он также помещает в память.
В общем случае верификация такого ОВ на верхнем иерархическом уровне — это, по сути, программирование. Навыки работы с C/C++ и Python здесь будут крайне полезны, так как для обеспечения максимального верификационного покрытия потребуется большое количество больших и маленьких программ дял проверки всевозможных ситуаций.
Для эффективной верификации необходима референсная модель процессора (GM), а также средства компиляции и отладки программ под него. Примеры таких референсных моделей можно найти в открытых проектах ЦПУ: LowRISC, Syntacore (SCR1), Gaisler (LEON), RISC-V и т.д.
Для облегчения своей участи выделите время на создание управляемого генератора потока инструкций в самом начале работ или найдите готовый. Он позволит формировать потоки команд по заданным параметрам или даже паттерны кода с необходимыми данными, что вам сильно поможет в дальнейшем.
Подсистемы, особенно в случае сложных процессоров, лучше проверять отдельно. Иначе велика вероятность лавинообразного усложнения ТО и невозможности достичь качественного верификационного покрытия.
В ТО используйте стандартные модели памяти, максимально приближённые к реальности. Это упрощает разработку и позволяет тестовому окружению корректно имитировать окружение ОВ. Подходящие модели памяти можно поискать, например, на Free Model Foundry [6].
Для ОВ такого типа, так же как и для ОВ типа «Функция», имеет смысл рассмотреть использование CocoTB [3], если ваш маршрут и проект допускают это.
Типовое ТО
Типовая последовательность теста:
Тестовая программа берёт готовый образ памяти из базы или вызывает генератор потока команд для формирования образа памяти с заданными параметрами.
Образ памяти подаётся на GM и загружается в памяти инструкций.
Тестовая программа инициализирует и запускает ОВ.
ОВ получает поток команд из памяти инструкций и исполняет их.
Производится сравнение контрольных точек с данными из GM и/или сравнение итогового результата работы в памяти.
CPU - объект верификации
im model - модель памяти инструкций.
dm model - модель памяти данных.
ctrl/st i/f UVC - UVC(ВСФБ) сигналов управления и статусов. Как правило этим управляются различными режимами работы "Процессора", прерываниями и т.п.
dbg i/f UVC - UVC(ВСФБ) интерфейса отладки.
analyzer - анализатор, производит оценку корректности работы ОВ.
CPn - контрольная точка - цепь внутри ОВ.
probe - монитор контрпольной точки, обеспечивает забор данных внутри ОВ, его преобразование в требуемый формат и предоставление данных для дальнейшей обработки.
generator - генератор потока команд.
GM - референсная модель ОВ. Как правило это поведенческа модель, написанная на высокоуровневом языке программирования.
test program - алгоритмическая часть ТО, управляет всеми компонентами ТО, определяет ход процесса симуляции.
SW - база образов памяти.
Особенности работы с ОВ типа "Система с программным управлением"
В идеальном случае ТО для такого ОВ должно состоять из готовых UVC, имитирующих различные варианты окружения будущей ИМС. Основной фокус верификации — проверка интеграции подсистем SoC (СнК), анализ их взаимодействия, производительности, энергопотребления как в целом, так и по отдельным блокам в различных режимах работы.
Для каждого внешнего интерфейса SoC необходим свой UVC — иначе трудно корректно оценить правильность его функционирования. Очень хорошо, если у вас уже есть готовые UVC. Если нет — не очень хорошо, готовьтесь потратить значительное время на их разработку. Как и в случае других типов ОВ, интеграция готовых сторонних UVC в ТО (особенно для сложных интерфейсов) занимает значительное время и может доходить до нескольких месяцев.
Также стоит заранее продумать систему подключения и конфигурации UVC либо общую схему реконфигурации ТО, чтобы оно поддерживало необходимые варианты портов ввода-вывода (GPIO). Лучше уделить пристальное внимание этой фазе работы, так как потом фокус сместится на разработку различного ПО и ошибки в ТО могут сильно замедлить процесс верификации.
Наиболее эффективные методы проверки такого ОВ — ко-симуляция или прототипирование на системах типа Veloce, Palladium или на подходящей FPGA (ПЛИС).
Если выбран путь ко-симуляции, обязательно ознакомьтесь с рекомендациями производителя ускорителя. Например, могут существовать требования к структуре UVC, их подключению к ОВ, либо необходимость разделения ТО на синтезируемую и несинтезируемую части, чтобы ОВ вместе с «пробниками» можно было отправить в ускоритель. Всё это напрямую влияет на архитектуру ТО.
Основой тестов для такого ОВ является ПО, покрывающее интересующие сценарии и режимы работы. Поэтому для эффективной верификации необходимы навыки программирования на языке, на котором пишется ПО для данной системы, либо тесное взаимодействие с командой разработчиков, которые смогут предоставить нужный код.
И напоследок: для корректного описания режимов энергосбережения имеет смысл изучить UPF [7], применяемый для описания power intent.
Типовое ТО:
Типовая последовательность теста:
Конфигурация и настройка всех компонентов ТО.
Загрузка или модификация образа памяти.
Активация системы.
Ожидание окончания работы ПО, загруженного в память, и сбор данных в контрольных точках для последующего анализа.
Динамический анализ ошибок, например корректности передачи данных через интерфейсы.
Анализ данных и формирование результата функционального тестирования (прошёл / не прошёл).
Формирование отчётов по производительности и энергопотреблению, если это предусмотрено тестом.
Приведение ОВ и необходимых компонентов ТО в исходное состояние (сброс).
Повтор с первого шага, если это предусмотрено сценарием теста.
SoC - ОВ
core - CPU
mem - памяти программ и данных
GPIO - универсальный порт вводы-вывода
X - коммутатор UVC на порты ввода-вывода SoC
IFn - интерфейс
IFn UVC - UVC интерфеса
CPn - контрольная точка - цепь внутри ОВ
probe - монитор контрпольной точки, обеспечивает забор данных внутри ОВ, его преобразование в требуемый формат и предоставление данных для дальнейшей обработки
analyzer - анализатор производительности
SW DB - база ПО, образы памяти программ
test program - алгоритмическая часть ТО, управляет всеми компонентами ТО, определяет ход процесса симуляции
Особенности маршрута верификации смешанных проектов
Если честно, то это отдельная тема, которую лучше излагать с примерами. Сейчас я хочу просто декларативно осветить основные моменты.
Маршрут верификации смешанных систем, коими являются практически все современные ИМС и многие интерфейсы, — это сплетение цифрового и аналогового маршрутов, столкновение двух миров.
Верификация обычно двухэтапная: сначала аналоговые и цифровые системы проектируются в соответствии со своими маршрутами, средства которых оптимальны для работы с тем или иным типом. Когда все системы готовы, проходит смешанное моделирование.
При смешанном моделировании цифровые и аналоговые системы, как правило, предстают в своих естественных формах. Например, аналоговые — в SPICE-моделях, а цифровые — в виде списка цепей (net-list) и файла задержек. Но для верификации в рамках цифрового или аналогового маршрутов проектирования необходимо иметь своего рода аватары или адаптеры для систем другого типа.
При этом для аналоговой системы проблема состоит в том, что ей необходимо объяснять языком Эллочки Людоедки всё разнообразие своего внутреннего мира. Это как русским матерным переписать «Евгения Онегина» — настроение понятно, а нюансы стираются. То есть каким-то способом необходимо объяснить цифровой системе поведение, доступным для неё языком, при этом говорить ей дают только в определённые моменты времени (цифровой мир дискретный). Вот довольно интересная статья — "Fast Validation of Mixed-Signal SoCs" [8].
Цифровая система при совместной работе с аналоговой должна уметь формировать и принимать сигналы, у которых больше чем несколько возможных состояний. Тут хочу отметить, что проблема больше относится к ТО, так как цифровой дизайн в любом случае общается с аналоговым посредством дискретных сигналов. Посмотрите для интереса этот материал — "Extending UVM To Analog" [9].
Для решения данных проблем верификации аналоговых систем вместе с цифровыми разработчики аналоговых IP (СФБ) создают замещающие функциональные модели, написанные на Verilog или Verilog-AMS (можно даже VHDL и VHDL-AMS). Если у кого есть доступ к такой команде, просто для интереса узнайте, как они эту модель получают. Откроете для себя много нового.
Если очень грубо, то делают они это, скорее всего, одним из следующих способов:
Модель создаётся отдельно от аналоговой схемы и верифицируется на соответствие с ней.
Модель создаётся сразу на языках типа Verilog-AMS, аналоговая схема получается из неё.
Модель получается из аналоговой схемы через конвертор.
Свой собственный Wunderweg.
Модель не создаётся. Дорогие «цифровики», крутитесь как хотите, встретимся на смешанном моделировании при прогоне системы в целом. :)
Лично я в основном работал с первым и последним вариантами.
Итак, как уже ранее сказано, когда все компоненты смешанной системы готовы, прошли функциональную верификацию или полностью смоделированы, завершена физическая имплементация, переходят к смешанному моделированию. На данном этапе аналоговые системы представлены схемой из SPICE-моделей, цифровые — списком цепей и описанием временных задержек.
Как правило, при смешанном моделировании производится запуск определённого набора тестов; особое внимание уделяется проверке правильности согласования подсистем по уровням напряжений, активным уровням сигналов и т. п. Делается так потому, что данный процесс очень затратный в плане временных и вычислительных ресурсов. Эта сборка представляет из себя наиболее полную, приближённую к реальности модель будущей системы.
Вот и всё, если кратко.
Список литературы
Steve McConnell Code Complete, 2nd edition. ISBN 0-7356-1967-0.
Макконнелл С. Совершенный код. Мастер-класс. ISBN 5-7502-0064-7. ISBN 5-469-00822-3
CocoTB, 2025-11
UVM Cookbook, 2025-11
IEEE Std 1800TM-2012. IEEE Standard for SystemVerilog - Unified Hardware Design, Specification, and Verification Language
Free Model Foundry, 2025-11
IEEE 1801-2024.IEEE Standard for Design and Verification of Low-Power Energy-Aware Electronic Systems
Fast Validation of Mixed-Signal SoCs. OJ-SSCS-21-0026.R1
Extending UVM To Analog, 2025-11
System-on-a-Chip Verification. 978-0-7923-7279-0, 978-0-306-46995-4.