Программные продукты и системы

По данным различных источников, трудозатраты на верификацию и валидацию микропроцессора (МП) составляют до 70 % общих трудозатрат на разработку. Так как современные микропроцессоры постоянно усложняются, для проведения работ по верификации в заданное (ограниченное согласно плану верификации) время требуется применение разнообразных методов и средств. Верификация процессора включает в себя три этапа:

–      верификация RTL-модели и ПЛИС-прото­типа микропроцессора;

–      валидация тестового кристалла (first-pass silicon validation);

–      валидация серийно выпускаемых экземпляров СБИС (post-silicon validation).

Основные усилия инженеров-верификаторов направлены на нахождение ошибок на стадии RTL-модели. Причина в том, что время нахождения и стоимость исправления таких ошибок на порядки ниже времени и стоимости, затрачиваемых на правку ошибок, найденных на второй и третьей стадиях. Однако верификация RTL-модели имеет ряд недостатков. Главный из них – очень низкая скорость выполнения инструкций на модели, которая приводит к невозможности выполнения достаточного количества тестов. Поэтому верификацию и тестирование следует продолжать на стадиях ПЛИС-прототипа, тестового кристалла и после выпуска партии готовых СБИС. На второй и третьей стадиях верификации благодаря возросшей скорости появляется возможность выполнить гораздо более объемные тесты, существенно увеличить покрытие кода RTL-модели. Состоятельность этого подхода подтверждает информация различных фирм-изготовителей об ошибках в уже выпущенных микропроцессорах (например [1, 2]).

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

Обзор тестов верификации

Тесты, разрабатываемые для верификации микропроцессоров и их RTL-моделей, делятся на четыре основные группы.

1.     Тесты разработчика – тесты, направленные на инструкцию, набор инструкций микропроцессора или на какой-либо функциональный блок. Такие тесты почти всегда создаются со встроенным механизмом самопроверки и развитой диагностикой ошибочных ситуаций. Как правило, разрабатываются на языке ассемблера или С.

2.     Псевдослучайные тесты – тесты, созданные с помощью генератора тестов на основе шаблона. Метод основан на покомандном сравнении трасс RTL-модели с эталонным эмулятором, который называют golden model (золотая модель).

3.     Переборные тесты (constraint-driven test generation) – тесты для одной или нескольких инструкций, которые создаются автоматически.

4.     Запуск одной или нескольких ОС и приложений под ОС.

В настоящей работе предлагается развитие последнего метода – запуска ОС и существующего ПО под ОС. Этот метод имеет следующие достоинства.

·       ОС является большим программным комплексом, использующим различные особенности микропроцессорной архитектуры. Поэтому сама по себе ОС – большой архитектурный тест.

·       Пользовательские пакеты программ под ОС, как правило, содержат встроенные в дистрибутивы пакетов наборы готовых самопроверяющихся тестов.

·       Найденные в результате прохождения тестов ПО ошибки служат основой для создания шаблонов псевдослучайных тестов.

·       Простота процесса запуска ПО и тестов под него означает невысокие накладные расходы на один тест.

·       Возможно использование огромного количества уже существующих тестов под ОС, таких как LTP (Linux Test Project), SPEC CPU 2000/2006.

·       Возможно изучение производительности процессора, например, анализ трасс на потактовом эмуляторе и результатов тестов, измеряющих производительность на готовом кристалле.

·       Возможно решение задач на родной платформе, таких как программирование в среде ОС специализированных сопроцессоров, входящих в состав разрабатываемого микропроцессора.

·       Можно выбрать из множества программ пользователя подходящий набор тестов для создания блока функционального контроля, на котором проводятся приемочные испытания изготавливаемых СБИС микропроцессоров.

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

·       Метод начинает работать уже тогда, когда на образцовом эмуляторе (виртуальном прототипе) или на ПЛИС-прототипе еще до выпуска тестового кристалла разработчики ПО начинают портирование (адаптацию), разработку и верификацию своего ПО параллельно с разработкой и верификацией RTL-модели микропроцессора.

Необходимо отметить и недостатки данного метода:

–      множество повторяющихся массивов кода приводит к избыточности метода без значительного увеличения тестового покрытия;

–      локализация ошибки нередко затруднена сложностью ПО;

