RTL в GDS: проверка дизайна

1. Введение: инженерия, которая математически и логически доказывает замысел проекта

С точки зрения общего потока проектирования полупроводников, а именно потока RTL to GDSII, мы ранее рассмотрели структурную обоснованность и синтаксические ошибки кода с помощью стиля кодирования Verilog и линтинга на предыдущем этапе.

Теперь мы переходим к верификации проекта, которая является сердцем проектирования и этапом, требующим наибольших затрат времени и ресурсов. этап: Верификация проекта.

Верификация — это не просто тест, чтобы проверить, «работает» ли код RTL. Это процесс, который доказывает, была ли архитектурная спецификация, задуманная проектировщиком, точно переведена в RTL-реализацию и не возникнет ли логических проблем на последующих этапах, таких как логический синтез.

В современном проектировании SoC (System on Chip) верификация имеет настолько большое значение, что часто занимает больше времени, чем сам этап проектирования RTL. Это связано с тем, что стоимость исправления ошибок, обнаруженных после изготовления чипа (Silicon Bugs), в тысячи раз превышает стоимость их исправления на этапе RTL.в тысячи раз превышает затраты на их исправление на этапе RTL. Следовательно, это чрезвычайно важный этап, на котором существует значительный спрос на специалистов.kg-image" alt="" loading="lazy" width="750" height="677" srcset="https://www.vlsi.kr/content/images/size/w600/2026/01/image-50.png 600w, https://www.vlsi.kr/content/images/2026/01/image-50.png 750w" sizes="(min-width: 720px) 720px">

Таким образом, задача инженера по проверке выходит за рамки простого поиска ошибок; она заключается в статистическом и логическом доказательстве того, что «ошибок нет».

2. Смена парадигмы в методологии верификации: от направленного к ограниченному случайному

Несколько десятилетий назад, при верификации проектов на уровне сотен вентилей, преобладающим подходом было направленное тестирование, при котором инженеры вручную кодировали каждый предсказуемый сценарий. Однако для современных проектов, обладающих сложностью масштаба VLSI, полагаться исключительно на предсказательные способности человека практически невозможно. Это ограничение потребовало коренного сдвига в методологии верификации.

Преимущества такого подхода очевидны. Цель тестирования ясна, что упрощает отладку и облегчает быструю проверку базовой функциональности на начальном этапе запуска.p>

Однако критическим недостатком является то, что он абсолютно не может проверить «сценарии, которые инженер не учел». Сложные задержки конвейера, условия гонки между асинхронными интерфейсами и обработка исключительных ошибок — все это сложно перечислить человеческому разуму, чтобы перечислить все возможные комбинации. Кроме того, при каждом изменении спецификации проекта вручную написанные тестовые случаи должны быть индивидуально модифицированы, что приводит к экспоненциальному увеличению затрат на обслуживание.

2.2 Ограниченная случайная верификация (CRV)

Для преодоления этих ограничений направленного тестирования появилась ограниченная случайная верификация (CRV).

CRV использует возможности объектно-ориентированного программирования SystemVerilog и функции рандомизации для генерации тестовых стендов. Она исследует пространство состояний случайным образом, накладывая ограничения в пределах допустимых диапазонов для выполнения верификации.

Основой CRV являются рандомизация, автоматизация и исследование.

Вместо написания отдельных тестовых векторов инженеры определяют только структуру пакета данных и правила протокола (ограничения). Каждый раз, когда симулятор вызывает функцию randomise(), он генерирует различные комбинации данных, адреса, задержки и комбинации управляющих сигналов. Например, ограничения типа constraint valid_addr { addr < 1024; } гарантирует, что попытки случайного доступа остаются в пределах допустимого адресного пространства. Симулятор генерирует сложные сценарии, такие как крайние случаи, которые могут быть непредвиденными для человека, например, «ситуация, когда сброс происходит внезапно, когда FIFO заполнен, одновременно с прерыванием». UVM (универсальная методология верификации)

