OVM/OVM методология/Механика OVM - История изменений

Anastasiya в 10:35, 1 апреля 2013

2013-04-01T10:35:31Z

Anastasiya в 08:21, 28 марта 2013

2013-03-28T08:21:21Z

Внесённые изменения

Vidokq: /* Factory(Фабрика) */

2013-03-25T22:10:54Z

‎Factory(Фабрика)

Vidokq: /* Как работает Фабрика */

2013-03-25T21:59:22Z

‎Как работает Фабрика

Vidokq: /* Фабрика */

2013-03-25T21:49:32Z

‎Фабрика

Anastasiya в 11:06, 25 марта 2013

2013-03-25T11:06:20Z

Внесённые изменения

Anastasiya в 08:55, 25 марта 2013

2013-03-25T08:55:15Z

Vidokq: /* Примечание для пользователей AVM */

2013-03-21T23:11:25Z

‎Примечание для пользователей AVM

Vidokq: /* Подключение через Иерархию */

2013-03-21T22:59:55Z

‎Подключение через Иерархию

Vidokq: /* Connectivity */

2013-03-21T22:38:12Z

‎Connectivity

← Предыдущая		Версия 10:35, 1 апреля 2013
Строка 893:		Строка 893:

	Недостатком использования type-based фабрики является то, что нет никакого способа поиска объекта строки. Это потому, что без второго аргумента в ovm_object_registry typedef, нет названия, под которым хранится объект. При первом использовании type-based фабрики, может ввести в замешательство, что нет доступного имени. Вы быстро обнаружите, что строка имени не является действительно необходимой. В тех случаях, когда необходимо имя, например, когда вы получаете имена объектов из пользовательского ввода, тогда можно использовать string-based фабрику.		Недостатком использования type-based фабрики является то, что нет никакого способа поиска объекта строки. Это потому, что без второго аргумента в ovm_object_registry typedef, нет названия, под которым хранится объект. При первом использовании type-based фабрики, может ввести в замешательство, что нет доступного имени. Вы быстро обнаружите, что строка имени не является действительно необходимой. В тех случаях, когда необходимо имя, например, когда вы получаете имена объектов из пользовательского ввода, тогда можно использовать string-based фабрику.
		+
		+
		+
		+
		+	== Прекращение работы Testbench ==
		+
		+
		+	Самым простым способом прекратить выполнение testbench ОВМ является вызов глобальной функции global_stop_request (). Это запросы, которые закрывают testbench. Если нет никаких причин для закрытия, то выполнение testbench будет приостановлено. global_stop_request () представитель ovm_top.stop_request (). Эти два формы семантически эквивалентны.
		+	Какие причины будут для того, чтобы не допустить прекращения работы? Каждая компонента имеет виртуальные задачу stop(). Когда вы вызываете global_stop_request (), эта задача вызывается для каждой компоненты, enable_stop_request устанавливается в 1.
		+	Когда все задачи остановки выполнились, testbench прекращает работу.
		+
		+	Задача остановки может быть использована для очистки информации, скажите DUT, чтобы прекратил выполнение, служил в качестве объекта завершения работы, или что-нибудь еще вы хотели бы сделать до завершения выполняемой фазы. Поскольку это задача, stop()может потреблять время. stop() задача может запретить выключение блокировкой. она может подождать выполнения некоторого условия или задержки на фиксированное время. stop()задача случит для прекращения(отмены) выполнения запроса. When stop() returns, it allows the request to be granted.
		+
		+	В следующем примере показано, как работает механизм остановки. Этот пример содержит из двух producers транзакций для отправки их к получателю через FIFO. Каждый producers работает независимо от других. Мы хотим убедиться, что оба producers закончили свою работу. Когда один заканчивает, другой продолжает до тех пор, пока он не выполнит свою работу до конца.
		+
		+	[[Файл:81.png]]
		+
		+
		+	В build() функции для топ-уровня среды, в дополнение к экземплярам различных компонент, мы настроим различное число итераций для каждого producer. Так как число итераций для каждого из них разные, один producer завершится перед другими.
		+
		+	<big><source lang="cpp">127 function void build();
		+	128 set_config_int(“producer1”, “iterations”, 5);
		+	129 set_config_int(“producer2”, “iterations”, 9);
		+	130 p1 = new(“producer1”, this);
		+	131 p2 = new(“producer2”, this);
		+	132 c = new(“consumer”, this);
		+	133 f = new(“fifo”, this);
		+	134 endfunction
		+	file: 04_OVM_mechanics/09_shutdown/top.sv</source></big>
		+
		+	Мы хотим, чтобы testbench завершил выполнение в определенном порядке, когда все необходимая работа будет сделана, но мы не хотим закрывать преждевременно, когда первый producer завершит работу. Мы используем механизм остановки для достижения этой цели. Каждый producer имеет задачу остановки, которая ждет, пока done станет 1.
		+
		+	<big><source lang="cpp">77 task stop(string ph_name);
		+	78 ovm_report_info(“stop”, “initating stop”);
		+	79 wait(done == 1);
		+	80 ovm_report_info(“stop”, “shutting down...”);
		+	81 endtask
		+	file: 04_OVM_mechanics/09_shutdown/top.sv</source></big>
		+
		+
		+	Ph_name аргумент содержит имя фазs, в которой вызывается stop() . Хотя по умолчанию есть только на task-based фаза, run() есть возможность произвольно добавить больше task-based фаз (и функций на основе фаз, тоже). Остановка механизм запроса работает во всех task-based фазах, а вызов global_stop_request () работает в текущей task-based фазе. Это приводит к вызову stop(). Так как только одна задача с именем stop возможна в каждой компоненте, ph_name аргумент определяет фазу, в которой она была вызвана. Вы можете использовать это для изменения поведения stop() на основе имени task-based фазы.
		+	Для остановки механизма запроса, мы должны отменить его, установив enable_stop_interrupt в 1. Мы делаем это в конструкторе компоненты.
		+
		+	<big><source lang="cpp">42 function new(string name, ovm_component p = null);
		+	43 super.new(name,p);
		+	44 iterations = 10; // default value
		+	45 done = 0;
		+	46 enable_stop_interrupt = 1;
		+	47 endfunction
		+	</source></big>
		+
		+	Основной цикл producer прост. Каждая итерация цикла генерирует случайное число и передает его через выходной порт к consumer. В следующем примере, когда цикл завершается, мы устанавливаем done в 1, который запускает задачу stop.
		+
		+	<big><source lang="cpp">66 for(int i = 0; i < iterations; i++) begin
		+	67 randval = $random % 100;
		+	68 $sformat(s, “sending %4d”, randval);
		+	69 ovm_report_info(“producer”, s);
		+	70 put_port.put(randval);
		+	71 end
		+	72
		+	73 done = 1;
		+	file: 04_OVM_mechanics/09_shutdown/top.sv
		+	</source></big>
		+
		+	Заключительная часть - задачи run верхнего уровня среды:
		+
		+	<big><source lang="cpp">142 task run();
		+	143 ovm_report_info(“run”, “start”);
		+	144 global_stop_request();
		+	145 endtask
		+	file: 04_OVM_mechanics/09_shutdown/top.sv
		+	</source></big>
		+
		+	После запуска, задача немедленно вызывает global_stop_request (), которая
		+	приводит к вызову задачи stop() в producers (потому что enable_stop_interrupt установлен в 1 в каждой). В свою очередь, каждый producer блокируется до соответствующего значения флага done. Когда producer с наименьшими числом итераций заканчивает свое выполнение, о it triggers its local done flag and its stop task returns. However, because there are outstanding blocked stop tasks, the simulation continues. Только, когда все задачи stop будут выполнены моделирование прекращается.
		+
		+	=== Timeout ===
		+
		+	Вполне возможно, что моделирование может остановиться, когда ошибка в stop задаче препятствует возвращению значения, заблокированный вызов никогда не разблокируется или бесконечный цикл никогда не остановится. Для предотвращения моделирования от зависания на неопределенный срок, OVM предоставляет два timeout механизма. Однин для задач фаз, а другой для stop задачи.
		+	ovm_root содержит две переменные, phase_timeout и stop_timeout. Их типа это Verilog тип tim, и их значения могут быть установлены set_global_timeout и set_global_stop_timeout. Значение по умолчанию переменных 0, что означает тайм-аут отключен.
		+
		+	Когда задача на основе фаз выполняется, такие как Run (), и имеет phase_timeout был установлен в значение больше нуля, то отдельный процесс сторожевой породил, который просто ждет, пока тайм-аута. fork/join конструкция используется для создания этих задач, поэтому, если run задачи завершились до тайм-аута, то тайм-аут игнорируется. С другой стороны, если тайм-аут истекает первым, то он будет инициировать отключение. Фрагмент кода в ovm_root :: run_global_phase () управляющий задачей run и выключением заключается в следующем:
		+
		+	<big><source lang="cpp">fork : task_based_phase
		+	m_stop_process();
		+	begin
		+	m_do_phase_all(this,m_curr_phase);
		+	wait fork;
		+	end
		+	#timeout ovm_report_error("TIMOUT",
		+	$psprintf("Watchdog timeout of '%0t' expired.", timeout));
		+	join_any
		+	disable task_based_phase;
		+	</source></big>
		+
		+	fork состоит из трех процессов, в том числе m_stop_process (), который управляет остановкой запросов; m_do_phase_all (), который приводит к выполнению всех задач run выполняться параллельно, и тайм-аут.
		+	Выражение disable после join_any вызывает оставшиеся процессы будут убиты. Так что, если тайм-аут истекает первым, то затем процессы stop и run задача будут убиты. Если run задач завершится первой, то процессы stop и timeout будут убиты. Наконец, если global_stop_request () вызывается, вызывается stop задачи, все они выполняются до конца, а затем stop процесс завершится первым и run задача и timeout будут убиты.

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


