Изучить методы и компьютерные средства

• алгоритмического, функционального и структурного описания цифровых систем на формальных языках проектирования на примере языка VHDL (Very high speed integrated circuits Hardware Description Language)
• моделирования проектов цифровых систем и устройств
• верификации проектов цифровых систем и устройств
• схемной реализации проектов цифровых систем и устройств.

Язык VHDL является международным стандартом в области автоматизации проектирования цифровых систем, это входной язык многих современных систем автоматизированного проектирования (САПР) как заказных, так и программируемых логических интегральных схем (ПЛИС) – Programmable Logic Devices (PLD) – и программируемых пользователями вентильных матриц – Field-Programmable Gate Arrays (FPGA). VHDL предназначен, в первую очередь, для спецификации – точного описания проектируемых систем и их моделирования на начальных этапах проектирования – алгоритмическом и логическом.

Для оценки сложности интегральных схем используется единица эквивалентного вентиля (например 2-входовый И-НЕ),
который соответствует 4-м эквивалентным транзисторам. Уровни интеграции цифровых интегральных схем принято делить на следующие группы:

• SSI - Small scale integration или МИС - малая интегральная схема с десятками и сотнями эквивалентных вентилей.
• MSI - Medium scale integration или СИС - средняя интегральная схема с тысячами вентилей.
• LSI - Large scale integration или БИС - большая интегральная схема с сотнями тысяч вентилей.
• VLSI – Very large scale integration или СБИС - Сверхбольшая Интегральная Схема с несколькими миллионами вентилей.
• USLI – Ultra large scale integration или УБИС - УльтраБольшая Интегральная Схема.

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

Кроме того интегральные схемы условно делятся на группы специализированных применений (ASIC - Application Specific Integrated Circuit) и коммерческие интегральные микросхемы общего применения, как массовые микропроцессоры и серийные наборы микросхем. С развитием технологий производства и повышением степени интеграции появилось такое понятие как системы на кристалле (СнК) или Systems-on-Chip (SoC), которые представляют собой комбинацию специализированных и универсальных процессорных ядер и блоков, выполненных на единой кремниевой подложке.

СБИС также различаются по полупроводниковой технологии исполнения:

• TTL или ТТЛ - транзисторно-транзисторная логика на биполярных транзисторах
• ECL или ЭСЛ - эмиттерно-связанная логика
• MOS - NMOS, CMOS или МОП, НМОП и КМОП логика.

• Полнозаказные СБИС (Full-Custom ASICs)
• Полузаказные матричные СБИС на основе стандартных ячеек-модулей (StandardCell–Based ASICs)
• Полузаказные СБИС на основе матрицы вентилей (Gate-Array–Based ASICs)
  • Канальные матрицы вентилей (Channeled Gate Array)
  • Бесканальные матрицы вентилей (Channelless Gate Array), наиболее популярные в настоящее время
  • Структурированные матрицы вентилей (Structured Gate Array)
• СБИС программируемой логики c макроячейками или макроблоками (Complex Programmable Logic Devices or CPLDs) или ПЛИС
• СБИС программируемой логики c микроячейками или базовыми блоками (FieldProgrammable Gate Arrays or FPGA)

Каждый тип СБИС имеет свою нишу на рынке, которая определяется массовостью применения приборов
и изделий, а также степенью универсальности характеристик СБИС. Все эти типы СБИС различаются стоимостью проектирования и изготовления, в случае ПЛИС разработчик использует готовые СБИС, программируя их
для своих приложений, что дает минимальную цену подготовки производства, которую называют
NRE – non-recurring engineering cost.

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

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

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

• Используется также аббревиатура CBIC —“sea-bick (Сell-based ASIC)
• Используются библиотеки стандартных элементов
• Возможно использование предварительно спроектированных мега-ячеек, мегафункций, полнозаказных мега-ячеек, системных макросов, блоков с фиксированными функциями, готовых процессорных ядер (IP-ядер) от других поставщиков, или стандартных функциональных блоков
• Все слои масок являются заказными – размещение транзисторов и все соединения между ними
• Автоматизированное изменение размерности буферов, размещение блоков и трассирование межсоединений
• Полнозаказные блоки легко могут быть встроены в структуру СБИС без проблем (если спроектированы под ту же технологию)
• Ориентировочное время производственного цикла с момента получения топологии в виде GDS файла около восьми недель

Этот тип полузаказных СБИС является базовой кремниевой платформой для современных систем на кристалле (СнК или SoC).

Так как с точки зрения свободы размещения блоков и макроблоков этот тип СБИС близок к полнозаказной и отличается только использованием заранее спроектированных библиотечных элементов и макроблоков, то размещение базовых транзисторов может быть совершенно произвольным и определяется макрокомпоновкой топологии полузаказной СБИС. Библиотечные элементы-ячейки в такой СБИС могут располагаться в виде матрицы, имеющей определенное число строк и столбцов, пресечениями которых являются логические элемент-ячейки. Между строками и столбцами могут оставляться пространства (каналы) для разводки межсоединений. И полузаказная структура СБИС строится путем соединения этих ячеек-элементов в логические схемы в соответствии с принципиальной схемой логического устройства, оформленной в виде списка логических сетей в формате EDIF или структурного кода VHDL/Verilog.

В матрице вентилей позиции всех транзисторов на пластине предопределены нижними слоями топологических масок, которые являются общими для всех вариантов СБИС. Эта предопределенная топология размещения транзисторов называется базовой матрицей, поэтому такие СБИС часто называют базовыми матричными кристаллами (БМК).

• Наименьший элемент, который повторяется в матрице, называется базой или ячейкой-примитивом
• Верхние уровни соединений между транзисторами определяются разработчиками СБИС в заказных масках верхнего уровня для формирования матрицы вентилей – Masked Gate Array (MGA)
• Проектирование выполняется путем соединения предпроектированных и заранее верифицированных библиотечных логических элементов (макроблоков)

После предварительной проверки реализуемости СБИС на уровне библиотечных элементов и макроблоков используется, как правило, автоматическое размещение и трассировка для преобразования в топологию СБИС с использованием ячеек-примитивов базовой матрицы.

Существуют три типа базовых матричных СБИС:

• Канальные матричные СБИС (Channeled Gate Array)
• Бесканальные матричные СБИС (Channelless Gate Array)
• Структурированные матричные СБИС (Structured Gate Array)

Особенности канальных матричных СБИС (Channeled Gate Array)

• Разработчиком проектируются только межсоединения между вентилями и соответственно изготовляются только верхние слои масок
• Межсоединения используют изначально предопределенны промежутки (каналы) между линейками базовых элементов
• Так как могут быть использованы предобработанные пластины с выполненными нижними слоями топологии, то резко снижается время прои который может длиться от двух дней до двух недель в зависимости от числа заказных верхних слоев металлизации межсоединений

Особенности бесканальных матричных СБИС (Channelless Gate Array)

• Их также называют «Море вентилей» (Sea-of-Gates)
• В таких матричных кристаллах нет предопределенных промежутков для трассирования межсоединений, межсоединения идут поверх базовых элементов матрицы
• Достижимая плотность размещения логических блоков значительно выше по сравнению с канальными матричными СБИС, что приводит к уменьшению кристалла
• Так как могут быть использованы предобработанные пластины с выполненными нижними слоями топологии, то резко снижается время производственного цикла СБИС, который может длиться от двух дней до двух недель в зависимости от числа заказных верхних слоев металлизации межсоединений.

Особенности структурированных матричных СБИС (Structured Gate Array)

• Заказчик проектирует только межсоединения вентилей матрицы
• Полнозаказные блоки могут быть встроены в конкретный вариант СБИС (для всей серии, имеющей определенную структуру)
  • Это могут быть функционально завершенные блоки как процессоры, разного рода контроллеры или модули памяти
  • И/или это могут быть матрицы базовых вентилей другого типа, которые больше подходят для выполнения специфической функции
• Длительность производственного цикла структурированной матричной СБИС от двух дней двух недель в зависимости от числа заказных верхних слоев металлизации межсоединений.

На рисунке ниже приведена структура матрицы вентилей с выделенными каналами для межсоединений, бесканальной и структурированной матрицы ветелй (A, B и C соответственно).

Рассмотрим упрощенный маршрут проектирования СБИС, который включает ряд этапов, взаимосвязь которых отображена на рисунке ниже. В реальности маршрут проектирования выглядит сложнее, но в любом случае он содержит верификацию, логическое проектирование СБИС (front-end design) и физическое проектирования СБИС (back-end design).

Этап описания логических схем (не учитывается технология, физические,электрические и другие характеристики). Описывается комбинационная логика, триггеры и связи между элементами схемы. Для описания используются такие языки, как VHDL, Verilog, SystemC. Результатом является логическая схема на уровне регистровых передач (RTL).

В данном этапе можно выделить нексолько дополнительных шагов:

• Формальное описание проекта (Design entry) – Проектирование СБИС осуществляется с использованием либо разработанной принципиальной схемы, либо языка моделирования аппаратных средств (Verilog, VHDL, SystemC). В обоих случаях используются специальные срества САПР от производителей Сadence, Synopsys, Mentor Graphics.
• Логический синтез (Logic synthesis) – Средства САПР от производителей, указанных выше обеспечивают генерацию списка логических вентилей и их межсоединений (netlist)
• Разбиение на модули (System partitioning) – Большая система (top level) разбивается на модули (sub-system level), которые в свою очередь могут быть разбиты на ещё более мелкие блоки (block level).

Цифровая система может быть описана на уровне поведения посредством описания функций, реализуемых системой, и на структурном уровне.
Структурное описание – это описание системы в виде совокупности компонент (подсхем, элементов) и связей между компонентами.
Поведенческое описание – это описание системы при помощи некоторых процедур на уровне зависимостей выходов от входов. Иначе говоря, поведенческое описание задает алгоритм, реализуемый системой.
Цифровая система может быть сложной, как, например, микропроцессор или весьма простой, как логическая схема, состоящая из нескольких логических элементов (вентилей). Некоторые компоненты системы в структурном описании могут состоять из нескольких частей – компонент более низкого уровня иерархии описания. Представляя отношение вхождения подсхем в схемы в виде графа, можно получить дерево (граф) иерархии описания всей системы.

Пусть цифровая система S реализует следующий алгоритм. На входные полюсы системы S подаются два двухразрядных числа a=(a2,a1), b=(b2,b1),
где a2, b2 – старшие разряды чисел a, b соответственно и x – управляющий сигнал.
Если x=1, система S должна перемножить числа a, b и выдать четырехразрядное число d=(d4,d3,d2,d1), где d= a×b.
Если x=0, то числа a, b должны быть сложены, при этом в разряде d4 всегда должен быть нуль, в разряде d3 – перенос c2, в разряде d2 – старший разряд суммы s2, в разряде d1 – младший разряд суммы s1. Предполагается, что
(a2,a1) + (b2,b1)= (с2,s2,s1).
Мы описали алгоритм, который должна реализовать система S, на русском языке. Однако для автоматизированного (компьютерного) проектирования требуется формальная спецификация.

Формальные спецификации должны быть записаны на соответствующем формальном языке. Позже будет показано, что алгоритм, реализуемый системой S, может быть очень коротко описан на языке VHDL.

Если же рассматривать структурный уровень описания системы S, то можно легко увидеть, что в систему S входит двухразрядный сумматор и двухразрядный умножитель.
Двухразрядный сумматор – это устройство для сложения двухразрядных чисел, двухразрядный умножитель – устройство для перемножения двух чисел, каждое из которых имеет только два разряда. В систему S должно входить также простейшее устройство управления и схема дизъюнктивного объединения выходных сигналов. Структура системы S изображена ниже.

