OVM/OVM методология/Transaction-Level моделирование - История изменений

Anastasiya: /* */

2013-04-09T15:11:21Z

‎

Vidokq: /* Блокирующие интерфейсы против не блокирующих */

2013-03-18T19:26:23Z

‎Блокирующие интерфейсы против не блокирующих

Vidokq: /* TLM идиомы */

2013-03-18T17:34:08Z

‎TLM идиомы

Vidokq: /* Абстракция */

2013-03-18T17:15:21Z

‎Абстракция

Vidokq: /* Абстракция */

2013-03-18T17:09:06Z

‎Абстракция

Vidokq: /* Абстракция */

2013-03-18T17:04:44Z

‎Абстракция

ANA: /* Get */

2013-03-15T11:37:10Z

‎Get

Anastasiya в 08:11, 14 марта 2013

2013-03-14T08:11:57Z

Anastasiya в 13:25, 13 марта 2013

2013-03-13T13:25:18Z

ANA: /* Блокирующие интерфейсы против не блокирующих */

2013-03-12T14:03:01Z

‎Блокирующие интерфейсы против не блокирующих

@@ Строка 6: / Строка 6: @@
 Процесс проектирования электронной системы включает в себя последовательное замещение абстрактных идей  конкретной их реализацией, пока не будет достигнуто представление, которое может быть изготовлено на кремнии. С момента появления цифровой интегральной схемы, электронные сообщества тщательно определили и кодировали абстракции, начиная с переключателей и логических элементов, для обеспечения среды  в которой работает  проект. RTL является примером среды, часто используемой для создания проектов. Есть много инструментов на основе RTL, которые делают ее удобной для  создания проекта и его верификации.
-Однако, как только проект становится больше и сложнее, становится  более представлять их с помощью абстракции выше, чем RTL. Уровень транзакций становится популярным для создания первого представления проекта, которое может быть смоделировано и проанализировано.
+Однако, как только проекты становятся больше и сложнее, становится все сложнее представлять их с помощью абстракции выше, чем RTL. Уровень транзакций становится популярным для создания первого представления проекта, которое может быть смоделировано и проанализировано.
 В этой главе описаны основные понятия transaction-level моделирования (TLM). Модели  transaction-level состоят из нескольких процессов, которые обмениваются информацией посредством транзакций.
@@ Строка 18: / Строка 18: @@
 '''Абстракция времени.''' Время абстракция в симуляторе относится к тому, насколько внутренние состояния схемы совместимы. Модели, запущенные в управляемых событиями симуляторах (например, логических симуляторах) используют дискретное представление  времени, то есть события происходят в определенные моменты времени. События, как правило (хотя и не всегда) вызывают запущенный процесс. Чем больше событий происходит в симуляции, больше процессов вызывается, и с большим числом процессов происходит снижении скорости моделирования. Абстрагирование время уменьшает количество точек, где схема должна быть совместимой и общего числа событий и процессов, которые будут активированы. Например, в RTL модели, каждая сеть должна быть согласована после каждого изменения. В cycle-accurate абстракции, схема должна быть синхронизирована с синхросигналом, устраняя все события, что происходит между фронтами синхроимпульса. В transaction-level модели, состояния схемы должны быть синхронизированы в конце каждой операции, каждая из которых может охватывать много тактов.
-'''Абстракция данных'''. Данные относятся к объектам, передаваемым между компонентами. В RTL моделях, данные относятся к отдельным битам, которые передаются по сети между компонентами. В transaction-level моделях, данных представлены в виде транзакций, гетерогенных структур, которые содержат произвольные коллекции элементов.
+'''Абстракция данных'''. Данные относятся к объектам, передаваемым между компонентами. В RTL моделях, данные относятся к отдельным битам, которые передаются по сети между компонентами. В transaction-level моделях, данные представлены в виде транзакций, гетерогенных структур, которые содержат произвольные коллекции элементов.
 Рассмотрим пакет в устройстве связи. На самом низком уровне детализации, пакет содержит бит начала и стоп-биты, заголовок, информацию исправления ошибок, размер передаваемых данных, данные, и пакет остановки передачи(последний пакет - trailer). В более абстрактной модели, только данные и размер данных может быть необходим. Другие  данные не нужны  для выполнения расчетов.
