Средства функциональной верификации микропроцессоров Текст научной статьи по специальности «Компьютерные и информационные науки»

Средства функциональной верификации микропроцессоров

A.C. Камкин, А.М. Коцыняк, С.А. Смолов, A.A. Сортов, А.Д. Татарников,

М.М. Чупилко

{kamkin, kotsynyak, ssedai, sortov, andrewt, chupilko} @ispras. ru

Аннотация. Обеспечение корректности микропроцессоров и другой микроэлектронной аппаратуры является фундаментальной проблемой, для решения которой применяют разнообразные средства функциональной верификации. В отличие от программ, ошибки в которых исправляются сравнительно просто, дефекты в интегральных схемах (конструктивные и производственные) не могут быть устранены. Несмотря на то, что постоянно совершенствуются системы автоматизированного проектирования (САПР), инструменты генерации тестов и методы анализа схем, верификация остается самым узким местом процесса разработки (на нее тратится около 70% всех ресурсов проектирования). В работе делается краткий обзор средств верификации микропроцессоров, рассматриваются проблемы, возникающие в промышленной практике, анализируются возможные пути их решения. Значительная часть статьи посвящена исследованиям по верификации аппаратуры, проводимым в ИСП РАН: подводятся итоги выполненных работ, описываются текущие разработки, формулируются направления дальнейших исследований.

Ключевые слова: микропроцессоры; цифровая аппаратура; верификация; валидация; тестирование; генерация тестов; моделирование; языки описания архитектуры; распараллеливание.

1. Введение

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

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

функциональной верификацией (в дальнейшем под верификацией будет

пониматься именно функциональная верификация).

Год Ми кропроц ессор Транзисторы

1971 4004 2 300

1974 8080 5 000

1978 8086 29 000

1982 186 55 000

1982 286 134 000

1985 386 275 000

1989 486 1 180 235

1993 Pentium 3 100 000

1997 Pentium II 7 500 000

1999 Pentium III 24 000 000

2000 Pentium 4 42 000 000

2001 Itanium 25 000 000

2002 Itanium 2 220 000 000

2004 Itanium 2 9M 592 000 000

2006 Core 2 Duo (2 ядра) 291 000 000

2008 Core І7 (4 ядер) 731 000 000

2011 Core І7 (6 ядер) 2 270 000 000

2012 Xeon Westmere-EX (8 ядер) 2 600 000 000

2012 Xeon Pili (62) 5 000 000 000

Рис. 1. Рост числа транзисторов (на графике — десятичный логарифм) в микропроцессорах фирмы ІпґеІ [2]

Тема статьи ограничена не только видом верификации, но и типом рассматриваемых систем — микропроцессорами, программно управляемыми устройствами, предназначенными для цифровой обработки данных. Поскольку функциональность микропроцессора определяется реализуемой им системой команд, то, в самых общих словах, задача верификации состоит в проверке того, что микропроцессор (точнее, его проектная модель или схема) корректно реализует все указанные в техническом задании команды (инструкции): результат выполнения каждой команды во всех возможных ситуациях соответствует ее спецификации [3]. Верификация микропроцессора

— чрезвычайно трудоемкая задача. По некоторым оценкам, затраты на нее составляют порядка 70% от всех затрат на проектирование, число инженеров-верификаторов примерно вдвое превосходит число инженеров-разработчиков, а исходный код тестовых систем составляет до 80% от общего объема кода [4]. С ростом сложности микропроцессоров (закон Мура [5] работает до сих пор — см. рис. 1) ситуация только ухудшается — возможности методов верификации отстают от развития микропроцессоров; соответственно, проверка корректности (и без того являющаяся самым узким местом процесса проектирования) вовлекает в себя все большие объемы ресурсов. К примеру, над верификацией микропроцессора Pentium 4 (2000 г.) работала команда, состоявшая приблизительно из 70 человек, а для прогона тестов использовалось около 6 тысяч компьютеров, работавших в круглосуточном режиме [6, 7].

Почему верификация микропроцессоров так важна? Потому что никто не хочет доверять свою жизнь, здоровье и благополучие системам, содержащим ошибки, которые при некоторых обстоятельствах могут повести себя непредсказуемым образом, а микропроцессоры — это основа основ всех компьютерных систем. Неслучайно пользователи компьютеров (которых с каждым годом становится все больше и больше) очень бурно реагируют на ошибки, обнаруживаемые в микропроцессорах. Показательна в этом плане ошибка в реализации команды деления в микропроцессоре Pentium компании Intel, обнаруженная в 1994 г. [8]. Несмотря на то, что большинства пользователей эта проблема не касалась, и вероятность ее возникновения крайне мала, для сохранения имиджа компании Intel пришлось организовать замену микросхем, что обошлось ей в 475 миллионов долларов. В 2007 г. много шума наделала ошибка в реализации механизмов кэширования 4-ядерного микропроцессора AMD Phenom (ошибка #298 [9]), которая может приводить к зависанию системы или порче данных. В 2008 г. в Сети обсуждалась близкая проблема в Intel Core i7 (Nehalem), но, как выяснилось, тревога оказалась ложной [10]. С другой стороны, в Core i7 хватает и других проблем — в спецификации [11] (2011г.) перечислены 153 ошибки, из которых только 16 имеют статус «исправлена» и 2 «исправление запланировано». Следует понимать, что это лишь известные проблемы — общее число ошибок может быть существенно больше.

Трудоемкость и актуальность верификации стимулируют научные исследования в этой области. Основная тенденция в развитии средств верификации состоит в усилении роли формальных методов — методов, основанных на анализе математических (формальных) моделей систем, модулей и протоколов их взаимодействия [12]. В рамках формальной верификации используются специфические техники, такие как проверка моделей, дедуктивный анализ, проверка эквивалентности и другие [1]. Использование формальных методов требует значительных усилий на построение моделей, однако если модели построены, то их анализ в значительной мере может быть выполнен автоматически. Лидером в области формальной верификации микропроцессоров является компания Ьйе1, которая формально проверяет широкий класс устройств: от модулей арифметики с плавающей точкой до протоколов обеспечения когерентности памяти [13]. К 2015 г. I п1е1 планирует увеличить использование формальных методов в модульной верификации микропроцессоров до 50% [14, 15]. Методы

тестирования по-прежнему доминируют, но следует отметить, что за последние 20 лет они претерпели значительную трансформацию: современные подходы сочетают в себе как эвристические, так и формальные техники [16].

Свой вклад в развитие средств функциональной верификации микропроцессоров вносит и ИСП РАН, занимающийся этой тематикой с 2005 г. Сфера интересов Института включает технологии промышленной верификации микропроцессоров на модульном и системном уровнях, а также формальные методы проектирования и верификации микропроцессоров. Помимо выполнения теоретических исследований и разработки инструментальных средств Институт сотрудничает с ведущими отечественными производителями микропроцессоров, НИИСИ РАН и ЗАО «МЦСТ», выполняя для них проекты по верификации с использованием разработанных средств. В статье описываются результаты, полученные Институтом в области верификации микропроцессоров, рассматриваются текущие разработки, обрисовываются направления дальнейших исследований.

Статья организована следующим образом. Раздел 2 представляет собой краткое введение в предметную область. В разделе 3 описываются выполненные исследования и разработки. Раздел разбит на два подраздела, посвященных модульной и системной верификации соответственно. Каждый подраздел содержит несколько частей, отражающих основные вехи проделанных работ. Сравнение предложенных методов и реализованных инструментов с существующими подходами осуществляется непосредственно в той части, которая описывает предлагаемое решение. Раздел 4 рассматривает текущие и перспективные разработки Института. Как и раздел 3, он разбит на два подраздела, посвященных модульной и системной верификации. Раздел 5 завершает статью.

2. Средства верификации микропроцессоров

В общих словах, процесс проектирования микропроцессора состоит из четырех основных этапов, на каждом из которых создается его модель определенного уровня абстракции: (1) архитектурное проектирование,

(2) детальное проектирование, (3) логическое проектирование, (4) физическое проектирование [3]. Рассмотрим первые два этапа более подробно (этапы логического и физического синтеза автоматизированы средствами современных САПР и в данной статье не рассматриваются).

На этапе архитектурного проектирования разрабатывается система команд микропроцессора {макроархитектура) и уточняется его внутренняя структура {микроархитектура). Основными средствами, используемыми на данном этапе, являются (1 ) языки программирования общего назначения, {2) языки системного проектирования {SLDL, System-Level Design Languages) и

(3) языки описания архитектуры {ADL, Architecture Description Languages) [17, 18, 19]. Примеры языков указанных типов представлены в табл. 1. Результатом архитектурного проектирования является симулятор микропроцессора — программная модель, позволяющая интерпретировать программы, написанные в соответствующей системе команд. Симуляторы микропроцессоров используются для кросс-разработки ПО, а также для верификации, где они выступают в качестве эталонных моделей (см. раздел 2.3).

Табл. 1. Языки, используемые при проектировании микропроцессоров

Тип языка Примеры

Языки программирования общего назначения С, C++, Perl, Python

Языки описания архитектуры (АЭЬ) LISA, EXPRESSION, ISDL, nML

Языки системного проектирования ^ОЕ) SystemC, SystemVerilog, Bluespec

Языки описания аппаратуры (НОЬ) Verilog, VHDL

На этапе детального проектирования применяются языки описания аппаратуры {HDL, Hardware Description Languages), такие как VHDL и Verilog, позволяющие предельно точно описывать структуру и поведение микропроцессора [17]. Результатом этапа является модель уровня регистровых передач {RTL, Register Transfer Level), которая с потактовой точностью определяет пересылки данных, возникающие при работе устройства. RTL-модель (называемая также HDL-моделью или HDL-описанием) преобразуется (посредством логического и физического синтеза) в представление (как правило, основанное на фотошаблонах), используемое при производстве интегральных схем. Хотя верификация присутствует на всех этапах разработки, особенно она актуальна при создании HDL-модели, поскольку функциональность, описанная на этом этапе, впоследствии не изменяется [3].

2.1. Методы верификации микропроцессоров

Существующие методы верификации микропроцессоров можно разбить на три основных класса: (1) экспертиза, (2) имитационная верификация

{simulation-based verification), также называемая динамической верификацией или тестированием, и (3) формальная верификация. Кроме того, существуют так называемые гибридные методы [16] (другие названия — синтетические методы [20] и полуформальные методы [21]), которые используют комбинации указанных подходов (прежде всего, комбинации имитационных и формальных методов).

К экспертизе относятся методы верификации, в которых оценка результатов проектирования выполняется людьми путем умозрительного анализа (инспекция кода, визуальный анализ схем и т.п.). Отличительной чертой экспертизы является возможность ее выполнения с использованием только результатов проектирования, а не их формальных моделей (как в формальной верификации) или результатов работы (как в имитационной верификации). Гипотетически, экспертиза позволяет выявлять практически любые виды ошибок, причем на самых ранних стадиях. В то же время она не может быть автоматизирована и ее эффективность существенно зависит от опыта и мотивации ее участников [1].

Под имитационной верификацией обычно понимается тестирование HDL-моделей аппаратуры, выполняемое в специальной среде имитационного моделирования — HDL-симуляторе [4]. Для применения этого подхода необходимо иметь модель микропроцессора, что невозможно на ранних этапах проектирования. Создание набора тестов, позволяющих адекватно проверить такое сложное устройство, как микропроцессор, является чрезвычайно трудоемкой задачей. Однако наличие простых методик (например, случайная генерация тестов), а также возможность проверить реальное поведение на реальных примерах являются основными причинами, по которым имитационная верификация широко распространена (более подробно этот класс методов рассмотрен в разделах 2.2 и 2.3).

Формальная верификация основана на построении математической (формальной) модели системы и ее анализе на предмет выполнимости свойств, также выраженных формально (например, свойств безопасности {safety) — недостижимости ошибочных состояний — и живости {liveness) — отсутствия зависаний и зацикливаний) [22]. Модель может разрабатываться вручную или извлекаться из HDL-описания устройства [23]. Преимущество формальной верификации состоит в том, что проверка осуществляется для всех возможных вариантов поведения модели, что позволяет считать верификацию исчерпывающей (для заданных модели и свойств) [24]. Недостатком является высокая трудоемкость, связанная с необходимостью разработки формальной модели (если модель не извлекается из исходного кода) и обоснованием ее адекватности (эквивалентности исходному HDL-описанию) [25].

В табл. 2 представлено распределение найденных ошибок в зависимости от используемого метода верификации в проекте РсШшт 4 компании 1гие1 (2000 г.) [6]. Согласно представленным данным, 74% ошибок находится с помощью имитационной верификации, причем большая их часть приходится на модульную верификацию (автономную проверку модулей микропроцессора). Формальные методы применялись ограниченно, поэтому процент ошибок, найденных таким способом, невелик (около 6%), однако это такие ошибки, которые практически невозможно обнаружить с помощью других средств. Несмотря на то, что статистике, приведенной в табл. 2, более 10 лет, она все еще сохраняет свою актуальность (особенно для отечественных компаний, которые уступают ведущим мировым компаниям по уровню развития технологий верификации1).

Табл. 2. Метод верификации — число найденных ошибок (Репйит 4, 2000 г.) [6]

Метод верификации Число ошибок Процент ошибок

Имитационная верификация (модульный уровень) 3411 43.5%

Имитационная верификация (системный уровень) 2398 30.5%

Экспертиза (инспекция кода) 1554 20.0%

Формальная верификация 492 6.0%

Итого 7855 100%

Доминирующим подходом (даже в таких компаниях, как Intel, AMD и IBM) по-прежнему является имитационная верификация. Чтобы повысить ее эффективность микропроцессор декомпозируется на множество относительно простых модулей (устройств, блоков, подсистем, кластеров), каждый из которых проверяется автономно. Таким образом, помимо обязательной системной верификации, оценивающей работоспособность микропроцессора в целом, применяют еще и модульную верификацию для более тщательной проверки отдельных устройств. Ниже кратко рассматривается, как имитационная верификация реализуется на модульном и системном уровнях.

2.2. Средства модульной верификации

Имитационная верификация на модульном уровне осуществляется с помощью тестовых систем (testbenches) — специализированных программ, которые в автоматическом режиме подают на верифицируемую HDL-модель тестовые воздействия (стимулы) и проверяют корректность выдаваемых ею ответов

В условиях ограниченного финансирования обычно экономят на верификации.