adder_2 – двухразрядный сумматор, mult_2 – двухразрядный умножитель, YY – устройство управления, dd – схема дизъюнктивного формирования выходных сигналов. Схему dd образуют три дизъюнктора. Устройство управления YY является весьма простым и функционирует следующим образом: если x=0, то (a2,a1)=(f4,f3), (b2,b1)=(f6,f5), (f2,f1)=(0,0), т.е. числа a, b подаются на вход сумматора adder_2. Если же x=1, то (f4,f3)=(0,0), (f6,f5)=(0,0), (a2,a1)=(f2,f1), т.е. числа a, b подаются на вход умножителя mult_2.

Рассмотрим двухразрядный умножитель mult_2. На вход данной схемы поступают сигналы r1, r0, s1, s0.

	Сигналы r1, r0 интерпретируются как двухразрядное целое число r=(r1,r0), сигналы s1, s0 – как двухразрядное целое число s=(s1,s0). Выходные сигналы в t3, t2, t1, t0 представляют собой разряды числа t – произведения чисел s, r: (t3, t2, t1, t0) = (r1,r0)×(s1,s0).

В схему входят элементы двух типов – add1 и and2. Элемент and2 представляет собой логический элемент И – двухвходовый конъюнктор. Заметим, что на языке VHDL знак & употребляется не для обозначения логической операции "И" (конъюнкции), а для операции конкатенации векторов. Оператором логической конъюнкции служит оператор and, поэтому описание функции элемента and2 на языке VHDL выглядит следующим образом:

   y <= x1 and x2;

где x1, x2 – имена входных сигналов, у – имя выходного сигнала, <= – оператор назначения сигнала (будет рассмотрен позже).
Элемент add1 представляет собой одноразрядный полусумматор.

entity Test_add1 is
end Test_add1;
architecture Behavior of test_add1 is
    component add1 
        port (b1,b2 : in BIT;     -- в VHDL не различаются строчные
              c1,s1 : out BIT);  -- и прописные буквы
    end component;
    signal  b1, b2 :  BIT;
    signal  c1,  s1 : BIT;
    begin
        p1 : add1 port map (b1 => b1, b2 => b2, c1 => c1, s1 => s1);
        b1 <= '1',              -- входные воздействия
              '0' after 50 ns,
              '1' after 100 ns,
              '0' after 150 ns,
              '1' after 200 ns;
        b2 <= '1',              -- входные воздействия
              '1' after 50 ns,
              '1' after 100 ns,
              '0' after 150 ns,
              '0' after 200 ns, 
              '1' after 250 ns;
    end behavior;
--------------------------------------------------

Тестирующая программа для проверки правильности VHDL-модели полусумматора представляет собой текстовый файл test_add1.vhd. Файл test_add1.vhd находится в директории D:/Petrov, который называется рабочим директорием (директорием проекта)

После запуска программы ModelSim SE 6.1b открывается основное окно системы

В главном меню выбираем File → New → Project. Появится окно Create Project Указание имени проекта, места расположения проекта, имени рабочей библиотеки.

1. В окне Project Name укажем имя проекта ( pro_1)
2. В окне Project Location укажем рабочий директорий (d:/petrov )
3. В окне Default Library Name оставим имя work.
4. Нажмем OK.

В окне Add Items to the Project выбираем “Add Existing File”, так как VHDL-файлы с описанием цифрового дизайна и тестбенча уже имеются.
Они находятся в директории проекта d:/petrov. После выбора Add Exiting File появится окно Add file to Project

По очереди (с помощью Browser) находим в директории d:/petrov файл add1.vhd (VHDL-модель) и файл test_add1.vhd (VHDL-тест)
и добавляем их в проект (можно отметить несколько файлов и одновременно добавить их в проект). В окне Workspace поочередно,
в порядке их добавления, появляются имена добавляемых файлов, составляющих проект.

