Версия 00:31, 27 марта 2013

Основы 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

Основной цикл состоит из двух под-циклов, цикл записи и чтения цикла. Цикл записи генерирует случайное число для операций записи. Для каждой записи, он генерирует случайное значение данных, которые хранятся как в очереди ссылок (refq) и помещает его в объект запроса. Transport() отправляет запрос в канал запросов и блокируется, пока ответ не доступен. Цикл чтения считывает те же адреса в том же порядке и сравнивает каждое считанное значение со значением в очереди ссылок. Если есть несоответствие, то подается сигнал об ошибке. Основной цикл из memory slave получает каждый запрос, декодирует его, обрабатывает его и выдает ответ.

50 forever begin
51 slave_port.get(req);
52 assert($cast(rsp, req.clone()));
53
54 addr = req.get_addr();
55 if(req.is_read()) begin
56 data = m.read(addr);
57 rsp.set_rdata(data);
58 end
59 else begin
60 data = req.get_wdata();
61 m.write(addr, data);
62 end
63
64 slave_port.put(rsp);
65 #1;
66 end
67 endtask

Обратите внимание, что ведомый использует бесконечный цикл, в то время, как мастер имеет ограниченный цикл. Ведомый не имеет возможности узнать наперед сколько запросов будет обрабатывать. Мастер - тот кто определяет, сколько запросов будет обработано. Чтобы отправить ответ, мы создаем объект ответа, сделав точную копию запроса с помощью функция clone(), а затем если нужно заменяем в ответе поля. Этот тип событий представляет собой ссылки, когда объекты запроса и ответа имеют одинаковые типы, как в данном случае. Простое представление приемник-передатчка как генератор воздействий и драйвер есть общая идиома для OVM testbenches. Самым простым решением является прямая подачи из генератора воздействий, который посылает операций для управления пакетами в драйвере. Более сложные механизмы включают такие вещи, как несколько последовательностей работающих параллельно через (обрабочик событий)sequencer драйвера. Во всех этих случаях идея та же: один или несколько элементов тестбенча порождают операций и, возможно, (имеют возможность) получить ответы из подключенных драйверов. Драйвер преобразует поток транзакций на уровень переключений на контактах.

5.2 Введение в HFPB (Harry Foster peripheral bus)

В этой и следующей главе нескольких главах, мы проиллюстрируем построение тестбенча с использованием простого, не конвейерного протокола шины, который называют протоколом HFPB. HFPB является аббревиатурой, что расшифровывается как Гарри Фостер периферийная шина, которая названа в честь Гарри Фостера, который первый предложил этот формат. Гарри черпал вдохновение для протокола из AMBA ARM-APB протокола. В таблице ниже приводится краткая информация о шине сигналы для нашего простого примера nonpipelined шины.