(реакций) [4]. Типичная архитектура тестовой системы представлена на рис. 2. Тестовая система выполняется в НОЬ-симуляторе и эмулирует окружение тестируемой НОЬ-модели. В общих словах, она решает три задачи:

(1)генерация тестовой последовательности, (2) проверка корректности поведения ЬЮЬ-модсли и (3) оценка полноты тестирования. За решение каждой задачи отвечает свой компонент тестовой системы: соответственно генератор стимулов, тестовый оракул и сборщик тестового покрытия.

Н DL-симулятор Стимулы

Рис. 2. Архитектура тестовой системы (системы имитационной

верификации)

Генератор стимулов на основе тестовых сценариев или иных параметров генерации создает поток стимулов на тестируемую HDL-модель. Цель генератора — реализовать максимально возможное число ситуаций в работе устройства. В зависимости от используемой технологии сценарии (или непосредственно генераторы) описываются разными способами: используя техники случайной генерации, в том числе случайной генерации на основе ограничений [26] или на основе конечно-автоматных моделей (графов состояний). Первый подход используется в технологии UVM (Universal Verification Methodology) [27], продвигаемой организацией Accellera Systems Initiative; второй — в технологии UniTESK (Unified TEsting and Specification Kit) [28], разрабатываемой в ИСП РАН (см. раздел 3.1). Перспективным направлением является генерация тестов на основе статического анализа HDL-описания (см. раздел 4.1). Дополнительное представление о методах построения тестов для микропроцессоров дает раздел 2.3, посвященный системной верификации.

Тестовый оракул проверяет корректность поведения HDL-модели и выносит вердикт о его соответствии (или несоответствии) требованиям. Как правило, требования задаются посредством эталонной модели — упрощенной реализации устройства на языке программирования (С или C++) или SLDL-языке (SystemC или SystemVerilog). Также используются спецификации в декларативной форме: расширенные регулярные выражения [29],

контрактные спецификации [30], системы правил [31] и темпоральные утверждения [32]. Самым популярным формализмом, используемым для описания свойств аппаратуры, является темпоральная логика линейного времени (LTL, Linear Temporal Logic) [33], расширения которой используются в языках верификации аппаратуры (HVL, Hardware Verification Languages): ForSpec [34], OpenVera [35], Property Specification Language (PSL) [36], e [37], SystemVerilog2 [38].

Сборщик тестового покрытия предназначен для оценки полноты тестирования и принятия решения о его завершении. Для этого используются количественные показатели, называемые метриками [39]. Метрики могут определяться на основе разных артефактов проектирования (HDL-описания, эталонной модели, формальной спецификации или документации). Основная идея состоит в следующем. Некоторым систематическим образом определяется набор тестовых ситуаций, составляющих в совокупности тестовое покрытие. Для заданного выполнения тестовой системы (и HDL-модели) метрика возвращает число реализованных ситуаций. Цель тестирования — покрыть все ситуации в рамках выбранной модели покрытия. Метрики на основе реализации называются структурными, а метрики на основе спецификации — функциональными. Широко используются метрики на основе кода (HDL-описания и эталонной модели): покрытие строк кода, ветвей и путей в графе потока управления, условий. Для аппаратуры большую роль играют также метрики на основе автоматных моделей: покрытие состояний и переходов.

Как правило, тестовые системы разрабатываются не на уровне RTL, а на более высоком уровне абстракции — уровне транзакций (TLM, Transaction Level Modeling) [40, 25]. TLM-модели основаны на парадигме передачи сообщений: компоненты модели соединяются каналами и взаимодействуют друг с другом посредством транзакций (посылки и приема сообщений). Соответственно, стимулы и реакции внутри тестовой системы имеют форму сообщений, а их передача на входные интерфейсы HDL-модели (логически связанные группы сигналов) и прием с выходных интерфейсов осуществляется с помощью специализированных каналов, адаптеров (транзакторов), инкапсулирующих детали преобразования данных между разными уровнями. Для разработки TLM-моделей используются SLDL-языки, а также языки программирования общего назначения (см. табл. 1).

Язык SystemVerilog может использоваться как для проектирования аппаратуры, так и для верификации. Такие языки называются языками описания и верификации аппаратуры (HDVL, Hardware Description and Verification Languages).

2.3. Средства системной верификации

Верификация на системном уровне3 осуществляется путем создания тестовых программ и анализа результатов их выполнения на HDL-модели микропроцессора [41, 42]. Как правило, тестовые программы разрабатываются на языке ассемблера, а их целью является создание разнообразных ситуаций в работе микропроцессора (особые случаи выполнения арифметических операций, возникновение прерываний, заполнение буферов, вытеснение данных из кэш-памяти, сложные взаимодействия между модулями и т.п.). Ввиду высокой трудоемкости верификации тестовые программы обычно генерируются автоматически. Тесты, разработанные вручную, используются для проверки сложно формализуемых и маловероятных ситуаций (такие тесты создаются с привлечением экспертного знания об особенностях реализации той или иной подсистемы микропроцессора). Для верификации также применяется код, полученный с помощью компиляции существующих программ на языках высокого уровня: известных библиотек (вроде glibc), архитектурно-независимых тестов (типа арифметического теста PARANOIA [43]), тестов на оптимизирующий компилятор (создаваемый для разрабатываемого микропроцессора) и других.

Для автоматического построения тестовых программ применяются следующие способы [44]: (1) случайная генерация, (2) комбинаторная

генерация, (3) генерация на основе шаблонов и (4) генерация на основе моделей. Случайная генерация является самым распространенным методом создания тестовых программ. Примерами генераторов случайных тестов являются RAVEN (Random Architecture Verification Engine) [45], разработанный в Obsidian Software и в настоящее время используемый в ARM, и INTEG [46], созданный в НИИСИ РАН. Идея комбинаторной генерации состоит в систематическом переборе тестовых программ небольшого размера [42]. Различные варианты этого подхода реализованы в инструменте MicroTESK (Microprocessor TEsting and Specification Kit) [47], разрабатываемом в ИСП РАН (см. раздел 3.2.1). Более общий подход к генерации тестовых программ основан на использовании шаблонов — абстрактных символических представлений тестовых программ. Построение программ по шаблонам базируется на случайной генерации на основе ограничений [26]. Примерами инструментов такого типа являются Genesys-Рго [41, 48] от IBM Research и MicroTESK (см. раздел 3.2.2). Для генерации высококачественных тестовых программ могут использоваться модели уровня микроархитектуры [49, 50]. Коммерческие инструменты такого типа нам не известны, однако исследования на эту тему ведутся (см. раздел 4.2.1).

Для многоядерных микропроцессоров также применяется верификация уровня ядра. Сказанное в этом разделе относится как к системной верификации, так и к верификации уровня ядра.

Рис. 3. Системная верификация посредством сравнения трасс

Для проверки корректности поведения HDL-модели микропроцессора применяются два основных метода: (1) сравнение трасс выполнения тестовых программ с эталонными трассами и (2) использование тестовых программ со встроеннъши проверками (self-checking test programs). В первом подходе (см. рис. 3) при выполнении программы на HDL-модели создается трасса выполнения, отражающая события, возникающие в микропроцессоре. Полученная трасса сравнивается с эталонной трассой — трассой, полученной при выполнении той же программы на симуляторе микропроцессора. Сравнение трасс осуществляется с помощью специальной программы, называемой компаратором. Во втором методе в код тестовой программы (вручную или автоматически) включаются проверки, которые необходимо осуществить в процессе выполнения программы. Программы со встроенными проверками можно использовать не только для тестирования проекта в HDL-симуляторе, но и для его верификации с помощью аппаратных ускорителей и опытных образцов интегральных схем (post-silicon verification). Точность проверок при этом снижается (программно можно наблюдать лишь малую часть событий, возникающих в микропроцессоре: запись данных в регистр или память, прерывание и другие), однако производительность значительно возрастает (год круглосуточного тестирования с использованием тысяч компьютеров соответствует нескольким минутам реальной работы микропроцессора [7]).

Для принятия решения о завершении верификации, как и на модульном уровне, используются метрики тестового покрытия, однако они задают необходимое, но не достаточное условие сдачи проекта в производство (на системном уровне практически невозможно создать адекватную модель тестового покрытия). Большинство производителей микропроцессоров используют подход, основанный на измерении частоты обнаружения ошибок. Этот метод предполагает постоянный прогон случайно генерируемых тестов: когда частота обнаружения ошибок становится устойчиво низкой, и в течение длительного времени ошибки не проявляются, тестирование прекращается (при условии, что достигнуты показатели, заданные метриками). В начале 2000-х гг. в компании Motorola одним из необходимых условий сдачи проекта в производство была безошибочная работа HDL-модели в течение 40 миллиардов тактов на случайных тестах [51].

3. Выполненные исследования и разработки

Исследования по верификации аппаратуры ведутся в ИСП РАН с 2005 г., когда была показана применимость технологии UniTESK [28] к модульному тестированию HDL-моделей, и были разработаны средства интеграции тестовых систем, создаваемых с помощью инструмента CTESK [52], с HDL-симуляторами [53]. Немного позже, в 2006 г., начались совместные работы с НИИСИ РАН — организацией, занимающейся промышленной разработкой микропроцессоров. Темой первой из них стала генерация тестовых программ для подсистемы управления памятью (MMU, Memory Management Unit) MIPS-совместимого микропроцессора [54]. Вторая работа (которая тоже проводилась в 2006 г.) была посвящена модульной верификации буфера преобразования адресов (TLB, Translation Lookaside Buffer) [55]. Эти работы стали отправными точками дальнейших исследований и разработок в области верификации микропроцессоров, о которых рассказывается в этом разделе (следуя структуре статьи, сначала описываются средства модульной верификации, а потом — системной).

3.1. Разработки в области модульной верификации

При создании средств модульной верификации микропроцессоров и другой аппаратуры (на модульном уровне микропроцессорная специфика не заметна) нами использовался имеющийся задел в области тестирования программного обеспечения (ПО) — преяеде всего, технология UniTESK [28], развиваемая в ИСП РАН с момента его основания в 1994 г. (технология является преемницей подхода KVEST [56]). Технология базируется на контрактных спецификациях в форме пред- и постусловий интерфейсных операций и на уникальных средствах генерации тестовых последовательностей, основанных на факторизации (обобщении) состояний тестируемой системы и обходе графа состояний с помощью неизбыточных алгоритмов [57, 58].

Контрактные спецификации и основанный на них процесс проектирования (Design by Contract) [59] были предложены Мейером в 1986 г. в результате прикладного развития идей Флойда, Хоара и Дейкстры 1960-х - 1970-х гг. о формализации программирования [60, 61, 62]. Компонент, предоставляя окружению некоторую операцию, указывает требования, которые должны быть выполнены окружением перед ее вызовом (предусловие); при выполнении заданных требований компонент, в свою очередь, гарантирует достижение определенного результата (постусловие). Спецификации такого типа широко используются в практике тестирования ПО, поскольку они привычны для разработчиков и позволяют автоматически строить тестовые оракулы.

3.1.1 Контрактные спецификации конвейера

Используя опыт тестирования ПО, прежде всего, реализаций коммуникационных протоколов (для которых, как и для аппаратуры,

характерны параллелизм и событийный характер поведения) [63], подход ишТЕ8К был адаптирован для верификации ЬЮЬ-модслсй аппаратуры. Это потребовало уточнения понятия контракта. Классический контракт — это пара логических формул Ф = (ф, \|/), определенных над множеством видимых переменных (параметров вызова операции, возвращаемого ей результата, глобальных переменных программы). Первая формула, ср, называется предусловием, а вторая, у, — постусловием. Контракт интерпретируется следующим образом: если непосредственно перед вызовом операции было выполнено предусловие ф, то непосредственно после выполнения операции должно быть выполнено постусловие \|/. Нарушение контракта трактуется как ошибка: нарушение предусловия — ошибка окружения, нарушение

постусловия при выполненном предусловии — ошибка компонента.

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

аппаратуры, ввиду физических особенностей ее реализации, характерен высокий уровень параллелизма, что на логическом уровне выражается в конвейерно-параллельной организации (см. рис. 4). Последнее обстоятельство определило выбор названия для предлагаемого метода формальной спецификации — контрактные спецификации конвейера [64] (другое название — контрактные спецификации потактовой точности [65]).

Вызов операции (стимул)

Результаты микроопераций (реакции)

1 © ! © © ! (¡) !. 1 п ‘ ©

г я 1 1 1 1 Конвейерное выполнение | | ! О \ (г) 1 | 1 V © ® © 1

Перекрытие операций по времени 0 1 2 3 4 5

Время (такты), ?

Рис. 4. Конвейерное выполнение двух однотипных операций