−	~~The code makes heavy use of the double-colon~~ (::) ~~scope operator. Он~~ используется для обращения к статической функции в factory и в wrapper#(). Сначала, мы получаем уникальный экземпляр структуры данных фабрики, затем создаем экземпляр объекта family_base. family_base :: type_id :: get_type() является статической ~~функции~~ внутри ~~оболочки специализации для~~ family_base. Мы проверяем, что экземпляр family_base создается путем вызова print(). Далее, определяем переопределение B для family_base. Опять же, мы создаем экземпляр family_base. На этот раз, так как переопределение сейчас находится на месте, вместо того, чтобы получить экземпляр family_base, мы получаем экземпляр B.	+	При написании кода интенсивно используют оператор (::), он используется для обращения к статической функции в factory и в wrapper#(). Сначала, мы получаем уникальный экземпляр структуры данных фабрики, затем создаем экземпляр объекта family_base. family_base :: type_id :: get_type() является статической функцией внутри специально обвернутого family_base. Мы проверяем, что экземпляр family_base создается путем вызова print(). Далее, определяем переопределение B для family_base. Опять же, мы создаем экземпляр family_base. На этот раз, так как переопределение сейчас находится на месте, вместо того, чтобы получить экземпляр family_base, мы получаем экземпляр B.

	Наша фабрика не содержит все функциональные возможности фабрики, реализованной в OVM. Фабрика OVM обеспечивает отображение строк (имен) в типы. Это позволяет переопределить цепочки, в то время, как фабрика этого не делает. Например, если B переопределяет А и C переопределяет B, когда вы просите экземпляр А, вы получите экземпляр C. Фабрика OVM поддерживает два начальных базовых класса, ovm_object и ovm_component для зарегистрированных объектов, и метод create() для обоих, в то время, фабрика имеет только один первичный класс, object_base.		Наша фабрика не содержит все функциональные возможности фабрики, реализованной в OVM. Фабрика OVM обеспечивает отображение строк (имен) в типы. Это позволяет переопределить цепочки, в то время, как фабрика этого не делает. Например, если B переопределяет А и C переопределяет B, когда вы просите экземпляр А, вы получите экземпляр C. Фабрика OVM поддерживает два начальных базовых класса, ovm_object и ovm_component для зарегистрированных объектов, и метод create() для обоих, в то время, фабрика имеет только один первичный класс, object_base.

