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-х годов с появлением настраиваемого псевдослучайного моделирования. Очевидно, одной из значимых возможностей настраиваемого псевдослучайного генератора входных воздействий является то, что среда моделирования позволяет автоматически генерировать тысячи тестов, которые обычно требовали бы значительного количества ручного труда to create as directed tests. Тем не менее, одной из проблем с настраиваемым псевдослучайным генератором входных воздействий является то, что вы никогда точно не знаете, какая функциональность была проверена без tedious effort of examining waveforms после запуска моделирования. Таким образом, функциональное покрытие было изобретено, как измерение, помогающее определить, какую именно функциональность регрессии моделирования можно тестировать без необходимости визуального контроля формы сигналов.
Сегодня, принятие функционального покрытия не ограничено для настраиваемых псевдослучайных сред моделирования. На самом деле, функциональное покрытие обеспечивает автоматические средства для выполнения requirements tracing в процессе моделирования, что часто является важным шагом, необходимым для выполнения проверки в DO-254. Например, функциональное покрытие может быть реализовано с помощью механизма, который связан с конкретными требованиями, определенными в спецификации. Затем, после моделирования, можно автоматически измерять, какие требования были проверены специально направленными или настраиваемыми псевдослучайными тестами, а также автоматически определять, какие требования не были проверены.
Ограничения:
Так как функциональное покрытие не является метрикой неявного покрытия, оно не может быть автоматически извлечено. Следовательно, это требует от пользователя вручную создать покрытие модели. С точки зрения высокого уровня, существуют два различных этапа в создании модели функционального покрытия, которые должны быть рассмотрены:
- Определить функциональность или цель проекта, которую вы хотите измерить
- Реализация механизма для измерения функциональности или цели проекта
Первый этап относится к планированию верификации и подробно рассматривается в разделе план теста функционального покрытия.
Второй этап включает в себя кодирование оборудования для каждого элемента покрытия, определенных на этапе планирования верификации (например, кодирование набора групп покрытия SystemVerilog для каждой цели верификации, определенных в план верификации). Во время реализации модели покрытия, есть также много деталей, которые необходимо учитывать, таких как: определение соответствующей точки для trigger измерения и определения управляемости (отключение / включение) для измерения. Эти и многие другие детали подробно рассматриваются в примерах покрытия.
Так как функциональное покрытие должно быть создано вручную, всегда есть риск, что какая-нибудь функциональность, указанная в спецификации, будет отсутствовать в модели покрытия.
Типы метрик функционального покрытия
Функциональное поведение любого проекта, которое наблюдается с какого-нибудь интерфейса в рамках среды верификации, состоит из данных и временных компонентов. Таким образом, с точки зрения высокого уровня, есть два основных вида измерений функционального покрытия, которые мы должны рассмотреть: Cover Groups и Cover Properties.
Моделирование Cover Group
Что касается функционального покрытия, сбор значений состояний в пределах модели проекта или по интерфейсу, вероятно, самый простой для понимания. Мы называем эту форму функционального покрытия, как cover group modeling. Она состоит из значения состояния наблюдаемого на шинах, группировка сигналов интерфейса управления, а также зарегистрироваться. Дело в том, что ценности, которые измеряются происходят в одном явно или неявно пробы момент времени. SystemVerilog covergroups являются частью механизма мы обычно используем для построения функциональной модели данных покрытия, детали обсуждаются в блок-схема примера уровне и обсуждение соответствующего примера реализации covergroup.
Cover Property Modeling
With respect to functional coverage, temporal relationships between sequences of events are probably the hardest to reason about. However, ensuring that these sequences of events are properly tested is important. We use cover property modeling to measure temporal relationships between sequences of events. Probably the most popular example of cover properties involves the handshaking sequence between control signals on a bus protocol. Other examples include power-state transition coverage associated with verifying a low-power design. Assertions and coverage properties are part of the machinery that we use to build temporal coverage models, and are addressed in the bus protocol monitor example.
Assertion Coverage
The term assertion coverage has many meanings in the industry today. For example, some people define assertion coverage as the ratio of number of assertions to RTL lines of code. However, assertion density is a more accurate term that is often used for this metric. For our discussion, we use the term assertion coverage to describe an implementation of of coverage properties using assertions.
Difference Between Cover Groups and Cover Properties
To help illustrate the difference between coverage modeled with covergroups and cover properties, lets look at a simple nonpipelined bus example, as illustrated in Figure 1.
A single write and read bus sequence for our non-pipelined bus protocol are illustrated in Figure 2.
To verify our bus example, it's important to test the boundary conditions for the address bus for both the write sequence and read sequence (that is, the bits within addr at some point contained all zeros and all ones). In addition, it's also important that we have covered a sufficient number of non-boundary conditions on the address bus during our regression. We are only interested in sampling the address bus when the slave is selected and the enable strobe is active (that is, sel==1'b1 && en==1'b1). Finally, we will want to keep track of separate write and read events for these coverage items to ensure that we have tested both these operations sufficiently.
This is one example of using cover groups to model functional coverage (e.g., the SystemVerilog covergroup construct). In addition, we could apply the same data coverage approach to measuring the read and write data busses.
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.
