Функциональная верификация HDL-кода

Функциональная верификация HDL-кода

Пермяков Валерий, НПП «ЦРТС»

Терминология 1|22

I Верификация — комплекс функциональныхпроверок, выявляющих, соответствует ли реализациясистемы предъявляемым к ней требованиям итехническому заданию.

I Валидация — определение, соответствуют литребования и техническое задание здравому смыслу.

I Тестирование — полномасштабная проверкаразличных аспектов работы готового устройства.

О чем будет речь? 2|22

План доклада:

I Вкратце ознакомимся с процессом разработкицифровых схем;

I Рассмотрим различия между тестированием ифункциональной верификацией;

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

Разработка цифровых схем 3|22

HDL — Hardware Description Language, язык описанияаппаратуры (Verilog, VHDL, AHDL).

RTL — Register-Transfer Level, уровень представленияцифровой схемы с помощью пересылок сигналов междуотдельными регистрами.

HDL-код 4.1|22

// Verilog HDLmodule adder(

input [7:0] input_a ,input [7:0] input_b ,input carry_in ,output [8:0] result

);

assign result = input_a + input_b + carry_in;

endmodule

Подобный код используется для синтеза и симуляции.

Синонимы:I HDL-код;I Функциональное описание;I Модель (потому что можно запускать в симуляторе).

HDL-код 4.2|22

// Verilog HDL// This code cannot be synthesizedmodule test;

initialbegin

#10;$display("Hello world!");$finish ();

endendmodule

Подобный код используется только для симуляции.

Синонимы:I HDL-код;I Функциональное описание;I Модель (потому что можно запускать в симуляторе).

Тестирование цифровых схем 5|22

Верификация — правильно ли работает HDL-код всимуляторе?

Тестирование — правильно ли работает готовоеустройство, полученное на основе синтеза HDL-кода?

Верификация HDL-кода 6|22

Как же провести верификацию HDL-кода?

1. Анализируем требования.

2. Составляем тесты для проверки требований.

3. Запускаем HDL-код в симуляторе. Запускаем тесты.

4. Смотрим, какие тесты пройдены, а какие нет.

Всё довольно очевидно. . .Не так ли?

Верификация HDL-кода 7.1|22

Сложность и количество информации могут довольнобыстро сразить даже стойкого тестировщика. . .

Верификация HDL-кода 7.2|22

Сложность и количество информации могут довольнобыстро сразить даже стойкого тестировщика. . .

Верификация HDL-кода 7.3|22

Сложность и количество информации могут довольнобыстро сразить даже стойкого тестировщика. . .

Верификация HDL-кода 7.4|22

Сложность и количество информации могут довольнобыстро сразить даже стойкого тестировщика. . .

Что же делать? 8|22

Не отступать! Мы рассмотрим:

I Какие существуют подходы к верификации HDL-кода;

I С какими трудностями сопряжено применение тогоили иного подхода;

I Как успешно расставить приоритеты и провестиверификацию.

Тестовое окружение 9.1|22

DUT — Device Under Test, функциональное описание(HDL-код) тестируемого устройства.

Testbench — тестовое окружение, инкапсулирующеепроверяемое устройство.

Тестовое окружение 9.2|22

DUT — Device Under Test, функциональное описание(HDL-код) тестируемого устройства.

Testbench — тестовое окружение, инкапсулирующеепроверяемое устройство.

Тестовое окружение 9.3|22

// DUT source codemodule adder(

input [7:0] input_a ,input [7:0] input_b ,input carry_in ,output [8:0] result

);

assign result = input_a + input_b + carry_in;

endmodule

DUT — Device Under Test, функциональное описание(HDL-код) тестируемого устройства.

Testbench — тестовое окружение, инкапсулирующеепроверяемое устройство.

Тестовое окружение 9.4|22

// Testbench source codemodule adder_test;

reg [7:0] input_a;reg [7:0] input_b;reg carry_in;reg [8:0] result;

// Instantiating (creating) DUTadder adder_inst(input_a , input_b , carry_in , result);

// Add test logic here: <...>endmodule

DUT — Device Under Test, функциональное описание(HDL-код) тестируемого устройства.

Testbench — тестовое окружение, инкапсулирующеепроверяемое устройство.

Направленные тесты 10|22

Направленное тестирование (directed testing) даетравномерный, легко прогнозируемый и измеримыйпрогресс по выполнению (покрытию) плана верификации.

Направленные тесты 11|22

Преимущества направленных тестов:

I Измеримый, ясный прогресс.

I Не требуется подготовка инфраструктуры, легкоразвернуть для нового проекта.

I Не требуется изучать дополнительные технологии иинструменты.

I Возможно применять для встроенногосамотестирования устройства (BIST, Built-InSelf-Test).

Направленные тесты 12.1|22

Требование: двигатель не должен заглохнуть принормальной эксплуатации.

Сценарий 1: разгоняемся до 42 км/ч, включаем кассету сзаписью Андрея Макаревича, включаем правыйповоротник.

Направленные тесты 12.2|22

Несколько недель спустя. . .

Направленные тесты 12.3|22

Требование: двигатель не должен заглохнуть принормальной эксплуатации.

Сценарий 769: разгоняемся до 53 км/ч, открываемпереднее правое окно на 3

4 , дважды нажимаем на клаксонс интервалом в секунду.

Направленные тесты 13|22

Как протестировать такой сценарий?

Направленные тесты плохо масштабируются!

Принципы верификации 14.1|22

1. CRV (Constraint Random Verification) — верификацияна основе рандомизации входных данных.

Принципы верификации 14.2|22

1. CRV (Constraint Random Verification) — верификацияна основе рандомизации входных данных.

Что можно рандомизировать?

I Конфигурацию устройства.I Конфигурацию окружения.I Входные данные для DUT.I Внедряемые ошибки данных.I Внедряемые ошибки протокола передачи.I Задержки.

Принципы верификации 14.3|22

1. CRV (Constraint Random Verification) — верификацияна основе рандомизации входных данных.

// Length -> Address constraintconstraint c_addr{

(fields.length == ’d32) -> fields.addr == ’hFFFFFF;solve fields.length before fields.addr;

}

// <...>// Randomizationmy_packet.randomize () with{

fields.length >= ’d4;fields.length <= ’d64;

}

Принципы верификации 14.4|22

1. Контролируемая рандомизация2. Применение метрик

Принципы верификации 14.5|22

1. Контролируемая рандомизация2. Применение метрик

Что может выступать в роли метрик?I Функциональное покрытие кода.I Покрытие требований.I Производительность симулятора.I Статистическая информация о частях системы.I Время на разработку тестового окружения.

Принципы верификации 14.6|22

1. Контролируемая рандомизация2. Применение метрик3. Автоматизация и предсказание результата

Принципы верификации 14.7|22

1. Контролируемая рандомизация2. Применение метрик3. Автоматизация и предсказание результата4. Верификация на уровне транзакций

Принципы верификации 14.8|22

1. Контролируемая рандомизация2. Применение метрик3. Автоматизация и предсказание результата4. Верификация на уровне транзакций

Формат транзакции PCIe

При верификации PCIe имеет смысл оперироватьабстракциями подобного уровня, а не отдельнымисигналами.

Принципы верификации 14.9|22

1. Контролируемая рандомизация2. Применение метрик3. Автоматизация и предсказание результата4. Верификация на уровне транзакций5. Повторное использование компонентов

Принципы верификации 14.10|22

1. Контролируемая рандомизация2. Применение метрик3. Автоматизация и предсказание результата4. Верификация на уровне транзакций5. Повторное использование компонентов

Принципы верификации 14.11|22

1. Контролируемая рандомизация2. Применение метрик3. Автоматизация и предсказание результата4. Верификация на уровне транзакций5. Повторное использование компонентов

Принципы верификации 14.12|22

1. Контролируемая рандомизация2. Применение метрик3. Автоматизация и предсказание результата4. Верификация на уровне транзакций5. Повторное использование компонентов

Принципы верификации 14.13|22

1. Контролируемая рандомизация2. Применение метрик3. Автоматизация и предсказание результата4. Верификация на уровне транзакций5. Повторное использование компонентов

Принципы верификации 14.14|22

1. Контролируемая рандомизация2. Применение метрик3. Автоматизация и предсказание результата4. Верификация на уровне транзакций5. Повторное использование компонентов6. DFT (Design For Test) — тест-ориентированная

разработка.

Принципы верификации 14.15|22

