Сегодня, в субботу, 26 февраля, в Школе синтеза цифровых схем «Сколково» Михаил Коробков проводит урок, посвященный технологиям функциональной верификации: решатели ограничений, контейнеры покрытий и параллельные утверждения.
Примеры, которые мы подготовили для школы, вращаются вокруг протокола AXI для систем на кристалле, вопросы о котором задаются, например, на собеседованиях в аппаратном отделе компании «Мета» и других.
На предыдущих школьных занятиях мы в основном изучали аспект проектирования на языке описания аппаратного обеспечения Verilog. Но как уже заметили участники, Verilog — это не только язык описания и синтеза схем, но и язык программирования для написания тестов.
В некоторых компаниях на каждого инженера, пишущего код verilog на уровне передачи регистров, приходится два-три инженера, пишущих проверочный код. Суть деятельности Верификатора заключается в создании фреймворков, проверяющих аппаратные конструкции на прочность, отправляя в них псевдослучайные транзакции и учитывая покрытие интересных сценариев (функциональное покрытие).
Хороший инженер-проектировщик RTL должен знать основные элементы этих технологий.
Приглашаем вас присоединиться к трансляции урока на YouTube-канале школы, в субботу 26 февраля с 12.00 до 15.00: Как выглядит процесс проверки блока микросхем, описанный на уровне передачи регистров (RTL): 
Малейшая ошибка в описании схемы на уровне передачи регистров (код RTL) может привести к необходимости перевыпуска микросхемы на заводе (респин ASIC) и потерям в десятки миллионов долларов.
Особенно серьезные последствия могут возникнуть, когда компания упускает время для выпуска нового чипа, а лидером рынка становятся конкуренты.
Поэтому электронные компании используют развитые и совершенные методы контроля качества.
Одна голова хорошо, а три головы лучше.
Поскольку корень крупнейших ошибок — неоднозначность интерпретации функциональной спецификации (fSpec), в отрасли используется концепция реконвергенции.
Он сравнивает интерпретацию спецификации RTL, сделанную инженером, с интерпретациями двух других людей — инженера по моделированию и инженера по верификации:
- Для каждого значимого RTL-блока пишется поведенческая или функциональная модель — просто программа, которая на основе входных данных и внутреннего состояния, не пытаясь сделать что-либо эффективно, реализует поведение блока согласно спецификации.
Эта программа написана инженером-симулятором на основе его видения fSpec. Программа может быть на SystemVerilog, C и даже Python, если скорость работы модели на компьютере не критична.
- Инженер по верификации под руководством менеджера по верификации составляет план испытаний на основе своего восприятия fSpec. В плане описаны сценарии работы блока и для каждого случая указано, как его автоматически проверить, сравнивая поведение RTL блока и модели, а также как проверить (тоже автоматически), что данный сценарий произошел.
во время тестирования.
Последнее называется «проверкой функционального покрытия».
- План тестирования рассматривается, после чего на его основе на языке SystemVerilog пишутся тестовая среда, тесты и специальные конструкции, называемые «группами покрытия».
Последнее необходимо для контроля того, чтобы все тесты, обещанные в плане тестирования, были действительно написаны.
- Многие тесты проводятся с использованием ограниченно случайных данных и ограниченно случайных последовательностей событий с течением времени.
Для этой цели в языке SystemVerilog имеется встроенный генератор случайных данных на основе правил зависимостей (constraintsolver).
В сочетании с тестированием функционального покрытия такие тесты позволяют генерировать сценарии, о которых инженер, пишущий тесты, не подумал.
Например, у NPU может возникнуть ситуация, когда транзакции через две независимые шины AXI в многобанковую память, в которой расположены веса и поток команд, начинают конфликтовать и вызывать ошибки, когда расстояние между ними составляет ровно 3 такта, и не 0, не 1 и не 10.
- Возможно, функциональная спецификация не описывает все аспекты блока, и инженер RTL добавил к блоку на основании устного соглашения с архитектором.
Инженер по проверке может не знать об этом и не проводить дополнительные испытания.
После этого при запуске тестов в журнале может появиться сообщение «100% покрыто», хотя это не будет соответствовать действительности (часть реализованного функционала не будет покрыта тестами).
В этом случае методология использует страховку в виде автоматической проверки покрытия кода во время моделирования — она выявит RTL-код, который не участвовал в процессе тестирования.
Картина отсюда .
Теги: #Производство и разработка электроники #математика #Алгоритмы #ASIC #Системный анализ и проектирование #FPGA #verilog #systemverilog #systemverilog #симуляция #верификация #программирование в ограничениях #функциональное покрытие #временная логика #проверка чипа
-
Войдите В Мир Контекстной Рекламы
19 Oct, 24 -
Баг В Платежных Терминалах Петроэлектросбыта
19 Oct, 24 -
Как Мы Практикуем Коридорное Тестирование
19 Oct, 24 -
Младший Ios-Разработчик. Путь Формирования
19 Oct, 24 -
Нло Забрал Денискин?
19 Oct, 24