-'''Абстракция функций.''' Функция модели является набором всех операций, которая она делать на каждое событие. Абстрагирование функций уменьшает этот набор или заменяет его более простыми вычислениями. Например, в ALU, вы можете выбрать использование родной операции умножении поставляемой в язык моделирования, вместо кодирования  a shift-and-add алгоритма умножения. Последний может быть частью реализации, но на более высоком уровне, детали a shift-and-add - неважны. Базовые элементы, которые являются частью языка, определяет, как вы можете абстрагировать функцию. В gate-level  языке, например, можно создавать сложные поведения, начиная с логических элементов. В RTL языка, построение  поведения основывается на арифметических и логических операциях над регистрами. В TLM, вы реализуете функциональность схемы с помощью вызовов функций произвольной сложности.
+'''Абстракция функций.''' Функция модели является набором всех операций, которая она делать на каждое событие. Абстрагирование функций уменьшает этот набор или заменяет его более простыми вычислениями. Например, в ALU, вы можете выбрать использование родной операции умножении поставляемой в язык моделирования, вместо кодирования  a shift-and-add алгоритма умножения. Последний может быть частью реализации, но на более высоком уровне, детали a shift-and-add - неважны. Базовые элементы, которые являются частью языка, определяет, как вы можете абстрагировать функцию. В gate-level  языке, например, можно создавать сложные поведения, начиная с логических элементов. В RTL языках, построение  поведения основывается на арифметических и логических операциях над регистрами. В TLM, вы реализуете функциональность схемы с помощью вызовов функций произвольной сложности.
 Для целей функциональной верификации, RTL самый низкий уровень абстракции, который мы должны рассмотреть. С синтезаторы могут эффективно конвертировать RTL в логические элементы, нам не нужно затрагивать  более низкий уровень детализации.
@@ Строка 62: / Строка 62: @@
 * Интерфейс DUT
-'''Интерфейс в SystemVerilog'''. SystemVerilog предоставляет конструкцию, называемую интерфейс, который является одним из основных объектов контейнер, из которого строится проект в SystemVerilog. Мы используем виртуальные интерфейсы, которые  указывают на интерфейсы для подключения module-based аппаратуры к  class-based testbenches.
+'''Интерфейс в SystemVerilog'''. SystemVerilog предоставляет конструкцию, называемую интерфейс, который является одним из основных объектов контейнера, из которого строится проект в SystemVerilog. Мы используем виртуальные интерфейсы, которые  указывают на интерфейсы для подключения module-based аппаратуры к  class-based testbenches.
 '''Интерфейс объекта.''' Общедоступные задачи и функции, доступные для объекта, образуют его интерфейс. Есть два небольших варианта этого значения интерфейса. Одним из них является прямой. Посмотрите на класс и определите, какие задачи и функций, доступны пользователю класса. Это его интерфейс. Другое значение состоит в ссылке на базовый класс, который определяет набор задач и функций, доступных для работы производного класса. Это значение интерфейса обычно используется в объектно-ориентированных языках, которые поддерживают множественное наследование, таких как C++ или Java. В этих  языках, вы можете установить требование, что производный класс определяет функциональность, наследуемую от интерфейса базового класса.

@@ Строка 323: / Строка 323: @@
 === Блокирующие интерфейсы против не блокирующих ===
+Интерфейсы, которые мы рассмотрели ранее, блокирующие. Это означает, что функции и задачи блокируют поток выполнения до их завершения. Им не разрешается заканчиваться неудачей.  Не существует механизма для блокировки при аварийном завершении или возможности иным образом изменять поток управления. Поток управления просто ждет, пока запрос будет выполнен. В синхронизированной системе это означает, что может  пройти время между вызовом и возвращением полученного результата.
-Интерфейсы мы рассмотрели ранее блокирующие. Это означает, что функции и задачи блокируют выполнение до их завершения. Им не разрешается заканчиваться неудачей.  Не существует механизма для  блокировки при аварийном завершении или иным образом изменять поток управления. Они просто ждать, пока запрос будет выполнен. В синхронизированной системе это означает, что время может пройти между вызовом и возвращением полученного результата.
 В put конфигурации, у нас есть два компонента, producer и consumer. Producer  генерирует случайное число и посылает его к consumer, используя  put(). Прежде чем вызывается put(),  нет активности в consumer. Вызов put() вызывает активность в consumer, которая выводит значение аргумента. За то время, что consumer является активным, producer ожидает. Это природа блокирующего вызова. Вызывающий должен ждать, пока вызов завершиться для возобновления выполнения.