@@ Строка 618: / Строка 618: @@
-<big><source lang="cpp">46 class object_base;
+<big><source lang="verilog">46 class object_base;
 virtual function void print();
 $display(“object_base”);
@@ Строка 634: / Строка 634: @@
 factory - это singleton, то есть его конструктор локальный, и он содержит статическую ссылку  на самого себя. Единственный способ создать экземпляр factory является вызов factory::get(). factory содержит ассоциативный массив, который отображает запрашиваемые типы wrapper_base в   переопределенные типы wrapper_base.
-<big><source lang="cpp">73 class factory;
+<big><source lang="verilog">73 class factory;
 static factory f;
@@ Строка 675: / Строка 675: @@
-<big><source lang="cpp">118 class wrapper #(type T=object_base) extends wrapper_base;
+<big><source lang="verilog">118 class wrapper #(type T=object_base) extends wrapper_base;
 typedef wrapper#(T) this_type;
@@ Строка 721: / Строка 721: @@
-<big><source lang="cpp">static wrapper#(T) type_handle = get_type();</source></big>
+<big><source lang="verilog">static wrapper#(T) type_handle = get_type();</source></big>
@@ Строка 728: / Строка 728: @@
-<big><source lang="cpp">typedef wrapper#(some_type) type_id;</source>
+<big><source lang="verilog">typedef wrapper#(some_type) type_id;</source>
 </big>
