Coverage Cookbook/Метрики и процессы покрытия (Теория)/ru
Содержание |
Покрытие/Что такое покрытие
Как говорится, "Что нельзя измерить, не может быть сделано." И это, конечно, верно в случаях, когда мы пытаемся определить прогресс верификации проекта или пытаемся ответить на вопрос: "Все готово?" Будь ваша методика моделирования основана на методе направленного тестирования или на ограниченно случайной верификации, чтобы понять ход вашей верификации вам необходимо ответить на следующие вопросы:
- Были все конструктивные особенности и требования, определенные в плане теста, верифицированы?
- Были ли строки кода или структуры в проекте, которые никогда не использовались?
Покрытие - это измерения, которое мы используем в процессе моделирования, чтобы ответить на эти вопросы. Тем не менее, как только измерения покрытия стали неотъемлемой частью нашего процессе верификации, это дает возможности для более точных прогнозов работы проекта, а также предоставление средств для оптимизации нашего общего процесса верификации. На данном этапе мы можем задавать такие вопросы как:
- Когда мы тестировали функцию X, мы когда-нибудь проверяли функцию Y в то же самое время?
- Зависал ли наш прогресс верификации по неожиданным причинам?
- Существуют ли тесты, которые мы могли бы устранить, чтобы ускорить наш regression suite и все ещё достигать наших целей покрытия?
Таким образом, покрытие - это измерение в моделировании, которое мы используем для измерения прогресса верификации и завершенности.
Наблюдение и управление
Основой для обсуждения покрытия является понимание понятий управление и наблюдение. Неофициально, управление относится к возможности влиять или активировать встроенный конечный автомат, структуру, специальные строки кода или поведение в проекте, стимулируя различные порты ввода. Обратите внимание, что, в то время как в теории моделирования тестовая программа имеет высокую управляемость портов ввода модели проекта во время верификации, она может иметь очень низкую управляемость внутренней структуры в рамках этой модели. В отличие от управления, наблюдение относится к возможности наблюдать эффекты конкретного внутреннего состояния конечного автомата, структуры или стимулированной строки кода. Таким образом, тестовая программа, как правило, имеет ограниченную возможность наблюдения, если она наблюдает только за внешними портами модели проекта (потому что внутренние сигналы и структуры часто неявно скрыты от тестовой программы).
Чтобы определить ошибку в проекте, используя подход моделирования тестовой программы, следующие условия должны выполняться:
- Тестовая программа должна создавать надлежащие входящие сигналы для активации ошибки проектирования.
- Тестовая программа должна создавать надлежащие входящие сигналы для распространения всех последствий,
связанных с ошибкой проектирования в выходной порт.
- Тестовая программа должна содержать монитор, который может обнаружить ошибку проектирования, который был впервые активирован, затем распространен в точку обнаружения.
Вполне возможно создать условия, где входной сигнал активирует ошибку проектирования, которая не распространяется на наблюдаемые выходные порты. В этих случаях принимается первое условие приведенное выше; однако, второе условие отсутствует, как показано на рисунке 1.
В целом, покрытие - это измерение, которое мы используем для определения качества управления тестовой программы. Например, покрытие кода может непосредственно определить строки кода, которые не были активированы из-за плохой управляемости исходящей от входного сигнала моделирования. Кроме того, функциональное покрытие может определить ожидаемые поведения, которые никогда не были активированы во время моделирования из-за плохой управляемости.
Хотя наши обсуждения в этом разделе сосредоточены на покрытии, важно отметить, что мы можем обратиться к проблемам наблюдения путем внедрения assertions в модели проекта для обеспечения низкого уровня наблюдения и создания мониторов внутри и на выходных портах нашей тестовой программы для обеспечения высокого уровня наблюдения.
Резюме
Так что же такое покрытие? Проще говоря, покрытие - это измерение в моделировании, которое мы используем для измерения прогресса верификации и её завершенности. Измерение покрытия говорит нам, какая часть проекта была активирована во время моделирования (то есть, качества управления тестовой программы). Или, что еще более важно, измерение покрытия определяет части проекта, которые не были активированы в процессе моделирования, что позволяет нам корректировать наш входной сигнал для улучшения верификации.
There are different kinds of coverage metrics available to you, and the process of how to use them is discussed in the Coverage Cookbook examples.
Coverage/Kinds of coverage
No single metric is sufficient at completely characterizing the verification process. For example, we might achieve 100% code coverage during our simulation regressions. However, this would not mean that 100% of the functionality was verified. The reason for this is that code coverage does not measure the concurrent interaction of behavior within, or between multiple design blocks, nor does it measure the temporal sequences of functional events that occur within a design. Similarly, we might achieve 100% functional coverage, yet only achieve 90% code coverage. This might indicate that there is either a problem with the fidelity in our functional coverage model (that is, an important behavior of the design was missing from the coverage model), or possibly some functionality was implemented that was never initially specified (for example, perhaps the specification and testplan needs to be updated with some late stage change in the requirements). Hence, to get a complete picture of a project's verification progress we often need multiple metrics.
Coverage Classification
To begin our discussion on the kinds of coverage metrics, it is helpful to first identify various classifications of coverage. In general, there are multiple ways in which we might classify coverage, but the two most common ways are to classify them by either their method of creation (such as, explicit versus implicit), or by their origin of source (such as, specification versus implementation).
For instance, functional coverage is one example of an explicit coverage metric, which has been manually defined and then implemented by the engineer. In contrast, line coverage and expression coverage are two examples of an implicit coverage metric since its definition and implementation is automatically derived and extracted from the RTL representation.
Coverage Space Classification
Coverage associated with the two categories we just described can be combined to form a coverage space, which is often referred to as a coverage model. [1] For instance, an explicit specification coverage space consists of coverage metrics that are manually created by an engineer, derived from a design's requirements document or specification. Another kind of explicit coverage is the instrumentation created by an engineer that is based on the behavior encapsulated by the design implemention, such as the filling or emptying events associated with a particular FIFO in an RTL model.
Similarly, an implicit implementation coverage space consists of coverage metrics that are automatically extracted by a tool (such as a simulator), and derived from a design implementation (such as an RTL model). Another part of the implicit specification coverage space consists of coverage metrics that are automatically extracted by a tool, and are derived from the design specification. This part of the coverage space is currently an area of academic research, although there have been a few EDA tools recently emerge that attempt to automatically extract higher-level coverage properties by observing the effects of simulation patterns on an implementation (such as an RTL model). Note that these higher-level functional behaviors cannot be automatically extracted from the implementation alone, which is why they fall into the coverage metrics associated with the implicit specification coverage space.
Coverage Metrics
There are two primary forms of coverage metrics in production use in industry today and these are:
- Code Coverage Metrics (Code Coverage Metrics (Implicit coverage))
- Functional Coverage Metrics (Functional Coverage/Assertion Coverage Metrics (Explicit coverage))
References
[1] A. Piziali, Functional Verification Coverage Measurement and Analysis, Kluwer Academic Publishers, 2004.