OVM/OVM методология/Основы Testbench

Ссылки сюда (29) →

Основы Testbench

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

5.1 драйвера и мониторы

Два из наиболее фундаментальных объектов в тестбенчах являются драйвера и мониторы. Драйвер преобразует поток операций в переключения на выводе на уровне интерфейса. Монитор делает обратное, он преобразует переключения на уровне контактного интерфейса в поток операций. Драйверы используются для управления DUT путем применения воздействий, а в мониторы используются для наблюдения за ответами. Чтобы понять, как создавать и использовать драйверы и мониторов, мы начнем пример с уровня транзакций, который иллюстрирует генератор воздействий (memory master) связанный с управляемой памятью. Управляемая память находится напротив драйвера. В то время как истинный драйвер имеет пин-уровень связи, управляемая память его не имеет. Чтобы управляемая память и драйверы были вместе, их интерфейсы обмена интерфейсов и их архитектуры тоже вместе (объединены). После построения понимания на уровне транзакций, например, мы будем расширять его использование на контактный уровень общения, обмена. В memory master генерирует поток запросов операций(транзакций) и отправляет их через транспортный канал в memory slave. Ведомый обрабатывает каждый запрос и формирует ответ, который он посылает обратно к ведущему через транспортный канал.

Во-первых, давайте посмотрим на канал связи из этого примера, то есть через что происходит соединения и передача потоков данных между компонентами. Транспортный канал состоит из двух противоположных FIFO, один для запросов и один для ответов и транспортного интерфейса. Memory master подключается к транспортному интерфейсу канала. Как вы, возможно, помните из раздела 3.4.3, транспортный интерфейс позволяет гарантировать memory master, что запросы и ответы будут синхронизированы. Ведомый интерфейс, как следует из названия, предназначена для устройств, которые должны отвечать на запросы, в то время, транспортный интерфейс для устройств, которые генерируют запросы.

Memory master использует свой порт для повторного вызова функции transport(), которая вызывает запрос на посылку запроса в FIFO транспортный канал. transport() также блокируется, пока ответ доступен. Ведомый вызывает функцию get(), которая извлекает запрос, затем обрабатывает его, генерирует ответ, и посылает ответ обратно в FIFO используя put(). Наконец, функция transport(), которая была в состоянии ожидания ответа, теперь может вернуть ответ memory master.

Основной цикл master'a содержит тесты самоконтроля. Это порождает ряд записей в памятью и сохранение тех, кто записывает ссылку в очередь. Затем происходит считывание из всех ячеек памяти только то, что было записано, и сравниваются каждое считанное значение с стоящими в очереди.

62 for(int i = 0; i < bursts; i++) begin
63 req = new();
64
65 addr = $random & addr_mask;
66 size = ($random & ‘h1f) +1; // size > 0 && size <= 32
67
68 // write loop
69 for(j = 0; j < size; j++) begin
70 req.set_addr(addr);
71 data = $random & data_mask;
72 refq.push_back(data);
73 req.set_wdata(data);
74 req.set_write();
75 req.set_slave_id(0);
76 transport_port.transport(req,rsp);
77 // ignore response
78 addr++;
79 #0;
80 end
81
82 // read loop
83 addr -= size;
84 for(j = 0; j < size; j++) begin
85 req.set_addr(addr);
86 req.set_wdata(0);
87 req.set_read();
88 req.set_slave_id(0);
89 transport_port.transport(req,rsp);
90 data = rsp.get_rdata();
91 refd = refq.pop_front();
92 if(data != refd) begin
93 $sformat(s, “data mismatch: %x != %x”,
94 data, refd);
95 ovm_report_error(“compare”, s);
96 end
97 addr++;
98 #0;
99 end
100 end