Для аппаратуры без внутренних блокировок контракт операции имеет вид Ф = (ф- !('|'/-',)!, к»)- где ф — предусловие операции, у, — постусловие г-ой микрооперации, — время завершения выполнения г-ой микрооперации

161

(относительно времени вызова операции), п — общее число микроопераций [30]. Например, контракт операции х, представленной на рис. 4, имеет следующую структуру ФЛ. = <фх, {(уа, 1), (ц>ъ, 2), (ус, 2), (\\id, 4)}>. Семантику подобных контрактов можно определить в терминах логики LTL [33]. Так, контракт, приведенный выше, эквивалентен следующей формуле4: С(фх ->■ срх) л в(фх (Х\\/а л ХХ(уг,лус) л ХХХХу^)), где фх обозначает факт вызова операции х. Другой способ определить семантику спецификаций — описать на их основе тестовый оракул. Пусть X — алфавит операций. Для х е X введем следующие обозначения: v|/x(/) — конъюнкция постусловий микроопераций, помеченных временной меткой t, Ту — время выполнения операции (время завершения последней микрооперации). Тестовый оракул работает синхронно с проверяемой системой и вызывается на каяедом такте. Возможная организация выполняемой процедуры приведена в примере 1 (в начале работы S = 0 и v = true; в случае ошибки в v заносится false).

Пример 1. Организация тестового оракула для операций без блокировок

01: for х е X do проверка предусловий

операций

02: if фх л —i(px then v <— false

03 • for x e X do эмуляция вызова операций

04: if фх then S<r- S'u {(x, 0)}

05: for (x. Oe-S'do проверка постусловий

микроопераций

06: if then v <— false

07: S <- {(x, /+1) | (x, t) e S л / < Tx}

эмуляция такта работы системы

Если в аппаратуре возможны внутренние блокировки, формализация контракта операции немного усложняется. Предположим, что в рассматриваемом примере одноименные микрооперации, а также микрооперации а и b не могут выполняться одновременно (например, они используют общий ресурс), причем микрооперация а имеет больший приоритет по сравнению с Ь, а при других конфликтах приоритет получает та микрооперация, родительская операция которой была вызвана раньше. В такой ситуации конвейерное выполнение операций могло бы выглядеть, как показано на рис. 5. Формально блокировки конвейера могут быть описаны с помощью предусловий микроопераций, называемых также охранными условиями (guards) [64, 66]. Соответственно, контракт операции имеет вид

Темпоральный оператор G (Globally) требует, чтобы формула выполнялась всегда (начиная с текущего момента времени), X (neXt time) — чтобы формула выполнялась в следующий момент времени.

Ф = (ф- {(у,-. Ч'/- !<)! - і .¡'і/• где у, — охранное условие /-ой микрооперации. Охранные условия интерпретируются следующим образом: если для

некоторой микрооперации завершились все предшествующие ей действия и выполнено охранное условие, в этот момент должны быть видимы результаты ее работы5.

О @ V- о © - j>© ! і 1 1 Блокировки (с/) і і L J. J_

о © © @ ! ■ а ; О © | a 11

Конфликт а и b Конфликт bub

------------------------------------------------------------------►

О 1 2 3 4 5 6 f

Рис. 5. Конфликты и блокировки при конвейерном выполнении операций

Выразить такие свойства с помощью LTL проблематично. Возможным вариантом видится замена подформул вида Х...Ху|/, (используемых при описании операций без блокировок) на формулы6 -.у,- U (у, л у,), однако и этот вариант не вполне адекватен — в нем не принимается во внимание то обстоятельство, что охранное условие микрооперации должно учитываться только после того, как завершились все предшествующие действия (вследствие этого возможны ложные обнаружения ошибок). В предположении, что у каждой выполняемой операции в любой момент времени в обработке находится не более одной микрооперации, семантику спецификаций можно выразить следующим алгоритмом (см. пример 2) работы тестового оракула (первые четыре строки полностью совпадают с описанием алгоритма для случая операций без блокировок).

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

6 Бинарный темпоральный оператор U (Until) требует, чтобы первая

формула была выполнена до тех пор, пока не станет истинной вторая формула (такой момент обязательно должен наступить).

Пример 2. Организация тестового оракула для операций с блокировками

05: Е <- {(х, t) | (х, t) е S вычисление множества

активных микроопераций

06: for (х, I) е /•’ do проверка постусловий

активных микроопераций

07: if —then v <— false

08: S <— {(x, i+1) \ (x, t) e E л t < Tx} u (S\E) эмуляция такта работы

системы

Контрактные спецификации могут быть расширены для операций со сложной структурой потока управления [67]. Поток управления описывается ориентированным графом, в котором возможны следующие типы вершин: начало и конец (start и slop), микрооперация (stage), ветвление и соединение потока управления (switch и merge), создание параллельных процессов и их соединение (fork и join). Семантика подобных блок-схем может быть естественным образом формализована. Не останавливаясь на этом вопросе подробно, отметим следующие моменты: (1) как и прежде, каждая

микрооперация описывается парой (у, у); (2) обработка всех типов вершин, за исключением stage и join (когда есть незавершившиеся процессы), осуществляется мгновенно (сразу после обработки микрооперации вычисляется множество следующих микроопераций); (3) для моделирования задержек можно использовать вершины типа delay, в которых указана величина задержки (вершина delay At раскрывается в цепочку из At микроопераций с тривиальным контрактом (true, true)). Описание графа потока управления операции из рассматриваемого примера (см. рис. 4) приведено на рис. 6.

fork join

Рис. 6. Описание графа потока управления операции

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

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

Чаще используется второй подход — каждая микрооперация описывается тройкой (у, а, \|/). где а — это действие (элементарная программа) [68]. Отметим также, что точное определение охранных условий у (по существу, управляющей логики устройства) не всегда требуется — часто неважно, как устроен арбитр, управляющий доступом к некоторому ресурсу, главное, чтобы он был безопасным (safe) и справедливым (fair) — обеспечивал взаимное исключение процессов и рано или поздно давал доступ каждому желающему процессу7: G(|{y е Гд | у}| < 1) и Fy для всех у е Гд, где Гд — множество охранных условий микроопераций, желающих получить доступ к ресурсу R. Когда управляющая логика не специфицируется детально, охранные условия определяются через переменные HDL-модели (выходные или внутренние сигналы) — такие спецификации называются адаптивными, поскольку, используя обратную связь от реализации, они подстраиваются под ее поведение [69].

Контрактные спецификации конвейера можно использовать не только для проверки корректности поведения HDL-модели, но и для построения тестовой последовательности [65]. В подходе, описанном в [66], тестовая последовательность генерируется на лету (on the fly) на основе обхода состояний управления (множеств параллельно выполняемых микроопераций). Для этого используются неизбыточные алгоритмы обхода графов, позволяющие пошагово обходить сильно связные графы, располагая в каждый момент времени только информацией о текущей вершине (состоянии) и множестве исходящих из нее дуг (допустимых стимулов) [57, 58]. В большинстве проектов по верификации аппаратуры использовалась оптимизированная версия алгоритма и,пк11,_т. ориентированного на графы, в которых имеется детерминированный (по стимулам) сильно-связный полный остовный подграф [70].

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

Темпоральный оператор F (in the Future) требует, чтобы формула когда-нибудь выполнилась (начиная с текущего момента времени): Fy =

true U у.

детерминизации обходимого графа был предложен следующий подход: в состояние обработки операции (часть состояния управления) добавляется информация о ситуации, возникающей при выполнении операции, и зависимостях операции от других обрабатываемых операций [65]. Ситуация задает путь в графе потока управления операции (между вершинами start и stop) и детерминизирует выбор очередной микрооперации, зависимости определяют конфликты между операциями и детерминизируют установку блокировок. Понятно, что для сложного устройства граф может быть огромным, а его обобщение может снизить качество верификации. Для решения этой проблемы был предложен метод параллельного обхода графа на компьютерном кластере (см. раздел 3.1.3).

Инструментальная поддержка разработки контрактных спецификаций конвейера и тестов на их основе реализована в виде библиотечного расширения PIPE (от англ. pipeline — конвейер) инструмента CTESK [52]. Библиотека разработана на языке SeC (Specification extension of С), используемом в инструменте CTESK, и не привязана к конкретному языку описания аппаратуры. Основные возможности библиотеки PIPE можно разбить на две группы: (1) описание структуры конвейера — композиция операций из множества микроопераций с использованием описанных выше примитивов (switch, merge, fork, join и других); (2) эмуляция поведения конвейера — потактовое моделирование конвейера, основанное на отслеживании множества параллельно выполняемых микроопераций, и выполнение проверок, определенных в постусловиях микроопераций. Для разработки тестовых сценариев и генерации тестов использовались стандартные средства инструмента CTESK. В примере 3 приведено описание графа потока управления операции, рассмотренной ранее (см. рис. 6), средствами библиотеки PIPE.

Пример 3. Описание операции с использованием примитивов PIPE

01: specification void х(...) { описание операции х:

02: рге { ... } описание предусловия

операции

03: coverage { ... } описание тестового покрытия

04: }

05: reaction Process* «(void) { описание микрооперации а:

06: рге { ... } описание охранного условия

микрооперации

07: post { ... } описание постусловия

микрооперации

08: }

09: Operation *ор = create_Operation(x); описание графа потока

управления операции х:

10: registerStage (op, 0, а); вершина stage (метка 0,

спецификация а)

11: registerFork (op, 1, 3); вершина fork (метка следующие вершины 2 и 3) 1,

12: registerStage (op, 2, b)\ вершина stage (метка спецификация Ь) 2,

13: registerEdge (op, 2, 4); дуга ме5вду вершинами 2 и 4

14: registerStage (op, 3, c); вершина stage (метка спецификация с) з,

15: registerJoin (op, 4); вершина join (метка 4)

16: registerDelay (op, 5, 1); вершина delay (метка задержка 1) 5,

17: registerStage (op, 6, d); вершина stage (метка спецификация d) 6,

18: registerStop (op, 7); вершина stop (метка 7)

Предложенный метод и поддерживающий его инструмент (CTESK вместе с библиотекой PIPE) в 2007-2010 гг. использовались в нескольких проектах по верификации модулей микропроцессоров: буфера преобразования адресов TLB [55], модуля арифметики с плавающей точкой (FPU, Floating Point Unit)8 [71], кэш-памяти второго уровня (L2) [72] и коммутатора северного моста (Databox) [67]. Во всех модулях были обнаружены ошибки (включая критические), которые были пропущены другими методами верификации (это не удивительно, поскольку детальность спецификаций и систематичность перебора состояний делают подход сравнимым по полноте верификации с формальными методами). Наиболее сложный модуль, проверенный описанным методом, — коммутатор северного моста (описание модуля составляет около 6 тысяч строк на языке Verilog; модуль реализует около 60 различных типов операций9; выполнение некоторых операций занимает около 40 тактов). Метод хорошо себя зарекомендовал для сравнительно небольших и детально задокументированных устройств; для сложных проектов со скудной документацией затраты на разработку и отладку потактовых спецификаций трудно оценить [73]. Трудоемкость верификации устройств средней сложности (3-6 тысяч строк кода) составляют 0.7-1.3 человеко-месяца на 1 тысячу строк кода [72].

Сравнивая контрактные спецификации конвейера с другими формализмами, используемыми для описания поведения аппаратуры, следует еще раз упомянуть темпоральную логику LTL и ее варианты. Как было показано ранее, логика LTL не способна адекватно описать некоторые свойства, которые простым образом описываются с помощью контрактных

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

9 Под типами операций здесь понимаются не только коды операций, но

и различные способы выполнения (ветви функциональности).

спецификаций. В языках верификации аппаратуры, поддерживающих темпоральные утверждения (см. раздел 2.2), выразительные возможности LTL существенно расширены: можно обращаться к значениям переменных в прошлом и будущем, задавать временные интервалы наступления событий, описывать регулярные события, создавать параметризованные шаблоны утверждений, использовать в утверждениях присваивания [34]. Темпоральная логика такого вида позволяет описывать широкий диапазон свойств и активно используется в имитационной верификации, однако, как показывает опыт, инженеры не используют всех ее возможностей, а ограничиваются описанием простых причинно-следственных связей, которые, на наш взгляд, более естественно описываются в терминах контрактов и действий: (у, а, у) — «если у, выполнить а и проверить у».

Заметим, что добавление в контракты действий приводит нас к классическому формализму — охраняемым действиям (guarded actions), введенному Дейкстрой в 1975 г. [74], который в последнее время активно используется для высокоуровнего описания аппаратуры с последующим логическим синтезом [75] (в этой связи следует упомянуть язык Bluespec [76]). Охраняемыми действиями называются пары (у, а) (в другой форме — у —>■ а), интерпретируемые следующим образом: когда истинно условие у,

выполняется действие а. Учитывая то, что в контрактных спецификациях конвейера условия и действия структурированы в графы (см. рис. 6), рассматриваемая форма спецификаций имеет много общего с алгоритмическими машинами состояний (ASM, Algorithmic State Machines) — диаграммами, применяемыми для описания и синтеза аппаратуры [77, 78]. В ASM, однако, нет проверок (постусловий микроопераций) и не поддерживается параллельное выполнение микроопераций (вершины типа fork и join).

3.1.2 Событийные спецификации аппаратуры

При применении метода верификации на основе потактово точных контрактных спецификаций в промышленной практике были выявлены его ограничения и слабые места [40]: (1) высокие требования к качеству документации — как правило, описание модулей не отличается полнотой (акцент делается на их структуре, а не на требованиях к поведению); тонкости работы устройства, необходимые для создания потактовых спецификаций, описываются разработчиками с трудом (часто происходит апелляция к исходному коду); (2) медленный старт верификации — сроки проведения верификации ограничены, а результаты (единственным значимым результатом на практике являются найденные ошибки) требуется получить как можно скорее; детальные спецификации позволяют провести тщательную проверку, но результаты могут быть получены слишком поздно; (3) сложность интеграции в процессы проектирования — разработка модулей микропроцессоров часто сопровождается созданием их обобщенных моделей

на языках высокого уровня, таких как C++ и SystemC; вместо разработки спецификаций с нуля целесообразно использовать имеющиеся наработки.

В результате анализа опыта промышленной верификации используемый подход был расширен (2011 г.). В теоретическом плане, расширение подхода связано с переходом от потактовой парадигмы к событийной, что позволяет использовать спецификации с неточной моделью времени (с упрощенной или отсутствующей управляющей логикой). Используемая техника проверки корректности поведения HDL-моделей основана на динамическом сопоставлении трасс (частично упорядоченных множеств событий) [79]: одна трасса порождается реализацией, вторая — спецификацией (эталонной моделью). Практическая сторона работ связана с переходом от языка SeC (используемом в CTESK расширения ANSI С) к языку программирования C++, что дает возможность использовать в составе тестовых систем модели устройств (компоненты симулятора), создаваемые в процессе архитектурного проектирования (см. раздел 2).

Наблюдаемое поведение HDL-модели описывается временным словом — последовательностью вида {(«,. 1,)\, где а, — событие, a I, — время его наступления. События, происходящие в одно и то же время, допустимы, но должны возникать на разных интерфейсах устройства. Поведение эталонной модели задается временной трассой (или просто трассой) — частично упорядоченным множеством пар (a, t). Частичный порядок описывает причинно-следственные связи между событиями и другие ограничения, связанные с упорядоченностью. Заметим, что временные слова являются частной разновидностью трасс — трассами с тривиальным порядком (по сути, это означает отсутствие информации о взаимосвязях между событиями). При использовании неточных эталонных моделей трассы обобщаются — вместо временных меток указываются временные интервалы, задающие ограничения на времена возникновения событий в реализации [80]. Пример показан на рис. 7: наблюдаемое поведение верифицируемой HDL-модели описывается трассой {(b, 1), (а, 2), (с, 3), (с/. 5)}, поведение эталонной модели — {(а, 1), (b, 2), (с, 2), (с!. 3)}; при обобщении эталонной трассы временные метки расширяются до интервалов, но, вместе с тем, в трассу добавляется информация о зависимостях между событиями.

О

е е

о

®

© © @

4

4

Проверка

[О, 2]

2) [1-5]

Обобщение

Интервальная трасса

Рис. 7. Схема проверки соответствия между НОЬ-моделью и эталонной

моделью

В общих словах, суть выполняемой проверки поведения следующая: трасса реализации (НОЬ-модсли) должна быть линеаризацией трассы спецификации (эталонной модели), а временные метки событий реализации не должны выходить за рамки интервалов, заданных в соответствующих событиях спецификации (формальное определение можно найти в работе [79]). Важно отметить, что проверка соответствия трасс выполняется в динамике, а не после завершения верификации. Рис. 8 иллюстрирует проверку корректности поведения на примере трасс, показанных на рис. 7 (рассматривается момент времени / = 4). В верхней части изображены реакции НОЬ-модсли. в нижней

— реакции эталонной модели; отношение порядка между реакциями эталонной модели показано стрелками; пунктирные линии соединяют сопоставленные реакции.

Тестовый оракул, осуществляющий сопоставление трасс, имеет два типа входов: (1) реакции НОЬ-модсли и (2) реакции эталонной модели. На каждом такте тестовый оракул выполняет следующие действия: (1) прием реакций — полученные реакции спецификации и реализации, X’ и У’, заносятся в соответствующие частично упорядоченные множества событий, X и У: Х<—ХиХ, ) <— ) ’ и ) ': из обоих множеств удаляется пересечение множеств минимальных (по отношению порядка) элементов10:

(2) проверка превышения лимита времени — если время нахождения реакции в соответствующем множестве превышает заданную величину, фиксируется ошибка: пропущенная реакция (для реакции спецификации) или неожиданная реакция (для реакции реализации).

Как отмечалось выше, поведение реализации (как правило) моделируется трассой с тривиальным порядком (порядком, задаваемым отношением равенства), для которого все события являются минимальными.

Х<—Х\ (тт(Х) п да/и(У)), У <— У \ (тт{Х) п тт(У))

HDL-модель Прошлое Интервал d Будущее

Интервал с О

О Интервал b

Интервала \ О

0 1 / 2 3 4 5 t

Эталонная модель П-З] /?

[0,2] —П.5]

Рис. 8. Соответствие между HDL-моделью и эталонной моделью

Упрощенное описание алгоритма работы оракула на каждом такте верификации приведено в примере 4 (в начале работы А' = Y= 0 и v = true: в случае ошибки в v заносится false). Более детальное и формализованное описание можно найти в работе [79].

Пример 4. Примерный алгоритм работы тестового оракула

01: receive A ’, 7’

02: for (x. t) e X’ do

03: if (x. t) i Y then A' <— (x. t)

04: for (y. t) e ) ’ do

05: if (v, t) i A'then Y <— (v, t)

06: for (x. t) e X do

07: if timcout(x. t) then v <— false

08: for (i’. t) e ) do

09: if timeout(v, t) then v <— false

прием множеств реакции на текущем такте

сопоставление реакции эталонной модели

(несопоставленные реакции откладываются) сопоставление реакции НЭЬ-модели

(несопоставленные реакции откладываются) если для реакции эталонной модели превышен лимит времени, фиксируется ошибка: пропущенная реакция если для реакции НОЬ-модели превышен лимит времени, фиксируется ошибка: неожиданная реакция

Рассмотренный подход к проверке корректности поведения HDL-моделей был реализован в инструменте C++TESK [81]. Отношение порядка между реакциями эталонной модели может быть задано двумя способами:

(1) непосредственно в эталонной модели и (2) с помощью арбитров реакций [40]. Арбитр реакций задается для каждого выходного интерфейса и по запросу тестовой системы выдает очередную реакцию эталонной модели. Арбитры делятся на три типа: (1) модельные арбитры (которые при выборе реакции ориентируются только на порядок их выдачи эталонной моделью),

(2) адаптивные арбитры (которые осуществляют выбор реакции эталонной модели путем сопоставления с заданной реакцией реализации) и

(3) двухуровневые арбитры (которые работают в два этапа: сначала строят множество возможных реакций эталонной модели, используя модельный арбитр (множество минимальных по отношению порядка реакций), а затем применяют к полученному множеству адаптивный арбитр).

В основе C++TESK лежит библиотека классов, обеспечивающая разработку тестовых систем для HDL-моделей аппаратуры на уровне TLM (см. раздел 2.2). Средства инструмента позволяют создавать такие компоненты, как эталонные модели, адаптеры, тестовые сценарии, сборщики тестового покрытия и другие (см. рис. 2). Использование для создания тестовых систем языка программирования C++ позволяет без труда встраивать в них сторонние эталонные модели, разработанные на этом языке. В примере 5 показано описание операции, изображенной на рис. 6, средствами C++TESK. Обратим внимание, что процессы могут быть запущены как параллельным {PARALLEL), так и последовательным образом (SEQUENTIAL). При запуске процесса указывается интерфейс (ifacea, ifaceb, ifacec, ifaced) и входное сообщение для обработки (msga, msgb, msgc, msgd).

Пример 5. Описание операции с использованием примитивов C++TESK

01: DEFINE_STIMULUS (х) { описание операции х:

02: S Т ART_S TIMULU S (); начало операции

03: CALL_PROCESS(SEQUENTIAL, запуск микрооперации а

a, if асе а, msga);

04: CALL_PROCESS(SEQUENTIAL,

b, ifaceb, msgb)', запуск микрооперации о

05: CALL_PROCESS(PARALLEL, запуск микрооперации с

c, if ace c, msgc); (параллельно Ъ)

06: CYCLE(); задержка в один такт

07: CALL_PROCESS(SEQUENTIAL, d, запуск микрооперации с!

if ace d, msgd);

08: S T OP_S TIMULU S (); завершение операции

09: } описание операции х:

Инструмент C++TESK в 2011-2013 гг. использовался в ряде проектов по верификации модулей микропроцессоров [40, 79, 73]: межпроцессорного коммутатора данных (MAU Hub, Memory Access Unit’s Hub), системного контроллера прерываний (SAPIC, System Advanced Programmable Interrupt Controller), модуля поиска по таблице страниц (TLU, Table Lookup Unit), коммутатора северного моста (Databox), буфера команд (IB, Instruction Buffer), подсистем кэширования 2-ого и 3-ого уровней (L2 и L3). Предложенный метод позволил создать эталонные модели для модулей средней сложности без наличия детальной документации и найти большое количество сложных ошибок. Трудоемкость разработки тестовой системы в среднем оценивается в 1 человеко-месяц на 1 тысячу строк кода HDL-описания (причем работа по созданию эталонной модели трудно распараллеливается). Метод применим для верификации модулей средней сложности (до 10 тысяч строк кода) и модулей большой сложности (10-50 тысяч строк кода), но допускающих абстракцию управляющей логики. Для более сложных подсистем целесообразнее использовать верификацию с помощью тестовых программ (см. раздел 3.2).

Рассмотрим подходы, близкие к предлагаемому методу. В работе [82] используется модель автомата с частично упорядоченными входными/выходными событиями (РОЮ А, Partial Order Input/Output Automaton) для представления поведения эталонной модели и реализации. Если (1) реализация сообщает о приеме неподдерживаемых стимулов,

(2) можно установить порядок выдачи реакций реализацией, (3) время ответа реализации ограничено, и (4) каждый единичный переход в эталонной модели соответствует единичному переходу в реализации, можно установить соответствие между реализацией и эталонной моделью: они соответствуют друг другу, если реализация принимает допустимые эталонной моделью стимулы и выдает описываемые ею реакции в допустимом порядке. Данный подход к определению соответствия схож с предложенным нами, но отличается отсутствием контроля временных интервалов. В работе [63] рассматривается подход к тестированию параллельных систем с помощью неявно заданных асинхронных конечных автоматов (AFSM, Asynchronous Finite State Machines). Поведение реализации проверяется только в стационарных состояниях, в которых не ожидается выдача реакций:

(1) собираются все события, и определяется их частичный порядок;

(2) строятся и проверяются все возможные линеаризации событий. Считается, что реализация соответствует эталонной модели, если допускается хотя бы одна линеаризация. Данный подход, в отличие от предложенного метода, не может использоваться с произвольными генераторами стимулов, поскольку в нем требуется, чтобы в процессе тестирования регулярно возникали стационарные состояния, но, с другой стороны, он применим в том случае, когда не известен точный порядок выдачи реакций реализацией.

3.1.3 Распараллеливание процесса верификации

Способ генерации тестовых последовательностей, используемый в технологии ишТЕ8К [28], основан на обходе графа состояний тестируемой системы. Отличительной чертой технологии является то, что граф состояний задается неявно (с помощью функции построения текущего состояния и множества допустимых стимулов) и строится по мере его обхода [57, 58]. При проходе по дуге графа осуществляется подача стимула на тестируемую систему. Обход графа завершается после прохождения всех дуг (когда обнаружено, что ни из одной известной вершины не выходит непройденная дуга) или обнаружения ошибки (при невыполнении одного из постусловий). Для тестирования НБЬ-моделей аппаратуры пространство состояний задавалось множествами параллельно выполняемых микроопераций (см. раздел 3.1.1). Такой способ позволяет добиться высоких показателей тестового покрытия (см. раздел 2.2), однако получаемые графы могут быть очень большими. Так, для системного контроллера прерываний 8АР1С (простого устройства, НОЬ-описание которого содержит около 2 тысяч строк кода) граф состояний (для одного из тестовых сценариев11) содержал около 100 тысяч вершин и 500 тысяч дуг, а для модели коммутатора северного моста ЭгЦаЬох (около 6 тысяч строк кода)

— около 500 тысяч состояний и 2 миллионов дуг. Размер графов, используемых для генерации тестовых последовательностей, может быть уменьшен с помощью техник сокращения [83], однако это может снизить качество верификации.

Чтобы ускорить процесс тестирования (обход больших графов состояний) были использованы возможности, предоставляемые распределенными вычислительными системами (компьютерными кластерами). Был разработан метод, позволяющий динамически распараллеливать обход графа, не располагая при этом никакой информацией о его структуре до начала тестирования [84]. Реализация метода потребовала расширения классической архитектуры тестовой системы. Эго было сделано следующим образом. На каждом компьютере кластера выполняется свой процесс тестовой системы. Процесс осуществляет обход графа, а полученной информацией о пройденной части графа обменивается с процессами на других компьютерах кластера (заметим, что разные процессы могут использовать разные алгоритмы обхода). Архитектура процесса распределенной тестовой системы представлена на рис. 9 (для наглядности такие компоненты, как тестовый оракул и адаптер, опущены).

Процесс включает в себя следующие компоненты: (1) реализация алгоритма обхода (обходчик), (2) представление графа состояний (хранилище),

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

(3) синхронизатор и (3) генератор стимулов. Обходчик — это библиотечный компонент, который по запросу строит маршрут из текущей вершины графа в вершину, из которой выходят еще не пройденные дуги, и выбирает одну из них. Хранилище отвечает за представление пройденной части графа (посещенных вершин, допустимых в них стимулов, пройденных дуг). Синхронизатор получает от обходчика информацию о новых пройденных дугах и рассылает ее синхронизаторам других процессов; он также получает информацию о дугах, пройденных другими процессами, и передает ее своему обходчику (который добавляет информацию в хранилище). Генератор стимулов является активной частью тестовой системы, использующей обходчик для построения путей в графе и тестовый сценарий для вычисления текущего состояния и определения допустимых в нем стимулов. Более подробно архитектура тестовой системы и протокол синхронизации процессов описаны в работе [84].

Рис. 9. Архитектура процесса распределенной тестовой системы

Предложенный метод реализован в рамках проекта СТЕ8К [52] (в настоящее время разработанные средства также доступны в инструменте С++ТЕ8К [81]). Для управления процессом тестирования разработан координатор, позволяющий через \¥еЬ-интерфейс задавать такие параметры, как используемые для тестирования компьютеры, топологию связей между ними (граф обмена информацией) и другие. Координатор запускает процессы тестовой системы и собирает информацию о состоянии тестирования (размере пройденного графа, числе найденных ошибках и достигнутом уровне тестового покрытия). Так как обход графа может занимать продолжительное время, система поддерживает возможность сохранения и последующего восстановления пройденной части графа. Это позволяет при необходимости прервать тестирование или же продолжить его после сбоя без потери полученных результатов.

В 2010-2012 гг. подход применялся при верификации нескольких модулей микропроцессоров: коммутатора северного моста Ба1аЬох, системного

контроллера прерываний SAPIC и межпроцессорного коммутатора данных MAU Hub. Размеры графов доходили до нескольких миллионов вершин. Использование описанного подхода позволило существенно снизить время выполнения тестов, коэффициент эффективности распараллеливания превосходил 0.8 (то есть при использовании, например, 100 компьютеров время выполнения тестов уменьшалось более чем в 80 раз) [85]. Существующая реализация имеет ограничение — каждый процесс тестовой системы хранит совокупный граф состояний, между тем, графы могут быть настолько велики, что не помещаются в оперативной памяти компьютера (а при использовании внешней памяти сильно возрастает время построения путей). Одно из возможных решений этой проблемы предлагается в статье [86] — способ параллельного обхода, позволяющий избежать

дублирования информации о пройденной части графа в процессах, распределяя ее между ними.

3.2. Разработки в области системной верификации

Если при создании методологии модульной верификации микропроцессоров мы отталкивались от опыта разработки и применения технологии тестирования UniTESK [28], то, столкнувшись в 2006 г. с новой для нас задачей системной верификации (с задачей генерации тестовых программ на языке ассемблера для одноядерного MIPS-совместимого микропроцессора), выбор метода решения был неочевиден. Наиболее близкими подходами, разработанными в ИСП РАН, представлялись методы автоматического построения тестов (программ на языках высокого уровня) для проверки синтаксических анализаторов [87] и оптимизирующих компиляторов [88]. Эти методы основаны на синтаксических моделях: в первом из них используется грамматика языка, во втором — редуцированная грамматика, построенная с учетом алгоритма оптимизации.

В отличие от языков высокого уровня язык ассемблера имеет бедный, нерекурсивный синтаксис, что снижает значимость синтаксически-ориентированных методов (хотя в некоторой форме они используются для генерации ассемблерных программ [89] и могут быть полезны для построения графов потока управления программ [90] и композиции сложных программ из простых [91]). Следует также отметить, что методы, описанные в [87, 88] не учитывают семантику грамматических конструкций — между тем, это важно для генерации тестовых программ со встроенными проверками (см. раздел 2.3). На основе анализа большого числа методов и инструментов генерации тестовых программ для микропроцессоров (см., например, [42]) в качестве спецификаций были выбраны модели уровня системы команд.

3.2.1 Комбинаторная генерация тестовых программ

Модели уровня системы команд описывают микропроцессор в форме переменных (регистров и памяти) и команд — атомарных действий над

переменными (для которых также указываются предусловия). В отличие от детальных моделей, используемых для модульной верификации микропроцессоров, такие модели абстрагируются от структуры конвейера и совместного выполнения команд на нем. Основное назначение моделей уровня системы команд — формализация семантики команд и формирование программистского взгляда на микропроцессор (программист, составляя программу, считает команды атомарными — выполнение последовательности команд равносильно их последовательному выполнению одна за другой). Описание семантики команд на псевдокоде можно встретить в большинстве руководств по архитектуре микропроцессоров. В примере 6 приведено описание команды ADD (целочисленное сложение) из руководства по системе команд MIPS [92]. Команда имеет формат ADD rd, rs, rt, где rs, rt и rd — это номера регистров общего назначения (GPR, General-Purpose Registers).

Пример 6. Описание команды ADD архитектуры MIPS [92]

01:

02:

03:

04:

05

06

07

08

09:

if NotWordValue(GPR[rs]) or NotWordValue(GPR[rt]) then

UNPREDICTABLE

endif

temp <- (GPR[rs]3i||GPR[rs]3i 0) + (GPR[rt]3i||GPR[rt]3i o) if temp32 Ф temp3i then

SignalException(IntegerOverflow)

else

GPR[rd] <- sign_extend(temp3i o) endif

проверка предусловия команды:

если предусловие не выполнено, результат команды непредсказуем описание производимых действий:

если возникает переполнение, Г енерируется исключение, в противном случае записывается в регистр г проверка предусловия команды:

На основе анализа спецификации команды можно выделить набор тестовых ситуаций — ограничений на значения операндов команды и состояние микропроцессора, характеризующих различные способы выполнения этой команды. Как правило, тестовая ситуация соответствует одному из возможных путей в графе потока управления спецификации. В приведенном выше примере можно идентифицировать две тестовые ситуации: целочисленное переполнение (temp32 Ф temp3j) и нормальное выполнение (temp32 = temp3\), где temp = (GPi?[rs]3i || GPi?[rs]3i 0) + (GPR[rt\3г || GPR[rt]31 0) (символ || обозначает конкатенацию битовых векторов, а нижние индексы используются для выделения подмассива). Покрытие всех тестовых ситуаций реализуемых микропроцессором команд является необходимым, но не достаточным условием качественной системной верификации.

Другим типом информации, полезным для верификации микропроцессора, является информация о зависимостях между командами, характеризующая совместное выполнение команд на конвейере и, прежде всего, конфликты использования ресурсов (см. рис. 5). Обычно подобные сведения (за исключением очевидных зависимостей по регистрам) не отражаются в моделях уровня системы команд (и руководствах по системам команд) — их источником выступают спецификации конкретных микропроцессоров. В качестве примера рассмотрим следующую зависимость между командами обращения в память — попадание в разные строки кэш-памяти Ь1, расположенные по одному индексу (в одном множестве). Зависимость определяется организацией кэширования. В микропроцессорах семейства ЯМ7000 кэширование осуществляется по физическим 36-битным адресам: биты 2..0 адреса определяют позицию байта внутри двойного слова, биты 4..3

— позицию двойного слова в строке кэш-памяти, биты 11..5 — индекс строки и, наконец, биты 35.. 12 — тэг, используемый для проверки попадания данных в кэш-память [93] (см. пример 7).

Пример 7. Формат физического адреса в микропроцессоре 1047000 [93]

Тэг данных Индекс строки Ы Номер двойного слова Номер байта

35 12 11 5 4 3 2 0

Таким образом, две команды связаны зависимостью данного типа, если для физических адресов, по которым происходит реальное обращение в память (обозначим их х и у), выполнено ограничение (хп 5=>,п 5) л (х35Л2 ^Уъъ..12). Виртуальные 40-битные адреса (обозначим их а и Ь) должны быть подобраны соответствующим образом — если размер страницы виртуальной памяти составляет 4 килобайта (в этом случае биты 11..О виртуального адреса задают смещение, а биты 39.. 12 — номер страницы), должно выполняться условие (ац..5 = ¿11.5) а (039.12^*39.12), причем тар(аЪ9Л2) * тарфШЛ2), где тар — отображение страниц виртуальной памяти в страницы физической памяти, осуществляемое с помощью буфера трансляции адресов. Более детально различные типы зависимостей по физическим и виртуальным адресам рассмотрены в статье [54].

Идея предложенного подхода к построению тестовых программ, названного комбинаторной генерацией на основе моделей [94], основана на двух предположениях: (1) поведение микропроцессора определяется множеством параллельно выполняемых команд (загрузкой конвейера), зависимостями между командами (характером обращений к ресурсам микропроцессора), а также ситуациями, возникающими при выполнении команд (путями выполнения команд в конвейере); (2) ошибки (в ШБС-процессорах) могут быть обнаружены с помощью небольших тестовых примеров (состоящих из 2-

5 команд) [42, 94]. В простейшем случае генерация тестовых программ

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

Подход также позволяет комбинировать простые тестовые шаблоны (последовательности команд с заданными тестовыми ситуациями и зависимостями без указания конкретных значений операндов) в сложные [91]. Целью комбинирования является создание нетривиальных ситуаций в работе микропроцессора (одновременных исключений, параллельных конфликтов и других). Составление сложных тестовых шаблонов из простых может осуществляться с помощью следующих операций: наложение (Т\ || Т2 — объединение множеств тестовых ситуаций и зависимостей у однотипных шаблонов), сдвиг (7\ »Т2 — соединение шаблонов без отождествления команд со сдвигом одного относительно другого), конкатенация (7\ ■ Т2 — последовательное расположение шаблонов друг за другом) и вложение (71 [ТУ

— помещение одного шаблона внутрь другого). Генерация тестовых программ для фиксированного набора базовых шаблонов осуществляется путем перебора синтаксических деревьев ограниченного размера, описывающих составные шаблоны. В примере 8 приведен результат комбинирования простых тестовых шаблонов с помощью указанных операций (71[72»73]-74) [95].

Пример 8. Результат комбинирования тестовых шаблонов

шаблон Т\ (зависимость по адресам)

шаблон Т2 (зависимость по регистрам) шаблон 73 (конфликт между командами) шаблон Т2 шаблон 73

шаблон Т\

шаблон 74 (исключение

Отдельного упоминания заслуживает подход к генерации тестовых программ, содержащих команды ветвления. Как минимум, такие программы не должны зацикливаться. Построение тестовых программ осуществляется перебором разнообразных графов потока управления (структур переходов) и маршрутов в них (трасс выполнения) [90]. Перебор трасс выполнения для заданной структуры переходов основан на поиске в глубину в графе потока управления. Чтобы программа выполнялась согласно заданной построенной трассе, в нее

01: 1Л) ?,?(?) а 1ш<ТЬВ>(РРЫ 1)

02: АРБ г, ?, ?

03: Р1У.8 ?. ?. ?

04: 8иВ ?, г, ?

05: Р1У.Р ?. ?. ?

06- Ж ?’ ?(?)

@ 1Ш<ТЬВ>(РРЫ2) && РБМ = РЬЫ2

07: БРи ?, ?, ? @ ОуегПо\у

встраиваются вспомогательные команды, называемые управляющими. Представленный ниже пример 9 содержит команду перехода BEQ (переход по равенству), которая выполняется два раза (когда она выполняется первый раз, условие перехода истинно; затем условие делается ложным, и выполнение теста завершается). Управляющая команда (ADDI) инкрементирует один из регистров, используемых в команде перехода (вначале значения регистров равны).

Пример 9. Тестовый шаблон, содержащий команды ветвления

01: INU: инициализация регистров

02: ORI rl, r0, 2014 г1 — 2014

03: ORI r2, rO, 2014 г2 = 2014

04:

05: J START переход на начальную метку

06:

07: BACK: промежуточная метка

08: ADDI rl, rl, 1 управляющая команда

09: FPU ?, ?, ? команда тестового шаблона

10: START: начальная метка

11: BEQ rl, r2, BACK @ trace = {true, false} условный переход по равенству

12: LD ?, ?(?) команда тестового шаблона

13: STOP: инициализация регистров

Предложенный метод был реализован в генераторе тестовых программ для микропроцессоров MicroTESK12 [47] (первоначально инструмент был назван TestFusion4M [94]). Генератор реализован на языке программирования Java и состоит из трех основных компонентов: (1) библиотека моделирования — средства высокоуровневого описания микропроцессоров и реализуемых ими команд; (2) библиотека тестирования — средства разработки генераторов тестовых данных и тестовых последовательностей; (3) графическая оболочка

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

В этом разделе речь идет о генераторе MicroTESK версии 1.0 (2006-2008 гг.); в текущей версии инструмента (версии 2.0) реализованы дополнительные возможности, которые рассматриваются в разделе 3.2.2.

зависимости описываются конструктивно — для каждого типа тестовой ситуации (и зависимости) разрабатывается генератор, конструирующий случайные тестовые данные, удовлетворяющие заданной ситуации. В примере 10 приведен фрагмент описания команды ADD архитектуры MIPS (см. пример 6).

Пример 10. Описание команды ADD с использованием примитивов MicroTESK

01:

02:

03:

04:

05:

06:

07:

08:

09:

10:

11:

12:

13:

14:

15:

public class ADD extends Instruction { public ADD() {

rd = add(this, OUT, GPR, WORD);

}

public void execute(Processor processor) {

Data result = add(rs.getWord(), rt.getWord());

if(isOverflow32(result))

{ setException(new IntegerOverflowO); } else

{ rd.setWord(result); }

}

public String toStringO {

return format("ADD %s, %s, %s", rd, rs, rt);

}}

класс, описывающии команду ADD

конструктор класса команды:

добавление

операндов

метод, эмулирующий

выполнение

команды:

код соответствует

спецификации

команды (см.

пример 6)

метод вывода команды в формате языка ассемблера

Предложенный метод и генератор тестовых программ MicroTESK в 2006-2010 гг. использовались в нескольких проектах по верификации микропроцессоров и их компонентов: подсистема управления памятью (MMU, Memory Management Unit) [42, 54], MIPS-совместимый микропроцессор [42], два арифметических сопроцессора (CPI, СР2) [91]. Во всех указанных проектах были обнаружены ошибки, которые были пропущены другими

181

методами верификации. Наиболее сложное устройство, проверенное описанным методом, — MIPS-совместимый микропроцессор (одноядерный микропроцессор, реализующий более 200 команд; имеет в своем составе буфер трансляции адресов и двухуровневую кэш-память). При использовании метода не было выявлено ограничений на сложность верифицируемых систем (в классе одноядерных микропроцессоров). Трудоемкость разработки генератора тестовых программ определяется числом команд микропроцессора и составляет приблизительно 0.8 человеко-дня на одну команду (судя по всему, этот показатель может быть снижен за счет использования специализированных ADL-языков). Другие подходы к генерации тестовых программ рассмотрены в разделе 2.3.

3.2.2 Генерация тестовых программ на основе шаблонов

Одна из проблем, которая возникает при разработке нового микропроцессора, состоит в том, что имеющиеся генераторы тестовых программ сложно адаптировать к его архитектуре. Для этого приходится вручную модифицировать логику генерации, что приводит к дополнительным затратам ресурсов и чревато внесением ошибок. Генераторы, основанные на моделях, такие как Genesys-Pro [41], решают эту проблему, выделяя функции генерации в архитектурно-независимые компоненты. Адаптация генератора осуществляется путем изменения модели, инкапсулирующей архитектурнозависимую информацию. Для того чтобы облегчить создание модели нами был предложен подход [96], состоящий в использовании ADL-языков [19].

По характеру описываемых свойств ADL-языки принято разделять на две группы: структурные и поведенческие. Языки первой группы ориентированы на спецификацию микроархитектуры (примером такого языка является MIMOLA). Вторая группа концентрируется на описании команд микропроцессора (к этой категории можно отнести ISDL и nML). Кроме того, существуют смешанные языки, сочетающие возможности языков обеих групп (например, LISA и EXPRESSION). Для спецификации макроархитектуры наиболее подходят поведенческие ADL-языки, позволяющие явно описывать синтаксис и семантику команд. На основе этой информации может быть построена обобщенная модель микропроцессора, которую можно использовать для настройки генератора под конкретную архитектуру. Из нескольких поведенческих и смешанных ADL-языков, таких как LISA, EXPRESSION, ISDL и nML [19], был выбран последний. Данный язык обладает интуитивно понятным синтаксисом, имеет доступную документацию и используется в нескольких зарубежных университетах и коммерческих компаниях.

Язык nML [97] был разработан в начале 1990-х гг. в Берлинском техническом университете (Technische Universität Berlin) и изначально предназначался для создания симуляторов микропроцессоров и настраиваемых компиляторов. С конца 1990-х гг. nML активно используется Target Compiler Technologies [98]

для решения таких задач, как генерация симуляторов, компиляторов и HDL-моделей. Эта компания расширила язык nML средствами моделирования конвейера [98, 19]. Другая версия языка nML была разработана в Индийском технологическом институте Канпур (Indian Institute of Technology Kanpur) и получила название Sim-nML [99]. В язык были добавлены средства описания ресурсов микропроцессора. В Исследовательском институте информатики в Тулузе (Institut de Recherche en Informatique de Toulouse) для создания симуляторов микропроцессоров применяется язык пМР, основанный на Sim-nML [100, 101]. Среда генерации тестовых программ MicroTESK (версии 2.0) [47], разрабатываемая в ИСП РАН с 2010 г., использует nML для спецификации архитектуры верифицируемого микропроцессора.

Пример 11. Описание команды ADD на языке nML

01:

02:

03:

04:

05:

06:

07:

08:

09:

10:

11:

12:

13:

14:

op ADD (rd : index, rs : REG, rt : REG)

syntax = format("ADD %d, %s, %s" rd, rs.syntax, rt.syntax)

image = format("000000%s%s%5b00000100000", rs.image, rt.image, rd)

action = {

команда .¡1)1):

ассемблерный

формат

бинарный

формат

описание

семантики

temp = rs<31..31>::rs<31..0> + rt<31..31>::rt<31..0>; if (temp<32..32> != temp<31..31>) then

SignalException("Integer Overflow Exception"); else

GPR[rd] = temp<31..0>; endif;

}

mode REG (r : index) = if (r == 0) then 0 else GPR[r] endif

syntax = format("%d", r) image = format("%5b", r)

режим

адресации

REG:

ассемблерный

формат

бинарный

формат

Спецификация на языке пМЕ включает описание следующих сущностей: (1) элементов хранения данных (памяти, регистров, внутренних переменных), определяющих состояние микропроцессора; (2) команд, выполнение которых изменяет это состояние; (3) режимов адресации, реализующих абстракцию

доступа к элементам хранения данных. Пример 11 содержит спецификацию команды ADD архитектуры MIPS (см. пример 6) и спецификацию режима адресации REG, который она использует для чтения данных из регистров общего назначения.

Архитектура среды генерации тестовых программ Micro ТЕ SK показана на рис. 10. Среда включает в себя транслятор, который преобразует спецификацию на языке nML в исполнимую модель микропроцессора и модель покрытия. Модель микропроцессора строится на основе библиотеки моделирования и реализует следующие функции: (^предоставление метаинформации, описывающей элементы микропроцессора (регистры, память, команды и т.д.); {2) симуляция команд микропроцессора; (3) мониторинг состояния элементов памяти модели. Модель покрытия содержит информацию о ситуациях, которые могут возникнуть в процессе выполнения команд [102].

Формальные спецификации

) к

Тестовые шаблоны

MicroTESK

Транслятор

Модуль генерации модели

Модуль извлечения ______покрытия_______

Генератор

Обработчик тестовых шаблонов

Генераторы тестовых последовательностей

Г енераторы тестовых _______данных_________

Библиотека

Библиотека моделирования микропроцессоров

Библиотека описания _______покрытия________

Решатели

Универсальные

решатели

Специальные

решатели

Модель

микропроцессора

Модель покрытия

| Мета-информация | Симулятор

Монитор

Рис. 10. Архитектура среды генерации тестовых программ MicroTESK

MicroTESK генерирует тесты на основе тестовых шаблонов, представляющих собой абстрактные описания тестовых программ. Для их разработки используется язык описания тестовых шаблонов, реализованный в виде набора библиотек на языке Ruby [103], что отличает его от узкоспециализированных языков, используемых в инструментах Genesys-Рго [41] и RAVEN [45]. Средства языка описания тестовых шаблонов можно разделить на две группы: (1) встроенные конструкции Ruby (условные операторы, операторы циклов и т.д.) и (2) средства библиотек MicroTESK (базовые классы тестовых шаблонов, конструкции описания блоков построения тестовых последовательностей и другие). Пример 12 демонстрирует формат тестового шаблона.

Пример 12. Структура тестового шаблона на языке Ruby

01: class Template2014 < Template класс тестового примера

02: def pre... end инициализирующий код

03: def run ... end основной код

04: def post... end завершающий код

05: end

Основная секция тестового шаблона представляет собой иерархическую систему блоков, каждый из которых описывает способ генерации тестовой последовательности. Объединяющие блоки заданным образом комбинируют тестовые последовательности, описанные во вложенных блоках (см. раздел 3.2.1). Такой подход позволяет применять различные методы построения тестов в одном тестовом шаблоне (см. пример 13).

Пример 13. Фрагмент тестового шаблона с вложенными блоками

01:

02:

03:

04

05

06

07

08

09

10

11

12

13

14

block (xombinc => "product",

xompose => "random") { block (:engine => "random",

:length => 3, :count => 2) { ADD reg(8), reg(16), reg(17) SUB reg(9), reg(18), reg(19) AND reg(10), reg(16), reg(17) OR reg(ll), reg(18), reg(19)

}

block (:engine => "permútate") {

LW reg(12), reg(20), imml6(0) SW reg(19), reg(21), imml6(4)

объединяющий блок случайно смешивает все возможные комбинации результатов вложенных блоков

вложенный блок генерирует 2 случайные последовательности длины 3

вложенный блок генерирует последовательности из всех возможных перестановок команд

}

За генерацию тестовых программ по шаблонам в среде MicroTESK отвечает обработчик тестовых шаблонов, который формирует тестовые

последовательности, вызывая генераторы, указанные в блоках. Результатом являются символические тестовые программы, в которых операнды команд задаются с помощью тестовых ситуаций (ограничений, описывающих условия возникновения определенных событий в работе микропроцессора). Для конструирования значений операндов используются генераторы тестовых данных, основанные на решателях ограничений. После генерации значений операндов в тестовую программу добавляется инициализирующий код, в котором полученные значения записываются в соответствующие элементы памяти. Среда MicroTESK предоставляет набор универсальных и специальных решателей. Первые применимы для ограничений в широком классе теорий (булевой алгебры, целочисленной арифметики, теории битовых векторов и многих других). Вторые же предназначены для решения узкоспециализированных задач (например, для воспроизведения событий, связанных с подсистемой управления памятью [104, 105]).

4. Текущие работы и перспективы

При выборе тем для своих исследований ИСП РАН отталкивается от потребностей индустрии. Партнерские отношения с ведущими отечественными разработчиками микропроцессоров — НИИСИ РАН и ЗАО «МЦСТ» — позволяют изнутри увидеть проблемы, возникающие при промышленной верификации, и поставить актуальные задачи перед научными сотрудниками, аспирантами и студентами. Описанные выше подходы к проверке микропроцессоров были испытаны в реальных проектах, и, надо сказать, не всегда результаты их использования были положительными [73]. Мы тщательно анализируем негативный опыт, глубже проникаем в проблематику и стараемся найти решения возникающих задач. В этом разделе делается краткий обзор тем, над которыми мы работаем в настоящее время, и которые, так или иначе, имеют индустриальные корни.

4.1. Развитие средств модульной верификации

В промышленных технологиях верификации микропроцессоров возрастает роль формальных методов (проверки моделей, дедуктивного анализа, проверки эквивалентности). Одной из приоритетных задач модульной верификации является автоматическое построение формальной модели по HDL-описанию и генерация тестов на ее основе. Естественным формализмом для описания таких моделей является расширенный конечный автомат (EFSM, Extended Finite State Machine). В отличие от классического автомата, EFSM обладает переменными, а его переходы имеют особый вид. Каждый переход содержит охранное условие и действие над переменными: переход может сработать, только когда истинно охранное условие; при этом выполняется действие. Таким образом, EFSM — это множество охраняемых действий (см. раздел 3.1.1) над общими переменными, структурированное в систему переходов. Формализм охраняемых действий применяется для

описания сложных аппаратных систем, и для него разработаны эффективные алгоритмы синтеза [106].

Для извлечения ЕР8М-модели (автомата) из НОЬ-описания предлагается следующий подход [23]. Сначала из исходного кода извлекаются охраняемые действия. Затем из множества входных сигналов НОЬ-описания выделяется сигнал, по изменению которого меняется внутреннее состояние описываемого устройства (синхросигнал). После чего идентифицируются внутренние переменные НОЬ-описания. значения которых кодируют состояния устройства. Множество состояний автомата строится путем декомпозиции охранных условий, содержащих выделенные переменные состояния, на набор попарно несовместных ограничений (каяедое из полученных ограничений соответствует одному состоянию БЬВМ-модсли). Отношение переходов конструируется следующим образом. Для каждого действия проверяется совместимость его охранного условия с ограничениями, задающими состояния автомата. Таким образом определяется, из каких состояний есть переходы, помеченные данным охраняемым действием. Если имеется несколько состояний автомата, с которыми совместимо охраняемое условие, осуществляется «расщепление» перехода. Для того чтобы определить, в какое состояние ведет переход, проверяется совместимость результата символического выполнения действия с ограничениями состояний.

В качестве направлений дальнейших исследований рассматриваются следующие задачи: (1) генерация тестовых последовательностей на основе БЬВМ-модслсй [107] и (2) формальный анализ БЬВМ-модслсй на предмет достижимости ошибочных ситуаций (гонок, зависаний, конфликтов использования ресурсов) [108].

4.2. Развитие средств системной верификации

В рамках системной верификации микропроцессоров имеются две важные и взаимосвязанные темы, практически не затронутые нашими разработками: (1) верификация микропроцессоров на основе моделей уровня микроархитектуры и (2) верификация многоядерных микропроцессоров и многопроцессорных вычислительных комплексов. В настоящее время в ИСП РАН ведутся исследования по обоим направлениям. Работы по первой теме проводятся в контексте создания среды генерации тестовых программ М1сгоТЕ8К (см. раздел 3.2). Исследования по второй теме выполняются совместно с компанией ЗАО «МЦСТ», занимающейся разработкой многоядерных микропроцессоров и систем на их основе: МЦСТ-11500§ (2 ядра, 2008 г.), Эльбрус-2С+ (2+4 ядра, 2011 г.), МЦСТ-Ш000 (4 ядра, 2012 г.) и других [109]. Рассмотрим кратко содержание обозначенных работ.

4.2.1 Моделирование на уровне микроархитектуры

Модели, используемые в настоящее время в МюгоТЕ8К, игнорируют устройство конвейера и динамику совместного выполнения команд. С одной

стороны, это делает инструмент проще и облегчает его изучение и использование. С другой стороны, это сказывается на качестве генерируемых тестовых программ — на некотором этапе увеличение уровня тестового покрытия микропроцессора становится возможным только при существенном увеличении объема тестов. Обычно эта проблема решается с помощью ручного создания направленных тестов, точечно покрывающих ситуации, оставшиеся неохваченными, однако такой подход имеет два очевидных недостатка: (1) структурные метрики тестового покрытия (см. раздел 2.2) не позволяют выразить ситуации, связанные с взаимодействиями параллельных процессов; (2) ручная разработка тестов требует много ресурсов.

Модели уровня микроархитектуры позволяют задавать более адекватные метрики тестового покрытия, а также автоматизировать генерацию тестов, направленных на возникновение определенных событий в работе микропроцессора (особых случаев выполнения операций, прерываний, ситуаций заполнения буферов и т.п.). Кроме того, они делают возможной формальную верификацию проекта и могут использоваться для синтеза HDL-описания и генерации таких инструментов, как симулятор и компилятор (как правило, чем детальнее модель, тем точнее симулятор и эффективнее компилятор). В свою очередь, наличие средств кросс-разработки позволяет исследовать альтернативы проектных решений (выбор той или иной микроархитектуры) с использованием ПО (типовых задач), предназначенного для целевого микропроцессора [19].

Спецификация микропроцессора — это очень сложная задача, и выбор адекватного формализма имеет первостепенное значение. Важными требованиями к формализму, используемому для описания микроархитектуры, являются: (1) возможность частичной спецификации

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

Среди возможных вариантов рассматриваются следующие нотации: (1) графические языки типа UML (Unified Modeling Language) [110]; (2) Sim-nML [101] — расширение ADL-языка nML, используемого в генераторе тестовых программ MicroTESK (см. раздел 3.2.2); (3) EXPRESSION [19] — ADL-язык смешанного типа (позволяющий описывать не только систему команд микропроцессора, но и его структуру); (4) xMAS (Executable Micro Architecture Specifications) [111] — язык описания коммуникационных сетей; (5) Promela (Process meta language) [112] — язык описания процессов и протоколов, используемый в инструменте проверки моделей SPIN;

(6) Вкгеэрес [76] — язык, основанный на парадигме атомарных охраняемых действий.

4.2.2 Верификация реализаций протоколов когерентности

Вторая задача (верификация многоядерных микропроцессоров и многопроцессорных комплексов) связана с проверкой механизмов обеспечения когерентности памяти. Каждый узел системы (вычислительное ядро или микропроцессор) имеет в своем составе кэш-память, из-за чего в системе могут существовать несколько копий одних данных - одна копия в основной памяти и несколько копий в кэш-памяти узлов. При изменении копии данных в одном из узлов другие совладельцы этих данных должны согласованным образом изменить свои копии (или удалить их). Взаимодействие между узлами системы осуществляется согласно протоколу когерентности, за реализацию которого отвечают соответствующие механизмы подсистемы управления памятью. Их разработка осуществляется в два этапа: (1) проектирование протокола когерентности (и создание его формальной модели); (2) реализация протокола в аппаратуре. На первом этапе осуществляется верификация модели протокола; для этого используются формальные методы (прежде всего, проверка моделей и дедуктивный анализ). Для проверки реализации протокола (НОЬ-модели подсистемы управления памятью) обычно используется случайная генерация тестов, что не гарантирует выявления всех ошибок (пример - ошибка #298 в АМЕ) РЬепот [9]).

Представляется целесообразным использовать модели, применяемые для верификации протоколов когерентности, для тестирования НОЬ-моделей подсистем управления памятью. При этом возникают две задачи: (1) генерация тестов по модели и (2) детерминированное (сохраняющее порядок событий) воспроизведение построенных тестов на реализации. Первая задача решается методами тестирования на основе моделей (в том числе методами обхода графов состояний). Исследования, проводимые совместно с ЗАО «МЦСТ», сфокусированы на второй задаче и нацелены на создание средств, позволяющих тестировать реализации протоколов когерентности на основе трасс выполнения моделей. Разрабатываемые средства позволяют воспроизводить трассы на реализации, проверять корректность поведения реализации и оценивать уровень тестового покрытия. Кроме того, средства являются универсальными — применимыми к системам, основанным на разных архитектурах и протоколах когерентности [113]. Прототип инструмента позволил обнаружить ошибку в эталонной модели подсистемы управления памятью, которая не была обнаружена другими способами верификации.

4.3. Унификация и интеграция средств верификации

Среди задач, решаемых разными средствами верификации микропроцессоров (как модульного, так и системного уровней), есть много похожих. Унификация интерфейсов механизмов (engines) решения общих подзадач и создание библиотек переиспользуемых компонентов снижает трудоемкость разработки инструментов верификации, упрощает их интеграцию друг с другом и создает предпосылки для создания расширяемых сред [20, 44, 114]. Так, во многих средствах верификации (формальной и имитационной) применяются техники разрешения ограничений и реализующие их инструменты —решатели {solvers), например, Yices [115], Z3 [116] и другие. Сфера применения решателей широка: генерация тестовых данных [26], статический анализ HDL-описаний [23], символическая проверка моделей [117]. Ввиду многочисленности таких инструментов (каждый решатель лучше справляется с ограничениями того или иного вида) имеется потребность в унификации интерфейсов работы с ними.

В ИСП РАН была разработана библиотека JCS API (Java Constraint Solver API) [118], позволяющая описывать ограничения в форме объектов (синтаксических деревьев) на языке Java (на котором разработаны многие наши инструменты) и вызывать внешние решатели. В качестве основного средства взаимодействия JCS API с решателями используется язык SMT-LIB (Satisfiability Modulo Theories Library) [119], поддерживаемый многими инструментами. Библиотека, изначально разработанная в рамках проекта MicroTESK [47], где она применялась для генерации тестовых данных (см. раздел 3.2.2), в настоящее время активно используется в наших разработках в области анализа HDL-описаний (см. раздел 4.1). Развитие JCS API осуществляется по трем направлениям: (1) расширение множества

поддерживаемых операций и типов данных; (2) разработка средств трансформации ограничений (и других формул); (3) создание эффективных решателей, ориентированных на типичные виды ограничений, встречающиеся при верификации аппаратуры.

Другими работами общего характера, выполняемыми в ИСП РАН и связанными с верификацией микропроцессоров, являются: (1) эффективная реализация операций над битовыми векторами (такие операции могут быть полезны при построении симуляторов HDL- и ADL-моделей, а также при создании генераторов тестовых данных); (2) разработка библиотеки для представления моделей аппаратуры (автоматов, сетей и т.п.) и их анализа (библиотека может применяться в составе разных инструментов верификации, включая генераторы тестов и инструменты проверки моделей); (3) разработка средств интеграции разных инструментов верификации (преобразователей моделей, представленных в формате одного инструмента, в формат другого). В качестве примера интеграции разных инструментов верификации можно привести следующий. Для статического анализа HDL-описаний (см. раздел 4.1) мы используем открытую платформу ZamiaCAD [120], которая по

описанию аппаратуры на языке VHDL строит граф экземпляров модулей (IG, Instantiation Graph), преобразуемый с помощью средств интеграции во внутреннее представление наших инструментов.

5. Заключение

Несмотря на развитие методов функциональной верификации, их возможности не справляются со все возрастающей сложностью микропроцессоров [3]. Если первые устройства мог проверить буквально один человек путем непосредственного анализа (экспертизы) схемы из логических вентилей или даже транзисторов (микросхема 4004, выпущенная в 1971 г., состояла менее чем из 2.5 тысяч транзисторов, соединения между которыми можно изобразить на листе ватмана), то сейчас штат инженеров-верификаторов достигает внушительных размеров (последние образцы микропроцессоров содержат в 2 миллиона раз большее число транзисторов по сравнению с микросхемой 4004 — см. рис. 1 [2]). Костяк команды, работающей над проверкой PentiumPro (5.5 миллиона транзисторов), состоял из 10 человек, в проекте Pentium 4 (42 миллиона транзисторов) к ним присоединилось еще 60 [6]. Скорее всего, сейчас штат верификаторов в таких компаниях, как Intel, насчитывает несколько сотен специалистов (с тех пор прошло более 10 лет, а число транзисторов выросло более чем в 100 раз). Трудоемкость верификации огромна — сотни человеко-лет и миллионы часов компьютерного времени (только на формальную проверку Pentium 4 было затрачено 60 человеко-лет [51]).

Мечтой всех производителей микропроцессоров является автоматическое доказательство корректности проектирования. Некоторые компании, университеты и исследовательские институты проводят большую работу, чтобы приблизиться к этой мечте. По заявлению Боба Бентли (Bob Bentley), к 2015 г. Intel планирует увеличить долю использования формальных методов в модульной верификации микропроцессоров до 50% — это серьезный вызов, который потребует кардинальной перестройки процессов проектирования [14]. Если говорить о ситуации в настоящий момент времени, то основным подходом по-прежнему остается тестирование; но, нужно отметить, методы тестирования не стоят на месте и многое заимствуют из формальных методов. Скорее всего, взаимное проникновение разных методов верификации будет продолжаться, что приведет к появлению новых гибридных методов. Именно таким подходам, находящимся на стыке разных методов, посвящены исследования, выполняемые в ИСП РАН: формальная спецификация (на уровнях микро- и макроархитектуры), генерация тестов по моделям (потактовым, событийным, обобщенным), статический анализ HDL-описаний и другие. Результаты этих исследований нашли воплощение в инструментах CTESK [52], C++TESK [81], MicroTESK [47] и JCS API [118], которые успешно применялись в промышленных проектах.

Отдельно следует упомянуть проблему кадров. Кен Элбин (Ken Albin) из компании Motorola справедливо утверждает, что инженеры-верификаторы должны иметь совершенно другой набор знаний и навыков, нежели инженеры-проектировщики [51]. Среди качеств, желательных для верификатора, можно отметить следующие: умение изменять уровень абстракции модели, опыт программирования, знание основ проектирования аппаратуры, умение работать с огромными массивами данных, хорошие коммуникационные навыки и внутренняя мотивация. Кроме того, для работы в области формальной верификации требуется серьезная математическая подготовка (дискретная математика, математическая логика, теория трансляции и преобразования программ). Многие коммерческие компании осознают необходимость в подготовке высококлассных верификаторов и сотрудничают с ведущими университетами. Для развития отрасли крайне важно, чтобы университеты и исследовательские институты вели образовательную деятельность в области верификации и готовили квалифицированные кадры. На протяжении нескольких лет в ИСП РАН читаются лекции по методам верификации для студентов старших курсов МФТИ. Мы рассчитываем, что работа Института будет способствовать росту надежности микропроцессоров.

Список литературы

[1] В.В. Кулямин. Методы верификации программного обеспечения, 2008. 111 с. ('http://www.ispras.ru/~kuliamin/docs/VerMethods-2008-ru.pdf)

[2] Статистика числа транзисторов в микропроцессорах — http://en.wikipedia.org/wiki/Transistor count

[3] А.С. Камкин. Верификация микропроцессоров: борьба с ошибками и управление качеством. Электроника: НТБ, №3,2010. С. 98-104.

[4] J. Bergeron. Writing Testbenches: Functional Verification of HDL Models. Kluwer Academic Publishers, 2000. 354 p.

[5] G.E. Moore. Cramming More Components onto Integrated Circuits. Electronics Magazine, 86(1), 1965. P. 82-85.

('http://www.cs.utexas.edu/~fussell/courses/cs352h/papers/moore.pdf)

[6] B. Bentley. Validating the Intel® Pentium 4®Microprocessor. Design Automation Conference (DAC), 2001. P. 244-248.

[7] В. Bentley. Validating a Modem Microprocessor. International Conference on Computer Aided Verification (CAV), 2005. P. 2-4.

('http://www.cav2005.inf.ed.ac.uk/bentlev CAY 07 08 2005.ppt')

[8] FDIV Replacement Program: Description of the Flaw — http://www.intel.com/support/processors/pentium/sb/CS-013007.htm

[9] Revision Guide for AMD Family lOh Processors. Revision 3.84, August 2011. ihttp: //developer, amd. com/wordpress/media/2012/10/41322 .pdfl

[10] S. Barak. Intel Denies Core i7 TLB Bug. The Inquirer, December 02 2008. ('http://www.theinquirer.net/inquirer/news/1049427/intel-denies-core-i7-tlb-bug')

[11] Intel® Core™ i7-900 Desktop Processor Extreme Edition Series and Intel® Core™ i7-900 Desktop Processor Series. Specification Update, May 2011. ('http://download.intel.com/design/processor/specupdt/320836.pdF)

[12] E.M. Clarke, J.M. Wing. Formal Methods: State of the Art and Future Directions. ACM Computing Surveys, 28(4), 1996. P. 626-643.

[13] J. Harrison. Formal Methods at Intel—An Overview. Second NASA Formal Methods Symposium (NFM), 2010. ('http://www.cl.cam.ac.uk/~irhl3/slides/nasa-14aprl0/slides.pdf)

[14] P. McLellan. History of Formal Verification at Intel. DAC Blog, December 05 2012. ('http://blog.dac.com/post/2012/12/05/Historv-of-Foimal-Verification-at-Intel.aspx')

[15] R. Kaivola, R. Ghughal, N. Narasimhan, A. Telfer, J. Whittemore, S. Pandav,

A. Slobodova, C. Taylor, V. Frolov, E. Reeber, A. Naik. Replacing Testing with Formal Verification in Intel® Core™ i7Processor Execution Engine Validation. International Conference on Computer Aided Verification (CAV), 2009. P. 414-429.

[16] J. Bhadra, M. Abadir, S. Ray, L. Wang. A Survey of Hybrid Techniques for Functional Verification. IEEE Design & Test of Computers, 24(22), 2007. P. 112-122.

[17] Z. Navabi. Languages for Design and Implementation of Hardware. W.-K. Chen (Ed.). The VLSI Handbook. CRC Press, 2007. 2320 p.

[18] S. Mikhani, Z. Navabi. System Level Design Languages. W.-K. Chen (Ed.). The VLSI Handbook. CRC Press, 2007. 2320 p.

[19] P. Mishra, N. Dutt (Eds.). Processor Description Languages. Systems on Silicon.

Morgan Kaufmann, 2008. 432 p.

[20] В. Кулямин. Перспективы интеграции методов верификации программного обеспечения. Труды ИСП РАН, 16, 2009. С. 73-88.

[21] S. Agbaria, D. Carmi, О. Cohen, D. Korchemny, M. Lifshits, A. Nadel. SAT-Based Semiformal Verification of Hardware. Formal Methods in Computer-Aided Design (FMCAD), 2010. P. 25-32.

[22] H. Jain, D. Kroening, N. Sharygina, E. Clarke. VCEGAR: Verilog Counterexample Guided Abstraction Refinement Tools and Algorithms for Construction and Analysis of Systems (TACAS), 2007. P. 583-586.

[23] A. Kamkin, S. Smolov, I. Melnichenko. Static Analysis of HDL Descriptions: Extracting Models for Verification. East-West Design and Test Symposium (EWDTS), 2013. P. 184-187.

[24] W.K. Lam. Hardware Design Verification: Simulation and Formal Method-Based Approaches. Prentice Hall, 2005. 624 p.

[25] N. Bombieri, F. Fummi, G. Pravadelli, J. Marques-Silva. Towards Equivalence Checking between TLM and RTL Models. IEEE/ACM International Conference on Formal Methods and Models for Codesign (MEMOCODE), 2007. P. 113-122.

[26] Y. Naveh, M. Rimon, I. Jaeger, Y. Katz, M. Vinov, E. Marcus, G. Shurek. Constraint-Based Random Stimuli Generation for Hardware Verification. AI Magazine, 28(3), 2007.

P. 13-30.

[27] Технология верификации UVM — http://www.accellera.org/communitv/uvm

[28] A.B. Баранцев, И.Б. Бурдонов, А.В. Демаков, С.В. Зеленов, А.С. Косачев,

B.В. Кулямин, В.А. Омельченко, Н.В. Пакулин, А.К. Петренко, А.В. Хорошилов. Подход UniTesK к разработке тестов: достижения и перспективы. Труды ИСП РАН, 5,2004. С. 151-156.

[29] К. Sen, G. Rosu. Generating Optimal Monitors for Extended Regular Expressions. Electronic Notes in Theoretical Computer Science, 89(2), 2003. P. 162-181.

[30] В.П. Иванников, А.С. Камкин, А.С. Косачев, B.B. Кулямин, А.К. Петренко. Использование контрактных спецификаций для представления требований и функционального тестирования моделей аппаратуры. Программирование, № 5,2007. С. 47-61.

[31] Н. Barringer, D. Ry deheard, К. Havelund. Rule Systems for Run-Time Monitoring: From Eagle to RuleR. International Workshop on Runtime Verification, 2007. P. 111-125.

[32] A. Bauer, M. Leucker, C. Schallhart. Runtime Verification forLTL and TLTL. ACM Transactions on Software Engineering and Methodology, 20(4), 2011. P. 14:1-14:64.

[33] A. Pnueli. Temporal Logic of Programs. Symposium on Foundation of Computer Science (SFCS), 1977. P. 46-57.

[34] R. Armoni, L. Fix, A. Flaisher, R. Gerth, B. Ginsburg, T. Kanza, A. Landver, S. Mador-Haim, E. Singerman, A. Tiemeyer, M. Vardi, Y. Zbar. The ForSpec Temporal Logic: A New Temporal Property-Specification Language. Tools and Algorithms for Construction and Analysis of Systems (TACAS), 2002. P. 296-311.

[35] OpenVera® Language Reference Manual: Assertions. Version 1.4.1, November 2004.

[36] 1850-2010 — IEEE Standard for Property Specification Language (PSL), 2010.

[37] 1647-2011 — IEEE Standard for the Functional Verification Language e, 2011.

[38] 1800-2012 — IEEE Standard for SystemVerilog—Unified Hardware Design, Specification, and Verification Language, 2013.

[39] A. Pizialli. Functional Verification Coverage Measurement and Analysis. Kluwer Academic Publishers, 2004. 216 p.

[40] M. Chupilko, A. Kamkin. A TLM-Based Approach to Functional Verification of Hardware Components at Different Abstraction Levels. Latin American Test Workshop (LATW), 2011. P. 1-6.

[41] A. Adir, E. Almog, L. Fournier, E. Marcus, M. Rimon, M. Vinov, A. Ziv. Genesys-Pro: Innovations in Test Program Generation for Functional Processor Verification. IEEE Design

& Test of Computers, 21(2), 2004. P. 84-93.

[42] A.C. Камкин. Генерация тестовых программ для микропроцессоров. Труды ИСП РАН, 14(2), 2008. С. 23-63.

[43] Тестовая программа PARANOIA —

http://people.sc.fsu.edu/~%20iburkardt/c src/paranoia/paranoia.html

[44] А.С. Камкин, Т.И. Сергеева, С.А. Смолов, А.Д. Татарников, М.М. Чупилко. Расширяемая среда генерации тестовых программ для микропроцессоров. Программирование, № 1, 2014. (в печати)

[45] Слайды по генератору тестовых программ RAVEN —

http://www.slideshare.net/DVClub/introducing-obsidian-software-and-ravengcs-for-powerpc

[46] I.V. Gribkov, A.V. Zakharov, P.P. Koltsov, N.V. Kotovich, A.A. Kravchenko,

A.S. Koutsaev, A.S. Osipov, I.S Khisambeev. INTEG: A Stochastic Testing System for Microprocessor Verification. WSEAS International Conference on Circuits, Systems, Signal and Telecommunications (CSST), 2007. P. 55-59.

[47] Страница инструментаMicroTESK — http://forge.ispras.ru/proiects/microtesk

[48] Страница инструмента Genesys-Pro —

https://www.research.ibm.com/haifa/proiects/verification/genesvs pro/index.shtml

[49] P. Mishra, N. Dutt. Specification-Driven Directed Test Generation for Validation of Pipelined Processors. ACM Transactions on Design Automation of Electronic Systems, 13(3), 2008. P. 1-36.

[50] T.N. Dang, A. Roychoudhury, T. Mitra, P. Mishra. Generating Test Programs to Cover Pipeline Interactions. Design Automation Conference (DAC), 2009. P. 142-147.

[51] N. Mokhoff. Intel, Motorola Report Formal Verification Gains. EE Times, June 21 2001. ('http://www.eetimes.com/document.asp7doc id= 1215957)

[52] Страница инструмента CTESK — http://forge.ispras.ru/proiects/ctesk

[53] В.П. Иванников, А.С. Камкин, В.В. Кулямин, А.К. Петренко. Применение технологии UniTesK для функционального тестирования моделей аппаратного обеспечения. Препринт ИСП РАН, 2005. 16 с.

[54] Д.Н. Воробьев, А.С. Камкин. Генерация тестовых программ для подсистемы управления памятью микропроцессора. Труды ИСП РАН, 17,2009. С. 119-132.

[55] С.И. Аряшев, А.С. Камкин, Б.Ю. Рогаткин. Тестирование RTL-моделей аппаратуры с помощью технологии UniTESK на примере блока преобразования адресов микропроцессора. Электроника, микро- и наноэлектроника, 2007. С. 183-187.

[56] I. Bourdonov, A. Kossatchev, A. Petrenko, D. Gaiter. KVEST: Automated Generation of Test Suites from Formal Specifications. Formal Methods. World Congress on Formal Methods in the Development of Computing Systems (FM), 1, 1999. P. 608-621.

[57] И.Б. Бурдонов, А.С. Косачев, B.B. Кулямин. Неизбыточные алгоритмы обхода ориентированных графов. Детерминированный случай. Программирование, № 5, 2003.

С.11-30.

[58] И.Б. Бурдонов, А.С. Косачев, В.В. Кулямин. Неизбыточные алгоритмы обхода ориентированных графов. Недетерминированный случай. Программирование, № 1,

2004. С. 4-24.

[59] В. Meyer. Design by Contract. Technical Report TR-EI-12/CO, Interactive Software Engineering Inc, 1986.

[60] R.W. Floyd. Assigning Meaning to Programs. Symposium on Applied Mathematics, 1967. P. 19-32.

[61] C.A.R. Hoare. An Axiomatic Basis for Computer Programming. Communications of the ACM, 12(10), 1969. P. 576-585.

[62] E.W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976. 217 p.

[63] V. Kuliamin, A. Petrenko, N. Pakoulin, A. Kossatchev, I. Bourdonov. Integration of Functional and Timed Testing of Real-Time and Concurrent Systems. Perspectives of System Informatics, 2003. P. 450-461.

[64] A. Kamkin. Contract Specification of Pipelined Designs: Application to Testbench Automation. Spring Young Researchers’ Colloquium on Software Engineering (SYRCoSE), 2007. P. 7-13.

[65] A. Kamkin. Coverage-Directed Verification of Microprocessor Units Based on Cycle-Accurate Contract Specifications. East-West Design & Test Symposium (EWDTS), 2008.

P. 84-87.

[66] A.C. Камкин. Метод формальной спецификации аппаратуры с конвейерной организацией и его приложение к задачам функционального тестирования. Труды ИСП РАН, 16, 2009. С. 107-128.

[67] M. Chupilko, A. Kamkin. Developing Cycle-Accurate Contract Specifications for Synchronous Parallel-Pipeline Hardware: Application to Verification. Baltic Electronics Conference (ВЕС), 2010. P. 185-188.

[68] M. Chupilko, A. Kamkin. Specification-Driven Testbench Development for Synchronous Parallel-Pipeline Designs. NORCHIP, 2009. P. 1-4.

[69] M. Chupilko, A. Kamkin. Contract Specification of Hardware Designs at Different Abstraction Levels: Application to Functional Verification. Spring/Summer Young Researchers’ Colloquium on Software Engineering (SYRCoSE), 2010. P. 125-129.

[70] A.B. Хорошилов. Спецификация и тестирование систем с асинхронным интерфейсом. Препринт ПСП РАН, 2006. 139 с.

[71] А.С. Камкин, М.М. Чупилко. Тестирование модулей арифметики с плавающей точкой микропроцессоров на соответствие стандарту IEEE 754. Труды ПСП РАН, 14(2), 2008. С. 7-22.

[72] М. Chupilko, A. Kamkin, D. Vorobyev. Methodology and Experience of Simulation-Based Verification of Microprocessor Units Based on Cycle-Accurate Contract Specifications. Spring Young Researchers’ Colloquium on Software Engineering (SYRCoSE), 2008. P. 25-31.

[73] P.A. Баратов, А.С. Камкин, В.М. Майорова, А.Н. Мешков, А.А. Сортов,

М.А. Якушева. Трудности модульной верификации аппаратуры на примере буфера команд микропроцессора «Элъбрус-28». Вопросы радиоэлектроники, № 3, 2013. С. 84-96.

[74] Е. Dijkstra. Guarded Commands, Non-determinacy and Formal Derivation of Programs. Communications of the ACM, 18(8), 1975. P. 453-457.

[75] D.L. Rosenband, Arvind. Hardware Synthesis from Guarded Atomic Actions with Performance Specifications. International Conference on Computer-Aided Design (ICCAD),

2005. P. 784-791.

[76] Bluespec™SystemVerilog Reference Guide, 2012.

[77] C. Clare. Designing Logic Systems Using State Machines. McGraw-Hill, 1973. 150 p.

[78] S. Baranov. Logic and System Design of Digital Systems. TUT Press, 2008. 266 p.

[79] В.П. Иванников, А.С. Камкин, М.М. Чупилко. Проверка корректности поведения HDL-моделей цифровой аппаратуры на основе динамического сопоставления трасс. Tools & Methods of Program Analysis (TMPA), 2013. C. 71-82.

[80] M. Chupilko, A. Kamkin. Runtime Verification Based on Executable Models: On-the-Fly Matching of Timed Traces. Model-Based Testing Workshop (МВТ), 2013. P. 67-81.

[81] Страница инструмента C++TESK — http://forge.ispras.ru/cpptesk

[82] G. von Bochmann, S. Haar, C. Jard, G. V. Jourdan. Testing Systems Specified as Partial Order Input/Output Automata. International Conference on Testing of Software and Communicating Systems (TestCom), 2008. P. 169-183.

[83] И.Б. Бурдонов, А.С. Косачев, B.B. Кулямин. Использование конечных автоматов для тестирования программ. Программирование, 26(2), 2000. С. 61-73.

[84] И.Б. Бурдонов, С.Г. Грошев, А.В. Демаков, А.С. Камкин, А.С. Косачев,

А.А. Сортов. Параллельное тестирование больших автоматных моделей. Вестник ИНГУ, №3,2011. С. 187-193.

[85] A. Demakov, A. Kamkin, A. Sortov. High-Performance Testing: Parallelizing Functional Tests for Computer Systems Using Distributed Graph Exploration. Open Cirrus Summit, 2011.

[86] И.Б. Бурдонов, А.С. Косачев. Обход неизвестного графа коллективом автоматов. Научный сервис в сети Интернет: все грани параллелизма, 2013. С. 228-232.

[87] А.В. Демаков, С.А. Зеленова, С.В. Зеленов. Тестирование парсеров текстов на формальных языках. Программные системы и инструменты: Тематический сборник факультета ВМиК МГУ, № 2, 2001. С. 150-156.

[88] С.В. Зеленов, С.А. Зеленова, А.С. Косачев, А.К. Петренко. Применение модельного подхода для автоматического тестирования оптимизирующих компиляторов, 2003.( http : //citforum. ru/SE/testing/compilers'l

[89] L.-M. Wu, К. Wang, С.-Y. Chiu. A BNF-Based Automatic Test Program Generator for Compatible Microprocessor Verification. ACM Transactions on Design Automation of Electronic Systems, 9(1), 2004. P. 105-132.

[90] A.C. Камкин. Некоторые вопросы автоматизации построения тестовых программ для модулей обработки переходов микропроцессоров. Труды ИСП РАН, 18, 2010. С. 129-149.

[91] Д.Н. Воробьев, А.С. Камкин. Генерация тестовых программ для микропроцессоров на основе шаблонов конвейерных конфликтов. Труды ИСП РАН, 18, 2010. С. 91-113.

[92] MIPS64™ Architecture For Programmers, Revision 2.0. MIPS Technologies Inc, June 9 2003.

[93] RM7000 Family User Manual. Issue 1, May 2001.

[94] A.C. Камкин. Комбинаторная генерация тестовых программ для микропроцессоров на основе моделей. Препринт ИСП РАН, 2008. 18 с.

[95] A. Kamkin, Е. Komykhin, D. Vorobyev. Reconfigurable Model-Based Test Program Generator for Microprocessors. International Conference on Software Testing, Verification and Validation Workshops (ICSTW), 2011. P. 47-54.

[96] A. Kamkin, A. Tatamikov. MicroTESK: An ADL-Based Reconfigurable Test Program Generator for Microprocessors. Spring/Summer Young Researchers’ Colloquium on Software Engineering (SYRCoSE), 2012. P. 64-69.

[97] M. Freericks. The nML Machine Description Formalism. Techical Report. TU Berlin, FB20, Bericht, 1991/15. 47 p.

[98] Страница компании Target Compiler Technologies — http://www.retarget.com

[99] S. Chandra, R. Moona. Retargetable Functional Simulator using High Level Processor Models. VLSI Design, 2000. P. 424-429.

[100] Страница инструмента GLISS —

http://www.irit.fr/recherches/ARCHI/MARCH/rubriaue.php37id rubriaue=54

[101] H. Cassé, J. Barre, R. Vaillant, P. Sainrat. Fast Instruction-Accurate Simulation with SimNML. Workshop on Rapid Simulation and Performance Evaluation: Methods and Tools (RAPIDO), 2011. P. 8-12.

[102] A. Kamkin, T. Sergeeva, A. Tatamikov, A. Utekhin. MicroTESK: An Extendable Framework for Test Program Generation. Spring/Summer Young Researchers’ Colloquium on Software Engineering (SYRCoSE), 2013. P. 51-57.

[103] Язык программирования Ruby — http://www.rubv-lang.org

[104] E. Komykhin. SMT-Based Test Program Generation for Cache-Memory Testing. East-West Design & Test Symposium (EWDTS), 2009. P. 124-127.

[105] E. Komykhin. Generation of Test Data for Verification of Caching Mechanisms and Address Translation in Microprocessors. Programming and Computing Software, 36(1),

2010. P. 28-35.

[106] J. Brandt, M. Gemixnde, K. Schneider, S. Shukla, J.-P. Talpin. Integrating System Descriptions by Clocked Guarded Actions. Forum on Design Languages, 2011. P. 1-8.

[107] G. Guglielmo, L. Guglielmo, F. Fummi, G. Pravadelli. Efficient Generation of Stimuli for Functional Verification by Backjumping Across Extended FSMs. Journal of Electronic Testing, 27(2), 2011. P. 37-162.

[108] B. Karaçali, K.-C. Tai, M.A. Vouk. Deadlock Detection ofEFSMs using Simultaneous Reachability Analysis. Dependable Systems and Networks (DSN), 2000. P. 315-324.

[109] A.K. Ким, В.И. Перекатов, С.Г. Ермаков. Микропроцессоры и вычислительные комплексы семейства «Эльбрус». СПб.: Питер, 2013. 272 с.

[110] Сайт ресурсов UML — http: //www.uml. org

[111] S. Chatterjee, M. Kishinevsky, U. Ogras. xMAS: Quick Formal Modeling of Communication Fabrics to Enable Verification. IEEE Design & Test of Computers, 2011. P. 80-88.

[112] G.J. Holzmann. The SPIN Model Checker: Primer and Reference Manual. Addison-Wesley, 2003. 608 p.

[113] A.C. Камкин, M.B. Петроченков. Система поддержки верификации реализаций протоколов когерентности с использованием формальных методов. Вопросы радиоэлектроники, серия ЭВТ, 2014. (в печати)

[114] К. Schneider, Т. Kropf. A Unified Approach for Combining Different Formalisms for Hardware Verification. International Conference on Formal Methods in Computer Aided Design (FMCAD), 1996. P. 202-217.

[115] B. Dutertre, L. Moura. The YICES SMI Solver, 2006. ('http://vices.csl.sri.com/tool-paper.pdf).

[116] L. Moura, N. Bjemer. Z3: An Efficient SMI Solver. Tools and Algorithms for the Construction and Analysis of Systems (TACAS), 2008. P. 337-340.

[117] K.L. McMillan. Symbolic Model Checking. Kluwer Academic, 1993. 194 p.

[118] Библиотека Java Constraint Solver API — http://forge.ispras.ru/proiects/solver-api

[119] D.R. Cok. The SMT-LIBv2 Language and Tools: A Tutorial. GrammaTech, Inc.,

Version 1.1, 2011.

[120] Страница инструмента ZamiaCAD — http: //zamiacad. sourceforge.net

Tools for Functional Verification of Microprocessors

A. Kamkin, A. Kotsynyak, S. Smolov, A. Sortov, A. Tatarnikov, M. Chupilko {kamkin, kotsynyak, ssedai, sortov, andrewt, chupilko} @ispras. ru

Abstract. Ensuring the correctness of microprocessors and other microelectronic equipment is a fundamental problem. To deal with it, various tools for functional verification are used. Unlike bugs in software programs which are relatively easy to fix (it does not apply to their consequences), defects in integrated circuits (both design and manufacturing ones) cannot be removed. In spite of continuous development of computer-aided design (CAD) systems, test generation tools and approaches to analysis of circuits, verification remains the bottleneck of the microprocessor design cycle (it accounts for approximately 70 percent of total design resources). The article gives a brief overview of microprocessor verification tools, describes issues that commonly occur in industrial practice and analyzes possible ways to solve them. The main part of the article is dedicated to research in the field of hardware verification conducted at ISPRAS. It summarizes the outcomes of accomplished projects, describes the present works and formulates the directions of further research.

Keywords: microprocessors, hardware, verification, validation, testing, test generation, modeling, architecture description languages, parallelization.