SlideShare une entreprise Scribd logo
1  sur  65
Télécharger pour lire hors ligne
Функциональная верификация HDL-кода
Пермяков Валерий, НПП «ЦРТС»
Терминология 1|22
Верификация — комплекс функциональных
проверок, выявляющих, соответствует ли реализация
системы предъявляемым к ней требованиям и
техническому заданию.
Валидация — определение, соответствуют ли
требования и техническое задание здравому смыслу.
Тестирование — полномасштабная проверка
различных аспектов работы готового устройства.
О чем будет речь? 2|22
План доклада:
Вкратце ознакомимся с процессом разработки
цифровых схем;
Рассмотрим различия между тестированием и
функциональной верификацией;
Обозначим основные подходы к функциональной
верификации и сопряженные с ними сложности.
Разработка цифровых схем 3|22
HDL — Hardware Description Language, язык описания
аппаратуры (Verilog, VHDL, AHDL).
RTL — Register-Transfer Level, уровень представления
цифровой схемы с помощью пересылок сигналов между
отдельными регистрами.
HDL-код 4.1|22
// Verilog HDL
module 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
Подобный код используется для синтеза и симуляции.
Синонимы:
HDL-код;
Функциональное описание;
Модель (потому что можно запускать в симуляторе).
HDL-код 4.2|22
// Verilog HDL
// This code cannot be synthesized
module test;
initial
begin
#10;
$display("Hello world!");
$finish ();
end
endmodule
Подобный код используется только для симуляции.
Синонимы:
HDL-код;
Функциональное описание;
Модель (потому что можно запускать в симуляторе).
Тестирование цифровых схем 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
Не отступать! Мы рассмотрим:
Какие существуют подходы к верификации HDL-кода;
С какими трудностями сопряжено применение того
или иного подхода;
Как успешно расставить приоритеты и провести
верификацию.
Тестовое окружение 9.1|22
DUT — Device Under Test, функциональное описание
(HDL-код) тестируемого устройства.
Testbench — тестовое окружение, инкапсулирующее
проверяемое устройство.
Тестовое окружение 9.2|22
DUT — Device Under Test, функциональное описание
(HDL-код) тестируемого устройства.
Testbench — тестовое окружение, инкапсулирующее
проверяемое устройство.
Тестовое окружение 9.3|22
// DUT source code
module 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 code
module adder_test;
reg [7:0] input_a;
reg [7:0] input_b;
reg carry_in;
reg [8:0] result;
// Instantiating (creating) DUT
adder 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
Преимущества направленных тестов:
Измеримый, ясный прогресс.
Не требуется подготовка инфраструктуры, легко
развернуть для нового проекта.
Не требуется изучать дополнительные технологии и
инструменты.
Возможно применять для встроенного
самотестирования устройства (BIST, Built-In
Self-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) — верификация
на основе рандомизации входных данных.
Что можно рандомизировать?
Конфигурацию устройства.
Конфигурацию окружения.
Входные данные для DUT.
Внедряемые ошибки данных.
Внедряемые ошибки протокола передачи.
Задержки.
Принципы верификации 14.3|22
1. CRV (Constraint Random Verification) — верификация
на основе рандомизации входных данных.
// Length -> Address constraint
constraint c_addr
{
(fields.length == ’d32) -> fields.addr == ’hFFFFFF;
solve fields.length before fields.addr;
}
// <...>
// Randomization
my_packet.randomize () with
{
fields.length >= ’d4;
fields.length <= ’d64;
}
Принципы верификации 14.4|22
1. Контролируемая рандомизация
2. Применение метрик
Принципы верификации 14.5|22
1. Контролируемая рандомизация
2. Применение метрик
Что может выступать в роли метрик?
Функциональное покрытие кода.
Покрытие требований.
Производительность симулятора.
Статистическая информация о частях системы.
Время на разработку тестового окружения.
Принципы верификации 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
Направленные тесты позволяют получить первые
результаты сразу.
Масштабируемость тестирования 15.2|22
Направленные тесты позволяют получить первые
результаты сразу.
Если применять описанные принципы верификации,
польза будет получена в перспективе.
Chicken
Chicken chicken chicken chicken: chicken chicken.
Chicken chicken chicken “chicken” chicken.
Chicken Chicken chicken chicken, chickens-chicken chicken
chicken.
Chicken chicken chicken chicken chicken chicken chicken
chicken (Chicken-Chicken Chicken) chicken CHICKEN.
CC Chickens: C.3.2 [Chickens]: Chicken Chickens-chicken/chicken
chicken; C.3.4 [Chicken chicken]: Chicken chicken chicken-chickens;
C.2.4 [Chicken-chicken chickens]: Chicken/Chicken, chicken
chickens.
chicken.chicken.com
chickens.chickeeen.org/ch/chicken
Трудности на пути 16.1|22
Почему описанные принципы верификации сложно
применять?
Нужно проделать большую работу.
Трудности на пути 16.2|22
Почему описанные принципы верификации сложно
применять?
Нужно проделать большую работу.
Люди сопротивляются изменениям.
Трудности на пути 16.3|22
Почему описанные принципы верификации сложно
применять?
Нужно проделать большую работу.
Люди сопротивляются изменениям.
Требуются не только новые инструменты и обучение
сотрудников, но и комплексный взгляд на
планирование.
Трудности на пути 16.4|22
Почему описанные принципы верификации сложно
применять?
Нужно проделать большую работу.
Люди сопротивляются изменениям.
Требуются не только новые инструменты и обучение
сотрудников, но и комплексный взгляд на
планирование.
Большие изменения требуют времени. Приходится
расставлять приоритеты!
Трудности на пути 16.5|22
Почему описанные принципы верификации сложно
применять?
Нужно проделать большую работу.
Люди сопротивляются изменениям.
Требуются не только новые инструменты и обучение
сотрудников, но и комплексный взгляд на
планирование.
Большие изменения требуют времени. Приходится
расставлять приоритеты!
Законченные тестовые окружения зачастую создать не
легче, чем само тестируемое устройство.
Трудности на пути 16.6|22
Почему описанные принципы верификации сложно
применять?
Нужно проделать большую работу.
Люди сопротивляются изменениям.
Требуются не только новые инструменты и обучение
сотрудников, но и комплексный взгляд на
планирование.
Большие изменения требуют времени. Приходится
расставлять приоритеты!
Законченные тестовые окружения зачастую создать не
легче, чем само тестируемое устройство.
Необходимо сопровождение, документирование и
анализ процесса.
Внедрение новых подходов 17.1|22
Внедрение новых подходов 17.2|22
Внедрение новых подходов 17.3|22
Что же делать? 18.1|22
Планировать!
Проводить декомпозицию задач, идти от общего к
частному, ясно понимая стоящую цель.
Что же делать? 18.2|22
Планировать!
Проводить декомпозицию задач, идти от общего к
частному, ясно понимая стоящую цель.
Но какова цель?
Какой подход выбрать? 19|22
Цель: в отведенное время максимально
выполнить план верификации.
Как добиться цели? На основе планирования и
анализа выбрать подходящую стратегию!
Какой подход выбрать? 20.1|22
Классические направленные тесты:
Легко развернуть.
Не нужно изучать новых языков, инструментов,
методик.
Могут применяться для встроенного
самотестирования (BIST).
Какой подход выбрать? 20.2|22
Классические направленные тесты:
Легко развернуть.
Не нужно изучать новых языков, инструментов,
методик.
Могут применяться для встроенного
самотестирования (BIST).
Применение принципов верификации:
Какой подход выбрать? 20.3|22
Классические направленные тесты:
Легко развернуть.
Не нужно изучать новых языков, инструментов,
методик.
Могут применяться для встроенного
самотестирования (BIST).
Применение принципов верификации:
1. Рандомизация
2. Метрики
3. Автоматизация
4. Транзакции
5. Переиспользование
6. Design-for-Test
Какой подход выбрать? 20.4|22
Классические направленные тесты:
Легко развернуть.
Не нужно изучать новых языков, инструментов,
методик.
Могут применяться для встроенного
самотестирования (BIST).
Применение принципов верификации:
Масштабируемые, гибкие тестовые окружения.
Возможность переиспользования компонентов.
Высокоуровневое, не зависимое от конкретной
реализации описание тестов.
Итог 21|22
Соизмеряйте цели и средства!
И главное — планируйте!
Контактная информация 22|22
Валерий Пермяков
инженер по верификации
FPGA
valery.permyakov@gmail.com
v.permyakov@npp-crts.ru
www.npp-crts.ru
LinkedIn profile:
Backup
Рекомендованная литература
SystemVerilog For Verification, Chris Spear
Verification Intellectual Property Recommended Practices,
Accelera Systems Initiative
Verification Methodology Manual for SystemVerilog, Janick
Bergeron, Eduard Cerny, Alan Hunter, Andrew Nightingale
UVM Cookbook, Mentor Graphics, Verification Academy
Verification Academy Online Courses, Mentor Graphics,
Verification Academy
Backup
Расширение языка Verilog («Verilog с классами»).
Утвержден организацией IEEE Standards Association.
Применяется для описания как синтезируемых цифровых
схем, так и для создания тестовых окружений.
Поддерживается различными вендорами: Cadence, Mentor,
Synopsys и др.
www.systemverilog.org
standards.ieee.org/getieee/1800
Backup
UVM (Universal Verification Methodology)
Стандартизированная методология верификации
цифровых схем.
Утверждена в качестве стандарта организацией Accellera
Systems Initiative.
Реализована в виде набора библиотек для SystemVerilog.
Поддерживается различными вендорами: Aldec, Cadence,
Mentor, Synopsys.
www.accelera.org verificationacademy.com
Backup
Набор библиотек C++ для описания цифровых схем.
Утвержден организацией IEEE Standards Association.
Разработан организацией Open SystemC Initiative.
Поддерживается различными вендорами: Aldec, Cadence,
Mentor, Synopsys и др.
Некоторыми вендорами поддерживается не только
симуляция, но и высокоуровневый синтез (High-Level
Synthesis) в RTL.
www.systemc.org
standards.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