@@ Строка 83: / Строка 83: @@
 == TLM идиомы ==
-В данном разделе рассматриваются основные средства передачи транзакций между компонентами. Мы put, get, и transport формы связи транзакций. Эти примеры не используют библиотеку OVM, так как они предназначены для иллюстрации основных механизмов связи на transaction-level с минимальными затратами. В следующем разделе мы рассмотрим более полный пример, который использует OVM библиотека для связи.
+В данном разделе рассматриваются основные средства передачи транзакций между компонентами. Мы рассмотрим put, get, и transport формы связи транзакций. Эти примеры не используют библиотеку OVM, так как они предназначены для иллюстрации основных механизмов связи на transaction-level с минимальными затратами. В следующем разделе мы рассмотрим более полный пример, который использует OVM библиотека для связи.
 === Put ===
@@ Строка 435: / Строка 435: @@
 Блокирующие интерфейсы полезны для работы с двумя компонентами синхронно. Вызовы блокируются до тех пор, пока запрошенная операция выполняется, не смотря на то, сколько это потребует времени. С другой стороны, неблокирующие интерфейсы полезны при асинхронной передаче данных. Они не ждут и могут быть использованы для опроса целей, как в приведенном примере.
 == Изоляция компонент с помощью каналов ==

@@ Строка 19: / Строка 19: @@
 '''Абстракция данных'''. Данные относятся к объектам, передаваемым между компонентами. В RTL моделях, данные относятся к отдельным битам, которые передаются по сети между компонентами. В transaction-level моделях, данных представлены в виде транзакций, гетерогенных структур, которые содержат произвольные коллекции элементов.
-Рассмотрим пакет в устройстве связи. На самом низком уровне детализации, пакет содержит бит начала и стоп-биты, заголовок, информацию исправления ошибок, размер передаваемых данных, данные, и пакет остановки передачи(последний пакет - trailer). В более абстрактной модели, только данные и размер данные могут быть необходимы. Другие  данные не нужны  для выполнения расчетов.
+Рассмотрим пакет в устройстве связи. На самом низком уровне детализации, пакет содержит бит начала и стоп-биты, заголовок, информацию исправления ошибок, размер передаваемых данных, данные, и пакет остановки передачи(последний пакет - trailer). В более абстрактной модели, только данные и размер данных может быть необходим. Другие  данные не нужны  для выполнения расчетов.
 '''Абстракция функций.''' Функция модели является набором всех операций, которая она делать на каждое событие. Абстрагирование функций уменьшает этот набор или заменяет его более простыми вычислениями. Например, в ALU, вы можете выбрать использование родной операции умножении поставляемой в язык моделирования, вместо кодирования  a shift-and-add алгоритма умножения. Последний может быть частью реализации, но на более высоком уровне, детали a shift-and-add - неважны. Базовые элементы, которые являются частью языка, определяет, как вы можете абстрагировать функцию. В gate-level  языке, например, можно создавать сложные поведения, начиная с логических элементов. В RTL языка, построение  поведения основывается на арифметических и логических операциях над регистрами. В TLM, вы реализуете функциональность схемы с помощью вызовов функций произвольной сложности.

@@ Строка 19: / Строка 19: @@
 '''Абстракция данных'''. Данные относятся к объектам, передаваемым между компонентами. В RTL моделях, данные относятся к отдельным битам, которые передаются по сети между компонентами. В transaction-level моделях, данных представлены в виде транзакций, гетерогенных структур, которые содержат произвольные коллекции элементов.
-Рассмотрим пакет в устройстве связи. На самом низком уровне детализации, пакет содержит бит начала и стоп-биты, заголовок, информацию исправления ошибок, размер полезной нагрузки, нагрузки, и завершитель (??????). В более абстрактной модели, только нагрузка и размер нагрузки могут быть необходимы. Другие  данные не нужны  для выполнения расчетов.
+Рассмотрим пакет в устройстве связи. На самом низком уровне детализации, пакет содержит бит начала и стоп-биты, заголовок, информацию исправления ошибок, размер передаваемых данных, данные, и пакет остановки передачи(последний пакет - trailer). В более абстрактной модели, только данные и размер данные могут быть необходимы. Другие  данные не нужны  для выполнения расчетов.
 '''Абстракция функций.''' Функция модели является набором всех операций, которая она делать на каждое событие. Абстрагирование функций уменьшает этот набор или заменяет его более простыми вычислениями. Например, в ALU, вы можете выбрать использование родной операции умножении поставляемой в язык моделирования, вместо кодирования  a shift-and-add алгоритма умножения. Последний может быть частью реализации, но на более высоком уровне, детали a shift-and-add - неважны. Базовые элементы, которые являются частью языка, определяет, как вы можете абстрагировать функцию. В gate-level  языке, например, можно создавать сложные поведения, начиная с логических элементов. В RTL языка, построение  поведения основывается на арифметических и логических операциях над регистрами. В TLM, вы реализуете функциональность схемы с помощью вызовов функций произвольной сложности.