@@ Строка 741: / Строка 741: @@
-<big><source lang="cpp">169 class A extends family_base;
+<big><source lang="verilog">169 class A extends family_base;
 typedef wrapper#(A) type_id;
@@ Строка 754: / Строка 754: @@
-<big><source lang="cpp">206 function void run();
+<big><source lang="verilog">206 function void run();
 f = factory::get();

@@ Строка 594: / Строка 594: @@
 В цикле, где мы строим masters, ссылки на каждого нового master сохраняются в той же переменной, m. Каждый новый master заменяет предыдущий. Мы не используем массив для хранения всех компонент. В каждой итерации, мы используем $ sformat, чтобы создать уникальное имя. Конструктор, new(), вызывает super.new (), конструктор в ovm_component базовом классе, который отвечает за вставку вновь созданную компоненту потомка в родительский список. Нет  необходимости явно сохранять компоненту, потому что родительская компонента сделает это за нас. Цикл для создания slaves организован таким же образом.
-== Фабрика ==
+== Factory(Фабрика) ==
-Структура testbench определяется организацией компонент в иерархии и то, как эти объекты связаны между собой. Поведение testbench определяется процедурным кодом в фазе callbacks—build, connect, run и так далее. Есть моменты, когда это необходимо изменить поведение или часть структуры внешне, то есть во время выполнения, не касаясь, кода testbench. Например, чтобы ввести ошибку в систему, вы можете заменить обычный драйвер  драйвером с ошибкой, который умышленно вводит ошибки. Вместо повторного кодирования окружающей среды для использования другого драйвера, вы можете использовать фабрику, чтобы сделать замену автоматически.
+Структура testbench определяется организацией компонент в иерархии и то, как эти объекты связаны между собой. Поведение testbench определяется процедурным кодом в фазе callbacks—build, connect, run и так далее. Есть моменты, когда это необходимо изменить поведение или часть структуры извне(снаружи), то есть во время выполнения, не касаясь, кода testbench. Например, чтобы ввести ошибку в систему, вы можете заменить обычный драйвер  драйвером с ошибкой, который умышленно вводит ошибки. Вместо повторного кодирования окружающей среды для использования другого драйвера, вы можете использовать factory, чтобы сделать замену автоматически.
-Фабрика обеспечивает средства для замены одного объекта на другой без использования текстового редактора для изменения testbench. Вместо создания объект с помощью new(), вы вызываете функцию create  фабрики. Фабрика  хранит список зарегистрированных объектов и, при необходимости, набор переопределения связанный с каждой из них. При создании объекта с помощью фабрики, список переопределения проверяется на наличие такого объекта. Если он есть, то переопределенный объект возвращается. В противном случае, зарегистрированный объект возвращается.
+Factory обеспечивает средства для замены одного объекта на другой без использования текстового редактора для изменения testbench. Вместо создания объект с помощью new(), вы вызываете функцию create  из factory. Factory  хранит список зарегистрированных объектов и, при необходимости, набор переопределения связанный с каждой из них. При создании объекта с помощью factory, список переопределения проверяется на наличие такого объекта. Если он есть, то переопределенный объект возвращается. В противном случае, зарегистрированный объект возвращается.
-Фабрика  является OVM структурой данных. Она  глобальна в области видимости, и только один элемент может существовать  (то есть, это singleton). Она служит в качестве полиморфных конструкторов, одна функция, которая позволяет создавать различные объекты. Она  обеспечивает средства для регистрации объектов, и для их переопределения. Объекты, зарегистрированные как переопределения,  должны быть производным от объекта, от которого они переопределялись. Для того, чтобы одна функция возвращала несколько объектов, каждый из этих объектов должны быть получен от общего базового класса.
+Factory  является OVM структурой данных. Она  глобальна в области видимости, и только один элемент factory может существовать  (то есть, это singleton). Она служит в качестве полиморфных конструкторов, одна функция, которая позволяет создавать различные объекты. Она  обеспечивает средства для регистрации объектов, и для их переопределения. Объекты, зарегистрированные как переопределения,  должны быть производным от объекта, от которого они переопределялись. Для того, чтобы одна функция возвращала несколько объектов, каждый из этих объектов должны быть получен от общего базового класса.
-Важным компонентом фабрики является оболочка, класс, который описывает объект, который мы хотим создать с  помощью фабрики. Структура данных фабрики основывается на таблице оболочек, проиндексированной по ключу. Оболочка имеет функцию create(), которая обращается к  конструктору обернутого объекта.
+Важным компонентом factory является оболочка, класс, который описывает объект, который мы хотим создать с  помощью factory. Структура данных factory основывается на таблице оболочек, проиндексированной по ключу. Оболочка имеет функцию create(), которая обращается к  конструктору обернутого объекта.
-Использование фабрики состоит из трех этапов: регистрация, настройки переопределение и создание. На первом этапе необходимо зарегистрировать объект с помощью фабрики. На втором шаге, добавляется переопределение зарегистрированного объекта. На третьем этапе, вы создаете объект с помощью фабрики, который будет возвращать либо первоначально зарегистрированный объект или переопределенный, в зависимости от того, переопределение было передано в качестве  запрашиваемого объекта.
+Использование factory состоит из трех этапов: регистрация, настройки переопределение и создание. На первом этапе необходимо зарегистрировать объект с помощью factory. На втором шаге, добавляется переопределение зарегистрированного объекта. На третьем этапе, вы создаете объект с помощью factory, который будет возвращать либо первоначально зарегистрированный объект или переопределенный, в зависимости от того, переопределение было передано в качестве  запрашиваемого объекта.
-=== Как работает фабрика ===
+Factory OVM основана на структуре данных, которая  отображает необходимые типы в переопределенные. По сути, организация представляет собой ассоциативный массив типов, ключом в котором является также тип. При регистрации типа при помощи фабрики, его переопределенным типом является он сам. Таким образом, по умолчанию, когда вы запрашиваете объект этого типа, вы получаете только тип. Фабрика  также предоставляет средства для замены переопределенных типов другими типами, чтобы вы могли получить переопределенные типы, которые отличаются от зарегистрированных типов.
-−
-Термин фабрика был придуман The Gang of Four для использования в программном обеспечении в их книге Design Patterns: Elements of Reusable Object-Oriented Software. В этой книге, они определили шаблон, который они называют abstract
-factory, как интерфейс для создания семейств связанных объектов. Они определили шаблон factory method  в качестве интерфейса для создания объектов, относящихся к подклассам для определения, какой объект создавать. Фабрика OVM является комбинацией этих двух  шаблонов. Она предоставляет средства для создания семейства объектов, а также предоставляет средства для определения, какой именно объект создавать структуре данных фабрики.
-−
-Фабрика OVM основана на структуре данных, которая  отображает необходимые типы в  переопределенные. По сути, организация представляет собой ассоциативный массив типов, ключом в котором является также тип. При регистрации типа при помощи фабрики, его переопределенным типом является он сам. Таким образом, по умолчанию, когда вы запрашиваете объект этого типа, вы получаете только тип. Фабрика  также предоставляет средства для замены переопределенных типов другими типами, чтобы вы могли получить переопределенные типы, которые отличаются от зарегистрированных типов.
 [[Файл:79.png]]
 Следующий пример является сильно упрощенной фабрикой, которая показывает,  как OVM фабрика работает. Фабрика  сохраняет основные структуры OVM фабрики, но многие детали были удалены для более понятной иллюстрации. Наша фабрика реализуется в четырех классах, двух базовых классах и двух производных классах, которые делают реальную работу. Двумя базовыми классами являются object_base и wrapper_base. Все объекты, зарегистрированные в фабрике, должны быть получены (в конечном счете) от object_base, а wrapper_base является базовым классом для параметризованной обертки. Factory  - это singleton, который содержит ассоциативный массив, содержащий экземпляры обертки. Наконец, обертки являются производными от wrapper_base и параметризованными классами, которые представляют уникальные типы.

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

	Запрос на конфигурационный элемент t был успешным во всех контекстах с того момента как вызов set_config_int установил, что tдоступно во всех контекстах. Два запроса на элемент конфигурации i были успешными, и два нет. Результат получился такой потому что мы ограничены наличием i только компонентах на уровне или ниже env.c2. Компоненты на уровне или ниже c1 не могут видеть элемент конфигурации i из-за того, как мы создали базу данных конфигурации.		Запрос на конфигурационный элемент t был успешным во всех контекстах с того момента как вызов set_config_int установил, что tдоступно во всех контекстах. Два запроса на элемент конфигурации i были успешными, и два нет. Результат получился такой потому что мы ограничены наличием i только компонентах на уровне или ниже env.c2. Компоненты на уровне или ниже c1 не могут видеть элемент конфигурации i из-за того, как мы создали базу данных конфигурации.
		+
		+
		+	=== Конфигурация и фазы ===
		+
		+
		+	Теперь, когда мы знаем, что набор вызовов для размещения и извлечение элементов в конфигурацию базы данных, следующей задачей, является эффективное применение этих функции для настройки компонент. Конфигурация может быть использована для изменения поведения или структуры testbench. Как правило, поведенческий и структурный режимы определяются, когда testbench начинает работу, поэтому он является наиболее удобным местом для установки параметров конфигурации на одной из ранних стадий, таких как new, build или connect.
		+
		+	Из таблицы фаз, вы можете увидеть, что new и build являются нисходящими фазами, в то время как все остальные фазы восходящие. Так что, если вы хотите установить элемент конфигурации в базу данных на более высокий уровень контекста, чтобы он был подхвачен более низким уровнем, вы должны вызвать функцию set_config_ * в new или build фазе. Фазы выполняется дискретно, это означает, что каждая фаза выполняется до начала следующей. Вы можете установить элементы конфигурации в new или build фазу и извлекать их для использования в установке поведенческого режима или изменения топологии на этапе build. В вашей функции build, сначала вызовите get_config_ * для извлечения элементов из более высоких уровней иерархии для управления конфигурацией текущего уровня. Затем добавьте вызов set_config_ * для помещения элементов конфигурации в базу данных для использования компонентами на более низких уровнях иерархии. Наконец, используя соответствующие элементы конфигурации, обработайте компоненты. Важно вызвать get_config_ * вначале, потому, что указанная информация может влиять на значения, которые установлены на более низких уровнях иерархии.
		+
		+	Например, настройка топологии включает в себя установку параметров топологии
		+	на верхнем уровне среды, а затем применение эти параметров в различных компонентах, которые находятся ниже верхнего уровня среды в иерархии. Наш пример имеет шину, которая может иметь любое количество masters или slaves. Число masters и slaves расположены в верхнем уровне среды. Модель шину подхватывает эту конфигурационную информацию и использует ее для построения шины. В build функции верхнего уровня окружающей среды, мы создаем модель шины и настраиваем ее с числом masters и slaves.
		+
		+	<big><source lang="cpp">129 function void build();
		+	130 set_config_int(“bus”, “masters”, 4);
		+	131 set_config_int(“bus”, “slaves”, 8);
		+	132 b = new(“bus”, this);
		+	133 endfunction
		+	file: 04_OVM_mechanics/05_config_topo/top.sv</source></big>
		+
		+	Модель шины построена таким образом, что число masters и slaves не фиксировано. Вместо этого, количество приходит из конфигурации системы.
		+
		+	<big><source lang="cpp">90 function void build();
		+	91
		+	92 int unsigned i;
		+	93
		+	94 if(!get_config_int(“masters”, masters)) begin
		+	95 $sformat(msg, “\”masters\” is not in the
		+	configuration database, using default value of %0d”, masters);
		+	96 ovm_report_warning(“build”, msg);
		+	97 end
		+	98
		+	99 for(i = 0; i < masters; i++) begin
		+	100 $sformat(name, “master_%0d”, i);
		+	101 m = new(name, this);
		+	102 end
		+	103
		+	104 if(!get_config_int(“slaves”, slaves)) begin
		+	105 $sformat(msg, “\”slaves\” is not in the configuration
		+	database, using default value of %0d”, slaves);
		+	106 ovm_report_warning(“build”, msg);
		+	107 end
		+	108
		+	109 for(i = 0; i < slaves; i++) begin
		+	110 $sformat(name, “slave_%0d”, i);
		+	111 s = new(name, this);
		+	112 end
		+	113
		+	114 endfunction
		+	file: 04_OVM_mechanics/05_config_topo/top.sv
		+	</source>
		+	</big>
		+
		+	В функции build для модели шины, схема получает необходимую конфигурационную информацию, используя вызовы get_config_int. В каждом случае, Возвращаемое значение проверяется, чтобы определить, была ли получена запрошенная конфигурационная информация. Если нет, сообщение об ошибке предупреждает, что конфигурационный элемент не найден и что будет использовано значение по умолчанию. С точки зрения Best Practices, важно убедиться, что возвращается значение, проверено и выдается предупреждение, в случае ошибки. Без этой проверки, то, что используется значения по умолчанию, могло остаться незамеченным. В некоторых случаях это может быть приемлемо, в других случаях - нет. Человек, создающий модель шины не может знать всех обстоятельств, при которых модель будет использоваться. Поэтому важно сделать все возможное, чтобы модель была надежной. Проверка возвращаемых значений и выдача соответствующих сообщений является одним из способов повышения надежности модели.
		+
		+	В цикле, где мы строим masters, ссылки на каждого нового master сохраняются в той же переменной, m. Каждый новый master заменяет предыдущий. Мы не используем массив для хранения всех компонент. В каждой итерации, мы используем $ sformat, чтобы создать уникальное имя. Конструктор, new(), вызывает super.new (), конструктор в ovm_component базовом классе, который отвечает за вставку вновь созданную компоненту потомка в родительский список. Нет необходимости явно сохранять компоненту, потому что родительская компонента сделает это за нас. Цикл для создания slaves организован таким же образом.
		+
		+	== Фабрика ==
		+
		+	Структура testbench определяется организацией компонент в иерархии и то, как эти объекты связаны между собой. Поведение testbench определяется процедурным кодом в фазе callbacks—build, connect, run и так далее. Есть моменты, когда это необходимо изменить поведение или часть структуры внешне, то есть во время выполнения, не касаясь, кода testbench. Например, чтобы ввести ошибку в систему, вы можете заменить обычный драйвер драйвером с ошибкой, который умышленно вводит ошибки. Вместо повторного кодирования окружающей среды для использования другого драйвера, вы можете использовать фабрику, чтобы сделать замену автоматически.
		+
		+	Фабрика обеспечивает средства для замены одного объекта на другой без использования текстового редактора для изменения testbench. Вместо создания объект с помощью new(), вы вызываете функцию create фабрики. Фабрика хранит список зарегистрированных объектов и, при необходимости, набор переопределения связанный с каждой из них. При создании объекта с помощью фабрики, список переопределения проверяется на наличие такого объекта. Если он есть, то переопределенный объект возвращается. В противном случае, зарегистрированный объект возвращается.
		+
		+	Фабрика является OVM структурой данных. Она глобальна в области видимости, и только один элемент может существовать (то есть, это singleton). Она служит в качестве полиморфных конструкторов, одна функция, которая позволяет создавать различные объекты. Она обеспечивает средства для регистрации объектов, и для их переопределения. Объекты, зарегистрированные как переопределения, должны быть производным от объекта, от которого они переопределялись. Для того, чтобы одна функция возвращала несколько объектов, каждый из этих объектов должны быть получен от общего базового класса.
		+	Важным компонентом фабрики является оболочка, класс, который описывает объект, который мы хотим создать с помощью фабрики. Структура данных фабрики основывается на таблице оболочек, проиндексированной по ключу. Оболочка имеет функцию create(), которая обращается к конструктору обернутого объекта.
		+
		+	Использование фабрики состоит из трех этапов: регистрация, настройки переопределение и создание. На первом этапе необходимо зарегистрировать объект с помощью фабрики. На втором шаге, добавляется переопределение зарегистрированного объекта. На третьем этапе, вы создаете объект с помощью фабрики, который будет возвращать либо первоначально зарегистрированный объект или переопределенный, в зависимости от того, переопределение было передано в качестве запрашиваемого объекта.