Contenu connexe

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

QA Fest 2015. Владимир Скляр. Организация тестирования встроенных систем в ко...
QA Fest 2015. Владимир Скляр. Организация тестирования встроенных систем в ко...QA Fest 2015. Владимир Скляр. Организация тестирования встроенных систем в ко...
QA Fest 2015. Владимир Скляр. Организация тестирования встроенных систем в ко...QAFest
 
Тестирование осень 2013 лекция 4
Тестирование осень 2013 лекция 4Тестирование осень 2013 лекция 4
Тестирование осень 2013 лекция 4Technopark
 
Организация тестирования встроенных систем в компании «с нуля»
Организация тестирования встроенных систем в компании «с нуля»Организация тестирования встроенных систем в компании «с нуля»
Организация тестирования встроенных систем в компании «с нуля»Vladimir Sklyar
 
Тестирование осень 2013 лекция 3
Тестирование осень 2013 лекция 3Тестирование осень 2013 лекция 3
Тестирование осень 2013 лекция 3Technopark
 
Процесс тестирования
Процесс тестированияПроцесс тестирования
Процесс тестированияAlexander Solosh
 
Андрей Зайцев - TDD в кровавом энтерпрайзе
Андрей Зайцев - TDD в кровавом энтерпрайзеАндрей Зайцев - TDD в кровавом энтерпрайзе
Андрей Зайцев - TDD в кровавом энтерпрайзеElias Fofanov
 