1. Контролируемая рандомизация2. Применение метрик3. Автоматизация и предсказание результата4. Верификация на уровне транзакций5. Повторное использование компонентов6. Тест-ориентированная разработка.

ABV (Assertion-Based Verification) — верификация наоснове утверждений («ассёртов»).

Принципы верификации 14.16|22

1. Контролируемая рандомизация2. Применение метрик3. Автоматизация и предсказание результата4. Верификация на уровне транзакций5. Повторное использование компонентов6. Тест-ориентированная разработка.

Разработчики! Уважайте труд тестировщиков, и тогдапроводить верификацию будет проще!

Масштабируемость тестирования 15.1|22

I Направленные тесты позволяют получить первыерезультаты сразу.

I Если применять описанные принципы верификации,польза будет получена в перспективе.

Масштабируемость тестирования 15.2|22

I Направленные тесты позволяют получить первыерезультаты сразу.

I Если применять описанные принципы верификации,польза будет получена в перспективе.

Chicken

I Chicken chicken chicken chicken: chicken chicken.I Chicken chicken chicken “chicken” chicken.I Chicken Chicken chicken chicken, chickens-chicken chicken

chicken.I Chicken chicken chicken chicken chicken chicken chicken

chicken (Chicken-Chicken Chicken) chicken CHICKEN.

CC Chickens: C.3.2 [Chickens]: Chicken Chickens-chicken/chickenchicken; C.3.4 [Chicken chicken]: Chicken chicken chicken-chickens;C.2.4 [Chicken-chicken chickens]: Chicken/Chicken, chickenchickens.

chicken.chicken.comchickens.chickeeen.org/ch/chicken

Трудности на пути 16.1|22

Почему описанные принципы верификации сложноприменять?

I Нужно проделать большую работу.

I Люди сопротивляются изменениям.I Требуются не только новые инструменты и обучение

сотрудников, но и комплексный взгляд напланирование.

I Большие изменения требуют времени. Приходитсярасставлять приоритеты!

I Законченные тестовые окружения зачастую создать нелегче, чем само тестируемое устройство.

I Необходимо сопровождение, документирование ианализ процесса.

Трудности на пути 16.2|22

Почему описанные принципы верификации сложноприменять?

I Нужно проделать большую работу.I Люди сопротивляются изменениям.

I Требуются не только новые инструменты и обучениесотрудников, но и комплексный взгляд напланирование.

I Большие изменения требуют времени. Приходитсярасставлять приоритеты!

I Законченные тестовые окружения зачастую создать нелегче, чем само тестируемое устройство.

I Необходимо сопровождение, документирование ианализ процесса.

Трудности на пути 16.3|22

Почему описанные принципы верификации сложноприменять?

I Нужно проделать большую работу.I Люди сопротивляются изменениям.I Требуются не только новые инструменты и обучение

сотрудников, но и комплексный взгляд напланирование.

I Большие изменения требуют времени. Приходитсярасставлять приоритеты!

I Законченные тестовые окружения зачастую создать нелегче, чем само тестируемое устройство.

I Необходимо сопровождение, документирование ианализ процесса.

Трудности на пути 16.4|22

Почему описанные принципы верификации сложноприменять?

I Нужно проделать большую работу.I Люди сопротивляются изменениям.I Требуются не только новые инструменты и обучение

сотрудников, но и комплексный взгляд напланирование.

I Большие изменения требуют времени. Приходитсярасставлять приоритеты!

I Законченные тестовые окружения зачастую создать нелегче, чем само тестируемое устройство.

I Необходимо сопровождение, документирование ианализ процесса.

Трудности на пути 16.5|22

Почему описанные принципы верификации сложноприменять?

I Нужно проделать большую работу.I Люди сопротивляются изменениям.I Требуются не только новые инструменты и обучение

сотрудников, но и комплексный взгляд напланирование.

I Большие изменения требуют времени. Приходитсярасставлять приоритеты!

I Законченные тестовые окружения зачастую создать нелегче, чем само тестируемое устройство.

I Необходимо сопровождение, документирование ианализ процесса.

Трудности на пути 16.6|22

Почему описанные принципы верификации сложноприменять?

I Нужно проделать большую работу.I Люди сопротивляются изменениям.I Требуются не только новые инструменты и обучение

сотрудников, но и комплексный взгляд напланирование.

