Coverage Cookbook/Coverage Metrics and process (Theory)/Code Coverage Metrics/ru
|
Эта статья требует перевода на русский язык |
- Метрики и процессы покрытия (en)
- Метрики покрытия кода (en)
- Метрики функционального покрытия (en)
- Specification to testplan (en)
- Testplan to functional coverage (en)
- Coverage Examples (Practice) (en)
- Requirements Writing Guidelines (en)
В этом разделе мы рассмотрим различные измерения покрытия, связанные с design model's implicit implementation coverage space. В общем, эти измерения относят к покрытию кода или измерениям структурного покрытия.
Содержание |
Преимущества
Покрытие кода, чье происхождение может быть прослежено с 1960-х годов, является одним из первых методов изобретенных для систематического тестирования программного обеспечения. [1] Одним из преимуществ покрытия кода является то, что оно автоматически описывает степень, в которой исходный код программы был активирован во время тестирования, таким образом, выявление структуры в исходном коде, которые не были активированы во время тестирования. Одним из ключевых преимуществ покрытия кода, в отличие от функционального покрытия, является то, что создание структурной модели покрытия - это автоматический процесс. Таким образом, интеграция покрытия кода в существующий поток моделирования проста и не требует изменений вашего текущего проекта или способа верификации.
Ограничения:
В нашем разделе, называемом Что такое покрытие, мы обсудили три важных условия, которые должны произойти в процессе моделирования для успешного тестирования. Это были:
- Тестовая программа должна создавать надлежащие входящие сигналы для активации ошибки проектирования.
- Тестовая программа должна создавать надлежащие входящие сигналы для распространения всех последствий, связанных с ошибкой проектирования в выходной порт.
- Тестовая программа должна содержать монитор, который может обнаружить ошибку проектирования, который был впервые активирован, затем распространен в точку обнаружения.
Покрытие кода является измерением структур в исходном коде, которые были активированы в процессе моделирования. Одним из ограничений с метриками покрытия кода является то, что вы могли бы добиться 100% покрытия кода во время выполнения регрессии, означающее, что ваша тестовая программа обеспечивала сигналы, которые активировали все структуры в исходном коде вашего RTL, несмотря на то, что существовали ошибки в проекте. Например, входной сигнал мог активировать строку кода, которая содержала ошибку, но тестовая программа не генерировала необходимый дополнительный сигнал, который распространяет эффекты ошибки в некоторую точку тестовой программы, где это может быть обнаружено. На самом деле, исследователи изучили эту проблему и нашли случаи, когда тестовая программа достигала 90% покрытия кода, несмотря на то, что только 54% покрытого кода может наблюдаться во время моделирования. [2] Это означает, что ошибка могла существовать в строке кода, которая была помечены как covered?yet the bug was never detected due to insufficient input stimulus to propagate the bug to an observability point.
Другим ограничением покрытия кода является то, что оно не указывает, какая конкретно функциональность, определенная в спецификации, была протестирована. Например, вы можете столкнуться с ситуацией, когда вы достигли 100% покрытия кода и затем полагаете, что все готово. Тем не менее, может существовать функциональность, определенная в спецификации, которая не была протестирована или даже функциональность, которая никогда не были реализована! Метрики покрытия кода не помогут вам найти эти ситуации.
Даже с этими ограничениями, автоматический аспект покрытия кода является относительно простым способом определения недостатков входного сигнала в тестовой программе. И это отличный первый выбор для покрытия метрик, пока вы начинаете развивать ваши расширенные возможности процесса верификации.
Типы метрик покрытия кода
Покрытие переключений
Покрытие переключений это метрика покрытия кода, используемая для подсчета количества раз, сколько каждый бит регистра или wire изменил свое значение. Хотя это относительно простая метрика, многие проекты имеют такие требования тестирования, что все порты и регистры, как минимум, должно быть проверены на переходы ноль - единица и единица - ноль.
В целом, рассмотрение отчета анализа покрытия переключений может быть непреодолимым и иметь мало значения, если не отнестись к этому с должной тщательностью. Например, покрытие переключения часто используется для проверки основного соединения между IP-блоками. Кроме того, может быть полезно знать, что многие управляющие структуры, такие как one-hot select bus, были полностью выполнены.
Покрытие строк кода
Покрытие строк кода - это метрика покрытия кода, которую мы используем, чтобы определить, какие строки нашего кода были выполнены во время моделирования. Отчет метрики строкового покрытия будет иметь число, связанное с каждой строкой исходного кода, указывающее полное количество раз, когда строка выполнена. Значение количества строк выполнения не только полезно для выявления строк исходного кода, которые никогда не выполняются, но и также полезно, когда инженер считает, что требуется минимальный порог строк выполнения для достижения достаточного тестирования.
Анализ покрытия строк кода часто показывает, что редкое состояние, необходимое для активации строки кода, не произошло из-за отсутствия входного воздействия. Кроме того, анализ покрытия строк кода может показать, что данных и управления потоком исходного кода помешало ему либо из-за ошибки в коде, либо из-за мертвого кода, который в настоящее время не нужен в определенных IP конфигурациях. Для неиспользуемого или мертвого кода вы можете исключить или фильтровать этот код при записи покрытия и шагов отчетности, что позволяет сосредоточиться только на актуальном коде.
Покрытие операторов
Покрытие операторов - это метрика покрытие кода, которую мы используем, чтобы определить, какие операторы в нашем исходном коде были выполнены во время моделирования. В целом, большинство инженеров считают, что анализ покрытие операторов является более полезным, чем покрытие строк, так как оператор часто занимает несколько строк исходного кода или несколько операторов могут находиться в одной строке исходного кода.
Отчет метрик используемый для анализа покрытия операторов будет иметь число, связанное с каждой строкой исходного кода, указывающее общее количество раз, когда оператор выполнялся. Это значение выполнения операторов не только полезно для выявления строк исходного кода, которые никогда не выполнялись, но также полезны, когда инженер считает, что требуется минимальный порог оператора исполнения для достижения достаточной тестирования.
Block Coverage
Block coverage is a variant on the statement coverage metric which identifies whether a block of code has been executed or not. A block is defined as a set of statements between conditional statements or within a procedural definition, the key point being that if the block is reached, all the lines within the block will be executed. This metric is used to avoid unscrupulous engineers from achieving a higher statement coverage by simply adding more statements to their code.
Branch Coverage
Branch coverage (also referred to as decision coverage) is a code coverage metric that reports whether Boolean expressions tested in control structures (such as the if, case, while, repeat, forever, for and loop statements) evaluated to both true and false. The entire Boolean expression is considered one true-or-false predicate regardless of whether it contains logical-and or logical-or operators.
Expression Coverage
Expression coverage (sometimes referred to as condition coverage) is a code coverage metric used to determine if each condition evaluated both to true and false. A condition is an Boolean operand that does not contain logical operators. Hence, expression coverage measures the Boolean conditions independently of each other.
Focused Expression Coverage
Focused Expression Coverage (FEC), which is also referred to as Modified Condition/Decision Coverage (MC/DC), is a code coverage metric often used used by the DO-178B safety critical software certification standard, as well as the DO-254 formal airborne electronic hardware certification standard. This metric is stronger than condition and decision coverage. The formal definition of MC/DC as defined by DO-178B is:
Every point of entry and exit in the program has been invoked at least once, every condition in a decision has taken all possible outcomes at least once, every decision in the program has taken all possible outcomes at least once, and each condition in a decision has been shown to independently affect that decisions outcome. A condition is shown to independently affect a decisions outcome by varying just that condition while holding fixed all other possible conditions. [3]
It is worth noting that completely closing Focused Expressing Coverage can be non-trivial.
Finite-State Machine Coverage
Today's code coverage tools are able to identify finite state machines within the RTL source code. Hence, this makes it possible to automatically extract FSM code coverage metrics to measure conditions. For example, the number of times each state of the state machine was entered, the number of times the FSM transitioned from one state to each of its neighboring states, and even sequential arc coverage to identify state visitation transitions.
Typical Code Coverage Flow
The objective of gathering and analyzing code coverage metrics is to identify portions of the source code that have not been exercised by the current verification environment. From a project perspective, it is generally best to wait until the implementation of the RTL is close to complete before seriously starting to gather and analyze code coverage results. Otherwise, you can waste a lot of cycles trying to make sense of a moving target from the changing RTL code. 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 three main steps involved in a code coverage flow, which include:
- Instrument the RTL code 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 code
- A bug in the design (or testbench) that is preventing the input stimulus from activating the uncovered code
- Unused code for certain IP configuations or expected unreachable code related during normal operating conditions
The first condition requires you to either write additional directed stimulus or adjust random constraints to generate the required input stimulus that targets the uncovered code. The second condition obviously requires the engineer to fix the bug that is preventing the uncovered code from being exercised. The third condition can be addressed by directing the coverage tool to exclude the unused or unreachable code during the coverage recording and reporting steps. Formal tools can be used to automate the identification of unreachable code, and then automatically generate the exclusion files.
Ссылки
[1] J. Miller, C. Maloney, "Systematic mistake analysis of digital computer programs." Communications of the ACM 6 (2): 58-63, February 1963.
[2] F. Fallah, S. Devadas, K. Keutzer: "OCCOM: Efficient Computation of Observability-Based Code Coverage Metrics for Functional Verification." Proceedings of the Design Automation Conference, 1998: 152-157
[3] DO-178B, "Software Considerations in Airborne Systems and Equipment Certification", RCTA, December 1992, pp.31, 74.
[4] M. Stuart, D. Dempster: Verification Methodology Manual for Code Coverage in HDL Designs - TransEDA, August 2000