Современный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтерыСовременный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтерыcorehard_by
 
Модульное тестирование и TDD в .NET
Модульное тестирование и TDD в .NETМодульное тестирование и TDD в .NET
Модульное тестирование и TDD в .NETAlexander Byndyu
 
Технический долг: взгляд и действия со стороны QA / QC&AT
Технический долг: взгляд и действия со стороны QA / QC&ATТехнический долг: взгляд и действия со стороны QA / QC&AT
Технический долг: взгляд и действия со стороны QA / QC&ATCodeFest
 
Повышение качества тестов и автоматическая валидация REST API документации
Повышение качества тестов и автоматическая валидация REST API документацииПовышение качества тестов и автоматическая валидация REST API документации
Повышение качества тестов и автоматическая валидация REST API документацииCEE-SEC(R)
 
Маргарита Сафарова - Аудит процессов тестирования при смене проектной команды
Маргарита Сафарова - Аудит процессов тестирования при смене проектной командыМаргарита Сафарова - Аудит процессов тестирования при смене проектной команды
Маргарита Сафарова - Аудит процессов тестирования при смене проектной командыSQALab
 
Alexandrov, Alexandr основы управления качеством
Alexandrov, Alexandr основы управления качествомAlexandrov, Alexandr основы управления качеством
Alexandrov, Alexandr основы управления качествомrit2010
 
Blind Sql Injections. Хороши ли ваши тесты?
Blind Sql Injections. Хороши ли ваши тесты?Blind Sql Injections. Хороши ли ваши тесты?
Blind Sql Injections. Хороши ли ваши тесты?Zestranec
 
Использование метрик в процессе обеспечения качества сложных систем
Использование метрик в процессе обеспечения качества сложных системИспользование метрик в процессе обеспечения качества сложных систем
Использование метрик в процессе обеспечения качества сложных системSQALab
 
Нагрузка и автоматизация в большой организации. Движение к DevOps
Нагрузка и автоматизация в большой организации. Движение к DevOpsНагрузка и автоматизация в большой организации. Движение к DevOps
Нагрузка и автоматизация в большой организации. Движение к DevOpsSQALab
 
Промышленное взвешивание
Промышленное взвешиваниеПромышленное взвешивание
Промышленное взвешиваниеЛВС компания
 
