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). Кроме того, мы могли бы применить тот же подход покрытия данных для измерения чтения и записи шин данных.
Now, let's look at cover properties with respect to this example. There is a standard sequence that is followed for both the write and read cycle. For example, let's examine a write cycle. At clock one, since both the slave select (sel) and bus enable (en) signals are de-asserted, our bus is in an INACTIVE state. The first clock of the write sequence is called the bus START state, which the master initiates by asserting one of the slave select line (sel==1'b1). During the START state, the master places a valid address and valid data on the bus. The data transfer (referred to as the bus ACTIVE state) actually occurs when the master asserts the bus enable strobe signal (en). In our case, it is detected on the rising edge of clock three. The address, data, and control signals all remain valid throughout the ACTIVE state.
When the ACTIVE state completes, the bus enable strobe signal (en) is de-asserted by the bus master, and thus completes the current single write operation. If the master has finished transferring all data to the slave (that is, there are no more write operations), then the master de-asserts the slave select signal (sel). Otherwise, the slave select signal remains asserted, and the bus returns to the bus START state to initiate a new write operation. Multiple back-to-back write operations (without returning to the bus INACTIVE state) are known as burst write.
From a temporal coverage perspective, a set of assertions could be written to ensure proper sequencing of states on the bus. For example, the only legal bus state transitions are illustrated in Figure 3. Furthermore, it's important to test a single write and read cycle, as well as the burst read in write operation. In fact, we might want to measure the various burst write and read cycles.
By combining cover groups and cover properties, we are able to achieve a higher fidelity coverage model that more accurately allows us to measure key features of the design.
Details on how to code temporal coverage are covered in the APB3 Bus protocol monitor example.
Typical Functional Coverage Flow
In many respects, the typical functional coverage flow is very similar to the typical code coverage flow. The objective of gathering and analyzing functional coverage metrics is to identify features and requirements from the specification that have not been exercised by the current verification environment and the test cases run on it. From a project perspective, it is generally best to wait until the implementation of the test cases associated with coverage are close to complete before seriously starting to gather and analyze functional coverage results. Otherwise, you can waste a lot of cycles trying to make sense of a moving target from the changing stimlus. With that said, we recommend that you at least run a few simulations that capture coverage metrics early in the project cycle (that is, prior to seriously gathering coverage metrics) to work out any potential issues in your coverage flow.
From a high-level perspective, there are generally four main steps involved in a functional coverage flow, which include:
- Create a functional coverage model
- If using assertions, instrument the RTL model to gather coverage
- Run simulation to capture and record coverage metrics
- Report and analyze the coverage results
Part of the analysis step is to identify coverage holes, and determine if the coverage hole is due to one of three conditions:
- Missing input stimulus required to activate the uncovered functionality
- A bug in the design (or testbench) that is preventing the input stimulus from activating the uncovered functionality
- Unused functionality for certain IP configuations or expected unreachable functionality related during normal operating conditions
The first condition requires you to either write additional directed tests or adjust random constraints to generate the required input stimulus that targets the uncovered functionality. The second condition obviously requires the engineer to fix the bug that is preventing the uncovered functionality from being exercised. The third condition can be addressed by directing the coverage tool to exclude the unused or unreachable functionality during the coverage recording and reporting steps.
