Wiki - Вклад участника [ru]

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

2013-04-09T15:11:21Z

Anastasiya: /* */

{{OVM TOC}}
__TOC__

= =

Процесс проектирования электронной системы включает в себя последовательное замещение абстрактных идей конкретной их реализацией, пока не будет достигнуто представление, которое может быть изготовлено на кремнии. С момента появления цифровой интегральной схемы, электронные сообщества тщательно определили и кодировали абстракции, начиная с переключателей и логических элементов, для обеспечения среды в которой работает проект. RTL является примером среды, часто используемой для создания проектов. Есть много инструментов на основе RTL, которые делают ее удобной для создания проекта и его верификации.
Однако, как только проекты становятся больше и сложнее, становится все сложнее представлять их с помощью абстракции выше, чем RTL. Уровень транзакций становится популярным для создания первого представления проекта, которое может быть смоделировано и проанализировано.
В этой главе описаны основные понятия transaction-level моделирования (TLM). Модели transaction-level состоят из нескольких процессов, которые обмениваются информацией посредством транзакций.

== Абстракция ==

RTL моделирование использует дискретную модель времени. Связь между процессами осуществляется с помощью сетки (цепи), и процесс активации происходит при изменении значения во входной сети (цепи).
Для сравнения, transaction-level модели (моделирующей схемы) могут быть синхронизированы или не синхронизированы и использовать шину для обмена данными между процессами. Вместо того чтобы посылать отдельные биты туда и обратно, процессы общаются, посылая транзакции друг другу посредством вызова функций. Мир TLM включает в себя ряд моделей(моделирующих схем) вычислений с различным временем, системами связи и процессами активации моделей (моделирующей схемы). В каждом конкретном случае, содержание связей находится на более высоком уровне абстракции, чем отдельные биты. Таким образом, transaction-level модель находится на более высоком уровне абстракции (более абстрактна), чем RTL модель. Объединяя понятия абстракции и модели (моделирующей схемы) вычислений, видно, что создание абстрактных моделей означает абстрагирование времени, данных и функций.

'''Абстракция времени.''' Время абстракция в симуляторе относится к тому, насколько внутренние состояния схемы совместимы. Модели, запущенные в управляемых событиями симуляторах (например, логических симуляторах) используют дискретное представление времени, то есть события происходят в определенные моменты времени. События, как правило (хотя и не всегда) вызывают запущенный процесс. Чем больше событий происходит в симуляции, больше процессов вызывается, и с большим числом процессов происходит снижении скорости моделирования. Абстрагирование время уменьшает количество точек, где схема должна быть совместимой и общего числа событий и процессов, которые будут активированы. Например, в RTL модели, каждая сеть должна быть согласована после каждого изменения. В cycle-accurate абстракции, схема должна быть синхронизирована с синхросигналом, устраняя все события, что происходит между фронтами синхроимпульса. В transaction-level модели, состояния схемы должны быть синхронизированы в конце каждой операции, каждая из которых может охватывать много тактов.

'''Абстракция данных'''. Данные относятся к объектам, передаваемым между компонентами. В RTL моделях, данные относятся к отдельным битам, которые передаются по сети между компонентами. В transaction-level моделях, данные представлены в виде транзакций, гетерогенных структур, которые содержат произвольные коллекции элементов.
Рассмотрим пакет в устройстве связи. На самом низком уровне детализации, пакет содержит бит начала и стоп-биты, заголовок, информацию исправления ошибок, размер передаваемых данных, данные, и пакет остановки передачи(последний пакет - trailer). В более абстрактной модели, только данные и размер данных может быть необходим. Другие данные не нужны для выполнения расчетов.

'''Абстракция функций.''' Функция модели является набором всех операций, которая она делать на каждое событие. Абстрагирование функций уменьшает этот набор или заменяет его более простыми вычислениями. Например, в ALU, вы можете выбрать использование родной операции умножении поставляемой в язык моделирования, вместо кодирования a shift-and-add алгоритма умножения. Последний может быть частью реализации, но на более высоком уровне, детали a shift-and-add - неважны. Базовые элементы, которые являются частью языка, определяет, как вы можете абстрагировать функцию. В gate-level языке, например, можно создавать сложные поведения, начиная с логических элементов. В RTL языках, построение поведения основывается на арифметических и логических операциях над регистрами. В TLM, вы реализуете функциональность схемы с помощью вызовов функций произвольной сложности.

Для целей функциональной верификации, RTL самый низкий уровень абстракции, который мы должны рассмотреть. С синтезаторы могут эффективно конвертировать RTL в логические элементы, нам не нужно затрагивать более низкий уровень детализации.

== Определение транзакции ==

Для более подробного рассмотрения TLM, мы должны сделать шаг назад и определить понятие транзакции.

[[Файл:61.png]]

Это самое общее определение транзакции. Оно утверждает, что транзакция – это все, что происходит в проекте (или модуле или подсистеме проекта) между двумя точками времени. Хотя оно точное, оно является настолько общим, что не приводит к практическому применению. Более полезные определения следующие:

[[Файл:62.png]]
<blockquote>Транзакция — передача управления и данных между двумя элементами (компонентами)</blockquote>

Это аппаратно-ориентированные понятие транзакции. Когда смотришь на часть аппаратного обеспечения, вы можете легко определить элементы, между которыми передается управление или данные. В проекте с шинной архитектурой, чтение и запись на шину может быть вызвано транзакцией. В пакетной системе связи, отправка пакета представляет собой транзакцию.

Ниже третье определение:

[[Файл:63.png]]

Это определение программно-ориентированного понятия транзакции. В transaction-level модели, деятельность инициируется путем вызова функции. Вызов функции содержит параметры, которые "посылаются" (передаются) вызываемой функции, а возвращаемое значение функции содержит данные, которые возвращаются вызванной функцией. Вызванная функция может блокировать и вызвать задержку (в синхронной системе) или может вернуться (выполниться) немедленно.


== Интерфейсы ==

Прежде чем вдаваться в подробности о том, как построить transaction-level модель, мы сначала обсудим интерфейсы. Термин интерфейс используется в несколько случаях в OVM, каждый раз с немного другим смыслом. Это прискорбный факт истории, то что слово стало означать различные вещи. В большинстве случаев значение будет понятно из контекста, в котором этот термин используется. Различных применения :

* Интерфейс в SystemVerilog
* Интерфейс объекта
* Интерфейс DUT

'''Интерфейс в SystemVerilog'''. SystemVerilog предоставляет конструкцию, называемую интерфейс, который является одним из основных объектов контейнера, из которого строится проект в SystemVerilog. Мы используем виртуальные интерфейсы, которые указывают на интерфейсы для подключения module-based аппаратуры к class-based testbenches.

'''Интерфейс объекта.''' Общедоступные задачи и функции, доступные для объекта, образуют его интерфейс. Есть два небольших варианта этого значения интерфейса. Одним из них является прямой. Посмотрите на класс и определите, какие задачи и функций, доступны пользователю класса. Это его интерфейс. Другое значение состоит в ссылке на базовый класс, который определяет набор задач и функций, доступных для работы производного класса. Это значение интерфейса обычно используется в объектно-ориентированных языках, которые поддерживают множественное наследование, таких как C++ или Java. В этих языках, вы можете установить требование, что производный класс определяет функциональность, наследуемую от интерфейса базового класса.

[[Файл:64.png]]

Интерфейс print_if определяет прототипы для функций печати. Любой класс, который наследуется от print_if затем обязан осуществлять print()и sprint(). SystemVerilog не поддерживает множественное наследование, но он поддерживает истинно виртуальные интерфейсы. Истинно виртуальный интерфейс - интерфейс во втором контексте (базовый класс, который определяет набор задач и функций прототипов), который не имеет реализаций. Истинно виртуальная версия print_if выглядит следующим образом в SystemVerilog:

<big><source lang="cpp">virtual class print_if;
pure virtual function void print();
pure virtual function string sprint();
endclass</source></big>

Даже если SystemVerilog не поддерживает множественное наследование, и OVM построено на SystemVerilog, важно понять истинно виртуальные интерфейсы и наследование интерфейсов, потому что они активно используются в OVM. В частности, TLM ports and exports являются производными от интерфейса класс tlm_if_base.

'''DUT интерфейс.''' Часть аппаратуры, как правило, доступны через свои интерфейсы. В этом контексте, интерфейс состоит из контактов и протоколов используемых для связи с устройством. Например, устройство может иметь USB интерфейс.

== TLM идиомы ==

В данном разделе рассматриваются основные средства передачи транзакций между компонентами. Мы рассмотрим put, get, и transport формы связи транзакций. Эти примеры не используют библиотеку OVM, так как они предназначены для иллюстрации основных механизмов связи на transaction-level с минимальными затратами. В следующем разделе мы рассмотрим более полный пример, который использует OVM библиотека для связи.

=== Put ===
В put конфигурации, один компонент отправляет операции другому компоненту. Операция называется put. Инициатором является компонентом, который инициирует передачу, а целевой компонент, который получает результат. Используя TLM номенклатуру, мы говорим, что инициатор put транзакции цели.

[[Файл:65.png]]

Рисунок 3-2 показывает, что А предает операцию в пункт Б. Инициатор имеет порт, рисуется как квадрат, и цель имеет export, изображается в виде круга. Поток управления направлен от квадрата к кругу, то есть, А вызывает B, который содержит реализацию методов port. Стрелка показывает направление поток данных, и в этом случае, это означает, что данные будут двигаться от А до B.
Мы можем проиллюстрировать код для этих компонентов с producer и consumer. producer является инициатором и consumer является целью. Мы должны строить эти компоненты таким образом, что они не знали друг о друге априори. Чтобы сделать это, мы используем истинно виртуальный интерфейс для определения функции, который будет использоваться для передачи данных между инициатором и целью. Во-первых, давайте взглянем на SystemVerilog версию producer.

<big><source lang="verilog">46 class producer;
47
48 put_if put_port;
49
50 task run();
51
52 int randval;
53
54 for(int i=0; i<10; i++)
55 begin
56 randval = $random %100;
57 $display(“producer: sending %4d”, randval);
58 put_port.put(randval);
59 end
60
61 endtask
62
63 endclass : producer
file: 03_tlm/01_put/put.sv</source></big>

producer - это класс, который создается динамически. Он имеет два ключевых элемента, Run () задачу и put_port. Run () задача является простой задачей, которая повторяется 10 раз и передает 10 транзакций. Для простоты, наши операции являются целыми числами. На практике, транзакция может быть сколь угодно сложным объектом, таким как структура или класс.
Чтобы передать операции, producer вызывает put() на put_port. Что такое put_port? Это не порт в традиционном смысле Verilog. Это ссылка на put_if. Что такое put_if? Put_if это виртуальный интерфейс класса расположенный между инициатором (producer) и целью (consumer).

<big><source lang="verilog">39 virtual class put_if;
40 pure virtual task put(int val);
41 endclass : put_if</source></big>

put_if класс с истинно виртуальными задачами, т.е. задачами, не имеющими реализацию. Без реализации всех своих задач и функций, виртуальный класс не может быть создан сам по себе. Он должен быть базовым классом другого класса, который создается. В нашем случае, класс, производный от истинно виртуального put_if является consumer.

<big><source lang="verilog">68 class consumer extends put_if;
69 task put(int val);
70 $display(“consumer: receiving %4d”, val);
71 endtask : put
72 endclass : consumer
file: 03_tlm/01_put/put.sv
</source></big>

consumer содержит реализацию put(); истинно виртуальные задачи определены в put_if. Задача put() реализация принимает аргументы, переданные ей, и печатает их. put_if играет ключевую роль в соединении consumer и producer. Ссылка на него на стороне producer, которую мы называем порт, устанавливает требование, что должна быть реализация функций и задач интерфейса, к которому этот объект будет привязан. consumer является производным от интерфейса и, следовательно, в нем должны быть реализованы истинно виртуальные задачи, удовлетворяющие требованиям.

Модуль верхнего уровня связывающий producer и consumer.

<big><source lang="verilog">77 module top;
78
79 producer p;
80 consumer c;
81
82 initial begin
83 // instantiate producer and consumer
84 p = new();
85 c = new();
86 // connect producer and consumer
87 // through the put_if interface class
88 p.put_port = c;
89 p.run();
90 end
91 endmodule : top
file: 03_tlm/01_put/put.sv</source></big>

Обратите внимание, что оператор присваивания:

<big><source lang="verilog">88 p.put_port = c;</source></big>

Он образует связь между producer и consumer. Когда new() вызывается на р, чтобы создать новый экземпляр producer, член put_port не имеет значения. Во время выполнения произойдет ошибка, если put_port. put () вызывается до связи назначения. Назначение С к p.put_port дает ссылку для consumer, который содержит реализацию задачи put() интерфейса.

=== Get ===

Дополнением к ''put'' является ''get''. В этой конфигурации, инициатор получает транзакции от цели. Поток управления такой же как у ''put'' — от инициатора к цели, но направление потока данных обратное. Инициатор получает транзакции от цели. В этом случае ''consumer'' является инициатором (блок А), ''producer'' — целью (блок В). ''Consumer'' инициирует вызов ''producer'' для получения транзакции.

[[Файл:66.png]]

Рисунок 3-3 очень похож на рисунок 3-2. Разница лишь в том, что здесь стрелка от цели к инициатору, а не наоборот. Это означает, что потоки данных идут от цели к инициатору. Ниже SystemVerilog consumer (инициатор, блок А).

<big><source lang="verilog">62 class consumer;
63
64 get_if get_port;
65
66 task run();
67 int randval;
68 for(int i=0; i<10; i++)
69 begin
70 get_port.get(randval);
71 $display(“consumer: receiving %4d”, randval);
72 end
73 endtask
74 endclass
file: 03_tlm/02_get/get.sv</source></big>

Класс ''consumer'' имеет задачу, ''run()'', в которой выполняется 10 транзакций. Так же как класс ''producer'' в конфигурации ''put'', в данном примере класс ''consumer'' имеет порт. Кроме того, как в ''put'' примере, порт ссылается на истинно (pure) виртуальный интерфейс, в данном случае он называется ''get_if''.

<big><source lang="verilog">41 virtual class get_if;
42 pure virtual task get(output int t);
43 endclass : get_if
file: 03_tlm/02_get/get.sv</source>
</big>

''get_if'' является истинно виртуальным интерфейсным классом, который определяет функцию get(). Цель (producer) строится аналогично, как и цель в put примере. Она содержит реализацию функции интерфейса. Этот producer генерирует случайное число между 0 и 99.

<big><source lang="verilog">48 class producer extends get_if;
49
50 task get(output int t);
51 int randval;
52 randval = $random % 100;
53 $display(“producer: sending %4d”, randval);
54 t = randval;
55 endtask
56
57 endclass : producer
file: 03_tlm/02_get/get.sv</source></big>

Связи на высшем уровне будут выглядеть очень похожими.

<big><source lang="verilog">79 module top;
80
81 producer p;
82 consumer c;
83
84 initial begin
85 // instantiate producer and consumer
86 p = new();
87 c = new();
88 // connect producer and consumer through the get_if
89 // interface class
90 c.get_port = p;
91 c.run();
92 end
93 endmodule : top
file: 03_tlm/02_get/get.sv</source></big>

После создания объектов producer и consumer, используя операцию new(), два объекта будут соединяться с помощью связей назначения.

=== Transport ===

Transport является двунаправленным интерфейсом. Интерфейс обеспечивает передачу транзакций от инициатора к цели и от цели обратно к инициатору. Как правило, мы используем этот механизм, чтобы смоделировать запрос-ответ протоколы. Когда речь идет о компонентах с двунаправленным интерфейсов, мы используем термины master (ведущего) и slave (ведомого), а не инициатор и цель.

[[Файл:67.png]]

master (A) делает и put и get за один вызов функции. Как мы видели в предыдущих примерах, put() и get() принимают один аргумент, аргумент они помещают или извлекают. Тем не менее, функция transport() имеет два аргумента, запрос и ответ. Она посылает запрос и возвращает ответ. slave (B) принимает запрос и возвращает ответ.

Давайте сначала посмотрим на истинно виртуальный интерфейс.

<big><source lang="verilog">37 virtual class transport_if;
38 pure virtual task transport(input int request,
39 output int response);
40 endclass : transport_if
file: 03_tlm/03_transport/transport.sv</source></big>

Интерфейс содержит одну функцию, transport(), которая принимает два аргумента: запрос, который передается цели и ответ, который возвращается инициатору.

Master вызывает transport(), создает запрос и отправляет его slave, используя transport. Он обрабатывает ответ, который возвращается.

<big><source lang="verilog">45 class master;
46
47 transport_if port;
48
49 task run();
50
51 int request;
52 int response;
53
54 for(int i=0; i<10; i++)
55 begin
56 request = $random % 100;
57 $display(“master: sending request %4d”,
58 request);
59 port.transport(request, response);
60 $display(“master: receiving response %4d”,
61 response);
62 end
63
64 endtask
65 endclass : master
file: 03_tlm/03_transport/transport.sv</source></big>

slave реализует функцию transport(). В нашем примере, она делает некоторые тривиальные обработки запроса для создания ответа.

<big><source lang="verilog">70 class slave extends transport_if;
71
72 task transport(input int request, output int response);
73 $display(“slave: receiving request %4d”,
74 request);
75 response = -request;
76 $display(“slave: sending response %4d”,
77 response);
78 endtask
79
80 endclass
file: 03_tlm/03_transport/transport.sv</source></big>

Связи верхнего уровня между master и slave работают точно так же как и в примере с put и get.

<big><source lang="verilog">85 module top;
86
87 master m;
88 slave s;
89
90 initial begin
91 // instantiate the master and slave
92 m = new();
93 s = new();
94
95 // connect the master and slave through
96 // the port interface
97 m.port = s;
98 m.run();
99 end
100
101 endmodule : top
file: 03_tlm/03_transport/transport.sv</source>
</big>

Связь назначения связывает master и slave. После выполнения соединения, master может использовать соединения для прямого вызова функций slave.

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

Интерфейсы, которые мы рассмотрели ранее, блокирующие. Это означает, что функции и задачи блокируют поток выполнения до их завершения. Им не разрешается заканчиваться неудачей. Не существует механизма для блокировки при аварийном завершении или возможности иным образом изменять поток управления. Поток управления просто ждет, пока запрос будет выполнен. В синхронизированной системе это означает, что может пройти время между вызовом и возвращением полученного результата.

В put конфигурации, у нас есть два компонента, producer и consumer. Producer генерирует случайное число и посылает его к consumer, используя put(). Прежде чем вызывается put(), нет активности в consumer. Вызов put() вызывает активность в consumer, которая выводит значение аргумента. За то время, что consumer является активным, producer ожидает. Это природа блокирующего вызова. Вызывающий должен ждать, пока вызов завершиться для возобновления выполнения.

Теперь сравните это описание с неблокирующим вызовом. Неблокирующий вызов возвращается немедленно. Семантика неблокирующего вызова гарантирует, что вызов возвращается в том же дельта цикле, в котором он был запущен, то есть без задержки, даже на один дельта цикл.

Истинно виртуальный интерфейс, который соединяет неблокирующего slave и master выглядит так же, как другие истинно виртуальные интерфейсы, которые мы видели. Значительная разница в том, что nb_get () возвращает значение статуса вместо транзакции.

<big><source lang="verilog">41 virtual class get_if;
42 pure virtual function int nb_get(output int t);
43 endclass : get_if
file: 03_tlm/04_nonblocking/nbget.sv</source>
</big>

master (consumer) должен проверить состояние, возвращаемое из nb_get (), чтобы определить, завершена ли функция успешно. Отметим также, что мы ввели время в модель. Consumer проверяет каждый 4 нс доступность значения.

<big><source lang="verilog">78 class consumer;
79
80 get_if get_port;
81
82 task run();
83 int randval;
84 int ok;
85
86 for(int i=0; i<20; i++)
87 begin
88 #4;
89 if(get_port.nb_get(randval))
90 $display(“%t: consumer: receiving %4d”, $time,
randval);
91 else
92 $display(“%t: consumer: no randval”, $time);
93 end
94 endtask
95 endclass
file: 03_tlm/04_nonblocking/nbget.sv</source></big>

producer организован как функция и задача. Задача будет раздвоена (порождена), чтобы запуститься как непрерывный процесс. Он генерирует новые случайные значения, что consumer будет захватывать. Тем не менее, каждая случайная величина доступна только для 2 нс из 7 нс цикла. Функция - реализация nb_get, которая возвращает значение, запускает периодически выполнение run().

<big><source lang="verilog">48 class producer extends get_if;
49
50 int randval = 0;
51 int rand_avail = 0;
52
53 function int nb_get(output int t);
54 if(rand_avail) begin
55 $display(“%t: producer: sending %4d”,
56 $time, randval);
57 t = randval;
58 return 1;
59 end
60 return 0;
61 endfunction
62
63 task run();
64 forever begin;
65 #5;
66 randval = $random % 100;
67 rand_avail = 1;
68 #2;
69 rand_avail = 0;
70 end
71 endtask
72
73 endclass : producer
file: 03_tlm/04_nonblocking/nbget.sv
</source>
</big>

Когда мы запускаем пример, мы видим, что не каждый вызов nb_get () успешен.

<pre>4: consumer: no randval
8: consumer: no randval
12: producer: sending -99
12: consumer: receiving -99
16: consumer: no randval
20: producer: sending -39
20: consumer: receiving -39
24: consumer: no randval
28: producer: sending -9
28: consumer: receiving -9
32: consumer: no randval
36: consumer: no randval
40: producer: sending 57
40: consumer: receiving 57
44: consumer: no randval
48: producer: sending -71
48: consumer: receiving -71
52: consumer: no randval
56: producer: sending -14
56: consumer: receiving -14
60: consumer: no randval
64: consumer: no randval
68: producer: sending 29
68: consumer: receiving 29
72: consumer: no randval
76: producer: sending 18
76: consumer: receiving 18
80: consumer: no randval
</pre>
Блокировать get конфигурацию смог только один процесс - consumer, который постоянно обращался с запросом к producer, чтобы тот отправил новое значение. Неблокирующий вариант состоит из двух этапов: consumer регулярно опрашивает producer, чтобы получить новое значение, и producer генерирует новые значения асинхронно по отношению к consumer. Наши неблокирующий producer генерирует доступное случайное значение каждые 7 нс. Он ждет 5 нс, а затем создает новое значение и новое значение действительно в течение 2 нс. Флаг rand_avail устанавливается, когда случайное значение доступно и сбрасывается в противном случае.

Реализация nb_get () в этом примере должна проверить rand_avail есть ли что отправить. Если нет, то она возвращает 0, чтобы указать, что запрос не удался. Если есть что-то, то он посылает его и возвращает 1, чтобы показать успех.

Блокирующие интерфейсы полезны для работы с двумя компонентами синхронно. Вызовы блокируются до тех пор, пока запрошенная операция выполняется, не смотря на то, сколько это потребует времени. С другой стороны, неблокирующие интерфейсы полезны при асинхронной передаче данных. Они не ждут и могут быть использованы для опроса целей, как в приведенном примере.

== Изоляция компонент с помощью каналов ==

В предыдущем разделе обсуждались простые механизмы для перемещения транзакций между двумя процессами. В каждом, инициатор и цель были сильно синхронизированы вызовом транзакции интерфейса. В этом разделе мы рассмотрим случай, когда инициатор и цель менее тесно связаны, это можно сделать с помощью канала, в этом случае 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.

== Формирование 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 интерфейсов.

OVM/OVM методология/Основы верификации

2013-04-09T13:45:47Z

Anastasiya: /* Основы верификации */

{{OVM TOC}}
__TOC__

= =

== Основы верификации==

Функционально проверить устройство означает, сравнить цель разработчика с полученным поведением на их эквивалентность. Мы считаем устройство проверенным, когда, к всеобщему удовлетворению, оно работает в соответствии с целью разработчика. Этот основной принцип часто теряется при использовании testbenches, среды контроля, отладки, моделирования , и все другие средства, применяемые в современных технологических проверках. Чтобы узнать, работает ли верно устройство, вы должны сравнить его с некоторым известным эталоном, который представляет цель разработчика. Каждый testbench имеет своего рода эталонную модель и средство для сравнения функциональность устройство с эталоном.

Когда мы говорим "устройство", мы имеем в виду проверяемое устройство, часто называемое тестируемое устройство или DUT. Чтобы проверить, DUT, как правило, представлен форме подходящей для производства, которое может быть перенесено на кремний с помощью автоматизированных и ручных средств. Мы различаем DUT от эскиза на обратной стороне салфетки или окончательного нанесенный на кристалл, ни один из которых не может быть проверен. Эталонная модель отражает цели разработчика, то есть то, что устройство должно делать.Эталон может принимать различные формы, такие как документ, описывающий работу DUT, golden модель, которая содержит уникальный алгоритм, или assertions, которые представляют протокол.

[[Файл:1.png]]

Для автоматизации сравнения поведения и эталона, оба должны быть представлены в форме, которую можно выполнить на компьютере с помощью некоторых программ, что делает сравнение.

==== Два вопроса====

Проверка устройства включает в себя два вопроса:Does it work? (Работает ли это устройство?) и Are we done? (Сделали ли мы?). Это основные, и некоторые сказали бы, очевидные вопросы. Тем не менее они мотивируют всю механику каждого проверочного потока. Первый вопрос - это Does it work? Этот вопрос исходит от основной идеи верификации. Он спрашивает, соответствует ли устройство эталону? Второй вопрос - Are we done? Он спрашивает, довольны ли мы сравнительным анализом полученной схемы и эталона для определения работает ли устройство согласно цели, если нет, то почему. Мы используем эти ценные вопросы для создания основы разработки эффективных testbenches.

====Does it work?====

Does it work? Это не единственный вопрос, а категория вопросов, которые представляют природу DUT. Каждый проект будет иметь свой собственный набор Does-It-Work вопросов, чья роль заключается в определении правильного функционирования устройства. Функциональные вопросы определяют, ведет ли себя устройство должным образом в конкретных ситуациях. Мы получаем эти вопросы непосредственно из цели разработки устройства, и мы используем их, чтобы отразить цель проекта в testbench.

Рассмотрим простой маршрутизатор пакетов в качестве примера. Это устройство маршрутизации пакетов от входа к одному из четырех портов вывода. Пакеты содержат адреса портов назначения и имеют различные длины полезной нагрузки. Каждый пакет имеет заголовок, трейлер, и два байта для циклического избыточного кода (CRC). Does-It-Work вопросы в этом случае должны быть следующие:

*пакет, поступающий на вход порта, адресованный на имя выходного порта 3, прибыл на порт 3?
*пакет длиной 16 пришел без изменений?
*CRC байты правильны, если полезная нагрузка [0f 73 a8 c2 3e 57 11 0a 88 FF 00 00 33 2b 4c 89]?

Это простой пример полного набора вопросов. Для устройства даже такого простого как этот гипотетическое маршрутизатор, набор Does-It-Work вопросов может быть длинным. Чтобы построить план проверки и testbench, который поддерживает план, вы должны сначала перечислить все вопросы или показать как получит полный набор вопросов, а затем выберите те, которые являются интересными.

Продолжая пример маршрутизатора пакетов,для того чтобы перечислить все Does-It-Work вопросы, вы можете создать таблицу:

[[Файл:2.png]]

Приведенная выше таблица содержит два вида вопросов, те, на которые мы можем ответить сразу и те, которые мы можно разбить на более мелкие вопросы. Вопрос 1 из ряда вопросов, которые можно представить в виде:

[[Файл:3.png]]
[[Файл:4.png]]

Обратите внимание, что мы формулируем все вопросы, так что на них можно ответить да или нет. В конце концов, схема работает либо нет – она либо готова для синтеза, размещения и трассировке, либо нет. Если вы можете ответить на все вопросы утвердительно, тогда проект готов для следующего производственного шага.
При разработке набора does-it-work вопросов, не забудьте сформулировать их таким образом, чтобы на них можно было ответить да или нет. Ответ да положителен, то есть, ответить да означает, что устройство работает правильно. Это будет сделать легче, чем пытаться отслеживать на какие вопросы нужно ответить да, и на какие следует ответить нет. Такой вопрос как Передает ли маршрутизатор ошибочные пакеты? требует ответа нет, чтобы считаться успешным. Лучшей формулировкой вопроса будет: Отклоняет ли маршрутизатор ошибочные пакеты? Вы должны сделать вопросы наиболее конкретными, даже если лучшее звучание будет: Когда ошибочный пакет попадает на входной порт, маршрутизатор обнаруживает его, подает сигнал ошибки и отклоняет этот пакет? Имейте в виду, что более конкретные вопросы более подробно описывают устройство. Ваш testbench должен дать ответ да или нет.
Тщательно сформулированный да или нет вопрос содержит свои собственные критерии успеха. Он сообщает, что получает ответа да. Такой вопрос как, Средняя задержка менее 27 тактов? содержит метрику, 27 тактов, и форму сравнения, меньше. Если вопрос (неправильно) сформулирован, например, Какова средняя задержка прохождения пакетов через маршрутизатор? мы не будем знать, что считается приемлемым. Чтобы ответить на ваш вопрос, вы в первую очередь должны быть в состоянии определить среднее время задержки. Только при правильной постановке вопроса мы знаем, как сделать сравнение, чтобы определить, является ли результат правильным. Метрика сама по себе не говорит нам о том, функционирует ли схема как задумано. Когда мы сравниваем измеренное значение со значением в спецификации, 27 тактов в этом примере, мы можем определить, работает ли схема.
Как это часто бывает, это не практично перечислять каждый does-it-work вопрос. Чтобы убедиться, что каждое слово в памяти 1 Мб можно записать и читать, непрактично и не необходимо записать один миллион вопросов. Вместо этого, вопрос-генератор, вопрос, который генерирует многие другие, занимает место миллиона отдельных вопросов. Может каждый миллион слов в памяти быть успешно записан и считан? -является вопросом-генератором.
Другие вопросы могут сами по себе представлять классы вопросов. Вопрос 3, Является ли вычисление CRC корректным для каждого пакета? является примером такого вопроса. Тестирование CRC вычисления требует ряда тщательно продуманных тестов, для определения является ли вычисления CRC корректным во всех случаях.

==== Are We Done?====

Для определения ответа на вопрос Are we done?, мы должны знать, что мы ответили на достаточное количество does-it-work вопросов, чтобы утверждать, что у нас есть проверенная схема. Мы начинаем эту задачу путем разделения на приоритеты всех does-it-work вопросов по двум направлениям:

[[Файл:5.png]]

Искусство создания testbench требует, чтобы на начальном этапе, мы определили множество вопросов и отсортировали их в соответствии с ценностью возвращаемой информации с точки зрения проверки схемы. Следующий шаг заключается в создании механизма, который будет отвечать на вопросы и определять на какие из них были даны ответы (и на какие нет).

Are-we-done вопросы также называется вопросами функционального покрытия, вопросы, которые устанавливают все ли состояния охватывают тесты с точки зрения функций схемы. Как и does-it-work вопросы, мы можем также разбить вопросы функционального охвата на более подробные вопросы. И как вопросы функциональной корректности, вопросы функционального охвата должны также иметь ответы да или нет. Приведенный ниже список включает в себя примеры вопросы функционального охвата:

• Выполняется ли каждая команда процессора, по крайней мере, один раз?

• Проходит, по крайней мере, один пакет от каждого входного порта до каждого выходного порта?

• Можно ли обратиться к памяти с набором адресов, которые содержат каждый бит адреса как 1 и затем каждый бит адреса 0, не включая 0xffffffff и 0x00000000?(?????????)

Другим мнением об этих вопросах является то, о чем они спрашивают, Получен ли утвердительный ответ на необходимый does-it-work вопрос? Когда мы думаем о функциональном охвате с этой точки зрения, то имеем виду покрытие множества does-it-work вопросов. Кроме того, вопросы охвата распознают метрику и порог для сравнения. Покрытие будет (то есть, охват вопрос можно ответить, да), когда метрика достигает порога.

Таким образом, искусство построения testbench начинается с плана тестирования. План тестирования начинается с тщательно продуманным набором does-it-work и Are-we-done вопросов.

==== Процесс(проверки) с двумя циклами (итерациями)====

Процесс ответа на does-it-work и Are-we-done вопросы может быть описан простой схемой, как показано на рисунке 1-2. Все обусловлено функциональной спецификацией на проектирование. Из функциональной спецификации, вы можете получить саму схему и план верификации. План верификации запускает testbench.

Поток состоит из двух циклов, does-it-work цикла и Are-we-done цикл. Оба цикла начинаются с моделирования. Моделирование тестирует схему при помощи testbench и генерирует информацию, которую мы используем для ответа на вопросы. Сначала мы спрашиваем, Это работает? Если ответ нет, то необходимо отладить проект. Процесс отладки схемы может привести к изменениям в реализации схемы.
Как только схема работает, то пора ответить на вопрос, Are-we-done? Мы ответим на этот вопрос, собирая информацию охвата и сравнения его с порогом, указанным в тестовом плане. Если мы не достигнем порогов, то ответ нет, и мы должны изменить testbench для увеличения охвата. Тогда мы моделируем снова.

Изменение testbench или воздействия может вызвать другие скрытые ошибки в схеме. Последующие итерации по циклу могут заставить нас вернуться к does-it-work циклу снова, чтобы исправить новые ошибки, которые появятся. Как вы можете видеть, полный процесс проверки колеблется вперед и назад между does-it-work и Are-we-done циклами, пока мы не можем утвердительно ответить на все вопросы обоих категорий.

[[Файл:6.png]]

В идеальном мире, схема не имеет ошибок и с покрытием всегда полное, так что вам только надо пройти по каждому циклу один раз, чтобы получить ответы да на оба вопроса. В реальном мире, это может занять много итераций для достижения двух ответов да. Одна из целей хорошего процесса проверки свести к минимуму количество итераций для выполнения верификации проекта в кратчайшие сроки с использованием наименьшего количества ресурсов.

== Первый Testbench==

Давайте начнем с проверки одного из самых фундаментальных цифровых электронных устройств, схемы логического И. Логическое И вычисляет логическое умножение входов. Функция этого устройства является тривиальной, а на практике, вряд ли должна иметь свой собственный testbench. Так как она тривиальна, мы можем использовать ее для иллюстрации некоторых основных принципов проверки без необходимости вникать в более сложную схему.

Рисунок 1-3 показывает условное обозначение логического элемента умножения с двумя входами. Логический элемент имеет два входа, А и В, и один выход Y. Устройство вычисляет логическое умножение А и В и помещает результат в Y.

[[Файл:7.png]]

Следующая таблица истинности описывает функцию устройства.

[[Файл:8.png]]

Таблица истинности является исчерпывающей: она содержит все возможные входы А и В и поэтому, все возможные значения для выхода Y.
Наша задача состоит в том, чтобы доказать, что наша схема, логического И, работает правильно. Чтобы убедиться, что он действительно выполняет функцию логического умножения правильно, нам в первую очередь необходимо перечислим вопросы. Таблица истинности поможет нам создать множество вопросов, необходимых для проверки. Каждая строка таблицы содержит вход для А и В и ожидаемый выход для Y. Так как таблица является исчерпывающей, наш вопрос-генератор будет: Для каждой ли строки в таблице истинности, когда мы получаем значения А и B, определенные в этой строке, устройство вычисляет ожидаемый результат для Y? Для ответа на Are-we-done вопрос, мы определяем, проверили ли мы каждую строку в таблице истинности, и получил ли утвердительный ответ does-itwork вопрос для этой строки. Наш Are-we-done вопрос- это Работает на всех наборах?
Для автоматизации ответов как на does-itwork та и на Are-we-done вопросы, нам нужна следующая атрибутика:

• Модель, которая представляет DUT (в данном случае, логическое И)

• Концепция конструкции в форме, которую мы можем кодифицировать как эталонную модель

• Некоторое воздействие для проверки схемы

• Способ сравнить результат с концепцией конструкции

[[Файл:9.png]]

В то время как наш маленький testbench прост, он содержит ключевые элементы, которые можно найти в большинстве testbenches любого уровня сложности. Ключевыми элементами являются следующие:

• DUT

• Stimulus генератор, который генерирует последовательность сигналов для DUT

• Scoreboard, которое изображает эталонную модель

Табло следит за входами и выходом тестируемого устройства, выполняет же функции, что DUT за исключением более высокого уровня абстракции, и определяет, совпадает ли DUT и эталонная модель. Scoreboard помогает нам ответить на does-itwork вопросы.

=== DUT===

DUT- это наше логическое И с двумя входами. Мы реализуем логическое И, как модуль с двумя входами А и В, и одним выходом Y.

<big><source lang="verilog">44 module and2 (
45 output bit Y,
46 input A, B);
47
48 initial Y = A & B;
49
50 always @* Y = #1 A & B;
51 endmodule
</source></big>

Stimulus генератор в этом примере создает заданные сигналы. Каждое новое значение вычисляются в определенном порядке. Позже, мы будем смотреть на генератор случайных сигналов, которые, как следует из их названия, генерирует случайные значения.

<big><source lang="verilog">81 module stimulus(output bit A, B);
82
83 bit [1:0] stimulus_count = 0;
84
85 always
86 #10 {A,B} = stimulus_count++;
87
88 endmodule</source></big>

Цель Stimulus генератор - получение значений на вход DUT. Сигналы, двухбитная величина, содержащая значение для А и B. После того как он увеличивается при каждой последующей итерации, младший бит посылает на А, а старший бит на B.

=== Scoreboard===

Scoreboard несет ответственность за ответы на does-it-work вопросы. Оно следит за работой DUT и сообщает работает ли оно корректно. Обратите внимание на то, что структура Scoreboard поразительно похожа на структуру DUT. Это имеет смысл, когда вы считаете, что назначением Scoreboard является отслеживание активности DUT и определение, работает ли DUT как ожидалось.

<big><source lang="verilog">59 module scoreboard(input bit Y, A, B);
60
61 reg Y_sb, truth_table[2][2];
62
63 initial begin
64 truth_table[0][0] = 0;
65 truth_table[0][1] = 0;
66 truth_table[1][0] = 0;
67 truth_table[1][1] = 1;
68 end
69
70 always @(A or B) begin
71 Y_sb = truth_table[A][B];
72 #2 $display(“@%4t - %b%b : Y_sb=%b, Y=%b (%0s)”,
73 $time, A, B, Y_sb, Y,
74 ((Y_sb == Y) ? “Match” : “Mis-match”));
75 end
76 endmodule</source></big>

Scoreboard отображает пины всех входов. На Scoreboard не вызывает воздействия на схему. Оно пассивно наблюдает за входами и выходами тестируемого устройства.

Модуль верхнего уровня, как показано ниже, является полностью структурированным, он содержит экземпляр тестируемого устройства, Scoreboard и Stimulus генератор, с кодом, необходимым для их подключения.

<big><source lang="verilog">93 module top;
94 stimulus s(A, B);
95 and2 a(Y, A, B);
96 scoreboard sb(Y, A, B);
97
98 initial
99 #100 $finish(2);
100 endmodule</source></big>

Когда мы запускаем моделирования для нескольких итераций, вот что мы получаем:

[[Файл:14.png]]

Каждое сообщение состоит из двух частей. В первой части показаны применяемые сигналы. Вторая часть показывает результаты проверки Scoreboard, которое сравнивает соответствие DUT с необходимыми результатами. Мы используем двоеточие для разделения двух частей.

Этот простой testbench демонстрирует использование Stimulus генератор и Scoreboard, которое служит в качестве эталона. Несмотря на то, DUT – логическое И, все элементы полного testbench присутствуют.

== Второй Testbench==

В предыдущий пример показывает элементарные понятия проверки с использованием комбинационного дизайна. Комбинационные конструкций, по природе, не поддерживают никаких статических данных. В нашем втором примере мы рассмотрим чуть более сложную конструкцию, которая сохраняет данные о состояниях и использует тактовый сигнал для перехода между состояниями.

Проблема верификации, связанная с синхронными (последовательными) схемами, иная чем у комбинационных конструкций. Все, что вам нужно знать о комбинационной схеме доступно на ее входах. Эталонная модель для комбинационного устройства просто должна вычислять F (X), где X представляет входы устройства и F – это реализуемая функция. Выходы же на последовательном устройстве зависят от входных сигналов и его внутреннего состояния. Дальнейшее вычисление может изменить внутреннее состояние. Scoreboard должно отслеживать внутреннее состояние тестируемого устройства и сравнить выходные данные.

Комбинационное устройство может быть полностью проверено при подаче всех возможных комбинаций сигналов на входы. Для устройства N входами, мы должны применить в общей сложности 2n входных комбинаций. Число 2n может быть большим, но вычисление такого количества входов достаточно простое. Нам просто необходимо иметь N-разрядный счетчик и посылать каждое значение счетчика на входы устройства.
Для последовательного устройства, понятие "done" должно распространяться и на покрытие не только всевозможных сигналов на входах, но и на число всевозможных внутренних состояний. Для устройства с n входами и m внутренних состояний, вы должны покрыть (2n входов) * (2m внутренних состояний), 2n+m – число всевозможных комбинаций внутренних состояний и входов. Для устройства с 64 входами и одним 32-битный внутренним регистром, количество комбинаций 296 -очень большое число, не так ли!

Даже для очень большого числа комбинаций, проверка не была бы слишком трудной, если бы было возможно просто увеличивать счетчик для получения всех комбинаций, как мы делаем с комбинационными устройствами. К сожалению, это не представляется возможным. Внутреннее состояние напрямую не доступны извне устройства. Оно может быть изменено только путем манипулированием входов. И теперь проблема заключается в том, как добраться до всех состояний в устройстве только через входы. Это сложная проблема, которая требует глубокого понимания устройства, для генерации последовательности входов для получения всех состояний.

Поскольку трудно получить все состояния, становится очевидным вопрос, Можем ли мы упростить задачу путем сокращения числа состояний, которые мы должны получить, чтобы показать, что устройство работает правильно? Ответ: да. Теперь возникает другой вопрос, Как мы решим, какие состояния можно пропустить?

Эта тема является сложной. Тем не менее, мы можем дать интуитивный ответ на вопрос. Состояния, которые могут быть отмечены как недоступные, при использовании формальной проверки или других методов, не должны быть покрыты. Проектировщик должен рассмотреть вопрос об упрощении схемы для удаления недоступных состояний, так как они не представляют никакой ценности. Состояния, которые имеют низкую вероятность быть достигнутыми, также могут быть исключены из плана проверки. Определение порогового значения вероятности и вероятностей состояний такое же искусство, как наука. Она включает в себя понимание того, как устройство используется и какие входы необходимы (по сравнению с которые возможны).

Это также позволяет устранить состояния, которые являются функционально эквивалентными. Рассмотрим устройство пакет коммуникаций. В теории, каждое возможное значение полезной нагрузки пакета представляет собой различное состояние (или множества состояний), которое принимает схема, и оно должно быть покрыто во время проверки. Однако, это, вероятно, не будет преувеличением считать, что произвольное ненулевое значение, для всех намерений и целей, эквивалентно. Конечно, могут быть некоторые интересные случаи, которые должны быть проверены, как все нули, все единицы, конкретные значения, которые могли бы бросить алгоритмы коррекции ошибок, и так далее. Изменения данных становятся интереснее, когда они влияют на поток управления.

В общем, это более важно, чтобы охватить управляющие состояния, чем состояние данных. Простым способом уменьшить число состояний, необходимых для покрытия схемы является разделения данных и управления. Для конкретного пути контроля, данные могут быть произвольными. По некоторых данных, вы можете захотеть изменить путь управления. Например, в ALU вы можете разделить функции контроля записи данных и получения данных из регистров и установление арифметической операции для выполнения из результатов конкретные арифметических операций. Использование направленного управления, вы можете сделать данные случайные или рассмотреть данные в специфичных случаях, таких как деление на 0 или умножение на 1.

Для сложных последовательных конструкций, определения того, какие состояния должны быть покрыты(и какие не должны) и, как получить эти состояния с минимальными усилиями является проблемой.

=== 3-х разрядный счетчик===

Схема, приведенная на рисунке 1-5, представляет собой 3-разрядный счетчик с асинхронным сбросом. Каждый раз, когда тактовый сигнал высокий, счетчик увеличивается. Схема состоит из трех переключательных триггеров, каждый из которых поддерживает один бит счета(??). Триггеры связаны с некоторой комбинационной логикой для формирования счетчика . Каждый триггер переключается, когда на входе T сигнал высокой. При низком сигнале на Т , триггер сохраняет свое текущее состояние. Когда активный низкий сброса установлен в 0, триггер переходит в состояние 0.

[[Файл:15.png]]

Код для счетчика содержится в двух модулях. Одним из них является простой переключательный триггер, а другой подключает триггера с необходимой логикой для формирования счетчика. Первый пример показывает переключательный триггер.

<big><source lang="verilog">36 module toggle_ff (output bit q, input t, rst_n, clk);
37
38 always @ (posedge clk or negedge rst_n)
39 if (!rst_n) q <= ‘0;
40 else if (t) q <= ~q;
41
42 endmodule
</source></big>

Счетчик состоит из трех переключательных триггеров и логического элемента И.

<big><source lang="verilog">47 module counter (output [2:0] q, input rst_n, clk);
48
49 toggle_ff ff0 (q[0], 1’b1, rst_n, clk);
50 toggle_ff ff1 (q[1], q[0], rst_n, clk);
51 toggle_ff ff2 (q[2], t2, rst_n, clk);
52 and a1 (t2, q[0], q[1]);
53
54 endmodule</source></big>

Схема проста, но имеет характеристики, которые являются общими с реальными проектами и которые требуют внимания для надлежащей проверки дизайна. Основными характеристиками является то, что конструкция работает по тактовому сигналу, и что она сохраняет внутреннее состояние. Логический элемент И из предыдущего примера не сохраняет никаких состояний. Вся информация о том, что делает схема, находится на ее входах. В конструкциях с внутренними данными, что это не так.

Эта разница отражается на схеме нашего табло. Рисунок 1-6 показывает схему testbench для 3х разрядного счетчика.

[[Файл:18.png]]

Во многих отношениях, testbench для 3-разрядного счетчика очень похож на testbench для логического элемента И. Оба имеют Scoreboard, роль которого состоит в наблюдении, что делает схема, и определить, выполняется ли операция правильно. Оба имеют устройства для DUT. Тем не менее, мы выполняем операции по-разному для этих конструкций. Мы используем Stimulus генератор для логического элемента И, но мы используем контроллер для 3-х разрядного счетчика. 3-х разрядный счетчик автономное устройство. Пока он подключен к тактовому сигналу, он будет продолжать считать. Таким образом, нам не нужен Stimulus генератор, который мы использовали для логического И. Вместо этого, контроллер управляет работой тестируемого устройства и testbench. Контроллер обеспечивает начальный сброс, так что отсчет начинается с известного значения. Он также останавливает моделирование в соответствующее время.

<big><source lang="verilog">93 module control(output bit rst_n, input clk);
94
95 initial begin
96 rst_n <= 0;
97 @(posedge clk);
98 @(negedge clk);
99 rst_n <= 1;
100 repeat (10) @(posedge clk);
101 $finish;
102 end
103
104 endmodule</source></big>

Табло должны отслеживать внутреннее состояние DUT. Это делается с помощью переменной count. Как и DUT, когда reset активирован, счетчик устанавливается в 0. Каждый тактовый цикл count увеличивается на единицу, и новое значение сравнивается с count, поступающего с DUT.

<big><source lang="verilog">71 module scoreboard (input [2:0] q, input rst_n, clk );
72
73 int count;
74
75 always @(posedge clk or negedge rst_n) begin
76 if(!rst_n) count <= 0;
77 else begin
78 if (count == q)
79 $display(“time =%4t q = %3b count = %0d match!”,
80 $time, q, count);
81 else
82 $display(“time =%4t q = %3b count = %0d <-- no
match”,
83 $time, q, count);
84 count <= (count + 1) % 8;
85 end
86 end
87
88 endmodule</source></big>

Табло имеет модель счетчика высокого уровня. Он использует целую переменную и оператор сложения (+) , чтобы сформировать счетчик вместо триггеров и элемента И. Каждый раз, при изменении тактового импульса, он увеличивает свой счет, так же как и RTL счетчика. Он также проверяет, соответствует ли ее внутренний счетчик выходу счетчика DUT.

Для полноты, пример показывает тактовый генератор и модуль топ-уровня. Тактовый генератор просто инициализирует тактовый сигнал 0, а затем переключает его каждые 5 нс.

<big><source lang="verilog">
59 module clkgen(output bit clk);
60
61 initial begin
62 clk <= 0;
63 forever #5 clk = ~clk;
64 end
65
66 endmodule</source></big>

Модуля верхнего уровня является типичным для большинства testbenches. Он соединяет DUT и компоненты testbench.

<big><source lang="verilog">109 module top;
110
111 wire [2:0] q;
112
113 clkgen ckgn (clk);
114 counter cntr (q, rst_n, clk);
115 control ctrl (rst_n, clk);
116 scoreboard score (q, rst_n, clk);
117
118 endmodule</source>
</big>
Мы показали простой testbench, который содержит элементы, используемые в гораздо более сложных testbenches. Последовательные схемы, которые поддерживают внутреннее состояние, требуют табло, которое работает параллельно с DUT. Табло выполняет те же вычисления что и DUT, но на более высоком уровне абстракции. Табло также сравнивает свои вычисления с вычислениями, полученными от DUT.

== Многоуровневая организация Testbenches==

Так как схема представляет собой совокупность компонент проекта, testbench представляет собой совокупность компонент верификации. OVM определяет верификацию компонент, их структуру,интерфейс. В этом разделе описываются OVM компоненты.

OVM testbenches организованы в виде уровней. Самый нижний слой -устройство RTL с pin-level интерфейсом (с интерфейсом на уровне выводов). Выше находится уровень транзакторов (посредник), устройств, которые преобразуют из уровня транзакций в pin-level. Все компоненты, находящиеся на этом уровне, являются компонентами уровня транзакций. Диаграмма, приведенная ниже, иллюстрирует уровневую организацию тестовых программ. Блок слева — название уровня, блок справа — перечень типов компонентов, входящих в него. Вертикальные стрелки показывают, какие уровни взаимодействуют на прямую. Например, управляющий уровень взаимодействует с уровнями анализа, операций, транзакторов, но с DUT напрямую не может.

[[Файл:23.png]]

Вы также можете рассмотреть testbench как концентрическую организацию компонент. Внутреннему кольцу соответствует нижний уровень, а внешнему кольцу - верхний уровень. Для некоторых будет проще понять отношения между уровнями, используя диаграмму в виде списка связей.

[[Файл:24.png]]

=== Transactors(Посредники)===

Роль посредников в testbench состоит в преобразование потока транзакций в pin-level activity или наоборот. Транзакторы характеризуются наличием, по крайней мере, одного pin-level интерфейса и хотя бы одного transaction-level интерфейса. Транзакторы могут принимать большое разнообразие форм, цветов и стилей. Мы сосредоточимся на мониторах, драйверах и передатчиках.

'''Монитор'''. Монитор, как следует из названия, следит за шиной данных. Он следит за выводами и преобразует их в поток транзакций. Мониторы пассивные - это означает, что они не влияют на операции в DUT.

'''Драйвер'''. Драйвер преобразует поток транзакций (или последовательность элементов) в pin-level activity.

'''Передатчик'''. Передатчик очень похож на драйвер, но он реагирует на активность на выходе, а не на входную активность.

===Операционные компоненты===

Операционные компоненты – это набор компонент, которые обеспечивают все необходимые операции в DUT. Операционные компоненты отвечают за генерацию трафика для DUT. Все эти компоненты относятся к уровню транзакций и имеют только интерфейс уровня транзакций. Существуют различные варианты формирования сигнала, которые варьируются в зависимости от верифицируемого устройства. Мы рассмотрим три основных вида операционных компонентов: stimulus generators, masters, и slaves.

'''Stimulus генераторы'''. Генератор сигналов создает поток транзакций для проверки DUT. Stimulus генераторы могут быть случайными, заданными или заданными случайно; они могут запускаться самостоятельно или контролируемо; и они могут быть независимыми или синхронизированными. Простейший stimulus генератор рандомизирует содержимое объекта запроса и посылает этот объект на драйвер. OVM также предоставляет модульные, динамические средства для построения сложных stimulus, называемыми последовательностями.

'''Главное устройство'''. Главное устройство - двунаправленная компонента, которая посылает запросы и принимает ответы. Главное устройство инициирует активность. Как и Stimulus генераторы, оно может передавать отдельные рандомизированные транзакции или последовательности заданных или случайно заданных транзакций. Главное устройство может использовать ответы для определения последующих действий. Главное устройство также может быть реализовано как последовательность.

'''Подчиненное устройство'''. Подчиненное устройство, как и главное устройство, является двунаправленной компонентой. Оно реагирует на запросы и возвращает ответы (в отличие от главного устройства, которое отправляют запросы, и принимает ответы).

[[Файл:25.png]]

=== Компоненты анализа===

Компоненты анализа получают информацию о том, что происходит в testbench, и используют эту информацию, чтобы сделать некоторые заключения о правильности и полноты теста. Два наиболее распространенных вида анализа - это scoreboards и coverage collectors.

'''Scoreboards'''. Табло используются для определения правильности DUT, чтобы ответить на does-it-work вопросы. Scoreboards перехватывает информацию, входящую и выходящую из DUT и определяют правильно ли DUT отвечает на данный stimulus.

'''Coverage Collector'''. Coverage Collector используются для подсчета. Они перехватывают поток транзакций, и считает транзакции или различные аспекты транзакций. Цель состоит в том, чтобы определить завершенность верификации, отвечая на are-we-done вопросы. Определенные параметры, которые coverage collectors считает, зависит от схемы и специфики тестов. Общие вещи, которые coverage collectors включают в себя: необработанные транзакции, транзакции, которые происходит в определенном сегменте адресного пространства, и протокол ошибок. Список неограничен.

Coverage Collector могут также выполнять вычисления как часть полноты верификации. Например, coverage collectors может содержать скользящее среднее и среднее квадратичное отклонение данных, которые отслеживаются. Или они могут хранить отношения ошибок к выполнимым операциям.

=== Контроллер===

Контроллеры формируют основной поток теста, и управляют работой. Как правило, контроллеры получают информацию от Scoreboard и coverage collectors, и отправляют информацию компонентам окружающей среды.
Например, контроллер может запустить Stimulus генератор, а затем ждать сигнала от coverage collectors, чтобы уведомить его, когда тест будет завершен. Контроллер, в свою очередь, останавливает Stimulus генератор. Более сложные вариации на эту тему возможны. В пример возможные конфигурации, контроллер инициализирует Stimulus генератор начальным набором ограничений и запускает его. При достижении определенного соотношения типов пакетов, coverage collectors сигнализирует контроллеру. Вместо того, чтобы остановить Stimulus генератор, контроллер может отправить ему новый набор ограничений.

== Два домена (Две области)==

Мы можем разделить множество компонент в testbench на отдельные области. Оперативная область - множество компонент, в том числе DUT, которые управляют DUT. Это Stimulus генератор, шина функциональной модели (BFM), и аналогичные компоненты, которые генерируют сигналы и возвращают ответы, которые управляют моделированием. DUT, ответчик, и драйвер операций, наряду с компонентами окружающей среды, которые непосредственно обращаются или отвечают драйверам и передатчикам ответа, включены в оперативную область. Остальные компоненты testbench –монитор транзакций, scoreboard, coverage collectors, и контроллера включены в область анализа. Это компоненты, которые собирают информацию из оперативной области.

Данные должны быть перемещены из оперативной области в область анализа таким образом, чтобы не мешать работе DUT и сохранить оптимальный выбор событий. Это достигается с помощью специального интерфейса связи называемого портом анализа. Порт анализа представляют собой особый вид порта транзакций, в котором издатель передает данные одному или нескольким получателям. Издатель оповещает всех получателей, когда новые данные готовы.

Одной из ключевых особенностей порта анализа является то, что он имеет единственную функцию, write(). Очередь(fifo) анализа, каналы, используемые для подключения к порту анализа для анализа компонентов, неограниченные. Это гарантирует, что издатель не блокирует, а передает свои данные в очередь (fifo) анализа в точно такой же дельта-цикл, в котором они были созданы.

[[Файл:26.png]]

Как правило, оперативная и область анализа связаны портами анализа и интерфейсами управления и конфигурации. Порты анализа - шлюз, через который выходят данные относящиеся к операциям DUT. Эти данные могут включать шину транзакций, коммуникационные пакеты и информацию о состоянии (успех или ошибка конкретных операций). Компоненты области анализа анализируют данные и принимают решения. Результатами этих решений могут быть сообщения оперативной области, используя интерфейсы управления и конфигурирования. Интерфейсы управления и конфигурирования могут быть использованы для запуска и остановки Stimulus генератор, изменения ограничений, изменения процента ошибок, или манипулирование другими параметрами, влияющих на работу testbench.

== Заключение==

В этой главе мы рассмотрели, как структурировать весь процесс проверки. Этот процесс основывается на двух фундаментальных вопросах, Does it work? и Are we done? Простые примеры показали, как построить testbench для аппаратного ответа на эти вопросы такими устройствами как генератор сигналов и табло. Далее будет показано, как применять на уровне транзакций методы моделирования для создания практических, масштабируемых, многоразовых компонент testbench, которые отвечают на эти вопросы и показывают, как подключить их testbenches.

OVM/OVM методология/Механика OVM

2013-04-01T10:35:31Z

Anastasiya:

{{OVM TOC}}
__TOC__

= Механика OVM =

Библиотека OVM предоставляет много возможностей для построения testbenches. В этой главе мы ознакомимся с наиболее важными возможностями, которые вы будете использовать почти во всех ваши testbenches.

== Компоненты и иерархия ==

Первичная структура для создания элементов testbench является компонента. Компонента в OVM – это аналогия модулю в Verilog. Компонента OVM сконструирована на основе класса, который обеспечивает ему различные характеристики, чем модуль Verilog и имеет различные использования импликаций. Среди таких характеристик является то, что классы создаются во время выполнения, а не во время разработки, как модули. Таким образом, OVM отвечает за создание компонента и сборки их в иерархии.

{|
|[[Файл:69.png]]
|<graph>
digraph G{
node[shape="circle",fontsize="11",margin="0.03,0.03"]
edge[arrowhead=none]
env -> {c1 c2}
c1 -> {child11 child12}
c2 -> {child21 child22}
child11 [label="child1"]
child12 [label="child2"]
child21 [label="child1"]
child22 [label="child2"]
}
</graph>
|}

Рисунок 4-1 иллюстрирует простую иерархию компонент. После мы покажем, как построить эту иерархию с помощью средств OVM для создания компонент и объединения их в иерархии:

Самый верхний узел, ENV, является корнем. Корень отличается тем, что он не имеет предка. Все остальные узлы имеют только одного предка. Каждый узел имеет имя. Расположение каждого узла в иерархии может быть идентифицировано уникальным full_name (путем), который строится на нанизывании имен всех узлов между корнем и узлов в запросе, разделяя их сепаратором иерархии, точкой (.). Например, путь к компоненту, второго потомка с2 - top.c2.child2.

Компонент в ОВМ является классом, производным от ovm_component. Простейшая компоненты - листья, те, которые не имеют потомков.

<big><source lang="cpp">57 class child extends ovm_component;
58
59 function new(string name, ovm_component parent);
60 super.new(name, parent);
61 endfunction
62
63 endclass
file: 04_OVM_mechanics/01_hierarchy/top.sv</source></big>

Конструктор имеет два параметра, имя компоненты и указатель на его предка. Название - простое имя, а не иерархический путь. Предок предоставляет место для подключения новой компоненты в иерархии. Полный путь потомка создается путем объединения имени потомка с полным именем предка, разделенный точкой (.).OVM предоставляет методы для получения и имени и полного пути компоненты:

<big><source lang="cpp">string get_name();
string get_full_name();</source>
</big>

Подчиненные компоненты создаются в функции build(), которая вызывается на этапе сборки (фазы объясняется далее в этой главе). Создание экземпляра компонента включает вызов new() для выделения памяти для нее и передачи соответствующих параметров в конструктор. В компоненте, показанной ниже, мы создаем две подчиненные компоненты, и child1 child2.

<big><source lang="cpp">71 class component extends ovm_component;
72
73 child child1;
74 child child2;
75
76 function new(string name, ovm_component parent);
77 super.new(name, parent);
78 endfunction
79
80 function void build();
81 child1 = new(“child1”, this);
82 child2 = new(“child2”, this);
83 endfunction
84
85 endclass
file: 04_OVM_mechanics/01_hierarchy/top.sv</source></big>

Как component, ENV также создает экземпляры двух подчиненных компонент, c1 и c2. Вся иерархия с корнем в модуле, называемым top в нашем проекте.(??)

<big><source lang="cpp">131 module top;
132
133 env e;
134
135 initial begin
136 e = new(“env”);
137 run_test();
138 end
139
140 endmodule
file: 04_OVM_mechanics/01_hierarchy/top.sv</source></big>

Вызов new() создает верхний уровень окружающей среды. run_test () начинает выполнение testbench.

В SystemVerilog, модули, интерфейсы и программные блоки создаются во время разработки, в то время как классы создаются после разработки, во время выполнения. Таким образом, чтобы создать иерархию классов, мы должны иметь интерфейс, модуль или программу, который содержит начальный блок, который начинает процесс создание компонент иерархии, основанных на классах. Интерфейсы предназначены для использования в качестве средства связи между двумя модулями и не очень хорошо подходят для использования в качестве корня иерархии классов. Программные блоки или модули могут быть использованы как корень (??). Для нашей простой иерархии, это не имеет значения. Позже, когда мы подключаем класс-компонент для модуля на основе аппаратных средств, мы увидим, что использование модуля предпочтительнее программным блокам.

=== Перемещение по иерархии ===

Мы можем исследовать структуры данных, используемые для реализации компонента иерархии с некоторыми методами, предусмотренными в ovm_component. Потомки компоненты хранятся в ассоциативном массиве. Этот массив напрямую не доступен, но он может быть доступен через иерархию API. Этот API-интерфейс похож на встроенные методы SystemVerilog, предназначенные для ассоциативных массивов.

<big><source lang="cpp">int get_first_child(ref string name);
int get_next_child(ref string name);
ovm_component get_child(string name);
int get_num_children();
</source></big>

get_first_child () и get_next_child () работают вместе для перебора множества потомков, содержащихся в компоненте. get_first_child () извлекает имя первого ребенка в списке. Он возвращает имя в качестве ссылки. get_next_child () возвращает имя следующего ребенка в списке. Он возвращает 1, если имеется следующая имя потомка и 0, если был достигнут конец списка. get_child () преобразует имя в ссылку компоненты.

Используя эти функции, мы можем пройти по компонентам иерархии.

<big><source lang="cpp">73 function void depth_first(ovm_component node,
74 int unsigned level = 0);
75
76 string name;
77
78 if(node == null)
79 return;
80
81 visit(node, level);
82
83 if(node.get_first_child(name))
84 do begin
85 depth_first(node.get_child(name), level+1);
86 end while(node.get_next_child(name));
87
88 endfunction
file: 04_OVM_mechanics/utils/traverse.svh
</source>
</big>

Эта функция будет осуществляющая обход в глубину иерархии, называя visit(). Мы используем get_first_child () и get_next_child () для перебора списка каждого потомка в каждом узле. Для каждого итерации мы вызываем depth_first () рекурсивно. Для нашего маленького проекта, результат будет следующий:

<big><pre>+ env
| + env.c1
| | env.c1.child1
| | env.c1.child2
| + env.c2
| | env.c2.child1
| | env.c2.child2
</pre></big>

Функция visit() использует глубину узла и определяет является ли он конечным для печати строки каждого узла.

=== Singleton Top ===

Компоненты, которые не имеют предков (то есть, параметр предок в конструкторе является нулевым) называют orphans.(??) В OVM вы можете создать столько компоненты без предков, сколько вам необходимо. Тем не менее, не существует такого понятия, как истинные orphans. Любой компонент, чей предок является null, относится к встроенному предку, называемому ovm_top. ovm_top состоит из одного экземпляра ovm_root. Это предок всех компонент, которые имеют предков. В самом деле, env в нашем предыдущем примере является потомком ovm_top. Так как он не имеет предка, то автоматически получают ovm_top в качестве родителя.

singleton - широко известный объектно-ориентированных шаблон проектирования, который имеет private (local) или protected конструкторы и статическую функцию get, которая возвращает тот же самый указатель не смотря на то, сколько раз она вызывается. Это означает, что возможно существование одного экземпляра, и что экземпляр создается автоматически при вызове функции get. ovm_top содержит дескриптор экземпляра singleton ovm_root(???). Он статически инициализируется при вызове ovm_root :: Get (). Вы можете вызвать ovm_root :: Get () в любое время, но в этом нет необходимости, так как ovm_top предусматривает это.

Есть целый ряд полезных следствий существования singleton top-level компоненты. Одним из них является, что вы можете достичь любую компоненту из ovm_top. Если вы запустили алгоритм обхода иерархии, начиная с ovm_top, вы доберетесь до каждой компоненты в системе. Другим следствием является то, что любая компонента, включая порты, экспорт и каналы, которые создаются внутри модуля, достижима из ovm_top. Если вы хотите изменить отчет во всех обработчиках компонент, вы можете сделать это, вызвав одну из иерархических функции отчетности в ovm_top. ovm_top содержит все механизмы синхронизации, которые объясняются далее в этой главе.

== Connectivity ==

Компоненты соединены друг с другом через TLM port и exports. Port и exports обеспечивают средства для компонент, или, точнее, процессы в компонентах для синхронизации и связи друг с другом. Port и exports - объекты, которые образуют пункт связывания для обеспечения межкомпонентной связи. Как уже говорилось в предыдущей главе, exports обеспечивают функции и задачи, которые могут быть вызваны из Port.

[[Файл:70.png]]

Метод connect портов и exports используется для связывания их вместе.

initiator_port.connect(target.export)

Этот метод создает ассоциацию, или связывание, между port и export так, что port может вызывать(запускать) задачи и функции из export. Для успешного соединения, типы port и export должны совпадать. То есть, типы интерфейсов должны быть одинаковыми, и тип объекта, передающегося в интерфейс должны быть одинаковыми.

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

Как и контактами в RTL дизайне, нам нужно подключиться к портам TLM через иерархические границы. Рисунок 4-3 использует простой дизайн, чтобы показать, как сделать эти соединения. Этот проект содержит исходную компоненту с двумя port(выходами), которые в конечном итоге подключаются к двум входам(export). Для осуществления подключения между этими компонентами, мы должны расширить port и export на уровень выше в иерархии.

[[Файл:71.png]]

Компонент source содержит два порта, и first_put_port, second_put_port.

<big><source lang="cpp">65 class source extends ovm_component;
66
67 ovm_put_port #(trans_t) first_put_port;
68 ovm_put_port #(trans_t) second_put_port;
69
70 function new(string name, ovm_component parent);
71 super.new(name, parent);
72 endfunction
73
74 function void build();
75 first_put_port = new(“first_put_port”, this);
76 second_put_port = new(“second_put_port”, this);
77 endfunction
file: 04_OVM_mechanics/02_connectivity/top.sv</source>
</big>

Кроме того, компонента sink создает экспорт и создает его в функции build. Экспорт связан с внутренним каналом, FIFO, от которого компонента может получать объекты во время выполнения.

<big><source lang="cpp">126 class sink extends ovm_component;
127
128 ovm_put_export #(trans_t) put_export;
129 local tlm_fifo #(trans_t) fifo;
130
131 function new(string name, ovm_component parent);
132 super.new(name, parent);
133 endfunction
134
135 function void build();
136 put_export = new(“put_export”, this);
137 fifo = new(“fifo”, this);
138 endfunction
139
140 function void connect();
141 put_export.connect(fifo.put_export);
142 endfunction
file: 04_OVM_mechanics/02_connectivity/top.sv
</source>
</big>

source_wrapper должен создать соединение между внутренним источником компоненты и внешней ее границей. Он делает это соединение, создавая свои порты, которые имеют тот же тип, что и тип портов lower-level, в нашем случае, тех, которые принадлежат к source.

<big><source lang="cpp">98 class source_wrapper extends ovm_component;
99
100 source s;
101 ovm_put_port #(trans_t) put_port1;
102 ovm_put_port #(trans_t) put_port2;
103
104 function new(string name, ovm_component parent);
105 super.new(name, parent);
106 endfunction
107
108 function void build();
109 s = new(“source”, this);
110 put_port1 = new(“put_port1”, this);
111 put_port2 = new(“put_port2”, this);
112 endfunction
113
114 function void connect();
115 s.first_put_port.connect(put_port1);
116 s.second_put_port.connect(put_port2);
117 endfunction
118
119 endclass
file: 04_OVM_mechanics/02_connectivity/top.sv
</source>
</big>

После того как порты в source_wrapper были созданы, они подключаются к портам lower-level компоненты source с помощью метода Connect. Видимость портов на более высоком уровне иерархии достигается таким же образом, как мы видим в sinker.
<big><source lang="cpp">
160 class sinker extends ovm_component;
161
162 ovm_put_export #(trans_t) first_put_export;
163 ovm_put_export #(trans_t) second_put_export;
164
165 sink sink1;
166 sink sink2;
167
168 function new(string name, ovm_component parent);
169 super.new(name, parent);
170 endfunction
171
172 function void build();
173 sink1 = new(“sink1”, this);
174 sink2 = new(“sink2”, this);
175 first_put_export = new(“first_put_export”, this);
176 second_put_export = new(“second_put_export”, this);
177 endfunction
178
179 function void connect();
180 first_put_export.connect(sink1.put_export);
181 second_put_export.connect(sink2.put_export);
182 endfunction
183
184 endclass
file: 04_OVM_mechanics/02_connectivity/top.sv
</source>
</big>

Два нижних уровня компоненты sink и exports создаются обычным способом. Затем они соединяются с помощью метода подключения export. Сейчас мы создаем port-export соединение между source_wrapper и sinker, также с помощью функции Connect.

<big><source lang="cpp">192 class env extends ovm_component;
193
194 sinker s;
195 source_wrapper sw;
196
197 function new(string name, ovm_component parent = null);
198 super.new(name, parent);
199 endfunction
200
201 function void build();
202 s = new(“sinker”, this);
203 sw = new(“source_wrapper”, this);
204 endfunction
205
206 function void connect();
207 sw.put_port1.connect(s.first_put_export);
208 sw.put_port2.connect(s.second_put_export);
209 endfunction
210
211 task run;
212 global_stop_request();
213 endtask
214
215 endclass
file: 04_OVM_mechanics/02_connectivity/top.sv

</source>
</big>

Для новых пользователей часто может вызвать трудности определить, порт или экспорт необходимо подключить и какой объект является аргументом. Вы можете легко понять это, следуя потоку управления через систему. Общее правило заключается в том, что запрашиваемый порт вызывается с помощью функции connect() и передачи в нее запрашиваемого port или export в качестве аргумента. Рисунок 4-4 показывает поток управления через иерархическую систему.

[[Файл:72.png]]

Порт – объект вызова и экспорт - объект вызванной функции или задачи. Вы можете воспринимать порты, как вызов экспорта. Так, в env, мы вызываем connect на put_ports с put_exports в качестве аргументов. Для port-to- port и export-to-export иерархии соединений, вызывающий будет чуть менее очевиден. Если вызов осуществляется со стороны порта, вы можете считать, что вызов lowest-level порта в иерархии является вызовом методов интерфейса upper-level порта. Аналогично, если экспорт объект вызова, вы можете считать upper-level экспорт вызовом lower-level export. В таблице ниже приведены возможные типы подключения:

[[Файл:73.png]]

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

В 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.)

== Фазы ==

Для традиционных модулей Verilog полная разработка проекта и его выполнение осуществялется в симуляторе. Так как OVM компоненты - это классы, они создаются и подключаются, и их выполнение начинается за пределами Verilog разработчика. Компоненты создаются вызовом конструктора класса операцией new(), которая выделяет память и выполняет инициализацию. В то время как Verilog время выполнения run-time engine managing instantiation, разработка, и выполнение компонент на основе классов, функциональность компонент разделена на фазы, и контроллер фазы OVM управляет их исполнением.

Каждая фаза представлена в компоненте как виртуального метода (задачи или функция) с тривиальной реализацией по умолчанию. Эти phase callbacks реализуются разработчиком компоненты, который обеспечивает соответствующую функциональность. Фаза контроллера гарантирует, что фазы выполняются в надлежащем порядке. Набор стандартных фаз показано в следующей таблице:

[[Файл:74.png]]

[[Файл:75.png]]

Каждая фаза имеет определенную цель. разработчики Компонент должны заботиться о том, чтобы функциональность реализованная в каждой фазе callback соответствовала фазе определения.

• '''New''' технически не является фазой, в том, что она не управляется фазой контроллера. Тем не менее, для каждого компонента, конструктор должен быть выполнен и завершен в целях создания компоненты. Таким образом, new должен выполниться до build() или любого другого последующего этапах выполнения.

• '''build''' это место, где новые компоненты, порты и экспорт создаются и настраиваются. Это также рекомендуемое место для вызова set_config_ * и get_config_ * (см. Section4.4).

• '''connect''' – место, где компоненты, порты и экспорт созданные в build() связываются.

• '''end_of_elaboration''' здесь вы можете выполнить изменение конфигураций, зная, что разработка уже завершена. То есть, вы можете предположить, что все компоненты созданы и соединены.

• '''start_of_simulation''' выполняется только до времени 0.

• '''run''' pre-defined task фазой. Все выполняемые задачи работают параллельно. Каждая выполняемая задача продолжается, пока ее управление не достигнет оператора EndTask или она явно будет прекращена. Позже в этой главе мы обсудим, как завершать testbenches.

• '''extract''' предназначен для сбора информации, касающейся покрытия или другой информации о том, как ответить на вопросы testbench.

• '''проверка''' - место, где выполняется любая проверка правильности или проверка валидации извлеченных данных.

• '''отчет''' -место , где делаются окончательные отчеты.

Ниже простой пример, использующий ovm_report_info () для иллюстрации порядка выполнения фаз.

<big><source lang="cpp">38 class sub_component extends ovm_component;
39
40 function new(string name, ovm_component parent);
41 super.new(name, parent);
42 endfunction
43
44 function void build();
45 ovm_report_info(“build”, ““);
46 endfunction
47
48 function void connect();
49 ovm_report_info(“connect”, ““);
50 endfunction
51
52 function void end_of_elaboration();
53 ovm_report_info(“end_of_elaboration”, ““);
54 endfunction
55
56 function void start_of_simulation();
57 ovm_report_info(“start_of_simulation”, ““);
58 endfunction
59
60 task run();
61 ovm_report_info(“run”, ““);
62 endtask
63
64 function void extract();
65 ovm_report_info(“extract”, ““);
66 endfunction
67
68 function void check();
69 ovm_report_info(“check”, ““);
70 endfunction
71
72 function void report();
73 ovm_report_info(“report”, ““);
74 endfunction
75
76 endclass
file: 04_OVM_mechanics/03_phases/top.sv

</source></big>

В компоненте верхнего уровня, мы создаем две компоненты, каждая из которых в свою очередь создает две sub_component. sub_components являющимися такими же, как и сами компоненты; каждая фаза обратного callback просто печатает строку, определяющую фазу. При выполнении, вы получите следующий результат:

<pre>OVM_INFO @ 0 [RNTST] Running test ...
OVM_INFO @ 0: env.c1 [build]
OVM_INFO @ 0: env.c1.s1 [build]
OVM_INFO @ 0: env.c1.s2 [build]
OVM_INFO @ 0: env.c2 [build]
OVM_INFO @ 0: env.c2.s1 [build]
OVM_INFO @ 0: env.c2.s2 [build]
OVM_INFO @ 0: env.c1.s1 [connect]
OVM_INFO @ 0: env.c1.s2 [connect]
OVM_INFO @ 0: env.c1 [connect]
OVM_INFO @ 0: env.c2.s1 [connect]
OVM_INFO @ 0: env.c2.s2 [connect]
OVM_INFO @ 0: env.c2 [connect]
OVM_INFO @ 0: env.c1.s1 [end_of_elaboration]
OVM_INFO @ 0: env.c1.s2 [end_of_elaboration]
OVM_INFO @ 0: env.c1 [end_of_elaboration]
OVM_INFO @ 0: env.c2.s1 [end_of_elaboration]
OVM_INFO @ 0: env.c2.s2 [end_of_elaboration]
OVM_INFO @ 0: env.c2 [end_of_elaboration]
OVM_INFO @ 0: env.c1.s1 [start_of_simulation]
OVM_INFO @ 0: env.c1.s2 [start_of_simulation]
OVM_INFO @ 0: env.c1 [start_of_simulation]
OVM_INFO @ 0: env.c2.s1 [start_of_simulation]
OVM_INFO @ 0: env.c2.s2 [start_of_simulation]
OVM_INFO @ 0: env.c2 [start_of_simulation]
OVM_INFO @ 0: env.c2 [run]
OVM_INFO @ 0: env.c2.s2 [run]
OVM_INFO @ 0: env.c2.s1 [run]
OVM_INFO @ 0: env.c1 [run]
OVM_INFO @ 0: env.c1.s2 [run]
OVM_INFO @ 0: env.c1.s1 [run]
OVM_INFO @ 1: env.c1.s1 [extract]
OVM_INFO @ 1: env.c1.s2 [extract]
OVM_INFO @ 1: env.c1 [extract]
OVM_INFO @ 1: env.c2.s1 [extract]
OVM_INFO @ 1: env.c2.s2 [extract]
OVM_INFO @ 1: env.c2 [extract]
OVM_INFO @ 1: env.c1.s1 [check]
OVM_INFO @ 1: env.c1.s2 [check]
OVM_INFO @ 1: env.c1 [check]
OVM_INFO @ 1: env.c2.s1 [check]
OVM_INFO @ 1: env.c2.s2 [check]
OVM_INFO @ 1: env.c2 [check]
OVM_INFO @ 1: env.c1.s1 [report]
OVM_INFO @ 1: env.c1.s2 [report]
OVM_INFO @ 1: env.c1 [report]
OVM_INFO @ 1: env.c2.s1 [report]
OVM_INFO @ 1: env.c2.s2 [report]
OVM_INFO @ 1: env.c2 [report]
</pre>

Вы видите, что build()выполняется сверху вниз и остальные фазы запуска снизу вверх. Вы также можете видеть, что каждый этап завершается во всех компонентах до начала следующего этапа. Таким образом, в connect(), например, вы можете расчитывать, что build() завершена во всех компонентах. Вы также заметите, что время запускается после фазы run. В нашем примере задача run - тривиальна, она просто выполняет задержку времени на единицу (# 1).

un_test (), упоминалось ранее в разделе 4.1, инициирует фазу выполнение. Он начинает выполнение фаз по порядку и контролирует, что каждый этап завершен до начала следующего.

== Config ==

Для увеличения повторного использования компонент, желательно объявит их с параметрами, которые могут быть внешне настроены. Конфигурационные средства обеспечивают возможности для этого. Они основаны на базе пар имя-значение, и называются configuration items, которые организованы иерархически. Каждая компонента содержит таблицу конфигураций элементов конфигурации, так как компоненты организованы в качестве дерева, каждый элемент в базе данных может быть уникально размещен по расположению компоненты и имени элемента конфигурации

[[Файл:76.png]]

Класс ovm_component содержит два набора методов для конфигурации размещения элементов в базу данных и потом для их получения. Это set_config_ * и * get_config_. В таблице ниже приведены оба набора.

[[Файл:77.png]]

Set_config_ * функция помещает элемент в конфигурационную базу данных текущего компонента, то есть в экземпляре компонента, в котором функция вызывается. Каждая из этих функций принимают три аргумента, имя, field_name и значение. Аргумент name - имя пути, который представляет набор компонент, которые должны соответсвовать кофигурациям этого элемента. name используется в * get_config_, чтобы найти элементы в базе данных конфигурации. field_name - это имя поля и должно быть уникальным в пределах текущей базы конфигураций. value является частью пары имя-значение и его тип может быть строка, INT, или ovm_object, в зависимости от вызываемой функции. Кроме того, set_config_object принимает копию аргумента для указания, был ли объект передан в качестве значения так как значение должно быть клонировано прежде чем оно будет помещено в базу конфигурации.
Функции get_config_ * извлекает элементов из базы данных конфигураций. Эти функции принимают только два аргумента, имя поля и INOUT переменную, который содержит значение расположения элемента. Они также возвращают бит, чтобы указать был ли удачно расположен запрашиваемый объект. * Get_config_ функции не принимают аргументы имени пути, как их set_config_ * коллеги, поскольку они используют путь к текущему компоненту, как ссылку, чтобы найти элементы конфигурации. Они разработаны, чтобы узнать, есть значение элемента конфигурации для текущего контекста, то есть, компонент, в котором функция get_config_ * вызывается.

Алгоритм поиска для извлечения элементов конфигурации использует имя пути компонента запроса и путь к файлу вставляемый в каждый item. Он начинается с поиска конфигурационных элементов в базе данных в верхней компоненте по field_name. Если такой элемент существует, то он затем спрашивает, соответствует ли указанный путь к файлу пути имени компоненты. Если элемента с указанным field_name нет или имена путей не совпадают, то поиск идет с дочерней компоненты. Этот процесс продолжается до соответствия или до достижения компоненты начала поиска.

Путь каждого элемент конфигурации может быть регулярным выражением. Таким образом, мы используем алгоритм соответствия регулярных выражений для нахождения совпадения с путем запрошенной компоненты и именем пути элемента конфигурации. Эффект заключается в соответствии иерархической области.
В качестве примера, рассмотрим простую иерархию на рисунке 4-5. Давайте предположим, что в env::build()мы запускаем два вызова set_config_ *:

<big>
<source lang="cpp">112 function void build();
113 c1 = new(“c1”, this);
114 c2 = new(“c2”, this);
115
116 set_config_int(“c2.*”, “i”, 42);
117 set_config_int(“*”, “t”, 19);
118 endfunction
file: 04_OVM_mechanics/04_config/top.sv

</source></big>

Это вызовет запись двух конфигурационных элементов в базу данных в env. Обратите внимание на звездочку (*) в имени пути. Имя пути в вызове set_config_ * - регулярное выражение, и дикие символы используются для указать несколько областей, к которыми элемент применяется. По элементу i, c2. * показывает, что в любой области ниже c2 в иерархии, i будет определять указанное значение. В этом случае указанное значение - 42. Если вы опустите звездочку, то элемент конфигурации применяется только к c2, а не к любому из своих потомков.
Состояние конфигурации базы данных для каждого компонента в иерархии после вызова set_config_ * показано на рисунке 4-6,

[[Файл:78.png]]

пусть в элементе top.c1.child1 мы осуществим вызов:

<big><source lang="cpp">int i;
...
get_config_int(“i”, i)
</source></big>

Поиск задает вопрос: Каково значение конфигурации i в иерархических рамках top.c1.child1? Чтобы ответить на этот вопрос, конфигурации базы данных в env ищется в первую очередь. Запись i там говорит, что значение i совпадающее с env.c2. * - 42. Тем не менее, компоненты, из которых был сделан запрос, находятся в c1 sub-hierarchy. Таким образом, не существует соответствия, а get_config_int () возвращает статус неудачи. Запрос в любую компоненту, которая является дочерней c2 будет успешно завершен и вернется значение 42.

Ниже приведен код для функцию build() дочерней компоненты. Это место где эти компоненты ищут конфигурационные значения i и t.

<big><source lang="cpp">60 function void build();
61
62 string msg;
63
64 if(!get_config_int(“t”, t)) begin
65 $sformat(msg, “no value for t found in config
database, using default value of %0d”, t);
66 ovm_report_warning(“build”, msg);
67 end
68
69 if(!get_config_int(“i”, i)) begin
70 $sformat(msg, “no value for i found in config
database, using default value of %0d”, i);
71 ovm_report_warning(“build”, msg);
72 end
73
74 endfunction
file: 04_OVM_mechanics/04_config/top.sv
</source></big>

Следующий пример показывает вывода при выполнении этого проекта:

<pre># OVM_INFO @ 0 [RNTST] Running test ...
# OVM_WARNING @ 0: env.c1.child1 [build] no value for i found in
config database, using default value of 91
# OVM_WARNING @ 0: env.c1.child2 [build] no value for i found in
config database, using default value of 91
</pre>

Запрос на конфигурационный элемент 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 организован таким же образом.

== Factory(Фабрика) ==

Структура testbench определяется организацией компонент в иерархии и то, как эти объекты связаны между собой. Поведение testbench определяется процедурным кодом в фазе callbacks—build, connect, run и так далее. Есть моменты, когда это необходимо изменить поведение или часть структуры извне(снаружи), то есть во время выполнения, не касаясь, кода testbench. Например, чтобы ввести ошибку в систему, вы можете заменить обычный драйвер драйвером с ошибкой, который умышленно вводит ошибки. Вместо повторного кодирования окружающей среды для использования другого драйвера, вы можете использовать factory, чтобы сделать замену автоматически.

Factory обеспечивает средства для замены одного объекта на другой без использования текстового редактора для изменения testbench. Вместо создания объект с помощью new(), вы вызываете функцию create из factory. Factory хранит список зарегистрированных объектов и, при необходимости, набор переопределения связанный с каждой из них. При создании объекта с помощью factory, список переопределения проверяется на наличие такого объекта. Если он есть, то переопределенный объект возвращается. В противном случае, зарегистрированный объект возвращается.

Factory является OVM структурой данных. Она глобальна в области видимости, и только один элемент factory может существовать (то есть, это singleton). Она служит в качестве полиморфных конструкторов, одна функция, которая позволяет создавать различные объекты. Она обеспечивает средства для регистрации объектов, и для их переопределения. Объекты, зарегистрированные как переопределения, должны быть производным от объекта, от которого они переопределялись. Для того, чтобы одна функция возвращала несколько объектов, каждый из этих объектов должны быть получен от общего базового класса.
Важным компонентом factory является оболочка, класс, который описывает объект, который мы хотим создать с помощью factory. Структура данных factory основывается на таблице оболочек, проиндексированной по ключу. Оболочка имеет функцию create(), которая обращается к конструктору обернутого объекта.

Использование factory состоит из трех этапов: регистрация, настройки переопределение и создание. На первом этапе необходимо зарегистрировать объект с помощью factory. На втором шаге, добавляется переопределение зарегистрированного объекта. На третьем этапе, вы создаете объект с помощью factory, который будет возвращать либо первоначально зарегистрированный объект или переопределенный, в зависимости от того, переопределение было передано в качестве запрашиваемого объекта.

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

Термин factory-Фабрика был придуман The Gang of Four для использования в программном обеспечении в их книге Design Patterns: Elements of Reusable Object-Oriented Software. В этой книге, они определили шаблон, который они называют abstract factory, как интерфейс для создания семейств связанных объектов. Они определили шаблон factory method в качестве интерфейса для создания объектов, относящихся к подклассам для определения, какой объект создавать. Factory в OVM является комбинацией этих двух шаблонов. Она предоставляет средства для создания семейства объектов, а также предоставляет средства для определения, какой именно объект создавать структуре данных фабрики.

Factory OVM основана на структуре данных, которая отображает необходимые типы в переопределенные. По сути, организация представляет собой ассоциативный массив типов, ключом в котором является также тип. При регистрации типа при помощи фабрики, его переопределенным типом является он сам. Таким образом, по умолчанию, когда вы запрашиваете объект этого типа, вы получаете только тип. Фабрика также предоставляет средства для замены переопределенных типов другими типами, чтобы вы могли получить переопределенные типы, которые отличаются от зарегистрированных типов.

[[Файл:79.png]]

Следующий пример является сильно упрощенной фабрикой, которая показывает, как OVM фабрика работает. Фабрика сохраняет основные структуры OVM фабрики, но многие детали были удалены для более понятной иллюстрации. Наша фабрика реализуется в четырех классах, двух базовых классах и двух производных классах, которые делают реальную работу. Двумя базовыми классами являются object_base и wrapper_base. Все объекты, зарегистрированные в фабрике, должны быть получены (в конечном счете) от object_base, а wrapper_base является базовым классом для параметризованной обертки. Factory - это singleton, который содержит ассоциативный массив, содержащий экземпляры обертки. Наконец, обертки являются производными от wrapper_base и параметризованными классами, которые представляют уникальные типы.

Для нашей фабрики, базовые классы тривиальны:

<big><source lang="verilog">46 class object_base;
47 virtual function void print();
48 $display(“object_base”);
49 endfunction
50 endclass
file: 04_OVM_mechanics/07_toy_factory/top.sv
59 class wrapper_base;
60 virtual function object_base create_object();
61 return null;
62 endfunction
63 endclass
file: 04_OVM_mechanics/07_toy_factory/top.sv</source></big>

object_base имеет виртуальную функцию print(), которую мы используем для проверки типов, созданных на фабрике. wrapper_base имеет виртуальную функцию create(), полиморфный конструктор, который используется для создания новых объектов.
factory - это singleton, то есть его конструктор локальный, и он содержит статическую ссылку на самого себя. Единственный способ создать экземпляр factory является вызов factory::get(). factory содержит ассоциативный массив, который отображает запрашиваемые типы wrapper_base в переопределенные типы wrapper_base.

<big><source lang="verilog">73 class factory;
74
75 static factory f;
76 wrapper_base override_map[wrapper_base];
77
78 local function new();
79 endfunction
80
81 static function factory get();
82 if(f == null)
83 f = new();
84 return f;
85 endfunction
86
87 function void register(wrapper_base w);
88 override_map[w] = w;
89 endfunction
90
91 function void set_override(wrapper_base requested_type,
92 wrapper_base override_type);
93 override_map[requested_type] = override_type;
94 endfunction
95
96 function object_base create(wrapper_base
97 requested_type);
98 object_base obj;
99 wrapper_base override_type =
100 override_map[requested_type];
101 obj = override_type.create_object();
102 return obj;
103 endfunction
104
105 endclass
file: 04_OVM_mechanics/07_toy_factory/top.sv
</source></big>

Метод register() добавляет новую запись в карту. Первоначально, при регистрации, тип не имеет переопределения. Таким образом, мы записали в карту тип, указывающий сам на себя. Set_override () метод заменяет запись в карте новым переопределенным типом. create() метод ищет переопределения на указанный тип, инициирует создание переопределенного типа и возвращает вновь созданный объект.
Класс-оболочка является наиболее интересным классом в нашем созвездии factory-related классов. Хотя он довольно прост, он делает большую часть тяжелой работы. Это основной интерфейс для фабрики, и большинство операций, которые производятся фабрикой, проходят через интерфейс оболочки.

<big><source lang="verilog">118 class wrapper #(type T=object_base) extends wrapper_base;
119
120 typedef wrapper#(T) this_type;
121
122 static this_type type_handle = get_type();
123
124 local function new();
125 endfunction
126
127 function object_base create_object();
128 T t = new();
129 return t;
130 endfunction
131
132 static function T create();
133 T obj;
134 factory f = factory::get();
135 assert($cast(obj, f.create(get_type())));
136 return obj;
137 endfunction
138
139 static function this_type get_type();
140 factory f;
141 if(type_handle == null) begin
142 type_handle = new();
143 f = factory::get();
144 f.register(type_handle);
145 end
146 return type_handle;
147 endfunction
148
149 static function void set_override(wrapper_base
150 override_type);
151 factory f = factory::get();
152 f.set_override(type_handle, override_type);
153 endfunction
154
155 endclass
file: 04_OVM_mechanics/07_toy_factory/top.sv</source>
</big>

Все функции в wrapper#() являются статическими, за исключением конструктора и create_object (). Мы можем выполнить его статические функции, не заботясь о том, был ли они явно создан экземпляр класса. Так как каждая обертка специализации уникальна. Это означает, что статическая переменная type_handle является уникальной и может быть использован в качестве прокси-сервера для обернутого типа (то есть, типа, передающегося в качестве параметра, который используется для специализации класса). Так как тип является уникальным, и большинство методов являются статическими, мы можем рассматривать типа больше как тип, а не объект.

Тип инициализируется статически. Это происходит в следующей строке:

<big><source lang="verilog">static wrapper#(T) type_handle = get_type();</source></big>

Функция get_type () вызывается во время статической инициализации, которая не только создает экземпляр оболочки, но и регистрирует его в фабрике. Для регистрации класса в фабрике, сначала специализируется обертка с типом объекта, который вы оборачиваете. Используйте typedef для специализации оболочки, как показано в следующем примере:

<big><source lang="verilog">typedef wrapper#(some_type) type_id;</source>
</big>

Это определение типа создает оболочку для SOME_TYPE типа, тип, производный от object_base.
Рисунок 4-8 иллюстрирует, как использовать фабрику с некоторыми классами A, B, и С, которые являются производными от family_base.

[[Файл:80.png]]

Чтобы зарегистрировать классы с помощью фабрики, каждый из них имеет typedef из обертки, параметризованной со своим типом. Ниже класс А. Класс B и C похожи. Каждый из них имеет typedef, которая специализируется обертку.

<big><source lang="verilog">169 class A extends family_base;
170
171 typedef wrapper#(A) type_id;
172
173 virtual function void print();
174 $display(“A”);
175 endfunction
176 endclass
file: 04_OVM_mechanics/07_toy_factory/top.sv</source>
</big>
Ниже приводится короткая программа, которая использует фабрику.

<big><source lang="verilog">206 function void run();
207
208 f = factory::get();
209
210 h = family_base::type_id::create();
211 h.print();
212
213
family_base::type_id::set_override(B::type_id::get_type());
214
215 h = family_base::type_id::create();
216 h.print();
217
218 endfunction
file: 04_OVM_mechanics/07_toy_factory/top.sv
</source></big>

При написании кода интенсивно используют оператор (::), он используется для обращения к статической функции в 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.

=== The OVM Factory API ===

В этом разделе мы рассмотрим более подробно API OVM фабрики. Он состоит из двух частей, type-based фабрики и string-based фабрики. В string-based фабрике запрашиваемый тип идентифицируются строкой имени. В type-based фабрике, тип идентифицируются по поддерживаемому типу(????). Один тип может быть зарегистрирован двумя способами. Методы выполнения трех этапов (регистрация, установка коррекции, и создание) немного отличаются в каждом случае. Сначала мы рассмотрим type-based фабрику. Вот компонент, называемый драйвер, который регистрирует себя на основе type-based фабрики.

<big><source lang="cpp">49 class driver extends ovm_component;
50
51 typedef ovm_component_registry#(driver) type_id;
52
53 static function type_id get_type();
54 return type_id::get();
55 endfunction
56
57 function string get_type_name();
58 return “driver”;
59 endfunction
60
61 function new(string name, ovm_component parent);
62 super.new(name, parent);
63 endfunction
64
65 endclass
file: 04_OVM_mechanics/06_factory/top.sv
</source>
</big>

Есть две части для регистрации, поддержка typedef ovm_component_registry # () и supplying статической функции get_type ().typedef создает специализацию ovm_component_registry помощью компонент типа драйвер в качестве параметра. ovm_component_registry # () класс имеет статический инициализатор, который регистрирует, используя структуру фабрики. Таким образом, создание специализации, используя typedef , влечет за собой идентификацию класса по параметру, driver в этом случае, должен быть зарегистрирован в фабрике.
Задание переопределения является простой причиной вызова функции set_override и передача переопределенного типа в качестве аргумента, как показано ниже:

<big><source lang="cpp">105
driver::type_id::set_type_override(error_driver::get_type());
file: 04_OVM_mechanics/06_factory/top.sv
</source></big>

Эта строка выглядит довольно сложными, но на самом деле, это довольно просто. Давайте преобразуем выражение, чтобы полностью понять, что оно значит.

driver – запрашиваемый тип.

driver::type_id – тип обертки.

driver::type_id::set_type_override – the set override function in the specialized wrapper. This is a static function, which is why
you need the :: scope operator to refer to it.

error_driver – переопределенный тип.

error_driver::get_type() – статическая функция, возвращаемая тип, поддерживаемый error_driver.

Для создания экземпляра класса с помощью фабрики, мы называем метод создания фабрики, как показано ниже:

<big><source lang="cpp">102 d1 = driver::type_id::create(“d1”, this);
file: 04_OVM_mechanics/06_factory/top.sv
</source></big>

Синтаксис :: работает так же, как и в предыдущем примере - driver относится к запрашиваемому типу, driver::type_id относится к типу специализированной обертки и driver::type_id::create относится к функции создать в специализированной обертке. Этот оператор создает экземпляр driver. Разница между вызовом Create () и new() является то, что create() обращаться к фабрике на наличие переопределенных типов. Если это так, Create () возвращает объект переопределенного типа.

Теперь давайте рассмотрим string-based фабрику. Механизм регистрации string-based фабрики опирается на определение типа как на основе типа фабрики, как показано ниже:

<big><source lang="cpp">48 typedef ovm_component_registry#(driver, “driver”)
type_id;
</source></big>

Единственная разница заключается в добавлении второго параметра параметризованной обертки. Он определяет имя типа, в этом случае driver. Когда ovm_component_registry # () специализируется с двумя параметрами, тип и имя, оболочка регистрирует в с type-based фабрике и на string-based фабрике. Чтобы установить переопределение, используя имя типа, необходимо вызвать API фабрики напрямую, а не использовать обертку API, как показано ниже:

<big><source lang="cpp">106 factory.set_type_override_by_name(“driver”,
107 “error_driver”);
</source></big>

Это утверждение просто говорит, когда необходимо создать объект, имя типа которого driver, возвращать тип, имя которого error_driver вместо этого. Главная разница между использованием string-based и type-based фабрик в том, как создаются объекты. В type-based API, вы получаете доступ к фабрике через оболочку. В string-based API, вы вызываете фабрику напрямую. Тип возвращаемого ovm_factory :: create_component_by_name () является ovm_component. Сравните это с возвращаемым типом
ovm_component_registry (T)::Create, который T. Чтобы получить доступ к предполагаемому типу возвращаемого объекта вам придется downcast его, как показано ниже:

<big><source lang="cpp">99 assert($cast(d1,
100 factory.create_component_by_name(“driver”,
101 ““,
102 “d1”,
103 this)));
</source></big>

Вызов factory.create_component_by_name () возвращает объект типа ovm_component.$ $cast downcasts возвращается объект типа d1, который является driver. Поскольку тип аргумента create_component_by_name () является строкой, нет никакой проверки во время компиляции, что тип возвращаемого объекта приведен к требуемому типу. Поэтому важно, чтобы проверялся код возвращаемого значения $cast, для определения удалось ли приведение. Фабрика string-based API включает в себя create_object_by_name(). Она используется для создания объектов, производных от ovm_object. Вы должны вызвать $cast to downcast созданный объект по той же причине вы вызываете cast в компонентах, созданных string-based фабрики API.

=== String-Based or Type-Based? ===

type-based и string-based фабрики API, каждая имеет свои плюсы и минусы, но, как правило, мы рекомендуем вам использовать type-based фабрику. Она гораздо более надежная, защищена от ошибок в строке названия.

Иногда нет другого выбора; только на string-based фабрику можно использовать. Важным примером этого является, когда вы хотите указать название теста с командной строки. run_test () принимает необязательный строковый аргумент, test_name. Кроме того, эта задача проверяет OVM_TESTNAME аргумент командной строки. Если тестовое имя поддерживается командной строкой либо списком аргументов, run_test () вызывает string-based фабрику для создания экземпляра объекта.

string-based фабрика страдает от двух существенных недостатков. Один из них, уже упоминался, это то, что легко неправильно ввести имя типа, когда вы пишете код. Это может привести к ошибке testbench, потому что невозможно найти объект, или in a subtle bug where the wrong object is instantiated. Вторым недостатком является то, что это трудно, если нет возможности объявить параметризованный класс с использованием строки названия. Рассмотрим, например, параметризованный класс my_class.

<big><source lang="cpp">class my_class #(type T=int) extends ovm_object;
typedef my_class#(T) this_t;
typedef ovm_object_registry#(this_t, “my_class#(T)”) type_id;
endclass
</source></big>

Мы зарегистрировали его на string-based фабрики, используя имя my_class # (T). Кажется логичным. Теперь рассмотрим две специализации этого класса.

<big><source lang="cpp">typedef my_class#(A) C1;
typedef my_class#(B) C2;
</source></big>

Не существует удобного способа регистрации их фабрикой с использованием имен, которые являются уникальными для специализации. В наших классах в примере, С1 и С2 зарегистрированы с использованием имени my_class # (T). В структуре данных фабрики, это выглядит так, как будто вы пытаетесь зарегистрировать два объекта с одним и тем же именем, что является ошибкой. The remedy is to use the type-based factory API, which is not encumbered with strings

<big><source lang="cpp">class my_class #(type T=int) extends ovm_object;
typedef my_class#(T), this_t;
typedef ovm_object_registry#(this_t) type_id;
endclass
</source></big>

Оставляя второй аргумент в typedef из type_id, мы говорим фабрике зарегистрировать объект без имени, использовать только тип как ключ поиска. Теперь у специализаций будут свои собственные уникальные типы, и не будет ошибочно считаться, что это один и тот же объект в фабрике.

Недостатком использования 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 будут убиты.

Файл:81.png

2013-04-01T10:26:42Z

Anastasiya:

OVM/OVM методология/Механика OVM

2013-03-28T08:21:21Z

Anastasiya:

OVM/OVM методология/Механика OVM

2013-03-25T11:06:20Z

Anastasiya:

{{OVM TOC}}
__TOC__

= Механика OVM =

Библиотека OVM предоставляет много возможностей для построения testbenches. В этой главе мы ознакомимся с наиболее важными возможностями, которые вы будете использовать почти во всех ваши testbenches.

== Компоненты и иерархия ==

Первичная структура для создания элементов testbench является компонента. Компонента в OVM – это аналогия модулю в Verilog. Компонента OVM сконструирована на основе класса, который обеспечивает ему различные характеристики, чем модуль Verilog и имеет различные использования импликаций. Среди таких характеристик является то, что классы создаются во время выполнения, а не во время разработки, как модули. Таким образом, OVM отвечает за создание компонента и сборки их в иерархии.

{|
|[[Файл:69.png]]
|<graph>
digraph G{
node[shape="circle",fontsize="11",margin="0.03,0.03"]
edge[arrowhead=none]
env -> {c1 c2}
c1 -> {child11 child12}
c2 -> {child21 child22}
child11 [label="child1"]
child12 [label="child2"]
child21 [label="child1"]
child22 [label="child2"]
}
</graph>
|}

Рисунок 4-1 иллюстрирует простую иерархию компонент. После мы покажем, как построить эту иерархию с помощью средств OVM для создания компонент и объединения их в иерархии:

Самый верхний узел, ENV, является корнем. Корень отличается тем, что он не имеет предка. Все остальные узлы имеют только одного предка. Каждый узел имеет имя. Расположение каждого узла в иерархии может быть идентифицировано уникальным full_name (путем), который строится на нанизывании имен всех узлов между корнем и узлов в запросе, разделяя их сепаратором иерархии, точкой (.). Например, путь к компоненту, второго потомка с2 - top.c2.child2.

Компонент в ОВМ является классом, производным от ovm_component. Простейшая компоненты - листья, те, которые не имеют потомков.

<big><source lang="cpp">57 class child extends ovm_component;
58
59 function new(string name, ovm_component parent);
60 super.new(name, parent);
61 endfunction
62
63 endclass
file: 04_OVM_mechanics/01_hierarchy/top.sv</source></big>

Конструктор имеет два параметра, имя компоненты и указатель на его предка. Название - простое имя, а не иерархический путь. Предок предоставляет место для подключения новой компоненты в иерархии. Полный путь потомка создается путем объединения имени потомка с полным именем предка, разделенный точкой (.).OVM предоставляет методы для получения и имени и полного пути компоненты:

<big><source lang="cpp">string get_name();
string get_full_name();</source>
</big>

Подчиненные компоненты создаются в функции build(), которая вызывается на этапе сборки (фазы объясняется далее в этой главе). Создание экземпляра компонента включает вызов new() для выделения памяти для нее и передачи соответствующих параметров в конструктор. В компоненте, показанной ниже, мы создаем две подчиненные компоненты, и child1 child2.

<big><source lang="cpp">71 class component extends ovm_component;
72
73 child child1;
74 child child2;
75
76 function new(string name, ovm_component parent);
77 super.new(name, parent);
78 endfunction
79
80 function void build();
81 child1 = new(“child1”, this);
82 child2 = new(“child2”, this);
83 endfunction
84
85 endclass
file: 04_OVM_mechanics/01_hierarchy/top.sv</source></big>

Как component, ENV также создает экземпляры двух подчиненных компонент, c1 и c2. Вся иерархия с корнем в модуле, называемым top в нашем проекте.(??)

<big><source lang="cpp">131 module top;
132
133 env e;
134
135 initial begin
136 e = new(“env”);
137 run_test();
138 end
139
140 endmodule
file: 04_OVM_mechanics/01_hierarchy/top.sv</source></big>

Вызов new() создает верхний уровень окружающей среды. run_test () начинает выполнение testbench.

В SystemVerilog, модули, интерфейсы и программные блоки создаются во время разработки, в то время как классы создаются после разработки, во время выполнения. Таким образом, чтобы создать иерархию классов, мы должны иметь интерфейс, модуль или программу, который содержит начальный блок, который начинает процесс создание компонент иерархии, основанных на классах. Интерфейсы предназначены для использования в качестве средства связи между двумя модулями и не очень хорошо подходят для использования в качестве корня иерархии классов. Программные блоки или модули могут быть использованы как корень (??). Для нашей простой иерархии, это не имеет значения. Позже, когда мы подключаем класс-компонент для модуля на основе аппаратных средств, мы увидим, что использование модуля предпочтительнее программным блокам.

=== Перемещение по иерархии ===

Мы можем исследовать структуры данных, используемые для реализации компонента иерархии с некоторыми методами, предусмотренными в ovm_component. Потомки компоненты хранятся в ассоциативном массиве. Этот массив напрямую не доступен, но он может быть доступен через иерархию API. Этот API-интерфейс похож на встроенные методы SystemVerilog, предназначенные для ассоциативных массивов.

<big><source lang="cpp">int get_first_child(ref string name);
int get_next_child(ref string name);
ovm_component get_child(string name);
int get_num_children();
</source></big>

get_first_child () и get_next_child () работают вместе для перебора множества потомков, содержащихся в компоненте. get_first_child () извлекает имя первого ребенка в списке. Он возвращает имя в качестве ссылки. get_next_child () возвращает имя следующего ребенка в списке. Он возвращает 1, если имеется следующая имя потомка и 0, если был достигнут конец списка. get_child () преобразует имя в ссылку компоненты.

Используя эти функции, мы можем пройти по компонентам иерархии.

<big><source lang="cpp">73 function void depth_first(ovm_component node,
74 int unsigned level = 0);
75
76 string name;
77
78 if(node == null)
79 return;
80
81 visit(node, level);
82
83 if(node.get_first_child(name))
84 do begin
85 depth_first(node.get_child(name), level+1);
86 end while(node.get_next_child(name));
87
88 endfunction
file: 04_OVM_mechanics/utils/traverse.svh
</source>
</big>

Эта функция будет осуществляющая обход в глубину иерархии, называя visit(). Мы используем get_first_child () и get_next_child () для перебора списка каждого потомка в каждом узле. Для каждого итерации мы вызываем depth_first () рекурсивно. Для нашего маленького проекта, результат будет следующий:

<big><pre>+ env
| + env.c1
| | env.c1.child1
| | env.c1.child2
| + env.c2
| | env.c2.child1
| | env.c2.child2
</pre></big>

Функция visit() использует глубину узла и определяет является ли он конечным для печати строки каждого узла.

=== Singleton Top ===

Компоненты, которые не имеют предков (то есть, параметр предок в конструкторе является нулевым) называют orphans.(??) В OVM вы можете создать столько компоненты без предков, сколько вам необходимо. Тем не менее, не существует такого понятия, как истинные orphans. Любой компонент, чей предок является null, относится к встроенному предку, называемому ovm_top. ovm_top состоит из одного экземпляра ovm_root. Это предок всех компонент, которые имеют предков. В самом деле, env в нашем предыдущем примере является потомком ovm_top. Так как он не имеет предка, то автоматически получают ovm_top в качестве родителя.

singleton - широко известный объектно-ориентированных шаблон проектирования, который имеет private (local) или protected конструкторы и статическую функцию get, которая возвращает тот же самый указатель не смотря на то, сколько раз она вызывается. Это означает, что возможно существование одного экземпляра, и что экземпляр создается автоматически при вызове функции get. ovm_top содержит дескриптор экземпляра singleton ovm_root(???). Он статически инициализируется при вызове ovm_root :: Get (). Вы можете вызвать ovm_root :: Get () в любое время, но в этом нет необходимости, так как ovm_top предусматривает это.

Есть целый ряд полезных следствий существования singleton top-level компоненты. Одним из них является, что вы можете достичь любую компоненту из ovm_top. Если вы запустили алгоритм обхода иерархии, начиная с ovm_top, вы доберетесь до каждой компоненты в системе. Другим следствием является то, что любая компонента, включая порты, экспорт и каналы, которые создаются внутри модуля, достижима из ovm_top. Если вы хотите изменить отчет во всех обработчиках компонент, вы можете сделать это, вызвав одну из иерархических функции отчетности в ovm_top. ovm_top содержит все механизмы синхронизации, которые объясняются далее в этой главе.

== Connectivity ==

Компоненты соединены друг с другом через TLM port и exports. Port и exports обеспечивают средства для компонент, или, точнее, процессы в компонентах для синхронизации и связи друг с другом. Port и exports - объекты, которые образуют пункт связывания для обеспечения межкомпонентной связи. Как уже говорилось в предыдущей главе, exports обеспечивают функции и задачи, которые могут быть вызваны из Port.

[[Файл:70.png]]

Метод connect портов и exports используется для связывания их вместе.

initiator_port.connect(target.export)

Этот метод создает ассоциацию, или связывание, между port и export так, что port может вызывать(запускать) задачи и функции из export. Для успешного соединения, типы port и export должны совпадать. То есть, типы интерфейсов должны быть одинаковыми, и тип объекта, передающегося в интерфейс должны быть одинаковыми.

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

Как и контактами в RTL дизайне, нам нужно подключиться к портам TLM через иерархические границы. Рисунок 4-3 использует простой дизайн, чтобы показать, как сделать эти соединения. Этот проект содержит исходную компоненту с двумя port(выходами), которые в конечном итоге подключаются к двум входам(export). Для осуществления подключения между этими компонентами, мы должны расширить port и export на уровень выше в иерархии.

[[Файл:71.png]]

Компонент source содержит два порта, и first_put_port, second_put_port.

<big><source lang="cpp">65 class source extends ovm_component;
66
67 ovm_put_port #(trans_t) first_put_port;
68 ovm_put_port #(trans_t) second_put_port;
69
70 function new(string name, ovm_component parent);
71 super.new(name, parent);
72 endfunction
73
74 function void build();
75 first_put_port = new(“first_put_port”, this);
76 second_put_port = new(“second_put_port”, this);
77 endfunction
file: 04_OVM_mechanics/02_connectivity/top.sv</source>
</big>

Кроме того, компонента sink создает экспорт и создает его в функции build. Экспорт связан с внутренним каналом, FIFO, от которого компонента может получать объекты во время выполнения.

<big><source lang="cpp">126 class sink extends ovm_component;
127
128 ovm_put_export #(trans_t) put_export;
129 local tlm_fifo #(trans_t) fifo;
130
131 function new(string name, ovm_component parent);
132 super.new(name, parent);
133 endfunction
134
135 function void build();
136 put_export = new(“put_export”, this);
137 fifo = new(“fifo”, this);
138 endfunction
139
140 function void connect();
141 put_export.connect(fifo.put_export);
142 endfunction
file: 04_OVM_mechanics/02_connectivity/top.sv
</source>
</big>

source_wrapper должен создать соединение между внутренним источником компоненты и внешней ее границей. Он делает это соединение, создавая свои порты, которые имеют тот же тип, что и тип портов lower-level, в нашем случае, тех, которые принадлежат к source.

<big><source lang="cpp">98 class source_wrapper extends ovm_component;
99
100 source s;
101 ovm_put_port #(trans_t) put_port1;
102 ovm_put_port #(trans_t) put_port2;
103
104 function new(string name, ovm_component parent);
105 super.new(name, parent);
106 endfunction
107
108 function void build();
109 s = new(“source”, this);
110 put_port1 = new(“put_port1”, this);
111 put_port2 = new(“put_port2”, this);
112 endfunction
113
114 function void connect();
115 s.first_put_port.connect(put_port1);
116 s.second_put_port.connect(put_port2);
117 endfunction
118
119 endclass
file: 04_OVM_mechanics/02_connectivity/top.sv
</source>
</big>

После того как порты в source_wrapper были созданы, они подключаются к портам lower-level компоненты source с помощью метода Connect. Видимость портов на более высоком уровне иерархии достигается таким же образом, как мы видим в sinker.
<big><source lang="cpp">
160 class sinker extends ovm_component;
161
162 ovm_put_export #(trans_t) first_put_export;
163 ovm_put_export #(trans_t) second_put_export;
164
165 sink sink1;
166 sink sink2;
167
168 function new(string name, ovm_component parent);
169 super.new(name, parent);
170 endfunction
171
172 function void build();
173 sink1 = new(“sink1”, this);
174 sink2 = new(“sink2”, this);
175 first_put_export = new(“first_put_export”, this);
176 second_put_export = new(“second_put_export”, this);
177 endfunction
178
179 function void connect();
180 first_put_export.connect(sink1.put_export);
181 second_put_export.connect(sink2.put_export);
182 endfunction
183
184 endclass
file: 04_OVM_mechanics/02_connectivity/top.sv
</source>
</big>

Два нижних уровня компоненты sink и exports создаются обычным способом. Затем они соединяются с помощью метода подключения export. Сейчас мы создаем port-export соединение между source_wrapper и sinker, также с помощью функции Connect.

<big><source lang="cpp">192 class env extends ovm_component;
193
194 sinker s;
195 source_wrapper sw;
196
197 function new(string name, ovm_component parent = null);
198 super.new(name, parent);
199 endfunction
200
201 function void build();
202 s = new(“sinker”, this);
203 sw = new(“source_wrapper”, this);
204 endfunction
205
206 function void connect();
207 sw.put_port1.connect(s.first_put_export);
208 sw.put_port2.connect(s.second_put_export);
209 endfunction
210
211 task run;
212 global_stop_request();
213 endtask
214
215 endclass
file: 04_OVM_mechanics/02_connectivity/top.sv

</source>
</big>

Для новых пользователей часто может вызвать трудности определить, порт или экспорт необходимо подключить и какой объект является аргументом. Вы можете легко понять это, следуя потоку управления через систему. Общее правило заключается в том, что запрашиваемый порт вызывается с помощью функции connect() и передачи в нее запрашиваемого port или export в качестве аргумента. Рисунок 4-4 показывает поток управления через иерархическую систему.

[[Файл:72.png]]

Порт – объект вызова и экспорт - объект вызванной функции или задачи. Вы можете воспринимать порты, как вызов экспорта. Так, в env, мы вызываем connect на put_ports с put_exports в качестве аргументов. Для port-to- port и export-to-export иерархии соединений, вызывающий будет чуть менее очевиден. Если вызов осуществляется со стороны порта, вы можете считать, что вызов lowest-level порта в иерархии является вызовом методов интерфейса upper-level порта. Аналогично, если экспорт объект вызова, вы можете считать upper-level экспорт вызовом lower-level export. В таблице ниже приведены возможные типы подключения:

[[Файл:73.png]]

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

В 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.)

== Фазы ==

Для традиционных модулей Verilog полная разработка проекта и его выполнение осуществялется в симуляторе. Так как OVM компоненты - это классы, они создаются и подключаются, и их выполнение начинается за пределами Verilog разработчика. Компоненты создаются вызовом конструктора класса операцией new(), которая выделяет память и выполняет инициализацию. В то время как Verilog время выполнения run-time engine managing instantiation, разработка, и выполнение компонент на основе классов, функциональность компонент разделена на фазы, и контроллер фазы OVM управляет их исполнением.

Каждая фаза представлена в компоненте как виртуального метода (задачи или функция) с тривиальной реализацией по умолчанию. Эти phase callbacks реализуются разработчиком компоненты, который обеспечивает соответствующую функциональность. Фаза контроллера гарантирует, что фазы выполняются в надлежащем порядке. Набор стандартных фаз показано в следующей таблице:

[[Файл:74.png]]

[[Файл:75.png]]

Каждая фаза имеет определенную цель. разработчики Компонент должны заботиться о том, чтобы функциональность реализованная в каждой фазе callback соответствовала фазе определения.

• '''New''' технически не является фазой, в том, что она не управляется фазой контроллера. Тем не менее, для каждого компонента, конструктор должен быть выполнен и завершен в целях создания компоненты. Таким образом, new должен выполниться до build() или любого другого последующего этапах выполнения.

• '''build''' это место, где новые компоненты, порты и экспорт создаются и настраиваются. Это также рекомендуемое место для вызова set_config_ * и get_config_ * (см. Section4.4).

• '''connect''' – место, где компоненты, порты и экспорт созданные в build() связываются.

• '''end_of_elaboration''' здесь вы можете выполнить изменение конфигураций, зная, что разработка уже завершена. То есть, вы можете предположить, что все компоненты созданы и соединены.

• '''start_of_simulation''' выполняется только до времени 0.

• '''run''' pre-defined task фазой. Все выполняемые задачи работают параллельно. Каждая выполняемая задача продолжается, пока ее управление не достигнет оператора EndTask или она явно будет прекращена. Позже в этой главе мы обсудим, как завершать testbenches.

• '''extract''' предназначен для сбора информации, касающейся покрытия или другой информации о том, как ответить на вопросы testbench.

• '''проверка''' - место, где выполняется любая проверка правильности или проверка валидации извлеченных данных.

• '''отчет''' -место , где делаются окончательные отчеты.

Ниже простой пример, использующий ovm_report_info () для иллюстрации порядка выполнения фаз.

<big><source lang="cpp">38 class sub_component extends ovm_component;
39
40 function new(string name, ovm_component parent);
41 super.new(name, parent);
42 endfunction
43
44 function void build();
45 ovm_report_info(“build”, ““);
46 endfunction
47
48 function void connect();
49 ovm_report_info(“connect”, ““);
50 endfunction
51
52 function void end_of_elaboration();
53 ovm_report_info(“end_of_elaboration”, ““);
54 endfunction
55
56 function void start_of_simulation();
57 ovm_report_info(“start_of_simulation”, ““);
58 endfunction
59
60 task run();
61 ovm_report_info(“run”, ““);
62 endtask
63
64 function void extract();
65 ovm_report_info(“extract”, ““);
66 endfunction
67
68 function void check();
69 ovm_report_info(“check”, ““);
70 endfunction
71
72 function void report();
73 ovm_report_info(“report”, ““);
74 endfunction
75
76 endclass
file: 04_OVM_mechanics/03_phases/top.sv

</source></big>

В компоненте верхнего уровня, мы создаем две компоненты, каждая из которых в свою очередь создает две sub_component. sub_components являющимися такими же, как и сами компоненты; каждая фаза обратного callback просто печатает строку, определяющую фазу. При выполнении, вы получите следующий результат:

<pre>OVM_INFO @ 0 [RNTST] Running test ...
OVM_INFO @ 0: env.c1 [build]
OVM_INFO @ 0: env.c1.s1 [build]
OVM_INFO @ 0: env.c1.s2 [build]
OVM_INFO @ 0: env.c2 [build]
OVM_INFO @ 0: env.c2.s1 [build]
OVM_INFO @ 0: env.c2.s2 [build]
OVM_INFO @ 0: env.c1.s1 [connect]
OVM_INFO @ 0: env.c1.s2 [connect]
OVM_INFO @ 0: env.c1 [connect]
OVM_INFO @ 0: env.c2.s1 [connect]
OVM_INFO @ 0: env.c2.s2 [connect]
OVM_INFO @ 0: env.c2 [connect]
OVM_INFO @ 0: env.c1.s1 [end_of_elaboration]
OVM_INFO @ 0: env.c1.s2 [end_of_elaboration]
OVM_INFO @ 0: env.c1 [end_of_elaboration]
OVM_INFO @ 0: env.c2.s1 [end_of_elaboration]
OVM_INFO @ 0: env.c2.s2 [end_of_elaboration]
OVM_INFO @ 0: env.c2 [end_of_elaboration]
OVM_INFO @ 0: env.c1.s1 [start_of_simulation]
OVM_INFO @ 0: env.c1.s2 [start_of_simulation]
OVM_INFO @ 0: env.c1 [start_of_simulation]
OVM_INFO @ 0: env.c2.s1 [start_of_simulation]
OVM_INFO @ 0: env.c2.s2 [start_of_simulation]
OVM_INFO @ 0: env.c2 [start_of_simulation]
OVM_INFO @ 0: env.c2 [run]
OVM_INFO @ 0: env.c2.s2 [run]
OVM_INFO @ 0: env.c2.s1 [run]
OVM_INFO @ 0: env.c1 [run]
OVM_INFO @ 0: env.c1.s2 [run]
OVM_INFO @ 0: env.c1.s1 [run]
OVM_INFO @ 1: env.c1.s1 [extract]
OVM_INFO @ 1: env.c1.s2 [extract]
OVM_INFO @ 1: env.c1 [extract]
OVM_INFO @ 1: env.c2.s1 [extract]
OVM_INFO @ 1: env.c2.s2 [extract]
OVM_INFO @ 1: env.c2 [extract]
OVM_INFO @ 1: env.c1.s1 [check]
OVM_INFO @ 1: env.c1.s2 [check]
OVM_INFO @ 1: env.c1 [check]
OVM_INFO @ 1: env.c2.s1 [check]
OVM_INFO @ 1: env.c2.s2 [check]
OVM_INFO @ 1: env.c2 [check]
OVM_INFO @ 1: env.c1.s1 [report]
OVM_INFO @ 1: env.c1.s2 [report]
OVM_INFO @ 1: env.c1 [report]
OVM_INFO @ 1: env.c2.s1 [report]
OVM_INFO @ 1: env.c2.s2 [report]
OVM_INFO @ 1: env.c2 [report]
</pre>

Вы видите, что build()выполняется сверху вниз и остальные фазы запуска снизу вверх. Вы также можете видеть, что каждый этап завершается во всех компонентах до начала следующего этапа. Таким образом, в connect(), например, вы можете расчитывать, что build() завершена во всех компонентах. Вы также заметите, что время запускается после фазы run. В нашем примере задача run - тривиальна, она просто выполняет задержку времени на единицу (# 1).

un_test (), упоминалось ранее в разделе 4.1, инициирует фазу выполнение. Он начинает выполнение фаз по порядку и контролирует, что каждый этап завершен до начала следующего.

== Config ==

Для увеличения повторного использования компонент, желательно объявит их с параметрами, которые могут быть внешне настроены. Конфигурационные средства обеспечивают возможности для этого. Они основаны на базе пар имя-значение, и называются configuration items, которые организованы иерархически. Каждая компонента содержит таблицу конфигураций элементов конфигурации, так как компоненты организованы в качестве дерева, каждый элемент в базе данных может быть уникально размещен по расположению компоненты и имени элемента конфигурации

[[Файл:76.png]]

Класс ovm_component содержит два набора методов для конфигурации размещения элементов в базу данных и потом для их получения. Это set_config_ * и * get_config_. В таблице ниже приведены оба набора.

[[Файл:77.png]]

Set_config_ * функция помещает элемент в конфигурационную базу данных текущего компонента, то есть в экземпляре компонента, в котором функция вызывается. Каждая из этих функций принимают три аргумента, имя, field_name и значение. Аргумент name - имя пути, который представляет набор компонент, которые должны соответсвовать кофигурациям этого элемента. name используется в * get_config_, чтобы найти элементы в базе данных конфигурации. field_name - это имя поля и должно быть уникальным в пределах текущей базы конфигураций. value является частью пары имя-значение и его тип может быть строка, INT, или ovm_object, в зависимости от вызываемой функции. Кроме того, set_config_object принимает копию аргумента для указания, был ли объект передан в качестве значения так как значение должно быть клонировано прежде чем оно будет помещено в базу конфигурации.
Функции get_config_ * извлекает элементов из базы данных конфигураций. Эти функции принимают только два аргумента, имя поля и INOUT переменную, который содержит значение расположения элемента. Они также возвращают бит, чтобы указать был ли удачно расположен запрашиваемый объект. * Get_config_ функции не принимают аргументы имени пути, как их set_config_ * коллеги, поскольку они используют путь к текущему компоненту, как ссылку, чтобы найти элементы конфигурации. Они разработаны, чтобы узнать, есть значение элемента конфигурации для текущего контекста, то есть, компонент, в котором функция get_config_ * вызывается.

Алгоритм поиска для извлечения элементов конфигурации использует имя пути компонента запроса и путь к файлу вставляемый в каждый item. Он начинается с поиска конфигурационных элементов в базе данных в верхней компоненте по field_name. Если такой элемент существует, то он затем спрашивает, соответствует ли указанный путь к файлу пути имени компоненты. Если элемента с указанным field_name нет или имена путей не совпадают, то поиск идет с дочерней компоненты. Этот процесс продолжается до соответствия или до достижения компоненты начала поиска.

Путь каждого элемент конфигурации может быть регулярным выражением. Таким образом, мы используем алгоритм соответствия регулярных выражений для нахождения совпадения с путем запрошенной компоненты и именем пути элемента конфигурации. Эффект заключается в соответствии иерархической области.
В качестве примера, рассмотрим простую иерархию на рисунке 4-5. Давайте предположим, что в env::build()мы запускаем два вызова set_config_ *:

<big>
<source lang="cpp">112 function void build();
113 c1 = new(“c1”, this);
114 c2 = new(“c2”, this);
115
116 set_config_int(“c2.*”, “i”, 42);
117 set_config_int(“*”, “t”, 19);
118 endfunction
file: 04_OVM_mechanics/04_config/top.sv

</source></big>

Это вызовет запись двух конфигурационных элементов в базу данных в env. Обратите внимание на звездочку (*) в имени пути. Имя пути в вызове set_config_ * - регулярное выражение, и дикие символы используются для указать несколько областей, к которыми элемент применяется. По элементу i, c2. * показывает, что в любой области ниже c2 в иерархии, i будет определять указанное значение. В этом случае указанное значение - 42. Если вы опустите звездочку, то элемент конфигурации применяется только к c2, а не к любому из своих потомков.
Состояние конфигурации базы данных для каждого компонента в иерархии после вызова set_config_ * показано на рисунке 4-6,

[[Файл:78.png]]

пусть в элементе top.c1.child1 мы осуществим вызов:

<big><source lang="cpp">int i;
...
get_config_int(“i”, i)
</source></big>

Поиск задает вопрос: Каково значение конфигурации i в иерархических рамках top.c1.child1? Чтобы ответить на этот вопрос, конфигурации базы данных в env ищется в первую очередь. Запись i там говорит, что значение i совпадающее с env.c2. * - 42. Тем не менее, компоненты, из которых был сделан запрос, находятся в c1 sub-hierarchy. Таким образом, не существует соответствия, а get_config_int () возвращает статус неудачи. Запрос в любую компоненту, которая является дочерней c2 будет успешно завершен и вернется значение 42.

Ниже приведен код для функцию build() дочерней компоненты. Это место где эти компоненты ищут конфигурационные значения i и t.

<big><source lang="cpp">60 function void build();
61
62 string msg;
63
64 if(!get_config_int(“t”, t)) begin
65 $sformat(msg, “no value for t found in config
database, using default value of %0d”, t);
66 ovm_report_warning(“build”, msg);
67 end
68
69 if(!get_config_int(“i”, i)) begin
70 $sformat(msg, “no value for i found in config
database, using default value of %0d”, i);
71 ovm_report_warning(“build”, msg);
72 end
73
74 endfunction
file: 04_OVM_mechanics/04_config/top.sv
</source></big>

Следующий пример показывает вывода при выполнении этого проекта:

<pre># OVM_INFO @ 0 [RNTST] Running test ...
# OVM_WARNING @ 0: env.c1.child1 [build] no value for i found in
config database, using default value of 91
# OVM_WARNING @ 0: env.c1.child2 [build] no value for i found in
config database, using default value of 91
</pre>

Запрос на конфигурационный элемент 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(), которая обращается к конструктору обернутого объекта.

Использование фабрики состоит из трех этапов: регистрация, настройки переопределение и создание. На первом этапе необходимо зарегистрировать объект с помощью фабрики. На втором шаге, добавляется переопределение зарегистрированного объекта. На третьем этапе, вы создаете объект с помощью фабрики, который будет возвращать либо первоначально зарегистрированный объект или переопределенный, в зависимости от того, переопределение было передано в качестве запрашиваемого объекта.

=== Как работает фабрика ===

Термин фабрика был придуман 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 и параметризованными классами, которые представляют уникальные типы.

Для нашей фабрики, базовые классы тривиальны:

<big><source lang="cpp">46 class object_base;
47 virtual function void print();
48 $display(“object_base”);
49 endfunction
50 endclass
file: 04_OVM_mechanics/07_toy_factory/top.sv
59 class wrapper_base;
60 virtual function object_base create_object();
61 return null;
62 endfunction
63 endclass
file: 04_OVM_mechanics/07_toy_factory/top.sv</source></big>

object_base имеет виртуальную функцию print(), которую мы используем для проверки типов, созданных на фабрике. wrapper_base имеет виртуальную функцию create(), полиморфный конструктор, который используется для создания новых объектов.
factory - это singleton, то есть его конструктор локальный, и он содержит статическую ссылку на самого себя. Единственный способ создать экземпляр factory является вызов factory::get(). factory содержит ассоциативный массив, который отображает запрашиваемые типы wrapper_base в переопределенные типы wrapper_base.

<big><source lang="cpp">73 class factory;
74
75 static factory f;
76 wrapper_base override_map[wrapper_base];
77
78 local function new();
79 endfunction
80
81 static function factory get();
82 if(f == null)
83 f = new();
84 return f;
85 endfunction
86
87 function void register(wrapper_base w);
88 override_map[w] = w;
89 endfunction
90
91 function void set_override(wrapper_base requested_type,
92 wrapper_base override_type);
93 override_map[requested_type] = override_type;
94 endfunction
95
96 function object_base create(wrapper_base
97 requested_type);
98 object_base obj;
99 wrapper_base override_type =
100 override_map[requested_type];
101 obj = override_type.create_object();
102 return obj;
103 endfunction
104
105 endclass
file: 04_OVM_mechanics/07_toy_factory/top.sv
</source></big>

Метод register() добавляет новую запись в карту. Первоначально, при регистрации, тип не имеет переопределения. Таким образом, мы записали в карту тип, указывающий сам на себя. Set_override () метод заменяет запись в карте новым переопределенным типом. create() метод ищет переопределения на указанный тип, инициирует создание переопределенного типа и возвращает вновь созданный объект.
Класс-оболочка является наиболее интересным классом в нашем созвездии factory-related классов. Хотя он довольно прост, он делает большую часть тяжелой работы. Это основной интерфейс для фабрики, и большинство операций, которые производятся фабрикой, проходят через интерфейс оболочки.

<big><source lang="cpp">118 class wrapper #(type T=object_base) extends wrapper_base;
119
120 typedef wrapper#(T) this_type;
121
122 static this_type type_handle = get_type();
123
124 local function new();
125 endfunction
126
127 function object_base create_object();
128 T t = new();
129 return t;
130 endfunction
131
132 static function T create();
133 T obj;
134 factory f = factory::get();
135 assert($cast(obj, f.create(get_type())));
136 return obj;
137 endfunction
138
139 static function this_type get_type();
140 factory f;
141 if(type_handle == null) begin
142 type_handle = new();
143 f = factory::get();
144 f.register(type_handle);
145 end
146 return type_handle;
147 endfunction
148
149 static function void set_override(wrapper_base
150 override_type);
151 factory f = factory::get();
152 f.set_override(type_handle, override_type);
153 endfunction
154
155 endclass
file: 04_OVM_mechanics/07_toy_factory/top.sv</source>
</big>

Все функции в wrapper#() являются статическими, за исключением конструктора и create_object (). Мы можем выполнить его статические функции, не заботясь о том, был ли они явно создан экземпляр класса. Так как каждая обертка специализации уникальна. Это означает, что статическая переменная type_handle является уникальной и может быть использован в качестве прокси-сервера для обернутого типа (то есть, типа, передающегося в качестве параметра, который используется для специализации класса). Так как тип является уникальным, и большинство методов являются статическими, мы можем рассматривать типа больше как тип, а не объект.

Тип инициализируется статически. Это происходит в следующей строке:

<big><source lang="cpp">static wrapper#(T) type_handle = get_type();</source></big>

Функция get_type () вызывается во время статической инициализации, которая не только создает экземпляр оболочки, но и регистрирует его в фабрике. Для регистрации класса в фабрике, сначала специализируется обертка с типом объекта, который вы оборачиваете. Используйте typedef для специализации оболочки, как показано в следующем примере:

<big><source lang="cpp">typedef wrapper#(some_type) type_id;</source>
</big>

Это определение типа создает оболочку для SOME_TYPE типа, тип, производный от object_base.
Рисунок 4-8 иллюстрирует, как использовать фабрику с некоторыми классами A, B, и С, которые являются производными от family_base.

[[Файл:80.png]]

Чтобы зарегистрировать классы с помощью фабрики, каждый из них имеет typedef из обертки, параметризованной со своим типом. Ниже класс А. Класс B и C похожи. Каждый из них имеет typedef, которая специализируется обертку.

<big><source lang="cpp">169 class A extends family_base;
170
171 typedef wrapper#(A) type_id;
172
173 virtual function void print();
174 $display(“A”);
175 endfunction
176 endclass
file: 04_OVM_mechanics/07_toy_factory/top.sv</source>
</big>
Ниже приводится короткая программа, которая использует фабрику.

<big><source lang="cpp">206 function void run();
207
208 f = factory::get();
209
210 h = family_base::type_id::create();
211 h.print();
212
213
family_base::type_id::set_override(B::type_id::get_type());
214
215 h = family_base::type_id::create();
216 h.print();
217
218 endfunction
file: 04_OVM_mechanics/07_toy_factory/top.sv
</source></big>

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.

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

Файл:80.png

2013-03-25T10:59:21Z

Anastasiya:

Файл:79.png

2013-03-25T10:59:03Z

Anastasiya:

OVM/OVM методология/Механика OVM

2013-03-25T08:55:15Z

Anastasiya:

OVM/OVM методология/Механика OVM

2013-03-20T11:30:10Z

Anastasiya:

Файл:78.png

2013-03-20T11:14:35Z

Anastasiya:

Файл:77.png

2013-03-20T11:14:19Z

Anastasiya:

Файл:76.png

2013-03-20T11:14:01Z

Anastasiya:

Файл:75.png

2013-03-20T11:13:45Z

Anastasiya:

Файл:74.png

2013-03-20T11:13:30Z

Anastasiya:

OVM/OVM методология/Механика OVM

2013-03-19T09:10:20Z

Anastasiya:

OVM/OVM методология/Механика OVM

2013-03-19T09:08:42Z

Anastasiya:

Файл:73.png

2013-03-19T08:59:40Z

Anastasiya:

Файл:72.png

2013-03-19T08:59:25Z

Anastasiya:

Файл:71.png

2013-03-19T08:59:12Z

Anastasiya:

Файл:70.png

2013-03-19T08:58:56Z

Anastasiya:

OVM/OVM методология/Механика OVM

2013-03-18T13:38:19Z

Anastasiya:

OVM/OVM методология/Механика OVM

2013-03-18T09:24:44Z

Anastasiya:

Файл:69.png

2013-03-18T09:20:33Z

Anastasiya:

OVM/OVM методология/Механика OVM

2013-03-18T09:20:11Z

Anastasiya: Новая страница: «{{OVM TOC}} __TOC__ = Механика OVM =»

{{OVM TOC}}
__TOC__

= Механика OVM =

OVM

2013-03-18T09:17:50Z

Anastasiya: /* Описание проекта */

{{OVM_TOC}}
__TOC__
== Описание проекта ==
* [http://redmine.simhard.com/projects/ovm Контроль проекта]
* [http://simhard.com/websvn/listing.php?repname=ovm Просмотр репозитория проекта]
* [[OVM/OVM методология | OVM методология ]]
**[[OVM/OVM методология/Введение| Введение]]
**[[OVM/OVM методология/Основы верификации| Основы верификации]]
**[[OVM/OVM методология/Основы объектно-ориентированного программирования| Основы объектно-ориентированного программирования]]
**[[OVM/OVM методология/Transaction-Level моделирование|Transaction-Level моделирование]]
**[[OVM/OVM методология/Механика OVM|Механика OVM]]

== Литература ==
* [[OVM/Ссылки | Ссылки ]]
* [[OVM/Книги | Книги ]]
* [[OVM/Стандарт OVM| Стандарт OVM ]]
== TO DO ==
* [[OVM/Описание пакетов | Описание пакетов ]]
* [[OVM/Описание функций | Описание функций ]]
* [[OVM/Тестовый план | Тестовый план ]]

[[Категория:Дипломы-2013]]

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

2013-03-14T08:11:57Z

Anastasiya:

{{OVM TOC}}
__TOC__

= =

Процесс проектирования электронной системы включает в себя последовательное замещение абстрактных идей конкретной их реализацией, пока не будет достигнуто представление, которое может быть изготовлено на кремнии. С момента появления цифровой интегральной схемы, электронные сообщества тщательно определили и кодировали абстракции, начиная с переключателей и логических элементов, для обеспечения среды в которой работает проект. RTL является примером среды, часто используемой для создания проектов. Есть много инструментов на основе RTL, которые делают ее удобной для создания проекта и его верификации.
Однако, как только проект становится больше и сложнее, становится более представлять их с помощью абстракции выше, чем RTL. Уровень транзакций становится популярным для создания первого представления проекта, которое может быть смоделировано и проанализировано.
В этой главе описаны основные понятия transaction-level моделирования (TLM). Модели transaction-level состоят из нескольких процессов, которые обмениваются информацией посредством транзакций.

== Абстракция ==

RTL моделирование использует дискретную модель времени. Связь между процессами осуществляется с помощью сетки ( цепи), и процесс активации происходит при изменении значения во входной сети ( цепи).
Для сравнения, transaction-level модели (моделирующей схемы) могут быть синхронизированы или не синхронизированы и использовать шину для обмена данными между процессами. Вместо того чтобы посылать отдельные биты туда и обратно, процессы общаются, посылая транзакции друг другу посредством вызова функций. Мир TLM включает в себя ряд моделей(моделирующих схем) вычислений с различным временем, системами связи и процессами активации моделей (моделирующей схемы). В каждом конкретном случае, содержание связей находится на более высоком уровне абстракции, чем отдельные биты. Таким образом, transaction-level модель находится на более высоком уровне абстракции (более абстрактна), чем RTL модель. Объединяя понятия абстракции и модели (моделирующей схемы) вычислений, видно, что создание абстрактных моделей означает абстрагирование времени, данных и функций.

'''Абстракция времени.''' Время абстракция в симуляторе относится к тому, насколько внутренние состояния схемы совместимы. Модели, запущенные в управляемых событиями симуляторах (например, логических симуляторах) используют дискретное представление времени, то есть события происходят в определенные моменты времени. События, как правило (хотя и не всегда) вызывают запущенный процесс. Чем больше событий происходит в симуляции, больше процессов вызывается, и с большим числом процессов происходит снижении скорости моделирования. Абстрагирование время уменьшает количество точек, где схема должна быть совместимой и общего числа событий и процессов, которые будут активированы. Например, в RTL модели, каждая сеть должна быть согласована после каждого изменения. В cycle-accurate абстракции, схема должна быть синхронизирована с синхросигналом, устраняя все события, что происходит между фронтами синхроимпульса. В transaction-level модели, состояния схемы должны быть синхронизированы в конце каждой операции, каждая из которых может охватывать много тактов.

'''Абстракция данных'''. Данные относятся к объектам, передаваемым между компонентами. В RTL моделях, данные относятся к отдельным битам, которые передаются по сети между компонентами. В transaction-level моделях, данных представлены в виде транзакций, гетерогенных структур, которые содержат произвольные коллекции элементов.
Рассмотрим пакет в устройстве связи. На самом низком уровне детализации, пакет содержит бит начала и стоп-биты, заголовок, информацию исправления ошибок, размер полезной нагрузки, нагрузки, и завершитель (??????). В более абстрактной модели, только нагрузка и размер нагрузки могут быть необходимы. Другие данные не нужны для выполнения расчетов.

'''Абстракция функций.''' Функция модели является набором всех операций, которая она делать на каждое событие. Абстрагирование функций уменьшает этот набор или заменяет его более простыми вычислениями. Например, в ALU, вы можете выбрать использование родной операции умножении поставляемой в язык моделирования, вместо кодирования a shift-and-add алгоритма умножения. Последний может быть частью реализации, но на более высоком уровне, детали a shift-and-add - неважны. Базовые элементы, которые являются частью языка, определяет, как вы можете абстрагировать функцию. В gate-level языке, например, можно создавать сложные поведения, начиная с логических элементов. В RTL языка, построение поведения основывается на арифметических и логических операциях над регистрами. В TLM, вы реализуете функциональность схемы с помощью вызовов функций произвольной сложности.

Для целей функциональной верификации, RTL самый низкий уровень абстракции, который мы должны рассмотреть. С синтезаторы могут эффективно конвертировать RTL в логические элементы, нам не нужно затрагивать более низкий уровень детализации.

== Определение транзакции ==

Для более подробного рассмотрения TLM, мы должны сделать шаг назад и определить понятие транзакции.

[[Файл:61.png]]

Это самое общее определение транзакции. Оно утверждает, что транзакция – это все, что происходит в проекте (или модуле или подсистеме проекта) между двумя точками времени. Хотя оно точное, оно является настолько общим, что не приводит к практическому применению. Более полезные определения следующие:

[[Файл:62.png]]
<blockquote>Транзакция — передача управления и данных между двумя элементами (компонентами)</blockquote>

Это аппаратно-ориентированные понятие транзакции. Когда смотришь на часть аппаратного обеспечения, вы можете легко определить элементы, между которыми передается управление или данные. В проекте с шинной архитектурой, чтение и запись на шину может быть вызвано транзакцией. В пакетной системе связи, отправка пакета представляет собой транзакцию.

Ниже третье определение:

[[Файл:63.png]]

Это определение программно-ориентированного понятия транзакции. В transaction-level модели, деятельность инициируется путем вызова функции. Вызов функции содержит параметры, которые "посылаются" (передаются) вызываемой функции, а возвращаемое значение функции содержит данные, которые возвращаются вызванной функцией. Вызванная функция может блокировать и вызвать задержку (в синхронной системе) или может вернуться (выполниться) немедленно.


== Интерфейсы ==

Прежде чем вдаваться в подробности о том, как построить transaction-level модель, мы сначала обсудим интерфейсы. Термин интерфейс используется в несколько случаях в OVM, каждый раз с немного другим смыслом. Это прискорбный факт истории, то что слово стало означать различные вещи. В большинстве случаев значение будет понятно из контекста, в котором этот термин используется. Различных применения :

* Интерфейс в SystemVerilog
* Интерфейс объекта
* Интерфейс DUT

'''Интерфейс в SystemVerilog'''. SystemVerilog предоставляет конструкцию, называемую интерфейс, который является одним из основных объектов контейнер, из которого строится проект в SystemVerilog. Мы используем виртуальные интерфейсы, которые указывают на интерфейсы для подключения module-based аппаратуры к class-based testbenches.

'''Интерфейс объекта.''' Общедоступные задачи и функции, доступные для объекта, образуют его интерфейс. Есть два небольших варианта этого значения интерфейса. Одним из них является прямой. Посмотрите на класс и определите, какие задачи и функций, доступны пользователю класса. Это его интерфейс. Другое значение состоит в ссылке на базовый класс, который определяет набор задач и функций, доступных для работы производного класса. Это значение интерфейса обычно используется в объектно-ориентированных языках, которые поддерживают множественное наследование, таких как C++ или Java. В этих языках, вы можете установить требование, что производный класс определяет функциональность, наследуемую от интерфейса базового класса.

[[Файл:64.png]]

Интерфейс print_if определяет прототипы для функций печати. Любой класс, который наследуется от print_if затем обязан осуществлять print()и sprint(). SystemVerilog не поддерживает множественное наследование, но он поддерживает истинно виртуальные интерфейсы. Истинно виртуальный интерфейс - интерфейс во втором контексте (базовый класс, который определяет набор задач и функций прототипов), который не имеет реализаций. Истинно виртуальная версия print_if выглядит следующим образом в SystemVerilog:

<big><source lang="cpp">virtual class print_if;
pure virtual function void print();
pure virtual function string sprint();
endclass</source></big>

Даже если SystemVerilog не поддерживает множественное наследование, и OVM построено на SystemVerilog, важно понять истинно виртуальные интерфейсы и наследование интерфейсов, потому что они активно используются в OVM. В частности, TLM ports and exports являются производными от интерфейса класс tlm_if_base.

'''DUT интерфейс.''' Часть аппаратуры, как правило, доступны через свои интерфейсы. В этом контексте, интерфейс состоит из контактов и протоколов используемых для связи с устройством. Например, устройство может иметь USB интерфейс.

== TLM идиомы ==

В данном разделе рассматриваются основные средства передачи транзакций между компонентами. Мы put, get, и transport формы связи транзакций. Эти примеры не используют библиотеку OVM, так как они предназначены для иллюстрации основных механизмов связи на transaction-level с минимальными затратами. В следующем разделе мы рассмотрим более полный пример, который использует OVM библиотека для связи.

=== Put ===
В put конфигурации, один компонент отправляет операции другому компоненту. Операция называется put. Инициатором является компонентом, который инициирует передачу, а целевой компонент, который получает результат. Используя TLM номенклатуру, мы говорим, что инициатор put транзакции цели.

[[Файл:65.png]]

Рисунок 3-2 показывает, что А предает операцию в пункт Б. Инициатор имеет порт, рисуется как квадрат, и цель имеет export, изображается в виде круга. Поток управления направлен от квадрата к кругу, то есть, А вызывает B, который содержит реализацию методов port. Стрелка показывает направление поток данных, и в этом случае, это означает, что данные будут двигаться от А до B.
Мы можем проиллюстрировать код для этих компонентов с producer и consumer. producer является инициатором и consumer является целью. Мы должны строить эти компоненты таким образом, что они не знали друг о друге априори. Чтобы сделать это, мы используем истинно виртуальный интерфейс для определения функции, который будет использоваться для передачи данных между инициатором и целью. Во-первых, давайте взглянем на SystemVerilog версию producer.

<big><source lang="verilog">46 class producer;
47
48 put_if put_port;
49
50 task run();
51
52 int randval;
53
54 for(int i=0; i<10; i++)
55 begin
56 randval = $random %100;
57 $display(“producer: sending %4d”, randval);
58 put_port.put(randval);
59 end
60
61 endtask
62
63 endclass : producer
file: 03_tlm/01_put/put.sv</source></big>

producer - это класс, который создается динамически. Он имеет два ключевых элемента, Run () задачу и put_port. Run () задача является простой задачей, которая повторяется 10 раз и передает 10 транзакций. Для простоты, наши операции являются целыми числами. На практике, транзакция может быть сколь угодно сложным объектом, таким как структура или класс.
Чтобы передать операции, producer вызывает put() на put_port. Что такое put_port? Это не порт в традиционном смысле Verilog. Это ссылка на put_if. Что такое put_if? Put_if это виртуальный интерфейс класса расположенный между инициатором (producer) и целью (consumer).

<big><source lang="verilog">39 virtual class put_if;
40 pure virtual task put(int val);
41 endclass : put_if</source></big>

put_if класс с истинно виртуальными задачами, т.е. задачами, не имеющими реализацию. Без реализации всех своих задач и функций, виртуальный класс не может быть создан сам по себе. Он должен быть базовым классом другого класса, который создается. В нашем случае, класс, производный от истинно виртуального put_if является consumer.

<big><source lang="verilog">68 class consumer extends put_if;
69 task put(int val);
70 $display(“consumer: receiving %4d”, val);
71 endtask : put
72 endclass : consumer
file: 03_tlm/01_put/put.sv
</source></big>

consumer содержит реализацию put(); истинно виртуальные задачи определены в put_if. Задача put() реализация принимает аргументы, переданные ей, и печатает их. put_if играет ключевую роль в соединении consumer и producer. Ссылка на него на стороне producer, которую мы называем порт, устанавливает требование, что должна быть реализация функций и задач интерфейса, к которому этот объект будет привязан. consumer является производным от интерфейса и, следовательно, в нем должны быть реализованы истинно виртуальные задачи, удовлетворяющие требованиям.

Модуль верхнего уровня связывающий producer и consumer.

<big><source lang="verilog">77 module top;
78
79 producer p;
80 consumer c;
81
82 initial begin
83 // instantiate producer and consumer
84 p = new();
85 c = new();
86 // connect producer and consumer
87 // through the put_if interface class
88 p.put_port = c;
89 p.run();
90 end
91 endmodule : top
file: 03_tlm/01_put/put.sv</source></big>

Обратите внимание, что оператор присваивания:

<big><source lang="verilog">88 p.put_port = c;</source></big>

Он образует связь между producer и consumer. Когда new() вызывается на р, чтобы создать новый экземпляр producer, член put_port не имеет значения. Во время выполнения произойдет ошибка, если put_port. put () вызывается до связи назначения. Назначение С к p.put_port дает ссылку для consumer, который содержит реализацию задачи put() интерфейса.

=== Get ===

Дополнением к put является get. В этом устройстве, инициатор получает транзакции от цели. Поток управления такой же, от инициатора к цели, но направление потока данных обратное. Инициатор получает транзакции от цели. В этом случае consumer является инициатором, producer - целью. Consumer инициирует вызов producer для получения транзакции.

[[Файл:66.png]]

Рисунок 3-3 очень похож на рисунок 3-2. Разница лишь в том, что здесь стрелка от цели к инициатору, а не наоборот. Это означает, что потоки данных от цели к инициатору. Ниже SystemVerilog consumer (инициатор).

<big><source lang="verilog">62 class consumer;
63
64 get_if get_port;
65
66 task run();
67 int randval;
68 for(int i=0; i<10; i++)
69 begin
70 get_port.get(randval);
71 $display(“consumer: receiving %4d”, randval);
72 end
73 endtask
74 endclass
file: 03_tlm/02_get/get.sv</source></big>

consumer имеет задачу, run(), которая выполняется 10 раз, чтобы получить 10 транзакций. Producer как в put примере, consumer имеет здесь порт. Кроме того, как в put примере, порт ссылается на истинно виртуальный интерфейс, в данном случае
он называется get_if.

<big><source lang="verilog">41 virtual class get_if;
42 pure virtual task get(output int t);
43 endclass : get_if
file: 03_tlm/02_get/get.sv</source>
</big>
get_if

является истинно виртуальным интерфейс, который определяет функцию get(). Цель (producer) строится аналогично, как и цель в put примере. Она содержит реализацию функции интерфейса. Этот producer генерирует случайное число между 0 и 99.

<big><source lang="verilog">48 class producer extends get_if;
49
50 task get(output int t);
51 int randval;
52 randval = $random % 100;
53 $display(“producer: sending %4d”, randval);
54 t = randval;
55 endtask
56
57 endclass : producer
file: 03_tlm/02_get/get.sv</source></big>

Связи на высшем уровне будут выглядеть очень похожими.

<big><source lang="verilog">79 module top;
80
81 producer p;
82 consumer c;
83
84 initial begin
85 // instantiate producer and consumer
86 p = new();
87 c = new();
88 // connect producer and consumer through the get_if
89 // interface class
90 c.get_port = p;
91 c.run();
92 end
93 endmodule : top
file: 03_tlm/02_get/get.sv</source></big>

После создания объектов producer и consumer, используя операцию new(), два объекта будут соединяться с помощью связей назначения.

=== Transport ===

Transport является двунаправленным интерфейсом. Интерфейс обеспечивает передачу транзакций от инициатора к цели и от цели обратно к инициатору. Как правило, мы используем этот механизм, чтобы смоделировать запрос-ответ протоколы. Когда речь идет о компонентах с двунаправленным интерфейсов, мы используем термины master (ведущего) и slave (ведомого), а не инициатор и цель.

[[Файл:67.png]]

master (A) делает и put и get за один вызов функции. Как мы видели в предыдущих примерах, put() и get() принимают один аргумент, аргумент они помещают или извлекают. Тем не менее, функция transport() имеет два аргумента, запрос и ответ. Она посылает запрос и возвращает ответ. slave (B) принимает запрос и возвращает ответ.

Давайте сначала посмотрим на истинно виртуальный интерфейс.

<big><source lang="verilog">37 virtual class transport_if;
38 pure virtual task transport(input int request,
39 output int response);
40 endclass : transport_if
file: 03_tlm/03_transport/transport.sv</source></big>

Интерфейс содержит одну функцию, transport(), которая принимает два аргумента: запрос, который передается цели и ответ, который возвращается инициатору.

Master вызывает transport(), создает запрос и отправляет его slave, используя transport. Он обрабатывает ответ, который возвращается.

<big><source lang="verilog">45 class master;
46
47 transport_if port;
48
49 task run();
50
51 int request;
52 int response;
53
54 for(int i=0; i<10; i++)
55 begin
56 request = $random % 100;
57 $display(“master: sending request %4d”,
58 request);
59 port.transport(request, response);
60 $display(“master: receiving response %4d”,
61 response);
62 end
63
64 endtask
65 endclass : master
file: 03_tlm/03_transport/transport.sv</source></big>

slave реализует функцию transport(). В нашем примере, она делает некоторые тривиальные обработки запроса для создания ответа.

<big><source lang="verilog">70 class slave extends transport_if;
71
72 task transport(input int request, output int response);
73 $display(“slave: receiving request %4d”,
74 request);
75 response = -request;
76 $display(“slave: sending response %4d”,
77 response);
78 endtask
79
80 endclass
file: 03_tlm/03_transport/transport.sv</source></big>

Связи верхнего уровня между master и slave работают точно так же как и в примере с put и get.

<big><source lang="verilog">85 module top;
86
87 master m;
88 slave s;
89
90 initial begin
91 // instantiate the master and slave
92 m = new();
93 s = new();
94
95 // connect the master and slave through
96 // the port interface
97 m.port = s;
98 m.run();
99 end
100
101 endmodule : top
file: 03_tlm/03_transport/transport.sv</source>
</big>

Связь назначения связывает master и slave. После выполнения соединения, master может использовать соединения для прямого вызова функций slave.

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

Интерфейсы мы рассмотрели ранее блокирующие. Это означает, что функции и задачи блокируют выполнение до их завершения. Им не разрешается заканчиваться неудачей. Не существует механизма для блокировки при аварийном завершении или иным образом изменять поток управления. Они просто ждать, пока запрос будет выполнен. В синхронизированной системе это означает, что время может пройти между вызовом и возвращением полученного результата.

В put конфигурации, у нас есть два компонента, producer и consumer. Producer генерирует случайное число и посылает его к consumer, используя put(). Прежде чем вызывается put(), нет активности в consumer. Вызов put() вызывает активность в consumer, которая выводит значение аргумента. За то время, что consumer является активным, producer ожидает. Это природа блокирующего вызова. Вызывающий должен ждать, пока вызов завершиться для возобновления выполнения.

Теперь сравните это описание с неблокирующим вызовом. Неблокирующий вызов возвращается немедленно. Семантика неблокирующего вызова гарантирует, что вызов возвращается в том же дельта цикле, в котором он был запущен, то есть без задержки, даже на один дельта цикл.

Истинно виртуальный интерфейс, который соединяет неблокирующего slave и master выглядит так же, как другие истинно виртуальные интерфейсы, которые мы видели. Значительная разница в том, что nb_get () возвращает значение статуса вместо транзакции.

<big><source lang="verilog">41 virtual class get_if;
42 pure virtual function int nb_get(output int t);
43 endclass : get_if
file: 03_tlm/04_nonblocking/nbget.sv</source>
</big>

master (consumer) должен проверить состояние, возвращаемое из nb_get (), чтобы определить, завершена ли функция успешно. Отметим также, что мы ввели время в модель. Consumer проверяет каждый 4 нс доступность значения.

<big><source lang="verilog">78 class consumer;
79
80 get_if get_port;
81
82 task run();
83 int randval;
84 int ok;
85
86 for(int i=0; i<20; i++)
87 begin
88 #4;
89 if(get_port.nb_get(randval))
90 $display(“%t: consumer: receiving %4d”, $time,
randval);
91 else
92 $display(“%t: consumer: no randval”, $time);
93 end
94 endtask
95 endclass
file: 03_tlm/04_nonblocking/nbget.sv</source></big>

producer организован как функция и задача. Задача будет раздвоена (порождена), чтобы запуститься как непрерывный процесс. Он генерирует новые случайные значения, что consumer будет захватывать. Тем не менее, каждая случайная величина доступна только для 2 нс из 7 нс цикла. Функция - реализация nb_get, которая возвращает значение, запускает периодически выполнение run().

<big><source lang="verilog">48 class producer extends get_if;
49
50 int randval = 0;
51 int rand_avail = 0;
52
53 function int nb_get(output int t);
54 if(rand_avail) begin
55 $display(“%t: producer: sending %4d”,
56 $time, randval);
57 t = randval;
58 return 1;
59 end
60 return 0;
61 endfunction
62
63 task run();
64 forever begin;
65 #5;
66 randval = $random % 100;
67 rand_avail = 1;
68 #2;
69 rand_avail = 0;
70 end
71 endtask
72
73 endclass : producer
file: 03_tlm/04_nonblocking/nbget.sv
</source>
</big>

Когда мы запускаем пример, мы видим, что не каждый вызов nb_get () успешен.

<pre>4: consumer: no randval
8: consumer: no randval
12: producer: sending -99
12: consumer: receiving -99
16: consumer: no randval
20: producer: sending -39
20: consumer: receiving -39
24: consumer: no randval
28: producer: sending -9
28: consumer: receiving -9
32: consumer: no randval
36: consumer: no randval
40: producer: sending 57
40: consumer: receiving 57
44: consumer: no randval
48: producer: sending -71
48: consumer: receiving -71
52: consumer: no randval
56: producer: sending -14
56: consumer: receiving -14
60: consumer: no randval
64: consumer: no randval
68: producer: sending 29
68: consumer: receiving 29
72: consumer: no randval
76: producer: sending 18
76: consumer: receiving 18
80: consumer: no randval
</pre>
Блокировать get конфигурацию смог только один процесс - consumer, который постоянно обращался с запросом к producer, чтобы тот отправил новое значение. Неблокирующий вариант состоит из двух этапов: consumer регулярно опрашивает producer, чтобы получить новое значение, и producer генерирует новые значения асинхронно по отношению к consumer. Наши неблокирующий producer генерирует доступное случайное значение каждые 7 нс. Он ждет 5 нс, а затем создает новое значение и новое значение действительно в течение 2 нс. Флаг rand_avail устанавливается, когда случайное значение доступно и сбрасывается в противном случае.

Реализация nb_get () в этом примере должна проверить rand_avail есть ли что отправить. Если нет, то она возвращает 0, чтобы указать, что запрос не удался. Если есть что-то, то он посылает его и возвращает 1, чтобы показать успех.

Блокирующие интерфейсы полезны для работы с двумя компонентами синхронно. Вызовы блокируются до тех пор, пока запрошенная операция выполняется, не смотря на то, сколько это потребует времени. С другой стороны, неблокирующие интерфейсы полезны при асинхронной передаче данных. Они не ждут и могут быть использованы для опроса целей, как в приведенном примере.

== Изоляция компонент с помощью каналов ==

В предыдущем разделе обсуждались простые механизмы для перемещения транзакций между двумя процессами. В каждом, инициатор и цель были сильно синхронизированы вызовом транзакции интерфейса. В этом разделе мы рассмотрим случай, когда инициатор и цель менее тесно связаны, это можно сделать с помощью канала, в этом случае 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.

== Формирование 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 интерфейсов.

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

2013-03-13T13:25:18Z

Anastasiya:

{{OVM TOC}}
__TOC__

= =

Процесс проектирования электронной системы включает в себя последовательное замещение абстрактных идей конкретной их реализацией, пока не будет достигнуто представление, которое может быть изготовлено на кремнии. С момента появления цифровой интегральной схемы, электронные сообщества тщательно определили и кодировали абстракции, начиная с переключателей и логических элементов, для обеспечения среды в которой работает проект. RTL является примером среды, часто используемой для создания проектов. Есть много инструментов на основе RTL, которые делают ее удобной для создания проекта и его верификации.
Однако, как только проект становится больше и сложнее, становится более представлять их с помощью абстракции выше, чем RTL. Уровень транзакций становится популярным для создания первого представления проекта, которое может быть смоделировано и проанализировано.
В этой главе описаны основные понятия transaction-level моделирования (TLM). Модели transaction-level состоят из нескольких процессов, которые обмениваются информацией посредством транзакций.

== Абстракция ==

RTL моделирование использует дискретную модель времени. Связь между процессами осуществляется с помощью сетки ( цепи), и процесс активации происходит при изменении значения во входной сети ( цепи).
Для сравнения, transaction-level модели (моделирующей схемы) могут быть синхронизированы или не синхронизированы и использовать шину для обмена данными между процессами. Вместо того чтобы посылать отдельные биты туда и обратно, процессы общаются, посылая транзакции друг другу посредством вызова функций. Мир TLM включает в себя ряд моделей(моделирующих схем) вычислений с различным временем, системами связи и процессами активации моделей (моделирующей схемы). В каждом конкретном случае, содержание связей находится на более высоком уровне абстракции, чем отдельные биты. Таким образом, transaction-level модель находится на более высоком уровне абстракции (более абстрактна), чем RTL модель. Объединяя понятия абстракции и модели (моделирующей схемы) вычислений, видно, что создание абстрактных моделей означает абстрагирование времени, данных и функций.

'''Абстракция времени.''' Время абстракция в симуляторе относится к тому, насколько внутренние состояния схемы совместимы. Модели, запущенные в управляемых событиями симуляторах (например, логических симуляторах) используют дискретное представление времени, то есть события происходят в определенные моменты времени. События, как правило (хотя и не всегда) вызывают запущенный процесс. Чем больше событий происходит в симуляции, больше процессов вызывается, и с большим числом процессов происходит снижении скорости моделирования. Абстрагирование время уменьшает количество точек, где схема должна быть совместимой и общего числа событий и процессов, которые будут активированы. Например, в RTL модели, каждая сеть должна быть согласована после каждого изменения. В cycle-accurate абстракции, схема должна быть синхронизирована с синхросигналом, устраняя все события, что происходит между фронтами синхроимпульса. В transaction-level модели, состояния схемы должны быть синхронизированы в конце каждой операции, каждая из которых может охватывать много тактов.

'''Абстракция данных'''. Данные относятся к объектам, передаваемым между компонентами. В RTL моделях, данные относятся к отдельным битам, которые передаются по сети между компонентами. В transaction-level моделях, данных представлены в виде транзакций, гетерогенных структур, которые содержат произвольные коллекции элементов.
Рассмотрим пакет в устройстве связи. На самом низком уровне детализации, пакет содержит бит начала и стоп-биты, заголовок, информацию исправления ошибок, размер полезной нагрузки, нагрузки, и завершитель (??????). В более абстрактной модели, только нагрузка и размер нагрузки могут быть необходимы. Другие данные не нужны для выполнения расчетов.

'''Абстракция функций.''' Функция модели является набором всех операций, которая она делать на каждое событие. Абстрагирование функций уменьшает этот набор или заменяет его более простыми вычислениями. Например, в ALU, вы можете выбрать использование родной операции умножении поставляемой в язык моделирования, вместо кодирования a shift-and-add алгоритма умножения. Последний может быть частью реализации, но на более высоком уровне, детали a shift-and-add - неважны. Базовые элементы, которые являются частью языка, определяет, как вы можете абстрагировать функцию. В gate-level языке, например, можно создавать сложные поведения, начиная с логических элементов. В RTL языка, построение поведения основывается на арифметических и логических операциях над регистрами. В TLM, вы реализуете функциональность схемы с помощью вызовов функций произвольной сложности.

Для целей функциональной верификации, RTL самый низкий уровень абстракции, который мы должны рассмотреть. С синтезаторы могут эффективно конвертировать RTL в логические элементы, нам не нужно затрагивать более низкий уровень детализации.

== Определение транзакции ==

Для более подробного рассмотрения TLM, мы должны сделать шаг назад и определить понятие транзакции.

[[Файл:61.png]]

Это самое общее определение транзакции. Оно утверждает, что транзакция – это все, что происходит в проекте (или модуле или подсистеме проекта) между двумя точками времени. Хотя оно точное, оно является настолько общим, что не приводит к практическому применению. Более полезные определения следующие:

[[Файл:62.png]]
<blockquote>Транзакция — передача управления и данных между двумя элементами (компонентами)</blockquote>

Это аппаратно-ориентированные понятие транзакции. Когда смотришь на часть аппаратного обеспечения, вы можете легко определить элементы, между которыми передается управление или данные. В проекте с шинной архитектурой, чтение и запись на шину может быть вызвано транзакцией. В пакетной системе связи, отправка пакета представляет собой транзакцию.

Ниже третье определение:

[[Файл:63.png]]

Это определение программно-ориентированного понятия транзакции. В transaction-level модели, деятельность инициируется путем вызова функции. Вызов функции содержит параметры, которые "посылаются" (передаются) вызываемой функции, а возвращаемое значение функции содержит данные, которые возвращаются вызванной функцией. Вызванная функция может блокировать и вызвать задержку (в синхронной системе) или может вернуться (выполниться) немедленно.


== Интерфейсы ==

Прежде чем вдаваться в подробности о том, как построить transaction-level модель, мы сначала обсудим интерфейсы. Термин интерфейс используется в несколько случаях в OVM, каждый раз с немного другим смыслом. Это прискорбный факт истории, то что слово стало означать различные вещи. В большинстве случаев значение будет понятно из контекста, в котором этот термин используется. Различных применения :

* Интерфейс в SystemVerilog
* Интерфейс объекта
* Интерфейс DUT

'''Интерфейс в SystemVerilog'''. SystemVerilog предоставляет конструкцию, называемую интерфейс, который является одним из основных объектов контейнер, из которого строится проект в SystemVerilog. Мы используем виртуальные интерфейсы, которые указывают на интерфейсы для подключения module-based аппаратуры к class-based testbenches.

'''Интерфейс объекта.''' Общедоступные задачи и функции, доступные для объекта, образуют его интерфейс. Есть два небольших варианта этого значения интерфейса. Одним из них является прямой. Посмотрите на класс и определите, какие задачи и функций, доступны пользователю класса. Это его интерфейс. Другое значение состоит в ссылке на базовый класс, который определяет набор задач и функций, доступных для работы производного класса. Это значение интерфейса обычно используется в объектно-ориентированных языках, которые поддерживают множественное наследование, таких как C++ или Java. В этих языках, вы можете установить требование, что производный класс определяет функциональность, наследуемую от интерфейса базового класса.

[[Файл:64.png]]

Интерфейс print_if определяет прототипы для функций печати. Любой класс, который наследуется от print_if затем обязан осуществлять print()и sprint(). SystemVerilog не поддерживает множественное наследование, но он поддерживает истинно виртуальные интерфейсы. Истинно виртуальный интерфейс - интерфейс во втором контексте (базовый класс, который определяет набор задач и функций прототипов), который не имеет реализаций. Истинно виртуальная версия print_if выглядит следующим образом в SystemVerilog:

<big><source lang="cpp">virtual class print_if;
pure virtual function void print();
pure virtual function string sprint();
endclass</source></big>

Даже если SystemVerilog не поддерживает множественное наследование, и OVM построено на SystemVerilog, важно понять истинно виртуальные интерфейсы и наследование интерфейсов, потому что они активно используются в OVM. В частности, TLM ports and exports являются производными от интерфейса класс tlm_if_base.

'''DUT интерфейс.''' Часть аппаратуры, как правило, доступны через свои интерфейсы. В этом контексте, интерфейс состоит из контактов и протоколов используемых для связи с устройством. Например, устройство может иметь USB интерфейс.

== TLM идиомы ==

В данном разделе рассматриваются основные средства передачи транзакций между компонентами. Мы put, get, и transport формы связи транзакций. Эти примеры не используют библиотеку OVM, так как они предназначены для иллюстрации основных механизмов связи на transaction-level с минимальными затратами. В следующем разделе мы рассмотрим более полный пример, который использует OVM библиотека для связи.

=== Put ===
В put конфигурации, один компонент отправляет операции другому компоненту. Операция называется put. Инициатором является компонентом, который инициирует передачу, а целевой компонент, который получает результат. Используя TLM номенклатуру, мы говорим, что инициатор put транзакции цели.

[[Файл:65.png]]

Рисунок 3-2 показывает, что А предает операцию в пункт Б. Инициатор имеет порт, рисуется как квадрат, и цель имеет export, изображается в виде круга. Поток управления направлен от квадрата к кругу, то есть, А вызывает B, который содержит реализацию методов port. Стрелка показывает направление поток данных, и в этом случае, это означает, что данные будут двигаться от А до B.
Мы можем проиллюстрировать код для этих компонентов с producer и consumer. producer является инициатором и consumer является целью. Мы должны строить эти компоненты таким образом, что они не знали друг о друге априори. Чтобы сделать это, мы используем истинно виртуальный интерфейс для определения функции, который будет использоваться для передачи данных между инициатором и целью. Во-первых, давайте взглянем на SystemVerilog версию producer.

<big><source lang="verilog">46 class producer;
47
48 put_if put_port;
49
50 task run();
51
52 int randval;
53
54 for(int i=0; i<10; i++)
55 begin
56 randval = $random %100;
57 $display(“producer: sending %4d”, randval);
58 put_port.put(randval);
59 end
60
61 endtask
62
63 endclass : producer
file: 03_tlm/01_put/put.sv</source></big>

producer - это класс, который создается динамически. Он имеет два ключевых элемента, Run () задачу и put_port. Run () задача является простой задачей, которая повторяется 10 раз и передает 10 транзакций. Для простоты, наши операции являются целыми числами. На практике, транзакция может быть сколь угодно сложным объектом, таким как структура или класс.
Чтобы передать операции, producer вызывает put() на put_port. Что такое put_port? Это не порт в традиционном смысле Verilog. Это ссылка на put_if. Что такое put_if? Put_if это виртуальный интерфейс класса расположенный между инициатором (producer) и целью (consumer).

<big><source lang="verilog">39 virtual class put_if;
40 pure virtual task put(int val);
41 endclass : put_if</source></big>

put_if класс с истинно виртуальными задачами, т.е. задачами, не имеющими реализацию. Без реализации всех своих задач и функций, виртуальный класс не может быть создан сам по себе. Он должен быть базовым классом другого класса, который создается. В нашем случае, класс, производный от истинно виртуального put_if является consumer.

<big><source lang="verilog">68 class consumer extends put_if;
69 task put(int val);
70 $display(“consumer: receiving %4d”, val);
71 endtask : put
72 endclass : consumer
file: 03_tlm/01_put/put.sv
</source></big>

consumer содержит реализацию put(); истинно виртуальные задачи определены в put_if. Задача put() реализация принимает аргументы, переданные ей, и печатает их. put_if играет ключевую роль в соединении consumer и producer. Ссылка на него на стороне producer, которую мы называем порт, устанавливает требование, что должна быть реализация функций и задач интерфейса, к которому этот объект будет привязан. consumer является производным от интерфейса и, следовательно, в нем должны быть реализованы истинно виртуальные задачи, удовлетворяющие требованиям.

Модуль верхнего уровня связывающий producer и consumer.

<big><source lang="verilog">77 module top;
78
79 producer p;
80 consumer c;
81
82 initial begin
83 // instantiate producer and consumer
84 p = new();
85 c = new();
86 // connect producer and consumer
87 // through the put_if interface class
88 p.put_port = c;
89 p.run();
90 end
91 endmodule : top
file: 03_tlm/01_put/put.sv</source></big>

Обратите внимание, что оператор присваивания:

<big><source lang="verilog">88 p.put_port = c;</source></big>

Он образует связь между producer и consumer. Когда new() вызывается на р, чтобы создать новый экземпляр producer, член put_port не имеет значения. Во время выполнения произойдет ошибка, если put_port. put () вызывается до связи назначения. Назначение С к p.put_port дает ссылку для consumer, который содержит реализацию задачи put() интерфейса.

=== Get ===

Дополнением к put является get. В этом устройстве, инициатор получает транзакции от цели. Поток управления такой же, от инициатора к цели, но направление потока данных обратное. Инициатор получает транзакции от цели. В этом случае consumer является инициатором, producer - целью. Consumer инициирует вызов producer для получения транзакции.

[[Файл:66.png]]

Рисунок 3-3 очень похож на рисунок 3-2. Разница лишь в том, что здесь стрелка от цели к инициатору, а не наоборот. Это означает, что потоки данных от цели к инициатору. Ниже SystemVerilog consumer (инициатор).

<big><source lang="verilog">62 class consumer;
63
64 get_if get_port;
65
66 task run();
67 int randval;
68 for(int i=0; i<10; i++)
69 begin
70 get_port.get(randval);
71 $display(“consumer: receiving %4d”, randval);
72 end
73 endtask
74 endclass
file: 03_tlm/02_get/get.sv</source></big>

consumer имеет задачу, run(), которая выполняется 10 раз, чтобы получить 10 транзакций. Producer как в put примере, consumer имеет здесь порт. Кроме того, как в put примере, порт ссылается на истинно виртуальный интерфейс, в данном случае
он называется get_if.

<big><source lang="verilog">41 virtual class get_if;
42 pure virtual task get(output int t);
43 endclass : get_if
file: 03_tlm/02_get/get.sv</source>
</big>
get_if

является истинно виртуальным интерфейс, который определяет функцию get(). Цель (producer) строится аналогично, как и цель в put примере. Она содержит реализацию функции интерфейса. Этот producer генерирует случайное число между 0 и 99.

<big><source lang="verilog">48 class producer extends get_if;
49
50 task get(output int t);
51 int randval;
52 randval = $random % 100;
53 $display(“producer: sending %4d”, randval);
54 t = randval;
55 endtask
56
57 endclass : producer
file: 03_tlm/02_get/get.sv</source></big>

Связи на высшем уровне будут выглядеть очень похожими.

<big><source lang="verilog">79 module top;
80
81 producer p;
82 consumer c;
83
84 initial begin
85 // instantiate producer and consumer
86 p = new();
87 c = new();
88 // connect producer and consumer through the get_if
89 // interface class
90 c.get_port = p;
91 c.run();
92 end
93 endmodule : top
file: 03_tlm/02_get/get.sv</source></big>

После создания объектов producer и consumer, используя операцию new(), два объекта будут соединяться с помощью связей назначения.

=== Transport ===

Transport является двунаправленным интерфейсом. Интерфейс обеспечивает передачу транзакций от инициатора к цели и от цели обратно к инициатору. Как правило, мы используем этот механизм, чтобы смоделировать запрос-ответ протоколы. Когда речь идет о компонентах с двунаправленным интерфейсов, мы используем термины master (ведущего) и slave (ведомого), а не инициатор и цель.

[[Файл:67.png]]

master (A) делает и put и get за один вызов функции. Как мы видели в предыдущих примерах, put() и get() принимают один аргумент, аргумент они помещают или извлекают. Тем не менее, функция transport() имеет два аргумента, запрос и ответ. Она посылает запрос и возвращает ответ. slave (B) принимает запрос и возвращает ответ.

Давайте сначала посмотрим на истинно виртуальный интерфейс.

<big><source lang="verilog">37 virtual class transport_if;
38 pure virtual task transport(input int request,
39 output int response);
40 endclass : transport_if
file: 03_tlm/03_transport/transport.sv</source></big>

Интерфейс содержит одну функцию, transport(), которая принимает два аргумента: запрос, который передается цели и ответ, который возвращается инициатору.

Master вызывает transport(), создает запрос и отправляет его slave, используя transport. Он обрабатывает ответ, который возвращается.

<big><source lang="verilog">45 class master;
46
47 transport_if port;
48
49 task run();
50
51 int request;
52 int response;
53
54 for(int i=0; i<10; i++)
55 begin
56 request = $random % 100;
57 $display(“master: sending request %4d”,
58 request);
59 port.transport(request, response);
60 $display(“master: receiving response %4d”,
61 response);
62 end
63
64 endtask
65 endclass : master
file: 03_tlm/03_transport/transport.sv</source></big>

slave реализует функцию transport(). В нашем примере, она делает некоторые тривиальные обработки запроса для создания ответа.

<big><source lang="verilog">70 class slave extends transport_if;
71
72 task transport(input int request, output int response);
73 $display(“slave: receiving request %4d”,
74 request);
75 response = -request;
76 $display(“slave: sending response %4d”,
77 response);
78 endtask
79
80 endclass
file: 03_tlm/03_transport/transport.sv</source></big>

Связи верхнего уровня между master и slave работают точно так же как и в примере с put и get.

<big><source lang="verilog">85 module top;
86
87 master m;
88 slave s;
89
90 initial begin
91 // instantiate the master and slave
92 m = new();
93 s = new();
94
95 // connect the master and slave through
96 // the port interface
97 m.port = s;
98 m.run();
99 end
100
101 endmodule : top
file: 03_tlm/03_transport/transport.sv</source>
</big>

Связь назначения связывает master и slave. После выполнения соединения, master может использовать соединения для прямого вызова функций slave.

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

Интерфейсы мы рассмотрели ранее блокирующие. Это означает, что функции и задачи блокируют выполнение до их завершения. Им не разрешается заканчиваться неудачей. Не существует механизма для блокировки при аварийном завершении или иным образом изменять поток управления. Они просто ждать, пока запрос будет выполнен. В синхронизированной системе это означает, что время может пройти между вызовом и возвращением полученного результата.

В put конфигурации, у нас есть два компонента, producer и consumer. Producer генерирует случайное число и посылает его к consumer, используя put(). Прежде чем вызывается put(), нет активности в consumer. Вызов put() вызывает активность в consumer, которая выводит значение аргумента. За то время, что consumer является активным, producer ожидает. Это природа блокирующего вызова. Вызывающий должен ждать, пока вызов завершиться для возобновления выполнения.

Теперь сравните это описание с неблокирующим вызовом. Неблокирующий вызов возвращается немедленно. Семантика неблокирующего вызова гарантирует, что вызов возвращается в том же дельта цикле, в котором он был запущен, то есть без задержки, даже на один дельта цикл.

Истинно виртуальный интерфейс, который соединяет неблокирующего slave и master выглядит так же, как другие истинно виртуальные интерфейсы, которые мы видели. Значительная разница в том, что nb_get () возвращает значение статуса вместо транзакции.

<big><source lang="verilog">41 virtual class get_if;
42 pure virtual function int nb_get(output int t);
43 endclass : get_if
file: 03_tlm/04_nonblocking/nbget.sv</source>
</big>

master (consumer) должен проверить состояние, возвращаемое из nb_get (), чтобы определить, завершена ли функция успешно. Отметим также, что мы ввели время в модель. Consumer проверяет каждый 4 нс доступность значения.

<big><source lang="verilog">78 class consumer;
79
80 get_if get_port;
81
82 task run();
83 int randval;
84 int ok;
85
86 for(int i=0; i<20; i++)
87 begin
88 #4;
89 if(get_port.nb_get(randval))
90 $display(“%t: consumer: receiving %4d”, $time,
randval);
91 else
92 $display(“%t: consumer: no randval”, $time);
93 end
94 endtask
95 endclass
file: 03_tlm/04_nonblocking/nbget.sv</source></big>

producer организован как функция и задача. Задача будет раздвоена (порождена), чтобы запуститься как непрерывный процесс. Он генерирует новые случайные значения, что consumer будет захватывать. Тем не менее, каждая случайная величина доступна только для 2 нс из 7 нс цикла. Функция - реализация nb_get, которая возвращает значение, запускает периодически выполнение run().

<big><source lang="verilog">48 class producer extends get_if;
49
50 int randval = 0;
51 int rand_avail = 0;
52
53 function int nb_get(output int t);
54 if(rand_avail) begin
55 $display(“%t: producer: sending %4d”,
56 $time, randval);
57 t = randval;
58 return 1;
59 end
60 return 0;
61 endfunction
62
63 task run();
64 forever begin;
65 #5;
66 randval = $random % 100;
67 rand_avail = 1;
68 #2;
69 rand_avail = 0;
70 end
71 endtask
72
73 endclass : producer
file: 03_tlm/04_nonblocking/nbget.sv
</source>
</big>

Когда мы запускаем пример, мы видим, что не каждый вызов nb_get () успешен.

<pre>4: consumer: no randval
8: consumer: no randval
12: producer: sending -99
12: consumer: receiving -99
16: consumer: no randval
20: producer: sending -39
20: consumer: receiving -39
24: consumer: no randval
28: producer: sending -9
28: consumer: receiving -9
32: consumer: no randval
36: consumer: no randval
40: producer: sending 57
40: consumer: receiving 57
44: consumer: no randval
48: producer: sending -71
48: consumer: receiving -71
52: consumer: no randval
56: producer: sending -14
56: consumer: receiving -14
60: consumer: no randval
64: consumer: no randval
68: producer: sending 29
68: consumer: receiving 29
72: consumer: no randval
76: producer: sending 18
76: consumer: receiving 18
80: consumer: no randval
</pre>
Блокировать get конфигурацию смог только один процесс - consumer, который постоянно обращался с запросом к producer, чтобы тот отправил новое значение. Неблокирующий вариант состоит из двух этапов: consumer регулярно опрашивает producer, чтобы получить новое значение, и producer генерирует новые значения асинхронно по отношению к consumer. Наши неблокирующий producer генерирует доступное случайное значение каждые 7 нс. Он ждет 5 нс, а затем создает новое значение и новое значение действительно в течение 2 нс. Флаг rand_avail устанавливается, когда случайное значение доступно и сбрасывается в противном случае.

Реализация nb_get () в этом примере должна проверить rand_avail есть ли что отправить. Если нет, то она возвращает 0, чтобы указать, что запрос не удался. Если есть что-то, то он посылает его и возвращает 1, чтобы показать успех.

Блокирующие интерфейсы полезны для работы с двумя компонентами синхронно. Вызовы блокируются до тех пор, пока запрошенная операция выполняется, не смотря на то, сколько это потребует времени. С другой стороны, неблокирующие интерфейсы полезны при асинхронной передаче данных. Они не ждут и могут быть использованы для опроса целей, как в приведенном примере.

== Изоляция компонент с помощью каналов ==

В предыдущем разделе обсуждались простые механизмы для перемещения транзакций между двумя процессами. В каждом, инициатор и цель были сильно синхронизированы вызовом транзакции интерфейса. В этом разделе мы рассмотрим случай, когда инициатор и цель менее тесно связаны, это можно сделать с помощью канала, в этом случае 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.

Файл:68.png

2013-03-13T13:18:35Z

Anastasiya:

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

2013-03-12T08:55:47Z

Anastasiya:

{{OVM TOC}}
__TOC__

= =

Процесс проектирования электронной системы включает в себя последовательное замещение абстрактных идей конкретной их реализацией, пока не будет достигнуто представление, которое может быть изготовлено на кремнии. С момента появления цифровой интегральной схемы, электронные сообщества тщательно определили и кодировали абстракции, начиная с переключателей и логических элементов, для обеспечения среды в которой работает проект. RTL является примером среды, часто используемой для создания проектов. Есть много инструментов на основе RTL, которые делают ее удобной для создания проекта и его верификации.
Однако, как только проект становится больше и сложнее, становится более представлять их с помощью абстракции выше, чем RTL. Уровень транзакций становится популярным для создания первого представления проекта, которое может быть смоделировано и проанализировано.
В этой главе описаны основные понятия transaction-level моделирования (TLM). Модели transaction-level состоят из нескольких процессов, которые обмениваются информацией посредством транзакций.

== Абстракция ==

RTL моделирование использует дискретную модель времени. Связь между процессами осуществляется с помощью сетки ( цепи), и процесс активации происходит при изменении значения во входной сети ( цепи).
Для сравнения, transaction-level модели (моделирующей схемы) могут быть синхронизированы или не синхронизированы и использовать шину для обмена данными между процессами. Вместо того чтобы посылать отдельные биты туда и обратно, процессы общаются, посылая транзакции друг другу посредством вызова функций. Мир TLM включает в себя ряд моделей(моделирующих схем) вычислений с различным временем, системами связи и процессами активации моделей (моделирующей схемы). В каждом конкретном случае, содержание связей находится на более высоком уровне абстракции, чем отдельные биты. Таким образом, transaction-level модель находится на более высоком уровне абстракции (более абстрактна), чем RTL модель. Объединяя понятия абстракции и модели (моделирующей схемы) вычислений, видно, что создание абстрактных моделей означает абстрагирование времени, данных и функций.

'''Абстракция времени.''' Время абстракция в симуляторе относится к тому, насколько внутренние состояния схемы совместимы. Модели, запущенные в управляемых событиями симуляторах (например, логических симуляторах) используют дискретное представление времени, то есть события происходят в определенные моменты времени. События, как правило (хотя и не всегда) вызывают запущенный процесс. Чем больше событий происходит в симуляции, больше процессов вызывается, и с большим числом процессов происходит снижении скорости моделирования. Абстрагирование время уменьшает количество точек, где схема должна быть совместимой и общего числа событий и процессов, которые будут активированы. Например, в RTL модели, каждая сеть должна быть согласована после каждого изменения. В cycle-accurate абстракции, схема должна быть синхронизирована с синхросигналом, устраняя все события, что происходит между фронтами синхроимпульса. В transaction-level модели, состояния схемы должны быть синхронизированы в конце каждой операции, каждая из которых может охватывать много тактов.

'''Абстракция данных'''. Данные относятся к объектам, передаваемым между компонентами. В RTL моделях, данные относятся к отдельным битам, которые передаются по сети между компонентами. В transaction-level моделях, данных представлены в виде транзакций, гетерогенных структур, которые содержат произвольные коллекции элементов.
Рассмотрим пакет в устройстве связи. На самом низком уровне детализации, пакет содержит бит начала и стоп-биты, заголовок, информацию исправления ошибок, размер полезной нагрузки, нагрузки, и завершитель (??????). В более абстрактной модели, только нагрузка и размер нагрузки могут быть необходимы. Другие данные не нужны для выполнения расчетов.

'''Абстракция функций.''' Функция модели является набором всех операций, которая она делать на каждое событие. Абстрагирование функций уменьшает этот набор или заменяет его более простыми вычислениями. Например, в ALU, вы можете выбрать использование родной операции умножении поставляемой в язык моделирования, вместо кодирования a shift-and-add алгоритма умножения. Последний может быть частью реализации, но на более высоком уровне, детали a shift-and-add - неважны. Базовые элементы, которые являются частью языка, определяет, как вы можете абстрагировать функцию. В gate-level языке, например, можно создавать сложные поведения, начиная с логических элементов. В RTL языка, построение поведения основывается на арифметических и логических операциях над регистрами. В TLM, вы реализуете функциональность схемы с помощью вызовов функций произвольной сложности.

Для целей функциональной верификации, RTL самый низкий уровень абстракции, который мы должны рассмотреть. С синтезаторы могут эффективно конвертировать RTL в логические элементы, нам не нужно затрагивать более низкий уровень детализации.

== Определение транзакции ==

Для более подробного рассмотрения TLM, мы должны сделать шаг назад и определить понятие транзакции.

[[Файл:61.png]]

Это самое общее определение транзакции. Оно утверждает, что транзакция – это все, что происходит в проекте (или модуле или подсистеме проекта) между двумя точками времени. Хотя оно точное, оно является настолько общим, что не приводит к практическому применению. Более полезные определения следующие:

[[Файл:62.png]]

Это аппаратно-ориентированные понятие транзакции. Когда смотришь на часть аппаратного обеспечения, вы можете легко определить сущности, между которыми передается управление или данные. В проекте с шинной архитектурой, чтение и запись на шину может быть вызвано транзакцией. В пакетной системе связи, отправка пакета представляет собой транзакцию.

Ниже третье определение:

[[Файл:63.png]]

Это определение программно-ориентированного понятия транзакции. В transaction-level модели, деятельность инициируется путем вызова функции. Вызов функции содержит параметры, которые "послали" вызываемой функции, и возвращаемого значения функции. Вызванная функция может блокировать и cause time to pass or it could return immediately.

== Интерфейсы ==

Прежде чем вдаваться в подробности о том, как построить transaction-level модель, мы сначала обсудим интерфейсы. Термин интерфейс используется в несколько случаях в OVM, каждый раз с немного другим смыслом. Это прискорбный факт истории, то что слово стало означать различные вещи. В большинстве случаев значение будет понятно из контекста, в котором этот термин используется. Различных применения :

• Интерфейс SystemVerilog

• Объектный интерфейс

• Интерфейс DUT

'''SystemVerilog интерфейс'''. SystemVerilog предоставляет конструкцию, называемую интерфейс, который является одним из основных объектов контейнер, из которого строится проект в SystemVerilog. Мы используем виртуальные интерфейсы, которые указывают на интерфейсы для подключения module-based аппаратуры к class-based testbenches.

'''Объектный интерфейс.''' Общедоступные задачи и функции, доступные для объекта образует его интерфейс. Есть два небольших изменения этого значения интерфейс. Одним из них является прямой. Посмотрите на класс и определите, какие задачи и функций, доступны пользователю класса. Это его интерфейс. Другой вариант состоит в ссылке на базовый класс, который определяет набор задач и функций, доступных для работы производного класса. Это значение интерфейса обычно используется объектно-ориентированных языков, которые поддерживают множественное наследование, таких как C + + или java. В этих языках, вы можете установить требование, что производный класс определяет функциональность, наследуемую от интерфейса базового класса.

[[Файл:64.png]]

Интерфейс print_if определяет прототипы для функций печати. Любой класс, который наследуется от print_if затем обязан осуществлять print()и sprint(). SystemVerilog не поддерживает множественное наследование, но он поддерживает истинно виртуальные интерфейсы. Истинно виртуальный интерфейс - интерфейс во втором контексте (базовый класс, который определяет набор задач и функций прототипов), который не имеет реализаций. Истинно виртуальная версия print_if выглядит следующим образом в SystemVerilog:

<big><source lang="cpp">virtual class print_if;
pure virtual function void print();
pure virtual function string sprint();
endclass</source></big>

Даже если SystemVerilog не поддерживает множественное наследование, и OVM построено на SystemVerilog, важно понять истинно виртуальные интерфейсы и наследование интерфейсов, потому что они активно используются в OVM. В частности, TLM ports and exports являются производными от интерфейса класс tlm_if_base.

'''DUT интерфейс.''' Часть аппаратуры, как правило, доступны через свои интерфейсы. В этом контексте, интерфейс состоит из контактов и протоколов используемых для связи с устройством. Например, устройство может иметь USB интерфейс.

== TLM идиомы ==

В данном разделе рассматриваются основные средства передачи транзакций между компонентами. Мы put, get, и transport формы связи транзакций. Эти примеры не используют библиотеку OVM, так как они предназначены для иллюстрации основных механизмов связи на transaction-level с минимальными затратами. В следующем разделе мы рассмотрим более полный пример, который использует OVM библиотека для связи.

=== Put ===
В put конфигурации, один компонент отправляет операции другому компоненту. Операция называется put. Инициатором является компонентом, который инициирует передачу, а целевой компонент, который получает результат. Используя TLM номенклатуру, мы говорим, что инициатор put транзакции цели.

[[Файл:65.png]]

Рисунок 3-2 показывает, что А предает операцию в пункт Б. Инициатор имеет порт, рисуется как квадрат, и цель имеет export, изображается в виде круга. Поток управления направлен от квадрата к кругу, то есть, А вызывает B, который содержит реализацию методов port. Стрелка показывает направление поток данных, и в этом случае, это означает, что данные будут двигаться от А до B.
Мы можем проиллюстрировать код для этих компонентов с producer и consumer. producer является инициатором и consumer является целью. Мы должны строить эти компоненты таким образом, что они не знали друг о друге априори. Чтобы сделать это, мы используем истинно виртуальный интерфейс для определения функции, который будет использоваться для передачи данных между инициатором и целью. Во-первых, давайте взглянем на SystemVerilog версию producer.

<big><source lang="verilog">46 class producer;
47
48 put_if put_port;
49
50 task run();
51
52 int randval;
53
54 for(int i=0; i<10; i++)
55 begin
56 randval = $random %100;
57 $display(“producer: sending %4d”, randval);
58 put_port.put(randval);
59 end
60
61 endtask
62
63 endclass : producer
file: 03_tlm/01_put/put.sv</source></big>

producer - это класс, который создается динамически. Он имеет два ключевых элемента, Run () задачу и put_port. Run () задача является простой задачей, которая повторяется 10 раз и передает 10 транзакций. Для простоты, наши операции являются целыми числами. На практике, транзакция может быть сколь угодно сложным объектом, таким как структура или класс.
Чтобы передать операции, producer вызывает put() на put_port. Что такое put_port? Это не порт в традиционном смысле Verilog. Это ссылка на put_if. Что такое put_if? Put_if это виртуальный интерфейс класса расположенный между инициатором (producer) и целью (consumer).

<big><source lang="verilog">39 virtual class put_if;
40 pure virtual task put(int val);
41 endclass : put_if</source></big>

put_if класс с истинно виртуальными задачами, т.е. задачами, не имеющими реализацию. Без реализации всех своих задач и функций, виртуальный класс не может быть создан сам по себе. Он должен быть базовым классом другого класса, который создается. В нашем случае, класс, производный от истинно виртуального put_if является consumer.

<big><source lang="verilog">68 class consumer extends put_if;
69 task put(int val);
70 $display(“consumer: receiving %4d”, val);
71 endtask : put
72 endclass : consumer
file: 03_tlm/01_put/put.sv
</source></big>

consumer содержит реализацию put(); истинно виртуальные задачи определены в put_if. Задача put() реализация принимает аргументы, переданные ей, и печатает их. put_if играет ключевую роль в соединении consumer и producer. Ссылка на него на стороне producer, которую мы называем порт, устанавливает требование, что должна быть реализация функций и задач интерфейса, к которому этот объект будет привязан. consumer является производным от интерфейса и, следовательно, в нем должны быть реализованы истинно виртуальные задачи, удовлетворяющие требованиям.

Модуль верхнего уровня связывающий producer и consumer.

<big><source lang="verilog">77 module top;
78
79 producer p;
80 consumer c;
81
82 initial begin
83 // instantiate producer and consumer
84 p = new();
85 c = new();
86 // connect producer and consumer
87 // through the put_if interface class
88 p.put_port = c;
89 p.run();
90 end
91 endmodule : top
file: 03_tlm/01_put/put.sv</source></big>

Обратите внимание, что оператор присваивания:

<big><source lang="verilog">88 p.put_port = c;</source></big>

Он образует связь между producer и consumer. Когда new() вызывается на р, чтобы создать новый экземпляр producer, член put_port не имеет значения. Во время выполнения произойдет ошибка, если put_port. put () вызывается до связи назначения. Назначение С к p.put_port дает ссылку для consumer, который содержит реализацию задачи put() интерфейса.

=== Get ===

Дополнением к put является get. В этом устройстве, инициатор получает транзакции от цели. Поток управления такой же, от инициатора к цели, но направление потока данных обратное. Инициатор получает транзакции от цели. В этом случае consumer является инициатором, producer - целью. Consumer инициирует вызов producer для получения транзакции.

[[Файл:66.png]]

Рисунок 3-3 очень похож на рисунок 3-2. Разница лишь в том, что здесь стрелка от цели к инициатору, а не наоборот. Это означает, что потоки данных от цели к инициатору. Ниже SystemVerilog consumer (инициатор).

<big><source lang="verilog">62 class consumer;
63
64 get_if get_port;
65
66 task run();
67 int randval;
68 for(int i=0; i<10; i++)
69 begin
70 get_port.get(randval);
71 $display(“consumer: receiving %4d”, randval);
72 end
73 endtask
74 endclass
file: 03_tlm/02_get/get.sv</source></big>

consumer имеет задачу, run(), которая выполняется 10 раз, чтобы получить 10 транзакций. Producer как в put примере, consumer имеет здесь порт. Кроме того, как в put примере, порт ссылается на истинно виртуальный интерфейс, в данном случае
он называется get_if.

<big><source lang="verilog">41 virtual class get_if;
42 pure virtual task get(output int t);
43 endclass : get_if
file: 03_tlm/02_get/get.sv</source>
</big>
get_if

является истинно виртуальным интерфейс, который определяет функцию get(). Цель (producer) строится аналогично, как и цель в put примере. Она содержит реализацию функции интерфейса. Этот producer генерирует случайное число между 0 и 99.

<big><source lang="verilog">48 class producer extends get_if;
49
50 task get(output int t);
51 int randval;
52 randval = $random % 100;
53 $display(“producer: sending %4d”, randval);
54 t = randval;
55 endtask
56
57 endclass : producer
file: 03_tlm/02_get/get.sv</source></big>

Связи на высшем уровне будут выглядеть очень похожими.

<big><source lang="verilog">79 module top;
80
81 producer p;
82 consumer c;
83
84 initial begin
85 // instantiate producer and consumer
86 p = new();
87 c = new();
88 // connect producer and consumer through the get_if
89 // interface class
90 c.get_port = p;
91 c.run();
92 end
93 endmodule : top
file: 03_tlm/02_get/get.sv</source></big>

После создания объектов producer и consumer, используя операцию new(), два объекта будут соединяться с помощью связей назначения.

=== Transport ===

Transport является двунаправленным интерфейсом. Интерфейс обеспечивает передачу транзакций от инициатора к цели и от цели обратно к инициатору. Как правило, мы используем этот механизм, чтобы смоделировать запрос-ответ протоколы. Когда речь идет о компонентах с двунаправленным интерфейсов, мы используем термины master (ведущего) и slave (ведомого), а не инициатор и цель.

[[Файл:67.png]]

master (A) делает и put и get за один вызов функции. Как мы видели в предыдущих примерах, put() и get() принимают один аргумент, аргумент они помещают или извлекают. Тем не менее, функция transport() имеет два аргумента, запрос и ответ. Она посылает запрос и возвращает ответ. slave (B) принимает запрос и возвращает ответ.

Давайте сначала посмотрим на истинно виртуальный интерфейс.

<big><source lang="verilog">37 virtual class transport_if;
38 pure virtual task transport(input int request,
39 output int response);
40 endclass : transport_if
file: 03_tlm/03_transport/transport.sv</source></big>

Интерфейс содержит одну функцию, transport(), которая принимает два аргумента: запрос, который передается цели и ответ, который возвращается инициатору.

Master вызывает transport(), создает запрос и отправляет его slave, используя transport. Он обрабатывает ответ, который возвращается.

<big><source lang="verilog">45 class master;
46
47 transport_if port;
48
49 task run();
50
51 int request;
52 int response;
53
54 for(int i=0; i<10; i++)
55 begin
56 request = $random % 100;
57 $display(“master: sending request %4d”,
58 request);
59 port.transport(request, response);
60 $display(“master: receiving response %4d”,
61 response);
62 end
63
64 endtask
65 endclass : master
file: 03_tlm/03_transport/transport.sv</source></big>

slave реализует функцию transport(). В нашем примере, она делает некоторые тривиальные обработки запроса для создания ответа.

<big><source lang="verilog">70 class slave extends transport_if;
71
72 task transport(input int request, output int response);
73 $display(“slave: receiving request %4d”,
74 request);
75 response = -request;
76 $display(“slave: sending response %4d”,
77 response);
78 endtask
79
80 endclass
file: 03_tlm/03_transport/transport.sv</source></big>

Связи верхнего уровня между master и slave работают точно так же как и в примере с put и get.

<big><source lang="verilog">85 module top;
86
87 master m;
88 slave s;
89
90 initial begin
91 // instantiate the master and slave
92 m = new();
93 s = new();
94
95 // connect the master and slave through
96 // the port interface
97 m.port = s;
98 m.run();
99 end
100
101 endmodule : top
file: 03_tlm/03_transport/transport.sv</source>
</big>

Связь назначения связывает master и slave. После выполнения соединения, master может использовать соединения для прямого вызова функций slave.

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

Интерфейсы мы рассмотрели ранее блокирующие. Это означает, что функции и задачи блокируют выполнение до их завершения. Им не разрешается заканчиваться неудачей. Не существует механизма для блокировки при аварийном завершении или иным образом изменять поток управления. Они просто ждать, пока запрос будет выполнен. В синхронизированной системе это означает, что время может пройти между вызовом и возвращением полученного результата.

В put конфигурации, у нас есть два компонента, producer и consumer. Producer генерирует случайное число и посылает его к consumer, используя put(). Прежде чем вызывается put(), нет активности в consumer. Вызов put() вызывает активность в consumer, которая выводит значение аргумента. За то время, что consumer является активным, producer ожидает. Это природа блокирующего вызова. Вызывающий должен ждать, пока вызов завершиться для возобновления выполнения.

Теперь сравните это описание с неблокирующим вызовом. Неблокирующий вызов возвращается немедленно. Семантика неблокирующего вызова гарантирует, что вызов возвращается в том же дельта цикле, в котором он был запущен, то есть без задержки, даже на один дельта цикл.

Истинно виртуальный интерфейс, который соединяет неблокирующего slave и master выглядит так же, как другие истинно виртуальные интерфейсы, которые мы видели. Значительная разница в том, что nb_get () возвращает значение статуса вместо транзакции.

<big><source lang="verilog">41 virtual class get_if;
42 pure virtual function int nb_get(output int t);
43 endclass : get_if
file: 03_tlm/04_nonblocking/nbget.sv</source>
</big>

master (consumer) должен проверить состояние, возвращаемое из nb_get (), чтобы определить, завершена ли функция успешно. Отметим также, что мы ввели время в модель. Consumer проверяет каждый 4 нс доступность значения.

<big><source lang="verilog">78 class consumer;
79
80 get_if get_port;
81
82 task run();
83 int randval;
84 int ok;
85
86 for(int i=0; i<20; i++)
87 begin
88 #4;
89 if(get_port.nb_get(randval))
90 $display(“%t: consumer: receiving %4d”, $time,
randval);
91 else
92 $display(“%t: consumer: no randval”, $time);
93 end
94 endtask
95 endclass
file: 03_tlm/04_nonblocking/nbget.sv</source></big>

producer организован как функция и задача. Задача будет раздвоена (порождена), чтобы запуститься как непрерывный процесс. Он генерирует новые случайные значения, что consumer будет захватывать. Тем не менее, каждая случайная величина доступна только для 2 нс из 7 нс цикла. Функция - реализация nb_get, которая возвращает значение, запускает периодически выполнение run().

<big><source lang="verilog">48 class producer extends get_if;
49
50 int randval = 0;
51 int rand_avail = 0;
52
53 function int nb_get(output int t);
54 if(rand_avail) begin
55 $display(“%t: producer: sending %4d”,
56 $time, randval);
57 t = randval;
58 return 1;
59 end
60 return 0;
61 endfunction
62
63 task run();
64 forever begin;
65 #5;
66 randval = $random % 100;
67 rand_avail = 1;
68 #2;
69 rand_avail = 0;
70 end
71 endtask
72
73 endclass : producer
file: 03_tlm/04_nonblocking/nbget.sv
</source>
</big>

Когда мы запускаем пример, мы видим, что не каждый вызов nb_get () успешен.

4: consumer: no randval

8: consumer: no randval

12: producer: sending -99

12: consumer: receiving -99

16: consumer: no randval

20: producer: sending -39

20: consumer: receiving -39

24: consumer: no randval

28: producer: sending -9

28: consumer: receiving -9

32: consumer: no randval

36: consumer: no randval

40: producer: sending 57

40: consumer: receiving 57

44: consumer: no randval

48: producer: sending -71

48: consumer: receiving -71

52: consumer: no randval

56: producer: sending -14

56: consumer: receiving -14

60: consumer: no randval

64: consumer: no randval

68: producer: sending 29

68: consumer: receiving 29

72: consumer: no randval

76: producer: sending 18

76: consumer: receiving 18

80: consumer: no randval

Блокировать get конфигурацию смог только один процесс - consumer, который постоянно обращался с запросом к producer, чтобы тот отправил новое значение. Неблокирующий вариант состоит из двух этапов: consumer регулярно опрашивает producer, чтобы получить новое значение, и producer генерирует новые значения асинхронно по отношению к consumer. Наши неблокирующий producer генерирует доступное случайное значение каждые 7 нс. Он ждет 5 нс, а затем создает новое значение и новое значение действительно в течение 2 нс. Флаг rand_avail устанавливается, когда случайное значение доступно и сбрасывается в противном случае.

Реализация nb_get () в этом примере должна проверить rand_avail есть ли что отправить. Если нет, то она возвращает 0, чтобы указать, что запрос не удался. Если есть что-то, то он посылает его и возвращает 1, чтобы показать успех.

Блокирующие интерфейсы полезны для работы с двумя компонентами синхронно. Вызовы блокируются до тех пор, пока запрошенная операция выполниться, не смотря на то, сколько это может занять. С другой стороны, неблокирующие интерфейсы полезны для использования в асинхронном режиме. Они не ждут и могут быть использованы для опроса цели, как в приведенном примере.

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

2013-03-12T07:51:19Z

Anastasiya:

Файл:67.png

2013-03-12T07:43:13Z

Anastasiya:

Файл:66.png

2013-03-12T07:42:56Z

Anastasiya:

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

2013-03-10T16:27:31Z

Anastasiya:

Файл:65.png

2013-03-10T16:19:01Z

Anastasiya:

Файл:64.png

2013-03-10T16:18:47Z

Anastasiya:

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

2013-03-10T14:47:36Z

Anastasiya:

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

2013-03-10T14:44:52Z

Anastasiya: Новая страница: «Процесс проектирования электронной системы включает в себя последовательное замещение…»

Процесс проектирования электронной системы включает в себя последовательное замещение абстрактных идей конкретной их реализацией, пока не будет достигнуто представление, которое может быть изготовлено на кремнии. С момента появления цифровой интегральной схемы, электронные сообщества тщательно определили и кодировали абстракции, начиная с переключателей и логических элементов, для обеспечения среды в которой работает проект. RTL является примером среды, часто используемой для создания проектов. Есть много инструментов на основе RTL, которые делают ее удобной для создания проекта и его верификации.
Однако, как только проект становится больше и сложнее, становится более представлять их с помощью абстракции выше, чем RTL. Уровень транзакций становится популярным для создания первого представления проекта, которое может быть смоделировано и проанализировано.
В этой главе описаны основные понятия transaction-level моделирования (TLM). Модели transaction-level состоят из нескольких процессов, которые обмениваются информацией посредством транзакций.

3.1 Абстракция
RTL моделирование использует дискретную модель времени. Связь между процессами осуществляется с помощью сетки ( цепи), и процесс активации происходит при изменении значения во входной сети ( цепи).
Для сравнения, transaction-level модели (моделирующей схемы) могут быть синхронизированы или не синхронизированы и использовать шину для обмена данными между процессами. Вместо того чтобы посылать отдельные биты туда и обратно, процессы общаются, посылая транзакции друг другу посредством вызова функций. Мир TLM включает в себя ряд моделей(моделирующих схем) вычислений с различным временем, системами связи и процессами активации моделей (моделирующей схемы). В каждом конкретном случае, содержание связей находится на более высоком уровне абстракции, чем отдельные биты. Таким образом, transaction-level модель находится на более высоком уровне абстракции (более абстрактна), чем RTL модель. Объединяя понятия абстракции и модели (моделирующей схемы) вычислений, видно, что создание абстрактных моделей означает абстрагирование времени, данных и функций.
Абстракция времени. Время абстракция в симуляторе относится к тому, насколько внутренние состояния схемы совместимы. Модели, запущенные в управляемых событиями симуляторах (например, логических симуляторах) используют дискретное представление времени, то есть события происходят в определенные моменты времени. События, как правило (хотя и не всегда) вызывают запущенный процесс. Чем больше событий происходит в симуляции, больше процессов вызывается, и с большим числом процессов происходит снижении скорости моделирования. Абстрагирование время уменьшает количество точек, где схема должна быть совместимой и общего числа событий и процессов, которые будут активированы. Например, в RTL модели, каждая сеть должна быть согласована после каждого изменения. В cycle-accurate абстракции, схема должна быть синхронизирована с синхросигналом, устраняя все события, что происходит между фронтами синхроимпульса. В transaction-level модели, состояния схемы должны быть синхронизированы в конце каждой операции, каждая из которых может охватывать много тактов.

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

3.2 Определение транзакции
Для более подробного рассмотрения TLM, мы должны сделать шаг назад и определить понятие транзакции.

[[Файл:61.png]]

Это самое общее определение транзакции. Оно утверждает, что транзакция – это все, что происходит в проекте (или модуле или подсистеме проекта) между двумя точками времени. Хотя оно точное, оно является настолько общим, что не приводит к практическому применению. Более полезные определения следующие:

[[Файл:62.png]]

Это аппаратно-ориентированные понятие транзакции. Когда смотришь на часть аппаратного обеспечения, вы можете легко определить сущности, между которыми передается управление или данные. В проекте с шинной архитектурой, чтение и запись на шину может быть вызвано транзакцией. В пакетной системе связи, отправка пакета представляет собой транзакцию.

Ниже третье определение:

[[Файл:63.png]]

Это определение программно-ориентированного понятия транзакции. В transaction-level модели, деятельность инициируется путем вызова функции. Вызов функции содержит параметры, которые "послали" вызываемой функции, и возвращаемого значения функции. Вызванная функция может блокировать и cause time to pass or it could return immediately.

Файл:63.png

2013-03-10T14:42:33Z

Anastasiya:

Файл:62.png

2013-03-10T14:42:18Z

Anastasiya:

Файл:61.png

2013-03-10T14:42:04Z

Anastasiya:

OVM

2013-03-10T14:41:32Z

Anastasiya: /* Описание проекта */

{{OVM_TOC}}
__TOC__
== Описание проекта ==
* [http://redmine.simhard.com/projects/ovm Контроль проекта]
* [http://simhard.com/websvn/listing.php?repname=ovm Просмотр репозитория проекта]
* [[OVM/OVM методология | OVM методология ]]
**[[OVM/OVM методология/Введение| Введение]]
**[[OVM/OVM методология/Основы верификации| Основы верификации]]
**[[OVM/OVM методология/Основы объектно-ориентированного программирования| Основы объектно-ориентированного программирования]]
**[[OVM/OVM методология/Transaction-Level моделирование|Transaction-Level моделирование]]

== Литература ==
* [[OVM/Ссылки | Ссылки ]]
* [[OVM/Книги | Книги ]]
* [[OVM/Стандарт OVM| Стандарт OVM ]]
== TO DO ==
* [[OVM/Описание пакетов | Описание пакетов ]]
* [[OVM/Описание функций | Описание функций ]]
* [[OVM/Тестовый план | Тестовый план ]]

[[Категория:Дипломы-2013]]

OVM/OVM методология/Основы верификации

2013-03-05T13:29:53Z

Anastasiya: /* 3-х разрядный счетчик */

{{OVM TOC}}
__TOC__

= =

== Основы верификации==

Функционально проверить устройство означает, сравнить цель разработчика с полученным поведением на их эквивалентность. Мы считаем устройство проверенным, когда, к всеобщему удовлетворению, оно работает в соответствии с целью разработчика. Этот основной принцип часто теряется при использовании testbenches, среды контроля, отладки, моделирования , и все другие средства, применяемые в современных технологических проверках. Чтобы узнать, работает ли верно устройство, вы должны сравнить его с некоторыми известными эталоном, который представляет цель разработчика. Каждый testbench имеет своего рода эталонную модель и средство для сравнения функциональность устройство с эталоном.

Когда мы говорим "устройство", мы имеем в виду проверяемое устройство, часто называемое тестируемое устройство или DUT. Чтобы проверить, DUT, как правило, представлен форме подходящей для производства, которое может быть перенесено на кремний с помощью автоматизированных и ручных средств. Мы различаем DUT от эскиза на обратной стороне салфетки или окончательного нанесенный на кристалл, ни один из которых не может быть проверен. Эталонная модель отражает цели разработчика, то есть то, что устройство должно делать.Эталон может принимать различные формы, такие как документ, описывающий работу DUT, golden модель, которая содержит уникальный алгоритм, или assertions, которые представляют протокол.

[[Файл:1.png]]

Для автоматизации сравнения поведения и эталона, оба должны быть представлены в форме, которую можно выполнить на компьютере с помощью некоторых программ, что делает сравнение.

==== Два вопроса====

Проверка устройства включает в себя два вопроса:Does it work? (Работает ли это устройство?) и Are we done? (Сделали ли мы?). Это основные, и некоторые сказали бы, очевидные вопросы. Тем не менее они
мотивируют всю механику каждой проверочного потока. Первый вопрос - это Does it work? Этот вопрос исходит от основной идеи верификации. Он спрашивает, Соответствует ли устройство эталону? Второй вопрос - Are we done? Он спрашивает, довольны ли мы сравнительным анализом полученной схемы и эталона для определения работает ли устройство согласно цели, если нет, то почему. Мы используем эти ценные вопросы создания основы для разработки эффективных testbenches.

====Does it work?====

Does it work? Это не единственный вопрос, а категория вопросов, которые представляют природу DUT. Каждый проект будет иметь свой собственный набор Does-It-Work вопросов, чья роль заключается в определении правильного функционирования устройства. Функциональные вопросы определяют, ведет ли себя устройство должным образом в конкретных ситуациях. Мы получаем эти вопросы непосредственно из цели разработки устройства, и мы используем их, чтобы отразить цель проекта в testbench.

Рассмотрим простой маршрутизатор пакетов в качестве примера. Это устройство маршрутизации пакетов от входа к одному из четырех портов вывода. Пакеты содержат адреса портов назначения и имеют различные длины полезной нагрузки. Каждый пакет имеет заголовок, трейлер, и два байта для циклического избыточного кода (CRC). Does-It-Work вопросы в этом случае должны быть следующие:

*пакет, поступающий на вход порта, адресованный на имя выходного порта 3, прибыл на порт 3?
*пакет длиной 16 пришел без изменений?
*CRC байты правильны, если полезная нагрузка [0f 73 a8 c2 3e 57 11 0a 88 FF 00 00 33 2b 4c 89]?

Это простой пример полного набора вопросов. Для устройства даже такого простого как этот гипотетическое маршрутизатор, набор Does-It-Work вопросов может быть длинным. Чтобы построить план проверки и testbench, который поддерживает план, вы должны сначала перечислить все вопросы или показать как получит полный набор вопросов, а затем выберите те, которые являются интересными.

Продолжая пример маршрутизатора пакетов,для того чтобы перечислить все Does-It-Work вопросы, вы можете создать таблицу:

[[Файл:2.png]]

Приведенная выше таблица содержит два вида вопросов, те, на которые мы можем ответить сразу и те, которые мы можно разбить на более мелкие вопросы. Вопрос 1 из ряда вопросов, которые можно представить в виде:

[[Файл:3.png]]
[[Файл:4.png]]

Обратите внимание, что мы формулируем все вопросы, так что на них можно ответить да или нет. В конце концов, схема работает либо нет – она либо готова для синтеза, размещения и трассировке, либо нет. Если вы можете ответить на все вопросы утвердительно, тогда проект готов для следующего производственного шага.
При разработке набора does-it-work вопросов, не забудьте сформулировать их таким образом, чтобы на них можно было ответить да или нет. Ответ да положителен, то есть, ответить да означает, что устройство работает правильно. Это будет сделать легче, чем пытаться отслеживать на какие вопросы нужно ответить да, и на какие следует ответить нет. Такой вопрос как Передает ли маршрутизатор ошибочные пакеты? требует ответа нет, чтобы считаться успешным. Лучшей формулировкой вопроса будет: Отклоняет ли маршрутизатор ошибочные пакеты? Вы должны сделать вопросы наиболее конкретными, даже если лучшее звучание будет: Когда ошибочный пакет попадает на входной порт, маршрутизатор обнаруживает его, подает сигнал ошибки и отклоняет этот пакет? Имейте в виду, что более конкретные вопросы более подробно описывают устройство. Ваш testbench должен дать ответ да или нет.
Тщательно сформулированный да или нет вопрос содержит свои собственные критерии успеха. Он сообщает, что получает ответа да. Такой вопрос как, Средняя задержка менее 27 тактов? содержит метрику, 27 тактов, и форму сравнения, меньше. Если вопрос (неправильно) сформулирован, например, Какова средняя задержка прохождения пакетов через маршрутизатор? мы не будем знать, что считается приемлемым. Чтобы ответить на ваш вопрос, вы в первую очередь должны быть в состоянии определить среднее время задержки. Только при правильной постановке вопроса мы знаем, как сделать сравнение, чтобы определить, является ли результат правильным. Метрика сама по себе не говорит нам о том, функционирует ли схема как задумано. Когда мы сравниваем измеренное значение со значением в спецификации, 27 тактов в этом примере, мы можем определить, работает ли схема.
Как это часто бывает, это не практично перечислять каждый does-it-work вопрос. Чтобы убедиться, что каждое слово в памяти 1 Мб можно записать и читать, непрактично и не необходимо записать один миллион вопросов. Вместо этого, вопрос-генератор, вопрос, который генерирует многие другие, занимает место миллиона отдельных вопросов. Может каждый миллион слов в памяти быть успешно записан и считан? -является вопросом-генератором.
Другие вопросы могут сами по себе представлять классы вопросов. Вопрос 3, Является ли вычисление CRC корректным для каждого пакета? является примером такого вопроса. Тестирование CRC вычисления требует ряда тщательно продуманных тестов, для определения является ли вычисления CRC корректным во всех случаях.

==== Are We Done?====

Для определения ответа на вопрос Are we done?, мы должны знать, что мы ответили на достаточное количество does-it-work вопросов, чтобы утверждать, что у нас есть проверенная схема. Мы начинаем эту задачу путем разделения на приоритеты всех does-it-work вопросов по двум направлениям:

[[Файл:5.png]]

Искусство создания testbench требует, чтобы на начальном этапе, мы определили множество вопросов и отсортировали их в соответствии с ценностью возвращаемой информации с точки зрения проверки схемы. Следующий шаг заключается в создании механизма, который будет отвечать на вопросы и определять на какие из них были даны ответы (и на какие нет).

Are-we-done вопросы также называется вопросами функционального покрытия, вопросы, которые устанавливают все ли состояния охватывают тесты с точки зрения функций схемы. Как и does-it-work вопросы, мы можем также разбить вопросы функционального охвата на более подробные вопросы. И как вопросы функциональной корректности, вопросы функционального охвата должны также иметь ответы да или нет. Приведенный ниже список включает в себя примеры вопросы функционального охвата:

• Выполняется ли каждая команда процессора, по крайней мере, один раз?

• Проходит, по крайней мере, один пакет от каждого входного порта до каждого выходного порта?

• Можно ли обратиться к памяти с набором адресов, которые содержат каждый бит адреса как 1 и затем каждый бит адреса 0, не включая 0xffffffff и 0x00000000?(?????????)

Другим мнением об этих вопросах является то, о чем они спрашивают, Получен ли утвердительный ответ на необходимый does-it-work вопрос? Когда мы думаем о функциональном охвате с этой точки зрения, то имеем виду покрытие множества does-it-work вопросов. Кроме того, вопросы охвата распознают метрику и порог для сравнения. Покрытие будет (то есть, охват вопрос можно ответить, да), когда метрика достигает порога.

Таким образом, искусство построения testbench начинается с плана тестирования. План тестирования начинается с тщательно продуманным набором does-it-work и Are-we-done вопросов.

==== Двухпетлевый поток (???????????????)====

Процесс ответа на does-it-work и Are-we-done вопросы может быть описан простой схемой, как показано на рисунке 1-2. Все обусловлено функциональной спецификацией на проектирование. Из функциональной спецификации, вы можете получить саму схему и план верификации. План верификации запускает testbench.

Поток состоит из двух циклов, does-it-work цикла и Are-we-done цикл. Оба цикла начинаются с моделирования. Моделирование тестирует схему при помощи testbench и генерирует информацию, которую мы используем для ответа на вопросы. Сначала мы спрашиваем, Это работает? Если ответ нет, то необходимо отладить проект. Процесс отладки схемы может привести к изменениям в реализации схемы.
Как только схема работает, то пора ответить на вопрос, Are-we-done? Мы ответим на этот вопрос, собирая информацию охвата и сравнения его с порогом, указанным в тестовом плане. Если мы не достигнем порогов, то ответ нет, и мы должны изменить testbench для увеличения охвата. Тогда мы моделируем снова.

Изменение testbench или воздействия может вызвать другие скрытые ошибки в схеме. Последующие итерации по циклу могут заставить нас вернуться к does-it-work циклу снова, чтобы исправить новые ошибки, которые появятся. Как вы можете видеть, полный процесс проверки колеблется вперед и назад между does-it-work и Are-we-done циклами, пока мы не можем утвердительно ответить на все вопросы обоих категорий.

[[Файл:6.png]]

В идеальном мире, схема не имеет ошибок и с покрытием всегда полное, так что вам только надо пройти по каждому циклу один раз, чтобы получить ответы да на оба вопроса. В реальном мире, это может занять много итераций для достижения двух ответов да. Одна из целей хорошего потока проверки свести к минимуму количество итераций для выполнения верификации проекта в кратчайшие сроки с использованием наименьшего количества ресурсов.

== Первый Testbench==

Давайте начнем с проверки одного из самых фундаментальных цифровых электронных устройств, схемы логического И. Логическое И вычисляет логическое умножение входов. Функция этого устройства является тривиальной, а на практике, вряд ли должна иметь свой собственный testbench. Так как она тривиальна, мы можем использовать ее для иллюстрации некоторых основных принципов проверки без необходимости вникать в более сложную схему.

Рисунок 1-3 показывает условное обозначение логического элемента умножения с двумя входами. Логический элемент имеет два входа, А и В, и один выход Y. Устройство вычисляет логическое умножение А и В и помещает результат в Y.

[[Файл:7.png]]

Следующая таблица истинности описывает функцию устройства.

[[Файл:8.png]]

Таблица истинности является исчерпывающей: она содержит все возможные входы А и В и поэтому, все возможные значения для выхода Y.
Наша задача состоит в том, чтобы доказать, что наша схема, логического И, работает правильно. Чтобы убедиться, что он действительно выполняет функцию логического умножения правильно, нам в первую очередь необходимо перечислим вопросы. Таблица истинности поможет нам создать множество вопросов, необходимых для проверки. Каждая строка таблицы содержит вход для А и В и ожидаемый выход для Y. Так как таблица является исчерпывающей, наш вопрос-генератор будет: Для каждой ли строки в таблице истинности, когда мы получаем значения А и B, определенные в этой строке, устройство вычисляет ожидаемый результат для Y? Для ответа на Are-we-done вопрос, мы определяем, проверили ли мы каждую строку в таблице истинности, и получил ли утвердительный ответ does-itwork вопрос для этой строки. Наш Are-we-done вопрос- это Работает на всех наборах?
Для автоматизации ответов как на does-itwork та и на Are-we-done вопросы, нам нужна следующая атрибутика:

• Модель, которая представляет DUT (в данном случае, логическое И)

• Концепция конструкции в форме, которую мы можем кодифицировать как эталонную модель

• Некоторое воздействие для проверки схемы

• Способ сравнить результат с концепцией конструкции

[[Файл:9.png]]

В то время как наш маленький testbench прост, он содержит ключевые элементы, которые можно найти в большинстве testbenches любого уровня сложности. Ключевыми элементами являются следующие:

• DUT

• Stimulus генератор, который генерирует последовательность сигналов для DUT

• Scoreboard, которое изображает эталонную модель

Табло следит за входами и выходом тестируемого устройства, выполняет же функции, что DUT за исключением более высокого уровня абстракции, и определяет, совпадает ли DUT и эталонная модель. Scoreboard помогает нам ответить на does-itwork вопросы.

=== DUT===

DUT- это наше логическое И с двумя входами. Мы реализуем логическое И, как модуль с двумя входами А и В, и одним выходом Y.

<big><source lang="verilog">44 module and2 (
45 output bit Y,
46 input A, B);
47
48 initial Y = A & B;
49
50 always @* Y = #1 A & B;
51 endmodule
</source></big>

Stimulus генератор в этом примере создает заданные сигналы. Каждое новое значение вычисляются в определенном порядке. Позже, мы будем смотреть на генератор случайных сигналов, которые, как следует из их названия, генерирует случайные значения.

<big><source lang="verilog">81 module stimulus(output bit A, B);
82
83 bit [1:0] stimulus_count = 0;
84
85 always
86 #10 {A,B} = stimulus_count++;
87
88 endmodule</source></big>

Цель Stimulus генератор - получение значений на вход DUT. Сигналы, двухбитная величина, содержащая значение для А и B. После того как он увеличивается при каждой последующей итерации, младший бит посылает на А, а старший бит на B.

=== Scoreboard===

Scoreboard несет ответственность за ответы на does-it-work вопросы. Оно следит за работой DUT и сообщает работает ли оно корректно. Обратите внимание на то, что структура Scoreboard поразительно похожа на структуру DUT. Это имеет смысл, когда вы считаете, что назначением Scoreboard является отслеживание активности DUT и определение, работает ли DUT как ожидалось.

<big><source lang="verilog">59 module scoreboard(input bit Y, A, B);
60
61 reg Y_sb, truth_table[2][2];
62
63 initial begin
64 truth_table[0][0] = 0;
65 truth_table[0][1] = 0;
66 truth_table[1][0] = 0;
67 truth_table[1][1] = 1;
68 end
69
70 always @(A or B) begin
71 Y_sb = truth_table[A][B];
72 #2 $display(“@%4t - %b%b : Y_sb=%b, Y=%b (%0s)”,
73 $time, A, B, Y_sb, Y,
74 ((Y_sb == Y) ? “Match” : “Mis-match”));
75 end
76 endmodule</source></big>

Scoreboard отображает пины всех входов. На Scoreboard не вызывает воздействия на схему. Оно пассивно наблюдает за входами и выходами тестируемого устройства.

Модуль верхнего уровня, как показано ниже, является полностью структурированным, он содержит экземпляр тестируемого устройства, Scoreboard и Stimulus генератор, с кодом, необходимым для их подключения.

<big><source lang="verilog">93 module top;
94 stimulus s(A, B);
95 and2 a(Y, A, B);
96 scoreboard sb(Y, A, B);
97
98 initial
99 #100 $finish(2);
100 endmodule</source></big>

Когда мы запускаем моделирования для нескольких итераций, вот что мы получаем:

[[Файл:14.png]]

Каждое сообщение состоит из двух частей. В первой части показаны применяемые сигналы. Вторая часть показывает результаты проверки Scoreboard, которое сравнивает соответствие DUT с необходимыми результатами. Мы используем двоеточие для разделения двух частей.

Этот простой testbench демонстрирует использование Stimulus генератор и Scoreboard, которое служит в качестве эталона. Несмотря на то, DUT – логическое И, все элементы полного testbench присутствуют.

== Второй Testbench==

В предыдущий пример показывает элементарные понятия проверки с использованием комбинационного дизайна. Комбинационные конструкций, по природе, не поддерживают никаких статических данных. В нашем втором примере мы рассмотрим чуть более сложную конструкцию, которая сохраняет данные о состояниях и использует тактовый сигнал для перехода между состояниями.

Проблема верификации, связанная с синхронными (последовательными) схемами, иная чем у комбинационных конструкций. Все, что вам нужно знать о комбинационной схеме доступно на ее входах. Эталонная модель для комбинационного устройства просто должна вычислять F (X), где X представляет входы устройства и F – это реализуемая функция. Выходы же на последовательном устройстве зависят от входных сигналов и его внутреннего состояния. Дальнейшее вычисление может изменить внутреннее состояние. Scoreboard должно отслеживать внутреннее состояние тестируемого устройства и сравнить выходные данные.

Комбинационное устройство может быть полностью проверено при подаче всех возможных комбинаций сигналов на входы. Для устройства N входами, мы должны применить в общей сложности 2n входных комбинаций. Число 2n может быть большим, но вычисление такого количества входов достаточно простое. Нам просто необходимо иметь N-разрядный счетчик и посылать каждое значение счетчика на входы устройства.
Для последовательного устройства, понятие "done" должно распространяться и на покрытие не только всевозможных сигналов на входах, но и на число всевозможных внутренних состояний. Для устройства с n входами и m внутренних состояний, вы должны покрыть (2n входов) * (2m внутренних состояний), 2n+m – число всевозможных комбинаций внутренних состояний и входов. Для устройства с 64 входами и одним 32-битный внутренним регистром, количество комбинаций 296 -очень большое число, не так ли!

Даже для очень большого числа комбинаций, проверка не была бы слишком трудной, если бы было возможно просто увеличивать счетчик для получения всех комбинаций, как мы делаем с комбинационными устройствами. К сожалению, это не представляется возможным. Внутреннее состояние напрямую не доступны извне устройства. Оно может быть изменено только путем манипулированием входов. И теперь проблема заключается в том, как добраться до всех состояний в устройстве только через входы. Это сложная проблема, которая требует глубокого понимания устройства, для генерации последовательности входов для получения всех состояний.

Поскольку трудно получить все состояния, становится очевидным вопрос, Можем ли мы упростить задачу путем сокращения числа состояний, которые мы должны получить, чтобы показать, что устройство работает правильно? Ответ: да. Теперь возникает другой вопрос, Как мы решим, какие состояния можно пропустить?

Эта тема является сложной. Тем не менее, мы можем дать интуитивный ответ на вопрос. Состояния, которые могут быть отмечены как недоступные, при использовании формальной проверки или других методов, не должны быть покрыты. Проектировщик должен рассмотреть вопрос об упрощении схемы для удаления недоступных состояний, так как они не представляют никакой ценности. Состояния, которые имеют низкую вероятность быть достигнутыми, также могут быть исключены из плана проверки. Определение порогового значения вероятности и вероятностей состояний такое же искусство, как наука. Она включает в себя понимание того, как устройство используется и какие входы необходимы (по сравнению с которые возможны).

Это также позволяет устранить состояния, которые являются функционально эквивалентными. Рассмотрим устройство пакет коммуникаций. В теории, каждое возможное значение полезной нагрузки пакета представляет собой различное состояние (или множества состояний), которое принимает схема, и оно должно быть покрыто во время проверки. Однако, это, вероятно, не будет преувеличением считать, что произвольное ненулевое значение, для всех намерений и целей, эквивалентно. Конечно, могут быть некоторые интересные случаи, которые должны быть проверены, как все нули, все единицы, конкретные значения, которые могли бы бросить алгоритмы коррекции ошибок, и так далее. Изменения данных становятся интереснее, когда они влияют на поток управления.

В общем, это более важно, чтобы охватить управляющие состояния, чем состояние данных. Простым способом уменьшить число состояний, необходимых для покрытия схемы является разделения данных и управления. Для конкретного пути контроля, данные могут быть произвольными. По некоторых данных, вы можете захотеть изменить путь управления. Например, в ALU вы можете разделить функции контроля записи данных и получения данных из регистров и установление арифметической операции для выполнения из результатов конкретные арифметических операций. Использование направленного управления, вы можете сделать данные случайные или рассмотреть данные в специфичных случаях, таких как деление на 0 или умножение на 1.

Для сложных последовательных конструкций, определения того, какие состояния должны быть покрыты(и какие не должны) и, как получить эти состояния с минимальными усилиями является проблемой.

=== 3-х разрядный счетчик===

Схема, приведенная на рисунке 1-5, представляет собой 3-разрядный счетчик с асинхронным сбросом. Каждый раз, когда тактовый сигнал высокий, счетчик увеличивается. Схема состоит из трех переключательных триггеров, каждый из которых поддерживает один бит счета(??). Триггеры связаны с некоторой комбинационной логикой для формирования счетчика . Каждый триггер переключается, когда на входе T сигнал высокой. При низком сигнале на Т , триггер сохраняет свое текущее состояние. Когда активный низкий сброса установлен в 0, триггер переходит в состояние 0.

[[Файл:15.png]]

Код для счетчика содержится в двух модулях. Одним из них является простой переключательный триггер, а другой подключает триггера с необходимой логикой для формирования счетчика. Первый пример показывает переключательный триггер.

<big><source lang="verilog">36 module toggle_ff (output bit q, input t, rst_n, clk);
37
38 always @ (posedge clk or negedge rst_n)
39 if (!rst_n) q <= ‘0;
40 else if (t) q <= ~q;
41
42 endmodule
</source></big>

Счетчик состоит из трех переключательных триггеров и логического элемента И.

<big><source lang="verilog">47 module counter (output [2:0] q, input rst_n, clk);
48
49 toggle_ff ff0 (q[0], 1’b1, rst_n, clk);
50 toggle_ff ff1 (q[1], q[0], rst_n, clk);
51 toggle_ff ff2 (q[2], t2, rst_n, clk);
52 and a1 (t2, q[0], q[1]);
53
54 endmodule</source></big>

Схема проста, но имеет характеристики, которые являются общими с реальными проектами и которые требуют внимания для надлежащей проверки дизайна. Основными характеристиками является то, что конструкция работает по тактовому сигналу, и что она сохраняет внутреннее состояние. Логический элемент И из предыдущего примера не сохраняет никаких состояний. Вся информация о том, что делает схема, находится на ее входах. В конструкциях с внутренними данными, что это не так.

Эта разница отражается на схеме нашего табло. Рисунок 1-6 показывает схему testbench для 3х разрядного счетчика.

[[Файл:18.png]]

Во многих отношениях, testbench для 3-разрядного счетчика очень похож на testbench для логического элемента И. Оба имеют Scoreboard, роль которого состоит в наблюдении, что делает схема, и определить, выполняется ли операция правильно. Оба имеют устройства для DUT. Тем не менее, мы выполняем операции по-разному для этих конструкций. Мы используем Stimulus генератор для логического элемента И, но мы используем контроллер для 3-х разрядного счетчика. 3-х разрядный счетчик автономное устройство. Пока он подключен к тактовому сигналу, он будет продолжать считать. Таким образом, нам не нужен Stimulus генератор, который мы использовали для логического И. Вместо этого, контроллер управляет работой тестируемого устройства и testbench. Контроллер обеспечивает начальный сброс, так что отсчет начинается с известного значения. Он также останавливает моделирование в соответствующее время.

<big><source lang="verilog">93 module control(output bit rst_n, input clk);
94
95 initial begin
96 rst_n <= 0;
97 @(posedge clk);
98 @(negedge clk);
99 rst_n <= 1;
100 repeat (10) @(posedge clk);
101 $finish;
102 end
103
104 endmodule</source></big>

Табло должны отслеживать внутреннее состояние DUT. Это делается с помощью переменной count. Как и DUT, когда reset активирован, счетчик устанавливается в 0. Каждый тактовый цикл count увеличивается на единицу, и новое значение сравнивается с count, поступающего с DUT.

<big><source lang="verilog">71 module scoreboard (input [2:0] q, input rst_n, clk );
72
73 int count;
74
75 always @(posedge clk or negedge rst_n) begin
76 if(!rst_n) count <= 0;
77 else begin
78 if (count == q)
79 $display(“time =%4t q = %3b count = %0d match!”,
80 $time, q, count);
81 else
82 $display(“time =%4t q = %3b count = %0d <-- no
match”,
83 $time, q, count);
84 count <= (count + 1) % 8;
85 end
86 end
87
88 endmodule</source></big>

Табло имеет модель счетчика высокого уровня. Он использует целую переменную и оператор сложения (+) , чтобы сформировать счетчик вместо триггеров и элемента И. Каждый раз, при изменении тактового импульса, он увеличивает свой счет, так же как и RTL счетчика. Он также проверяет, соответствует ли ее внутренний счетчик выходу счетчика DUT.

Для полноты, пример показывает тактовый генератор и модуль топ-уровня. Тактовый генератор просто инициализирует тактовый сигнал 0, а затем переключает его каждые 5 нс.

<big><source lang="verilog">
59 module clkgen(output bit clk);
60
61 initial begin
62 clk <= 0;
63 forever #5 clk = ~clk;
64 end
65
66 endmodule</source></big>

Модуля верхнего уровня является типичным для большинства testbenches. Он соединяет DUT и компоненты testbench.

<big><source lang="verilog">109 module top;
110
111 wire [2:0] q;
112
113 clkgen ckgn (clk);
114 counter cntr (q, rst_n, clk);
115 control ctrl (rst_n, clk);
116 scoreboard score (q, rst_n, clk);
117
118 endmodule</source>
</big>
Мы показали простой testbench, который содержит элементы, используемые в гораздо более сложных testbenches. Последовательные схемы, которые поддерживают внутреннее состояние, требуют табло, которое работает параллельно с DUT. Табло выполняет те же вычисления что и DUT, но на более высоком уровне абстракции. Табло также сравнивает свои вычисления с вычислениями, полученными от DUT.

== Многоуровневая организация Testbenches==

Так как схема представляет собой совокупность компонент проекта, testbench представляет собой совокупность компонент верификации. OVM определяет верификацию компонент, их структуру,интерфейс. В этом разделе описываются OVM компоненты.

OVM testbenches организованы в виде уровней. Самый нижний слой -устройство RTL с pin-level интерфейсом (с интерфейсом на уровне выводов). Выше находится уровень транзакторов (посредник), устройств, которые преобразуют из уровня транзакций в pin-level. Все компоненты, находящиеся на этом уровне, являются компонентами уровня транзакций. Диаграмма, приведенная ниже, иллюстрирует уровневую организацию тестовых программ. Блок слева — название уровня, блок справа — перечень типов компонентов, входящих в него. Вертикальные стрелки показывают, какие уровни взаимодействуют на прямую. Например, управляющий уровень взаимодействует с уровнями анализа, операций, транзакторов, но с DUT напрямую не может.

[[Файл:23.png]]

Вы также можете рассмотреть testbench как концентрическую организацию компонент. Внутреннему кольцу соответствует нижний уровень, а внешнему кольцу - верхний уровень. Для некоторых будет проще понять отношения между уровнями, используя диаграмму в виде списка связей.

[[Файл:24.png]]

=== Transactors(?????????????????????????)===

Роль посредников в testbench состоит в преобразование потока транзакций в pin-level activity или наоборот. Транзакторы характеризуются наличием, по крайней мере, одного pin-level интерфейса и хотя бы одного transaction-level интерфейса. Транзакторы могут принимать большое разнообразие форм, цветов и стилей. Мы сосредоточимся на мониторах, драйверах и передатчиках.

'''Монитор'''. Монитор, как следует из названия, следит за шиной данных. Он следит за выводами и преобразует их в поток транзакций. Мониторы пассивные - это означает, что они не влияют на операции в DUT.

'''Драйвер'''. Драйвер преобразует поток транзакций (или последовательность элементов) в pin-level activity.

'''Передатчик'''. Передатчик очень похож на драйвер, но он реагирует на активность на выходе, а не на входную активность.

===Операционные компоненты===

Операционные компоненты – это набор компонент,которые обеспечивают все необходимые операции в DUT. Операционные компоненты отвечают за генерацию трафика для DUT. Все эти компоненты относятся к уровню транзакций и имеют только интерфейс уровня транзакций.Существуют различные варианты формирования сигнала, которые варьируются в зависимости от верифицируемого устройства. Мы рассмотрим три основных вида операционных компонентов: stimulus generators, masters, и slaves.

'''Stimulus генераторы'''. Генератор сигналов создает поток транзакций для проверки DUT. Stimulus генераторы могут быть случайными, заданными или заданными случайно; они могут запускаться самостоятельно или контролируемо; и они могут быть независимыми или синхронизированными. Простейший stimulus генератор рандомизирует содержимое объекта запроса и посылает этот объект на драйвер. OVM также предоставляет модульные, динамические средства для построения сложных stimulus, называемыми последовательностями.

'''Главное устройство'''. Главное устройство - двунаправленная компонента, которая посылает запросы и принимает ответы. Главное устройство инициирует активность. Как и Stimulus генераторы, оно может передавать отдельные рандомизированные транзакции или последовательности заданных или случайно заданных транзакций. Главное устройство может использовать ответы для определения последующих действий. Главное устройство также может быть реализовано как последовательность.

'''Подчиненное устройство'''. Подчиненное устройство, как и главное устройство, является двунаправленной компонентой. Оно реагирует на запросы и возвращает ответы (в отличие от главного устройства, которое отправляют запросы, и принимает ответы).

[[Файл:25.png]]

=== Компоненты анализа===

Компоненты анализа получают информацию о том, что происходит в testbench, и используют эту информацию, чтобы сделать некоторые заключения о правильности и полноты теста. Два наиболее распространенных вида анализа - это scoreboards и coverage collectors.

'''Scoreboards'''. Табло используются для определения правильности DUT, чтобы ответить на does-it-work вопросы.Scoreboards перехватывает информацию, входящую и выходящую из DUT и определяют правильно ли DUT отвечает на данный stimulus.

'''Coverage Collector'''. Coverage Collector используются для подсчета. Они перехватывают поток транзакций, и считает транзакции или различные аспекты транзакций. Цель состоит в том, чтобы определить завершенность верификации, отвечая на are-we-done вопросы. Определенные параметры, которые coverage collectors считает, зависит от схемы и специфики тестов. Общие вещи, которые coverage collectors включают в себя: необработанные транзакции, транзакции, которые происходит в определенном сегменте адресного пространства, и протокол ошибок. Список неограничен.

Coverage Collector могут также выполнять вычисления как часть полноты верификации. Например, coverage collectors может содержать скользящее среднее и среднее квадратичное отклонение данных, которые отслеживаются. Или они могут хранить отношения ошибок к выполнимым операциям.

=== Контроллер===

Контроллеры формируют основной поток теста, и управляют работой. Как правило, контроллеры получают информацию от Scoreboard и coverage collectors, и отправляют информацию компонентам окружающей среды.
Например, контроллер может запустить Stimulus генератор, а затем ждать сигнала от coverage collectors, чтобы уведомить его, когда тест будет завершен. Контроллер, в свою очередь, останавливает Stimulus генератор. Более сложные вариации на эту тему возможны. В пример возможные конфигурации, контроллер инициализирует Stimulus генератор начальным набором ограничений и запускает его. При достижении определенного соотношения типов пакетов, coverage collectors сигнализирует контроллеру. Вместо того, чтобы остановить Stimulus генератор, контроллер может отправить ему новый набор ограничений.

== Два домена( Две области)==

Мы можем разделить множество компонент в testbench на отдельные области. Оперативная область - множество компонент, в том числе DUT, которые управляют DUT. Это Stimulus генератор, шина функциональной модели (BFM), и аналогичные компоненты, которые генерируют сигналы и возвращают ответы, которые управляют моделированием. DUT, ответчик, и драйвер операций, наряду с компонентами окружающей среды, которые непосредственно обращаются или отвечают драйверам и передатчикам ответа, включены в оперативную область. Остальные компоненты testbench –монитор транзакций, scoreboard, coverage collectors, и контроллера включены в область анализа. Это компоненты, которые собирают информацию из оперативной области.

Данные должны быть перемещены из оперативной области в область анализа таким образом, чтобы не мешать работе DUT и сохранить оптимальный выбор событий. Это достигается с помощью специального интерфейса связи называемого портом анализа. Порт анализа представляют собой особый вид порта транзакций, в котором издатель передает данные одному или нескольким получателям. Издатель оповещает всех получателей, когда новые данные готовы.

Одной из ключевых особенностей порта анализа является то, что он имеет единственную функцию, write(). Анализ FIFO(????), каналы, используемые для подключения к порту анализа для анализа компонентов, неограниченные. Это гарантирует, что издатель не блокирует, а передает свои данные в анализ FIFO в точно такой же дельта-цикл, в котором они были созданы.

[[Файл:26.png]]

Как правило, оперативная и область анализа связаны портами анализа и интерфейсами управления и конфигурации. Порты анализа кран подачи выпускают данные относящиеся к операциям DUT. Эти данные могут включать шину транзакций, коммуникационные пакеты и информацию о состоянии (успех или ошибка конкретных операций). Компоненты области анализа анализируют данные и принимают решения. Результатами этих решений могут быть сообщения оперативной области, используя интерфейсы управления и конфигурирования. Интерфейсы управления и конфигурирования могут быть использованы для запуска и остановки Stimulus генератор, изменения ограничений, изменения процента ошибок, или манипулирование другими параметрами, влияющих на работу testbench.

== Заключение==

В этой главе мы рассмотрели, как структурировать весь процесс проверки. Этот процесс основывается на двух фундаментальных вопросах, Does it work? и Are we done? Простые примеры показали, как построить testbench для аппаратного ответа на эти вопросы такими устройствами как генератор сигналов и табло. Далее будет показано, как применять на уровне транзакций методы моделирования для создания практических, масштабируемых, многоразовых компонент testbench, которые отвечают на эти вопросы и показывают, как подключить их testbenches.

OVM/OVM методология/Основы верификации

2013-03-05T13:25:22Z

Anastasiya: /* Scoreboard */

{{OVM TOC}}
__TOC__

= =

== Основы верификации==

Функционально проверить устройство означает, сравнить цель разработчика с полученным поведением на их эквивалентность. Мы считаем устройство проверенным, когда, к всеобщему удовлетворению, оно работает в соответствии с целью разработчика. Этот основной принцип часто теряется при использовании testbenches, среды контроля, отладки, моделирования , и все другие средства, применяемые в современных технологических проверках. Чтобы узнать, работает ли верно устройство, вы должны сравнить его с некоторыми известными эталоном, который представляет цель разработчика. Каждый testbench имеет своего рода эталонную модель и средство для сравнения функциональность устройство с эталоном.

Когда мы говорим "устройство", мы имеем в виду проверяемое устройство, часто называемое тестируемое устройство или DUT. Чтобы проверить, DUT, как правило, представлен форме подходящей для производства, которое может быть перенесено на кремний с помощью автоматизированных и ручных средств. Мы различаем DUT от эскиза на обратной стороне салфетки или окончательного нанесенный на кристалл, ни один из которых не может быть проверен. Эталонная модель отражает цели разработчика, то есть то, что устройство должно делать.Эталон может принимать различные формы, такие как документ, описывающий работу DUT, golden модель, которая содержит уникальный алгоритм, или assertions, которые представляют протокол.

[[Файл:1.png]]

Для автоматизации сравнения поведения и эталона, оба должны быть представлены в форме, которую можно выполнить на компьютере с помощью некоторых программ, что делает сравнение.

==== Два вопроса====

Проверка устройства включает в себя два вопроса:Does it work? (Работает ли это устройство?) и Are we done? (Сделали ли мы?). Это основные, и некоторые сказали бы, очевидные вопросы. Тем не менее они
мотивируют всю механику каждой проверочного потока. Первый вопрос - это Does it work? Этот вопрос исходит от основной идеи верификации. Он спрашивает, Соответствует ли устройство эталону? Второй вопрос - Are we done? Он спрашивает, довольны ли мы сравнительным анализом полученной схемы и эталона для определения работает ли устройство согласно цели, если нет, то почему. Мы используем эти ценные вопросы создания основы для разработки эффективных testbenches.

====Does it work?====

Does it work? Это не единственный вопрос, а категория вопросов, которые представляют природу DUT. Каждый проект будет иметь свой собственный набор Does-It-Work вопросов, чья роль заключается в определении правильного функционирования устройства. Функциональные вопросы определяют, ведет ли себя устройство должным образом в конкретных ситуациях. Мы получаем эти вопросы непосредственно из цели разработки устройства, и мы используем их, чтобы отразить цель проекта в testbench.

Рассмотрим простой маршрутизатор пакетов в качестве примера. Это устройство маршрутизации пакетов от входа к одному из четырех портов вывода. Пакеты содержат адреса портов назначения и имеют различные длины полезной нагрузки. Каждый пакет имеет заголовок, трейлер, и два байта для циклического избыточного кода (CRC). Does-It-Work вопросы в этом случае должны быть следующие:

*пакет, поступающий на вход порта, адресованный на имя выходного порта 3, прибыл на порт 3?
*пакет длиной 16 пришел без изменений?
*CRC байты правильны, если полезная нагрузка [0f 73 a8 c2 3e 57 11 0a 88 FF 00 00 33 2b 4c 89]?

Это простой пример полного набора вопросов. Для устройства даже такого простого как этот гипотетическое маршрутизатор, набор Does-It-Work вопросов может быть длинным. Чтобы построить план проверки и testbench, который поддерживает план, вы должны сначала перечислить все вопросы или показать как получит полный набор вопросов, а затем выберите те, которые являются интересными.

Продолжая пример маршрутизатора пакетов,для того чтобы перечислить все Does-It-Work вопросы, вы можете создать таблицу:

[[Файл:2.png]]

Приведенная выше таблица содержит два вида вопросов, те, на которые мы можем ответить сразу и те, которые мы можно разбить на более мелкие вопросы. Вопрос 1 из ряда вопросов, которые можно представить в виде:

[[Файл:3.png]]
[[Файл:4.png]]

Обратите внимание, что мы формулируем все вопросы, так что на них можно ответить да или нет. В конце концов, схема работает либо нет – она либо готова для синтеза, размещения и трассировке, либо нет. Если вы можете ответить на все вопросы утвердительно, тогда проект готов для следующего производственного шага.
При разработке набора does-it-work вопросов, не забудьте сформулировать их таким образом, чтобы на них можно было ответить да или нет. Ответ да положителен, то есть, ответить да означает, что устройство работает правильно. Это будет сделать легче, чем пытаться отслеживать на какие вопросы нужно ответить да, и на какие следует ответить нет. Такой вопрос как Передает ли маршрутизатор ошибочные пакеты? требует ответа нет, чтобы считаться успешным. Лучшей формулировкой вопроса будет: Отклоняет ли маршрутизатор ошибочные пакеты? Вы должны сделать вопросы наиболее конкретными, даже если лучшее звучание будет: Когда ошибочный пакет попадает на входной порт, маршрутизатор обнаруживает его, подает сигнал ошибки и отклоняет этот пакет? Имейте в виду, что более конкретные вопросы более подробно описывают устройство. Ваш testbench должен дать ответ да или нет.
Тщательно сформулированный да или нет вопрос содержит свои собственные критерии успеха. Он сообщает, что получает ответа да. Такой вопрос как, Средняя задержка менее 27 тактов? содержит метрику, 27 тактов, и форму сравнения, меньше. Если вопрос (неправильно) сформулирован, например, Какова средняя задержка прохождения пакетов через маршрутизатор? мы не будем знать, что считается приемлемым. Чтобы ответить на ваш вопрос, вы в первую очередь должны быть в состоянии определить среднее время задержки. Только при правильной постановке вопроса мы знаем, как сделать сравнение, чтобы определить, является ли результат правильным. Метрика сама по себе не говорит нам о том, функционирует ли схема как задумано. Когда мы сравниваем измеренное значение со значением в спецификации, 27 тактов в этом примере, мы можем определить, работает ли схема.
Как это часто бывает, это не практично перечислять каждый does-it-work вопрос. Чтобы убедиться, что каждое слово в памяти 1 Мб можно записать и читать, непрактично и не необходимо записать один миллион вопросов. Вместо этого, вопрос-генератор, вопрос, который генерирует многие другие, занимает место миллиона отдельных вопросов. Может каждый миллион слов в памяти быть успешно записан и считан? -является вопросом-генератором.
Другие вопросы могут сами по себе представлять классы вопросов. Вопрос 3, Является ли вычисление CRC корректным для каждого пакета? является примером такого вопроса. Тестирование CRC вычисления требует ряда тщательно продуманных тестов, для определения является ли вычисления CRC корректным во всех случаях.

==== Are We Done?====

Для определения ответа на вопрос Are we done?, мы должны знать, что мы ответили на достаточное количество does-it-work вопросов, чтобы утверждать, что у нас есть проверенная схема. Мы начинаем эту задачу путем разделения на приоритеты всех does-it-work вопросов по двум направлениям:

[[Файл:5.png]]

Искусство создания testbench требует, чтобы на начальном этапе, мы определили множество вопросов и отсортировали их в соответствии с ценностью возвращаемой информации с точки зрения проверки схемы. Следующий шаг заключается в создании механизма, который будет отвечать на вопросы и определять на какие из них были даны ответы (и на какие нет).

Are-we-done вопросы также называется вопросами функционального покрытия, вопросы, которые устанавливают все ли состояния охватывают тесты с точки зрения функций схемы. Как и does-it-work вопросы, мы можем также разбить вопросы функционального охвата на более подробные вопросы. И как вопросы функциональной корректности, вопросы функционального охвата должны также иметь ответы да или нет. Приведенный ниже список включает в себя примеры вопросы функционального охвата:

• Выполняется ли каждая команда процессора, по крайней мере, один раз?

• Проходит, по крайней мере, один пакет от каждого входного порта до каждого выходного порта?

• Можно ли обратиться к памяти с набором адресов, которые содержат каждый бит адреса как 1 и затем каждый бит адреса 0, не включая 0xffffffff и 0x00000000?(?????????)

Другим мнением об этих вопросах является то, о чем они спрашивают, Получен ли утвердительный ответ на необходимый does-it-work вопрос? Когда мы думаем о функциональном охвате с этой точки зрения, то имеем виду покрытие множества does-it-work вопросов. Кроме того, вопросы охвата распознают метрику и порог для сравнения. Покрытие будет (то есть, охват вопрос можно ответить, да), когда метрика достигает порога.

Таким образом, искусство построения testbench начинается с плана тестирования. План тестирования начинается с тщательно продуманным набором does-it-work и Are-we-done вопросов.

==== Двухпетлевый поток (???????????????)====

Процесс ответа на does-it-work и Are-we-done вопросы может быть описан простой схемой, как показано на рисунке 1-2. Все обусловлено функциональной спецификацией на проектирование. Из функциональной спецификации, вы можете получить саму схему и план верификации. План верификации запускает testbench.

Поток состоит из двух циклов, does-it-work цикла и Are-we-done цикл. Оба цикла начинаются с моделирования. Моделирование тестирует схему при помощи testbench и генерирует информацию, которую мы используем для ответа на вопросы. Сначала мы спрашиваем, Это работает? Если ответ нет, то необходимо отладить проект. Процесс отладки схемы может привести к изменениям в реализации схемы.
Как только схема работает, то пора ответить на вопрос, Are-we-done? Мы ответим на этот вопрос, собирая информацию охвата и сравнения его с порогом, указанным в тестовом плане. Если мы не достигнем порогов, то ответ нет, и мы должны изменить testbench для увеличения охвата. Тогда мы моделируем снова.

Изменение testbench или воздействия может вызвать другие скрытые ошибки в схеме. Последующие итерации по циклу могут заставить нас вернуться к does-it-work циклу снова, чтобы исправить новые ошибки, которые появятся. Как вы можете видеть, полный процесс проверки колеблется вперед и назад между does-it-work и Are-we-done циклами, пока мы не можем утвердительно ответить на все вопросы обоих категорий.

[[Файл:6.png]]

В идеальном мире, схема не имеет ошибок и с покрытием всегда полное, так что вам только надо пройти по каждому циклу один раз, чтобы получить ответы да на оба вопроса. В реальном мире, это может занять много итераций для достижения двух ответов да. Одна из целей хорошего потока проверки свести к минимуму количество итераций для выполнения верификации проекта в кратчайшие сроки с использованием наименьшего количества ресурсов.

== Первый Testbench==

Давайте начнем с проверки одного из самых фундаментальных цифровых электронных устройств, схемы логического И. Логическое И вычисляет логическое умножение входов. Функция этого устройства является тривиальной, а на практике, вряд ли должна иметь свой собственный testbench. Так как она тривиальна, мы можем использовать ее для иллюстрации некоторых основных принципов проверки без необходимости вникать в более сложную схему.

Рисунок 1-3 показывает условное обозначение логического элемента умножения с двумя входами. Логический элемент имеет два входа, А и В, и один выход Y. Устройство вычисляет логическое умножение А и В и помещает результат в Y.

[[Файл:7.png]]

Следующая таблица истинности описывает функцию устройства.

[[Файл:8.png]]

Таблица истинности является исчерпывающей: она содержит все возможные входы А и В и поэтому, все возможные значения для выхода Y.
Наша задача состоит в том, чтобы доказать, что наша схема, логического И, работает правильно. Чтобы убедиться, что он действительно выполняет функцию логического умножения правильно, нам в первую очередь необходимо перечислим вопросы. Таблица истинности поможет нам создать множество вопросов, необходимых для проверки. Каждая строка таблицы содержит вход для А и В и ожидаемый выход для Y. Так как таблица является исчерпывающей, наш вопрос-генератор будет: Для каждой ли строки в таблице истинности, когда мы получаем значения А и B, определенные в этой строке, устройство вычисляет ожидаемый результат для Y? Для ответа на Are-we-done вопрос, мы определяем, проверили ли мы каждую строку в таблице истинности, и получил ли утвердительный ответ does-itwork вопрос для этой строки. Наш Are-we-done вопрос- это Работает на всех наборах?
Для автоматизации ответов как на does-itwork та и на Are-we-done вопросы, нам нужна следующая атрибутика:

• Модель, которая представляет DUT (в данном случае, логическое И)

• Концепция конструкции в форме, которую мы можем кодифицировать как эталонную модель

• Некоторое воздействие для проверки схемы

• Способ сравнить результат с концепцией конструкции

[[Файл:9.png]]

В то время как наш маленький testbench прост, он содержит ключевые элементы, которые можно найти в большинстве testbenches любого уровня сложности. Ключевыми элементами являются следующие:

• DUT

• Stimulus генератор, который генерирует последовательность сигналов для DUT

• Scoreboard, которое изображает эталонную модель

Табло следит за входами и выходом тестируемого устройства, выполняет же функции, что DUT за исключением более высокого уровня абстракции, и определяет, совпадает ли DUT и эталонная модель. Scoreboard помогает нам ответить на does-itwork вопросы.

=== DUT===

DUT- это наше логическое И с двумя входами. Мы реализуем логическое И, как модуль с двумя входами А и В, и одним выходом Y.

<big><source lang="verilog">44 module and2 (
45 output bit Y,
46 input A, B);
47
48 initial Y = A & B;
49
50 always @* Y = #1 A & B;
51 endmodule
</source></big>

Stimulus генератор в этом примере создает заданные сигналы. Каждое новое значение вычисляются в определенном порядке. Позже, мы будем смотреть на генератор случайных сигналов, которые, как следует из их названия, генерирует случайные значения.

<big><source lang="verilog">81 module stimulus(output bit A, B);
82
83 bit [1:0] stimulus_count = 0;
84
85 always
86 #10 {A,B} = stimulus_count++;
87
88 endmodule</source></big>

Цель Stimulus генератор - получение значений на вход DUT. Сигналы, двухбитная величина, содержащая значение для А и B. После того как он увеличивается при каждой последующей итерации, младший бит посылает на А, а старший бит на B.

=== Scoreboard===

Scoreboard несет ответственность за ответы на does-it-work вопросы. Оно следит за работой DUT и сообщает работает ли оно корректно. Обратите внимание на то, что структура Scoreboard поразительно похожа на структуру DUT. Это имеет смысл, когда вы считаете, что назначением Scoreboard является отслеживание активности DUT и определение, работает ли DUT как ожидалось.

<big><source lang="verilog">59 module scoreboard(input bit Y, A, B);
60
61 reg Y_sb, truth_table[2][2];
62
63 initial begin
64 truth_table[0][0] = 0;
65 truth_table[0][1] = 0;
66 truth_table[1][0] = 0;
67 truth_table[1][1] = 1;
68 end
69
70 always @(A or B) begin
71 Y_sb = truth_table[A][B];
72 #2 $display(“@%4t - %b%b : Y_sb=%b, Y=%b (%0s)”,
73 $time, A, B, Y_sb, Y,
74 ((Y_sb == Y) ? “Match” : “Mis-match”));
75 end
76 endmodule</source></big>

Scoreboard отображает пины всех входов. На Scoreboard не вызывает воздействия на схему. Оно пассивно наблюдает за входами и выходами тестируемого устройства.

Модуль верхнего уровня, как показано ниже, является полностью структурированным, он содержит экземпляр тестируемого устройства, Scoreboard и Stimulus генератор, с кодом, необходимым для их подключения.

<big><source lang="verilog">93 module top;
94 stimulus s(A, B);
95 and2 a(Y, A, B);
96 scoreboard sb(Y, A, B);
97
98 initial
99 #100 $finish(2);
100 endmodule</source></big>

Когда мы запускаем моделирования для нескольких итераций, вот что мы получаем:

[[Файл:14.png]]

Каждое сообщение состоит из двух частей. В первой части показаны применяемые сигналы. Вторая часть показывает результаты проверки Scoreboard, которое сравнивает соответствие DUT с необходимыми результатами. Мы используем двоеточие для разделения двух частей.

Этот простой testbench демонстрирует использование Stimulus генератор и Scoreboard, которое служит в качестве эталона. Несмотря на то, DUT – логическое И, все элементы полного testbench присутствуют.

== Второй Testbench==

В предыдущий пример показывает элементарные понятия проверки с использованием комбинационного дизайна. Комбинационные конструкций, по природе, не поддерживают никаких статических данных. В нашем втором примере мы рассмотрим чуть более сложную конструкцию, которая сохраняет данные о состояниях и использует тактовый сигнал для перехода между состояниями.

Проблема верификации, связанная с синхронными (последовательными) схемами, иная чем у комбинационных конструкций. Все, что вам нужно знать о комбинационной схеме доступно на ее входах. Эталонная модель для комбинационного устройства просто должна вычислять F (X), где X представляет входы устройства и F – это реализуемая функция. Выходы же на последовательном устройстве зависят от входных сигналов и его внутреннего состояния. Дальнейшее вычисление может изменить внутреннее состояние. Scoreboard должно отслеживать внутреннее состояние тестируемого устройства и сравнить выходные данные.

Комбинационное устройство может быть полностью проверено при подаче всех возможных комбинаций сигналов на входы. Для устройства N входами, мы должны применить в общей сложности 2n входных комбинаций. Число 2n может быть большим, но вычисление такого количества входов достаточно простое. Нам просто необходимо иметь N-разрядный счетчик и посылать каждое значение счетчика на входы устройства.
Для последовательного устройства, понятие "done" должно распространяться и на покрытие не только всевозможных сигналов на входах, но и на число всевозможных внутренних состояний. Для устройства с n входами и m внутренних состояний, вы должны покрыть (2n входов) * (2m внутренних состояний), 2n+m – число всевозможных комбинаций внутренних состояний и входов. Для устройства с 64 входами и одним 32-битный внутренним регистром, количество комбинаций 296 -очень большое число, не так ли!

Даже для очень большого числа комбинаций, проверка не была бы слишком трудной, если бы было возможно просто увеличивать счетчик для получения всех комбинаций, как мы делаем с комбинационными устройствами. К сожалению, это не представляется возможным. Внутреннее состояние напрямую не доступны извне устройства. Оно может быть изменено только путем манипулированием входов. И теперь проблема заключается в том, как добраться до всех состояний в устройстве только через входы. Это сложная проблема, которая требует глубокого понимания устройства, для генерации последовательности входов для получения всех состояний.

Поскольку трудно получить все состояния, становится очевидным вопрос, Можем ли мы упростить задачу путем сокращения числа состояний, которые мы должны получить, чтобы показать, что устройство работает правильно? Ответ: да. Теперь возникает другой вопрос, Как мы решим, какие состояния можно пропустить?

Эта тема является сложной. Тем не менее, мы можем дать интуитивный ответ на вопрос. Состояния, которые могут быть отмечены как недоступные, при использовании формальной проверки или других методов, не должны быть покрыты. Проектировщик должен рассмотреть вопрос об упрощении схемы для удаления недоступных состояний, так как они не представляют никакой ценности. Состояния, которые имеют низкую вероятность быть достигнутыми, также могут быть исключены из плана проверки. Определение порогового значения вероятности и вероятностей состояний такое же искусство, как наука. Она включает в себя понимание того, как устройство используется и какие входы необходимы (по сравнению с которые возможны).

Это также позволяет устранить состояния, которые являются функционально эквивалентными. Рассмотрим устройство пакет коммуникаций. В теории, каждое возможное значение полезной нагрузки пакета представляет собой различное состояние (или множества состояний), которое принимает схема, и оно должно быть покрыто во время проверки. Однако, это, вероятно, не будет преувеличением считать, что произвольное ненулевое значение, для всех намерений и целей, эквивалентно. Конечно, могут быть некоторые интересные случаи, которые должны быть проверены, как все нули, все единицы, конкретные значения, которые могли бы бросить алгоритмы коррекции ошибок, и так далее. Изменения данных становятся интереснее, когда они влияют на поток управления.

В общем, это более важно, чтобы охватить управляющие состояния, чем состояние данных. Простым способом уменьшить число состояний, необходимых для покрытия схемы является разделения данных и управления. Для конкретного пути контроля, данные могут быть произвольными. По некоторых данных, вы можете захотеть изменить путь управления. Например, в ALU вы можете разделить функции контроля записи данных и получения данных из регистров и установление арифметической операции для выполнения из результатов конкретные арифметических операций. Использование направленного управления, вы можете сделать данные случайные или рассмотреть данные в специфичных случаях, таких как деление на 0 или умножение на 1.

Для сложных последовательных конструкций, определения того, какие состояния должны быть покрыты(и какие не должны) и, как получить эти состояния с минимальными усилиями является проблемой.

=== 3-х разрядный счетчик===

Схема, приведенная на рисунке 1-5, представляет собой 3-разрядный счетчик с асинхронным сбросом. Каждый раз, когда тактовый сигнал высокий, счетчик увеличивается. Схема состоит из трех переключательных триггеров, каждый из которых поддерживает один бит счета(??). Триггеры связаны с некоторой комбинационной логикой для формирования счетчика . Каждый триггер переключается, когда на входе T сигнал высокой. При низком сигнале на Т , триггер сохраняет свое текущее состояние. Когда активный низкий сброса установлен в 0, триггер переходит в состояние 0.

[[Файл:15.png]]

Код для счетчика содержится в двух модулях. Одним из них является простой переключательный триггер, а другой подключает триггера с необходимой логикой для формирования счетчика. Первый пример показывает переключательный триггер.

[[Файл:16.png]]

Счетчик состоит из трех переключательных триггеров и логического элемента И.

[[Файл:17.png]]

Схема проста, но имеет характеристики, которые являются общими с реальными проектами и которые требуют внимания для надлежащей проверки дизайна. Основными характеристиками является то, что конструкция работает по тактовому сигналу, и что она сохраняет внутреннее состояние. Логический элемент И из предыдущего примера не сохраняет никаких состояний. Вся информация о том, что делает схема, находится на ее входах. В конструкциях с внутренними данными, что это не так.

Эта разница отражается на схеме нашего табло. Рисунок 1-6 показывает схему testbench для 3х разрядного счетчика.

[[Файл:18.png]]

Во многих отношениях, testbench для 3-разрядного счетчика очень похож на testbench для логического элемента И. Оба имеют Scoreboard, роль которого состоит в наблюдении, что делает схема, и определить, выполняется ли операция правильно. Оба имеют устройства для DUT. Тем не менее, мы выполняем операции по-разному для этих конструкций. Мы используем Stimulus генератор для логического элемента И, но мы используем контроллер для 3-х разрядного счетчика. 3-х разрядный счетчик автономное устройство. Пока он подключен к тактовому сигналу, он будет продолжать считать. Таким образом, нам не нужен Stimulus генератор, который мы использовали для логического И. Вместо этого, контроллер управляет работой тестируемого устройства и testbench. Контроллер обеспечивает начальный сброс, так что отсчет начинается с известного значения. Он также останавливает моделирование в соответствующее время.

[[Файл:19.png]]

Табло должны отслеживать внутреннее состояние DUT. Это делается с помощью переменной count. Как и DUT, когда reset активирован, счетчик устанавливается в 0. Каждый тактовый цикл count увеличивается на единицу, и новое значение сравнивается с count, поступающего с DUT.

[[Файл:20.png]]

Табло имеет модель счетчика высокого уровня. Он использует целую переменную и оператор сложения (+) , чтобы сформировать счетчик вместо триггеров и элемента И. Каждый раз, при изменении тактового импульса, он увеличивает свой счет, так же как и RTL счетчика. Он также проверяет, соответствует ли ее внутренний счетчик выходу счетчика DUT.

Для полноты, пример показывает тактовый генератор и модуль топ-уровня. Тактовый генератор просто инициализирует тактовый сигнал 0, а затем переключает его каждые 5 нс.

[[Файл:21.png]]

Модуля верхнего уровня является типичным для большинства testbenches. Он соединяет DUT и компоненты testbench.

[[Файл:22.png]]

Мы показали простой testbench, который содержит элементы, используемые в гораздо более сложных testbenches. Последовательные схемы, которые поддерживают внутреннее состояние, требуют табло, которое работает параллельно с DUT. Табло выполняет те же вычисления что и DUT, но на более высоком уровне абстракции. Табло также сравнивает свои вычисления с вычислениями, полученными от DUT.

== Многоуровневая организация Testbenches==

Так как схема представляет собой совокупность компонент проекта, testbench представляет собой совокупность компонент верификации. OVM определяет верификацию компонент, их структуру,интерфейс. В этом разделе описываются OVM компоненты.

OVM testbenches организованы в виде уровней. Самый нижний слой -устройство RTL с pin-level интерфейсом (с интерфейсом на уровне выводов). Выше находится уровень транзакторов (посредник), устройств, которые преобразуют из уровня транзакций в pin-level. Все компоненты, находящиеся на этом уровне, являются компонентами уровня транзакций. Диаграмма, приведенная ниже, иллюстрирует уровневую организацию тестовых программ. Блок слева — название уровня, блок справа — перечень типов компонентов, входящих в него. Вертикальные стрелки показывают, какие уровни взаимодействуют на прямую. Например, управляющий уровень взаимодействует с уровнями анализа, операций, транзакторов, но с DUT напрямую не может.

[[Файл:23.png]]

Вы также можете рассмотреть testbench как концентрическую организацию компонент. Внутреннему кольцу соответствует нижний уровень, а внешнему кольцу - верхний уровень. Для некоторых будет проще понять отношения между уровнями, используя диаграмму в виде списка связей.

[[Файл:24.png]]

=== Transactors(?????????????????????????)===

Роль посредников в testbench состоит в преобразование потока транзакций в pin-level activity или наоборот. Транзакторы характеризуются наличием, по крайней мере, одного pin-level интерфейса и хотя бы одного transaction-level интерфейса. Транзакторы могут принимать большое разнообразие форм, цветов и стилей. Мы сосредоточимся на мониторах, драйверах и передатчиках.

'''Монитор'''. Монитор, как следует из названия, следит за шиной данных. Он следит за выводами и преобразует их в поток транзакций. Мониторы пассивные - это означает, что они не влияют на операции в DUT.

'''Драйвер'''. Драйвер преобразует поток транзакций (или последовательность элементов) в pin-level activity.

'''Передатчик'''. Передатчик очень похож на драйвер, но он реагирует на активность на выходе, а не на входную активность.

===Операционные компоненты===

Операционные компоненты – это набор компонент,которые обеспечивают все необходимые операции в DUT. Операционные компоненты отвечают за генерацию трафика для DUT. Все эти компоненты относятся к уровню транзакций и имеют только интерфейс уровня транзакций.Существуют различные варианты формирования сигнала, которые варьируются в зависимости от верифицируемого устройства. Мы рассмотрим три основных вида операционных компонентов: stimulus generators, masters, и slaves.

'''Stimulus генераторы'''. Генератор сигналов создает поток транзакций для проверки DUT. Stimulus генераторы могут быть случайными, заданными или заданными случайно; они могут запускаться самостоятельно или контролируемо; и они могут быть независимыми или синхронизированными. Простейший stimulus генератор рандомизирует содержимое объекта запроса и посылает этот объект на драйвер. OVM также предоставляет модульные, динамические средства для построения сложных stimulus, называемыми последовательностями.

'''Главное устройство'''. Главное устройство - двунаправленная компонента, которая посылает запросы и принимает ответы. Главное устройство инициирует активность. Как и Stimulus генераторы, оно может передавать отдельные рандомизированные транзакции или последовательности заданных или случайно заданных транзакций. Главное устройство может использовать ответы для определения последующих действий. Главное устройство также может быть реализовано как последовательность.

'''Подчиненное устройство'''. Подчиненное устройство, как и главное устройство, является двунаправленной компонентой. Оно реагирует на запросы и возвращает ответы (в отличие от главного устройства, которое отправляют запросы, и принимает ответы).

[[Файл:25.png]]

=== Компоненты анализа===

Компоненты анализа получают информацию о том, что происходит в testbench, и используют эту информацию, чтобы сделать некоторые заключения о правильности и полноты теста. Два наиболее распространенных вида анализа - это scoreboards и coverage collectors.

'''Scoreboards'''. Табло используются для определения правильности DUT, чтобы ответить на does-it-work вопросы.Scoreboards перехватывает информацию, входящую и выходящую из DUT и определяют правильно ли DUT отвечает на данный stimulus.

'''Coverage Collector'''. Coverage Collector используются для подсчета. Они перехватывают поток транзакций, и считает транзакции или различные аспекты транзакций. Цель состоит в том, чтобы определить завершенность верификации, отвечая на are-we-done вопросы. Определенные параметры, которые coverage collectors считает, зависит от схемы и специфики тестов. Общие вещи, которые coverage collectors включают в себя: необработанные транзакции, транзакции, которые происходит в определенном сегменте адресного пространства, и протокол ошибок. Список неограничен.

Coverage Collector могут также выполнять вычисления как часть полноты верификации. Например, coverage collectors может содержать скользящее среднее и среднее квадратичное отклонение данных, которые отслеживаются. Или они могут хранить отношения ошибок к выполнимым операциям.

=== Контроллер===

Контроллеры формируют основной поток теста, и управляют работой. Как правило, контроллеры получают информацию от Scoreboard и coverage collectors, и отправляют информацию компонентам окружающей среды.
Например, контроллер может запустить Stimulus генератор, а затем ждать сигнала от coverage collectors, чтобы уведомить его, когда тест будет завершен. Контроллер, в свою очередь, останавливает Stimulus генератор. Более сложные вариации на эту тему возможны. В пример возможные конфигурации, контроллер инициализирует Stimulus генератор начальным набором ограничений и запускает его. При достижении определенного соотношения типов пакетов, coverage collectors сигнализирует контроллеру. Вместо того, чтобы остановить Stimulus генератор, контроллер может отправить ему новый набор ограничений.

== Два домена( Две области)==

Мы можем разделить множество компонент в testbench на отдельные области. Оперативная область - множество компонент, в том числе DUT, которые управляют DUT. Это Stimulus генератор, шина функциональной модели (BFM), и аналогичные компоненты, которые генерируют сигналы и возвращают ответы, которые управляют моделированием. DUT, ответчик, и драйвер операций, наряду с компонентами окружающей среды, которые непосредственно обращаются или отвечают драйверам и передатчикам ответа, включены в оперативную область. Остальные компоненты testbench –монитор транзакций, scoreboard, coverage collectors, и контроллера включены в область анализа. Это компоненты, которые собирают информацию из оперативной области.

Данные должны быть перемещены из оперативной области в область анализа таким образом, чтобы не мешать работе DUT и сохранить оптимальный выбор событий. Это достигается с помощью специального интерфейса связи называемого портом анализа. Порт анализа представляют собой особый вид порта транзакций, в котором издатель передает данные одному или нескольким получателям. Издатель оповещает всех получателей, когда новые данные готовы.

Одной из ключевых особенностей порта анализа является то, что он имеет единственную функцию, write(). Анализ FIFO(????), каналы, используемые для подключения к порту анализа для анализа компонентов, неограниченные. Это гарантирует, что издатель не блокирует, а передает свои данные в анализ FIFO в точно такой же дельта-цикл, в котором они были созданы.

[[Файл:26.png]]

Как правило, оперативная и область анализа связаны портами анализа и интерфейсами управления и конфигурации. Порты анализа кран подачи выпускают данные относящиеся к операциям DUT. Эти данные могут включать шину транзакций, коммуникационные пакеты и информацию о состоянии (успех или ошибка конкретных операций). Компоненты области анализа анализируют данные и принимают решения. Результатами этих решений могут быть сообщения оперативной области, используя интерфейсы управления и конфигурирования. Интерфейсы управления и конфигурирования могут быть использованы для запуска и остановки Stimulus генератор, изменения ограничений, изменения процента ошибок, или манипулирование другими параметрами, влияющих на работу testbench.

== Заключение==

В этой главе мы рассмотрели, как структурировать весь процесс проверки. Этот процесс основывается на двух фундаментальных вопросах, Does it work? и Are we done? Простые примеры показали, как построить testbench для аппаратного ответа на эти вопросы такими устройствами как генератор сигналов и табло. Далее будет показано, как применять на уровне транзакций методы моделирования для создания практических, масштабируемых, многоразовых компонент testbench, которые отвечают на эти вопросы и показывают, как подключить их testbenches.

OVM/OVM методология/Основы верификации

2013-03-05T13:23:38Z

Anastasiya: /* DUT */

{{OVM TOC}}
__TOC__

= =

== Основы верификации==

Функционально проверить устройство означает, сравнить цель разработчика с полученным поведением на их эквивалентность. Мы считаем устройство проверенным, когда, к всеобщему удовлетворению, оно работает в соответствии с целью разработчика. Этот основной принцип часто теряется при использовании testbenches, среды контроля, отладки, моделирования , и все другие средства, применяемые в современных технологических проверках. Чтобы узнать, работает ли верно устройство, вы должны сравнить его с некоторыми известными эталоном, который представляет цель разработчика. Каждый testbench имеет своего рода эталонную модель и средство для сравнения функциональность устройство с эталоном.

Когда мы говорим "устройство", мы имеем в виду проверяемое устройство, часто называемое тестируемое устройство или DUT. Чтобы проверить, DUT, как правило, представлен форме подходящей для производства, которое может быть перенесено на кремний с помощью автоматизированных и ручных средств. Мы различаем DUT от эскиза на обратной стороне салфетки или окончательного нанесенный на кристалл, ни один из которых не может быть проверен. Эталонная модель отражает цели разработчика, то есть то, что устройство должно делать.Эталон может принимать различные формы, такие как документ, описывающий работу DUT, golden модель, которая содержит уникальный алгоритм, или assertions, которые представляют протокол.

[[Файл:1.png]]

Для автоматизации сравнения поведения и эталона, оба должны быть представлены в форме, которую можно выполнить на компьютере с помощью некоторых программ, что делает сравнение.

==== Два вопроса====

Проверка устройства включает в себя два вопроса:Does it work? (Работает ли это устройство?) и Are we done? (Сделали ли мы?). Это основные, и некоторые сказали бы, очевидные вопросы. Тем не менее они
мотивируют всю механику каждой проверочного потока. Первый вопрос - это Does it work? Этот вопрос исходит от основной идеи верификации. Он спрашивает, Соответствует ли устройство эталону? Второй вопрос - Are we done? Он спрашивает, довольны ли мы сравнительным анализом полученной схемы и эталона для определения работает ли устройство согласно цели, если нет, то почему. Мы используем эти ценные вопросы создания основы для разработки эффективных testbenches.

====Does it work?====

Does it work? Это не единственный вопрос, а категория вопросов, которые представляют природу DUT. Каждый проект будет иметь свой собственный набор Does-It-Work вопросов, чья роль заключается в определении правильного функционирования устройства. Функциональные вопросы определяют, ведет ли себя устройство должным образом в конкретных ситуациях. Мы получаем эти вопросы непосредственно из цели разработки устройства, и мы используем их, чтобы отразить цель проекта в testbench.

Рассмотрим простой маршрутизатор пакетов в качестве примера. Это устройство маршрутизации пакетов от входа к одному из четырех портов вывода. Пакеты содержат адреса портов назначения и имеют различные длины полезной нагрузки. Каждый пакет имеет заголовок, трейлер, и два байта для циклического избыточного кода (CRC). Does-It-Work вопросы в этом случае должны быть следующие:

*пакет, поступающий на вход порта, адресованный на имя выходного порта 3, прибыл на порт 3?
*пакет длиной 16 пришел без изменений?
*CRC байты правильны, если полезная нагрузка [0f 73 a8 c2 3e 57 11 0a 88 FF 00 00 33 2b 4c 89]?

Это простой пример полного набора вопросов. Для устройства даже такого простого как этот гипотетическое маршрутизатор, набор Does-It-Work вопросов может быть длинным. Чтобы построить план проверки и testbench, который поддерживает план, вы должны сначала перечислить все вопросы или показать как получит полный набор вопросов, а затем выберите те, которые являются интересными.

Продолжая пример маршрутизатора пакетов,для того чтобы перечислить все Does-It-Work вопросы, вы можете создать таблицу:

[[Файл:2.png]]

Приведенная выше таблица содержит два вида вопросов, те, на которые мы можем ответить сразу и те, которые мы можно разбить на более мелкие вопросы. Вопрос 1 из ряда вопросов, которые можно представить в виде:

[[Файл:3.png]]
[[Файл:4.png]]

Обратите внимание, что мы формулируем все вопросы, так что на них можно ответить да или нет. В конце концов, схема работает либо нет – она либо готова для синтеза, размещения и трассировке, либо нет. Если вы можете ответить на все вопросы утвердительно, тогда проект готов для следующего производственного шага.
При разработке набора does-it-work вопросов, не забудьте сформулировать их таким образом, чтобы на них можно было ответить да или нет. Ответ да положителен, то есть, ответить да означает, что устройство работает правильно. Это будет сделать легче, чем пытаться отслеживать на какие вопросы нужно ответить да, и на какие следует ответить нет. Такой вопрос как Передает ли маршрутизатор ошибочные пакеты? требует ответа нет, чтобы считаться успешным. Лучшей формулировкой вопроса будет: Отклоняет ли маршрутизатор ошибочные пакеты? Вы должны сделать вопросы наиболее конкретными, даже если лучшее звучание будет: Когда ошибочный пакет попадает на входной порт, маршрутизатор обнаруживает его, подает сигнал ошибки и отклоняет этот пакет? Имейте в виду, что более конкретные вопросы более подробно описывают устройство. Ваш testbench должен дать ответ да или нет.
Тщательно сформулированный да или нет вопрос содержит свои собственные критерии успеха. Он сообщает, что получает ответа да. Такой вопрос как, Средняя задержка менее 27 тактов? содержит метрику, 27 тактов, и форму сравнения, меньше. Если вопрос (неправильно) сформулирован, например, Какова средняя задержка прохождения пакетов через маршрутизатор? мы не будем знать, что считается приемлемым. Чтобы ответить на ваш вопрос, вы в первую очередь должны быть в состоянии определить среднее время задержки. Только при правильной постановке вопроса мы знаем, как сделать сравнение, чтобы определить, является ли результат правильным. Метрика сама по себе не говорит нам о том, функционирует ли схема как задумано. Когда мы сравниваем измеренное значение со значением в спецификации, 27 тактов в этом примере, мы можем определить, работает ли схема.
Как это часто бывает, это не практично перечислять каждый does-it-work вопрос. Чтобы убедиться, что каждое слово в памяти 1 Мб можно записать и читать, непрактично и не необходимо записать один миллион вопросов. Вместо этого, вопрос-генератор, вопрос, который генерирует многие другие, занимает место миллиона отдельных вопросов. Может каждый миллион слов в памяти быть успешно записан и считан? -является вопросом-генератором.
Другие вопросы могут сами по себе представлять классы вопросов. Вопрос 3, Является ли вычисление CRC корректным для каждого пакета? является примером такого вопроса. Тестирование CRC вычисления требует ряда тщательно продуманных тестов, для определения является ли вычисления CRC корректным во всех случаях.

==== Are We Done?====

Для определения ответа на вопрос Are we done?, мы должны знать, что мы ответили на достаточное количество does-it-work вопросов, чтобы утверждать, что у нас есть проверенная схема. Мы начинаем эту задачу путем разделения на приоритеты всех does-it-work вопросов по двум направлениям:

[[Файл:5.png]]

Искусство создания testbench требует, чтобы на начальном этапе, мы определили множество вопросов и отсортировали их в соответствии с ценностью возвращаемой информации с точки зрения проверки схемы. Следующий шаг заключается в создании механизма, который будет отвечать на вопросы и определять на какие из них были даны ответы (и на какие нет).

Are-we-done вопросы также называется вопросами функционального покрытия, вопросы, которые устанавливают все ли состояния охватывают тесты с точки зрения функций схемы. Как и does-it-work вопросы, мы можем также разбить вопросы функционального охвата на более подробные вопросы. И как вопросы функциональной корректности, вопросы функционального охвата должны также иметь ответы да или нет. Приведенный ниже список включает в себя примеры вопросы функционального охвата:

• Выполняется ли каждая команда процессора, по крайней мере, один раз?

• Проходит, по крайней мере, один пакет от каждого входного порта до каждого выходного порта?

• Можно ли обратиться к памяти с набором адресов, которые содержат каждый бит адреса как 1 и затем каждый бит адреса 0, не включая 0xffffffff и 0x00000000?(?????????)

Другим мнением об этих вопросах является то, о чем они спрашивают, Получен ли утвердительный ответ на необходимый does-it-work вопрос? Когда мы думаем о функциональном охвате с этой точки зрения, то имеем виду покрытие множества does-it-work вопросов. Кроме того, вопросы охвата распознают метрику и порог для сравнения. Покрытие будет (то есть, охват вопрос можно ответить, да), когда метрика достигает порога.

Таким образом, искусство построения testbench начинается с плана тестирования. План тестирования начинается с тщательно продуманным набором does-it-work и Are-we-done вопросов.

==== Двухпетлевый поток (???????????????)====

Процесс ответа на does-it-work и Are-we-done вопросы может быть описан простой схемой, как показано на рисунке 1-2. Все обусловлено функциональной спецификацией на проектирование. Из функциональной спецификации, вы можете получить саму схему и план верификации. План верификации запускает testbench.

Поток состоит из двух циклов, does-it-work цикла и Are-we-done цикл. Оба цикла начинаются с моделирования. Моделирование тестирует схему при помощи testbench и генерирует информацию, которую мы используем для ответа на вопросы. Сначала мы спрашиваем, Это работает? Если ответ нет, то необходимо отладить проект. Процесс отладки схемы может привести к изменениям в реализации схемы.
Как только схема работает, то пора ответить на вопрос, Are-we-done? Мы ответим на этот вопрос, собирая информацию охвата и сравнения его с порогом, указанным в тестовом плане. Если мы не достигнем порогов, то ответ нет, и мы должны изменить testbench для увеличения охвата. Тогда мы моделируем снова.

Изменение testbench или воздействия может вызвать другие скрытые ошибки в схеме. Последующие итерации по циклу могут заставить нас вернуться к does-it-work циклу снова, чтобы исправить новые ошибки, которые появятся. Как вы можете видеть, полный процесс проверки колеблется вперед и назад между does-it-work и Are-we-done циклами, пока мы не можем утвердительно ответить на все вопросы обоих категорий.

[[Файл:6.png]]

В идеальном мире, схема не имеет ошибок и с покрытием всегда полное, так что вам только надо пройти по каждому циклу один раз, чтобы получить ответы да на оба вопроса. В реальном мире, это может занять много итераций для достижения двух ответов да. Одна из целей хорошего потока проверки свести к минимуму количество итераций для выполнения верификации проекта в кратчайшие сроки с использованием наименьшего количества ресурсов.

== Первый Testbench==

Давайте начнем с проверки одного из самых фундаментальных цифровых электронных устройств, схемы логического И. Логическое И вычисляет логическое умножение входов. Функция этого устройства является тривиальной, а на практике, вряд ли должна иметь свой собственный testbench. Так как она тривиальна, мы можем использовать ее для иллюстрации некоторых основных принципов проверки без необходимости вникать в более сложную схему.

Рисунок 1-3 показывает условное обозначение логического элемента умножения с двумя входами. Логический элемент имеет два входа, А и В, и один выход Y. Устройство вычисляет логическое умножение А и В и помещает результат в Y.

[[Файл:7.png]]

Следующая таблица истинности описывает функцию устройства.

[[Файл:8.png]]

Таблица истинности является исчерпывающей: она содержит все возможные входы А и В и поэтому, все возможные значения для выхода Y.
Наша задача состоит в том, чтобы доказать, что наша схема, логического И, работает правильно. Чтобы убедиться, что он действительно выполняет функцию логического умножения правильно, нам в первую очередь необходимо перечислим вопросы. Таблица истинности поможет нам создать множество вопросов, необходимых для проверки. Каждая строка таблицы содержит вход для А и В и ожидаемый выход для Y. Так как таблица является исчерпывающей, наш вопрос-генератор будет: Для каждой ли строки в таблице истинности, когда мы получаем значения А и B, определенные в этой строке, устройство вычисляет ожидаемый результат для Y? Для ответа на Are-we-done вопрос, мы определяем, проверили ли мы каждую строку в таблице истинности, и получил ли утвердительный ответ does-itwork вопрос для этой строки. Наш Are-we-done вопрос- это Работает на всех наборах?
Для автоматизации ответов как на does-itwork та и на Are-we-done вопросы, нам нужна следующая атрибутика:

• Модель, которая представляет DUT (в данном случае, логическое И)

• Концепция конструкции в форме, которую мы можем кодифицировать как эталонную модель

• Некоторое воздействие для проверки схемы

• Способ сравнить результат с концепцией конструкции

[[Файл:9.png]]

В то время как наш маленький testbench прост, он содержит ключевые элементы, которые можно найти в большинстве testbenches любого уровня сложности. Ключевыми элементами являются следующие:

• DUT

• Stimulus генератор, который генерирует последовательность сигналов для DUT

• Scoreboard, которое изображает эталонную модель

Табло следит за входами и выходом тестируемого устройства, выполняет же функции, что DUT за исключением более высокого уровня абстракции, и определяет, совпадает ли DUT и эталонная модель. Scoreboard помогает нам ответить на does-itwork вопросы.

=== DUT===

DUT- это наше логическое И с двумя входами. Мы реализуем логическое И, как модуль с двумя входами А и В, и одним выходом Y.

<big><source lang="verilog">44 module and2 (
45 output bit Y,
46 input A, B);
47
48 initial Y = A & B;
49
50 always @* Y = #1 A & B;
51 endmodule
</source></big>

Stimulus генератор в этом примере создает заданные сигналы. Каждое новое значение вычисляются в определенном порядке. Позже, мы будем смотреть на генератор случайных сигналов, которые, как следует из их названия, генерирует случайные значения.

<big><source lang="verilog">81 module stimulus(output bit A, B);
82
83 bit [1:0] stimulus_count = 0;
84
85 always
86 #10 {A,B} = stimulus_count++;
87
88 endmodule</source></big>

Цель Stimulus генератор - получение значений на вход DUT. Сигналы, двухбитная величина, содержащая значение для А и B. После того как он увеличивается при каждой последующей итерации, младший бит посылает на А, а старший бит на B.

=== Scoreboard===

Scoreboard несет ответственность за ответы на does-it-work вопросы. Оно следит за работой DUT и сообщает работает ли оно корректно. Обратите внимание на то, что структура Scoreboard поразительно похожа на структуру DUT. Это имеет смысл, когда вы считаете, что назначением Scoreboard является отслеживание активности DUT и определение, работает ли DUT как ожидалось.

[[Файл:12.png]]

Scoreboard отображает пины всех входов. На Scoreboard не вызывает воздействия на схему. Оно пассивно наблюдает за входами и выходами тестируемого устройства.

Модуль верхнего уровня, как показано ниже, является полностью структурированным, он содержит экземпляр тестируемого устройства, Scoreboard и Stimulus генератор, с кодом, необходимым для их подключения.

[[Файл:13.png]]

Когда мы запускаем моделирования для нескольких итераций, вот что мы получаем:

[[Файл:14.png]]

Каждое сообщение состоит из двух частей. В первой части показаны применяемые сигналы. Вторая часть показывает результаты проверки Scoreboard, которое сравнивает соответствие DUT с необходимыми результатами. Мы используем двоеточие для разделения двух частей.

Этот простой testbench демонстрирует использование Stimulus генератор и Scoreboard, которое служит в качестве эталона. Несмотря на то, DUT – логическое И, все элементы полного testbench присутствуют.

== Второй Testbench==

В предыдущий пример показывает элементарные понятия проверки с использованием комбинационного дизайна. Комбинационные конструкций, по природе, не поддерживают никаких статических данных. В нашем втором примере мы рассмотрим чуть более сложную конструкцию, которая сохраняет данные о состояниях и использует тактовый сигнал для перехода между состояниями.

Проблема верификации, связанная с синхронными (последовательными) схемами, иная чем у комбинационных конструкций. Все, что вам нужно знать о комбинационной схеме доступно на ее входах. Эталонная модель для комбинационного устройства просто должна вычислять F (X), где X представляет входы устройства и F – это реализуемая функция. Выходы же на последовательном устройстве зависят от входных сигналов и его внутреннего состояния. Дальнейшее вычисление может изменить внутреннее состояние. Scoreboard должно отслеживать внутреннее состояние тестируемого устройства и сравнить выходные данные.

Комбинационное устройство может быть полностью проверено при подаче всех возможных комбинаций сигналов на входы. Для устройства N входами, мы должны применить в общей сложности 2n входных комбинаций. Число 2n может быть большим, но вычисление такого количества входов достаточно простое. Нам просто необходимо иметь N-разрядный счетчик и посылать каждое значение счетчика на входы устройства.
Для последовательного устройства, понятие "done" должно распространяться и на покрытие не только всевозможных сигналов на входах, но и на число всевозможных внутренних состояний. Для устройства с n входами и m внутренних состояний, вы должны покрыть (2n входов) * (2m внутренних состояний), 2n+m – число всевозможных комбинаций внутренних состояний и входов. Для устройства с 64 входами и одним 32-битный внутренним регистром, количество комбинаций 296 -очень большое число, не так ли!

Даже для очень большого числа комбинаций, проверка не была бы слишком трудной, если бы было возможно просто увеличивать счетчик для получения всех комбинаций, как мы делаем с комбинационными устройствами. К сожалению, это не представляется возможным. Внутреннее состояние напрямую не доступны извне устройства. Оно может быть изменено только путем манипулированием входов. И теперь проблема заключается в том, как добраться до всех состояний в устройстве только через входы. Это сложная проблема, которая требует глубокого понимания устройства, для генерации последовательности входов для получения всех состояний.

Поскольку трудно получить все состояния, становится очевидным вопрос, Можем ли мы упростить задачу путем сокращения числа состояний, которые мы должны получить, чтобы показать, что устройство работает правильно? Ответ: да. Теперь возникает другой вопрос, Как мы решим, какие состояния можно пропустить?

Эта тема является сложной. Тем не менее, мы можем дать интуитивный ответ на вопрос. Состояния, которые могут быть отмечены как недоступные, при использовании формальной проверки или других методов, не должны быть покрыты. Проектировщик должен рассмотреть вопрос об упрощении схемы для удаления недоступных состояний, так как они не представляют никакой ценности. Состояния, которые имеют низкую вероятность быть достигнутыми, также могут быть исключены из плана проверки. Определение порогового значения вероятности и вероятностей состояний такое же искусство, как наука. Она включает в себя понимание того, как устройство используется и какие входы необходимы (по сравнению с которые возможны).

Это также позволяет устранить состояния, которые являются функционально эквивалентными. Рассмотрим устройство пакет коммуникаций. В теории, каждое возможное значение полезной нагрузки пакета представляет собой различное состояние (или множества состояний), которое принимает схема, и оно должно быть покрыто во время проверки. Однако, это, вероятно, не будет преувеличением считать, что произвольное ненулевое значение, для всех намерений и целей, эквивалентно. Конечно, могут быть некоторые интересные случаи, которые должны быть проверены, как все нули, все единицы, конкретные значения, которые могли бы бросить алгоритмы коррекции ошибок, и так далее. Изменения данных становятся интереснее, когда они влияют на поток управления.

В общем, это более важно, чтобы охватить управляющие состояния, чем состояние данных. Простым способом уменьшить число состояний, необходимых для покрытия схемы является разделения данных и управления. Для конкретного пути контроля, данные могут быть произвольными. По некоторых данных, вы можете захотеть изменить путь управления. Например, в ALU вы можете разделить функции контроля записи данных и получения данных из регистров и установление арифметической операции для выполнения из результатов конкретные арифметических операций. Использование направленного управления, вы можете сделать данные случайные или рассмотреть данные в специфичных случаях, таких как деление на 0 или умножение на 1.

Для сложных последовательных конструкций, определения того, какие состояния должны быть покрыты(и какие не должны) и, как получить эти состояния с минимальными усилиями является проблемой.

=== 3-х разрядный счетчик===

Схема, приведенная на рисунке 1-5, представляет собой 3-разрядный счетчик с асинхронным сбросом. Каждый раз, когда тактовый сигнал высокий, счетчик увеличивается. Схема состоит из трех переключательных триггеров, каждый из которых поддерживает один бит счета(??). Триггеры связаны с некоторой комбинационной логикой для формирования счетчика . Каждый триггер переключается, когда на входе T сигнал высокой. При низком сигнале на Т , триггер сохраняет свое текущее состояние. Когда активный низкий сброса установлен в 0, триггер переходит в состояние 0.

[[Файл:15.png]]

Код для счетчика содержится в двух модулях. Одним из них является простой переключательный триггер, а другой подключает триггера с необходимой логикой для формирования счетчика. Первый пример показывает переключательный триггер.

[[Файл:16.png]]

Счетчик состоит из трех переключательных триггеров и логического элемента И.

[[Файл:17.png]]

Схема проста, но имеет характеристики, которые являются общими с реальными проектами и которые требуют внимания для надлежащей проверки дизайна. Основными характеристиками является то, что конструкция работает по тактовому сигналу, и что она сохраняет внутреннее состояние. Логический элемент И из предыдущего примера не сохраняет никаких состояний. Вся информация о том, что делает схема, находится на ее входах. В конструкциях с внутренними данными, что это не так.

Эта разница отражается на схеме нашего табло. Рисунок 1-6 показывает схему testbench для 3х разрядного счетчика.

[[Файл:18.png]]

Во многих отношениях, testbench для 3-разрядного счетчика очень похож на testbench для логического элемента И. Оба имеют Scoreboard, роль которого состоит в наблюдении, что делает схема, и определить, выполняется ли операция правильно. Оба имеют устройства для DUT. Тем не менее, мы выполняем операции по-разному для этих конструкций. Мы используем Stimulus генератор для логического элемента И, но мы используем контроллер для 3-х разрядного счетчика. 3-х разрядный счетчик автономное устройство. Пока он подключен к тактовому сигналу, он будет продолжать считать. Таким образом, нам не нужен Stimulus генератор, который мы использовали для логического И. Вместо этого, контроллер управляет работой тестируемого устройства и testbench. Контроллер обеспечивает начальный сброс, так что отсчет начинается с известного значения. Он также останавливает моделирование в соответствующее время.

[[Файл:19.png]]

Табло должны отслеживать внутреннее состояние DUT. Это делается с помощью переменной count. Как и DUT, когда reset активирован, счетчик устанавливается в 0. Каждый тактовый цикл count увеличивается на единицу, и новое значение сравнивается с count, поступающего с DUT.

[[Файл:20.png]]

Табло имеет модель счетчика высокого уровня. Он использует целую переменную и оператор сложения (+) , чтобы сформировать счетчик вместо триггеров и элемента И. Каждый раз, при изменении тактового импульса, он увеличивает свой счет, так же как и RTL счетчика. Он также проверяет, соответствует ли ее внутренний счетчик выходу счетчика DUT.

Для полноты, пример показывает тактовый генератор и модуль топ-уровня. Тактовый генератор просто инициализирует тактовый сигнал 0, а затем переключает его каждые 5 нс.

[[Файл:21.png]]

Модуля верхнего уровня является типичным для большинства testbenches. Он соединяет DUT и компоненты testbench.

[[Файл:22.png]]

Мы показали простой testbench, который содержит элементы, используемые в гораздо более сложных testbenches. Последовательные схемы, которые поддерживают внутреннее состояние, требуют табло, которое работает параллельно с DUT. Табло выполняет те же вычисления что и DUT, но на более высоком уровне абстракции. Табло также сравнивает свои вычисления с вычислениями, полученными от DUT.

== Многоуровневая организация Testbenches==

Так как схема представляет собой совокупность компонент проекта, testbench представляет собой совокупность компонент верификации. OVM определяет верификацию компонент, их структуру,интерфейс. В этом разделе описываются OVM компоненты.

OVM testbenches организованы в виде уровней. Самый нижний слой -устройство RTL с pin-level интерфейсом (с интерфейсом на уровне выводов). Выше находится уровень транзакторов (посредник), устройств, которые преобразуют из уровня транзакций в pin-level. Все компоненты, находящиеся на этом уровне, являются компонентами уровня транзакций. Диаграмма, приведенная ниже, иллюстрирует уровневую организацию тестовых программ. Блок слева — название уровня, блок справа — перечень типов компонентов, входящих в него. Вертикальные стрелки показывают, какие уровни взаимодействуют на прямую. Например, управляющий уровень взаимодействует с уровнями анализа, операций, транзакторов, но с DUT напрямую не может.

[[Файл:23.png]]

Вы также можете рассмотреть testbench как концентрическую организацию компонент. Внутреннему кольцу соответствует нижний уровень, а внешнему кольцу - верхний уровень. Для некоторых будет проще понять отношения между уровнями, используя диаграмму в виде списка связей.

[[Файл:24.png]]

=== Transactors(?????????????????????????)===

Роль посредников в testbench состоит в преобразование потока транзакций в pin-level activity или наоборот. Транзакторы характеризуются наличием, по крайней мере, одного pin-level интерфейса и хотя бы одного transaction-level интерфейса. Транзакторы могут принимать большое разнообразие форм, цветов и стилей. Мы сосредоточимся на мониторах, драйверах и передатчиках.

'''Монитор'''. Монитор, как следует из названия, следит за шиной данных. Он следит за выводами и преобразует их в поток транзакций. Мониторы пассивные - это означает, что они не влияют на операции в DUT.

'''Драйвер'''. Драйвер преобразует поток транзакций (или последовательность элементов) в pin-level activity.

'''Передатчик'''. Передатчик очень похож на драйвер, но он реагирует на активность на выходе, а не на входную активность.

===Операционные компоненты===

Операционные компоненты – это набор компонент,которые обеспечивают все необходимые операции в DUT. Операционные компоненты отвечают за генерацию трафика для DUT. Все эти компоненты относятся к уровню транзакций и имеют только интерфейс уровня транзакций.Существуют различные варианты формирования сигнала, которые варьируются в зависимости от верифицируемого устройства. Мы рассмотрим три основных вида операционных компонентов: stimulus generators, masters, и slaves.

'''Stimulus генераторы'''. Генератор сигналов создает поток транзакций для проверки DUT. Stimulus генераторы могут быть случайными, заданными или заданными случайно; они могут запускаться самостоятельно или контролируемо; и они могут быть независимыми или синхронизированными. Простейший stimulus генератор рандомизирует содержимое объекта запроса и посылает этот объект на драйвер. OVM также предоставляет модульные, динамические средства для построения сложных stimulus, называемыми последовательностями.

'''Главное устройство'''. Главное устройство - двунаправленная компонента, которая посылает запросы и принимает ответы. Главное устройство инициирует активность. Как и Stimulus генераторы, оно может передавать отдельные рандомизированные транзакции или последовательности заданных или случайно заданных транзакций. Главное устройство может использовать ответы для определения последующих действий. Главное устройство также может быть реализовано как последовательность.

'''Подчиненное устройство'''. Подчиненное устройство, как и главное устройство, является двунаправленной компонентой. Оно реагирует на запросы и возвращает ответы (в отличие от главного устройства, которое отправляют запросы, и принимает ответы).

[[Файл:25.png]]

=== Компоненты анализа===

Компоненты анализа получают информацию о том, что происходит в testbench, и используют эту информацию, чтобы сделать некоторые заключения о правильности и полноты теста. Два наиболее распространенных вида анализа - это scoreboards и coverage collectors.

'''Scoreboards'''. Табло используются для определения правильности DUT, чтобы ответить на does-it-work вопросы.Scoreboards перехватывает информацию, входящую и выходящую из DUT и определяют правильно ли DUT отвечает на данный stimulus.

'''Coverage Collector'''. Coverage Collector используются для подсчета. Они перехватывают поток транзакций, и считает транзакции или различные аспекты транзакций. Цель состоит в том, чтобы определить завершенность верификации, отвечая на are-we-done вопросы. Определенные параметры, которые coverage collectors считает, зависит от схемы и специфики тестов. Общие вещи, которые coverage collectors включают в себя: необработанные транзакции, транзакции, которые происходит в определенном сегменте адресного пространства, и протокол ошибок. Список неограничен.

Coverage Collector могут также выполнять вычисления как часть полноты верификации. Например, coverage collectors может содержать скользящее среднее и среднее квадратичное отклонение данных, которые отслеживаются. Или они могут хранить отношения ошибок к выполнимым операциям.

=== Контроллер===

Контроллеры формируют основной поток теста, и управляют работой. Как правило, контроллеры получают информацию от Scoreboard и coverage collectors, и отправляют информацию компонентам окружающей среды.
Например, контроллер может запустить Stimulus генератор, а затем ждать сигнала от coverage collectors, чтобы уведомить его, когда тест будет завершен. Контроллер, в свою очередь, останавливает Stimulus генератор. Более сложные вариации на эту тему возможны. В пример возможные конфигурации, контроллер инициализирует Stimulus генератор начальным набором ограничений и запускает его. При достижении определенного соотношения типов пакетов, coverage collectors сигнализирует контроллеру. Вместо того, чтобы остановить Stimulus генератор, контроллер может отправить ему новый набор ограничений.

== Два домена( Две области)==

Мы можем разделить множество компонент в testbench на отдельные области. Оперативная область - множество компонент, в том числе DUT, которые управляют DUT. Это Stimulus генератор, шина функциональной модели (BFM), и аналогичные компоненты, которые генерируют сигналы и возвращают ответы, которые управляют моделированием. DUT, ответчик, и драйвер операций, наряду с компонентами окружающей среды, которые непосредственно обращаются или отвечают драйверам и передатчикам ответа, включены в оперативную область. Остальные компоненты testbench –монитор транзакций, scoreboard, coverage collectors, и контроллера включены в область анализа. Это компоненты, которые собирают информацию из оперативной области.

Данные должны быть перемещены из оперативной области в область анализа таким образом, чтобы не мешать работе DUT и сохранить оптимальный выбор событий. Это достигается с помощью специального интерфейса связи называемого портом анализа. Порт анализа представляют собой особый вид порта транзакций, в котором издатель передает данные одному или нескольким получателям. Издатель оповещает всех получателей, когда новые данные готовы.

Одной из ключевых особенностей порта анализа является то, что он имеет единственную функцию, write(). Анализ FIFO(????), каналы, используемые для подключения к порту анализа для анализа компонентов, неограниченные. Это гарантирует, что издатель не блокирует, а передает свои данные в анализ FIFO в точно такой же дельта-цикл, в котором они были созданы.

[[Файл:26.png]]

Как правило, оперативная и область анализа связаны портами анализа и интерфейсами управления и конфигурации. Порты анализа кран подачи выпускают данные относящиеся к операциям DUT. Эти данные могут включать шину транзакций, коммуникационные пакеты и информацию о состоянии (успех или ошибка конкретных операций). Компоненты области анализа анализируют данные и принимают решения. Результатами этих решений могут быть сообщения оперативной области, используя интерфейсы управления и конфигурирования. Интерфейсы управления и конфигурирования могут быть использованы для запуска и остановки Stimulus генератор, изменения ограничений, изменения процента ошибок, или манипулирование другими параметрами, влияющих на работу testbench.

== Заключение==

В этой главе мы рассмотрели, как структурировать весь процесс проверки. Этот процесс основывается на двух фундаментальных вопросах, Does it work? и Are we done? Простые примеры показали, как построить testbench для аппаратного ответа на эти вопросы такими устройствами как генератор сигналов и табло. Далее будет показано, как применять на уровне транзакций методы моделирования для создания практических, масштабируемых, многоразовых компонент testbench, которые отвечают на эти вопросы и показывают, как подключить их testbenches.

OVM/OVM методология/Основы объектно-ориентированного программирования

2013-03-05T13:17:58Z

Anastasiya:

{{OVM TOC}}
__TOC__

= =

Разработка программного обеспечения, не связанная с физикой электричества и магнетизма, уже давно пытается создать многократно используемые, взаимозаменяемые, надежные компоненты. Важной моделью программирования, которая решает проблему, называется объектно-ориентированным программированием (ООП). Основная идея ООП заключается в том, что программы организуются как набор взаимодействующих объектов, каждый со своим собственным областью данных и функций. Объекты могут быть многократно использованы, потому что они инкапсулируют все, что им нужно для работы, могут быть построены с минимальным числом или без внешних зависимостей, и может быть высоко параметризованы.
В этой главе вводятся основные понятия объектно-ориентированного программирования, в том числе понятия инкапсуляции и интерфейса. Глава завершается обсуждением того, почему ООП является важным для построения testbenches.

== Процедурные против ООП==

Чтобы понять ООП и его роль в проверке, необходимо сначала понять традиционное процедурное программирование и его ограничения. Это даст основу для понимания того, как ООП может преодолеть эти ограничения.
В первые дни языка ассемблера, программисты и компьютерные архитекторы быстро обнаружили, что программы часто содержат последовательности инструкций, которые повторяются во всей программе. Повторение кода (в частности, с перфокарт) является трудоемким и порождает ошибки. Чтобы избежать трудоемкости и ошибок, вызванных повторением последовательностей, была изобретена подпрограмма. Подпрограмма является единицей повторно используемого кода. Вместо кодирования той же последовательности встроенных инструкций, вы вызываете подпрограмму. Параметры, передаваемые в подпрограмму, позволяют динамически изменять код. То есть, каждый вызов подпрограммы с различными значениями параметров заставляет подпрограмму вести себя по-разному в зависимости от конкретных значений параметров.

Каждый язык программирования любой значимости имеет конструкции для создания подпрограмм, процедур и функций, а также синтаксис для передачи в них параметров и возвращаемых значений. Эти функции могут использоваться для создания операций, которые часто используются. Тем не менее, некоторые операции очень распространены (таких как I / O, преобразования данных, численные методы и т. д.). И во избежание переписывания этих операций, программисты посчитали необходимым создать библиотеки часто используемых функций. В результате, большинство языков программирования включает такие библиотеки как часть пакета компилятора. Одним из наиболее известных примеров является библиотека C, которая поступает с каждым компилятором C. Она содержит полезные функции, такие как printf() (), COS (), atof (), и QSort (). Эти функции практически каждый программист будет использовать в тот или иной момент.
Представьте себе, что писать собственные подпрограммы ввода / вывода или ваши собственные вычисления для преобразования чисел в строки и строк в числа. Был момент, когда программисты так и делали. Библиотеки универсальных функций все изменили и увеличили общую производительность программирования.

Как показывает практика программного обеспечения и передовых технологий, программисты начали думать на более высоком уровне абстракции, чем инструкции и процедуры. Вместо написания отдельных инструкций, программисты пишут код на языках, которые обеспечивают более высокую модель абстракции компьютера, и компиляторы или интерпретаторы переводят эти модели в конкретные инструкции. Библиотеки, такие как C библиотеки или STL в C + +, являются одной из форм абстракции. Они представляет собой набор функций, которые программисты могут использовать для создания все более сложных программы или абстракции.
В своей основополагающей книге Алгоритмы + Структуры данных = Программы, Никлаус Вирт объясняет, что для решения любой задачи программирования, вы должны разработать абстракцию реальности, которая имеет характеристики и свойства задачи, и игнорировать остальные детали. Он утверждает, что набор данных, которые вам нужны для решения проблемы, формирует абстракцию. Поэтому, прежде чем вы сможете решить проблема, в первую очередь необходимо определить, какие данные нужно иметь, чтобы создать решение.
Чтобы продолжить создание многократно используемой абстракции, мы должны создавать библиотеки данных объектов, которые могут быть многократно использованы для решения конкретных видов проблем. Поиск способа сделать это приводит к развитию объектно-ориентированных технологий.

Объектно-ориентированный анализ и проектирование программ сосредоточен вокруг данных объектов, функциональности, связанной с каждым объектом, и отношения между объектами.

Объектно-ориентированные языки предоставляют средства для отделения проблем программы, и выделения каждой из них независимо друг от друга, и для инкапсуляции данных абстракций и представление их через строго определенные интерфейсы. Полностью объектно-ориентированная программа строится путем разделения функциональности программы в различные классы, определения интерфейса для каждого класса, а затем установления связей и взаимодействий между компонентами через их интерфейсы.

==Классы и объекты==

Основным модулем программирования на объектно-ориентированных языках, таких как SystemVerilog, является класс. Класс содержит элементы данных, называемые членами, и задач и функций, называемых методами. Для выполнения объектно-ориентированных программ, вы должны создать один или более классов в основной программе, а затем вызвать методы на различных объектах. Хотя термины класс и объект иногда используются как синонимы, как правило, термин класс относится к классу декларации объекта, а термин объект относится к экземпляру класса.
Чтобы проиллюстрировать эти понятия, ниже приведен пример простой класс register.

<big><source lang="cpp">class register;
local bit[31:0] contents;
function void write(bit[31:0] d)
contents = d;
endfunction
function bit[31:0] read();
return contents;
endfunction
endclass
</source></big>

Это очень простой класс с одной переменной, и двумя методами, read() и write(). Чтобы использовать этот класс, вы создаете объекты путем создания экземпляра класса, а затем вызвать методы объекта, как показано ниже

<big><source lang="cpp">module top;
register r;
bit[31:0] d;
initial begin
r = new();
r.write(32’h00ff72a8);
d = r.read();
end
endmodule</source></big>

Локальный атрибут contents класса указывает компилятору строго соблюдать границы класса. Если вы пытаетесь получить доступ к contents напрямую, компилятор выдаст ошибку. Вы можете получить доступ к содержимому через доступные функции чтения и записи. Этот вид контроля доступа важен для гарантирования независимости от внутренностей класса и тем самым делает класс многократно используемым.
Вы можете использовать классы для создания новых типов данных, таких, как наш простой register. Использование классов для создания новых типов данных является важной частью ООП. Вы можете также использовать их для инкапсуляции математических вычислений или создания динамических структур данных, таких как стеки, списки, очереди, и так далее. Инкапсуляция организации структур данных или сведений о вычислениях в классе делает структуру данных или вычислений многократно используемыми.
В качестве более полного примера, давайте посмотрим на полезный тип данных, стек. Стек - это LIFO ("последним пришёл - первым обслужен") структура. Элементы помещаются в стек командой push(), а извлекаются из стека pop(). Pop () возвращает последний элемент, помещенный в стек, и удаляет его из структуры данных. Внутренние элемент stkptr следит за вершиной стека. Элемент, на который он указывает, это вершина стека, а все, что ниже его (то есть, с меньшим индексом) ниже в стеке. Ниже приведена базовая реализация стека в SystemVerilog

<big><source lang="cpp">43 class stack;
44
45 typedef bit[31:0] data_t;
46 local data_t stk[20];
47 local int stkptr;
48
49 function new();
50 clear();
51 endfunction
52
53 function bit pop(output data_t data);
54
55 if(is_empty())
56 return 0;
57
58 data = stk[stkptr];
59 stkptr = stkptr - 1;
60 return 1;
61
62 endfunction
63
64 function bit push(data_t data);
65
66 if(is_full())
67 return 0;
68
69 stkptr = stkptr + 1;
70 stk[stkptr] = data;
71 return 1;
72
73 endfunction
74
75 function bit is_full();
76 return stkptr >= 19;
77 endfunction
78
79 function bit is_empty();
80 return stkptr < 0;
81 endfunction
82
83 function void clear();
84 stkptr = -1;
85 endfunction
86
87 function void dump();
88
89 $write(“stack:”);
90 if(is_empty()) begin
91 $display(“<empty>”);
92 return;
93 end
94
95 for(int i = 0; i <= stkptr; i = i + 1) begin
96 $write(“ %0d”, stk[i]);
97 end
98
99 if(is_full())
100 $write(“ <full>”);
101 $display(““);
102
103 endfunction
104 endclass
file: 02_intro_to_OOP/01_stack/stack.sv</source>
</big>

Класс stack инкапсулирует все, что нужно знать о стеке данных структуры. Он содержит интерфейс и реализацию интерфейса. Интерфейс – это набор методов, которые используются для взаимодействия с классом. Реализация - это код, который заставляет класс работать. Интерфейс нашего стека содержит следующие методы:

<big><source lang="cpp">function new();
function bit pop(output DATA data);
function bit push(DATA data);
function bit is_full();
function bit is_empty();
function void clear();
function void dump();</source></big>

Не существует другого способа взаимодействия со стеком, как с помощью этих методов. Есть также два элемента данных класса, stk и stkptr, которые представляют фактическую структуру стека. Тем не менее, эти два элемента локальные, что означает, что компилятор запретит любые попытки доступа к ним за пределами класса. Для предотвращения доступа к внутренней структуре данных извне, мы можем сделать некоторые гарантии о состоянии данных. Например, Push () и Pop () могут рассчитывать на то, что stkptr корректно и указывает на вершину стека. Если бы можно было изменить значение stkptr иными средствами, чем с помощью интерфейса функций, тогда Push () и Pop () пришлось бы прибегнуть к дополнительным затратам и возможностям для ненадежной проверки истинности stkptr.
Реализация интерфейса встроенная. Объявление класса содержит не только определение интерфейса, а также реализацию каждой функции интерфейса. Оба C + + и SystemVerilog позволяют отделить реализацию от интерфейса. Разделение интерфейса и реализации является важной концепцией. Программисты, пишущие на C + +, могут использовать файлы заголовков для ввода интерфейс и. куб (или. срр или любой другой компилятор использует) для реализации.

Есть некоторые важные явления доступа через класс интерфейсов. Одним из них является возможность многократного использования. Мы можем удобно использовать классы, интерфейсы которых четко определены и хорошо объяснены, чем те, чьи интерфейсы нечеткие. Другим важным явлением обеспечения доступа через класс интерфейсов является надежность. Авторы класса может гарантировать определенную инвариантность (например, stkptr меньше, чем размер имеющегося массива STK) когда они знают, что пользователи не будут изменять данные иначе, чем предоставляемыми средствами. Кроме того, пользователи могут ожидать, что состояние объекта будет предсказуемым, когда они придерживаются интерфейса. Ясность другое явление. Интерфейс может описать всю семантику класса. Объект не будет делать ничего другого, чем выполнять операции, доступные через интерфейс. Это делает проще понять для тех, кто использует класс, что именно он будет делать.

== Отношения между объектами ==

Истинная сила ООП становится очевидной, когда объекты взаимосвязаны различными отношениями. Есть много видов отношений, которые возможны. Мы рассмотрим два из наиболее фундаментальных отношений HAS-A и IS-A.

=== HAS-A ===

HAS-A относится к концепции, когда один объект содержится или принадлежит другим. В нашем классе стека, например, HAS-A указатель стека (stkptr) и массив стека. Это примитивные типы данных, а не классы, но применяется тоже понятие HAS-A. В
SystemVerilog вы можете создать HAS-отношения между классами с ссылками или указателями. На рисунке ниже показаны основные памяти модель для HAS-А отношений. Объект А содержит ссылку или указатель на Объект B.

[[Файл:35.png]]

Unified Modeling Language (UML) является графическим языком для представления систем, в частности, отношения между объектами в этих системах. UML для HAS-связи выражается линией между объектами и закрашенным ромбиком(??????), как показано на рисунке ниже.

[[Файл:36.png]]

Объект А принадлежит экземпляру объекта B. кодирование HAS-А отношений в
SystemVerilog заключается в включении одного класса в другой или других способов предоставления доступа одного класса к одному классу, который хранится внутри.

<big><source lang="cpp">class B;
endclass
class A;
local B b;
function new();
b = new();
endfunction
endclass</source></big>

Класс А содержит ссылку на класс B. конструктор для класса A, метод new(), вызывает new() в классе B, чтобы создать его экземпляр. Член b содержит ссылку на вновь созданный экземпляр B.

=== IS-A ===

IS-А отношения чаще всего называют наследованием. Новый класс является производным от ранее существующего класса и наследует его характеристики. Объекты, созданные с наследованием наследования, созданы с использованием отношения IS-A. Производный класс является подклассом или более специализированная версия родительского объекта. Для иллюстрации понятия наследования, рисунок 2-3 использует часть систематики млекопитающих.

[[Файл:38.png]]

Животные, которые являются членами китообразных, хищных, приматов - млекопитающие. Эти очень разные виды существ имеют общие черты млекопитающих. Тем не менее, у китообразных (киты, дельфины), плотоядных (собак, медведей, енотов), и приматов (обезьян, людей), у каждого есть свои четкие и безошибочные характеристики. Для использования ОО терминологии, медведь - хищник и плотоядный IS- А млекопитающего. Иными словами, медведь состоит из атрибутов и плотоядные млекопитающие и плюс, дополнительные атрибуты, отличающие его от других плотоядных животных.

Для представления IS-A на языке UML, мы рисуем линию между объектами с открытыми стрелками, указывающие на базовый класс. Традиционно, мы изображаем базовый класс выше производных классов, а стрелки указывают вверх, образуя дерево наследования (или ориентированный ациклический граф, который может быть реализован в языках, таких как C + +, которые поддерживают множественное наследование).

[[Файл:39.png]]

При представлении двух объектов в компьютерной программе с использованием наследования, новый производный объект содержит характеристики родителей и обычно включает в себя дополнительные характеристики. На рисунке ниже показана базовая модель памяти для IS-А композиции. В этом примере класс B является производным от А.

[[Файл:40.png]]

SystemVerilog использует ключевое слово extends на определения наследования между классами:

<big><source lang="cpp">class A;
int i;
float f;
endclass
class B extends A;
string s;
endclass</source></big>

Класс B получена из A, поэтому он содержит все атрибуты A. Любой экземпляр B не только содержит строку S, но и объект с плавающей запятой F и целое i.

== Виртуальные функции и полиморфизм ==

Одной из причин для создания объектов, используя наследование, является определение различного поведения для той же операции. Другими словами, поведение, определенное в производном классе переопределяет поведение, определенное в базовом классе. Это можно сделать, используя виртуальные функции. Виртуальная функция – функция, которую можно переопределить в производном классе. Рассмотрим следующий универсальный пакет класса.

<big><source lang="cpp">class generic_packet;
addr_t src_addr;
addr_t dest_addr;
bit m_header [];
bit m_trailer []’
bit m_body [];
virtual function void set_header();
virtual function void set_trailer();
virtual function void set_body();
endclass</source></big>

Она имеет три виртуальных функций, чтобы установить содержимое пакета. Различные виды пакетов, требуют различного содержания. Мы используем generic_packet как базовый класс и получают различные виды пакетов из него.

<big><source lang="cpp">class packet_A extends generic packet;
virtual function void set_header();
endfunction
virtual function void set_trailer();
endfunction
virtual function void set_body();
endfunction
endclass
class packet_B extends generic_packet;
virtual function void set_header();
endfunction
virtual function void set_trailer();
endfunction
virtual function void set_body();
endfunction
endclass</source></big>

Оба packet_A и packet_B могут иметь различные заголовки и трейлеры и различные форматы полезной нагрузки. Информация о том, как части пакета отформатированы, хранится локально внутри производных классов пакета. Виртуальные функции set_header (), set_trailer (), и set_body () реализованы по-разному в каждом подклассе основываясь на типе пакета. Базовый класс generic_packet устанавливает организацию классов и типы операций, которые возможны, и производные классы могут изменить поведение этих операций.

Виртуальные функции используются для поддержки полиморфизма: несколько классов, которые могут быть использованы как взаимозаменяемые, каждый с разным поведением. Например, некоторая обработка пакетов не нуждается в информации о том, какой пакет обрабатывается. Единственной необходимой информацией является то, что объект действительно пакет, то есть, он является производным от базового класса. Еще один способ показать, что пакет является предком базового класса - это через IS-A отношения. Виртуальные функции являются механизмом, с помощью которого мы можем переопределять
поведение для различных вариантов пакетов.

Чтобы посмотреть немного глубже, как работают виртуальные функции, давайте рассмотрим три класса, связанных друг с другом IS-А отношением.

[[Файл:45.png]]

figure является базовым классом; polygon является производным от figure; square происходит от polygon. Каждый класс имеет две функции, draw(), которая является виртуальной, и compute_area (), которая не является виртуальной. Следующий пример показывает, SystemVerilog код:

<big><source lang="cpp">38
39 class figure;
40
41 virtual function void draw();
42 $display(“figure::draw”);
43 endfunction
44
45 function void compute_area();
46 $display(“figure::compute_area”);
47 endfunction
48
49 endclass
50
51 class polygon extends figure;
52
53 virtual function void draw();
54 $display(“polygon::draw”);
55 endfunction
56
57 function void compute_area();
58 $display(“polygon::compute_area”);
59 endfunction
60
61 endclass
62
63 class square extends polygon;
64
65 virtual function void draw();
66 $display(“square::draw”);
67 endfunction
68
69 function void compute_area();
70 $display(“square::compute_area”);
71 endfunction
72
73 endclass
file: 02_intro_to_OOP/03_virtual/virtual.sv
</source>
</big>
Каждая функция выводит его полное имя в виде class_name :: имя_функции. Мы можем написать простую программу, которая показывает, как виртуальные функции связаны.

<big><source lang="cpp">
75 program top;
76 figure f;
77 polygon p;
78 square s;
79
80 initial begin
81 s = new();
82 f = s;
83 p = s;
84
85 p.draw();
86 p.compute_area();
87 f.draw();
88 f.compute_area();
89 s.draw();
90 s.compute_area();
91 end
92 endprogram
file: 02_intro_to_OOP/03_virtual/virtual.sv</source></big>

Ниже показано, что происходит, когда мы запускаем эту программу:

[[Файл:49.png]]

Сначала мы создаем s, квадрат, а затем назначаем его на f и р. базовым классом для square является polygon и базовым классом polygon - figure. Из напечатанного вывода, мы можем заключить, что функции связаны в соответствии со следующей таблице:

[[Файл:50.png]]

Во всех случаях, compute_area () была связана с конкретным compute_area () функцией с типом ссылки, которая ее определяет -р ссылки на polygon, таким образом связаны polygon :: compute_area (). Так как compute_area () не является виртуальной функцией. Компилятор может легко определить, какие версии функций вызывать, основываясь на типе объекта.

Так как draw() является виртуальной, не всегда возможно для компилятора определить, какую функцию вызывать. Решение принимается на этапе выполнения с помощью
виртуальной таблицы, таблицы привязки функций. Виртуальная таблица используется для привязки функций, привязка не может быть полностью определена во время компиляции.

Обратите внимание, что хотя р представляет собой polygon, вызов p.draw () приводит к square::draw() вызывается не polygon::draw(), как вы могли бы ожидать.
То же самое происходит и с F-f.draw () связан с кsquare::draw().
объект, который мы первоначально создан представляет собой square, он поддерживает различные типы операций но, то, что это square не забывается. Это работает только потому, что square является производным от polygon, который в свою очередь является производным figure, и потому draw() объявлен как виртуальный. Ошибка компиляции О несовместимости типа возникает при попытке присвоить ей к s
и p так как с не получено от р.

== Универсальное программирование==

Напомним, что объектно-ориентированные языки обладают средствами для разделения программ на задачи и рассмотрения их отдельно. Импликация отдельных задач заключается в том, что каждая задача представлена один раз. Дублирование кода нарушает принцип. На практике, многие задачи очень схожи, и имеют похожее решение, но не идентичное. Интуитивно, мы хотим написать код, который может быть использован во многих ситуациях. Это интуиция подводит нас к написанию универсального кода, кода, который высоко параметризованный, так что он может быть легко использован в самых разнообразных ситуациях.

Подробная информация об универсальном коде поставляется во время компиляции или во время выполнения вместо жесткого кодирования. Любой код, который имеет параметры, такие как вызов функций, может, считается универсальным, но этот термин обычно используется для кода с использованием шаблонов (в C + +) или параметризованные классы (в SystemVerilog). Написание универсальных программ согласуется с целью ООП о разделении задач. Таким образом, ООП языки обеспечивают условия для создания универсального кода.

Параметризованный класс – это класс, который (очевидно) имеет параметры. В синтаксисе SystemVerilog для определения параметров используется знак # в заголовке класса, после следует список параметров в скобках. В качестве примера, рассмотрим следующий параметризованный класс:

<big><source lang="cpp">class param #(type T=int, int R=16);
endclass</source></big>

Этот класс имеет два параметра, T, который является фиктивным параметром и R, который является целочисленным параметром. Экземпляры параметризованных классов с определенными значениями параметров создают специализации, то есть версии кода с примененными параметрами.

<big><source lang="cpp">param #(real, 29) z;
param #(int unsigned, 12) q;</source></big>

Приведенные выше объявления создают специализации параметризованного класса
param. Имя класса и параметры определяют специализацию. Таким образом,
специализации, по сути, уникальные типы. Компилятор не позволит вам присвоить q к z, или наоборот, потому что они являются объектами различных типов.

Параметр type позволяет писать типа-независимый код, код, данные и алгоритмы которого могут работать с широким спектром типов данных. Например:

<big><source lang="cpp">class maximizer #(type T=int);
function T max(T a, T b);
if( a > b )
return a;
else
return b;
endfunction
endclass</source></big>

Параметризованный класс maximizer имеет функцию max(), которая возвращает
максимальное из двух значений. Алгоритм max() такой же, независимо от типа сравнения объектов. В этом случае, единственным ограничением является то, что объекты должны быть сравнимы оператором больше чем (>).
Классы не могут сравниваться с использованием оператора большего чем, поэтому другая версия maximizer должна работать с классами. Для создания версии maximizer, которая будет возвращать больший из двух классов, мы должны определить метод в каждом классе, который будет сравнивать объекты.

<big><source lang="cpp">class maximizer #(type T=int);
function T max( T a, T b);
if( a.comp(b) > 0 )
return a;
else
return b;
endfunction
endclass</source>
</big>

Это предполагает, что параметр T типа type действительно класс, а не встроенного тип, такие как int или real. Кроме того, он предполагает, что T имеет функцию под названием Comp (), которая используется для сравнения себя с другим экземпляром. Библиотека OVM содержит параметризованный компонент, называемый ovm_in_order_comparator # (T), который используется для сравнения потоков операций. Она имеет два варианта, один для сравнения потоков встроенных типов, и один для сравнения потоков классов. Причина необходимости двух компараторов в том, что SystemVerilog не поддерживает операторы, которые могут работать и с классами и со встроенными типами.

=== Универсальный стек ===

Наш стек не особенно универсальный. Она имеет фиксированный размер 20, а
тип данных элементов хранящихся в стеке Int. Ниже приводится более общий вид стека, который изменяет эти фиксированные характеристики параметризованными.

<big><source lang="cpp">53 class stack #(type T = int);
54
55 local T stk[];
56 local int stkptr;
57 local int size;
58 local int tp;
59
60 function new(int s = 20);
61 size = s;
62 stk = new [size];
63 clear();
64 endfunction
65
66 function bit pop(output T data);
67
68 if(is_empty())
69 return 0;
70
71 data = stk[stkptr];
72 stkptr = stkptr - 1;
73 return 1;
74
75 endfunction
76
77 function bit push(T data);
78
79 if(is_full())
80 return 0;
81
82 stkptr = stkptr + 1;
83 stk[stkptr] = data;
84 return 1;
85
86 endfunction
87
88 function bit is_full();
89 return stkptr >= (size - 1);
90 endfunction
91
92 function bit is_empty();
93 return stkptr < 0;
94 endfunction
95
96 function void clear();
97 stkptr = -1;
98 tp = stkptr;
99 endfunction
100
101 function void traverse_init();
102 tp = stkptr;
103 endfunction
104
105 function int traverse_next(output T t);
106 if(tp < 0)
107 return 0; // failure
108
109 t = stk[tp];
110 tp = tp - 1;
111 return 1;
112
113 endfunction
114
115 virtual function void print(input T t);
116 $display(“print is unimplemented”);
117 endfunction
118
119 function void dump();
120
121 T t;
122
123 $write(“stack:”);
124 if(is_empty()) begin
125 $display(“<empty>”);
126 return;
127 end
128
129 traverse_init();
130
131 while(traverse_next(t)) begin
132 print(t);
133 end
134 $display();
135
136 endfunction
137
138 endclass
file: 02_intro_to_OOP/02_generic_stack/stack.sv</source>
</big>

Универсальный класс stack параметризован типом объектов стека.
Параметр T содержит тип. В этом случае T может быть либо классом или встроенным
типом. В любом месте класса, где мы ранее использовали Int как тип стека, теперь мы используем Т. Например, push() теперь принимает аргумент типа T. Параметры класса,
такие как T, устанавливаются во время компиляции. Для специализации stack#(T), мы инициализируем его с определенным значением для данного типа. Например:

<big><source lang="cpp">stack #(real) real_stack;</source></big>

Этот оператор создает специализацию stack, который использует real, как тип объектов стека.
Размер стека больше не зафиксирована на уровне 20. Мы используем динамический массив для хранения стека, размер которого указан в качестве параметра конструктора. В отличие от T, аргумент size задается при выполнении программы. Это позволяет нам создать несколько стеков, каждый с разным размером.

<big><source lang="cpp">stack #(real) big_stack;
stack #(real) little_stack;
...
big_stack = new(2048);
little_stack = new(6);</source></big>

big_stack и little_stack одного типа. Они используют одну и ту же специализацию stack#(T). Тем не менее, каждый из них создается с различными параметрами размера.

В процессе создания универсального стека, мы сделали еще одно изменение. Мы заменили dump() на traverse_init () и traverse_next (). dump() зависит от типа элементов стека, которые не известны до компиляции. Мы должны иметь возможность пройти по стеку и отформатировать каждый элемент, не зависимо от типа элемента. Это может быть INT, или это может быть сложный класс с несколькими членами. Чтобы сохранить stack#(T) универсальным, мы должны исключить любую зависимость от типа элементов стека.

В то время как dump() пробежит по всем элементам стека и напечатает их в определенном порядке, traverse_init () устанавливает внутренний указатель(tp) на вершину стека, а traverse_next () возвращает текущий элемент и уменьшает tp. Стек поддерживает некоторую статическую информацию обхода. Статическая информация сбрасывается, когда вызывается traverse_init ().

== Классы и Модули==

Интересно, что HDLs, такие как Verilog и VHDL, хотя они не считаются объектно-ориентированными языками, строятся на концепции очень схожей классам и объектам. Модули в Verilog, например, являются объектами, каждый из которых имеет
свое собственное пространство данных и набор задач и функций. Так же, как объекты в ОО программах, каждый экземпляр модуля является независимой копией. Все экземпляры имеют один и тот же набор задач и функций и те же интерфейсы, но данные содержащихся внутри каждого является независимым от всех остальных экземпляров. Модули контролируются их интерфейсами. Verilog модули не поддерживают наследование или параметризации типов, и они являются статическими, что делает их непригодными для истинного ООП.

Сходство между классами и модулями открывает возможность для нас использовать объекты класса в аппаратном контексте. Мы можем создать компоненты верификации как экземпляры классов, что дает нам гибкость при подключении к аппаратным элементам. Дизайнеры SystemVerilog выигрывают при расширении Verilog классами, предоставляя возможность для классов работать как модули.

В приведенной ниже таблице сравниваются особенности классов в Verilog, SystemVerilog, и C + +.

[[Файл:60.png]]

В SystemVerilog есть особенность, которая делает это возможным это виртуальный интерфейс. Виртуальный интерфейс является ссылкой на интерфейс (здесь мы имеем в виду SystemVerilog интерфейс). Мы можем написать класс, содержащий ссылки
к элементам внутри интерфейса, которых еще не существует (то есть, они не создаются). Когда создается экземпляр класса, виртуальный интерфейс подключается к реальному интерфейсу. Это делает возможным для объекта класса реагировать и отвечать на входные изменения. Модули SystemC реализованы в виде классов и позволяют входам быть в списке портов, обеспечивая такую же структуру.

В HDLs, таких как Verilog и VHDL, не хватает многих возможностей ООП, и, следовательно, не хорошо подходят для построения testbenches. Основной единицей программирования в большинстве HDLs является модуль, и это статический объект. Модули создаются в самом начале программы и сохраняются не измененными до завершения программы. Они синтаксически статические и это означает, что
средства для изменения модулей, создания другого варианта, ограничены. Verilog позволяет параметризовать скалярные значения, но не типы. Часто все сводятся к резке и вставке кода, а затем внесению локальных изменений. Если у вас есть десять различных вариаций нужных в конкретном проекте, необходимо вставить десять копий в соответствующие места, а затем локально изменить каждую из них.

== ООП и Верификация==

Создание объектно-ориентированных программ и создания testbench мало чем отличается. testbench представляет собой сеть взаимодействующих компонентов. ООП работает с определением и анализом сетей взаимодействующих объектов. Объекты могут быть связаны IS-A или HAS-A отношениями, и они общаются через интерфейсы.
ООП просто естественно вписывается проблему создания testbenches.

Языки, таких как SystemC / C + + и SystemVerilog, которые действительно поддерживают возможности ООП , лучше подходят для создания testbench, чем HDLs, такие как Verilog и VHDL. Используя динамические классы, параметризованные классы, наследование и параметризованные конструкторы, вы можете создать компоненты, которые являются гибкими, повторно используемыми и надежные. Потратив немного больше времени, чтобы построить универсальную компоненту, приведет вас приросту производительности, когда эта компонент повторно используется по-разному в разных местах.

OVM/OVM методология/Основы объектно-ориентированного программирования

2013-03-05T12:13:34Z

Anastasiya:

{{OVM TOC}}
__TOC__

= =

Разработка программного обеспечения, не связанная с физикой электричества и магнетизма, уже давно пытается создать многократно используемые, взаимозаменяемые, надежные компоненты. Важной моделью программирования, которая решает проблему, называется объектно-ориентированным программированием (ООП). Основная идея ООП заключается в том, что программы организуются как набор взаимодействующих объектов, каждый со своим собственным областью данных и функций. Объекты могут быть многократно использованы, потому что они инкапсулируют все, что им нужно для работы, могут быть построены с минимальным числом или без внешних зависимостей, и может быть высоко параметризованы.
В этой главе вводятся основные понятия объектно-ориентированного программирования, в том числе понятия инкапсуляции и интерфейса. Глава завершается обсуждением того, почему ООП является важным для построения testbenches.

== Процедурные против ООП==

Чтобы понять ООП и его роль в проверке, необходимо сначала понять традиционное процедурное программирование и его ограничения. Это даст основу для понимания того, как ООП может преодолеть эти ограничения.
В первые дни языка ассемблера, программисты и компьютерные архитекторы быстро обнаружили, что программы часто содержат последовательности инструкций, которые повторяются во всей программе. Повторение кода (в частности, с перфокарт) является трудоемким и порождает ошибки. Чтобы избежать трудоемкости и ошибок, вызванных повторением последовательностей, была изобретена подпрограмма. Подпрограмма является единицей повторно используемого кода. Вместо кодирования той же последовательности встроенных инструкций, вы вызываете подпрограмму. Параметры, передаваемые в подпрограмму, позволяют динамически изменять код. То есть, каждый вызов подпрограммы с различными значениями параметров заставляет подпрограмму вести себя по-разному в зависимости от конкретных значений параметров.

Каждый язык программирования любой значимости имеет конструкции для создания подпрограмм, процедур и функций, а также синтаксис для передачи в них параметров и возвращаемых значений. Эти функции могут использоваться для создания операций, которые часто используются. Тем не менее, некоторые операции очень распространены (таких как I / O, преобразования данных, численные методы и т. д.). И во избежание переписывания этих операций, программисты посчитали необходимым создать библиотеки часто используемых функций. В результате, большинство языков программирования включает такие библиотеки как часть пакета компилятора. Одним из наиболее известных примеров является библиотека C, которая поступает с каждым компилятором C. Она содержит полезные функции, такие как printf() (), COS (), atof (), и QSort (). Эти функции практически каждый программист будет использовать в тот или иной момент.
Представьте себе, что писать собственные подпрограммы ввода / вывода или ваши собственные вычисления для преобразования чисел в строки и строк в числа. Был момент, когда программисты так и делали. Библиотеки универсальных функций все изменили и увеличили общую производительность программирования.

Как показывает практика программного обеспечения и передовых технологий, программисты начали думать на более высоком уровне абстракции, чем инструкции и процедуры. Вместо написания отдельных инструкций, программисты пишут код на языках, которые обеспечивают более высокую модель абстракции компьютера, и компиляторы или интерпретаторы переводят эти модели в конкретные инструкции. Библиотеки, такие как C библиотеки или STL в C + +, являются одной из форм абстракции. Они представляет собой набор функций, которые программисты могут использовать для создания все более сложных программы или абстракции.
В своей основополагающей книге Алгоритмы + Структуры данных = Программы, Никлаус Вирт объясняет, что для решения любой задачи программирования, вы должны разработать абстракцию реальности, которая имеет характеристики и свойства задачи, и игнорировать остальные детали. Он утверждает, что набор данных, которые вам нужны для решения проблемы, формирует абстракцию. Поэтому, прежде чем вы сможете решить проблема, в первую очередь необходимо определить, какие данные нужно иметь, чтобы создать решение.
Чтобы продолжить создание многократно используемой абстракции, мы должны создавать библиотеки данных объектов, которые могут быть многократно использованы для решения конкретных видов проблем. Поиск способа сделать это приводит к развитию объектно-ориентированных технологий.

Объектно-ориентированный анализ и проектирование программ сосредоточен вокруг данных объектов, функциональности, связанной с каждым объектом, и отношения между объектами.

Объектно-ориентированные языки предоставляют средства для отделения проблем программы, и выделения каждой из них независимо друг от друга, и для инкапсуляции данных абстракций и представление их через строго определенные интерфейсы. Полностью объектно-ориентированная программа строится путем разделения функциональности программы в различные классы, определения интерфейса для каждого класса, а затем установления связей и взаимодействий между компонентами через их интерфейсы.

==Классы и объекты==

Основным модулем программирования на объектно-ориентированных языках, таких как SystemVerilog, является класс. Класс содержит элементы данных, называемые членами, и задач и функций, называемых методами. Для выполнения объектно-ориентированных программ, вы должны создать один или более классов в основной программе, а затем вызвать методы на различных объектах. Хотя термины класс и объект иногда используются как синонимы, как правило, термин класс относится к классу декларации объекта, а термин объект относится к экземпляру класса.
Чтобы проиллюстрировать эти понятия, ниже приведен пример простой класс register.

[[Файл:27.png]]

[[Файл:28.png]]

Это очень простой класс с одной переменной, и двумя методами, read() и write(). Чтобы использовать этот класс, вы создаете объекты путем создания экземпляра класса, а затем вызвать методы объекта, как показано ниже

[[Файл:29.png]]

Локальный атрибут contents класса указывает компилятору строго соблюдать границы класса. Если вы пытаетесь получить доступ к contents напрямую, компилятор выдаст ошибку. Вы можете получить доступ к содержимому через доступные функции чтения и записи. Этот вид контроля доступа важен для гарантирования независимости от внутренностей класса и тем самым делает класс многократно используемым.
Вы можете использовать классы для создания новых типов данных, таких, как наш простой register. Использование классов для создания новых типов данных является важной частью ООП. Вы можете также использовать их для инкапсуляции математических вычислений или создания динамических структур данных, таких как стеки, списки, очереди, и так далее. Инкапсуляция организации структур данных или сведений о вычислениях в классе делает структуру данных или вычислений многократно используемыми.
В качестве более полного примера, давайте посмотрим на полезный тип данных, стек. Стек - это LIFO ("последним пришёл - первым обслужен") структура. Элементы помещаются в стек командой push(), а извлекаются из стека pop(). Pop () возвращает последний элемент, помещенный в стек, и удаляет его из структуры данных. Внутренние элемент stkptr следит за вершиной стека. Элемент, на который он указывает, это вершина стека, а все, что ниже его (то есть, с меньшим индексом) ниже в стеке. Ниже приведена базовая реализация стека в SystemVerilog

[[Файл:30.png]]

[[Файл:31.png]]

[[Файл:32.png]]

[[Файл:33.png]]

Класс stack инкапсулирует все, что нужно знать о стеке данных структуры. Он содержит интерфейс и реализацию интерфейса. Интерфейс – это набор методов, которые используются для взаимодействия с классом. Реализация - это код, который заставляет класс работать. Интерфейс нашего стека содержит следующие методы:

[[Файл:34.png]]

Не существует другого способа взаимодействия со стеком, как с помощью этих методов. Есть также два элемента данных класса, stk и stkptr, которые представляют фактическую структуру стека. Тем не менее, эти два элемента локальные, что означает, что компилятор запретит любые попытки доступа к ним за пределами класса. Для предотвращения доступа к внутренней структуре данных извне, мы можем сделать некоторые гарантии о состоянии данных. Например, Push () и Pop () могут рассчитывать на то, что stkptr корректно и указывает на вершину стека. Если бы можно было изменить значение stkptr иными средствами, чем с помощью интерфейса функций, тогда Push () и Pop () пришлось бы прибегнуть к дополнительным затратам и возможностям для ненадежной проверки истинности stkptr.
Реализация интерфейса встроенная. Объявление класса содержит не только определение интерфейса, а также реализацию каждой функции интерфейса. Оба C + + и SystemVerilog позволяют отделить реализацию от интерфейса. Разделение интерфейса и реализации является важной концепцией. Программисты, пишущие на C + +, могут использовать файлы заголовков для ввода интерфейс и. куб (или. срр или любой другой компилятор использует) для реализации.

Есть некоторые важные явления доступа через класс интерфейсов. Одним из них является возможность многократного использования. Мы можем удобно использовать классы, интерфейсы которых четко определены и хорошо объяснены, чем те, чьи интерфейсы нечеткие. Другим важным явлением обеспечения доступа через класс интерфейсов является надежность. Авторы класса может гарантировать определенную инвариантность (например, stkptr меньше, чем размер имеющегося массива STK) когда они знают, что пользователи не будут изменять данные иначе, чем предоставляемыми средствами. Кроме того, пользователи могут ожидать, что состояние объекта будет предсказуемым, когда они придерживаются интерфейса. Ясность другое явление. Интерфейс может описать всю семантику класса. Объект не будет делать ничего другого, чем выполнять операции, доступные через интерфейс. Это делает проще понять для тех, кто использует класс, что именно он будет делать.

== Отношения между объектами ==

Истинная сила ООП становится очевидной, когда объекты взаимосвязаны различными отношениями. Есть много видов отношений, которые возможны. Мы рассмотрим два из наиболее фундаментальных отношений HAS-A и IS-A.

=== HAS-A ===

HAS-A относится к концепции, когда один объект содержится или принадлежит другим. В нашем классе стека, например, HAS-A указатель стека (stkptr) и массив стека. Это примитивные типы данных, а не классы, но применяется тоже понятие HAS-A. В
SystemVerilog вы можете создать HAS-отношения между классами с ссылками или указателями. На рисунке ниже показаны основные памяти модель для HAS-А отношений. Объект А содержит ссылку или указатель на Объект B.

[[Файл:35.png]]

Unified Modeling Language (UML) является графическим языком для представления систем, в частности, отношения между объектами в этих системах. UML для HAS-связи выражается линией между объектами и закрашенным ромбиком(??????), как показано на рисунке ниже.

[[Файл:36.png]]

Объект А принадлежит экземпляру объекта B. кодирование HAS-А отношений в
SystemVerilog заключается в включении одного класса в другой или других способов предоставления доступа одного класса к одному классу, который хранится внутри.

[[Файл:37.png]]

Класс А содержит ссылку на класс B. конструктор для класса A, метод new(), вызывает new() в классе B, чтобы создать его экземпляр. Член b содержит ссылку на вновь созданный экземпляр B.

=== IS-A ===

IS-А отношения чаще всего называют наследованием. Новый класс является производным от ранее существующего класса и наследует его характеристики. Объекты, созданные с наследованием наследования, созданы с использованием отношения IS-A. Производный класс является подклассом или более специализированная версия родительского объекта. Для иллюстрации понятия наследования, рисунок 2-3 использует часть систематики млекопитающих.

[[Файл:38.png]]

Животные, которые являются членами китообразных, хищных, приматов - млекопитающие. Эти очень разные виды существ имеют общие черты млекопитающих. Тем не менее, у китообразных (киты, дельфины), плотоядных (собак, медведей, енотов), и приматов (обезьян, людей), у каждого есть свои четкие и безошибочные характеристики. Для использования ОО терминологии, медведь - хищник и плотоядный IS- А млекопитающего. Иными словами, медведь состоит из атрибутов и плотоядные млекопитающие и плюс, дополнительные атрибуты, отличающие его от других плотоядных животных.

Для представления IS-A на языке UML, мы рисуем линию между объектами с открытыми стрелками, указывающие на базовый класс. Традиционно, мы изображаем базовый класс выше производных классов, а стрелки указывают вверх, образуя дерево наследования (или ориентированный ациклический граф, который может быть реализован в языках, таких как C + +, которые поддерживают множественное наследование).

[[Файл:39.png]]

При представлении двух объектов в компьютерной программе с использованием наследования, новый производный объект содержит характеристики родителей и обычно включает в себя дополнительные характеристики. На рисунке ниже показана базовая модель памяти для IS-А композиции. В этом примере класс B является производным от А.

[[Файл:40.png]]

SystemVerilog использует ключевое слово extends на определения наследования между классами:

[[Файл:41.png]]

Класс B получена из A, поэтому он содержит все атрибуты A. Любой экземпляр B не только содержит строку S, но и объект с плавающей запятой F и целое i.

== Виртуальные функции и полиморфизм ==

Одной из причин для создания объектов, используя наследование, является определение различного поведения для той же операции. Другими словами, поведение, определенное в производном классе переопределяет поведение, определенное в базовом классе. Это можно сделать, используя виртуальные функции. Виртуальная функция – функция, которую можно переопределить в производном классе. Рассмотрим следующий универсальный пакет класса.

[[Файл:42.png]]

[[Файл:43.png]]

Она имеет три виртуальных функций, чтобы установить содержимое пакета. Различные виды пакетов, требуют различного содержания. Мы используем generic_packet как базовый класс и получают различные виды пакетов из него.

[[Файл:44.png]]

Оба packet_A и packet_B могут иметь различные заголовки и трейлеры и различные форматы полезной нагрузки. Информация о том, как части пакета отформатированы, хранится локально внутри производных классов пакета. Виртуальные функции set_header (), set_trailer (), и set_body () реализованы по-разному в каждом подклассе основываясь на типе пакета. Базовый класс generic_packet устанавливает организацию классов и типы операций, которые возможны, и производные классы могут изменить поведение этих операций.

Виртуальные функции используются для поддержки полиморфизма: несколько классов, которые могут быть использованы как взаимозаменяемые, каждый с разным поведением. Например, некоторая обработка пакетов не нуждается в информации о том, какой пакет обрабатывается. Единственной необходимой информацией является то, что объект действительно пакет, то есть, он является производным от базового класса. Еще один способ показать, что пакет является предком базового класса - это через IS-A отношения. Виртуальные функции являются механизмом, с помощью которого мы можем переопределять
поведение для различных вариантов пакетов.

Чтобы посмотреть немного глубже, как работают виртуальные функции, давайте рассмотрим три класса, связанных друг с другом IS-А отношением.

[[Файл:45.png]]

figure является базовым классом; polygon является производным от figure; square происходит от polygon. Каждый класс имеет две функции, draw(), которая является виртуальной, и compute_area (), которая не является виртуальной. Следующий пример показывает, SystemVerilog код:

[[Файл:46.png]]

[[Файл:47.png]]

Каждая функция выводит его полное имя в виде class_name :: имя_функции. Мы можем написать простую программу, которая показывает, как виртуальные функции связаны.

[[Файл:48.png]]

Ниже показано, что происходит, когда мы запускаем эту программу:

[[Файл:49.png]]

Сначала мы создаем s, квадрат, а затем назначаем его на f и р. базовым классом для square является polygon и базовым классом polygon - figure. Из напечатанного вывода, мы можем заключить, что функции связаны в соответствии со следующей таблице:

[[Файл:50.png]]

Во всех случаях, compute_area () была связана с конкретным compute_area () функцией с типом ссылки, которая ее определяет -р ссылки на polygon, таким образом связаны polygon :: compute_area (). Так как compute_area () не является виртуальной функцией. Компилятор может легко определить, какие версии функций вызывать, основываясь на типе объекта.

Так как draw() является виртуальной, не всегда возможно для компилятора определить, какую функцию вызывать. Решение принимается на этапе выполнения с помощью
виртуальной таблицы, таблицы привязки функций. Виртуальная таблица используется для привязки функций, привязка не может быть полностью определена во время компиляции.

Обратите внимание, что хотя р представляет собой polygon, вызов p.draw () приводит к square::draw() вызывается не polygon::draw(), как вы могли бы ожидать.
То же самое происходит и с F-f.draw () связан с кsquare::draw().
объект, который мы первоначально создан представляет собой square, он поддерживает различные типы операций но, то, что это square не забывается. Это работает только потому, что square является производным от polygon, который в свою очередь является производным figure, и потому draw() объявлен как виртуальный. Ошибка компиляции О несовместимости типа возникает при попытке присвоить ей к s
и p так как с не получено от р.

== Универсальное программирование==

Напомним, что объектно-ориентированные языки обладают средствами для разделения программ на задачи и рассмотрения их отдельно. Импликация отдельных задач заключается в том, что каждая задача представлена один раз. Дублирование кода нарушает принцип. На практике, многие задачи очень схожи, и имеют похожее решение, но не идентичное. Интуитивно, мы хотим написать код, который может быть использован во многих ситуациях. Это интуиция подводит нас к написанию универсального кода, кода, который высоко параметризованный, так что он может быть легко использован в самых разнообразных ситуациях.

Подробная информация об универсальном коде поставляется во время компиляции или во время выполнения вместо жесткого кодирования. Любой код, который имеет параметры, такие как вызов функций, может, считается универсальным, но этот термин обычно используется для кода с использованием шаблонов (в C + +) или параметризованные классы (в SystemVerilog). Написание универсальных программ согласуется с целью ООП о разделении задач. Таким образом, ООП языки обеспечивают условия для создания универсального кода.

Параметризованный класс – это класс, который (очевидно) имеет параметры. В синтаксисе SystemVerilog для определения параметров используется знак # в заголовке класса, после следует список параметров в скобках. В качестве примера, рассмотрим следующий параметризованный класс:

<source lang="cpp">class param #(type T=int, int R=16);
endclass</source>

Этот класс имеет два параметра, T, который является фиктивным параметром и R, который является целочисленным параметром. Экземпляры параметризованных классов с определенными значениями параметров создают специализации, то есть версии кода с примененными параметрами.

<source lang="cpp">param #(real, 29) z;
param #(int unsigned, 12) q;</source>

Приведенные выше объявления создают специализации параметризованного класса
param. Имя класса и параметры определяют специализацию. Таким образом,
специализации, по сути, уникальные типы. Компилятор не позволит вам присвоить q к z, или наоборот, потому что они являются объектами различных типов.

Параметр type позволяет писать типа-независимый код, код, данные и алгоритмы которого могут работать с широким спектром типов данных. Например:

<source lang="cpp">class maximizer #(type T=int);
function T max(T a, T b);
if( a > b )
return a;
else
return b;
endfunction
endclass</source>

Параметризованный класс maximizer имеет функцию max(), которая возвращает
максимальное из двух значений. Алгоритм max() такой же, независимо от типа сравнения объектов. В этом случае, единственным ограничением является то, что объекты должны быть сравнимы оператором больше чем (>).
Классы не могут сравниваться с использованием оператора большего чем, поэтому другая версия maximizer должна работать с классами. Для создания версии maximizer, которая будет возвращать больший из двух классов, мы должны определить метод в каждом классе, который будет сравнивать объекты.

<source lang="cpp">class maximizer #(type T=int);
function T max( T a, T b);
if( a.comp(b) > 0 )
return a;
else
return b;
endfunction
endclass</source>

Это предполагает, что параметр T типа type действительно класс, а не встроенного тип, такие как int или real. Кроме того, он предполагает, что T имеет функцию под названием Comp (), которая используется для сравнения себя с другим экземпляром. Библиотека OVM содержит параметризованный компонент, называемый ovm_in_order_comparator # (T), который используется для сравнения потоков операций. Она имеет два варианта, один для сравнения потоков встроенных типов, и один для сравнения потоков классов. Причина необходимости двух компараторов в том, что SystemVerilog не поддерживает операторы, которые могут работать и с классами и со встроенными типами.

=== Универсальный стек ===

Наш стек не особенно универсальный. Она имеет фиксированный размер 20, а
тип данных элементов хранящихся в стеке Int. Ниже приводится более общий вид стека, который изменяет эти фиксированные характеристики параметризованными.

<source lang="cpp">53 class stack #(type T = int);
54
55 local T stk[];
56 local int stkptr;
57 local int size;
58 local int tp;
59
60 function new(int s = 20);
61 size = s;
62 stk = new [size];
63 clear();
64 endfunction
65
66 function bit pop(output T data);
67
68 if(is_empty())
69 return 0;
70
71 data = stk[stkptr];
72 stkptr = stkptr - 1;
73 return 1;
74
75 endfunction
76
77 function bit push(T data);
78
79 if(is_full())
80 return 0;
81
82 stkptr = stkptr + 1;
83 stk[stkptr] = data;
84 return 1;
85
86 endfunction
87
88 function bit is_full();
89 return stkptr >= (size - 1);
90 endfunction
91
92 function bit is_empty();
93 return stkptr < 0;
94 endfunction
95
96 function void clear();
97 stkptr = -1;
98 tp = stkptr;
99 endfunction
100
101 function void traverse_init();
102 tp = stkptr;
103 endfunction
104
105 function int traverse_next(output T t);
106 if(tp < 0)
107 return 0; // failure
108
109 t = stk[tp];
110 tp = tp - 1;
111 return 1;
112
113 endfunction
114
115 virtual function void print(input T t);
116 $display(“print is unimplemented”);
117 endfunction
118
119 function void dump();
120
121 T t;
122
123 $write(“stack:”);
124 if(is_empty()) begin
125 $display(“<empty>”);
126 return;
127 end
128
129 traverse_init();
130
131 while(traverse_next(t)) begin
132 print(t);
133 end
134 $display();
135
136 endfunction
137
138 endclass
file: 02_intro_to_OOP/02_generic_stack/stack.sv</source>

Универсальный класс stack параметризован типом объектов стека.
Параметр T содержит тип. В этом случае T может быть либо классом или встроенным
типом. В любом месте класса, где мы ранее использовали Int как тип стека, теперь мы используем Т. Например, push() теперь принимает аргумент типа T. Параметры класса,
такие как T, устанавливаются во время компиляции. Для специализации stack#(T), мы инициализируем его с определенным значением для данного типа. Например:

<source lang="cpp">stack #(real) real_stack;</source>

Этот оператор создает специализацию stack, который использует real, как тип объектов стека.
Размер стека больше не зафиксирована на уровне 20. Мы используем динамический массив для хранения стека, размер которого указан в качестве параметра конструктора. В отличие от T, аргумент size задается при выполнении программы. Это позволяет нам создать несколько стеков, каждый с разным размером.

<source lang="cpp">stack #(real) big_stack;
stack #(real) little_stack;
...
big_stack = new(2048);
little_stack = new(6);</source>

big_stack и little_stack одного типа. Они используют одну и ту же специализацию stack#(T). Тем не менее, каждый из них создается с различными параметрами размера.

В процессе создания универсального стека, мы сделали еще одно изменение. Мы заменили dump() на traverse_init () и traverse_next (). dump() зависит от типа элементов стека, которые не известны до компиляции. Мы должны иметь возможность пройти по стеку и отформатировать каждый элемент, не зависимо от типа элемента. Это может быть INT, или это может быть сложный класс с несколькими членами. Чтобы сохранить stack#(T) универсальным, мы должны исключить любую зависимость от типа элементов стека.

В то время как dump() пробежит по всем элементам стека и напечатает их в определенном порядке, traverse_init () устанавливает внутренний указатель(tp) на вершину стека, а traverse_next () возвращает текущий элемент и уменьшает tp. Стек поддерживает некоторую статическую информацию обхода. Статическая информация сбрасывается, когда вызывается traverse_init ().

== Классы и Модули==

Интересно, что HDLs, такие как Verilog и VHDL, хотя они не считаются объектно-ориентированными языками, строятся на концепции очень схожей классам и объектам. Модули в Verilog, например, являются объектами, каждый из которых имеет
свое собственное пространство данных и набор задач и функций. Так же, как объекты в ОО программах, каждый экземпляр модуля является независимой копией. Все экземпляры имеют один и тот же набор задач и функций и те же интерфейсы, но данные содержащихся внутри каждого является независимым от всех остальных экземпляров. Модули контролируются их интерфейсами. Verilog модули не поддерживают наследование или параметризации типов, и они являются статическими, что делает их непригодными для истинного ООП.

Сходство между классами и модулями открывает возможность для нас использовать объекты класса в аппаратном контексте. Мы можем создать компоненты верификации как экземпляры классов, что дает нам гибкость при подключении к аппаратным элементам. Дизайнеры SystemVerilog выигрывают при расширении Verilog классами, предоставляя возможность для классов работать как модули.

В приведенной ниже таблице сравниваются особенности классов в Verilog, SystemVerilog, и C + +.

[[Файл:60.png]]

В SystemVerilog есть особенность, которая делает это возможным это виртуальный интерфейс. Виртуальный интерфейс является ссылкой на интерфейс (здесь мы имеем в виду SystemVerilog интерфейс). Мы можем написать класс, содержащий ссылки
к элементам внутри интерфейса, которых еще не существует (то есть, они не создаются). Когда создается экземпляр класса, виртуальный интерфейс подключается к реальному интерфейсу. Это делает возможным для объекта класса реагировать и отвечать на входные изменения. Модули SystemC реализованы в виде классов и позволяют входам быть в списке портов, обеспечивая такую же структуру.

В HDLs, таких как Verilog и VHDL, не хватает многих возможностей ООП, и, следовательно, не хорошо подходят для построения testbenches. Основной единицей программирования в большинстве HDLs является модуль, и это статический объект. Модули создаются в самом начале программы и сохраняются не измененными до завершения программы. Они синтаксически статические и это означает, что
средства для изменения модулей, создания другого варианта, ограничены. Verilog позволяет параметризовать скалярные значения, но не типы. Часто все сводятся к резке и вставке кода, а затем внесению локальных изменений. Если у вас есть десять различных вариаций нужных в конкретном проекте, необходимо вставить десять копий в соответствующие места, а затем локально изменить каждую из них.

== ООП и Верификация==

Создание объектно-ориентированных программ и создания testbench мало чем отличается. testbench представляет собой сеть взаимодействующих компонентов. ООП работает с определением и анализом сетей взаимодействующих объектов. Объекты могут быть связаны IS-A или HAS-A отношениями, и они общаются через интерфейсы.
ООП просто естественно вписывается проблему создания testbenches.

Языки, таких как SystemC / C + + и SystemVerilog, которые действительно поддерживают возможности ООП , лучше подходят для создания testbench, чем HDLs, такие как Verilog и VHDL. Используя динамические классы, параметризованные классы, наследование и параметризованные конструкторы, вы можете создать компоненты, которые являются гибкими, повторно используемыми и надежные. Потратив немного больше времени, чтобы построить универсальную компоненту, приведет вас приросту производительности, когда эта компонент повторно используется по-разному в разных местах.

Файл:60.png

2013-03-05T12:11:05Z

Anastasiya:

OVM/OVM методология/Основы объектно-ориентированного программирования

2013-03-05T12:10:45Z

Anastasiya:

{{OVM TOC}}
__TOC__

= =

Разработка программного обеспечения, не связанная с физикой электричества и магнетизма, уже давно пытается создать многократно используемые, взаимозаменяемые, надежные компоненты. Важной моделью программирования, которая решает проблему, называется объектно-ориентированным программированием (ООП). Основная идея ООП заключается в том, что программы организуются как набор взаимодействующих объектов, каждый со своим собственным областью данных и функций. Объекты могут быть многократно использованы, потому что они инкапсулируют все, что им нужно для работы, могут быть построены с минимальным числом или без внешних зависимостей, и может быть высоко параметризованы.
В этой главе вводятся основные понятия объектно-ориентированного программирования, в том числе понятия инкапсуляции и интерфейса. Глава завершается обсуждением того, почему ООП является важным для построения testbenches.

== Процедурные против ООП==

Чтобы понять ООП и его роль в проверке, необходимо сначала понять традиционное процедурное программирование и его ограничения. Это даст основу для понимания того, как ООП может преодолеть эти ограничения.
В первые дни языка ассемблера, программисты и компьютерные архитекторы быстро обнаружили, что программы часто содержат последовательности инструкций, которые повторяются во всей программе. Повторение кода (в частности, с перфокарт) является трудоемким и порождает ошибки. Чтобы избежать трудоемкости и ошибок, вызванных повторением последовательностей, была изобретена подпрограмма. Подпрограмма является единицей повторно используемого кода. Вместо кодирования той же последовательности встроенных инструкций, вы вызываете подпрограмму. Параметры, передаваемые в подпрограмму, позволяют динамически изменять код. То есть, каждый вызов подпрограммы с различными значениями параметров заставляет подпрограмму вести себя по-разному в зависимости от конкретных значений параметров.

Каждый язык программирования любой значимости имеет конструкции для создания подпрограмм, процедур и функций, а также синтаксис для передачи в них параметров и возвращаемых значений. Эти функции могут использоваться для создания операций, которые часто используются. Тем не менее, некоторые операции очень распространены (таких как I / O, преобразования данных, численные методы и т. д.). И во избежание переписывания этих операций, программисты посчитали необходимым создать библиотеки часто используемых функций. В результате, большинство языков программирования включает такие библиотеки как часть пакета компилятора. Одним из наиболее известных примеров является библиотека C, которая поступает с каждым компилятором C. Она содержит полезные функции, такие как printf() (), COS (), atof (), и QSort (). Эти функции практически каждый программист будет использовать в тот или иной момент.
Представьте себе, что писать собственные подпрограммы ввода / вывода или ваши собственные вычисления для преобразования чисел в строки и строк в числа. Был момент, когда программисты так и делали. Библиотеки универсальных функций все изменили и увеличили общую производительность программирования.

Как показывает практика программного обеспечения и передовых технологий, программисты начали думать на более высоком уровне абстракции, чем инструкции и процедуры. Вместо написания отдельных инструкций, программисты пишут код на языках, которые обеспечивают более высокую модель абстракции компьютера, и компиляторы или интерпретаторы переводят эти модели в конкретные инструкции. Библиотеки, такие как C библиотеки или STL в C + +, являются одной из форм абстракции. Они представляет собой набор функций, которые программисты могут использовать для создания все более сложных программы или абстракции.
В своей основополагающей книге Алгоритмы + Структуры данных = Программы, Никлаус Вирт объясняет, что для решения любой задачи программирования, вы должны разработать абстракцию реальности, которая имеет характеристики и свойства задачи, и игнорировать остальные детали. Он утверждает, что набор данных, которые вам нужны для решения проблемы, формирует абстракцию. Поэтому, прежде чем вы сможете решить проблема, в первую очередь необходимо определить, какие данные нужно иметь, чтобы создать решение.
Чтобы продолжить создание многократно используемой абстракции, мы должны создавать библиотеки данных объектов, которые могут быть многократно использованы для решения конкретных видов проблем. Поиск способа сделать это приводит к развитию объектно-ориентированных технологий.

Объектно-ориентированный анализ и проектирование программ сосредоточен вокруг данных объектов, функциональности, связанной с каждым объектом, и отношения между объектами.

Объектно-ориентированные языки предоставляют средства для отделения проблем программы, и выделения каждой из них независимо друг от друга, и для инкапсуляции данных абстракций и представление их через строго определенные интерфейсы. Полностью объектно-ориентированная программа строится путем разделения функциональности программы в различные классы, определения интерфейса для каждого класса, а затем установления связей и взаимодействий между компонентами через их интерфейсы.

==Классы и объекты==

Основным модулем программирования на объектно-ориентированных языках, таких как SystemVerilog, является класс. Класс содержит элементы данных, называемые членами, и задач и функций, называемых методами. Для выполнения объектно-ориентированных программ, вы должны создать один или более классов в основной программе, а затем вызвать методы на различных объектах. Хотя термины класс и объект иногда используются как синонимы, как правило, термин класс относится к классу декларации объекта, а термин объект относится к экземпляру класса.
Чтобы проиллюстрировать эти понятия, ниже приведен пример простой класс register.

[[Файл:27.png]]

[[Файл:28.png]]

Это очень простой класс с одной переменной, и двумя методами, read() и write(). Чтобы использовать этот класс, вы создаете объекты путем создания экземпляра класса, а затем вызвать методы объекта, как показано ниже

[[Файл:29.png]]

Локальный атрибут contents класса указывает компилятору строго соблюдать границы класса. Если вы пытаетесь получить доступ к contents напрямую, компилятор выдаст ошибку. Вы можете получить доступ к содержимому через доступные функции чтения и записи. Этот вид контроля доступа важен для гарантирования независимости от внутренностей класса и тем самым делает класс многократно используемым.
Вы можете использовать классы для создания новых типов данных, таких, как наш простой register. Использование классов для создания новых типов данных является важной частью ООП. Вы можете также использовать их для инкапсуляции математических вычислений или создания динамических структур данных, таких как стеки, списки, очереди, и так далее. Инкапсуляция организации структур данных или сведений о вычислениях в классе делает структуру данных или вычислений многократно используемыми.
В качестве более полного примера, давайте посмотрим на полезный тип данных, стек. Стек - это LIFO ("последним пришёл - первым обслужен") структура. Элементы помещаются в стек командой push(), а извлекаются из стека pop(). Pop () возвращает последний элемент, помещенный в стек, и удаляет его из структуры данных. Внутренние элемент stkptr следит за вершиной стека. Элемент, на который он указывает, это вершина стека, а все, что ниже его (то есть, с меньшим индексом) ниже в стеке. Ниже приведена базовая реализация стека в SystemVerilog

[[Файл:30.png]]

[[Файл:31.png]]

[[Файл:32.png]]

[[Файл:33.png]]

Класс stack инкапсулирует все, что нужно знать о стеке данных структуры. Он содержит интерфейс и реализацию интерфейса. Интерфейс – это набор методов, которые используются для взаимодействия с классом. Реализация - это код, который заставляет класс работать. Интерфейс нашего стека содержит следующие методы:

[[Файл:34.png]]

Не существует другого способа взаимодействия со стеком, как с помощью этих методов. Есть также два элемента данных класса, stk и stkptr, которые представляют фактическую структуру стека. Тем не менее, эти два элемента локальные, что означает, что компилятор запретит любые попытки доступа к ним за пределами класса. Для предотвращения доступа к внутренней структуре данных извне, мы можем сделать некоторые гарантии о состоянии данных. Например, Push () и Pop () могут рассчитывать на то, что stkptr корректно и указывает на вершину стека. Если бы можно было изменить значение stkptr иными средствами, чем с помощью интерфейса функций, тогда Push () и Pop () пришлось бы прибегнуть к дополнительным затратам и возможностям для ненадежной проверки истинности stkptr.
Реализация интерфейса встроенная. Объявление класса содержит не только определение интерфейса, а также реализацию каждой функции интерфейса. Оба C + + и SystemVerilog позволяют отделить реализацию от интерфейса. Разделение интерфейса и реализации является важной концепцией. Программисты, пишущие на C + +, могут использовать файлы заголовков для ввода интерфейс и. куб (или. срр или любой другой компилятор использует) для реализации.

Есть некоторые важные явления доступа через класс интерфейсов. Одним из них является возможность многократного использования. Мы можем удобно использовать классы, интерфейсы которых четко определены и хорошо объяснены, чем те, чьи интерфейсы нечеткие. Другим важным явлением обеспечения доступа через класс интерфейсов является надежность. Авторы класса может гарантировать определенную инвариантность (например, stkptr меньше, чем размер имеющегося массива STK) когда они знают, что пользователи не будут изменять данные иначе, чем предоставляемыми средствами. Кроме того, пользователи могут ожидать, что состояние объекта будет предсказуемым, когда они придерживаются интерфейса. Ясность другое явление. Интерфейс может описать всю семантику класса. Объект не будет делать ничего другого, чем выполнять операции, доступные через интерфейс. Это делает проще понять для тех, кто использует класс, что именно он будет делать.

== Отношения между объектами ==

Истинная сила ООП становится очевидной, когда объекты взаимосвязаны различными отношениями. Есть много видов отношений, которые возможны. Мы рассмотрим два из наиболее фундаментальных отношений HAS-A и IS-A.

=== HAS-A ===

HAS-A относится к концепции, когда один объект содержится или принадлежит другим. В нашем классе стека, например, HAS-A указатель стека (stkptr) и массив стека. Это примитивные типы данных, а не классы, но применяется тоже понятие HAS-A. В
SystemVerilog вы можете создать HAS-отношения между классами с ссылками или указателями. На рисунке ниже показаны основные памяти модель для HAS-А отношений. Объект А содержит ссылку или указатель на Объект B.

[[Файл:35.png]]

Unified Modeling Language (UML) является графическим языком для представления систем, в частности, отношения между объектами в этих системах. UML для HAS-связи выражается линией между объектами и закрашенным ромбиком(??????), как показано на рисунке ниже.

[[Файл:36.png]]

Объект А принадлежит экземпляру объекта B. кодирование HAS-А отношений в
SystemVerilog заключается в включении одного класса в другой или других способов предоставления доступа одного класса к одному классу, который хранится внутри.

[[Файл:37.png]]

Класс А содержит ссылку на класс B. конструктор для класса A, метод new(), вызывает new() в классе B, чтобы создать его экземпляр. Член b содержит ссылку на вновь созданный экземпляр B.

=== IS-A ===

IS-А отношения чаще всего называют наследованием. Новый класс является производным от ранее существующего класса и наследует его характеристики. Объекты, созданные с наследованием наследования, созданы с использованием отношения IS-A. Производный класс является подклассом или более специализированная версия родительского объекта. Для иллюстрации понятия наследования, рисунок 2-3 использует часть систематики млекопитающих.

[[Файл:38.png]]

Животные, которые являются членами китообразных, хищных, приматов - млекопитающие. Эти очень разные виды существ имеют общие черты млекопитающих. Тем не менее, у китообразных (киты, дельфины), плотоядных (собак, медведей, енотов), и приматов (обезьян, людей), у каждого есть свои четкие и безошибочные характеристики. Для использования ОО терминологии, медведь - хищник и плотоядный IS- А млекопитающего. Иными словами, медведь состоит из атрибутов и плотоядные млекопитающие и плюс, дополнительные атрибуты, отличающие его от других плотоядных животных.

Для представления IS-A на языке UML, мы рисуем линию между объектами с открытыми стрелками, указывающие на базовый класс. Традиционно, мы изображаем базовый класс выше производных классов, а стрелки указывают вверх, образуя дерево наследования (или ориентированный ациклический граф, который может быть реализован в языках, таких как C + +, которые поддерживают множественное наследование).

[[Файл:39.png]]

При представлении двух объектов в компьютерной программе с использованием наследования, новый производный объект содержит характеристики родителей и обычно включает в себя дополнительные характеристики. На рисунке ниже показана базовая модель памяти для IS-А композиции. В этом примере класс B является производным от А.

[[Файл:40.png]]

SystemVerilog использует ключевое слово extends на определения наследования между классами:

[[Файл:41.png]]

Класс B получена из A, поэтому он содержит все атрибуты A. Любой экземпляр B не только содержит строку S, но и объект с плавающей запятой F и целое i.

== Виртуальные функции и полиморфизм ==

Одной из причин для создания объектов, используя наследование, является определение различного поведения для той же операции. Другими словами, поведение, определенное в производном классе переопределяет поведение, определенное в базовом классе. Это можно сделать, используя виртуальные функции. Виртуальная функция – функция, которую можно переопределить в производном классе. Рассмотрим следующий универсальный пакет класса.

[[Файл:42.png]]

[[Файл:43.png]]

Она имеет три виртуальных функций, чтобы установить содержимое пакета. Различные виды пакетов, требуют различного содержания. Мы используем generic_packet как базовый класс и получают различные виды пакетов из него.

[[Файл:44.png]]

Оба packet_A и packet_B могут иметь различные заголовки и трейлеры и различные форматы полезной нагрузки. Информация о том, как части пакета отформатированы, хранится локально внутри производных классов пакета. Виртуальные функции set_header (), set_trailer (), и set_body () реализованы по-разному в каждом подклассе основываясь на типе пакета. Базовый класс generic_packet устанавливает организацию классов и типы операций, которые возможны, и производные классы могут изменить поведение этих операций.

Виртуальные функции используются для поддержки полиморфизма: несколько классов, которые могут быть использованы как взаимозаменяемые, каждый с разным поведением. Например, некоторая обработка пакетов не нуждается в информации о том, какой пакет обрабатывается. Единственной необходимой информацией является то, что объект действительно пакет, то есть, он является производным от базового класса. Еще один способ показать, что пакет является предком базового класса - это через IS-A отношения. Виртуальные функции являются механизмом, с помощью которого мы можем переопределять
поведение для различных вариантов пакетов.

Чтобы посмотреть немного глубже, как работают виртуальные функции, давайте рассмотрим три класса, связанных друг с другом IS-А отношением.

[[Файл:45.png]]

figure является базовым классом; polygon является производным от figure; square происходит от polygon. Каждый класс имеет две функции, draw(), которая является виртуальной, и compute_area (), которая не является виртуальной. Следующий пример показывает, SystemVerilog код:

[[Файл:46.png]]

[[Файл:47.png]]

Каждая функция выводит его полное имя в виде class_name :: имя_функции. Мы можем написать простую программу, которая показывает, как виртуальные функции связаны.

[[Файл:48.png]]

Ниже показано, что происходит, когда мы запускаем эту программу:

[[Файл:49.png]]

Сначала мы создаем s, квадрат, а затем назначаем его на f и р. базовым классом для square является polygon и базовым классом polygon - figure. Из напечатанного вывода, мы можем заключить, что функции связаны в соответствии со следующей таблице:

[[Файл:50.png]]

Во всех случаях, compute_area () была связана с конкретным compute_area () функцией с типом ссылки, которая ее определяет -р ссылки на polygon, таким образом связаны polygon :: compute_area (). Так как compute_area () не является виртуальной функцией. Компилятор может легко определить, какие версии функций вызывать, основываясь на типе объекта.

Так как draw() является виртуальной, не всегда возможно для компилятора определить, какую функцию вызывать. Решение принимается на этапе выполнения с помощью
виртуальной таблицы, таблицы привязки функций. Виртуальная таблица используется для привязки функций, привязка не может быть полностью определена во время компиляции.

Обратите внимание, что хотя р представляет собой polygon, вызов p.draw () приводит к square::draw() вызывается не polygon::draw(), как вы могли бы ожидать.
То же самое происходит и с F-f.draw () связан с кsquare::draw().
объект, который мы первоначально создан представляет собой square, он поддерживает различные типы операций но, то, что это square не забывается. Это работает только потому, что square является производным от polygon, который в свою очередь является производным figure, и потому draw() объявлен как виртуальный. Ошибка компиляции О несовместимости типа возникает при попытке присвоить ей к s
и p так как с не получено от р.

== Универсальное программирование==

Напомним, что объектно-ориентированные языки обладают средствами для разделения программ на задачи и рассмотрения их отдельно. Импликация отдельных задач заключается в том, что каждая задача представлена один раз. Дублирование кода нарушает принцип. На практике, многие задачи очень схожи, и имеют похожее решение, но не идентичное. Интуитивно, мы хотим написать код, который может быть использован во многих ситуациях. Это интуиция подводит нас к написанию универсального кода, кода, который высоко параметризованный, так что он может быть легко использован в самых разнообразных ситуациях.

Подробная информация об универсальном коде поставляется во время компиляции или во время выполнения вместо жесткого кодирования. Любой код, который имеет параметры, такие как вызов функций, может, считается универсальным, но этот термин обычно используется для кода с использованием шаблонов (в C + +) или параметризованные классы (в SystemVerilog). Написание универсальных программ согласуется с целью ООП о разделении задач. Таким образом, ООП языки обеспечивают условия для создания универсального кода.

Параметризованный класс – это класс, который (очевидно) имеет параметры. В синтаксисе SystemVerilog для определения параметров используется знак # в заголовке класса, после следует список параметров в скобках. В качестве примера, рассмотрим следующий параметризованный класс:

<source lang="cpp">class param #(type T=int, int R=16);
endclass</source>

Этот класс имеет два параметра, T, который является фиктивным параметром и R, который является целочисленным параметром. Экземпляры параметризованных классов с определенными значениями параметров создают специализации, то есть версии кода с примененными параметрами.

<source lang="cpp">param #(real, 29) z;
param #(int unsigned, 12) q;</source>

Приведенные выше объявления создают специализации параметризованного класса
param. Имя класса и параметры определяют специализацию. Таким образом,
специализации, по сути, уникальные типы. Компилятор не позволит вам присвоить q к z, или наоборот, потому что они являются объектами различных типов.

Параметр type позволяет писать типа-независимый код, код, данные и алгоритмы которого могут работать с широким спектром типов данных. Например:

<source lang="cpp">class maximizer #(type T=int);
function T max(T a, T b);
if( a > b )
return a;
else
return b;
endfunction
endclass</source>

Параметризованный класс maximizer имеет функцию max(), которая возвращает
максимальное из двух значений. Алгоритм max() такой же, независимо от типа сравнения объектов. В этом случае, единственным ограничением является то, что объекты должны быть сравнимы оператором больше чем (>).
Классы не могут сравниваться с использованием оператора большего чем, поэтому другая версия maximizer должна работать с классами. Для создания версии maximizer, которая будет возвращать больший из двух классов, мы должны определить метод в каждом классе, который будет сравнивать объекты.

<source lang="cpp">class maximizer #(type T=int);
function T max( T a, T b);
if( a.comp(b) > 0 )
return a;
else
return b;
endfunction
endclass</source>

Это предполагает, что параметр T типа type действительно класс, а не встроенного тип, такие как int или real. Кроме того, он предполагает, что T имеет функцию под названием Comp (), которая используется для сравнения себя с другим экземпляром. Библиотека OVM содержит параметризованный компонент, называемый ovm_in_order_comparator # (T), который используется для сравнения потоков операций. Она имеет два варианта, один для сравнения потоков встроенных типов, и один для сравнения потоков классов. Причина необходимости двух компараторов в том, что SystemVerilog не поддерживает операторы, которые могут работать и с классами и со встроенными типами.

=== Универсальный стек ===

Наш стек не особенно универсальный. Она имеет фиксированный размер 20, а
тип данных элементов хранящихся в стеке Int. Ниже приводится более общий вид стека, который изменяет эти фиксированные характеристики параметризованными.

<source lang="cpp">53 class stack #(type T = int);
54
55 local T stk[];
56 local int stkptr;
57 local int size;
58 local int tp;
59
60 function new(int s = 20);
61 size = s;
62 stk = new [size];
63 clear();
64 endfunction
65
66 function bit pop(output T data);
67
68 if(is_empty())
69 return 0;
70
71 data = stk[stkptr];
72 stkptr = stkptr - 1;
73 return 1;
74
75 endfunction
76
77 function bit push(T data);
78
79 if(is_full())
80 return 0;
81
82 stkptr = stkptr + 1;
83 stk[stkptr] = data;
84 return 1;
85
86 endfunction
87
88 function bit is_full();
89 return stkptr >= (size - 1);
90 endfunction
91
92 function bit is_empty();
93 return stkptr < 0;
94 endfunction
95
96 function void clear();
97 stkptr = -1;
98 tp = stkptr;
99 endfunction
100
101 function void traverse_init();
102 tp = stkptr;
103 endfunction
104
105 function int traverse_next(output T t);
106 if(tp < 0)
107 return 0; // failure
108
109 t = stk[tp];
110 tp = tp - 1;
111 return 1;
112
113 endfunction
114
115 virtual function void print(input T t);
116 $display(“print is unimplemented”);
117 endfunction
118
119 function void dump();
120
121 T t;
122
123 $write(“stack:”);
124 if(is_empty()) begin
125 $display(“<empty>”);
126 return;
127 end
128
129 traverse_init();
130
131 while(traverse_next(t)) begin
132 print(t);
133 end
134 $display();
135
136 endfunction
137
138 endclass
file: 02_intro_to_OOP/02_generic_stack/stack.sv</source>

Универсальный класс stack параметризован типом объектов стека.
Параметр T содержит тип. В этом случае T может быть либо классом или встроенным
типом. В любом месте класса, где мы ранее использовали Int как тип стека, теперь мы используем Т. Например, push() теперь принимает аргумент типа T. Параметры класса,
такие как T, устанавливаются во время компиляции. Для специализации stack#(T), мы инициализируем его с определенным значением для данного типа. Например:

<source lang="cpp">stack #(real) real_stack;</source>

Этот оператор создает специализацию stack, который использует real, как тип объектов стека.
Размер стека больше не зафиксирована на уровне 20. Мы используем динамический массив для хранения стека, размер которого указан в качестве параметра конструктора. В отличие от T, аргумент size задается при выполнении программы. Это позволяет нам создать несколько стеков, каждый с разным размером.

<source lang="cpp">stack #(real) big_stack;
stack #(real) little_stack;
...
big_stack = new(2048);
little_stack = new(6);</source>

big_stack и little_stack одного типа. Они используют одну и ту же специализацию stack#(T). Тем не менее, каждый из них создается с различными параметрами размера.

В процессе создания универсального стека, мы сделали еще одно изменение. Мы заменили dump() на traverse_init () и traverse_next (). dump() зависит от типа элементов стека, которые не известны до компиляции. Мы должны иметь возможность пройти по стеку и отформатировать каждый элемент, не зависимо от типа элемента. Это может быть INT, или это может быть сложный класс с несколькими членами. Чтобы сохранить stack#(T) универсальным, мы должны исключить любую зависимость от типа элементов стека.

В то время как dump() пробежит по всем элементам стека и напечатает их в определенном порядке, traverse_init () устанавливает внутренний указатель(tp) на вершину стека, а traverse_next () возвращает текущий элемент и уменьшает tp. Стек поддерживает некоторую статическую информацию обхода. Статическая информация сбрасывается, когда вызывается traverse_init ().

== Классы и Модули==

Интересно, что HDLs, такие как Verilog и VHDL, хотя они не считаются объектно-ориентированными языками, строятся на концепции очень схожей классам и объектам. Модули в Verilog, например, являются объектами, каждый из которых имеет
свое собственное пространство данных и набор задач и функций. Так же, как объекты в ОО программах, каждый экземпляр модуля является независимой копией. Все экземпляры имеют один и тот же набор задач и функций и те же интерфейсы, но данные содержащихся внутри каждого является независимым от всех остальных экземпляров. Модули контролируются их интерфейсами. Verilog модули не поддерживают наследование или параметризации типов, и они являются статическими, что делает их непригодными для истинного ООП.

Сходство между классами и модулями открывает возможность для нас использовать объекты класса в аппаратном контексте. Мы можем создать компоненты верификации как экземпляры классов, что дает нам гибкость при подключении к аппаратным элементам. Дизайнеры SystemVerilog выигрывают при расширении Verilog классами, предоставляя возможность для классов работать как модули.

В приведенной ниже таблице сравниваются особенности классов в Verilog, SystemVerilog, и C + +.

OVM/OVM методология/Основы объектно-ориентированного программирования

2013-03-04T13:33:45Z

Anastasiya:

OVM/OVM методология/Основы объектно-ориентированного программирования

2013-03-04T13:13:17Z

Anastasiya: