CC BY
36
УДК 004.3, 004.054, 004.432
А.В. Березкин, А.А. Федотов, А.С. Филиппов
тестирование цифровых систем, заданных высокоуровневыми спецификациями
Этап верификации и тестирования в процессе проектирования цифровых устройств на основе ASIC, ASSP и SoC занимает более 70 % от общего объема трудозатрат по разработке проекта, тем не менее свыше 60 % проектов требуют дополнительных доработок [1]. В связи с этим необходимо разрабатывать новые подходы к функциональной верификации и тестированию. Так как функциональную верификацию проводят при помощи моделей, разработанных на разных уровнях абстракции, то естественный шаг в данном направлении - использование моделей и средств моделирования (верификации), лежащих на более абстрактном уровне, чем стандартный инструментарий языков описания аппаратуры.
Тестирование любого устройства подразумевает подачу на его входы тестовых последовательностей, получение его реакций на поданные тестовые последовательности и сравнение полученных реакций с эталонными. Эталонные реакции определяются спецификацией на тестируемое устройство, они могут быть получены либо вручную - специалистом по тестированию
(исходя из анализа функционально-логической спецификации на устройство), либо от эталонной модели (ЭМ) тестируемого устройства (реализованной до процесса тестирования). Использование высокоуровневых спецификаций и средств автоматического синтеза из высокоуровневых спецификаций для формирования ЭМ позволяет получать ее за короткий срок, при этом несоответствие ЭМ спецификации практически исключено.
Разрабатываемый комплекс средств верификации аппаратно-программных встраиваемых систем включает в себя набор методик синтеза тестов из спецификаций, заданных на языках высокого уровня, инструментальных средств, поддерживающих эти методики. Разработанные методики применимы на основных этапах маршрута проектирования цифровых систем и при тестировании готовых изделий.
Реализуемый подход к верификации цифровых систем с использованием встраиваемых средств тестирования и разработанных методик представлен на рис. 1.
Высокоуровневая
System С UML
Методика разработки тестов с использованием средств модульного тестиоования
Для программных компонент
Для аппаратных компонент
Методика синтеза эталонной модели для быстрого прототипирования с распределенным сигнатурным
анапияэтсюом -*
,-j-Jtzz
I Тестирование ПО
Внешнее задание
Параметризируемые средства генерации тестов
Средства параметрического тестирования
Разработаны форматы тестов
Методика и инструментарий Формальной верификации UML - модели
Язык описания встраиваемых средств тестирования на базе OpenVERA
Инструментальные средства трансляции в синтезируемый VHDL
Методика и инструментарий синтеза тестов для потока управления с использованием 11М1_
Встраиваемые средства
тестирования
Входные Мобильная
тесты система
тестирования
Рис. 1. Реализуемый подход к верификации цифровых систем с использованием встраиваемых средств тестирования
Общая тенденция в разработке аппаратно-программных комплексов предполагает широкое использование высокоуровневых спецификаций. Разработанные методики и инструментальные средства формального контроля UML спецификаций на полноту и непротиворечивость позволяют исключить ошибки на этапе синтеза спецификации. Созданный таким образом исходный формализм служит исходной точкой для серии средств формальной верификации при переходе к более детальным уровням описания систем и с использованием предложенных методик позволяет синтезировать тестовое окружение и встраиваемые средства тестирования.
Автоматизация процедуры синтеза тестов позволяет обеспечить требуемую глубину тестирования, существенно сокращает время на подготовку тестов, что особенно важно при внесении изменений в спецификацию, обусловленных развитием проекта в процессе его реализации. Для аппаратной поддержки верификации в процессе разработки и тестировании готовых изделий разработан комплекс аппаратных и программных средств мобильной системы тестирования.
1. Синтез тестов на основе UML спецификации
1.1 Описание и верификация управляющих сигналов. Для задания спецификации на управляющие сигналы и тесты потока управления предлагается использовать следующие диаграммы UML:
диаграмма классов - для описания интерфейсной части;
деятельности - для описания алгоритма подачи тестовых воздействий на устройство;
последовательности - для описания причинно-следственных связей между управляющими сигналами, т. е. для описания поведения устройства.
Описание компонентов аппаратуры с помощью диаграмм ПМЕ
Описание интерфейса с помощью диаграммы классов. Рассмотрим два возможных варианта использования диаграммы классов для описания интерфейса устройств
В первом варианте для отображения входов и выходов используются объекты типа «интерфейс», а параметр устройства моделируется с помощью атрибута объекта. Во втором варианте входы, выходы, а также параметры устройства мо-
делируются с помощью атрибутов с разными нестандартными для UML типами и стереотипами. Предлагается использовать следующие стереотипы: «parameter» - для параметров устройства, «in» - для входов устройства и «out» - для его выходов. Для атрибутов со стереотипами «in» и «out» возможно также использование нестандартных типов - std_logic и std_logic_ vector. Данные типы полностью соответствуют одноименным типам из библиотеки IEEE std_ logic_1164 для VHDL [2], включаемой во все средства проектирования на VHDL.
Первый способ более универсален: его можно использовать для формирования структурных спецификаций устройства, соединяя входы и выходы устройств линиями ассоциации. Второй способ проще для генерации кода: все интерфейсные характеристики устройства находятся внутри одного объекта.
Использование диаграммы деятельности для описания алгоритма воздействий. Диаграммы деятельности используются для описания воздействий, подающихся на некоторое устройство в процессе его нормальной работы. Диаграмма деятельности позволяет синтезировать генерирующую часть теста, являющуюся сценарием тестирования.
Использование диаграммы последовательности для описания поведения устройства. Диаграмма последовательности используется для отображения внутреннего поведения устройства, для пояснения взаимосвязи между возникающими в нем управляющими сигналами. Пример такой диаграммы показан на рис. 2.
Прямоугольники в верхней части диаграммы использованы для отображения компонентов устройства. Вертикальные пунктирные лини -«линии жизни». Стрелками обозначены сообщения, которыми обмениваются компоненты устрой-
Рис. 2. Использование диаграммы последовательности для описания поведения устройства
ства. Сообщение трактуется как переход одного управляющего сигнала из неактивного состояния в активное (например, из «0» в «1»). Вертикально вытянутые прямоугольники - спецификации исполнения (execution specification). В нотации UML 2.0 данными элементами обозначаются части линии жизни объекта, представляющие целостный период его работы. В нашем случае они трактуются как элементы, объединяющие сообщения в причинно-следственные связи.
Диаграмма взаимодействия может дополняться разнообразными условиями, которые могут по-разному трактоваться (в зависимости от реализации). В рассмотренном рисунке условие сообщения stop записано в квадратных скобках, что является отступлением от нотации UML 2.0 (но допустимо в UML 1.x). Для обеспечения совместимости такой записи с UML 2.0 условия можно задавать как часть имени сообщения.
Генерация тестов аппаратуры из диаграмм UML
Генерация интерфейсной части из диаграммы классов. Для генерирования интерфейсной части testbench (описание интерфейса тестируемого устройства) используются диаграммы классов. Необходимо отметить, что, поскольку в testbench тестируемое устройство рассматривается как цельный блок, его внутренние сигналы, фигурирующие в диаграмме последовательности, недоступны. Чтобы сделать их наблюдаемыми, необходимо вынести их на интерфейсный уровень, что должно найти отражение как на диаграмме классов, так и в коде устройства.
Генерация источника тестовых воздействий из диаграммы деятельности. Рассмотрим использование диаграмм деятельности для синтеза генерирующей части теста. Поскольку диаграммы деятельности представляют собой схемы алгоритмов, их трансляция в код не представляет сложностей.
Генерация наблюдающей части теста из диаграммы последовательности. Поясним генерацию наблюдающей части теста с помощью некоторой диаграммы последовательности - спецификации исполнения, расположенной на линии жизни некоторого гипотетического управляющего устройства (рис. 3). Ниже приведен соответствующий ему код, управляющий состоянием верификатора.
Как видно из иллюстрации, вся спецификация исполнения делится на «кластеры», каждый из ко-
[success] ok
[!success] error
[cycle = 1] init
cycle = - 2] send
[cycle = 1 ] stop
->
и
if ((state = idle) and (start = '1')) then cycle := 0;
state <= after_cluster_0;
elsif ( (state = after_cluster_0)
and ((ok = '1') or (error = '1'))) then cycle := 0;
state <= after_cluster_2;
elsif ( (state = after_cluster_2)
and (stop = '1')) then state <= idle;
else
cycle <= cycle + 1; end if;
Рис. 3. Генерация верификатора из одной спецификации исполнения
торых - это группа смежных входящих сообщений. Каждому кластеру ставится в соответствие одно состояние управляющего конечного автомата. Переход от одного состояния (кластера) к другому происходит под воздействием входящих сообщений за исключением самого последнего сообщения, которое используется для остановки верификатора независимо от того, какое это сообщение.
Верификатор может использовать ряд внутренних счетчиков-переменных. В рассматриваемом примере используется счетчик cycle, значение которого равно количеству тактов после последнего входящего сообщения. Также используется объект success, который может быть сигналом, счетчиком, внутренней переменной.
Каждое исходящее сообщение при генерации порождает одно проверяющее утверждение (assert ... report ... severity). Например, второе исходящее сообщение ([cycle = 2] send) порождает утверждение вида:
if ((state = after_cluster_0) and (cycle = 2)) then
assert (send = '1') report ("send error") severity error; end if;
Таким образом, верификатор проверяет, что в заданное время при заданных условиях сообщение, которое должно появиться согласно спецификации, действительно появляется в устройстве.
1.2 Описание потока данных
Описание потоков данных с помощью UML
Описание алгоритма сравнения исходных и конечных данных. Алгоритм сравнения исходных и конечных данных - это ядро верификатора, именно он определяет, как произошел обмен: правильно или с ошибкой. Сложность алгоритма зависит от специфики устройства. Например, если проверяется выставление одного из битов слова в последовательном передатчике, проверка сводится к сравнению очередного разряда исходного слова с тем, который был выставлен на шину. Если проверяется более сложное устройство, такое, как сумматор, проверка сводится к самостоятельному суммированию операндов и сравнению результата, полученного на сумматоре, с результатом верификатора. Алгоритм проверки переписывания данных целесообразно описать с помощью диаграммы деятельности.
Верификатор может обращаться к специальным переменным - значениям внутренних счетчиков и задержанным информационным сигналам. Данные сигналы должны добавляться в верификатор автоматически в случае их упоминания в диаграмме деятельности. Для идентификации специальных переменных следует ввести лингвистические соглашения, например:
имя сигнала с суффиксом _latched_n (n -натуральное число) означает соответствующий сигнал, задержанный на n тактов;
имя управляющего сигнала с суффиксом _counter означает счетчик управляющего сигнала, т. е. количество активаций этого сигнала с момента последнего сброса истории.
Задание свойств управляющих сигналов
Алгоритмы проверки данных должны запускаться при появлении определенных управляющих сигналов. Привязка управляющих сигналов и алгоритмов проверки данных выполняется путем назначения управляющим сигналам определенных свойств. Некоторые параметры верификации можно задать с помощью опций сигналов, фигурирующих на диаграмме последовательности. Спецификация UML не поддерживает задания произвольных свойств сигнала напрямую, однако многие UML-редакторы позволяют назначать сигналам именованные значения, например, Tagged Values в Microsoft Visio. Для верной интерпретации этих значений необходимо принять
лингвистические соглашения относительно их имен и значений, например:
• VerificationAlg - ассоциированный алгоритм верификации. Значение - имя диаграммы деятельности.
• ActivePart - рабочая часть сигнала. Значения:
PositiveEdge, NegativeEdge - положительный и отрицательный перепады; Edge - любой перепад; Whole - весь сигнал.
• Latency - количество тактов с момента активации сигнала до запуска алгоритма проверки. Значение - целое неотрицательное число.
• ClearHistory - очистить историю управляющих сигналов данной диаграммы последовательности. Значения: True или False (по умолчанию).
Применение разработанных принципов генерации тестов аппаратуры на основе исходной UML спецификации позволяет обеспечить полную проверку потока управления и требуемую глубину проверки потока данных.
2. Применение SystemC подобных языков для решения задач тестирования и верификации аппаратных средств
Языки класса SystemC являются попыткой упрощения процедуры проектирования цифровых устройств и предоставляют разработчику возможность моделировать, описывать и верифицировать устройство на C-подобных языках. Появление подобных языков обусловлено их универсальностью, высоким уровнем абстракции, унификацией разработки программных и аппаратных средств, существенным сокращением времени разработки за счет ускорения этапа верификации. Один из подобных языков - язык Catapult C фирмы Mentor Graphics. Catapult C - один из наиболее репрезентативных вариантов C-подобных языков проектирования аппаратуры, и наиболее полно поддержанный фирменными инструментальными средствами (Mentor Graphics Catapult C Synthesys), позволяющими получить законченный полностью функциональный результат.
Различные варианты C-подобных языков описания аппаратуры имеют следующие характеристики:
за исключением самого SystemC являются подмножествами языка программирования
C/C++, включающими в себя специальные (нестандартные) библиотеки и макросы, позволяющие симулировать параллельные процессы;
так как описание аппаратуры на C-подобном языке предполагает разработку объекта, функционирование которого имеет параллельный характер, при помощи инструментария последовательной природы, то главнейшее свойство C-подобных языков проектирования цифровых устройств - выделение параллелизма из C-кода на разных уровнях: во-первых, на уровне модулей рассматривается, какие модули могут выполняться одновременно; во-вторых, анализируются циклы в поисках итераций, чьи выполнения могут произойти параллельно;
имеют ряд ограничений, касающихся применения определенных ресурсов/свойств стандартного (ANSI) C/C++, таких, как использование указателей, рекурсивности функций, динамического размещения памяти и др.
некоторые языки разрешают определить специфическую аппаратную базу для проектируемого устройства (как правило, в случае FPGA наиболее популярны решения фирм Xilinx, Inc., Altera Corp., Actel Corp. и Lattice Semiconductor Corp.).
на их основе инструментальные средства осуществляют автоматическое формирование описания устройства на нижележащих уровнях абстракции. Например, описание на уровне регистровых передач (формируются VHDL- или Verilog-описания), формирование списка соединений из алгоритмов, разработанных в традиционной среде разработки Matlab.
C++test
Основываясь на уровне абстракции, связанном с C-подобными языками, предложены методики по автоматизации процессов тестирования и верификации с применением спецификаций системы, заданных на подобных языках.
2.1 Использование средств тестирования ПО для верификации цифрового устройства на основе высокоуровневой модели. Тестирование ПО может быть осуществлено на разных уровнях с конкретными целями при помощи различных методик [3]. Как правило, выделяют три уровня: модулей, интеграции модулей и системный. Так как алгоритмическое описание цифровых систем на Catapult C состоит, в основном, из функций, то необходимо сделать акцент на модульное тестирование. При модульном тестировании ПО принято использовать драйверы и заглушки. Драйверами являются элементы тестов, запускающие тестируемый модуль, а заглушками - заменители недостающих компонентов, вызываемые тестируемым модулем [4].
Исследованы и применяются два общеизвестных инструментальных средства тестирования ПО: инфраструктура автоматического модульного тестирования MinUnit и среда модульного тестирования C++test. Первое является свободно распространяемым продуктом, а второе - коммерческой разработкой фирмы Parasoft Corp. На рис. 4 представлена структурная схема обоих средств, по которой видно, что при использовании инфраструктуры MinUnit необходимо самостоятельно сгенерировать тестовые входные данные и заглушки, в то время как это осуществляется автоматически в среде C++test.
Рис. 4. Структурная схема инфраструктуры автоматического модульного тестирования Мтипк и среды модульного тестирования C++test
На основе MinUnit и C++test предложен маршрут применения средств модульного тестирования ПО к функциональной верификации цифровых устройств, заданных на Catapult C. Маршрут изображен на рис. 5. Из рисунка видно, что инструментальные средства модульного тестирования ПО предлагается использовать в двух направлениях:
во-первых, MinUnit применяется для верификации функциональности цифрового устройства при запуске тестовых входных данных, разработанных вручную в соответствии с каждым из функциональных требований, приведенных в спецификации в виде функционального теста ПО на инструментальной ЭВМ.
во-вторых, C++test используется для создания аппаратной платформы верификации цифрового устройства и, следовательно, встраиваемого те-
стирующего устройства. Для этого необходимо осуществить переход, обозначенный звездочкой на рис. 5, адаптируя инфраструктуру автоматического тестирования и тестовые входные данные, сгенерированные C++test для их компиляции и оптимизации в Catapult C Synthesis, чтобы получить синтезируемое VHDL-описание тестирующего устройства.
Оба направления основываются на подходе, принятом при проектировании цифровых устройств в среде Catapult C Synthesis: при разработке алгоритмического описания проектируемого устройства исходный код на Catapult C изолируется от аппаратных и временных ограничений, в нем содержится информация только о функциональности разрабатываемого модуля или системы.
Предложенные подходы позволяют быстрее и надежнее выполнить функциональную верифика-
Рис. 5. Маршрут применения средств модульного тестирования программного обеспечения к функциональной верификации устройства, заданного на Catapult C
цию цифровых устройств и более эффективно создавать тесты, предназначенные для функциональной верификации разработанных на Catapult C цифровых устройств.
2.2 Использование высокоуровневых спецификаций для быстрого прототипирования цифрового устройства. Спецификация проектируемой системы - первичный и главный источник информации для разработчика конечных модулей системы. Современный подход предполагает задание подобных спецификаций, в т. ч. и на высокоуровневых языках программирования класса C и C++, что позволяет реализовать систему программно, а с привлечением современных компиляторов - и аппаратно.
Основная идея подхода - тестирование с эталонной моделью (ЭМ), синтезированной из высокоуровневой спецификации средствами Catapult C. Данный подход позволяет быстро реализовать алгоритмически верную ЭМ, из которой можно получить набор верных сигнатур, проведя для нее сигнатурный анализ, или набор верных - эталонных откликов на тестовые воздействия. Эти сигнатуры и отклики впоследствии можно использовать для обнаружения ошибок в целевом устройстве [4].
Для применения методики на практике необходимо в состав тестируемой системы встраивать тестирующую надстройку (ТН). ТН осуществляет тестирование цифрового устройства методом сигнатурного анализа с использованием ЭМ, реализованной средствами языка Catapult C. Ядром ТН является распределенный сигнатурный анализа-
тор. Абстрактная тестовая система приведена на рис. 6.
Процесс тестирования с помощью данной тестирующей надстройки подразумевает подачу одних и тех же тестовых векторов на вход тестируемого устройства и на вход ЭМ и ожидание одинаковой ответной реакции от них (одинаковых сигнатур). Возможны два варианта совместного тестирования.
1. Тестирование с использованием памяти сигнатур для тестируемого устройства и для ЭМ. В этом режиме испытания обоих устройств могут быть разнесены по времени. Полученные при испытании устройства сигнатуры заносятся в энергонезависимую память сигнатур, подключенную к данному устройству. Это дает значительное преимущество, если тестируемое устройство находится в разработке, а высокоуровневая спецификация на него имеется в наличии. В этом случае тестировщик формирует по программе функционального тестирования целевого устройства тестовые последовательности для ЭМ, полученной из высокоуровневой спецификации. Полученные при испытании ЭМ сигнатуры заносятся в память сигнатур ЭМ. После того как целевое устройство готово, для него проводят испытания по той же программе; полученные сигнатуры заносятся в память сигнатур целевого устройства.
Сравнение содержимого памяти сигнатур целевого устройства и памяти сигнатур ЭМ позволяет делать выводы об успешности прохождения теста, однако локализовывать ошибки, выявленные при тестировании в таком режиме, неудобно.
Блок сравнения и анализа
Рис. 6. Структура системы тестирования с ТН
Это связано с тем, что поиск источника ошибки по адресам в памяти сигнатур и перестройка тестирующей системы требует больших временных и аппаратных затрат. Такой вариант тестирования предпочтительнее использовать в случае если нужно не искать ошибки целевом устройстве, а убедиться в их отсутствии, например, при сдаче целевого устройства заказчику.
2. Тестирование в режиме реального времени. В этом режиме тестовые последовательности одновременно подаются на входы обоих устройств, их испытания проводятся параллельно. Полученные сигнатуры можно сравнивать в процессе тестирования и при наличии ошибки останавливать тестирование. Такой режим значительно удобнее при необходимости поиска и локализации ошибок, чем режим тестирования с использованием памяти сигнатур. При тестировании в режиме реального времени, обнаружив ошибку в выходном сигнале, можно быстро локализовать цепь, по которой прошел сбой, и перестроить тестирующую систему таким образом, чтобы протестировать блоки, входящие в эту цепь.
Отрицательной чертой тестирования в режиме реального времени является то, что несоответствие временных характеристик тестируемого устройства и эталонной модели может повлиять на результаты тестирования. Нередко, поскольку эталонная модель построена из высокоуровневой спецификации средствами автоматического синтеза, она уступает целевому устройству в производительности, и, в частности, в максимальной тактовой частоте. В связи с этим может возникнуть необходимость понижения частоты работы целевого устройства до максимальной частоты работы ЭМ. Так как тестирующая надстройка осуществляет не параметрическое тестирование, а лишь функциональное, понижение частоты работы не повлияет на результаты тестирования целевого устройства, только замедлит процесс тестирования. Согласования частоты работы целевого устройства и ЭМ можно добиться, используя устройства PLL (ФАПЧ) или счетчики-делители.
Еще одной проблемой, связанной с несоответствием ЭМ целевому устройству по временным характеристикам, является разное количество тактов синхросигнала, необходимое для срабатывания устройства. Из-за этого одни и те же сигнатуры на выходе целевого устройства и ЭМ бу-
дут формироваться в разное время, осуществлять их сравнение в таком случае затруднительно. Для решения данной проблемы необходимо либо замедлить опережающее устройство, либо ускорить отстающее, либо защелкивать значения сигнатур для обоих устройств в разные моменты времени таким образом, чтобы они оказывались равны. Для согласования устройств существует множество решений как схемотехнических (например, добавление конвейеризирующих регистров на входе или выходе опережающего устройства), так и функционально-логических, более высокоуровневых, позволяющих отталкиваться от логического времени и событий в системе, к нему привязанных.
Результаты апробации реализованных блоков ТН показали, что ее можно применять для тестирования цифровых устройств малой и средней сложности. Для сложных цифровых устройств процесс конфигурации распределенного сигнатурного анализатора в составе ТН может быть слишком сложен и длителен. Использование динамически конфигурируемого распределенного сигнатурного анализатора целесообразно именно при тестировании сложных цифровых устройств. Использование ЭМ в маршруте тестирования, особенно в режиме реального времени, предъявляет некоторые требования к ТН, которые сложно унифицировать. Для каждой системы необходимо формировать средства синхронизации тестируемого устройства с ЭМ специально, т. к. на данном этапе работы этот процесс не автоматизирован.
Предложенный подход к использованию ЭМ, получаемой из высокоуровневой спецификации, и к построению тестирующей надстройки - шаг на пути к созданию универсальной функционально законченной системы встраиваемого тестирования с эталонной моделью, синтезированной из высокоуровневой спецификации.
Разработанные подходы к тестированию цифровых систем с использованием высокоуровневых спецификаций основаны на формальных способах синтеза тестирующих последовательностей и встраиваемых средств тестирования. Предлагаемые методики применимы на основных этапах маршрута проектирования цифровых систем и при тестировании готовых изделий.
СПИСОК ЛИТЕРАТУРЫ
1. Bortolami, Jerome. Leveraging system models for RTL functional verification. Sequential logic equivalence checking provides an edge [Электронный ресурс] / Jerome Bortolami. -Режим доступа: (от 12.03.2007) http://www.eetimes.com/news/design/showArticle. jhtml?articleID=204203526
2. Bjiirklund D. From UML Behavioral Descriptions to Efficient Synthesizable VHDL [Text] / D. Bjorklund, J. Lilius // Proc. of 20th IEEE NORCHIP Conf. (Copenhagen, Denmark, 11-12 Nov. 2002); IEEE Computer Society. -Washington DC, USA, 2007.
3. Bertolino, Antonia. A brief essay on software testing [Электронный ресурс] / Antonia Bertolino, Eda Marchetti. - Режим доступа: (от 17.09.2004) http://dienst. isti.cnr.it/Dienst/Repository/2.0/Body/ ercim.cnr.isti/2004-TR-36/pdf
4. Городецкий, А. Встроенные инструменты тестирования [Электронный ресурс] / А. Городецкий // Компоненты и технологии. -2009. -№ 3. -Режим доступа: http://www.kit-e.ru/articles/jtag/2009_03_10.php
