Функциональная проверка

Функциональная проверка — это задача проверки того, что логическая конструкция соответствует спецификации. ^[1] Функциональная проверка пытается ответить на вопрос «Делает ли эта предлагаемая конструкция то, что задумано?» ^[2] Это сложная задача, которая занимает большую часть времени и усилий (до 70% времени проектирования и разработки) ^[1] в большинстве крупных проектов по проектированию электронных систем. Функциональная проверка является частью более всеобъемлющей проверки конструкции , которая, помимо функциональной проверки, учитывает нефункциональные аспекты, такие как синхронизация, компоновка и питание. ^[3]

Фон

Хотя количество транзисторов увеличивалось экспоненциально в соответствии с законом Мура , увеличение количества инженеров и времени, затрачиваемого на создание проектов, увеличивалось только линейно . По мере увеличения сложности транзисторов, количество ошибок кодирования также увеличивалось. Большинство ошибок в логическом кодировании возникали из-за небрежного кодирования (12,7%), недопонимания (11,4%) и проблем микроархитектуры (9,3%). ^[1] Таким образом, средства автоматизации электронного проектирования (EDA) создавались, чтобы догнать сложность проектирования транзисторов. Такие языки, как Verilog и VHDL, были введены вместе с инструментами EDA. ^[1]

Функциональная проверка очень сложна из-за огромного объема возможных тестовых случаев, которые существуют даже в простом проекте. Часто существует более 10^80 возможных тестов для всесторонней проверки проекта — число, которое невозможно достичь за всю жизнь. Эти усилия эквивалентны проверке программы и являются NP-трудными или даже хуже — и не было найдено решения, которое работало бы хорошо во всех случаях. Однако его можно атаковать многими методами. Ни один из них не идеален, но каждый может быть полезен в определенных обстоятельствах:

Логическое моделирование имитирует логику до ее построения.
Ускорение моделирования использует специализированное аппаратное обеспечение для решения задач логического моделирования.
Эмуляция создает версию системы с использованием программируемой логики. Это дорого и все еще намного медленнее, чем реальное оборудование, но на порядки быстрее, чем симуляция. Ее можно использовать, например, для загрузки операционной системы на процессоре.
Формальная верификация пытается математически доказать, что определенные требования (также выраженные формально) выполняются или что определенные нежелательные поведения (например, тупик) не могут возникнуть.
Интеллектуальная проверка использует автоматизацию для адаптации испытательного стенда к изменениям в коде уровня передачи регистра .
Для поиска распространенных проблем используются специфичные для HDL версии lint и другие эвристики.

Типы

Существует три типа функциональной верификации, а именно: динамическая функциональная, гибридная динамическая функциональная/статическая и статическая верификация. ^[1]

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

Среда моделирования обычно состоит из нескольких типов компонентов:

Генератор генерирует входные векторы, которые используются для поиска аномалий, существующих между намерением (спецификациями) и реализацией (кодом HDL). Этот тип генератора использует NP-полный тип SAT Solver, который может быть вычислительно дорогим. Другие типы генераторов включают вручную созданные векторы, генераторы на основе графов (GBM) и фирменные генераторы. Современные генераторы создают направленные случайные и случайные стимулы, которые статистически управляются для проверки случайных частей дизайна. Случайность важна для достижения высокого распределения по огромному пространству доступных входных стимулов. С этой целью пользователи этих генераторов намеренно недоопределяют требования для сгенерированных тестов. Роль генератора заключается в том, чтобы случайным образом заполнять этот пробел. Этот механизм позволяет генератору создавать входные данные, которые выявляют ошибки, которые пользователь не ищет напрямую. Генераторы также смещают стимулы в сторону угловых случаев дизайна, чтобы еще больше подчеркнуть логику. Смещение и случайность служат разным целям, и между ними существуют компромиссы, поэтому разные генераторы имеют разное сочетание этих характеристик. Поскольку входные данные для дизайна должны быть допустимыми (законными) и многие цели (например, смещение) должны поддерживаться, многие генераторы используют технику проблемы удовлетворения ограничений (CSP) для решения сложных требований тестирования. Законность входных данных дизайна и арсенал смещений моделируются. Генераторы на основе моделей используют эту модель для создания правильных стимулов для целевого дизайна.
Драйверы преобразуют стимулы , вырабатываемые генератором, в фактические входные данные для проверяемого проекта. Генераторы создают входные данные на высоком уровне абстракции, а именно, как транзакции или язык ассемблера. Драйверы преобразуют эти входные данные в фактические входные данные проекта, как определено в спецификации интерфейса проекта.
Симулятор выдает выходные данные проекта на основе текущего состояния проекта (состояния триггеров) и введенных входов. Симулятор имеет описание списка сетей проекта. Это описание создается путем синтеза HDL в список сетей низкого уровня вентилей.
Монитор преобразует состояние проекта и его выходные данные в уровень абстракции транзакций, чтобы их можно было сохранить в базе данных «таблиц» для последующей проверки.
Проверяющий проверяет, что содержимое «таблиц» является законным. Бывают случаи, когда генератор создает ожидаемые результаты в дополнение к входным данным. В этих случаях проверяющий должен проверить, что фактические результаты соответствуют ожидаемым.
Арбитражный управляющий управляет всеми вышеперечисленными компонентами одновременно.

Для оценки адекватности реализации дизайна определяются различные метрики покрытия . К ним относятся функциональное покрытие (каждая ли функциональность дизайна была реализована?), покрытие операторов (каждая ли строка HDL была реализована?) и покрытие ветвей (каждое направление каждой ветви было реализовано?).

Смотрите также

Ссылки

^ abcde Molina, A; Cadenas , O (8 сентября 2006 г.). "Функциональная верификация: подходы и проблемы". Latin American Applied Research . 37. ISSN 0327-0793. Архивировано из оригинала 16 октября 2022 г. Получено 12 октября 2022 г.
^ Резаеян, Банафшех. «Методология моделирования и проверки автомобильных ИС со смешанными сигналами». CiteSeerX 10.1.1.724.527 .
^ Страуд, Чарльз Э.; Чейндж, Яо-Чан (2009). "ГЛАВА 1 – Введение". Проверка дизайна . стр. 1–38. doi :10.1016/B978-0-12-374364-0.50008-4. ISBN 978-0-12-374364-0. Архивировано из оригинала 12 октября 2022 г. . Получено 11 октября 2022 г. . {{cite book}}: |journal=проигнорировано ( помощь )