Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Языки VHDL и VERILOG в проектировании цифровой аппаратуры
.pdf
Глава 4. Функциональная верификация HDL-описаний 91
Тестирующая программа (testbench)
VHDL VERILOG
entity TB_F is module NOT_STRUCT_TB ();
-- у теста порты отсутствуют
end TB_F;
USE STD.TEXTIO.all;-- ввод-вывод
architecture NOT_STRUCT_TB of TB_F is
component F port
(A1, A2: in bit; B1, B2: out bit);
end component;
signal I1, I2, O1, O2: bit; reg I1, I2;
begin wire O1,O2;
GEN_V1 :process begin initial begin :GEN_V1
I1<='0'; I2<='0' ; I1=0;I2=0;
wait for 10 ns; I1<='1'; #10; I1=1;
wait for 20 ns; I1<= '0' ; I2<='1'; #20; I1=0;I2=1;
wait for 10 ns; I1<='1' ; #10; I1=1;
wait for 10 ns; #10;
wait; -- бесконечное ожидание $finish;//останов модели
end process GEN_V1; end// GEN_V1
-- ниже связи компонент объекта TB_F
C2: F port map (I1, I2, O1, O2); F_CASE C2 (I1, I2, O1, O2);
WRITER1 : process (O1,O2) always @(O1 or O2);
variable L:LINE;-- из пакета TEXTIO
begin begin :WRITER1
write (L,NOW); $display("t=%t",$time);
$display("I1=%bI2=%b",I1,I2);
write (L,I1); write (L,I2);
write (L,O1); write (L,O2); $display("O1=%b",O1);
$display("O2=%b",O2);
writeline (output,L);
end process; end //WRITER1
end NOT_STRUCT_TB; endmodule //NOT_ STRUCT_TB
B VHDL-описании процесса вывода WRITER_1 использован стандартный пакет TEXTIO, содержащий декларацию текстового файла OUTPUT и стандартную
процедуру записи строки WRITELINE. Каждый раз, когда один из сигналов (O1
или O2) изменяет свое значение, процесс запускается и выполняет оператор записи значений модельного времени NOW и значений сигналов I1, I2, O1, O2 в стандартный текстовый файл OUTPUT.
B VERILOG-описании первый оператор форматируемого вывода $display выводит время, второй — значения входных сигналов, третий и четвертый выводят
значения выходов.
Обратите внимание на останов моделирования в момент времени 50 наносекунд.
В VHDL-модели процесс GEN_V1 попадает в оператор wait — вариант
безусловного ожидания — и зависает в нем. В модели пропадает источник
событий.
В VERILOG системный оператор $finish останавливает моделирование.
92 Глава 4. Функциональная верификация HDL-описаний
VHDL-описание объекта проекта TB_F для модельного эксперимента можно
не дополнять конфигурационным описанием, так как имя компоненты F совпадает в нашем случае с именем объекта проекта F (когда оно совпадает, то конфигурирование происходит по умолчанию).
На рис. 4.4 представлен экран системы моделирования ACTIVE_HDL после
прогона VHDL-модели TB_F.
В нижней части экрана видны результаты вывода на консоль значений сигналов и моментов времени, когда выходы объекта проекта F изменялись.
В левой верхней части экрана видны временные диаграммы сигналов.
Справа виден состав файлов и библиотек проекта. По результатам печати и
временным диаграммам видно, что поведение моделируемого объекта совпадает с
его табличной спецификацией.
Heтрудно ввести в тестирующую программу модуль автоматического сравнения выходных сигналов с эталоном, например с файлом, содержащим исходную
таблицу (см. рис. 4.1), использованную при проектировании объекта F. Можно
улучшить описание TB_F за счет его структуризации путем выделения в отдельные модули генератора входных сигналов и блока вывода (это упростит в дальнейшем их повторное использование и модификацию), вместо константных значений
использовать параметры или именованные константы (упрощение проведения экспериментов на различных частотах) и т. д. Эти вопросы будут рассмотрены позднее. Сначала рассмотрим вопросы полноты тестов.
Рис. 4.4. Экран системы моделирования
Глава 4. Функциональная верификация HDL-описаний 93
4.2. Стратегия функциональной верификации
4.2.1. Типы тестов
Для проверки правильности функционирования проектируемых систем в
основном используются методы детерминистского (deterministic), случайного (random) и транзакционного (transaction level) тестирования.
Детерминистский тест проверяет обычные режимы работы системы, а также
ее функционирование в граничных условиях c помощью фиксированного набора
входных воздействий.
Метод случайного тестирования предполагает наличие генератора случайных
входных воздействий.
Метод транзакционного тестирования предполагает фиксацию внимания на
проверке интерфейсов блоков системы и проверке прохождения пакетов данных
через нее.
Различают тестирование объекта как:
— «черного ящика» — инженер-верификатор при разработке теста не использует знаний о внутренней организации описания объекта;
— «серого ящика» — инженер-верификатор частично использует знание внутренней организации описания объекта;
— «прозрачного ящика» — инженер-верификатор базируется на знании внутренней структуры описания объекта.
4.2.2. Полнота теста
Целью процесса верификации проекта является проверка его соответствия
спецификации на всех уровнях проектирования.
Имитационная верификация — трудоемкий процесс. Обычно в реальных
случаях полный перебор невозможен (например, для такой проверки 16-разрядного сумматора требуется пeребрать 2
ченное множество входных наборов теста. Например, для того же сумматора сначала при тестировании его как «серого ящика» проверяют простейшие случаи
(0+0=0,2+2=4,11111111111+0,0+ 111111111111 и т. п.), затем пробег переносов (111111111+1,1+111111111 и т. д.) а затем, рассматривая его как «черный
ящик», используют выборку из случайных чисел.
Требуется оценить полноту таких тестов с учетом минимизации цены тестирования и максимизации вероятности обнаружения возможных ошибок в проекте.
32
степени наборов!) и используется ограни-
4.3. Оценка полноты функциональных тестов
4.3.1. Эвристические метрики
Эвристические метрики основаны на текущей статистике обнаружения ошибок в проекте. Подобные метрики включают:
— календарное время между моментами обнаружения ошибок проекта (к кон
цу процесса верификации оно увеличивается);
-
94 Глава 4. Функциональная верификация HDL-описаний
— общее количество промоделированных тактов работы проектируемого
устройства;
— общее число обнаруженных ошибок в проекте и т. д.
В свое время, когда автор работал в компании Raycer Graphics над проектом
мощного профессионального графического ускорителя, состоящего из трех функциональных блоков-кристаллов, шеф верификационной команды Рик Авра (Rick
Avra) оценил вероятное число ошибок в 3000, и, когда этот рубеж был достигнут в
условиях успешной работы всех трех RTL-моделей блоков на сотнях тестов (от
изображения простого голубого треугольника до изображений автомобиля с текстуровкой, тенями и полутонами), все вздохнули с облегчением. Психологический
барьер был пройден и стал виден конец работы, так как темп обнаружения ошибок коллективом из десятков человек стал менее одной ошибки в день. Однако
такие метрики весьма необъективны, и возможно, что часть функций проектируемого устройства осталась бы неверифицированной.
4.3.2. Программные метрики
В настоящее время большинство коммерческих систем оценки полноты функциональных тестов COVERSCAN, COVERMETER и т. п., а также развитые системы моделирования типа SILOS, ACTIVE-HDL, MODELSIM, VSS базируются
на метриках, используемых для верификации программ (программо-метрический
подход).
В числе таких метрик можно указать, например, такие:
— полнота покрытия тестом строк кода модели — количество исполнений
каждой строки описания;
— полнота покрытия переходов — число исполнений ветвей операторов if и
case;
— полнота покрытия путей — число исполнений всех возможных путей в графе программы;
— полнота покрытия выражений — низкоуровневая метрика, основанная на
оценке числа вычислений выражений на различных наборах данных;
— полнота переключений (0 ->1 и 1 ->0) каждого бита данных.
Пример подобных статистических данных, получаемых системой SILOS-demo
при прогоне VERILOG-варианта вышеприведенного теста описания объекта проекта F, представлен на рис. 4.5. Видно, что все строки кода тест-программы исполнялись, однако тест представляется неполным, так как выход В2 не перебрасывался из1в0,аB1из0в1.
Ясно, что, если после прогона теста собранная статистика говорит, что часть
операторов модели вообще ни разу не исполнялась или некоторые сигналы ни
разу не переключались, имеет смысл попытаться понять причину этого явления и
при необходимости дополнить тест. Несмотря на очевидную полезность и объективность этих метрик, никто не может гарантировать, что достижение, допустим,
100% покрытия тестом программного кода позволяет обнаружить все ошибки
проекта устройства.
Следует вспомнить о понятиях управляемости (controllability) и наблюдаемости (observability) тестируемых объектов и их блоков. То, что тест создал условия,
когда некоторая строка кода (оператор) исполняется (управляемость), не гаранти
рует, что результат этого исполнения будет влиять на выход моделируемой схемы
(наблюдаться на выходе и сравниваться с эталоном — наблюдаемость).
-
Глава 4. Функциональная верификация HDL-описаний 95
Рис. 4.5. Экран системы моделирования SILOS-3 demo: покрытие строк кода
модели объекта проекта F
Статистика говорит, что 100%-ное покрытие тестом строк HDL-кода функциональной модели дает примерно 70% наблюдаемости этого покрытия.
Второй недостаток программо-метрик в том, что они не имеют прямой связи
с оценкой функциональной корректности модели исследуемой системы и ее спецификации.
4.3.3. Автоматно-метрический подход
Если проектируемое устройство является конечным автоматом, то можно использовать для оценки полноты теста статистику о числе достижений автоматом
различных состояний (вершин) и переходов (дуг на графе автомата). Однако, так
же как и для программо-метрик, автомато-метрическая полнота — это необходимое (управляемость), но не достаточное (наблюдаемость) условие полноты теста.
Более мощные результаты дают системы формальной верификации автоматов, обнаруживающие зависания, недостижимые состояния и т. п.
4.3.4. Моделирование неисправностей
Эти методы базируются на идее обнаружения тестом множества возможных
неисправностей в моделируемой схеме (система моделирования SILOS 3 и др.).
96 Глава 4. Функциональная верификация HDL-описаний
В модель вносится неисправность, и если выходы неисправной системы не отличаются от эталона, т. е. на всем времени моделирования неисправность не
обнаруживается тестом, то тест неполный. Эти методы хорошо зарекомендовали
себя в моделях вентильного уровня (неисправности типа тождественный 0 или 1
на входе/выходе вентиля), но для моделей функционального уровня они недостаточны. Неясно, например, как моделировать неисправности оператора CASE,
и трудно представить, что все возможные неисправности в микросхеме процессора INTEL сводятся к установке одного из внешних контактов микросхемы в 0
или 1.
4.3.5. Мониторинг событий и проверка контрольных
соотношений в модели
Эти верификационные методики базируются на том, что для разработчика
модели устройства она является «прозрачным ящиком» и он имеет возможность
включить в модель дополнительные фрагменты текста (assertion — мониторы и
утверждения), контролирующие соблюдение функциональных ограничений.
Пример некорректных режимов — запрет одновременного прихода сигналов
сброса и установки на вход триггера или наличия двух открытых буферов на тристабильной шине и т. п.
Пример обязательного режима для протокола «рукопожатие» — за фронтом
сигнала запрос (req) должно следовать подтверждение (фронт ack), после чего
запрос снимается (срез req), после среза req должен следовать срез ack. Это
уже более сложное утверждение, содержащее последовательность событий во
времени.
В VHDL-моделях для контроля можно использовать оператор утверждения —
assert, реагирующий на ложность условия.
VERILOG не имеет подобного встроенного средства, и его приходится создавать с помощью обычных операторов.
Пример VHDL-утверждения о запрете одновременной 1 на двух входах set,
reset:
signal set, reset : bit;
assert ((set and reset) / = '1') report "wrong set_reset condition"
severity level error;
Eго VERILOG-эквивалент:
//пусть assert_on — переменная периода компиляции, управляющая включением
контроля,`ifdef и `endif — директивы компиляции. Если в модели есть строка
`define assert-on то в модель включается текст блока always.
`ifdef assert_on
always @(set or reset) begin
if (set && reset)
$display ("assert set && reset, %b, %b, time= %t",
set, reset, $time);
end
`endif
Второй вариант организации VERILOG-утверждений — оформление соответ
ствующего утверждения в виде процедуры (task) или модуля, включение его в биб
лиотеку исходных модулей (процедур) и использование в тексте модели.
-
-
Глава 4. Функциональная верификация HDL-описаний 97
Пример такого модуля:
`define assert_on 1
module assert_set_reset (clk, set, reset, assert_id);
input clk, set, reset;
input [7:0] assert_id;
`ifdef assert_on
always @(posedge clk) begin
if (set && reset)
$display
("assert set_reset, set = %b, reset = %b, assert_id = %d, time = %t",
set, reset, assert_id, $time);
end
`endif
endmodule
Рассмотрим пример использования подобного VERILOG-модуля в тексте
описания устройства. Из-за соображений эффективности контроль включается
только при определении (`define assert_on) переменной периода компиляции assert_on, а для пропуска утверждения синтезатором (см. главу 5) применяются
прагмы-комментарии rtl_synthesis on и off.
// rtl_synthesis off
`ifdef assert_on
assert_set_reset ff1_assert (clk, set, reset, 1);
`endif
// rtl_synthesis on
В библиотеке модулей-утверждений (ряд фирм поставляет библиотеки из
100—300 подобных модулей) обязательно имеются утверждения типа «всегда»,
«никогда», «при определенных условиях», «только один разряд» и т. п. Система
OpenVera 2 (www.open_vera.com) включает специальный язык утверждений и верификационные среды на этой базе.
4.4. Компоненты тестирующей программы
В типичной тестирующей программе (testbench) мы обычно имеем:
— генератор тактовых сигналов (clk);
— генератор сигнала сброса (reset);
— генератор (источник) векторов тестовых данных (test-vectors);
— вызов модели тестируемого устройства (Unit Under Test-UUT);
— компаратор — сравнение выходов устройства с эталоном;
— диагностическую печать (if (debug =1) $display(););
— проверку контрольных соотношений (assert);
— описание условий останова модели и печать итоговых сообщений.
При необходимости в этот список включаются: сохранение результатов моделирования в файле, средства реконфигурации модели для регрессионных экспериментов и т. п. Развитые системы создания верификационных сред типа SPECMAN фирмы VERYSITY включают библиотеки сложных типовых верификацион
ных компонент (например, шины PCI, Gigabit Ethernet и др.).
Ниже приведены примеры типичных простых компонент тестовых программ.
-
98 Глава 4. Функциональная верификация HDL-описаний
4.4.1. Тактовый генератор
В разделе дан пример генератора сигналов с периодом 10 ns и неравной длительностью сигнала1и0:
VHDL VERILOG
`timescale 1 ns/1 ns
signal Y: bit:='0'; reg Y; initial Y=1'b0;
GEN1:process always
begin begin: GEN1
wait for 3 ns; #3;
Y<= '1'; Y<=1;
wait for 7 ns; #7;
Y<= '0'; Y<=0;
end process; end //GEN1
Пример типичной ошибки при описании генератора (программа зациклится,
так как процесс не содержит оператора задержки):
VHDL VERILOG
WRONG_GEN1:process always
begin begin: WRONG_GEN1
Y<= '1' after 3 ns, Y<= #3 1;
'0' after 7 ns; Y<=#7 0;
end process WRONG_GEN1; end // WRONG_GEN1
4.4.2. Генератор сигнала сброса
Пример генератора сигналов сброса длительностью 10 тактов:
VHDL VERILOG
signal RST: bit:='1'; reg RST;
initial begin RST=1'b1;
r1:process variable I:integer; repeat( 10) @(posedge clk);
begin
for I in 1 to 10 loop RST<=0;
wait until clk='1' and clk'event;
end loop;
RST<= '0'; wait;
end process; end
4.4.3. Входные векторы
Источник входных воздействий на тестируемый объект может быть реализован в виде алгоритма (детерминированный или псевдослучайный) или набора
данных, считываемых из файла. Работа с файлом существеннее медленнее.
4.4.3.1. Cлучайные входные наборы и задержки
VERILOG
Наиболее просто случайные процессы реализуются в языке VERILOG, имею
щем встроенный датчик равномерного случайного распределения 32-разрядных
случайных чисел — системную функцию $random.
-
Глава 4. Функциональная верификация HDL-описаний 99
Пример генерации случайных адресов и данных длиной до 64 bit:
always @(posedge clk) begin
data ={$random, $random); addr={$random, $random);
end
Пример случайной задержки данных:
initial begin
#($random % Max_del) data =($random);
end
VHDL
Случайные функции VHDL реализованы в пакетах.
Приводим фрагмент использования одного из них - DISTRIBUTION.
Пример генерации случайных вещественных адресов (0:255) и данных (0:1023)
процедурой uniform (потом их надо преобразовать в целые):
Library Synopsys; use Synopsys.distribution.all;
-- в теле архитектуры---------------------
Rnd:process (clk)
Variable NN:real:= 20.0;
begin
if (clk'event and clk ='1')then
Uniform(NN, 0.0,1023.0, data);Uniform (NN,0.0,255.0,addr);
end if;
4.4.3.2. Входные наборы из файла
VERILOG
Integer I;
reg [width-1:0]pat_mem[0:depth-1];//буферная память векторов
initial begin
readmemh ("test_pat.dat", pat_mem);//считывание из файла в буфер
for (I=0; I< Max_pat_num; I=I+1) begin @(posedge clk);
#(pat_del) in_vec=pat_mem[I];// подача вектора на входы
end
end
VHDL
Пример cм. в разделее 4.6.
4.4.4. Cравнение выходов модели с эталоном (VERILOG)
Для сравнения в условии оператора if следует использовать операцию
===(тождественно), а не ==(равенство), так как, например:
I1= ( 4'b10xz !=4'b1011 ); // дает 1'bx (не истинно)
I2= (4'b10xz ==4'b1011) ;//дает 1'bx (не истинно)
I3= (4'b10xz ===4'b1011);// дает 1'b0 (ложно)
I4= (4'b10xz !==4'b1011);// дает 1'b1 (истинно)
100 Глава 4. Функциональная верификация HDL-описаний
4.5. Быстродействие и расход памяти
инструментальной ЭВМ
Кроме полноты тестирования, одними из важных характеристик тестирующей
программы являются требуемая память è расход машинного времени.
4.5.1. Расход памяти
Расход памяти зависит от числа данных в программе, их размера (особенно
больших векторов и массивов), а также количества и сложности операторов.
Например, объем памяти инструментальной ЭВМ, необходимый для хранения VHDL-данных вида signal, на порядок превышает объем для variable, и объявлять модель блока памяти лучше с помощью variable.
Пример фрагмента упрощенной модели асинхронной RAM (адрес — целое!).
entity OZU is
generic (width:positive:=10; depth:positive := 1024);
port (rw,CS:in bit;
DI,Do:inout bit_vector(width-1 downto 0); addr:in integer
);
end;
architecture BEH of OZU is
type mem_arr is array (0: depth-1) of bit_vector( width-1 downto 0);
begin
process read_write(rw,CS,DI)
variable Ram:mem_arr;
begin
if CS='1' then
if rw='1' then Do<=Ram(addr);
else Ram(addr) :=DI;
end if;
end if;
end process;
end;
VERILOG расходует обычно в 4 раза меньше памяти на хранение одного бита
данных, чем VHDL. Данные вида переменные в этом смысле всегда лучше, чем
вида сигналы и соединения.
4.5.2. Быстродействие тестирующей программы
Уменьшить время модельного эксперимента можно различными способами,
среди которых:
1. Эффективная организация тестирующей программы (профилирование —
выявление наиболее часто исполняемых фрагментов модели и их оптимизация,
исключение ненужных печатей и т. п.).
2. Использование систем поддержки верификации и языков программирова
ния для создания верификационной среды (это часто не только сокращает время
разработки и отладки теста, но и повышает его быстродействие).
-
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]