Coverage Cookbook/Метрики и процессы покрытия (Теория)/ru — различия между версиями
(→Наблюдение и управление) |
м (переименовал Coverage Cookbook/Coverage Metrics and process (Theory)/ru в Coverage Cookbook/Метрики и процессы покрытия (Теория)/ru) |
||
| (не показаны 32 промежуточные версии 2 участников) | |||
| Строка 7: | Строка 7: | ||
когда мы пытаемся определить прогресс верификации проекта или пытаемся ответить на вопрос: | когда мы пытаемся определить прогресс верификации проекта или пытаемся ответить на вопрос: | ||
"Все готово?" Будь ваша методика моделирования основана на методе направленного тестирования | "Все готово?" Будь ваша методика моделирования основана на методе направленного тестирования | ||
| − | или на | + | или на настраиваемой псевдослучайной верификации, чтобы понять ход вашей верификации вам необходимо |
ответить на следующие вопросы: | ответить на следующие вопросы: | ||
| − | * | + | * Все ли конструктивные особенности и требования, определенные в плане теста, были верифицированы? |
| − | * | + | * Есть ли такие строки кода или структуры в проекте, которые никогда не были использованы? |
| − | Покрытие | + | Покрытие — это метрика, которое мы используем в процессе моделирования, чтобы ответить на эти |
| − | вопросы. Тем не менее, как только | + | вопросы. Тем не менее, как только метрики покрытия стали неотъемлемой частью нашего процесса верификации, |
это дает возможности для более точных прогнозов работы проекта, а также предоставление | это дает возможности для более точных прогнозов работы проекта, а также предоставление | ||
средств для оптимизации нашего общего процесса верификации. На данном этапе мы можем задавать такие вопросы как: | средств для оптимизации нашего общего процесса верификации. На данном этапе мы можем задавать такие вопросы как: | ||
| − | * Когда мы тестировали функцию'' X'', мы когда-нибудь проверяли функцию'' Y'' в то же самое время? | + | * Когда мы тестировали функцию ''X'', мы когда-нибудь проверяли функцию ''Y'' в то же самое время? |
* Зависал ли наш прогресс верификации по неожиданным причинам? | * Зависал ли наш прогресс верификации по неожиданным причинам? | ||
| − | * Существуют ли тесты, которые | + | * Существуют ли тесты, которые можно устранить, чтобы ускорить выполнение нашего набора регрессионных тестов и все ещё достигать наших целей покрытия? |
| + | |||
| + | Таким образом, покрытие — это метрика в моделировании, которое мы используем для измерения прогресса верификации и завершенности. | ||
| − | |||
| − | |||
<!-- == Coverage/What is coverage== | <!-- == Coverage/What is coverage== | ||
| Строка 39: | Строка 39: | ||
Hence, coverage is a simulation metric we use to measure verification progress and completeness. --> | Hence, coverage is a simulation metric we use to measure verification progress and completeness. --> | ||
| − | === | + | === Наблюдаемость и управляемость === |
| − | Основой для обсуждения покрытия является понимание понятий '' | + | Основой для обсуждения покрытия является понимание понятий ''управляемость'' и ''наблюдаемость''. Фактически, |
| − | + | управляемость относится к возможности влиять или активировать встроенный конечный автомат, структуру, специальные | |
| − | строки кода или поведение в проекте, стимулируя различные порты ввода. Обратите внимание, что | + | строки кода или поведение в проекте, стимулируя различные порты ввода. Обратите внимание, что в то время как |
в теории моделирования тестовая программа имеет высокую управляемость портов ввода модели проекта во время | в теории моделирования тестовая программа имеет высокую управляемость портов ввода модели проекта во время | ||
верификации, она может иметь очень низкую управляемость внутренней структуры в рамках этой модели. В отличие | верификации, она может иметь очень низкую управляемость внутренней структуры в рамках этой модели. В отличие | ||
| Строка 56: | Строка 56: | ||
Чтобы определить ошибку в проекте, используя подход моделирования тестовой программы, следующие условия должны выполняться: | Чтобы определить ошибку в проекте, используя подход моделирования тестовой программы, следующие условия должны выполняться: | ||
| − | # Тестовая программа должна создавать надлежащие | + | # Тестовая программа должна создавать надлежащие входные воздействия для активации ошибки в проекте. |
| − | # Тестовая программа должна создавать надлежащие | + | # Тестовая программа должна создавать надлежащие входные воздействия для распространения всех последствий (явлений), связанных с ошибкой в проекте, на выходной порт. |
| − | связанных с ошибкой | + | # Тестовая программа должна содержать монитор, который может обнаружить ошибку в проекте, которая была сначала активирована, затем распространена в точку, где может быть обнаружена. |
| − | # Тестовая программа должна содержать монитор, который может обнаружить ошибку | + | |
Вполне возможно создать условия, где входной сигнал активирует ошибку проектирования, которая не распространяется на наблюдаемые выходные порты. В этих случаях принимается первое условие приведенное выше; однако, второе условие отсутствует, как показано на рисунке 1. | Вполне возможно создать условия, где входной сигнал активирует ошибку проектирования, которая не распространяется на наблюдаемые выходные порты. В этих случаях принимается первое условие приведенное выше; однако, второе условие отсутствует, как показано на рисунке 1. | ||
| Строка 72: | Строка 71: | ||
[[Файл:300px-WiC-1.png|300px|frame|center|Рисунок 1. Плохое наблюдение и управление не попадает ошибки]] | [[Файл:300px-WiC-1.png|300px|frame|center|Рисунок 1. Плохое наблюдение и управление не попадает ошибки]] | ||
| − | В целом, покрытие | + | В целом, покрытие — это метрика, которое мы используем для определения качества управления тестовой программы. |
Например, покрытие кода может непосредственно определить строки кода, которые не были активированы из-за плохой управляемости исходящей от входного сигнала моделирования. Кроме того, функциональное покрытие может определить ожидаемые поведения, которые никогда не были активированы во время моделирования из-за плохой управляемости. | Например, покрытие кода может непосредственно определить строки кода, которые не были активированы из-за плохой управляемости исходящей от входного сигнала моделирования. Кроме того, функциональное покрытие может определить ожидаемые поведения, которые никогда не были активированы во время моделирования из-за плохой управляемости. | ||
| − | Хотя наши обсуждения в этом разделе сосредоточены на покрытии, важно отметить, что мы можем обратиться к проблемам наблюдения путем внедрения | + | Хотя наши обсуждения в этом разделе сосредоточены на покрытии, важно отметить, что мы можем обратиться к проблемам наблюдения путем внедрения утверждений в модели проекта для обеспечения низкого уровня наблюдения и создания мониторов внутри и на выходных портах нашей тестовой программы для обеспечения высокого уровня наблюдения. |
<!-- In general, coverage is a metric we use to meaure the controllability quality of a testbench. For example, code coverage can directly identify lines of code that were never activated due to poor controllability issues with the simulation input stimulus. Similarly, functional coverage can identify expected behaviors that were never activated during a simulation run due to poor controllability. | <!-- In general, coverage is a metric we use to meaure the controllability quality of a testbench. For example, code coverage can directly identify lines of code that were never activated due to poor controllability issues with the simulation input stimulus. Similarly, functional coverage can identify expected behaviors that were never activated during a simulation run due to poor controllability. | ||
Although our discussion in this section is focused on coverage, it's important to note that we can address observability concerns by embedding assertions in the design model to facilitate low-level observability, and creating monitors within and on the output ports of our testbench to facilitate high-level observability. --> | Although our discussion in this section is focused on coverage, it's important to note that we can address observability concerns by embedding assertions in the design model to facilitate low-level observability, and creating monitors within and on the output ports of our testbench to facilitate high-level observability. --> | ||
| − | === Summary === | + | === Резюме === |
| + | |||
| + | Так что же такое покрытие? Проще говоря, покрытие — это метрика, которую мы используем для измерения прогресса верификации и её завершенности. Метрики покрытия говорят нам, какая часть проекта была активирована во время моделирования (то есть, качества управления тестовой программы). Или, что еще более важно, метрики покрытия определяют части проекта, которые не были активированы в процессе моделирования, что позволяет нам корректировать наш входной сигнал для улучшения верификации. | ||
| + | |||
| + | Существуют различные [https://verificationacademy.com/cookbook/Coverage/Kinds_of_coverage виды метрик покрытий] доступные вам, и процесс, как их использовать описан в [https://verificationacademy.com/cookbook/Coverage/Testplan_to_functional_coverage#Functional_Coverage_Examples Coverage Cookbook examples]. | ||
| + | <!-- === Summary === | ||
So what is coverage? Simply put, coverage is a metric we use to measure verification progress and completeness. Coverage metrics tells us what portion of the design has been activated during simulation (that is, the controllability quality of a testbench). Or more importantly, coverage metrics identify portions of the design that were never activated during simulation, which allows us to adjust our input stimulus to improve verification. | So what is coverage? Simply put, coverage is a metric we use to measure verification progress and completeness. Coverage metrics tells us what portion of the design has been activated during simulation (that is, the controllability quality of a testbench). Or more importantly, coverage metrics identify portions of the design that were never activated during simulation, which allows us to adjust our input stimulus to improve verification. | ||
| − | There are different [https://verificationacademy.com/cookbook/Coverage/Kinds_of_coverage kinds of coverage | + | There are different [https://verificationacademy.com/cookbook/Coverage/Kinds_of_coverage kinds of coverage metrics] available to you, and the process of how to use them is discussed in the [https://verificationacademy.com/cookbook/Coverage/Testplan_to_functional_coverage#Functional_Coverage_Examples Coverage Cookbook examples]. --> |
| − | == Coverage/Kinds of coverage == | + | == Покрытие/Виды покрытия == |
| + | Нет единственной метрики, которой было бы достаточно при полной характеризации процесса верификации. | ||
| + | Например, мы могли бы добиться 100% покрытия кода во время регрессионного моделирования. Однако, это не означает, что 100% функциональности было верифицировано. Причиной этого является то, что покрытие | ||
| + | кода не измеряет одновременное взаимодействие поведения внутри или между несколькими блоками проекта, а | ||
| + | также не измеряет временной последовательности функциональных событий, которые происходят в проекте. Кроме того, | ||
| + | мы могли бы достичь 100% функционального покрытия, но только достигнув 90% покрытия кода. Это может означать, что | ||
| + | либо есть проблемы с точностью в нашей функциональной модели покрытия (то есть важное поведение в проекте | ||
| + | отсутствовало в модели покрытия), или, возможно, некоторая функциональность была реализована так, что там не | ||
| + | определены начальные значения (например, возможно, спецификация и план тестирования должны быть обновлены на некотором последующем шаге с изменением в требований). Таким образом, чтобы получить полное представление о ходе верификации проекта нам часто нужно несколько метрик. | ||
| + | <!-- == 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. | + | 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 ==== | + | ==== Классификация покрытий ==== |
| + | |||
| + | Перед началом рассмотрения видов метрик покрытия, полезно сперва определить различные классификации покрытий. | ||
| + | В общем, существует несколько способов классифицировать покрытие, но два самых распространенных способа | ||
| + | — это классифицировать их либо по '''методу создания''' (например, ''явные'' или ''неявные'') | ||
| + | или по '''происхождению источника''' (например, спецификация или реализация). | ||
| + | |||
| + | [[Файл:300px-Explicit_implicit_coverage.gif|300px|frame|center|Различные категории метрик покрытия]] | ||
| + | |||
| + | Например, функциональное покрытие является одним из примеров явной метрики покрытия, которая была определена вручную, а затем осуществляется инженером. В то же время, покрытие строк и покрытие выражений являются двумя примерами неявных метрик покрытия, так как их определение и реализация автоматически получены и извлечены из RTL описания. | ||
| + | <!-- ==== 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''). | 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''). | ||
| Строка 96: | Строка 119: | ||
[[Файл:300px-Explicit_implicit_coverage.gif|300px|frame|center|Different categories of coverage metrics]] | [[Файл:300px-Explicit_implicit_coverage.gif|300px|frame|center|Different categories of coverage metrics]] | ||
| − | 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. | + | 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. --> |
| + | |||
| + | ==== Классификация пространства покрытия ==== | ||
| + | |||
| + | Покрытие, связанное с двумя категориями, которые мы только что описали, может быть объединено, чтобы сформировать область покрытия, которое часто называют модель покрытие [1]. Например, точная область покрытия спецификации состоит из метрик покрытия, которые созданы вручную инженером, выделенные из требований проекта или спецификации. Другим видом точного покрытия является инструментарий, созданный инженером, который основан на скрытом поведении в реализации проекта, например, заполнение или опустошение стека, связанное с конкретным FIFO в RTL модели. | ||
| + | <!-- ==== 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. --> | ||
| − | + | Кроме того, пространство покрытия неявной реализации состоит из метрик покрытия, которые автоматически извлекаются с помощью инструментов (таких как симулятор), и полученные от реализации проекта (например, RTL модели). Другая часть пространство покрытия неявной спецификации состоит из метрик покрытия, которые автоматически извлекаются с помощью инструмента, и полученные из спецификации проекта. Эта часть пространства покрытия в настоящее время область научных исследований, {{Жел|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}}. Отметим, что поведения более высокого уровня функционального не могут автоматически извлекаться из реализации в одиночку, поэтому они попадают в метриках покрытия, связанные с пространством покрытия неявной реализации. | |
| + | <!-- 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 ==== | + | * [[Coverage Cookbook/Coverage Metrics and process (Theory)/Code Coverage Metrics|Метрики покрытия кода]] ([https://verificationacademy.com/cookbook/Coverage/Code_Coverage_Metrics Code Coverage Metrics] (Implicit coverage)) |
| + | * [[Coverage Cookbook/Coverage Metrics and process (Theory)/Functional Coverage Metrics|Метрики функционального покрытия]] ([https://verificationacademy.com/cookbook/Coverage/Functional_Coverage_Metrics Functional Coverage/Assertion Coverage Metrics] (Explicit coverage)) | ||
| + | <!-- ==== Coverage Metrics ==== | ||
There are two primary forms of coverage metrics in production use in industry today and these are: | There are two primary forms of coverage metrics in production use in industry today and these are: | ||
| − | * [[Coverage Cookbook/Coverage Metrics and process (Theory)/Code Coverage Metrics|Code Coverage Metrics]] ([https://verificationacademy.com/cookbook/Coverage/Code_Coverage_Metrics Code Coverage Metrics] ( | + | * [[Coverage Cookbook/Coverage Metrics and process (Theory)/Code Coverage Metrics|Code Coverage Metrics]] ([https://verificationacademy.com/cookbook/Coverage/Code_Coverage_Metrics Code Coverage Metrics] (Неявное покрытие)) |
| − | * [[Coverage Cookbook/Coverage Metrics and process (Theory)/Functional Coverage Metrics|Functional Coverage Metrics]] ([https://verificationacademy.com/cookbook/Coverage/Functional_Coverage_Metrics Functional Coverage/Assertion Coverage Metrics] ( | + | * [[Coverage Cookbook/Coverage Metrics and process (Theory)/Functional Coverage Metrics|Functional Coverage Metrics]] ([https://verificationacademy.com/cookbook/Coverage/Functional_Coverage_Metrics Functional Coverage/Assertion Coverage Metrics] (Явное покрытие)) --> |
| − | === | + | === Ссылки === |
[1] A. Piziali, ''Functional Verification Coverage Measurement and Analysis'', Kluwer Academic Publishers, 2004. | [1] A. Piziali, ''Functional Verification Coverage Measurement and Analysis'', Kluwer Academic Publishers, 2004. | ||
[[Категория:Coverage]] | [[Категория:Coverage]] | ||
Текущая версия на 13:49, 8 апреля 2013
|
Эта статья требует перевода на русский язык |
- Метрики и процессы покрытия (en)
- Coverage Examples (Practice) (en)
- Requirements Writing Guidelines (en)
Содержание |
Покрытие/Что такое покрытие
Как говорится, "Что нельзя измерить, не может быть сделано." И это, конечно, верно в случаях, когда мы пытаемся определить прогресс верификации проекта или пытаемся ответить на вопрос: "Все готово?" Будь ваша методика моделирования основана на методе направленного тестирования или на настраиваемой псевдослучайной верификации, чтобы понять ход вашей верификации вам необходимо ответить на следующие вопросы:
- Все ли конструктивные особенности и требования, определенные в плане теста, были верифицированы?
- Есть ли такие строки кода или структуры в проекте, которые никогда не были использованы?
Покрытие — это метрика, которое мы используем в процессе моделирования, чтобы ответить на эти вопросы. Тем не менее, как только метрики покрытия стали неотъемлемой частью нашего процесса верификации, это дает возможности для более точных прогнозов работы проекта, а также предоставление средств для оптимизации нашего общего процесса верификации. На данном этапе мы можем задавать такие вопросы как:
- Когда мы тестировали функцию X, мы когда-нибудь проверяли функцию Y в то же самое время?
- Зависал ли наш прогресс верификации по неожиданным причинам?
- Существуют ли тесты, которые можно устранить, чтобы ускорить выполнение нашего набора регрессионных тестов и все ещё достигать наших целей покрытия?
Таким образом, покрытие — это метрика в моделировании, которое мы используем для измерения прогресса верификации и завершенности.
Наблюдаемость и управляемость
Основой для обсуждения покрытия является понимание понятий управляемость и наблюдаемость. Фактически, управляемость относится к возможности влиять или активировать встроенный конечный автомат, структуру, специальные строки кода или поведение в проекте, стимулируя различные порты ввода. Обратите внимание, что в то время как в теории моделирования тестовая программа имеет высокую управляемость портов ввода модели проекта во время верификации, она может иметь очень низкую управляемость внутренней структуры в рамках этой модели. В отличие от управления, наблюдение относится к возможности наблюдать эффекты конкретного внутреннего состояния конечного автомата, структуры или стимулированной строки кода. Таким образом, тестовая программа, как правило, имеет ограниченную возможность наблюдения, если она наблюдает только за внешними портами модели проекта (потому что внутренние сигналы и структуры часто неявно скрыты от тестовой программы).
Чтобы определить ошибку в проекте, используя подход моделирования тестовой программы, следующие условия должны выполняться:
- Тестовая программа должна создавать надлежащие входные воздействия для активации ошибки в проекте.
- Тестовая программа должна создавать надлежащие входные воздействия для распространения всех последствий (явлений), связанных с ошибкой в проекте, на выходной порт.
- Тестовая программа должна содержать монитор, который может обнаружить ошибку в проекте, которая была сначала активирована, затем распространена в точку, где может быть обнаружена.
Вполне возможно создать условия, где входной сигнал активирует ошибку проектирования, которая не распространяется на наблюдаемые выходные порты. В этих случаях принимается первое условие приведенное выше; однако, второе условие отсутствует, как показано на рисунке 1.
В целом, покрытие — это метрика, которое мы используем для определения качества управления тестовой программы. Например, покрытие кода может непосредственно определить строки кода, которые не были активированы из-за плохой управляемости исходящей от входного сигнала моделирования. Кроме того, функциональное покрытие может определить ожидаемые поведения, которые никогда не были активированы во время моделирования из-за плохой управляемости.
Хотя наши обсуждения в этом разделе сосредоточены на покрытии, важно отметить, что мы можем обратиться к проблемам наблюдения путем внедрения утверждений в модели проекта для обеспечения низкого уровня наблюдения и создания мониторов внутри и на выходных портах нашей тестовой программы для обеспечения высокого уровня наблюдения.
Резюме
Так что же такое покрытие? Проще говоря, покрытие — это метрика, которую мы используем для измерения прогресса верификации и её завершенности. Метрики покрытия говорят нам, какая часть проекта была активирована во время моделирования (то есть, качества управления тестовой программы). Или, что еще более важно, метрики покрытия определяют части проекта, которые не были активированы в процессе моделирования, что позволяет нам корректировать наш входной сигнал для улучшения верификации.
Существуют различные виды метрик покрытий доступные вам, и процесс, как их использовать описан в Coverage Cookbook examples.
Покрытие/Виды покрытия
Нет единственной метрики, которой было бы достаточно при полной характеризации процесса верификации. Например, мы могли бы добиться 100% покрытия кода во время регрессионного моделирования. Однако, это не означает, что 100% функциональности было верифицировано. Причиной этого является то, что покрытие кода не измеряет одновременное взаимодействие поведения внутри или между несколькими блоками проекта, а также не измеряет временной последовательности функциональных событий, которые происходят в проекте. Кроме того, мы могли бы достичь 100% функционального покрытия, но только достигнув 90% покрытия кода. Это может означать, что либо есть проблемы с точностью в нашей функциональной модели покрытия (то есть важное поведение в проекте отсутствовало в модели покрытия), или, возможно, некоторая функциональность была реализована так, что там не определены начальные значения (например, возможно, спецификация и план тестирования должны быть обновлены на некотором последующем шаге с изменением в требований). Таким образом, чтобы получить полное представление о ходе верификации проекта нам часто нужно несколько метрик.
Классификация покрытий
Перед началом рассмотрения видов метрик покрытия, полезно сперва определить различные классификации покрытий. В общем, существует несколько способов классифицировать покрытие, но два самых распространенных способа — это классифицировать их либо по методу создания (например, явные или неявные) или по происхождению источника (например, спецификация или реализация).
Например, функциональное покрытие является одним из примеров явной метрики покрытия, которая была определена вручную, а затем осуществляется инженером. В то же время, покрытие строк и покрытие выражений являются двумя примерами неявных метрик покрытия, так как их определение и реализация автоматически получены и извлечены из RTL описания.
Классификация пространства покрытия
Покрытие, связанное с двумя категориями, которые мы только что описали, может быть объединено, чтобы сформировать область покрытия, которое часто называют модель покрытие [1]. Например, точная область покрытия спецификации состоит из метрик покрытия, которые созданы вручную инженером, выделенные из требований проекта или спецификации. Другим видом точного покрытия является инструментарий, созданный инженером, который основан на скрытом поведении в реализации проекта, например, заполнение или опустошение стека, связанное с конкретным FIFO в RTL модели.
Кроме того, пространство покрытия неявной реализации состоит из метрик покрытия, которые автоматически извлекаются с помощью инструментов (таких как симулятор), и полученные от реализации проекта (например, RTL модели). Другая часть пространство покрытия неявной спецификации состоит из метрик покрытия, которые автоматически извлекаются с помощью инструмента, и полученные из спецификации проекта. Эта часть пространства покрытия в настоящее время область научных исследований, 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. Отметим, что поведения более высокого уровня функционального не могут автоматически извлекаться из реализации в одиночку, поэтому они попадают в метриках покрытия, связанные с пространством покрытия неявной реализации.
Метрики покрытий
Существуют две основные формы метрик покрытия используемые сегодня в производстве:
- Метрики покрытия кода (Code Coverage Metrics (Implicit coverage))
- Метрики функционального покрытия (Functional Coverage/Assertion Coverage Metrics (Explicit coverage))
Ссылки
[1] A. Piziali, Functional Verification Coverage Measurement and Analysis, Kluwer Academic Publishers, 2004.
