«Работать добросовестно — значит: работать, повышая свою квалификацию, проявляя инициативу в совершенствовании продукции, технологий, организации работ, оказывая не предусмотренную должностными инструкциями помощь другим сотрудникам (включая и руководителей) в общей им всем работе.

Проектирование цифровых систем на языках описания аппаратуры/Лекция 10

Материал из Wiki
Перейти к: навигация, поиск
Лекции ПЦСЯОА
Лекции
Практические
Доп. материалы
Slide Show
Slide Show
Заголовок
Верификация VHDL описаний цифровых систем
Автор
Ланкевич Ю.Ю.
Нижний колонтитул
Проектирование цифровых систем на языках описания аппаратуры/Лекция 10
Дополнительный нижний колонтитул
Ланкевич Ю.Ю., 00:29, 19 октября 2020


Слайд:Актуальные проблемы верификации

Этап проверки соответствия описания логических схем спецификации.
Объект верификации (ОВ) часто называют DUT (Design Under Test).

Актуальные проблемы верификации:

  • размер объекта верификации постоянно растет. Даже небольшая ИМС типа “микроконтроллер” — это набор из десятков подмодулей, очень часто со сложным функционалом. Большие ИМС — это комплексы, в которых может насчитываться до десятков миллиардов транзисторов, и одна только схема управления электропитанием по сложности может превосходить некоторые процессоры;
  • высокая цена ошибки (от десятков тысяч долларов до десятков миллионов долларов);
  • невозможно составить спецификацию на ИМС в начале проекта и в дальнейшем только следовать ей, она постоянно изменяется на протяжении всего процесса разработки (заказчик изменяет требования, технические проблемы или обнаружение более оптимальных решений вынуждают пересматривать подходы и т.д.). Исходя из этого, * все процессы должны в динамике воспринимать изменения спецификации и модифицироваться в соответствии с требованиями;
  • часто над верификацией проекта работает несколько удаленных друг от друга команд численность которых может достигать десятков человек;
  • количества отдельных тестов и их типов достигает огромного числа, результаты их надо собирать и анализировать;
  • моделирование цифровых систем требует много машинного времени и вычислительных ресурсов;
  • полнота установленных для проекта целевых показатели готовности во многом зависит от компетентности и интуиции специалистов по верификации;
  • несмотря на существование показателей охвата проекта тестами (метрик), единственный способ закончить верификацию — это принять решение о ее приостановке, основываясь в основном на следующих заключениях: деньги или время на этап проекта потрачены, необходимо запускать в производство, вроде как достигли покрытия кода в 100%, тестируем уже неделю и ошибок не обнаружили и т.п.

Слайд:Типы верификации

Верификацию можно разделить на следующие шаги:

  • Функциональная верификация (Functional Verification) – проверка всех функциональных параметров и характеристик СБИС на логическом уровне. Если моделирование не дает корректных результатов, то этап логического проектирования (исправление ошибок проектирования) повторяется до достижения успеха.
  • Формальная верификация (Formal Verification) - устанавливается эквивалентность представлений системы на разных стадиях маршрута проектирования или выполнение утверждений, помещенных в исходный код:
    • Equivalence Checking (например, RTL-to-RTL, RTL-to-Gate, Gate-to-Gate);
    • Property Checking (Model Checking) - проверяет свойства(assertions), заданные в коде средствами SVA (SystemVerilog Assertions) или PSL (Property Specification Language).
  • Cтатический анализ кода (static code analysis) — проверка исходного кода по формальным критериям на соблюдения правил использования языка и его конструкций. Программы для такой проверки обычно обозначаются как lint или linter;
  • Прототипирование — использование FPGA для функциональной проверки.
  • Физическая верификация — в основном подразумевается DRC, LVS, PERC и пр. проверки, физическое представление системы проверяется на соблюдение технологических норм и соответствия физического и логического представлений и т.д. Состав проверок сильно зависит от технологии. Обычно физическая верификация проводится инженером или командой топологического проектирования

Функциональная верификация в объеме всех работ наиболее значительна и требует непосредственного участия человека. Статический анализ кода требуют только первоначальной настройки инструментов, которая соответствует внутренним правилам проектирования, принятым в компании, дальше данный инструмент можно использовать без дополнительных трудозатрат. Инструменты формальной верификации часто тоже весьма самостоятельны, требует только внимательного анализа отчетов, которые они генерируют.

Источник — «http://www.simhard.com/wiki/index.php?title=Проектирование_цифровых_систем_на_языках_описания_аппаратуры/Лекция_10&oldid=7250»