OVM/OVM методология/Механика OVM/4.7 — различия между версиями

Версия 17:04, 22 марта 2013

4.7 Подключение тестбенча к hardware

В конечном счете, все компоненты на основе классов должны быть подключены к RTL оборудованию. SystemVerilog предоставляет интерфейсы для подключения аппаратных объектов без того, чтобы это сделать как подключение контакт к контакту. Оборудование, в данном случае, означает, RTL компоненту представлены с использованием Verilog модулей. Язык также обеспечивает виртуальные интерфейсы как средство на основе классов объектов для подключения к RTL компонентов. По сути, виртуальный интерфейс является указатель (ссылку) на интерфейс.

Для соединения тетсбенча и компонентов аппаратуры на основе класса, необходимо подключить интерфейс аппаратуры, а затем поместить(обвернуть) виртуальный интерфейс в classbased окружение. Ниже приведен пример интерфейс уровня подключения. Это интерфейс памяти, который имеет адрес (address), выходные данные (wr_data), входных данных (rd_data), вход, который выбирает данные направления (RW), контакты запроса и авторизации (REQ и ACK), контакт сброса (RST), индикатор ошибки (ERR), и, конечно, тактовый сигнал (CLK).

25 interface pin_if (input clk);
26 bit [15:0] address;
27 bit [7:0] wr_data;
28 bit [7:0] rd_data;
29 bit rst;
30 bit rw;
31 bit req;
32 bit ack;
33 bit err;
34
35 modport master_mp(
36 input clk,
37 input rst,
38 output address,
39 output wr_data,
40 input rd_data,
41 output req,
42 output rw,
43 input ack,
44 input err );
45
46 modport slave_mp(
47 input clk,
48 input rst,
49 input address,
50 input wr_data,
51 output rd_data,
52 input req,
53 input rw,
54 output ack,
55 output err );
56
57 modport monitor_mp(
58 input clk,
59 input rst,
60 input address,
61 input wr_data,
62 input rd_data,
63 input req,
64 input rw ,
65 input ack,
66 input err );
67 endinterface
file: 04_OVM_mechanics/10_vif/top.sv

Интерфейс состоит из нескольких частей. Мы рассмотрим их по отдельности. Первая часть заголовка, который определяет имя интерфейса, в данном случае pin_if. Чуть ниже, что является набором контактов, которые служат для внешнего наблюдения за оборудованием. В остальном конструкция интерфейса содержит декларацию трех modports. Каждый modport представляет собой вид комплект контактов. В нашем примере, каждый modport содержит набор всех контактов, но с разными направления сигналов. Мастер modport управляет операциями на шине: входами address, wr_data, REQ, RW и всеми выходами. Устройство, которое использует этот modport будет управлять этими контакты. На остальных устройствах все сигналы входные. Ведомые устройства используют управляемый modport, сигналами на котором управляет расположенный напротив master. Устройства наблюдения являются пассивными и не управляют никакими сигналами. Все их сигналы являются входами. Путем подбора соответствующих modport для любого устройства, мы можем легко установить направление всех сигналов и гарантировать согласованность всех устройств, подключенных к шине. В верхнем уровне модуля мы статически создадим экземпляр тактового генератора, интерфейса и DUT'а.

150 module top;
151
152 clkgen ck(clk);
153 pin_if pif(clk);
154 dut d(pif.slave_mp);
155
156 env e;
157
158 initial begin
159 e = new(“env”);
160 e.set_vif(pif.master_mp);
161 run_test();
162 end
163
164 endmodule
file: 04_OVM_mechanics/10_vif/top.sv

Initial block динамически создает экземпляр класса тестового окружения, передает заголовок интерфейса (иначе известная, как виртуальный интерфейс) в только что созданного окружения(тестового), и запускается тест. Обратите внимание, что slave modport передается в DUT. Это уместно, поскольку DUT это управляемая память. Мастер modport передается в тестовое окружение и в конечном счете управляет сигналами. Среда хранит виртуальный интерфейс и передает его в любой из подчиненных компонентов, которые могут в ней нуждается.