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. Смотрим, какие тесты пройдены, а какие нет.
Всё довольно очевидно. . . Не так ли?
13. Что же делать? 8|22
Не отступать! Мы рассмотрим:
Какие существуют подходы к верификации HDL-кода;
С какими трудностями сопряжено применение того
или иного подхода;
Как успешно расставить приоритеты и провести
верификацию.
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
, дважды нажимаем на клаксон
с интервалом в секунду.
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;
}
28. Принципы верификации 14.5|22
1. Контролируемая рандомизация
2. Применение метрик
Что может выступать в роли метрик?
Функциональное покрытие кода.
Покрытие требований.
Производительность симулятора.
Статистическая информация о частях системы.
Время на разработку тестового окружения.
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. Тест-ориентированная разработка.
Разработчики! Уважайте труд тестировщиков, и тогда
проводить верификацию будет проще!
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).
Применение принципов верификации:
Масштабируемые, гибкие тестовые окружения.
Возможность переиспользования компонентов.
Высокоуровневое, не зависимое от конкретной
реализации описание тестов.
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