В главном меню выбратьм Compile → Compile Order , появится окно Compile Order. Рекомендуется выбрать Auto Generate и нажать OK. Если программы не содержат ошибок,
то в окне Workspace напротив имен файлов знак вопроса после компиляции заменяется “птичкой”. В этом окне можно вручную установить порядок компиляции файлов:
компиляция осуществляется согласно иерархии описания проекта – сначала на компиляцию должны поступать

• описания пакетов (в примере их нет),
• затем листовые описания (в примере это описание add1.vhd),
• затем описания, содержащие листовые описания, и т.д. (других листовых описаний нет),
• последнее описание – это тестирующая (головная) VHDL-программа (test_add1.vhd).

Если программа содержит ошибку, то в нижнем окне Transcript выдается сообщение. Двойной щелчок на сообщении об ошибке выдает строку VHDL-текста, в которой может быть ошибка (однако на самом деле ошибка может быть совершенно в другой строке – синтаксис VHDL сложный!!!). Выдача текста VHDL-программы для редактирования осуществляется двойным щелчком по имени соответствующего VHDL-файла.

# vcom_capture -work work -2002 -explicit D:/petrov/add1.vhd 
# Compile of add1.vhd was successful.
# vcom_capture -work work -2002 -explicit D:/petrov/test_add1.vhd 
# Compile of test_add1.vhd was successful.  

Выбрать в главном меню Simulate → Runtime Options, появится окно Runtime Options. Задать:

• Default Radix → Symbolic (формат представления данных),
• Default Run → 100 ns (время одного шага моделирования при пошаговом моделировании),
• Iteration Limit → 5000 (число событий моделирования, событие – изменение сигнала).

Остальное – по умолчанию, нажать OK

Выбрать в главном меню Simulate → Start Simulation, появится окно Start Simulation Раскрыть библиотеку work, выбрать (двумя щелчками) имя головной программы (test_add1), остальное – по умолчанию. Нажать OK.

Правильный результат выполнения старта моделирования, проект для моделирования прочитан без ошибок

В главном меню View → Debug Windows → Objects установить флаг (птичку) Objects, откроется окно Objects. Из этого окна мышью можно будет перетащить отдельные требуемые для наблюдения сигналы в окно Wave. Это окно может быть открыто командой View → Debug Windows → Wave.

В окне Objects в меню выполнить Add → Wave → Signals in Region. В результате все сигналы из окна Objects повторятся в окне Wave. Откроется окно Wave, появятся соответствующие команды в нижнем окне Transcript. Это есть другой способ перемещения сигналов из окна Objects в окно Wave.

Выполнить команду (Run All) в окне Wave, получить возможно визуально “сжатую” временную диаграмму, которую сложно воспринимать.
Остановить бесконечное (зациклившиеся) моделирование можно командой break в консольной области (окно Transcript), либо командой главного меню Simulate → Break, либо нажатием кнопки (Break) в окне Wave.
В нормальном случае текущее время моделирования непрерывно увеличивается. Текущее время выводится внизу окна Wave.
! Опасность бесконечного цикла состоит в том, что результат моделирования (файл временной диаграммы) “забьет” все свободное место на жестком диске. Удалить такой файл бывает трудно.

Чтобы “разжать” временную диаграмму, можно воспользоваться командами "Zoom In"/"Zoom Out" изменения масштаба времени. Выполнив одну из команд "Zoom In"/"Zoom Out", получим “читаемую” временную диаграмму.

Временную диаграмму можно сохранить и распечатать по команде Print. При выходе из системы моделирования в рабочем директории появятся:

• директорий work (в нем скомпилированные во внутреннее представление файлы проекта);
• системный файл pro_1.mpf сохраненного проекта цифровой системы (двойной щелчок вызовет систему моделирования и загрузит сохраненное состояние проекта);
• системный файл vsim.wlf временной диаграммы (двойной щелчок вызовет систему моделирования и откроет окно wave с сохраненной временной диаграммой).

