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 напрямую не может.

Figure 1-7 OVM Testbench Architecture Layers

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

Figure 1-8 Concentric Testbench Organization

Транзакторы

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

Монитор

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

Драйвер

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

Респондер

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

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

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

Stimulus генератор

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

Мастер

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

Slave

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

Рисунок 1-9 Мастер и Slave

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

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

Scoreboard

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

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

Coverage collectors считают things. Они перехватывают поток транзакций и считают транзакции или их различные аспекты. Целью является определение завершенности верификации. Что конкретно должен считать 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, that operate the DUT. Это stimulus generators, шина функциональных моделей (ШФМ), и аналогичные компоненты, которые генерируют сигналы и возвращают ответы, которые управляют симуляцией. DUT, респондер и драйвер наряду с компонентами среды, которые непосредственно взаимодействуют с драйверами и респондерами составляют оперативную область. Остальные компоненты тестовой программы — монитор, scoreboards, coverage collectors и контроллер — составляют облать анализа. Это компоненты, которые собирают информацию из оперативной области.

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

One of the key features of analysis ports is that they have a single interface function, write(). Analysis FIFOs, the channels used to connect analysis ports to analysis components, are unbounded. This guarantees that the publisher doesn’t block and that it deposits its data into the analysis FIFO in precisely the same delta cycle in which it was generated. Chapter 7 discusses analysis ports and analysis FIFOs in more detail.

Figure 1-10 Connection between Operational and Analysis Domains

Generally, the operational and analysis domains are connected by analysis ports and control and configuration interfaces. Analysis ports tap off data concerning the operation of the DUT. These data might include bus transactions, communication packets, and status information (success or failure of specific operations). The components in the analysis domain analyze the data and make decisions. The results of those decisions can be communicated to the operational domain via the control and configuration interfaces. Control and configuration interfaces can be used to start and stop stimulus generators, change constraints, modify error rates, or manipulate other parameters affecting how the testbench operates.