Для эффективной реализации CRV требуется надежная и многократно используемая структура. Именно это послужило причиной создания UVM (универсальной методологии верификации) и стало причиной того, что она стала текущим отраслевым стандартом. height="1024" srcset="https://www.vlsi.kr/content/images/size/w600/2026/01/image-53.png 600w, https://www.vlsi.kr/content/images/2026/01/image-53.png 765w" sizes="(min-width: 720px) 720px">

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

3.1 Философия тестового стенда UVM: разделение задач

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

3.2 Подробный анализ основных компонентов

3.2.1 Элемент последовательности (транзакция): начало абстракции

Наиболее фундаментальной единицей верификации является uvm_sequence_item. Этот объект абстрагирует сигналы (0 и 1) на уровне выводов в «транзакции», которые представляют собой значимые фрагменты информации. Например, Хотя по шине AXI проходит множество управляющих сигналов, на уровне транзакций они представлены исключительно такими атрибутами, как Адрес, Данные, Чтение/запись и Длина пакета. Это позволяет инженерам по верификации сосредоточиться на самом потоке данных, не задумываясь о сложных вопросах синхронизации.

3.2.2 Секвенсор: центр управления потоком данных

uvm_sequencer — это центр управления потоком данных, который управляет выполнением последовательных задач.EC%A0%9C%ED%83%91">3.2.2 Секвенсор: контрольная башня потока данных

uvm_sequencer действует как посредник, передавая сгенерированные элементы последовательности драйверу. Помимо простой передачи данных, он выполняет арбитраж, решая, какой элемент последовательности отправить первым, когда несколько последовательностей выполняются одновременно. Например, когда обычная последовательность передачи данных и последовательность аварийного прерывания выполняются одновременно, секвенсор может сначала отправить драйверу элемент, связанный с прерыванием, на основе настроек приоритета. Эта концепция аналогична арбитру шины в реальном оборудовании..3 Драйвер: мост между абстракцией и реальностью

uvm_driver преобразует абстрактные пакеты транзакций, полученные от секвенсора, в сигналы на уровне выводов, которые может понять фактическое тестируемое устройство (DUT). В этом процессе используется интерфейс TLM (Transaction Level Modelling). Драйвер запрашивает элементы через seq_item_port.get_next_item(req) для запроса элемента и управляет виртуальным интерфейсом через свою внутреннюю логику для переключения сигналов на фронтах тактового сигнала. Драйвер занимается исключительно «входными данными» и не оценивает и не проверяет выходные данные от DUT. Это является исключительной ответственностью монитора и табло результатов.-%EB%88%88-observer">3.2.4 Монитор: глаз верификации (наблюдатель)

uvm_monitor — это компонент, который пассивно наблюдает (пассивный мониторинг) за сигналами интерфейса DUT. Он не подает никаких сигналов на DUT, а только обнаруживает изменения сигналов через виртуальный интерфейс. Монитор обнаруживает изменения сигналов на уровне выводов и собирает их в форму транзакции (uvm_sequence_item).Эта пересобрана информация передается подписчикам, таким как Scoreboards или Coverage Collectors, через analysis_port. Кроме того, монитор может внутренне включать Assertion Checker для проверки основных нарушений протокола.ED%86%A0%EC%BD%9C%EC%9D%98-%EC%BA%A1%EC%8A%90%ED%99%94">3.2.5 Агент: Инкапсуляция протокола

uvm_agent — это контейнер, который объединяет описанные выше Sequencer, Driver и Monitor. Агент служит в качестве единицы для верификации IP (VIP), обрабатывающей определенный протокол интерфейса (например, AHB, AXI, UART). Агент работает в двух режимах на основе конфигурационной переменной is_active:

• Активный режим: создает как секвенсор, так и драйвер для активного применения стимула к DUT.
• Пассивный режим: создает только монитор для наблюдения за сигналами шины. Используется для верификации подсистем внутри чипа или для мониторинга системы, когда другой мастер уже управляет шиной.

3.2.6 Табло результатов: Checker