@@ Строка 314: / Строка 314: @@
 === Примечание для пользователей AVM ===
-В AVM-3.0 соединения были сделаны аналогично: вызовом функции connect   портов и экспортов. Кроме того, export-to-export, port-to-export, и port-to-port вызовы были сделаны на разных фазах, export_connections (), Connect (), и import_connections (), соответственно. В OVM, порядок, в котором вызывается connect, не важен, он может быть вызван в любом порядке. Мы рекомендуем вам вызывать их в фазе connect()(?????????) (не следует путать с методом connect() на портов и экспортов).
+В AVM-3.0 соединения были сделаны аналогично: вызовам функции connect() из port и export. Кроме того, export-to-export, port-to-export, и port-to-port вызовы были сделаны на разных фазах, export_connections (), Connect (), и import_connections (), соответственно. В OVM, порядок, в котором вызывается connect(собственно происходит подключение), не важен, он может быть вызван в любом порядке. Мы рекомендуем вам создавать подключения в отдельных функциях и их вызов производить в нужное для вас время (к примеру можно назвать функцию connect(), не следует путать с методом connect(), который содержится в входных и выходных портах). OVM поддерживает позднее связывание, (a feature where calls to connect() only make a note that a connection is to be made..) фишка в том что соединение появится только тогда когда произведем вызов функции создания подключения. Позже, перед end_of_elaboration, notes соединения будут согласованы и выполнены. Это позволяет чище использовать модель и избавит от большинства очевидных ошибок подключение при соединении компонент. ( much more forgiving of understandable errors where connect() calls were made in the wrong order.)
 OVM поддерживает позднее связывание, a feature where calls to connect() only