–      тестируемый объект представляется в виде черного ящика, хотя есть возможность проверки RTL-модели механизмом утверждений (assertion checkers);

–      высока стоимость исправления ошибки, если она найдена в серийно выпускаемой СБИС.

Частный случай применения метода тестирования микропроцессоров готовыми пользовательскими приложениями описывается создателями процессора OpenRISC 1200 [3]. Авторы статьи используют для верификации лишь внутренние тесты компилятора GCC, обходясь при этом без ОС (bare metal environment). Этот подход позволяет запускать в общей сложности более 80 000 тестов для тестирования микропроцессора. Однако есть возможность расширить данный подход, включив в перечень тестов загрузку ОС, другое ПО и его внутренние проверки.

Наличие огромного количества свободно распространяемых программ с открытым исходным кодом, большинство из которых имеют встроенные механизмы самопроверки, делает возможным выделение запуска приложений под ОС Linux в отдельный подход к верификации универсальных микропроцессоров. Конечно, применение описываемого метода ни в коем случае не исключает, а лишь дополняет современный набор методов и средств тестирования и верификации микропроцессоров и их моделей. Стоит отметить факт создания специальной ОС для верификации аппаратного обеспечения [4].

Многие авторитетные фирмы-разработчики микропроцессоров признают полезность как можно более ранней загрузки какой-либо ОС на разрабатываемой RTL-модели [5]. Успешность этой операции зачастую дает разработчикам больше уверенности в правильности уже проделанной работы, чем тысячи прошедших тестов.

Объекты тестирования

Существуют пять различных объектов, к которым применима описываемая методика при проведении работ по верификации и тестированию: RTL-модель микропроцессора, покомандный эмулятор (С-модель, golden model), ПЛИС-прототип, тестовый кристалл микропроцессора, выпущенная в серийное производство СБИС.

Для загрузки ОС Linux процессору требуется выполнить порядка 109–1010 инструкций. Скорость симуляции RTL-модели сложного МП весьма низкая – до 103 инструкций в секунду при моделировании на современном ПК. Поэтому целесообразно использовать механизм среза-восстановления состояния модели микропроцессора для разбиения всей последовательности команд загрузки ОС на несколько подпоследовательностей, которые выполняются параллельно на разных вычислительных устройствах. Под срезом состояния понимается дамп ОЗУ, кэш-память всех имеющихся уровней, состояние регистровых файлов регистров общего назначения и сопроцессоров, TLB (translation lookaside buffer – буфер ассоциативной трансляции), а также значение PC (program counter – счетчик команд). Для быстрого получения среза состояния удобно использовать покомандный эмулятор (скорость моделирования (1–3)*106 инструкций в секунду) [6].

Критерием успешной загрузки ОС служит результат покомандного сравнения трасс выполнения кода на RTL-модели с трассами, полученными на покомандном эмуляторе. Как только ОС загружена на RTL-модели, код проекта, написанный на языке Verilog или VHDL, синтезируется в ПЛИС. ПЛИС-прототип микропроцессора, несмотря на относительно невысокую частоту функционирования (десятки мегагерц), позволяет создать отладочный стенд, представляющий полнофункциональную плату с возможностью запуска ОС Linux и программ пользователя (см. таблицу).

В зависимости от назначения разрабатываемого микропроцессора отладочная плата с ПЛИС либо с тестовым кристаллом может содержать контроллеры Ethernet, IDE- или SCSI-HDD-дис­ков, USB, графический контроллер.

Существующее ПО

В качестве тестов в рассматриваемой методике предлагается запускать реальные пользовательские пакеты программ и встроенные в дистрибутивы пакеты тестов (выполнив команду ОС Linux «make check»). Источником большинства тестовых программ является глобальная сеть Интернет, например, пакеты набора GNU [7]. Для сборки программ требуется наличие нативного или кросс-компилятора для различных языков программирования (наиболее часто встречаются C, C++ и Fortran). Тестовый набор зависит от имеющегося на верификацию времени, скорости работы ПЛИС-прототипа или тестового кристалла. Например, он может включать в себя запуск следующего ПО.

Операционные системы:

–      сборка ядра ОС Linux: 32/64-разрядные версии дистрибутивов Red Hat и Debian;

