OVM/OVM методология/Layered Organization of Testbenches/ru — различия между версиями
(→Stimulus Generator) |
м (→Уровневая организация тестовых программ) |
||
| (не показаны 48 промежуточных версий 2 участников) | |||
| Строка 11: | Строка 11: | ||
}} | }} | ||
| − | |||
== Уровневая организация тестовых программ == | == Уровневая организация тестовых программ == | ||
| + | <!-- == Layered Organization of Testbenches == --> | ||
| + | Так же, как проект (схема) является сетью компонентов проекта, тестовая программа является сетью компонентов верификации. OVM определяет компоненты верификации, их структуру, интерфейс. Этот раздел описывает сущность компонентов OVM. | ||
<!-- Just as a design is a network of design components, a testbench is a network | <!-- Just as a design is a network of design components, a testbench is a network | ||
of verification components. The OVM defines verification components, their | of verification components. The OVM defines verification components, their | ||
structure, and interfaces. This section describes the essential OVM | structure, and interfaces. This section describes the essential OVM | ||
components. --> | components. --> | ||
| − | |||
Тестовые программы OVM организованы в виде уровней. На самом нижнем уровне находится DUT, устройство RTL с pin-level интерфейсом (с интерфейсом на уровне выводов). Выше находится уровень транзакторов (посредник), устройств, которые преобразуют из уровня транзакций в pin-level. Все компоненты, находящиеся на этом уровне, являются компонентами уровня транзакций. Диаграмма, приведенная ниже, иллюстрирует уровневую организацию тестовых программ. | Тестовые программы OVM организованы в виде уровней. На самом нижнем уровне находится DUT, устройство RTL с pin-level интерфейсом (с интерфейсом на уровне выводов). Выше находится уровень транзакторов (посредник), устройств, которые преобразуют из уровня транзакций в pin-level. Все компоненты, находящиеся на этом уровне, являются компонентами уровня транзакций. Диаграмма, приведенная ниже, иллюстрирует уровневую организацию тестовых программ. | ||
| Строка 35: | Строка 35: | ||
<center>[[Файл:23.png]] | <center>[[Файл:23.png]] | ||
| + | <!-- '''Figure 1-7 OVM Testbench Architecture Layers'''--></center> | ||
| − | |||
Мы можем также представить тестовую программу, как концентричекую организацию компонентов. Внутреннему кольцу соответствует нижний | Мы можем также представить тестовую программу, как концентричекую организацию компонентов. Внутреннему кольцу соответствует нижний | ||
| Строка 49: | Строка 49: | ||
<center>[[Файл:24.png]] | <center>[[Файл:24.png]] | ||
| − | '''Figure 1-8 Concentric Testbench Organization'''</center> | + | <!-- '''Figure 1-8 Concentric Testbench Organization'''--></center> |
| + | === Транзакторы === | ||
| + | Задача транзакторов в тестовой программе - это преобразование потока транзакций в pin-level activity или наоборот. Транзакторы характеризуются наличием хотя бы одного pin-level интерфейса и хотя бы одного transaction-level интерфейса. Существуюет большое количество разновидностей транзакторов. Мы сфокусируемся на мониторах, драйверах и респондерах. | ||
<!-- === Transactors === | <!-- === Transactors === | ||
The role of a transactor in a testbench is to convert a stream of transactions to | The role of a transactor in a testbench is to convert a stream of transactions to | ||
| Строка 57: | Строка 59: | ||
Transactors come in a wide variety of shapes, colors, and styles. We’ll focus | Transactors come in a wide variety of shapes, colors, and styles. We’ll focus | ||
on monitors, drivers, and responders. --> | on monitors, drivers, and responders. --> | ||
| − | |||
| − | |||
| + | ==== Монитор ==== | ||
| + | Монитор как следует из имени, осуществляет мониторинг шины. Он следит за выводами и преобразует их изменения в поток транзакций. Мониторы - пассивны, то есть они не оказывают никакого влияния на операции в DUT. | ||
| + | ==== Драйвер ==== | ||
| + | Драйвер преобразует поток транзакций (или последовательность элементов) в pin-level activity. | ||
| + | ==== Респондер ==== | ||
| + | Респондер похож на драйвер, только он реагирует на активность на выходе, а не на входную активность. | ||
<!-- ==== Monitor ==== | <!-- ==== Monitor ==== | ||
A monitor, as the name implies, monitors a bus. It watches the pins | A monitor, as the name implies, monitors a bus. It watches the pins | ||
| Строка 68: | Строка 74: | ||
Responder. A responder is much like a driver, but it responds to activity on | Responder. A responder is much like a driver, but it responds to activity on | ||
pins rather than initiating activity. --> | pins rather than initiating activity. --> | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | === Операционные компоненты === | ||
| + | |||
| + | Операционные компоненты - это набор компонентов, которые обеспечивают все необходимые операции в DUT. | ||
| + | Операционные компоненты ответственны за генерацию трафика для DUT. Все эти компоненты относятся к уровню транзакций | ||
| + | и имеют только интерфейс уровня транзакций. Существуют различные варианты формирования сигнала, которые варьируются в | ||
| + | зависимости от верифицируемого устройства. Мы рассмотрим три основных вида операционных компонентов: stimulus generators, masters, и slaves. | ||
<!-- === Operational Components=== | <!-- === Operational Components=== | ||
| Строка 83: | Строка 89: | ||
as varied as the kinds of devices there are to verify. We’ll look at three general | as varied as the kinds of devices there are to verify. We’ll look at three general | ||
kinds of operational components: stimulus generators, masters, and slaves. --> | kinds of operational components: stimulus generators, masters, and slaves. --> | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | ====Генератор входных воздействий==== | ||
| + | Генератор входных воздействий создают поток транзакций, осуществляемых в DUT. Генераторы входных воздействий могут быть случайными, | ||
| + | заданными или заданными случайно; они могут запускаться самостоятельно или контролируемо; и они могут быть независимыми | ||
| + | или синхронизированными. Простейший генератор входных воздействий рандомизирует содержимое объекта запроса и посылает этот объект | ||
| + | на драйвер. OVM также предоставляет модульные динамические средства для построения сложных входных воздействий, называемыми последовательностями. Это подробно рассмотрено в главе 8. | ||
<!-- ====Stimulus Generator==== | <!-- ====Stimulus Generator==== | ||
Stimulus generators create a stream of transactions for | Stimulus generators create a stream of transactions for | ||
| Строка 103: | Строка 103: | ||
provides a modular, dynamic facility for building complex stimulus called | provides a modular, dynamic facility for building complex stimulus called | ||
sequences. These are discussed in detail in Chapter 8. --> | sequences. These are discussed in detail in Chapter 8. --> | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | ==== Master==== | + | ==== Мастер==== |
| + | Мастер - это двунаправленный компонент, который посылает запросы и принимает ответы. | ||
| + | Мастер инициирует активность. Также как и stimulus генераторы, они могут посылать | ||
| + | индивидуально рандомизированные транзакции или последовательности заданных или случайно | ||
| + | заданных транзакций. Мастер может использовать ответы для определения своих последующих действий. | ||
| + | Мастер может быть также реализован в терминах последовательностей. | ||
| + | <!-- ==== Master==== | ||
A master is a bidirectional component that sends requests and | A master is a bidirectional component that sends requests and | ||
receives responses. Masters initiate activity. Like stimulus generators, they | receives responses. Masters initiate activity. Like stimulus generators, they | ||
| Строка 115: | Строка 116: | ||
directed-random transactions. Masters may use the responses to determine | directed-random transactions. Masters may use the responses to determine | ||
their next course of action. Masters can also be implemented in terms of | their next course of action. Masters can also be implemented in terms of | ||
| − | sequences. | + | sequences. --> |
==== Slave ==== | ==== Slave ==== | ||
| + | Slaves, также как и мастера, являются двунаправленными компонентами. Они отвечают на запросы и возвращают ответы | ||
| + | (в отличии от мастеров, которые посылают запросы и принимают ответы). | ||
| + | <!-- ==== Slave ==== | ||
Slaves, like masters, are bidirectional components. They respond to | Slaves, like masters, are bidirectional components. They respond to | ||
requests and return responses (in contrast to masters, which send requests | requests and return responses (in contrast to masters, which send requests | ||
| − | and receive responses). | + | and receive responses). --> |
| − | <center>''' | + | <center>[[Файл:25.png]] |
| + | <!-- '''Рисунок 1-9 Мастер и Slave'''--></center> | ||
| − | === 1.4.3 Analysis Components === | + | === Компоненты анализа === |
| + | Компоненты анализа принимают информацию о том, что происходит в тестовой программе и | ||
| + | используют эту информацию для определения корректности и завершенности выполнения теста. | ||
| + | Два наиболее распространенных видов компонентов анализа - это scoreboards и coverage collectors. | ||
| + | <!-- === 1.4.3 Analysis Components === | ||
Analysis components receive information about what’s going on in the | Analysis components receive information about what’s going on in the | ||
testbench and use that information to make some determination about the | testbench and use that information to make some determination about the | ||
correctness or completeness of the test. Two common kinds of analysis | correctness or completeness of the test. Two common kinds of analysis | ||
| − | components are scoreboards and coverage collectors. | + | components are scoreboards and coverage collectors. --> |
==== Scoreboard ==== | ==== Scoreboard ==== | ||
| + | Scoreboards используются для определения корректности DUT, показывая, работает ли устройство. | ||
| + | Scoreboards перехватывают информацию, входящую и выходящую из DUT и определяют правильно ли DUT отвечает на данный stimulus. | ||
| + | <!-- ==== Scoreboard ==== | ||
Scoreboards are used to determine correctness of the DUT, to | Scoreboards are used to determine correctness of the DUT, to | ||
answer does-it-work questions. Scoreboards tap off information going into | answer does-it-work questions. Scoreboards tap off information going into | ||
and out of the DUT and determine if the DUT is responding correctly to its | and out of the DUT and determine if the DUT is responding correctly to its | ||
| − | stimulus. | + | stimulus. --> |
| − | ==== Coverage Collector ==== | + | ==== Coverage Collector (Сборщик покрытия) ==== |
| + | Coverage collectors считают элементы. Они перехватывают поток транзакций и считают транзакции или их различные аспекты. | ||
| + | Целью является определение завершенности верификации. Что конкретно должен считать coverage collector, зависит от архитектуры | ||
| + | и особенностей теста. Наиболее распространенные вещи, которые считают coverage collectors - это ряд транзакций, транзакции, происходящие в определенном сегменте адресного пространства, и ошибки протокола. Список неограничен. | ||
| + | |||
| + | Coverage collectors могут также производить вычисления как часть полной проверки. | ||
| + | Например, coverage collector может {{Жел|keep a running mean and | ||
| + | standard deviation of data being tracked}}. Или может содержать отношение ошибок к успешным | ||
| + | транзакциям. | ||
| + | <!-- ==== Coverage Collector ==== | ||
Coverage collectors count things. They tap into streams of | Coverage collectors count things. They tap into streams of | ||
transactions and count the transactions or various aspects of the transactions. | transactions and count the transactions or various aspects of the transactions. | ||
| Строка 149: | Строка 170: | ||
check. For example, a coverage collector might keep a running mean and | check. For example, a coverage collector might keep a running mean and | ||
standard deviation of data being tracked. Or it might keep a ratio of errors to | standard deviation of data being tracked. Or it might keep a ratio of errors to | ||
| − | good transactions. | + | good transactions. --> |
| − | === 1.4.4 Controller === | + | === Контроллер === |
| + | |||
| + | ''Контроллеры'' формируют основной поток теста и управляет активностью. | ||
| + | Обычно, контроллеры получают информацию из scoreboards и coverage | ||
| + | collectors и посылают информацию на компоненты среды. | ||
| + | |||
| + | Например, контроллер может запустить stimulus generator и затем ждать сигнала | ||
| + | coverage collector о том, что тест завершен. Контроллер, в свою очередь, останавливает | ||
| + | stimulus generator. Также возможны более сложные вариации. В качестве примера возможной конфигурации, | ||
| + | можно рассмотреть контроллер, подающий начальный набор ограничений на stimulus generator и запускающий его. | ||
| + | Когда определенное соотношение типов пакетов достигнуто, coverage collector сообщает это контроллеру. | ||
| + | Вместо того, чтобы остановить stimulus generator, контроллер может отправить ему новый набор ограничений. | ||
| + | |||
| + | <!-- === 1.4.4 Controller === | ||
''Controllers'' form the main thread of a test and orchestrate the activity. | ''Controllers'' form the main thread of a test and orchestrate the activity. | ||
| Строка 166: | Строка 200: | ||
Rather than stopping the stimulus generator, the controller may send it a new | Rather than stopping the stimulus generator, the controller may send it a new | ||
set of constraints. | set of constraints. | ||
| + | --> | ||
| + | |||
| + | == Две области == | ||
| − | == 1.5 Two Domains == | + | Мы можем рассмотреть набор компонентов в тестовой программе как компоненты, принадлежащие к |
| + | двум отдельным областям. ''Оперативная область'' - это набор компонентов, включающий | ||
| + | DUT, выполняющие операции над DUT. Это stimulus generators, шина функциональных моделей (ШФМ), | ||
| + | и аналогичные компоненты, которые генерируют сигналы и возвращают ответы, которые управляют | ||
| + | симуляцией. DUT, респондер и драйвер наряду с компонентами среды, которые непосредственно | ||
| + | взаимодействуют с драйверами и респондерами составляют оперативную область. Остальные компоненты | ||
| + | тестовой программы — монитор, scoreboards, coverage collectors и контроллер — составляют | ||
| + | ''облать анализа''. Это компоненты, которые собирают информацию из оперативной области. | ||
| + | <!-- == 1.5 Two Domains == | ||
We can view the set of components in a testbench as belonging to two | We can view the set of components in a testbench as belonging to two | ||
| Строка 178: | Строка 223: | ||
rest of the testbench components—monitor transactors, scoreboards, | rest of the testbench components—monitor transactors, scoreboards, | ||
coverage collectors, and controller—comprise the ''analysis domain''. These are | coverage collectors, and controller—comprise the ''analysis domain''. These are | ||
| − | the components that collect information from the operational domain. | + | the components that collect information from the operational domain. --> |
| − | Data must be moved from the operational domain to the analysis domain in a | + | Данные должны быть перемещены из оперативной области в область анализа таким образом, чтобы |
| + | не мешать работе DUT и {{Жел|preserves event timing}}. Это достигается с помощью специального | ||
| + | интерфейса связи, называемого ''порт анализа''. Порты анализа представляют собой особый вид порта | ||
| + | транзакций, в котором {{Жел|publisher}} передает данные одному или нескольким {{Жел|subscribers}}. | ||
| + | <!-- Data must be moved from the operational domain to the analysis domain in a | ||
way that does not interfere with the operation of the DUT and preserves | way that does not interfere with the operation of the DUT and preserves | ||
event timing. This is accomplished with a special communication interface | event timing. This is accomplished with a special communication interface | ||
called an ''analysis port''. Analysis ports are a special kind of transaction port in | called an ''analysis port''. Analysis ports are a special kind of transaction port in | ||
which a publisher broadcasts data to one or more subscribers. The publisher | which a publisher broadcasts data to one or more subscribers. The publisher | ||
| − | signals all the subscribers when it has new data ready. | + | signals all the subscribers when it has new data ready. --> |
| − | One of the key features of analysis ports is that they have a single interface | + | Одной из ключевых особенностей портов анализа является то, что они имеют единую Функцию интерфейса write(). FIFO анализа, каналы используемые для подключения портов анализа к компонентам анализа - не ограничены. Это гарантирует то, что {{Жел|publisher}} не блокирует и сдает свои данные в FIFO анализа в точно таком же дельте цикле, в котором он был создан. В главе 7 обсуждаются порты анализа и и FIFO анализа более подробно. |
| + | <!-- One of the key features of analysis ports is that they have a single interface | ||
function, <code>write()</code>. Analysis FIFOs, the channels used to connect analysis | function, <code>write()</code>. Analysis FIFOs, the channels used to connect analysis | ||
ports to analysis components, are unbounded. This guarantees that the | ports to analysis components, are unbounded. This guarantees that the | ||
publisher doesn’t block and that it deposits its data into the analysis FIFO in | publisher doesn’t block and that it deposits its data into the analysis FIFO in | ||
precisely the same delta cycle in which it was generated. Chapter 7 discusses | precisely the same delta cycle in which it was generated. Chapter 7 discusses | ||
| − | analysis ports and analysis FIFOs in more detail. | + | analysis ports and analysis FIFOs in more detail.--> |
| − | <center> | + | <center>[[Файл:26.png]] |
| − | Generally, the operational and analysis domains are connected by analysis | + | <!-- '''Figure 1-10 Connection between Operational and Analysis Domains'''--> |
| + | </center> | ||
| + | Как правило, оперативная область и область анализа связаны с помощью портов анализа и интерфейсов управления и конфигурации. Порты анализа перехватывают данные касаемые операций в DUT. Эти данные могут включать транзакции шины, пакеты коммуникации и информацию о состоянии (успех или неудача в конкретной операции). Компоненты в области анализа анализируют данные и принимают решения. Результаты этих решений могут быть связаны с оперативной областью через интерфейсы управления и конфигурации. Интерфейсы управления и конфигурации могут быть использованы для запуска и остановки генераторов входных воздействий, изменения ограничений, изменения показателей ошибок или для манипуляции других параметров, влияющих на работу тестовой программы. | ||
| + | <!-- Generally, the operational and analysis domains are connected by analysis | ||
ports and control and configuration interfaces. Analysis ports tap off data | ports and control and configuration interfaces. Analysis ports tap off data | ||
concerning the operation of the DUT. These data might include bus | concerning the operation of the DUT. These data might include bus | ||
| Строка 206: | Строка 259: | ||
interfaces. Control and configuration interfaces can be used to start and stop | interfaces. Control and configuration interfaces can be used to start and stop | ||
stimulus generators, change constraints, modify error rates, or manipulate | stimulus generators, change constraints, modify error rates, or manipulate | ||
| − | other parameters affecting how the testbench operates. | + | other parameters affecting how the testbench operates.--> |
Текущая версия на 12:18, 13 марта 2013
|
Эта статья требует перевода на русский язык |
Глава 1.4 из книги Glasser M. Open Verification Methodology Cookbook — USA: Springer, 2009. — 248 с. — ISBN 978-1-4419-0967-1.
Содержание |
Уровневая организация тестовых программ
Так же, как проект (схема) является сетью компонентов проекта, тестовая программа является сетью компонентов верификации. OVM определяет компоненты верификации, их структуру, интерфейс. Этот раздел описывает сущность компонентов OVM.
Тестовые программы OVM организованы в виде уровней. На самом нижнем уровне находится DUT, устройство RTL с pin-level интерфейсом (с интерфейсом на уровне выводов). Выше находится уровень транзакторов (посредник), устройств, которые преобразуют из уровня транзакций в pin-level. Все компоненты, находящиеся на этом уровне, являются компонентами уровня транзакций. Диаграмма, приведенная ниже, иллюстрирует уровневую организацию тестовых программ. Блок слева — название уровня, блок справа — перечень типов компонентов, входящих в него. Вертикальные стрелки показывают, какие уровни взаимодействуют на прямую. Например, управляющий уровень взаимодействует с уровнями анализа, операций, транзакторов, но с DUT напрямую не может.
Мы можем также представить тестовую программу, как концентричекую организацию компонентов. Внутреннему кольцу соответствует нижний
уровень, а внешнему кольцу - верхний уровень. Для некоторых будет проще понять отношения между уровнями, используя диаграмму в виде
списка связей.
Транзакторы
Задача транзакторов в тестовой программе - это преобразование потока транзакций в pin-level activity или наоборот. Транзакторы характеризуются наличием хотя бы одного pin-level интерфейса и хотя бы одного transaction-level интерфейса. Существуюет большое количество разновидностей транзакторов. Мы сфокусируемся на мониторах, драйверах и респондерах.
Монитор
Монитор как следует из имени, осуществляет мониторинг шины. Он следит за выводами и преобразует их изменения в поток транзакций. Мониторы - пассивны, то есть они не оказывают никакого влияния на операции в DUT.
Драйвер
Драйвер преобразует поток транзакций (или последовательность элементов) в pin-level activity.
Респондер
Респондер похож на драйвер, только он реагирует на активность на выходе, а не на входную активность.
Операционные компоненты
Операционные компоненты - это набор компонентов, которые обеспечивают все необходимые операции в DUT. Операционные компоненты ответственны за генерацию трафика для DUT. Все эти компоненты относятся к уровню транзакций и имеют только интерфейс уровня транзакций. Существуют различные варианты формирования сигнала, которые варьируются в зависимости от верифицируемого устройства. Мы рассмотрим три основных вида операционных компонентов: stimulus generators, masters, и slaves.
Генератор входных воздействий
Генератор входных воздействий создают поток транзакций, осуществляемых в DUT. Генераторы входных воздействий могут быть случайными, заданными или заданными случайно; они могут запускаться самостоятельно или контролируемо; и они могут быть независимыми или синхронизированными. Простейший генератор входных воздействий рандомизирует содержимое объекта запроса и посылает этот объект на драйвер. OVM также предоставляет модульные динамические средства для построения сложных входных воздействий, называемыми последовательностями. Это подробно рассмотрено в главе 8.
Мастер
Мастер - это двунаправленный компонент, который посылает запросы и принимает ответы. Мастер инициирует активность. Также как и stimulus генераторы, они могут посылать индивидуально рандомизированные транзакции или последовательности заданных или случайно заданных транзакций. Мастер может использовать ответы для определения своих последующих действий. Мастер может быть также реализован в терминах последовательностей.
Slave
Slaves, также как и мастера, являются двунаправленными компонентами. Они отвечают на запросы и возвращают ответы (в отличии от мастеров, которые посылают запросы и принимают ответы).
Компоненты анализа
Компоненты анализа принимают информацию о том, что происходит в тестовой программе и используют эту информацию для определения корректности и завершенности выполнения теста. Два наиболее распространенных видов компонентов анализа - это scoreboards и coverage collectors.
Scoreboard
Scoreboards используются для определения корректности DUT, показывая, работает ли устройство. Scoreboards перехватывают информацию, входящую и выходящую из DUT и определяют правильно ли DUT отвечает на данный stimulus.
Coverage Collector (Сборщик покрытия)
Coverage collectors считают элементы. Они перехватывают поток транзакций и считают транзакции или их различные аспекты. Целью является определение завершенности верификации. Что конкретно должен считать coverage collector, зависит от архитектуры и особенностей теста. Наиболее распространенные вещи, которые считают coverage collectors - это ряд транзакций, транзакции, происходящие в определенном сегменте адресного пространства, и ошибки протокола. Список неограничен.
Coverage collectors могут также производить вычисления как часть полной проверки. Например, coverage collector может keep a running mean and standard deviation of data being tracked. Или может содержать отношение ошибок к успешным транзакциям.
Контроллер
Контроллеры формируют основной поток теста и управляет активностью. Обычно, контроллеры получают информацию из scoreboards и coverage collectors и посылают информацию на компоненты среды.
Например, контроллер может запустить stimulus generator и затем ждать сигнала coverage collector о том, что тест завершен. Контроллер, в свою очередь, останавливает stimulus generator. Также возможны более сложные вариации. В качестве примера возможной конфигурации, можно рассмотреть контроллер, подающий начальный набор ограничений на stimulus generator и запускающий его. Когда определенное соотношение типов пакетов достигнуто, coverage collector сообщает это контроллеру. Вместо того, чтобы остановить stimulus generator, контроллер может отправить ему новый набор ограничений.
Две области
Мы можем рассмотреть набор компонентов в тестовой программе как компоненты, принадлежащие к двум отдельным областям. Оперативная область - это набор компонентов, включающий DUT, выполняющие операции над DUT. Это stimulus generators, шина функциональных моделей (ШФМ), и аналогичные компоненты, которые генерируют сигналы и возвращают ответы, которые управляют симуляцией. DUT, респондер и драйвер наряду с компонентами среды, которые непосредственно взаимодействуют с драйверами и респондерами составляют оперативную область. Остальные компоненты тестовой программы — монитор, scoreboards, coverage collectors и контроллер — составляют облать анализа. Это компоненты, которые собирают информацию из оперативной области.
Данные должны быть перемещены из оперативной области в область анализа таким образом, чтобы не мешать работе DUT и preserves event timing. Это достигается с помощью специального интерфейса связи, называемого порт анализа. Порты анализа представляют собой особый вид порта транзакций, в котором publisher передает данные одному или нескольким subscribers.
Одной из ключевых особенностей портов анализа является то, что они имеют единую Функцию интерфейса write(). FIFO анализа, каналы используемые для подключения портов анализа к компонентам анализа - не ограничены. Это гарантирует то, что publisher не блокирует и сдает свои данные в FIFO анализа в точно таком же дельте цикле, в котором он был создан. В главе 7 обсуждаются порты анализа и и FIFO анализа более подробно.
Как правило, оперативная область и область анализа связаны с помощью портов анализа и интерфейсов управления и конфигурации. Порты анализа перехватывают данные касаемые операций в DUT. Эти данные могут включать транзакции шины, пакеты коммуникации и информацию о состоянии (успех или неудача в конкретной операции). Компоненты в области анализа анализируют данные и принимают решения. Результаты этих решений могут быть связаны с оперативной областью через интерфейсы управления и конфигурации. Интерфейсы управления и конфигурации могут быть использованы для запуска и остановки генераторов входных воздействий, изменения ограничений, изменения показателей ошибок или для манипуляции других параметров, влияющих на работу тестовой программы.