-make a note that a connection is to be made.. Позже, перед end_of_elaboration, notes согласованы и выполнены соединения. Это позволяет более чистое использование модели much more forgiving of understandable errors where connect() calls were made in the wrong order.
 == Фазы ==

@@ Строка 304: / Строка 304: @@
-Для новых пользователей часто может вызвать трудности определить,  порт или экспорт необходимо подключить и какой объект является аргументом. Вы можете легко понять это, следуя потоку управления  через систему. Общее правило  заключается в том, что запрашиваемый порт вызывает connect() с помощью запрашиваемого порта или экспорта в качестве аргумента. Рисунок 4-4 показывает поток управления через иерархическую систему.
+Для новых пользователей часто может вызвать трудности определить,  порт или экспорт необходимо подключить и какой объект является аргументом. Вы можете легко понять это, следуя потоку управления  через систему. Общее правило  заключается в том, что запрашиваемый порт вызывается с помощью функции connect() и передачи в нее запрашиваемого port или export в качестве аргумента. Рисунок 4-4 показывает поток управления через иерархическую систему.
 [[Файл:72.png]]
@@ Строка 311: / Строка 311: @@
 [[Файл:73.png]]
 === Примечание для пользователей AVM ===

@@ Строка 164: / Строка 164: @@
 initiator_port.connect(target.export)
