Федор Михайлович Путря, к.т.н., нач. лаб. «Верификации...

Особенности использования возможностей объектно-

ориентированного программирования SystemVerilog для функциональной

верификации многоядерных СнК

Федор Михайлович Путря, к.т.н., нач. лаб. «Верификации СФ-блоков и СнК»

ОАО НПЦ «ЭЛВИС»

2ОАО НПЦ «ЭЛВИС»

Содержание

• Особенности верификации СнК

• Платформенный подход в верификации

• Возможности SystemVerilog и UVM для реализации платформенного подхода и создания тестов и тестовых окружений

• Проблема эталонной модели для верификации RTL модели

• Верификация проекта с использованием моделей высокого уровня абстракции

• Создание универсальной SystemVerilog обертки для интеграции С++ модели в тестовое окружение

• Заключение


Особенности верификации СнК

•



•Наличие нескольких групп проблемно ориентированных вычислительных ядер•Большая номенклатура периферийных интерфейсов различной пропускной способности и назначения•Собирается из покупных и повторно используемых блоков собственной разработки (скорость сборки СнК высокая)•Сложная, как правило многоуровневая организация коммутационной логики, особенности которой определяются целевой задачей СнК•Сложный характер трафика, обусловленный одновременной работой множества устройств различного типа•Колоссальная комбинационная сложность системы•Высокая вероятность ошибок в спецификации и архитектурных просчетов


Особенности верификации СнК•Наличие ошибок, которые обнаруживаются только при одновременном сочетании множества условий, которые бывает весьма сложно создать при верификации, не говоря уже о выявлении полного набора таких критических сочетаний.•Необходимо не только доказательство соответствия заявленной спецификации, но и доказательство, того что в текущей реализации проект позволяет успешно выполнять на нём целевые задачи во всех допустимых условиях применения системы (тесты на основе прикладных задач – обязательны).•Время моделирования и формальной верификации RTL модели всей системы становится недопустимо большим. Моделирование – критический процесс!•Необходим огромный набор тестов: время разработки полного набора тестов «обычными» методами на порядки превосходит время моделирования. Создание и отладка верификационного кода – еще более критический процесс чем моделирование!



Увеличение скорости моделирования и отладки:

• Акцент на верификации блоков в собственном тестовом окружении (на системном уровне выполняются только тесты интеграции и тесты на взаимодействие боков)

• Верификация проекта с использованием моделей высокого уровня абстракции

Сокращение времени разработки верификационного кода и повышение его эффективности:

• Преимущественное использование случайных тестов и генераторов тестов

• Разработка тестов на более высоком уровне абстракции и «многоуровневая» рандомизация

• Использование принципов ООП при создании тестов и генераторов тестов

• Платформенный подход


Платформенный подход в верификации

«Горизонтальное» повторное использование


Платформенный подход в верификации

«Вертикальное» повторное использование


Возможности SystemVerilog

• Возможность использовать принципы ООП при создании тестов и тестовых окружений

• Возможность создавать тесты на высоком уровне абстракции и использовать многоуровневую генерацию тестов

• Инструментарий для управления параллельными процессами

• Возможность прямого доступа как к сигналам RTL модели, так и к функциям сторонней С/С++ программы (DPI)

• Набор функций для создания случайных последовательностей различной степени сложности

• Система пакетов (package) для упаковки повторно используемого кода

• Методология и библиотека UVM (Universal Verification Methodology) на базе SystemVerilog


Диаграмма классов UVM


UVM

• Готовые базовые классы для всех основных компонентов тестового окружения (единообразие компонентов во всех тестовых окружениях)

• Идеология верификационных агентов: инкапсуляция кода, направленного на верификацию конкретных интерфейсов или блоков в рамках одного повторно используемого верификационного компонента

• Создание тестов на уровне транзакций

• Поддержка идеологии TLM

• Средства для упрощения работы с регистрами памятью верифицируемых устройств

• UVM – первая методология поддержанная одновременно Synopsys, Mentor и Cadence. На рынке верификационных компонент (VIP) уже доминируют компоненты на базе UVM.


Верификационный агент

•Унифицированные порты для взаимодействия с элементами тестового окружения•Унифицированные механизмы конфигурации агентов•В нашей реализации Slave агента используется TLM порт для связи с внешними компонентами


Тестовое окружение

?

*Возможен параллельный запуск нескольких последовательностей для имитации воздействий со стороны многоядерной системы


Модели высокого уровня абстракции

А) Алгоритмическая модель и/или модель всей системы на языках высокого уровня (С/С++)Б) Виртуальный прототип / TLM модель

В) Смешанные модели TLM+RTL


Требования к SV обертке для С++ модели

• Для повторного использования кода обертки необходимо наличие унифицированного интерфейса как для взаимодействия с UVM окружением, так и С++ моделью

• Для интеграции С++ модели в UVM тестовое окружение нужна SV обертка, имеющая общепринятые в методологии UVM интерфейсы

• SV обертка должна поддерживать взаимодействие с С++ моделью как по ведомому, так и по ведущему интерфейсу

• C++ модель блока должна обладать интерфейсом, совместимым с идеологией TLM

• SV обертка должна поддерживать возможность интеграции С++ модели в RTL модель системы в качестве полноценного блока

• Должна иметься возможность динамического создания нескольких копий модели в рамках сложного тестового окружения


Обеспечение возможности создания нескольких копий оберток


Обертка для C++ модели

Примеры DPI функций для взаимодействия обертки и С++ модели:Ведомый интерфейс:int model_name_put_s_tran_req (void * CPP_ptr, int device_id, int tran_id, long params[PARAM_LEN]); // SV->C++ (import)int model_name_put_s_tran_rsp (int WRAP_ptr, int device_id, int tran_id); // C++->SV (export) Ведущий интерфейс:int model_name_put_m_tran_req (int WRAP_ptr, int device_id, int tran_id, long params[PARAM_LEN]); // C++->SV (export) int model_name_put_m_tran_rsp (void * CPP_ptr, int device_id, int tran_id); // SV>C++


Повторное использование тестовых окружений на уровне системы


Недостатки методологии UVM

• Большое количество UVM компонент в составе тестового окружения замедляет процесс моделирования

• Необходим высокий уровень знаний инженеров


Заключение• Несмотря на высокие трудозатраты на «вход» на первых

проектах, методология UVM даёт ощутимый выигрыш для очередных проектов после накопления опыта и библиотеки компонентов

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

• Предложен метод, позволяющий повторно использовать код программной модели блоков в тестовых окружениях и стандартизовать способ интеграции таких моделей в тестовое окружение

• За счет создания единообразной библиотеки компонент и шаблонного тестового окружения, разработка первого варианта окружения блока может быть выполнена за 1-2 дня. Дополнительно код такого окружения повторно используется при верификации всей модели или аналогичных проектов


• Спасибо за внимание

Федор Михайлович Путря, к.т.н., нач. лаб. «Верификации...

Documents