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

1. Особенности использования возможностей объектно-ориентированного программирования SystemVerilog для функциональной верификации многоядерных СнК Федор Михайлович Путря, к.т.н., нач. лаб. «Верификации СФ-блоков и СнК» ОАО НПЦ «ЭЛВИС»

2. Содержание • Особенности верификации СнК • Платформенный подход в верификации • Возможности SystemVerilog и UVM для реализации платформенного подхода и создания тестов и тестовых окружений • Проблема эталонной модели для верификации RTL модели • Верификация проекта с использованием моделей высокого уровня абстракции • Создание универсальной SystemVerilog обертки для интеграции С++ модели в тестовое окружение • Заключение

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

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

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

6. Особенности верификации СнК Увеличение скорости моделирования и отладки: • Акцент на верификации блоков в собственном тестовом окружении (на системном уровне выполняются только тесты интеграции и тесты на взаимодействие боков) • Верификация проекта с использованием моделей высокого уровня абстракции Сокращение времени разработки верификационного кода и повышение его эффективности: • Преимущественное использование случайных тестов и генераторов тестов • Разработка тестов на более высоком уровне абстракции и «многоуровневая» рандомизация • Использование принципов ООП при создании тестов и генераторов тестов • Платформенный подход

7. Платформенный подход в верификации «Горизонтальное» повторное использование

8. Платформенный подход в верификации «Вертикальное» повторное использование

9. Возможности SystemVerilog • Возможность использовать принципы ООП при создании тестов и тестовых окружений • Возможность создавать тесты на высоком уровне абстракции и использовать многоуровневую генерацию тестов • Инструментарий для управления параллельными процессами • Возможность прямого доступа как к сигналам RTL модели, так и к функциямсторонней С/С++ программы (DPI) • Набор функций для создания случайных последовательностей различной степени сложности • Система пакетов (package)для упаковки повторно используемого кода • Методология и библиотека UVM (Universal Verification Methodology) на базе SystemVerilog

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

11. UVM • Готовые базовые классы для всех основных компонентов тестового окружения (единообразие компонентов во всех тестовых окружениях) • Идеология верификационных агентов: инкапсуляция кода, направленного на верификацию конкретных интерфейсов или блоков в рамках одного повторно используемого верификационного компонента • Создание тестов на уровне транзакций • Поддержка идеологии TLM • Средства для упрощения работы с регистрами памятью верифицируемых устройств • UVM – первая методология поддержанная одновременно Synopsys, Mentor и Cadence. На рынке верификационных компонент (VIP)ужедоминируют компоненты на базе UVM.

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

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

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

15. Требования к SV обертке для С++ модели • Для повторного использования кода обертки необходимо наличие унифицированного интерфейса как для взаимодействия с UVM окружением, так и С++ моделью • Для интеграции С++ модели в UVM тестовое окружение нужна SV обертка, имеющая общепринятые в методологии UVM интерфейсы • SV обертка должна поддерживать взаимодействие с С++ моделью как по ведомому, так и по ведущему интерфейсу • C++ модель блока должна обладать интерфейсом, совместимым с идеологией TLM • SV обертка должна поддерживать возможность интеграции С++ модели в RTL модель системы в качестве полноценного блока • Должна иметься возможность динамического создания нескольких копий модели в рамках сложного тестового окружения

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

17. Обертка для 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++

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

19. Недостатки методологии UVM • Большое количество UVM компонент в составе тестового окружения замедляет процесс моделирования • Необходим высокий уровень знаний инженеров

20. Заключение • Несмотря на высокие трудозатраты на «вход» на первых проектах, методология UVM даёт ощутимый выигрыш для очередных проектовпосле накопления опыта и библиотеки компонентов • Тем не менее для реализации платформенного подхода в верификации и минимизации трудозатрат на интеграцию компонент, созданных разными инженерами необходим набор дополнительных правил создания верификационных компонент (дополняющих UVM) • Предложен метод, позволяющий повторно использовать код программной модели блоков в тестовых окружениях и стандартизовать способ интеграции таких моделей в тестовое окружение • За счет создания единообразной библиотеки компонент и шаблонного тестового окружения, разработка первого варианта окружения блока может быть выполнена за 1-2 дня. Дополнительно код такого окружения повторно используется при верификации всей модели или аналогичных проектов

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