uvm_scoreboard — это основной компонент, определяющий успех/неудачу верификации. Он сравнивает фактический вывод DUT, собранный монитором, с ожидаемым выводом внутренне реализованной эталонной модели(золотой модель). Эталонная модель обычно пишется на C/C++ или SystemVerilog и, в отличие от RTL, моделируется для быстрого выполнения функциональных операций без информации о времени. Метод сравнения делится на проверку в порядке, где последовательность имеет решающее значение, и проверку вне порядка, где последовательность может быть перемешана. Это определяется на основе характеристик DUT.h2 id="4-systemverilog-assertions-sva-%EC%8B%A4%EC%8B%9C%EA%B0%84-%EC%95%88%EC%A0%84%EC%9E%A5%EC%B9%98">4. Утверждения SystemVerilog (SVA): Защита в реальном времени

В то время как тестовые стенды UVM проверяют общую функциональность чипа и поток данных, SystemVerilog Assertions (SVA) действуют как система видеонаблюдения, отслеживая в режиме реального времени мелкие правила поведения и синхронизацию на уровне сигналов в RTL. SVA значительно сокращают время отладки, немедленно останавливая симуляцию или выводя сообщения об ошибках в момент их возникновения. .h3>

SVA широко классифицируются по двум типам в зависимости от точки оценки.

4.1.1 Немедленные утверждения (немедленные утверждения)

Немедленные утверждения используются в процедурных блоках в Verilog (always, initial, task, function), и обладает семантикой выполнения, аналогичной оператору `if-else`. Оно оценивает выражение сразу же после возникновения события симуляции, которое запускает выполнение оператора.

