Coverage Cookbook/Coverage Metrics and process (Theory)/Functional Coverage Metrics/ru
|
Эта статья требует перевода на русский язык |
- Метрики и процессы покрытия (en)
- Метрики покрытия кода (en)
- Метрики функционального покрытия (en)
- Specification to testplan (en)
- Testplan to functional coverage (en)
- Coverage Examples (Practice) (en)
- Requirements Writing Guidelines (en)
Содержание |
Метрики функционального покрытия
Целью функциональной верификации является определение, функционирует ли наш проект в соответствии с требованиями, определенными в спецификации. Но как вы узнаете, что вся указанная функциональность была реализована? Кроме того, как мы узнаем, что вся указанная функциональность была на самом деле протестирована? Метрики покрытия кода не помогут нам ответить на эти вопросы.
В этом разделе мы представляем явную метрику покрытия относящуюся к функциональному покрытию, которое может быть связано либо с спецификацией проекта, либо с областью покрытия. Цель измерения функционального покрытия - это измерить прогресс верификации в отношении функциональных требований к проекту. То есть, функциональное покрытие помогает нам ответить на вопрос: все ли указанные функциональные требования были реализованы, а затем осуществлены при моделировании? Подробнее о том, как создавать функциональную модель покрытия рассматривается отдельно в главе План теста для функционального покрытия.
Приемущества:
Происхождение функционального покрытия может быть прослежена с 1990-х годов с появлением настраиваемого псевдослучайного моделирования. Очевидно, одной из значимых возможностей настраиваемого псевдослучайного генератора входных воздействий является то, что среда моделирования позволяет автоматически генерировать тысячи тестов, которые обычно требовали бы значительного количества ручного труда как при создании прямых тестов (directed tests). Тем не менее, одной из проблем с настраиваемым псевдослучайным генератором входных воздействий является то, что вы никогда точно не знаете, какая функциональность была проверена, без утомительных усилий на рассмотрение временных диаграмм (effort of examining waveforms) после запуска моделирования. Таким образом, функциональное покрытие было изобретено, как измерение, помогающее определить, какая именно функциональность при регрессионном моделировании была протестирована без необходимости визуального контроля временных диаграмм.
Сегодня, выбор функционального покрытия не ограничен использованием настраиваемых псевдослучайных сред моделирования. На самом деле, функциональное покрытие обеспечивает автоматические средства для выполнения отслеживания требований (requirements tracing) в процессе моделирования, что часто является необходимым шагом, требуемым для проверки соблюдения стандарта DO-254. Например, функциональное покрытие может быть реализовано с помощью механизма, который связан с конкретными требованиями, определенными в спецификации. Затем, после моделирования, можно автоматически измерять, какие требования были проверены специально направленными или настраиваемыми псевдослучайными тестами, а также автоматически определять, какие требования не были проверены.
Ограничения:
Так как функциональное покрытие не является метрикой неявного покрытия, оно не может быть автоматически извлечено. Следовательно, это требует от пользователя вручную создать покрытие модели. С точки зрения высокого уровня, существуют два различных этапа в создании модели функционального покрытия, которые должны быть рассмотрены:
- Определить функциональность или цель проекта, которую вы хотите измерить
- Реализация механизма для измерения функциональности или цели проекта
Первый этап относится к планированию верификации и подробно рассматривается в разделе план теста функционального покрытия.
Второй этап включает в себя кодирование оборудования для каждого элемента покрытия, определенных на этапе планирования верификации (например, кодирование набора групп покрытия SystemVerilog для каждой цели верификации, определенных в план верификации). Во время реализации модели покрытия, есть также много деталей, которые необходимо учитывать, таких как: определение соответствующей точки для trigger измерения и определения управляемости (отключение / включение) для измерения. Эти и многие другие детали подробно рассматриваются в примерах покрытия.
Так как функциональное покрытие должно быть создано вручную, всегда есть риск, что какая-нибудь функциональность, указанная в спецификации, будет отсутствовать в модели покрытия.
Типы метрик функционального покрытия
Функциональное поведение любого проекта, которое наблюдается с какого-нибудь интерфейса в рамках среды верификации, состоит из данных и временных компонентов. Таким образом, с точки зрения высокого уровня, есть два основных вида измерений функционального покрытия, которые мы должны рассмотреть: Cover Groups и Cover Properties.
Моделирование группы покрытия (Cover Group)
Что касается функционального покрытия, сбор значений состояний в пределах модели проекта или по интерфейсу, вероятно, самый простой для понимания. Мы называем эту форму функционального покрытия, как моделирование группы покрытия. Оно состоит из значений состояний наблюдаемых на шинах, группирующейся из сигналов интерфейса управления, а также регистра. Дело в том, что значения, которые измеряются происходят в одной явной или неявной точке в такт. Группы покрытия SystemVerilog являются частью механизма, который мы обычно используем для построения модели функционального покрытия, это подробнее рассмотрено в примерах блок схем и реализациях групп покрытия.
Моделирование покрытия свойств
Что касается функционального покрытия, временные отношения между последовательностями событий, вероятно, самое трудное, о чем можно рассуждать. Тем не менее, важно убедиться, что эти последовательности событий надлежащим образом протестированы. Мы используем моделирование покрытия свойств для измерения временных отношений между последовательностей событий. Наверное, самый популярный пример покрытия свойств включает в себя handshaking sequence между управляющими сигналами на шине протокола. Другие примеры включают power-state transition покрытие, связанное с проверкой low-power design. Утверждения и покрытие свойств являются частью механизма, который мы используем для создания временных моделей покрытия, и рассматриваются в примере монитора шины протокола.
Покрытие утверждений
Термин покрытия утверждений имеет сегодня много значений в промышленности. Например, некоторые люди определяют покрытие утверждений как отношение числа утверждений к строкам кода RTL. Тем не менее, плотность утверждений - это более точный термин, который часто используется для этой метрики. В нашем обсуждении, мы используем термин покрытия утверждений для описания реализации свойств покрытия, используя утверждения.
Разница между группами покрытия и свойствами покрытия
Чтобы проиллюстрировать разницу между покрытием моделируемым с группами покрытия и свойствами покрытия, давайте посмотрим на простом примере неконвеерной шины, как показано на рисунке 1.
A single write and read bus sequence для протокола нашей неконвеерной шины проиллюстрированы на рисунке 2.
Для верификации нашей шины важно, чтобы проверить граничные условия для адресной шины как для последовательности записи так и для последовательности чтения (то есть биты, в которых в addr содержатся все нули и все единицы). Кроме того, также важно, чтобы мы рассмотрели достаточное количество не граничных условий на адресной шине во время нашей регрессии. Мы заинтересованы только в сборе информации с адресной шины, когда выбран ведомый и строб включения активен (то есть sel==1'b1 && en==1'b1). Наконец, мы захотим отслеживать отдельные события записи и чтения для этих элементов покрытия, чтобы убедиться, что мы должным образом протестировали обе эти операции.
Это один из примеров использования групп покрытия для моделирования функционального покрытия (например, конструкция группы покрытия SystemVerilog). Кроме того, мы могли бы применить тот же подход покрытия данных для измерения чтения и записи шин данных.
Теперь, давайте посмотрим на свойства покрытия по отношению к этому примеру. Существует стандартная последовательность, которую сопровождают циклы записи и чтения. Например, давайте рассмотрим цикл записи. На первом такте, как только ведомый выбран (sel) и сигналы включения шины (en) de-asserted, наша шина находится в неактивном состоянии. Первый такт последовательности записи называется стартовое состояние шины, которое мастер инициирует, утверждая одной из линий выбора ведомого(sel==1'b1). Во время стартового состояния, мастер помещает действующие адрес и данные на шину. Передача данных (относится к активному состоянию шины) на самом деле происходит, когда мастер подает стробирующий сигнал включения шины (en). В нашем случае это определяется по переднему фронту третьего такта. Адреса, данные и сигналы управления остаются действительными на протяжении активного состояния.
Когда активное состояние завершается, стробирующий сигнал включения шины (en) de-asserted мастером шины, и таким образом завершается текущая операция записи. Если мастер закончит передачу всех данных ведомому (то есть, больше нет операций записи), то мастер de-asserts сигнал выбора ведомого (sel). В противном случае, сигнал выбора ведомого остается установленным и шина возвращается в стартовое состояние, чтобы начать новую операцию записи. Несколько back-to-back операций записи (без возвращения в неактивное состояние шины) известно как burst записи.
С точки зрения временного покрытия, набор утверждений может быть записан для обеспечения надлежащей последовательности состояний на шине. Например, только правильные переходы состояний шины показаны на рисунке 3. Кроме того, важно проверить единичные циклы чтения и записи, а также burst read in write operation. В самом деле, мы могли бы измерить различные burst циклов чтения и записи.
Комбинируя группы покрытия и свойства покрытия, мы можем достичь модели более высокой точности покрытия, которая более точно позволяет измерять ключевые особенности проекта.
Подробнее о том, как кодировать временное покрытие рассматривается в Примере APB3 монитора протокола шины.
Базовый маршрут функционального покрытия
Как правило базовый маршрут функционального покрытия очень похож на базовый маршрут покрытия кода. Цель сбора и анализа метрик функционального покрытия заключается в выявлении особенностей и требований из спецификации, которые не были выполнены в нынешней верификационной среде и test cases run on it. С точки зрения проекта, как правило, лучше подождать, пока реализация тестов связанных с покрытием будет близка к завершению, прежде чем всерьез начинать собирать и анализировать результаты функционального покрытия. В противном случае, вы можете потратить много попыток, чтобы правильно перемещать цель с меняющимся входным возействием. С учетом сказанного, мы рекомендуем Вам, по крайней мере, запустить несколько симуляций, которые захватывают метрики покрытия в начале цикла проекта (то есть, до начала серьезного сбора метрик покрытия), чтобы выработать любые потенциальные проблемы в вашем маршруте покрытия.
С точки зрения высокого уровня, маршрут функционального покрытия, как правило, включает четыре основных этапа:
- Создание функциональной модели покрытия
- Если используются утверждения, реализовать RTL модель для сбора покрытия
- Запуск моделирования для захвата и записи метрик покрытия
- Сообщение и анализ результатов покрытия
Часть анализа шага заключается в определении покрытия дыр, и определении, соответствует ли покрытие дыры одному из трех условий:
- Отсутствие входного воздействия, необходимого для активации непокрытой функциональности
- Ошибка в проекте (или в тестовой программе), которая не позволяет входному воздействию активировать непокрытое функциональность
- Неиспользуемая функциональность для некоторых конфигураций IP или expected unreachable functionality related during normal operating conditions
Первое условие требующее от Вас либо написать дополнительные заданные тесты, либо настроить случайные ограничения для создания необходимых входных воздействий, предназначенных для непокрытой функциональности. Второе условие, очевидно, требует инженера исправить ошибку, которая не позволяет выполняться непокрытой функциональности. Третье условие можно отнести к направлению инструмента покрытия для исключения неиспользуемую или недоступную функциональность при записи покрытия и шагах сообщения.