–      сборка и запуск ОС реального времени VxWorks.

Пакеты тестов:

–      пакет тестов LTP – тест системы в целом;

–      пакет вычислений простых чисел glucas, который интенсивно использует FPU и L2 кэш-память (аналог известного стрессового теста prime95 для x86-архитектуры);

–      тест памяти memtester – задействует все подсистемы памяти;

–      тесты производительности процессора dhrystone, whetstone, coremark, Lmbench, MiBench, HPL (MPI + ATLAS/GotoBLAS), CPU SPEC2000, CPU SPEC2006.

Прикладное ПО:

–      среда рабочего стола KDE или Gnome;

–      игры kdegames, wormux, prboom;

–      пакет офисных программ koffice (libre­office);

–      интернет-браузер mozilla-firefox.

Приложения, получаемые с помощью команды apt-get в ОС Debian [8].

Встроенные тесты (вызываемые shell-командой ОС Linux «make check») пакетов пользовательского ПО:

–      компиляторы набора GNU gcc, g++, gfortran, gcj;

–      трансляторы языков программирования ruby, python, perl, php, haskell;

–      кодеры/декодеры аудио mp3/flac lame, flac и видео ffmpeg;

–      математические библиотеки точных вычислений gmp, mpfr, mpc, gappa и другие.

Предложенный перечень тестовых задач является лишь начальной точкой при рассмотрении тестового набора. Интерес представляет разнообразная сборка исходных кодов для получения как можно большего многообразия исполняемого кода:

–      различными версиями компиляторов;

–      с несколькими ключами оптимизации кода;

–      под разные, но совместимые модели процессоров (поскольку получается различное заполнение конвейера планировщиком инструкций);

–      для различных ABI (application binary interface – бинарный интерфейс приложений).

Поиск ошибок

С помощью описываемого метода в ходе верификации моделей двух микропроцессоров с архитектурой MIPS64 было найдено несколько десятков ошибок на стадии RTL-модели и ПЛИС-прототипа, а также 5 ошибок на стадии выпуска тестового кристалла. Предлагается следующий алгоритм действий при нахождении ошибки.

1.     Подробно описать условия возникновения ошибки.

2.     Локализовать исполняемый файл и shell-команду, запуск которой приводит к обнаружению ошибки.

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

4.     Проверить, как ведет себя тестовый случай на покомандном эмуляторе.

5.     Если это программная ошибка, исправить тест.

6.     Найти ошибку в RTL-коде и исправить, после чего убедиться в исчезновении ошибки, запустить регрессионное тестирование.

Примеры ошибок

Рассмотрим несколько примеров найденных данным методом ошибок.

1.     Тест SPEC CPU2000 252.eon: неверные данные, получаемые в результате выполнения инструкции «mfc1 r4,fp1» в следующей ситуации:

madd.D fp0,fp4,fp8,fp2

lw r8,(r9)

addiu r2,r8,r3

jr r31

mfc1 r4,fp1

в режиме 32-разрядной совместимости FPU (специфический режим микропроцессоров архитектуры MIPS, в котором для хранения 64-разрядного вещественного числа используется пара 32-раз­рядных регистров). Ошибка возникала в результате конфликта по данным для регистра fp1 между записью пары регистров fp0,fp1 от инструкции madd и чтением от инструкции mfc1. Обходной путь для этой ошибки может быть следующим: при компиляции всех программ использовать ключ компилятора «-mfix-sb1», который позволяет автоматически включить в программу дополнительную инструкцию mov.d f0,f0 следом за инструкцией madd.d fp0, … и во всех подобных случаях, когда результат вычислительной инструкции вещественной арифметики не используется непосредственно за ней. Ошибка была найдена в тестовом кристалле, что позволило исправить ее до выхода микропроцессора в серийное производство.

2.     Выполнение одного из встроенных тестов для пакета perl-5.8.8. Процессор зависает в ситуации

0x4cf0ec: lw $v0,0x0($s2)

0x4cf0f0: lw $v1,0x8024($gp)

0x4cf0f4: lwc1 f2,0x14($v0),

