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

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

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

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

Два вопроса

Проверка устройства включает в себя два вопроса: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 вопросы, вы можете создать таблицу:

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

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

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

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

Первый Testbench

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

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

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

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

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

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

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

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

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

• DUT

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

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

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

DUT

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

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

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

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

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

Scoreboard

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

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

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

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

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

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

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

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

Второй Testbench

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

59 module clkgen(output bit clk);
60
61 initial begin
62 clk <= 0;
63 forever #5 clk = ~clk;
64 end
65
66 endmodule

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

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

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

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

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

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

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

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

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

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

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

Заключение

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