@@ Строка 13: / Строка 13: @@
-RTL моделирование использует дискретную модель времени. Связь между процессами осуществляется с помощью сетки ( цепи), и процесс активации происходит при изменении значения во входной сети ( цепи).
+RTL моделирование использует дискретную модель времени. Связь между процессами осуществляется с помощью сетки (цепи), и процесс активации происходит при изменении значения во входной сети (цепи).
 Для сравнения, transaction-level модели (моделирующей схемы) могут быть синхронизированы или не синхронизированы и использовать шину для обмена данными между процессами. Вместо того чтобы посылать отдельные биты туда и обратно, процессы общаются, посылая транзакции друг  другу посредством вызова функций.  Мир TLM включает в себя ряд моделей(моделирующих схем) вычислений с различным временем, системами связи и процессами активации моделей (моделирующей схемы). В каждом конкретном случае, содержание связей находится на более высоком уровне абстракции, чем отдельные биты. Таким образом, transaction-level модель находится на более высоком уровне абстракции (более абстрактна), чем RTL модель. Объединяя понятия абстракции и модели (моделирующей схемы) вычислений, видно, что создание абстрактных моделей означает абстрагирование времени, данных и функций.
@@ Строка 23: / Строка 23: @@
 '''Абстракция функций.''' Функция модели является набором всех операций, которая она делать на каждое событие. Абстрагирование функций уменьшает этот набор или заменяет его более простыми вычислениями. Например, в ALU, вы можете выбрать использование родной операции умножении поставляемой в язык моделирования, вместо кодирования  a shift-and-add алгоритма умножения. Последний может быть частью реализации, но на более высоком уровне, детали a shift-and-add - неважны. Базовые элементы, которые являются частью языка, определяет, как вы можете абстрагировать функцию. В gate-level  языке, например, можно создавать сложные поведения, начиная с логических элементов. В RTL языка, построение  поведения основывается на арифметических и логических операциях над регистрами. В TLM, вы реализуете функциональность схемы с помощью вызовов функций произвольной сложности.
 Для целей функциональной верификации, RTL самый низкий уровень абстракции, который мы должны рассмотреть. С синтезаторы могут эффективно конвертировать RTL в логические элементы, нам не нужно затрагивать  более низкий уровень детализации.
 ==  Определение транзакции ==

@@ Строка 170: / Строка 170: @@
 === Get ===
-Дополнением к put является get. В этом устройстве, инициатор получает транзакции от цели. Поток управления такой же, от инициатора к цели, но направление потока данных  обратное. Инициатор получает транзакции от цели. В этом случае consumer является инициатором, producer - целью. Consumer  инициирует вызов producer для получения транзакции.
+Дополнением к ''put'' является ''get''. В этой конфигурации, инициатор получает транзакции от цели. Поток управления такой же как у ''put'' — от инициатора к цели, но направление потока данных обратное. Инициатор получает транзакции от цели. В этом случае ''consumer'' является инициатором (блок А), ''producer'' — целью (блок В). ''Consumer'' инициирует вызов ''producer'' для получения транзакции.
 [[Файл:66.png]]
-Рисунок 3-3 очень похож на рисунок 3-2. Разница лишь в том, что здесь стрелка от цели к инициатору, а не наоборот. Это означает, что потоки данных от цели к инициатору. Ниже SystemVerilog consumer (инициатор).
+Рисунок 3-3 очень похож на рисунок 3-2. Разница лишь в том, что здесь стрелка от цели к инициатору, а не наоборот. Это означает, что потоки данных идут от цели к инициатору. Ниже SystemVerilog consumer (инициатор, блок А).
 <big><source lang="verilog">62 class consumer;