I Большие изменения требуют времени. Приходитсярасставлять приоритеты!

I Законченные тестовые окружения зачастую создать нелегче, чем само тестируемое устройство.

I Необходимо сопровождение, документирование ианализ процесса.

Внедрение новых подходов 17.1|22

Внедрение новых подходов 17.2|22

Внедрение новых подходов 17.3|22

Что же делать? 18.1|22

Планировать!

Проводить декомпозицию задач, идти от общего кчастному, ясно понимая стоящую цель.

Но какова цель?

Что же делать? 18.2|22

Планировать!

Проводить декомпозицию задач, идти от общего кчастному, ясно понимая стоящую цель.

Но какова цель?

Какой подход выбрать? 19|22

Цель: в отведенное время максимальновыполнить план верификации.

Как добиться цели? На основе планирования ианализа выбрать подходящую стратегию!

Какой подход выбрать? 20.1|22

Классические направленные тесты:

I Легко развернуть.I Не нужно изучать новых языков, инструментов,

методик.I Могут применяться для встроенного

самотестирования (BIST).

Применение принципов верификации:

Какой подход выбрать? 20.2|22

Классические направленные тесты:

I Легко развернуть.I Не нужно изучать новых языков, инструментов,

методик.I Могут применяться для встроенного

самотестирования (BIST).

Применение принципов верификации:

Какой подход выбрать? 20.3|22

Классические направленные тесты:

I Легко развернуть.I Не нужно изучать новых языков, инструментов,

методик.I Могут применяться для встроенного

самотестирования (BIST).

Применение принципов верификации:

1. Рандомизация2. Метрики3. Автоматизация

4. Транзакции5. Переиспользование6. Design-for-Test

Какой подход выбрать? 20.4|22

Классические направленные тесты:

I Легко развернуть.I Не нужно изучать новых языков, инструментов,

методик.I Могут применяться для встроенного

самотестирования (BIST).

Применение принципов верификации:

I Масштабируемые, гибкие тестовые окружения.I Возможность переиспользования компонентов.I Высокоуровневое, не зависимое от конкретной

реализации описание тестов.

Итог 21|22

Соизмеряйте цели и средства!

И главное — планируйте!

Контактная информация 22|22

Валерий Пермяковинженер по верификации

FPGA

valery.permyakov@gmail.comv.permyakov@npp-crts.ru

www.npp-crts.ru

LinkedIn profile:

Backup

Рекомендованная литература

I SystemVerilog For Verification, Chris SpearI Verification Intellectual Property Recommended Practices,

Accelera Systems InitiativeI Verification Methodology Manual for SystemVerilog, Janick

Bergeron, Eduard Cerny, Alan Hunter, Andrew NightingaleI UVM Cookbook, Mentor Graphics, Verification AcademyI Verification Academy Online Courses, Mentor Graphics,

Verification Academy

Backup

I Расширение языка Verilog («Verilog с классами»).I Утвержден организацией IEEE Standards Association.I Применяется для описания как синтезируемых цифровых

схем, так и для создания тестовых окружений.I Поддерживается различными вендорами: Cadence, Mentor,

Synopsys и др.

www.systemverilog.orgstandards.ieee.org/getieee/1800

Backup

UVM (Universal Verification Methodology)

I Стандартизированная методология верификациицифровых схем.

I Утверждена в качестве стандарта организацией AccelleraSystems Initiative.

I Реализована в виде набора библиотек для SystemVerilog.I Поддерживается различными вендорами: Aldec, Cadence,

Mentor, Synopsys.

www.accelera.org verificationacademy.com

Backup

I Набор библиотек C++ для описания цифровых схем.I Утвержден организацией IEEE Standards Association.I Разработан организацией Open SystemC Initiative.I Поддерживается различными вендорами: Aldec, Cadence,

Mentor, Synopsys и др.I Некоторыми вендорами поддерживается не только

симуляция, но и высокоуровневый синтез (High-LevelSynthesis) в RTL.

www.systemc.orgstandards.ieee.org/getieee/1666

Backup

Список аббревиатур

HDL — Hardware Description Language

RTL — Register-Transfer Level

DUT — Device Under Test

BIST — Built-In Self-Test

CRV — Constraint Random Verification

UVM — Universal Verification Methodology

DFT — Design For Test/Testing/Testability

ABV — Assertion-Based Verification