При завершении работы в системе ModelSim директорий проекта запоминается и в следующем сеансе можно начать работу с проектом, выполнив команду File → Recent Directories и выбрав соответствующий рабочий директорий, либо выполнив команду File → Recent Project, выбрав ранее сохраненный проект

Этап проверки соответствия описания логических схем спецификации.
Объект верификации (ОВ) часто называют 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 и пр. проверки, физическое представление системы проверяется на соблюдение технологических норм и соответствия физического и логического представлений и т.д. Состав проверок сильно зависит от технологии. Обычно физическая верификация проводится инженером или командой топологического проектирования

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

Функциональная верификация — представляет собой набор тестов, которые условно можно разбить на три группы:

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

Первые две стадии поддаются автоматизации с помощью UVC/VIP(Universal Verification Component/Verification IP) и достаточно быстро там можно нарастить объем различных тестов, в том числе — генерируемых автоматически. Третья стадия требует неординарного подхода и опыта, очень сложно автоматизируется, т.к. большинство ситуаций — это отдельный алгоритм, возможно скрипт для САПР или инструкции для «ручных» проверок.

Для целей верификации часто используются такие языки как SystemVerilog, SystemC, VHDL, specman E. Для каждого из перечисленных языков существуют стандартные фреймворки (библиотеки).

• SystemVerilog: VMM, OVM, UVM.
• VHDL: OSVVM, UVVM.
• SystemC: UVM.
• Specman E: UVM.

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

Типы метрик:

• функциональное покрытие. Показывает на сколько полно проверены функции устройства. Критерии данного покрытия могут определяться планом тестирования и внедрением специальных конструкций (covergroup) в тестовое окружение и/или в объект верификации, отслеживающих выполнялась или нет та или иная функция/действие, изменялись ли определенным образом данные и т.п. Информация от конструкций, внедренных в исходный код, может быть автоматически собрана средствами САПР.
• покрытие кода — изменение состояния конструкций исходного кода в ходе тестов. Собирается автоматически средствами САПР, не требует внесения каких-либо конструкций в исходный код. Например:
  • переключение регистров/сигналов (Toggle Coverage);
  • активность каждой строки кода (Line Coverage);
  • активность выражений (Statement Coverage), по сути — это Line Coverage, но может отслеживать выражения которые больше, чем одна строка в редакторе;
  • активность участка кода внутри условного оператора или процедуры (Block Coverage), разновидность Statement Coverage;
  • активность всех веток условных операторов таких как if, case, while, repeat, forever, for, loop (Branch Coverage);
  • изменение всех состояний(true, false) составляющих логических выражений (Expression Coverage);
  • состояния конечного автомата (Finite-State Machine (FSM) Coverage).
• покрытие утверждений (assertions). Утверждения — это специальные языковые конструкции, которые отслеживают различные события и последовательности, и по заданным критериям определяют правомерность их возникновения.

Directed Tests Method (DTM)
Прямые, осмысленные тесты. Если принимается этот метод в проекте, то план верификации составляется из тестов направленных на проверку поведения устройства в конкретных интересующих точках (состояниях). Проверить все возможные ситуации, особенно в сложных проектах, почти не возможно. При этом проблемы, которые могут возникнуть в ситуациях не покрытых тестами не обнаруживаются до того, как устройство начинают использовать в реальных условиях. Обычно в этих тестах используются метрики функционального покрытия.
Coverage-Driven Verification, Metric-Driven Verification (CDV, MDV)
Концепция создания тестов, направленная на достижение определенного «тестового покрытия» DUT. Опираются на метрики, чтобы понять какие тесты необходимо добавить в план верификации, чтобы достигнуть целевых показателей готовности проекта. Необходимо использовать инструменты анализа покрытия, чтобы посмотреть, что еще добавить в план верификации. По-сути, если начать корректировать план верификации в DTM, опираясь хотя бы на “покрытие кода”, то уже можно считать, что от DTM плавно перешли к CDV.
Constrained Random Verification (CRV)
Верификация подачей случайных воздействий. Это действительно автоматические тесты с генерацией случайных воздействий на DUT. Метод очень затратный вначале, т.к. требуется длительное время на подготовку инструментов. После того как начальный этап подготовки пройден, то тестирование может запускаться автоматически, многократно с разными исходными данными. При выявлении несоответствия проверок или утверждений (checkers or assertions), команда разработчиков и верификаторов приступает к анализу выявленной ошибки. В реальном проекте нельзя ограничится только этим методом, т.к. этим методом можно собрать покрытие кода и покрытие утверждений, а они могут ничего не говорить о правильности работы DUT, т.е. соответствии спецификации. Его необходимо дополнять функциональными тестами. Для реализации данной методологии требуется:

• внедрить “утверждения”(assertion) или специальные проверки (checkers) во всех важных точках исходного кода DUT и тестового окружения;
• разработать генераторы случайных воздействий и сценарии их работы, т.е. воздействия случайны, но имеют ограничения диапазона (все перебрать не успеем), порядок подачи и т.п..

Assertion Based Verification (ABV)
Верификация с помощью утверждений. Наверное, это даже не самостоятельный метод, а некоторый компонент или базовая составляющая вышеупомянутых. Важным вопросом при ABV является как распределить assertions, какие из них лучше поместить в исходные код DUT, какие нужно иметь в тестовом окружении. Сразу стоит отметить, что язык Verilog не имеет assertions в своем стандарте (их можно создать с использованием основных конструкций языка, но необходимы директивы для синтезатора, чтобы он не занимался их преобразованием). Аssertions появляются только в стандарте SystemVerilog, а так же они изначально были в стандарте языка VHDL и e.

Этап построения топологии цифровой схемы (размещение логических элементов и проводников на поверхности кристалла) для конкретного технологического процесса с учётом всех производственных норм и характеристик.
Результатом является файл топологии интегральной схемы GDS II, который отправляется на фабрику.

Физическое проектирование можно разбить на следующие шаги:

• Топологическое размещение (Floorplanning) – Размещение модулей и блоков из списка логических вентилей и соединений на площади кристалла СБИС.
• Размещение базовых элементов внутри блоков (Placement) – Выбор размещения базовых библиотечных элементов в блоках.
• Трассирование и разводка межсоединений (Routing) – Соединение базовых библиотечных элементов, модулей и блоков между собой.
• Экстракция паразитных сопротивлений и емкостей межсоединений (Extraction) – Определяются паразитные емкости и сопротивления, порождаемые спроектированной топологией межсоединений.
• Postlayout simulation – Проверяется работоспособность будущей СБИС с добавленной паразитной нагрузкой на межсоединения. Если они не удовлетворяют требованиям по частоте и нагрузке, то предыдущие шаги повторяются до получения требуемого результата.

В рамках этапов физического моделирования производится также проверка соблюдения правил дизайна для технологии, по которой будет производиться СБИС (design rule check – DRC), также производится процесс обратной экстракции принципиальной схемы из физического топологии и используемых библиотек и производится сверка с исходной принципиальной схемой (netlist). Такая проверка называется сверкой топологии с принципиальной схемой (layout versus schematic check- LVS).

• А. К. Поляков, Языки VHDL и VERILOG в проектировании цифровой аппаратуры
• П. Н. Бибило, Основы языка VHDL
• Сайт с заданиями (задачи и лабараторные) и синтаксисом языка VHDL: http://vhdl.bas-net.by/
• Сайт для онлайн моделирования HDL проектов с помощью современных CAD систем различных фирм (без временных диаграмм): https://www.edaplayground.com/
• Сайт по верификации от Mentor Graphics: https://verificationacademy.com/
• Медиавики ресурс с лекциями по верификации и проектированию ЦС : http://simhard.com/wiki/index.php