-Этот метод создает ассоциацию, или связывание, между портом и export так что порт может теперь называем задач и функций export. Для успешного соединения, типы  портов и export должны совпадать. То есть, типы интерфейсов должны быть одинаковыми, и тип объекта, передающегося в интерфейс должны быть одинаковыми.
+Этот метод создает ассоциацию, или связывание, между port и export так, что port может вызывать(запускать) задачи и функции из export. Для успешного соединения, типы  port и export должны совпадать. То есть, типы интерфейсов должны быть одинаковыми, и тип объекта, передающегося в интерфейс должны быть одинаковыми.
 === Подключение через Иерархию ===
-Как и контактами в RTL дизайне, нам нужно подключиться к портам  TLM через иерархические границы. Рисунок 4-3 использует простой дизайн, чтобы показать, как сделать эти соединения. Этот проект содержит исходную компоненту с двумя портами, которые в конечном итоге подключаются к двум экспортам. Для осуществления подключения между этими компонентами, мы должны расширить порты и экспорта на  уровень выше в иерархии.
+Как и контактами в RTL дизайне, нам нужно подключиться к портам  TLM через иерархические границы. Рисунок 4-3 использует простой дизайн, чтобы показать, как сделать эти соединения. Этот проект содержит исходную компоненту с двумя port(выходами), которые в конечном итоге подключаются к двум входам(export). Для осуществления подключения между этими компонентами, мы должны расширить port и export на  уровень выше в иерархии.
 [[Файл:71.png]]