@@ Строка 191: / Строка 191: @@
 file: 03_tlm/02_get/get.sv</source></big>
-consumer имеет задачу, run(), которая выполняется  10 раз, чтобы получить 10 транзакций. Producer   как в put  примере, consumer имеет здесь порт. Кроме того, как в put  примере, порт ссылается на истинно виртуальный интерфейс, в данном случае
+Класс ''consumer'' имеет задачу, ''run()'', в которой выполняется 10 транзакций. Так же как класс ''producer'' в конфигурации ''put'', в данном примере класс ''consumer'' имеет порт. Кроме того, как в ''put''  примере, порт ссылается на истинно (pure) виртуальный интерфейс, в данном случае он называется ''get_if''.
 он называется get_if.
 <big><source lang="verilog">41 virtual class get_if;
@@ Строка 199: / Строка 198: @@
 file: 03_tlm/02_get/get.sv</source>
 </big>
 <big><source lang="verilog">48 class producer extends get_if;

← Предыдущая		Версия 08:11, 14 марта 2013
Строка 550:		Строка 550:

	Функция connect() создает связь между портами на producer и consumer и соответствующего экспорта на FIFO. Run () отвечает за контроль выполнения testbench.		Функция connect() создает связь между портами на producer и consumer и соответствующего экспорта на FIFO. Run () отвечает за контроль выполнения testbench.
		+
		+
		+	== Формирование Transaction-Level подключений ==
		+
		+
		+	Для формирования transaction-level подключения, необходимо указать три элемента: поток управления, поток данных, а также тип данных транзакций. Объявление подключения как порта или export определяет поток управления – поток управления движется(???) от порта к export. То есть, порт инициирует деятельность и export реагирует на нее. Интерфейс определяет поток данных. put интерфейс означает, что данных движутся от инициатора (левый борт) к цели ( сторона export), get интерфейс показывает, что данные идут от цели к инициатору, а transport или запрос-ответ, интерфейс указывает двунаправленность потоков данных.
		+
		+	Мы объявляем put_port как порт, поэтому мы знаем, что устройство, в котором этот порт объявлен является инициатором. Тип интерфейса - tlm_nonblocking_put_if <>, который является одним put интерфейсов, определенных в библиотеке TLM. Этот порт выход для объектов данных. Наконец, тип данных отправленного объекта является trans.
		+
		+	Использование OVM в SystemVerilog, объявление портов и export охватывает эти три элемента. Вот пример:
		+
		+	<big><source lang="verilog">ovm_nonblocking_put_port #(trans) put_port;</source></big>
		+
		+	Суффикс тип объекта _port, указывает, что это порт. Exports используют суффикс _export.Тип интерфейса определяется по имени между префиксом ovm_ и _port или суффиксом _export. В этом случае, это имя nonblocking_put, который относится к tlm_nonblocking_put_if.
		+	Мы рассмотрели producer и consumer, каждый из которых использует блокирующие задачи для получения и отправки транзакций. Блокирующие задачи находятся в FIFO, объект, который выступает в качестве посредника между двумя компонентами, в другом случае известный как канал. Канал передает данные между двумя компонентами, и служит синхронизатором. Ввод FIFO между двумя компонентами для буферизации и синхронизации передачи является common idiom в TLM.
		+
		+	== Заключение ==
		+
		+	Put, get и transport являются основными средствами для синхронизации параллельных процессов и для обмена информацией между эти процессы на уровне transaction-level. Эти идеи широко используются в OVM для построения transaction-level testbenches. В следующей главе мы будем углубляться в ОВМ, чтобы показать, как строить произвольные иерархии компонент верификации, основанных на классах , связанных с помощью transaction-level интерфейсов.

