OVM/OVM методология/Layered Organization of Testbenches/ru

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

Эта статья требует перевода на русский язык

Глава 1.4 из книги Glasser M. Open Verification Methodology Cookbook — USA: Springer, 2009. — 248 с. — ISBN 978-1-4419-0967-1.

Уровневая организация тестовых программ

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

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

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

Транзакторы

Задача транзакторов в тестовой программе - это преобразование потока транзакций в pin-level activity или наоборот. Транзакторы характеризуются наличием хотя бы одного pin-level интерфейса и хотя бы одного transaction-level интерфейса. Существуюет большое количество разновидностей транзакторов. Мы сфокусируемся на мониторах, драйверах и респондерах.

Монитор

Монитор как следует из имени, осуществляет мониторинг шины. Он следит за выводами и преобразует их изменения в поток транзакций. Мониторы - пассивны, то есть они не оказывают никакого влияния на операции в DUT.

Драйвер

Драйвер преобразует поток транзакций (или последовательность элементов) в pin-level activity.

Респондер

Респондер похож на драйвер, только он реагирует на активность на выходе, а не на входную активность.

Операционные компоненты

Операционные компоненты - это набор компонентов, которые обеспечивают все необходимые операции в DUT. Операционные компоненты ответственны за генерацию трафика для DUT. Все эти компоненты относятся к уровню транзакций и имеют только интерфейс уровня транзакций. Существуют различные варианты формирования сигнала, которые варьируются в зависимости от верифицируемого устройства. Мы рассмотрим три основных вида операционных компонентов: stimulus generators, masters, и slaves.

Генератор входных воздействий

Генератор входных воздействий создают поток транзакций, осуществляемых в DUT. Генераторы входных воздействий могут быть случайными, заданными или заданными случайно; они могут запускаться самостоятельно или контролируемо; и они могут быть независимыми или синхронизированными. Простейший генератор входных воздействий рандомизирует содержимое объекта запроса и посылает этот объект на драйвер. OVM также предоставляет модульные динамические средства для построения сложных входных воздействий, называемыми последовательностями. Это подробно рассмотрено в главе 8.

Мастер

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

Slave

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

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

Компоненты анализа принимают информацию о том, что происходит в тестовой программе и используют эту информацию для определения корректности и завершенности выполнения теста. Два наиболее распространенных видов компонентов анализа - это scoreboards и coverage collectors.

Scoreboard

Scoreboards используются для определения корректности DUT, показывая, работает ли устройство. Scoreboards перехватывают информацию, входящую и выходящую из DUT и определяют правильно ли DUT отвечает на данный stimulus.

Coverage Collector (Сборщик покрытия)

Coverage collectors считают элементы. Они перехватывают поток транзакций и считают транзакции или их различные аспекты. Целью является определение завершенности верификации. Что конкретно должен считать coverage collector, зависит от архитектуры и особенностей теста. Наиболее распространенные вещи, которые считают coverage collectors - это ряд транзакций, транзакции, происходящие в определенном сегменте адресного пространства, и ошибки протокола. Список неограничен.

Coverage collectors могут также производить вычисления как часть полной проверки. Например, coverage collector может keep a running mean and standard deviation of data being tracked. Или может содержать отношение ошибок к успешным транзакциям.

Контроллер

Контроллеры формируют основной поток теста и управляет активностью. Обычно, контроллеры получают информацию из scoreboards и coverage collectors и посылают информацию на компоненты среды.

Например, контроллер может запустить stimulus generator и затем ждать сигнала coverage collector о том, что тест завершен. Контроллер, в свою очередь, останавливает stimulus generator. Также возможны более сложные вариации. В качестве примера возможной конфигурации, можно рассмотреть контроллер, подающий начальный набор ограничений на stimulus generator и запускающий его. Когда определенное соотношение типов пакетов достигнуто, coverage collector сообщает это контроллеру. Вместо того, чтобы остановить stimulus generator, контроллер может отправить ему новый набор ограничений.

Две области

Мы можем рассмотреть набор компонентов в тестовой программе как компоненты, принадлежащие к двум отдельным областям. Оперативная область - это набор компонентов, включающий DUT, выполняющие операции над DUT. Это stimulus generators, шина функциональных моделей (ШФМ), и аналогичные компоненты, которые генерируют сигналы и возвращают ответы, которые управляют симуляцией. DUT, респондер и драйвер наряду с компонентами среды, которые непосредственно взаимодействуют с драйверами и респондерами составляют оперативную область. Остальные компоненты тестовой программы — монитор, scoreboards, coverage collectors и контроллер — составляют облать анализа. Это компоненты, которые собирают информацию из оперативной области.

Данные должны быть перемещены из оперативной области в область анализа таким образом, чтобы не мешать работе DUT и preserves event timing. Это достигается с помощью специального интерфейса связи, называемого порт анализа. Порты анализа представляют собой особый вид порта транзакций, в котором publisher передает данные одному или нескольким subscribers.

Одной из ключевых особенностей портов анализа является то, что они имеют единую Функцию интерфейса write(). FIFO анализа, каналы используемые для подключения портов анализа к компонентам анализа - не ограничены. Это гарантирует то, что publisher не блокирует и сдает свои данные в FIFO анализа в точно таком же дельте цикле, в котором он был создан. В главе 7 обсуждаются порты анализа и и FIFO анализа более подробно.

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