• Использование: в основном используется для проверки состояния инициализации переменных, проверки входных аргументов функции и проверки состояния комбинационной логики.
• Пример: `assert (packet_len > 0) else $error("Длина пакета должна быть положительной");

4.1.2 Одновременные утверждения

Одновременные утверждения оцениваются синхронно с фронтом тактового импульса. Это делает их чрезвычайно мощным инструментом для проверки последовательностей событий во времени. Они оптимизированы для выражения временной логики, такой как «Когда сигнал Request поднимается, Grant должен подниматься через три тактовых цикла».

• Синтаксис: Используйте ключевые слова property и sequence для определения сложных временных отношений. Операторы |-> (перекрывающаяся импликация) и |=> (неперекрывающаяся импликация) явно указывают на соотношение между антецедентом и консеквентом.
• Пример: property req_gnt_prop; @(posedge clk) req |-> ##[1:3] gnt; endproperty (Проверяет, что если Request находится в состоянии High, Grant должен быть в состоянии High в течение 1–3 циклов).

4.2 Стратегия размещения SVA: интерфейс против привязки

Место реализации SVA существенно влияет на читаемость кода, возможность повторного использования и влияние на синтез.421-in-line-sva-rtl-placement-and-placement-BD%EC%9E%85">4.2.1 Встроенный SVA (вставка в RTL)

Этот подход предполагает, что разработчик RTL вставляет утверждения непосредственно в модуль во время написания кода. Хотя он дает преимущество в том, что разработчик, который лучше всего понимает замысел проекта, может немедленно наложить ограничения, оно может ухудшить читаемость, поскольку код верификации смешивается с кодом RTL. Кроме того, во время синтеза необходимо выполнять трудоемкое исключение таких утверждений с помощью прагм, таких как synthesis translate_off.

4.2.2 Интерфейс SVA

Этот метод предполагает встраивание утверждений в синтаксис interface SystemVerilog. Этот подход очень эффективен для верификации правил интерфейса, которые часто используются в нескольких модулях, например, протоколы шины. Простое подключение интерфейса автоматически выполняет верификацию протокола для всех модулей, использующих эту шину, что обеспечивает отличную возможность повторного использования.путем написания отдельного модуля SVA и динамического присоединения его к экземпляру RTL. Для этого используется ключевое слово bind, что позволяет полностью разделить задачи RTL (проектирование) и верификации. Это важная техника, особенно для верификации стороннего IP или устаревшего кода, где права на модификацию ограничены (верификация «черного ящика»).

5. Верификация на основе покрытия (CDV)

«Когда следует завершать верификацию?» — этот вопрос остается загадкой для каждого проектного менеджера и инженера. В отличие от прошлого, когда полагались на интуицию, современная верификация следует методологии верификации на основе покрытия (CDV) методологии. То есть верификация считается завершенной, когда количественная метрика покрытия достигает целевого значения.

5.1 Метрики покрытия: мера верификации">5.1 Показатели покрытия: мера верификации

Покрытие в целом делится на покрытие кода, автоматически извлекаемое инструментами, и функциональное покрытие, определяемое пользователем.B2%84%EB%A6%AC%EC%A7%80">5.1.1 Покрытие кода

Это показывает, какая часть кода RTL была выполнена во время симуляции. Достижение 100% является основной целью.

• Покрытие строк/блоков: Была ли каждая строка кода и каждый блок выполнены хотя бы один раз?
• Покрытие переключений: Все ли биты сигналов и регистров перешли из состояния 0 в состояние 1 и из состояния 1 в состояние 0? Это полезно для поиска застрявших сигналов.
• Покрытие FSM: Были ли посещены все состояния FSM и были ли пройдена все возможные пути перехода?
• Покрытие выражений/условий: В условных операторах, таких как if (A && B) были протестированы все комбинации True/False для A и B?

5.1.2 Функциональное покрытие

Даже если покрытие кода составляет 100%, функциональность не может считаться полной. Это связано с тем, что код может быть выполнен, но при этом могут отсутствовать значимые функциональные сценарии. Функциональное покрытие измеряет, были ли достигнуты сценарии, явно определенные инженерами с помощью covergroup и coverpoint.

• Перекрестное покрытие: Проверяет комбинации двух или более переменных. Например, определяет сложные ситуации, такие как «когда тип пакета — Video, а буфер одновременно — Full».
• Бины: Делит диапазон значений, которые может принимать переменная (бинирование)и проверяет, что все значения в определенном диапазоне произошли.

5.2 Стратегия исключений: исключение невозможного и бессмысленного

Реально, достижение 100% покрытия всего кода проекта иногда может быть невозможным или неэффективным. В этом случае требуется процесс исключений. Исключения — это не просто уловка для завышения показателей покрытия, а скорее процесс предоставления инженерного обоснованиядля непроверенных разделов.

Отступления от правил управляются с помощью текстовых файлов или графического интерфейса инструмента. При каждом изменении кода RTL существующие отступления должны пересматриваться, чтобы гарантировать их действительность. Неправильные отступления могут стать лазейками, скрывающими критические ошибки.

CDC и RDC будут рассмотрены отдельно в другой статье.

Заключение: Шлюз к синтезу, критерии утверждения для проверки проекта">Заключение: вход в синтез, критерии утверждения для проверки проекта

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

1. Регрессионная проверка: все определенные наборы тестов прошли без ошибок.
2. Закрытие покрытия: покрытие кода и функциональное покрытие достигли целевых значений (обычно 100% или согласованного значения), а любые недостатки были должным образом одобрены посредством отступления.
3. CDC/Lint Clean:Все проблемы пересечения тактовых доменов и нарушения стиля кодирования RTL были устранены с помощью инструментов статического анализа. Только при выполнении всех этих условий код RTL объявляется «замороженным».Этот RTL-код больше не будет изменяться и теперь готов для перехода к этапу логического синтеза, который будет рассмотрен в следующей части, где он будет преобразован в сетевой список на уровне вентилей.Действительно, определение момента, когда следует выполнить заморозку RTL, является одним из трех наиболее важных этапов в проекте ASIC. Своевременное завершение этого этапа позволяет быстро завершить последующие этапы проектирования, гарантируя, что проект полупроводника будет готов к производству к запланированной дате. проектов в график производственного процесса. Не забывайте, что верификация — это не просто тестирование, а последний бастион, гарантирующий качество и надежность чипа, а также самый важный инженерный процесс." class="kg-image" alt="" loading="lazy" width="1600" height="3156" srcset="https://www.vlsi.kr/content/images/size/w600/2026/01/image-46.png 600w, https://www.vlsi.kr/content/images/size/w1000/2026/01/image-46.png 1000w, https://www.vlsi.kr/content/images/2026/01/image-46.png 1600w" sizes="(min-width: 720px) 720px">