причем инструкция lwc1 вызывает исключительную ситуацию Coprocessor Unusable Exception (в левой колонке показаны виртуальные адреса инструкций, так как выравнивание инструкций в строке кэш-памяти имеет значение). Кроме выравнивания инструкций, должны быть соблюдены еще три условия для зависания процессора.

3.     Ошибка во время работы программы cc1, входящей в состав gcc, вызванной с определенными ключами. Ошибка в цикле, заключающаяся в том, что в случае прихода прерывания в один из тактов выполнения инструкции перехода (bnez) переход ошибочно происходит несмотря на то, что регистр v0 имеет нулевое значение:

0x72d62c: sw zero,20(v0)

0x72d630: lw v0,4(v0)

0x72d634: nop

0x72d638: bnez v0,72d62c

0x72d63c: nop.

Эта ошибка исчезала при отключении режима суперскалярности.

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

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

–      трассы выполнения кода на потактовой модели, набор инструкций;

–      сегментация памяти;

–      режим работы процессора;

–      исключительные ситуации и прерывания;

–      кэш-память;

–      сопроцессоры.

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

Пути развития методики

Большим преимуществом описываемой методики является ее расширяемость. Поскольку существует большое разнообразие свободного ПО, развитие тестового набора сводится к поиску программ. Стоит также упомянуть о возможности автоматизированной сборки полного набора инструментальных средств (toolchain) и корневой файловой системы для целевой Linux-системы с помощью набора buildroot [9]. Кроме того, большой интерес представляет объединение тестируемых микропроцессоров в вычислительные кластеры и запуск параллельных вычислений с использованием MPI (Message Passing Interface, интерфейс передачи сообщений). Для программной эмуляции и получения эталонного вывода тестов, время выполнения которых составляет несколько часов или даже суток, можно уменьшить уровень детализации эмулирования. Такую возможность поддерживает эмулятор с открытым исходным кодом QEMU, одним из достоинств которого является поддержка эмуляции многопотоковых многоядерных микропроцессоров.

В заключение необходимо отметить, что в статье рассматривается метод тестирования RTL-моделей, ПЛИС-прототипов, тестовых кристаллов и серийных СБИС микропроцессоров реальными пользовательскими приложениями под ОС Linux (тестирование на основе существующего ПО). В качестве тестов выступали пакеты тестов под ОС, сама ОС, встроенные механизмы диагностики и самотестирования пакетов ПО, реальные пользовательские приложения. Данный метод в комплексе с остальными был успешно применен для верификации разрабатываемых микропроцессоров и позволил найти несколько десятков ошибок на стадии RTL-моделирования микропроцессора с архитектурой MIPS64 и его ПЛИС-прототипа, а также 5 ошибок на стадии выпуска тестового кристалла.

Литература

1.     Pentium FDIV Bug. URL: http://en.wikipedia.org/wiki/ Pentium_FDIV_bug (дата обращения: 24.05.2012).

2.     PMC-Sierra RM7000 Family of Microprocessors Errata, Iss. 6: September 2010.

3.     Bennett J. Processor Verification using Open Source Tools and the GCC Regression Test Suite: A Case Study // Design Verification Club Meeting at Infineon, Bristol, September 2010. URL: http://www.embecosm.com/articles/ear6/dvc-or1k-verification.pdf (дата обращения: 24.05.2012).

4.     Gong L., Lu J. Verification-Purpose Operating System for Microprocessor System-Level Functions // IEEE Design & Test of Computers. 2010, pp. 76–85.

5.     Taylor S., Quinn M., Brown D., Dohm N., Hildebrandt S., Huggins J. and Ramey C. Functional Verification of a Multiple-issue, Out-of-Order, Superscalar Alpha Processor – The DEC Alpha 21264 Microprocessor // In Proceedings of DAC, 1998, pp. 638–643.

6.     Чибисов П.А., Николина Н.В. Функциональная верификация RTL-модели суперскалярных микропроцессоров. Электроника, микро- и наноэлектроника // Сборник научных трудов. М.: МИФИ, 2004. С. 213–216.

7.     URL: ftp://ftp.gnu.org/ (дата обращения: 24.05.2012).

8.     URL: http://www.debian.org/index.ru.html (дата обращения: 24.05.2012).

9.     URL: http://buildroot.uclibc.org/ (дата обращения: 24.05.2012).