ВОЛОДИМИР НІКОНОВ «Приймальні тести і стратегія тестування» Online QADay 2020 #2
ВОЛОДИМИР НІКОНОВ «Приймальні тести і стратегія тестування» Online QADay 2020 #2ВОЛОДИМИР НІКОНОВ «Приймальні тести і стратегія тестування» Online QADay 2020 #2
ВОЛОДИМИР НІКОНОВ «Приймальні тести і стратегія тестування» Online QADay 2020 #2GoQA
 
Организация автоматического тестирования в схеме непрерывной интеграции
Организация автоматического тестирования в схеме непрерывной интеграцииОрганизация автоматического тестирования в схеме непрерывной интеграции
Организация автоматического тестирования в схеме непрерывной интеграцииSQALab
 
Техники пентеста для активной защиты - Николай Овчарук
Техники пентеста для активной защиты - Николай ОвчарукТехники пентеста для активной защиты - Николай Овчарук
Техники пентеста для активной защиты - Николай ОвчарукHackIT Ukraine
 
Сергей Ревко
Сергей РевкоСергей Ревко
Сергей РевкоSQALab
 

Similaire à Функциональная верификация HDL-кода (20)

QA Fest 2015. Владимир Скляр. Организация тестирования встроенных систем в ко...
QA Fest 2015. Владимир Скляр. Организация тестирования встроенных систем в ко...QA Fest 2015. Владимир Скляр. Организация тестирования встроенных систем в ко...
QA Fest 2015. Владимир Скляр. Организация тестирования встроенных систем в ко...
 
Тестирование осень 2013 лекция 4
Тестирование осень 2013 лекция 4Тестирование осень 2013 лекция 4
Тестирование осень 2013 лекция 4
 
Организация тестирования встроенных систем в компании «с нуля»
Организация тестирования встроенных систем в компании «с нуля»Организация тестирования встроенных систем в компании «с нуля»
Организация тестирования встроенных систем в компании «с нуля»
 
Тестирование осень 2013 лекция 3
Тестирование осень 2013 лекция 3Тестирование осень 2013 лекция 3
Тестирование осень 2013 лекция 3
 
Процесс тестирования
Процесс тестированияПроцесс тестирования
Процесс тестирования
 
Андрей Зайцев - TDD в кровавом энтерпрайзе
Андрей Зайцев - TDD в кровавом энтерпрайзеАндрей Зайцев - TDD в кровавом энтерпрайзе
Андрей Зайцев - TDD в кровавом энтерпрайзе
 
Современный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтерыСовременный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтеры
 
Модульное тестирование и TDD в .NET
Модульное тестирование и TDD в .NETМодульное тестирование и TDD в .NET
Модульное тестирование и TDD в .NET
 
Технический долг: взгляд и действия со стороны QA / QC&AT
Технический долг: взгляд и действия со стороны QA / QC&ATТехнический долг: взгляд и действия со стороны QA / QC&AT
Технический долг: взгляд и действия со стороны QA / QC&AT
 
Повышение качества тестов и автоматическая валидация REST API документации
Повышение качества тестов и автоматическая валидация REST API документацииПовышение качества тестов и автоматическая валидация REST API документации
Повышение качества тестов и автоматическая валидация REST API документации
 
Маргарита Сафарова - Аудит процессов тестирования при смене проектной команды
Маргарита Сафарова - Аудит процессов тестирования при смене проектной командыМаргарита Сафарова - Аудит процессов тестирования при смене проектной команды
Маргарита Сафарова - Аудит процессов тестирования при смене проектной команды
 
Alexandrov, Alexandr основы управления качеством
Alexandrov, Alexandr основы управления качествомAlexandrov, Alexandr основы управления качеством
Alexandrov, Alexandr основы управления качеством
 
Blind Sql Injections. Хороши ли ваши тесты?
Blind Sql Injections. Хороши ли ваши тесты?Blind Sql Injections. Хороши ли ваши тесты?
Blind Sql Injections. Хороши ли ваши тесты?
 
Использование метрик в процессе обеспечения качества сложных систем
Использование метрик в процессе обеспечения качества сложных системИспользование метрик в процессе обеспечения качества сложных систем
Использование метрик в процессе обеспечения качества сложных систем
 
Нагрузка и автоматизация в большой организации. Движение к DevOps
Нагрузка и автоматизация в большой организации. Движение к DevOpsНагрузка и автоматизация в большой организации. Движение к DevOps
Нагрузка и автоматизация в большой организации. Движение к DevOps
 
Промышленное взвешивание
Промышленное взвешиваниеПромышленное взвешивание
Промышленное взвешивание
 
