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

Slave

Slaves, like masters, are bidirectional components. They respond to requests and return responses (in contrast to masters, which send requests and receive responses).

Figure 1-9 A Master and a Slave

1.4.3 Analysis Components

Analysis components receive information about what’s going on in the testbench and use that information to make some determination about the correctness or completeness of the test. Two common kinds of analysis components are scoreboards and coverage collectors.

Scoreboard

Scoreboards are used to determine correctness of the DUT, to answer does-it-work questions. Scoreboards tap off information going into and out of the DUT and determine if the DUT is responding correctly to its stimulus.

Coverage Collector

Coverage collectors count things. They tap into streams of transactions and count the transactions or various aspects of the transactions. The purpose is to determine verification completeness by answering are-wedone questions. The particular things that a coverage collector counts depends on the design and the specifics of the test. Common things that coverage collectors count include: raw transactions, transactions that occur in a particular segment of address space, and protocol errors. The list is limitless.

Coverage collectors can also perform computations as part of a completeness check. For example, a coverage collector might keep a running mean and standard deviation of data being tracked. Or it might keep a ratio of errors to good transactions.

1.4.4 Controller

Controllers form the main thread of a test and orchestrate the activity. Typically, controllers receive information from scoreboards and coverage collectors and send information to environment components.

For example, a controller might start a stimulus generator running and then wait for a signal from a coverage collector to notify it when the test is complete. The controller, in turn, stops the stimulus generator. More elaborate variations on this theme are possible. In an example of a possible configuration, a controller supplies a stimulus generator with an initial set of constraints and starts the stimulus generator running. When a particular ratio of packet types is achieved, the coverage collector signals the controller. Rather than stopping the stimulus generator, the controller may send it a new set of constraints.

1.5 Two Domains

We can view the set of components in a testbench as belonging to two separate domains. The operational domain is the set of components, including the DUT, that operate the DUT. These are the stimulus generators, bus functional models (BFM), and similar components that generate stimulus and provide responses that drive the simulation. The DUT, responder, and driver transactions—along with the environment components that directly feed or respond to drivers and responders—comprise the operational domain. The rest of the testbench components—monitor transactors, scoreboards, coverage collectors, and controller—comprise the analysis domain. These are the components that collect information from the operational domain.

Data must be moved from the operational domain to the analysis domain in a way that does not interfere with the operation of the DUT and preserves event timing. This is accomplished with a special communication interface called an analysis port. Analysis ports are a special kind of transaction port in which a publisher broadcasts data to one or more subscribers. The publisher signals all the subscribers when it has new data ready.

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.