← Предыдущая		Версия 13:25, 13 марта 2013
Строка 439:		Строка 439:

	Блокирующие интерфейсы полезны для работы с двумя компонентами синхронно. Вызовы блокируются до тех пор, пока запрошенная операция выполняется, не смотря на то, сколько это потребует времени. С другой стороны, неблокирующие интерфейсы полезны при асинхронной передаче данных. Они не ждут и могут быть использованы для опроса целей, как в приведенном примере.		Блокирующие интерфейсы полезны для работы с двумя компонентами синхронно. Вызовы блокируются до тех пор, пока запрошенная операция выполняется, не смотря на то, сколько это потребует времени. С другой стороны, неблокирующие интерфейсы полезны при асинхронной передаче данных. Они не ждут и могут быть использованы для опроса целей, как в приведенном примере.
		+
		+
		+
		+	== Изоляция компонент с помощью каналов ==
		+
		+
		+	В предыдущем разделе обсуждались простые механизмы для перемещения транзакций между двумя процессами. В каждом, инициатор и цель были сильно синхронизированы вызовом транзакции интерфейса. В этом разделе мы рассмотрим случай, когда инициатор и цель менее тесно связаны, это можно сделать с помощью канала, в этом случае FIFO, для управления синхронизацией между инициатором и целью, а не полагаться на взаимную синхронизацию самих компонент. Здесь мы имеем две компоненты, инициатор А и цель B, а также FIFO, соединяющий две компоненты.
		+
		+
		+	[[Файл:68.png]]
		+
		+
		+	В предыдущих примерах, одна компонента имела порт, а другая export. Компонента с портом обращается к компоненте с export. Здесь оба А и В имеют порты. Вместо того, чтобы инициатор обращался к непосредственно к цели, теперь у нас есть инициатор и цель, которые обращаются к каналу FIFO. Канал обеспечивает функции, необходимые как инициатору, так и цели.
		+
		+	Инициатор использует блокирующий put() для отправки транзакций на FIFO, и цель использует блокирующий get() для получения транзакций с FIFO. FIFO хранит транзакции и служит в качестве синхронизатора. Инициатор может помещать транзакции в FIFO, пока он не заполнится . Так как инициатора использует блокировку Put (), инициатор процесса будет блокироваться, когда FIFO заполнен. Кроме того, цель использует блокирующий get() и будет блокироваться, когда FIFO является пустым. По сути, producer в этом примере, как producer в блокирующем put примере, и consumer, как consumer в блокирующем get. FIFO replaces цели и предоставляет задачи, необходимые для удовлетворения требований интерфейса, созданные портами producer и consumer.
		+
		+	Давайте посмотрим на код. Это первый пример, который использует OVM библиотеки. OVM библиотека включает в себя FIFO, называемый tlm_fifo, который является параметризованным классом с различными интерфейсами для поддержки блокирующих и неблокирующий операций.
		+
		+	В этом случае producer выглядит как producer в блокирующем пут примере. Он имеет процесс, run(), который выполняется 10 раз, генерирует 10 случайных значений и
		+	отправив их к цели через put_port.
		+
		+	<big><source lang="verilog">42 class producer extends ovm_component;
		+	43
		+	44 ovm_blocking_put_port#(int) put_port;
		+	45
		+	46 function new(string name, ovm_component p = null);
		+	47 super.new(name,p);
		+	48 put_port = new(“put_port”, this);
		+	49 endfunction
		+	50
		+	51 task run();
		+	52
		+	53 int randval;
		+	54 string s;
		+	55
		+	56 for(int i = 0; i < 10; i++)
		+	57 begin
		+	58 randval = $random % 100;
		+	59 $sformat(s, “sending %4d”, randval);
		+	60 ovm_report_info(“producer”, s);
		+	61 put_port.put(randval);
		+	62 end
		+	63 global_stop_request(); // OK, we’re done now
		+	64 endtask
		+	65
		+	66 endclass
		+	file: 03_tlm/05_fifo/fifo.sv
		+	</source></big>
		+
		+	Есть две вещи, на которые необходимо обратить внимание. Во-первых, компоненты, полученные из ovm_component, которая является базовым классом в библиотеке OVM, обеспечивает основные возможности для компонент. Это позволяет компонентам подключиться к иерархии названных компонент и обеспечивает процесс управления выполнения задачи. Выполнение задачи разветвляется при запуске и может быть приостановлена или возобновлена по желанию.
		+
		+	Кроме того, необходимо заметить, как put_port объявлен. В наших простых примерах выше, мы создали наш собственный истинно виртуальный интерфейс для подключения инициатора к цели. Библиотека OVM поставляет набор портов и экспорт объектов, которые являются обертками вокруг истинно виртуальных ссылок интерфейса. Порт и экспорт объектов, которые сами по себе именные компоненты, позволяют функции connect() создавать ассоциаций между ports and exports. Использование модели лучше по сравнению с использованием операторов присваивания.
		+
		+	Consumer не сильно отличается от consumer в блокирующем get примере.
		+
		+	<big><source lang="verilog">71 class consumer extends ovm_component;
		+	72
		+	73 ovm_blocking_get_port#(int) get_port;
		+	74
		+	75 function new(string name, ovm_component p = null);
		+	76 super.new(name,p);
		+	77 get_port = new(“get_port”, this);
		+	78 endfunction
		+	79
		+	80 task run();
		+	81
		+	82 int val;
		+	83 string s;
		+	84
		+	85 forever
		+	86 begin
		+	87 get_port.get(val);
		+	88 $sformat(s, “receiving %4d”, val);
		+	89 ovm_report_info(“consumer”, s);
		+	90 end
		+	91
		+	92 endtask
		+	93
		+	94 endclass
		+	file: 03_tlm/05_fifo/fifo.sv
		+	</source>
		+	</big>
		+
		+
		+	Для подключения producer, consumer и FIFO, мы используем окружающую среду. Средой служит вершина иерархии именованных компонент, и это организует построение иерархии и выполнения testbench.
		+
		+	<big><source lang="verilog">99 class env extends ovm_component;
		+	100 producer p;
		+	101 consumer c;
		+	102 tlm_fifo #(int) f;
		+	103
		+	104 function new(string name, ovm_component parent = null);
		+	105 super.new(name, parent);
		+	106 endfunction
		+	107
		+	108 function void build();
		+	109 p = new(“producer”, this);
		+	110 c = new(“consumer”, this);
		+	111 f = new(“fifo”, this);
		+	112 endfunction
		+	113
		+	114 function void connect();
		+	115 p.put_port.connect(f.blocking_put_export);
		+	116 c.get_port.connect(f.blocking_get_export);
		+	117 endfunction
		+	118
		+	119 endclass
		+	file: 03_tlm/05_fifo/fifo.sv
		+	</source></big>
		+
		+	Функция connect() создает связь между портами на producer и consumer и соответствующего экспорта на FIFO. Run () отвечает за контроль выполнения testbench.