ВОЛОДИМИР НІКОНОВ «Приймальні тести і стратегія тестування» Online QADay 2020 #2
ВОЛОДИМИР НІКОНОВ «Приймальні тести і стратегія тестування» Online QADay 2020 #2ВОЛОДИМИР НІКОНОВ «Приймальні тести і стратегія тестування» Online QADay 2020 #2
ВОЛОДИМИР НІКОНОВ «Приймальні тести і стратегія тестування» Online QADay 2020 #2
 
Организация автоматического тестирования в схеме непрерывной интеграции
Организация автоматического тестирования в схеме непрерывной интеграцииОрганизация автоматического тестирования в схеме непрерывной интеграции
Организация автоматического тестирования в схеме непрерывной интеграции
 
Техники пентеста для активной защиты - Николай Овчарук
Техники пентеста для активной защиты - Николай ОвчарукТехники пентеста для активной защиты - Николай Овчарук
Техники пентеста для активной защиты - Николай Овчарук
 
Сергей Ревко
Сергей РевкоСергей Ревко
Сергей Ревко
 

Plus de SQALab

Готовим стажировку
Готовим стажировкуГотовим стажировку
Готовим стажировкуSQALab
 
Куда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщикаКуда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщикаSQALab
 
Оптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержкиОптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержкиSQALab
 
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программированияАвтоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программированияSQALab
 
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...SQALab
 
Continuous performance testing
Continuous performance testingContinuous performance testing
Continuous performance testingSQALab
 
Конфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нуженКонфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нуженSQALab
 
Команда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихииКоманда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихииSQALab
 
API. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советовAPI. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советовSQALab
 
Добиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестовДобиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестовSQALab
 
Делаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIsДелаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIsSQALab
 
Вредные привычки в тест-менеджменте
Вредные привычки в тест-менеджментеВредные привычки в тест-менеджменте
Вредные привычки в тест-менеджментеSQALab
 
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииМощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииSQALab
 
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеКак hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеSQALab
 
Стили лидерства и тестирование
Стили лидерства и тестированиеСтили лидерства и тестирование
Стили лидерства и тестированиеSQALab
 
"Давайте не будем про качество"
"Давайте не будем про качество""Давайте не будем про качество"
"Давайте не будем про качество"SQALab
 
Apache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектовApache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектовSQALab
 
Тестирование геолокационных систем
Тестирование геолокационных системТестирование геолокационных систем
Тестирование геолокационных системSQALab
 
Лидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопросЛидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопросSQALab
 
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...SQALab
 

Plus de SQALab (20)

Готовим стажировку
Готовим стажировкуГотовим стажировку
Готовим стажировку
 
Куда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщикаКуда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщика
 
Оптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержкиОптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержки
 
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программированияАвтоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
 
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
 
Continuous performance testing
Continuous performance testingContinuous performance testing
Continuous performance testing
 
Конфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нуженКонфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нужен
 
Команда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихииКоманда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихии
 
API. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советовAPI. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советов
 
Добиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестовДобиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестов
 
Делаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIsДелаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIs
 
Вредные привычки в тест-менеджменте
Вредные привычки в тест-менеджментеВредные привычки в тест-менеджменте
Вредные привычки в тест-менеджменте
 
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииМощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
 
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеКак hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
 
Стили лидерства и тестирование
Стили лидерства и тестированиеСтили лидерства и тестирование
Стили лидерства и тестирование
 
"Давайте не будем про качество"
"Давайте не будем про качество""Давайте не будем про качество"
"Давайте не будем про качество"
 
Apache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектовApache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектов
 
Тестирование геолокационных систем
Тестирование геолокационных системТестирование геолокационных систем
Тестирование геолокационных систем
 
Лидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопросЛидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопрос
 
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
 

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

  • 2. Терминология 1|22 Верификация — комплекс функциональных проверок, выявляющих, соответствует ли реализация системы предъявляемым к ней требованиям и техническому заданию. Валидация — определение, соответствуют ли требования и техническое задание здравому смыслу. Тестирование — полномасштабная проверка различных аспектов работы готового устройства.
  • 3. О чем будет речь? 2|22 План доклада: Вкратце ознакомимся с процессом разработки цифровых схем; Рассмотрим различия между тестированием и функциональной верификацией; Обозначим основные подходы к функциональной верификации и сопряженные с ними сложности.
  • 4. Разработка цифровых схем 3|22 HDL — Hardware Description Language, язык описания аппаратуры (Verilog, VHDL, AHDL). RTL — Register-Transfer Level, уровень представления цифровой схемы с помощью пересылок сигналов между отдельными регистрами.
  • 5. HDL-код 4.1|22 // Verilog HDL module 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 Подобный код используется для синтеза и симуляции. Синонимы: HDL-код; Функциональное описание; Модель (потому что можно запускать в симуляторе).
  • 6. HDL-код 4.2|22 // Verilog HDL // This code cannot be synthesized module test; initial begin #10; $display("Hello world!"); $finish (); end endmodule Подобный код используется только для симуляции. Синонимы: HDL-код; Функциональное описание; Модель (потому что можно запускать в симуляторе).
  • 7. Тестирование цифровых схем 5|22 Верификация — правильно ли работает HDL-код в симуляторе? Тестирование — правильно ли работает готовое устройство, полученное на основе синтеза HDL-кода?
  • 8. Верификация HDL-кода 6|22 Как же провести верификацию HDL-кода? 1. Анализируем требования. 2. Составляем тесты для проверки требований. 3. Запускаем HDL-код в симуляторе. Запускаем тесты. 4. Смотрим, какие тесты пройдены, а какие нет. Всё довольно очевидно. . . Не так ли?
  • 9. Верификация HDL-кода 7.1|22 Сложность и количество информации могут довольно быстро сразить даже стойкого тестировщика. . .
  • 10. Верификация HDL-кода 7.2|22 Сложность и количество информации могут довольно быстро сразить даже стойкого тестировщика. . .
  • 11. Верификация HDL-кода 7.3|22 Сложность и количество информации могут довольно быстро сразить даже стойкого тестировщика. . .
  • 12. Верификация HDL-кода 7.4|22 Сложность и количество информации могут довольно быстро сразить даже стойкого тестировщика. . .
  • 13. Что же делать? 8|22 Не отступать! Мы рассмотрим: Какие существуют подходы к верификации HDL-кода; С какими трудностями сопряжено применение того или иного подхода; Как успешно расставить приоритеты и провести верификацию.
  • 14. Тестовое окружение 9.1|22 DUT — Device Under Test, функциональное описание (HDL-код) тестируемого устройства. Testbench — тестовое окружение, инкапсулирующее проверяемое устройство.
  • 15. Тестовое окружение 9.2|22 DUT — Device Under Test, функциональное описание (HDL-код) тестируемого устройства. Testbench — тестовое окружение, инкапсулирующее проверяемое устройство.
  • 16. Тестовое окружение 9.3|22 // DUT source code module 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 — тестовое окружение, инкапсулирующее проверяемое устройство.
  • 17. Тестовое окружение 9.4|22 // Testbench source code module adder_test; reg [7:0] input_a; reg [7:0] input_b; reg carry_in; reg [8:0] result; // Instantiating (creating) DUT adder adder_inst(input_a , input_b , carry_in , result); // Add test logic here: <...> endmodule DUT — Device Under Test, функциональное описание (HDL-код) тестируемого устройства. Testbench — тестовое окружение, инкапсулирующее проверяемое устройство.
  • 18. Направленные тесты 10|22 Направленное тестирование (directed testing) дает равномерный, легко прогнозируемый и измеримый прогресс по выполнению (покрытию) плана верификации.
  • 19. Направленные тесты 11|22 Преимущества направленных тестов: Измеримый, ясный прогресс. Не требуется подготовка инфраструктуры, легко развернуть для нового проекта. Не требуется изучать дополнительные технологии и инструменты. Возможно применять для встроенного самотестирования устройства (BIST, Built-In Self-Test).
  • 20. Направленные тесты 12.1|22 Требование: двигатель не должен заглохнуть при нормальной эксплуатации. Сценарий 1: разгоняемся до 42 км/ч, включаем кассету с записью Андрея Макаревича, включаем правый поворотник.
  • 22. Направленные тесты 12.3|22 Требование: двигатель не должен заглохнуть при нормальной эксплуатации. Сценарий 769: разгоняемся до 53 км/ч, открываем переднее правое окно на 3 4 , дважды нажимаем на клаксон с интервалом в секунду.
  • 23. Направленные тесты 13|22 Как протестировать такой сценарий? Направленные тесты плохо масштабируются!
  • 24. Принципы верификации 14.1|22 1. CRV (Constraint Random Verification) — верификация на основе рандомизации входных данных.
  • 25. Принципы верификации 14.2|22 1. CRV (Constraint Random Verification) — верификация на основе рандомизации входных данных. Что можно рандомизировать? Конфигурацию устройства. Конфигурацию окружения. Входные данные для DUT. Внедряемые ошибки данных. Внедряемые ошибки протокола передачи. Задержки.
  • 26. Принципы верификации 14.3|22 1. CRV (Constraint Random Verification) — верификация на основе рандомизации входных данных. // Length -> Address constraint constraint c_addr { (fields.length == ’d32) -> fields.addr == ’hFFFFFF; solve fields.length before fields.addr; } // <...> // Randomization my_packet.randomize () with { fields.length >= ’d4; fields.length <= ’d64; }
  • 27. Принципы верификации 14.4|22 1. Контролируемая рандомизация 2. Применение метрик
  • 28. Принципы верификации 14.5|22 1. Контролируемая рандомизация 2. Применение метрик Что может выступать в роли метрик? Функциональное покрытие кода. Покрытие требований. Производительность симулятора. Статистическая информация о частях системы. Время на разработку тестового окружения.
  • 29. Принципы верификации 14.6|22 1. Контролируемая рандомизация 2. Применение метрик 3. Автоматизация и предсказание результата
  • 30. Принципы верификации 14.7|22 1. Контролируемая рандомизация 2. Применение метрик 3. Автоматизация и предсказание результата 4. Верификация на уровне транзакций
  • 31. Принципы верификации 14.8|22 1. Контролируемая рандомизация 2. Применение метрик 3. Автоматизация и предсказание результата 4. Верификация на уровне транзакций Формат транзакции PCIe При верификации PCIe имеет смысл оперировать абстракциями подобного уровня, а не отдельными сигналами.
  • 32. Принципы верификации 14.9|22 1. Контролируемая рандомизация 2. Применение метрик 3. Автоматизация и предсказание результата 4. Верификация на уровне транзакций 5. Повторное использование компонентов
  • 33. Принципы верификации 14.10|22 1. Контролируемая рандомизация 2. Применение метрик 3. Автоматизация и предсказание результата 4. Верификация на уровне транзакций 5. Повторное использование компонентов
  • 34. Принципы верификации 14.11|22 1. Контролируемая рандомизация 2. Применение метрик 3. Автоматизация и предсказание результата 4. Верификация на уровне транзакций 5. Повторное использование компонентов
  • 35. Принципы верификации 14.12|22 1. Контролируемая рандомизация 2. Применение метрик 3. Автоматизация и предсказание результата 4. Верификация на уровне транзакций 5. Повторное использование компонентов
  • 36. Принципы верификации 14.13|22 1. Контролируемая рандомизация 2. Применение метрик 3. Автоматизация и предсказание результата 4. Верификация на уровне транзакций 5. Повторное использование компонентов
  • 37. Принципы верификации 14.14|22 1. Контролируемая рандомизация 2. Применение метрик 3. Автоматизация и предсказание результата 4. Верификация на уровне транзакций 5. Повторное использование компонентов 6. DFT (Design For Test) — тест-ориентированная разработка.
  • 38. Принципы верификации 14.15|22 1. Контролируемая рандомизация 2. Применение метрик 3. Автоматизация и предсказание результата 4. Верификация на уровне транзакций 5. Повторное использование компонентов 6. Тест-ориентированная разработка. ABV (Assertion-Based Verification) — верификация на основе утверждений («ассёртов»).
  • 39. Принципы верификации 14.16|22 1. Контролируемая рандомизация 2. Применение метрик 3. Автоматизация и предсказание результата 4. Верификация на уровне транзакций 5. Повторное использование компонентов 6. Тест-ориентированная разработка. Разработчики! Уважайте труд тестировщиков, и тогда проводить верификацию будет проще!
  • 40. Масштабируемость тестирования 15.1|22 Направленные тесты позволяют получить первые результаты сразу.
  • 41. Масштабируемость тестирования 15.2|22 Направленные тесты позволяют получить первые результаты сразу. Если применять описанные принципы верификации, польза будет получена в перспективе.
  • 42. Chicken Chicken chicken chicken chicken: chicken chicken. Chicken chicken chicken “chicken” chicken. Chicken Chicken chicken chicken, chickens-chicken chicken chicken. Chicken chicken chicken chicken chicken chicken chicken chicken (Chicken-Chicken Chicken) chicken CHICKEN. CC Chickens: C.3.2 [Chickens]: Chicken Chickens-chicken/chicken chicken; C.3.4 [Chicken chicken]: Chicken chicken chicken-chickens; C.2.4 [Chicken-chicken chickens]: Chicken/Chicken, chicken chickens. chicken.chicken.com chickens.chickeeen.org/ch/chicken
  • 43. Трудности на пути 16.1|22 Почему описанные принципы верификации сложно применять? Нужно проделать большую работу.
  • 44. Трудности на пути 16.2|22 Почему описанные принципы верификации сложно применять? Нужно проделать большую работу. Люди сопротивляются изменениям.
  • 45. Трудности на пути 16.3|22 Почему описанные принципы верификации сложно применять? Нужно проделать большую работу. Люди сопротивляются изменениям. Требуются не только новые инструменты и обучение сотрудников, но и комплексный взгляд на планирование.
  • 46. Трудности на пути 16.4|22 Почему описанные принципы верификации сложно применять? Нужно проделать большую работу. Люди сопротивляются изменениям. Требуются не только новые инструменты и обучение сотрудников, но и комплексный взгляд на планирование. Большие изменения требуют времени. Приходится расставлять приоритеты!
  • 47. Трудности на пути 16.5|22 Почему описанные принципы верификации сложно применять? Нужно проделать большую работу. Люди сопротивляются изменениям. Требуются не только новые инструменты и обучение сотрудников, но и комплексный взгляд на планирование. Большие изменения требуют времени. Приходится расставлять приоритеты! Законченные тестовые окружения зачастую создать не легче, чем само тестируемое устройство.
  • 48. Трудности на пути 16.6|22 Почему описанные принципы верификации сложно применять? Нужно проделать большую работу. Люди сопротивляются изменениям. Требуются не только новые инструменты и обучение сотрудников, но и комплексный взгляд на планирование. Большие изменения требуют времени. Приходится расставлять приоритеты! Законченные тестовые окружения зачастую создать не легче, чем само тестируемое устройство. Необходимо сопровождение, документирование и анализ процесса.
  • 52. Что же делать? 18.1|22 Планировать! Проводить декомпозицию задач, идти от общего к частному, ясно понимая стоящую цель.
  • 53. Что же делать? 18.2|22 Планировать! Проводить декомпозицию задач, идти от общего к частному, ясно понимая стоящую цель. Но какова цель?
  • 54. Какой подход выбрать? 19|22 Цель: в отведенное время максимально выполнить план верификации. Как добиться цели? На основе планирования и анализа выбрать подходящую стратегию!
  • 55. Какой подход выбрать? 20.1|22 Классические направленные тесты: Легко развернуть. Не нужно изучать новых языков, инструментов, методик. Могут применяться для встроенного самотестирования (BIST).
  • 56. Какой подход выбрать? 20.2|22 Классические направленные тесты: Легко развернуть. Не нужно изучать новых языков, инструментов, методик. Могут применяться для встроенного самотестирования (BIST). Применение принципов верификации:
  • 57. Какой подход выбрать? 20.3|22 Классические направленные тесты: Легко развернуть. Не нужно изучать новых языков, инструментов, методик. Могут применяться для встроенного самотестирования (BIST). Применение принципов верификации: 1. Рандомизация 2. Метрики 3. Автоматизация 4. Транзакции 5. Переиспользование 6. Design-for-Test
  • 58. Какой подход выбрать? 20.4|22 Классические направленные тесты: Легко развернуть. Не нужно изучать новых языков, инструментов, методик. Могут применяться для встроенного самотестирования (BIST). Применение принципов верификации: Масштабируемые, гибкие тестовые окружения. Возможность переиспользования компонентов. Высокоуровневое, не зависимое от конкретной реализации описание тестов.
  • 59. Итог 21|22 Соизмеряйте цели и средства! И главное — планируйте!
  • 60. Контактная информация 22|22 Валерий Пермяков инженер по верификации FPGA valery.permyakov@gmail.com v.permyakov@npp-crts.ru www.npp-crts.ru LinkedIn profile:
  • 61. Backup Рекомендованная литература SystemVerilog For Verification, Chris Spear Verification Intellectual Property Recommended Practices, Accelera Systems Initiative Verification Methodology Manual for SystemVerilog, Janick Bergeron, Eduard Cerny, Alan Hunter, Andrew Nightingale UVM Cookbook, Mentor Graphics, Verification Academy Verification Academy Online Courses, Mentor Graphics, Verification Academy
  • 62. Backup Расширение языка Verilog («Verilog с классами»). Утвержден организацией IEEE Standards Association. Применяется для описания как синтезируемых цифровых схем, так и для создания тестовых окружений. Поддерживается различными вендорами: Cadence, Mentor, Synopsys и др. www.systemverilog.org standards.ieee.org/getieee/1800
  • 63. Backup UVM (Universal Verification Methodology) Стандартизированная методология верификации цифровых схем. Утверждена в качестве стандарта организацией Accellera Systems Initiative. Реализована в виде набора библиотек для SystemVerilog. Поддерживается различными вендорами: Aldec, Cadence, Mentor, Synopsys. www.accelera.org verificationacademy.com
  • 64. Backup Набор библиотек C++ для описания цифровых схем. Утвержден организацией IEEE Standards Association. Разработан организацией Open SystemC Initiative. Поддерживается различными вендорами: Aldec, Cadence, Mentor, Synopsys и др. Некоторыми вендорами поддерживается не только симуляция, но и высокоуровневый синтез (High-Level Synthesis) в RTL. www.systemc.org standards.ieee.org/getieee/1666
  • 65. 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