Обработка расширений протокола в UVC

Question

Мне любопытно, как вы обрабатываете расширения протокола UVC. Допустим, у нас есть APB UVC, который реализует протокол AMBA. Скажем также, что у нас есть DUT, который помимо сигналов, определенных в спецификации, также реализует несколько других сигналов, которые относятся к общим сигналам APB (они добавляют поддержку защищенного доступа или чего-либо еще). Со стороны класса это довольно просто: просто создайте новый подкласс элемента последовательности с дополнительными полями и сделайте переопределения типов. Труднее всего работать на уровне сигнала. Наш UVC уже использует интерфейс SV, который содержит только сигналы APB, и его невозможно расширить каким-либо образом. Как бы мы получили эти дополнительные сигналы в UVC для управления и мониторинга?

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

Этот вопрос я также задавал на форумах Accellera UVM: http://forums.accellera.org/topic/1832-handling-protocol-extensions/

Answer 1

Как расширить протокол UVC (UVM Verification Component) для добавления пользовательских расширений, поддерживая правильную инкапсуляцию?

Типичный протокол (и его UVC) имеет такие понятия, как состояния или режимы (управление работой в различных обстоятельствах) и фазы или события (разделенные области или точки интереса во время выполнения передачи в соответствии с протоколом). "Ванильный" UVC поддерживает внутренние состояния / моды / фазы на основе некоторой комбинации данных стимула и наблюдаемой обратной связи DUT. Расширение протокола UVC для добавления пользовательских сигналов обычно требует доступа к тем же состояниям / режимам / фазам или событиям.

Я предполагаю, что вам не нужно изменять протокол, только добавить к нему неразрушающим способом.

На уровне класса (вы уже знаете это):

1. создать основу для пользовательских расширений в базовом UVC, обеспечив / добавив
   • accessors() для ключевых состояний или режимов протокола, чтобы расширенный класс мог получить к ним доступ
   • события / обратные вызовы для ключевых фаз протокола, так что расширенный класс может подписаться на них
   • предпочитаю объект конфигурации для базовой конфигурации UVC, а не дискретные значения конфигурации
2. расширить элемент последовательности (и библиотеку последовательностей *), чтобы передать намерение стимула относительно расширения
   • рассмотрите возможность использования здесь случайных ограничений для обеспечения соблюдения правил пользовательского расширения
3. расширить базовый класс UVC, чтобы создать собственное расширение, добавив
   • секвенсор для вашего расширенного элемента последовательности, который извлекает расширенную часть стимула для локального использования и передает элемент в базовый UVC
   • порт анализа, который может сообщать любую дополнительную информацию, отслеживаемую благодаря пользовательскому расширению
   • драйвер / монитор для пользовательского расширения, вызванный событиями / обратными вызовами в базовом драйвере / мониторе UVC.
   • passthru для конфигурации объектов / подключения и обычных механизмов UVM.

На уровне сигнала:

4. рассмотреть подход "интерфейс в интерфейсе"
   • создать физический интерфейс, представляющий полный пакет сигналов, содержащий:
     • экземпляр оригинального интерфейса протокола vanilla
     • экземпляр нового интерфейса, представляющего "побочные сигналы"
   • назначьте внешние или внутренние интерфейсы виртуальным дескрипторам интерфейса в нужном месте в вашей тестовой среде и расширенном классе UVC (с помощью обычных механизмов UVM).
   • рассмотрите возможность использования утверждений в этом интерфейсе, если это возможно, чтобы сохранить поведение вашего расширения легальным по отношению к базовому протоколу

Разделяя расширения, вы получаете максимальную удобство сопровождения кода в ситуациях, которые часто бывают сложными в обслуживании (настройка протоколов, которые должны быть "стандартными"), при условии, что вы можете выставить правильные хуки и API в базовом UVC,

* Расширение всей библиотеки последовательностей не всегда возможно, и в этом случае вашей низкоуровневой последовательности или элементу может потребоваться доступ к некоторой конфигурации "на стороне", например, к дескриптору модели или некоторому объекту конфигурации, чтобы управлять "расширением" поведение, используя обычные механизмы UVM для этого. Примером этого могут быть расширения, связанные с управлением питанием, где реализация низкого уровня влияет на протокол, но управление высокого уровня не зависит от протокола.