Проектирование цифровых систем на языках описания аппаратуры/Лекция 10
- Заголовок
- Верификация VHDL описаний цифровых систем
- Автор
- Ланкевич Ю.Ю.
- Нижний колонтитул
- Проектирование цифровых систем на языках описания аппаратуры/Лекция 10
- Дополнительный нижний колонтитул
- Ланкевич Ю.Ю., 00:29, 19 октября 2020
Слайд:Актуальные проблемы верификации
Объект верификации (ОВ) часто называют DUT (Design Under Test).
Актуальные проблемы верификации:
- размер объекта верификации постоянно растет. Большие ИМС — это комплексы, в которых может насчитываться до десятков миллиардов транзисторов, схема управления электропитанием по сложности может превосходить некоторые процессоры;
- высокая цена ошибки (от десятков тысяч долларов до десятков миллионов долларов);
- невозможно составить спецификацию на ИМС в начале проекта и в дальнейшем только следовать ей, она постоянно изменяется на протяжении всего процесса разработки (заказчик изменяет требования, технические проблемы или обнаружение более оптимальных решений вынуждают пересматривать подходы и т.д.). Исходя из этого, все процессы должны в динамике воспринимать изменения спецификации и модифицироваться в соответствии с требованиями;
- количества отдельных тестов и их типов достигает огромного числа, результаты их надо собирать и анализировать;
- моделирование цифровых систем требует много машинного времени и вычислительных ресурсов;
- полнота установленных для проекта целевых показатели готовности во многом зависит от компетентности и интуиции специалистов по верификации;
- несмотря на существование показателей охвата проекта тестами (метрик), единственный способ закончить верификацию — это принять решение о ее приостановке, основываясь в основном на следующих заключениях: деньги или время на этап проекта потрачены, необходимо запускать в производство, вроде как достигли покрытия кода в 100%, тестируем уже неделю и ошибок не обнаружили и т.п.
Слайд:Типы верификации
- Функциональная верификация (Functional Verification) – проверка всех функциональных параметров и характеристик СБИС на логическом уровне. Если моделирование не дает корректных результатов, то этап логического проектирования (исправление ошибок проектирования) повторяется до достижения успеха. Функциональная верификация в объеме всех работ наиболее значительна и требует непосредственного участия человека.
- Формальная верификация (Formal Verification) - устанавливается эквивалентность представлений системы на разных стадиях маршрута проектирования или выполнение утверждений, помещенных в исходный код; инструменты формальной верификации часто тоже весьма самостоятельны, требует только внимательного анализа отчетов, которые они генерируют.
- Cтатический анализ кода (static code analysis) — проверка исходного кода по формальным критериям на соблюдения правил использования языка и его конструкций. Программы для такой проверки обычно обозначаются как lint или linter; требуют только первоначальной настройки инструментов, которая соответствует внутренним правилам проектирования, принятым в компании, дальше данный инструмент можно использовать без дополнительных трудозатрат.
- Прототипирование — использование FPGA для функциональной проверки.
- Физическая верификация — в основном подразумевается DRC, LVS, PERC и пр. проверки, физическое представление системы проверяется на соблюдение технологических норм и соответствия физического и логического представлений и т.д. Состав проверок сильно зависит от технологии. Обычно физическая верификация проводится инженером или командой топологического проектирования
Слайд:Методы функциональной верификации
Directed Tests Method (DTM)
Прямые, осмысленные тесты. План верификации составляется из тестов направленных на проверку поведения устройства в конкретных интересующих точках (состояниях). Проверить все возможные ситуации, особенно в сложных проектах, почти не возможно.
При этом проблемы, которые могут возникнуть в ситуациях не покрытых тестами не обнаруживаются до того, как устройство начинают использовать в реальных условиях. Обычно в этих тестах используются метрики функционального покрытия.
Coverage-Driven Verification, Metric-Driven Verification (CDV, MDV)
Концепция создания тестов, направленная на достижение определенного «тестового покрытия» DUT. Опираются на метрики, чтобы понять какие тесты необходимо добавить в план верификации, чтобы достигнуть целевых показателей готовности проекта.
Необходимо использовать инструменты анализа покрытия, чтобы посмотреть, что еще добавить в план верификации. По-сути, если начать корректировать план верификации в DTM, опираясь хотя бы на “покрытие кода”, то уже можно считать, что от DTM плавно перешли к CDV.
Constrained Random Verification (CRV)
Верификация подачей случайных воздействий. Это действительно автоматические тесты с генерацией случайных воздействий на DUT.
Метод очень затратный вначале, т.к. требуется длительное время на подготовку инструментов. После того как начальный этап подготовки пройден, то тестирование может запускаться автоматически, многократно с разными исходными данными. При выявлении несоответствия проверок или утверждений (checkers or assertions), команда разработчиков и верификаторов приступает к анализу выявленной ошибки.
Этим методом можно собрать покрытие кода и покрытие утверждений, а они могут ничего не говорить о правильности работы DUT, т.е. соответствии спецификации. Его необходимо дополнять функциональными тестами.
Для реализации данной методологии требуется:
- внедрить “утверждения”(assertion) или специальные проверки (checkers) во всех важных точках исходного кода DUT и тестового окружения;
- разработать генераторы случайных воздействий и сценарии их работы, т.е. воздействия случайны, но имеют ограничения диапазона (все перебрать не успеем), порядок подачи и т.п..
Assertion Based Verification (ABV)
Верификация с помощью утверждений. Наверное, это даже не самостоятельный метод, а некоторый компонент или базовая составляющая вышеупомянутых.
Важным вопросом при ABV является как распределить assertions, какие из них лучше поместить в исходные код DUT, какие нужно иметь в тестовом окружении.
Слайд:Типы метрик функциональной верификации
Метрики — это показатели охвата проекта тестами. Они нужны для того, чтобы понять какие еще тесты необходимо разработать для проверки возможных ситуаций и сколько предположительно времени может занять верификация. К сожалению, только один тип метрик оценивается на основании исходного кода проекта, определение критериев для остальных типов — это результат интеллектуального труда. К тому же, необходимо помнить, что достижение желаемых показателей одним типом метрик никак не говорит о работоспособности в целом, всегда необходимо оценивать комплекс.
Типы метрик:
- функциональное покрытие. Показывает на сколько полно проверены функции устройства. Критерии данного покрытия могут определяться планом тестирования и внедрением специальных конструкций (covergroup) в тестовое окружение и/или в объект верификации, отслеживающих выполнялась или нет та или иная функция/действие, изменялись ли определенным образом данные и т.п. Информация от конструкций, внедренных в исходный код, может быть автоматически собрана средствами САПР.
- покрытие кода — изменение состояния конструкций исходного кода в ходе тестов. Собирается автоматически средствами САПР, не требует внесения каких-либо конструкций в исходный код. Например:
- переключение регистров/сигналов (Toggle Coverage);
- активность каждой строки кода (Line Coverage);
- активность выражений (Statement Coverage), по сути — это Line Coverage, но может отслеживать выражения которые больше, чем одна строка в редакторе;
- активность участка кода внутри условного оператора или процедуры (Block Coverage), разновидность Statement Coverage;
- активность всех веток условных операторов таких как if, case, while, repeat, forever, for, loop (Branch Coverage);
- изменение всех состояний(true, false) составляющих логических выражений (Expression Coverage);
- состояния конечного автомата (Finite-State Machine (FSM) Coverage).
- покрытие утверждений (assertions). Утверждения — это специальные языковые конструкции, которые отслеживают различные события и последовательности, и по заданным критериям определяют правомерность их возникновения.
Слайд:Режим покрытия VHDL-кода в ModleSim
В системе ModelSim при моделировании можно задать следующие опции покрытия кода.
- Enable Statement coverage – покрытие операторов.
- Enable Branch coverage – подсчитывается число выполнений условий типа «if/then/else» и «case».
- Enable Condition coverage – анализируется выборы, сделанные в условиях "if" и "case"; данная опция является расширением Branch coverage.
- Enable Expression coverage – покрытие выражений в правой части оператора назначения сигнала.
- Enable 0/1 Toggle coverage – покрытие переходов логического сигнала из одного состояния в другое; учитываются только переходы из 0 в 1 и обратно.
- Enable State Machine coverage – в VHDL-коде выделяется описание конечного автомата, подсчитываются покрытые переходы между внутренними состояниями, в которые попадает автомат.
Слайд:Режим покрытия кода в ModelSim
 |
Установка опций компиляции для покрытия кода: по правой клавиши мыши открыть окно Compile Properties и установить флаги для выбранных видов покрытия |
|---|
Слайд:Установка опций покрытия кода перед моделированием и выполнение моделирования в ModleSim
В закладке Simulation выбираем раздел Start Simulation, затем в закладке Others устанавливаем флаг Enable Code Coverage - выполнять при моделировании покрытие кода.