@@ Строка 405: / Строка 405: @@
 Когда мы запускаем пример, мы видим, что не каждый вызов nb_get () успешен.
-: consumer: no randval
+<pre>4: consumer: no randval
-−
 : consumer: no randval
 : producer: sending -99
 : consumer: receiving -99
 : consumer: no randval
 : producer: sending -39
 : consumer: receiving -39
 : consumer: no randval
 : producer: sending -9
 : consumer: receiving -9
 : consumer: no randval
 : consumer: no randval
 : producer: sending 57
 : consumer: receiving 57
 : consumer: no randval
 : producer: sending -71
 : consumer: receiving -71
 : consumer: no randval
 : producer: sending -14
 : consumer: receiving -14
 : consumer: no randval
 : consumer: no randval
 : producer: sending 29
 : consumer: receiving 29
 : consumer: no randval
 : producer: sending 18
 : consumer: receiving 18
 : consumer: no randval
+</pre>
 Блокировать get конфигурацию смог только один процесс - consumer, который постоянно обращался с запросом к producer, чтобы тот отправил новое значение. Неблокирующий  вариант состоит из двух этапов: consumer регулярно опрашивает producer, чтобы получить новое значение, и producer генерирует новые значения асинхронно по отношению к consumer. Наши неблокирующий producer генерирует доступное случайное значение каждые 7 нс. Он ждет 5 нс, а затем создает новое значение и новое значение действительно в течение 2 нс. Флаг  rand_avail устанавливается, когда  случайное значение доступно и сбрасывается в противном случае.
 Реализация nb_get () в этом примере должна проверить rand_avail  есть ли  что отправить. Если нет, то она возвращает 0, чтобы указать, что запрос не удался. Если есть что-то, то он посылает его и возвращает 1, чтобы показать успех.
-Блокирующие интерфейсы полезны для работы с двумя компонентами синхронно. Вызовы блокируются до тех пор, пока запрошенная операция выполниться, не смотря на то, сколько это может занять. С другой стороны, неблокирующие интерфейсы полезны для использования в асинхронном режиме. Они не ждут и могут быть использованы для опроса цели, как в приведенном примере.
+Блокирующие интерфейсы полезны для работы с двумя компонентами синхронно. Вызовы блокируются до тех пор, пока запрошенная операция выполняется, не смотря на то, сколько это потребует времени. С другой стороны, неблокирующие интерфейсы полезны при асинхронной передаче данных. Они не ждут и могут быть использованы для опроса целей, как в приведенном примере.