CC BY
336
References
1. Bergeron J., Writing Testbenches using SystemVerilog, Springer, 2006.
2. Gribkov I.V., Zaharov A.V., Kol'cov P.P., Kotovich N.V., Kucaev A.S., Osipov A.S, Hisambeev I.S., Programmnye Produkty i Sistemy, 2007, no. 2, pp. 22-26.
3. Gribkov I.V., Zaharov A.V., Kol'cov P.P., Kotovich N.V., Kucaev A.S., Osipov A.S, Hisambeev I.S., Programmnye Produkty i Sistemy, 2010, no. 2, pp. 14-23.
4. Drechsler R., Advanced Formal Verification, Kluwer Academic Publishers, 2004.
5. Jayanta Bhadra, Magdy Abadir, Li-C. Wang, Sandip Ray, IEEE Design and Test of Computers (IEEE D&T), Vol. 24, no. 2, march-april 2007, pp. 112-122.
6. Cai L., Gajski D., Int. Conf. on HW/SW Codesign and System Synthesis (CODES-ISSS), 2003, pp. 19-24.
7. Piziali A., Functional Verification Coverage Measurement and Analysis, Kluwer Academic Publishers, 2004.
8. UVM/OVM Verification Methodology, available at: www.veri ficationacademy.com/verification-methodology (accessed 17.05.2012).
УДК 004.052.42
ТЕСТИРОВАНИЕ МИКРОПРОЦЕССОРОВ И ИХ RTL-МОДЕЛЕЙ ПРИЛОЖЕНИЯМИ ПОЛЬЗОВАТЕЛЯ ПОД ОС LINUX
П.А. Чибисов (НИИСИРАН, Москва, [email protected])
Рассматриваются методы верификации и тестирования современных микропроцессоров. Особое внимание уделяется методу тестирования RTL-моделей (модель на уровне регистровых передач), ПЛИС-прототипов и тестовых кристаллов микропроцессоров реальными пользовательскими приложениями под операционную систему Linux. Описываются взаимосвязь этих объектов и степень применимости обсуждаемой методики к каждому из них в контексте общего плана верификации. Перечисляются достоинства и недостатки метода. Так как скорость выполнения программ на RTL-модели микропроцессора крайне мала, предлагается использовать механизм среза-восстановления состояния модели микропроцессора для разбиения всей последовательности команд загрузки операционной системы на множество подпоследовательностей, которые выполняются параллельно на разных вычислительных устройствах. Наличие огромного количества свободно распространяемых программ с открытым исходным кодом, большинство из которых имеют встроенные автоматизированные механизмы самопроверки, делает возможным выделение запуска приложений под ОС Linux в отдельный подход к тестированию универсальных микропроцессоров. Применение описываемого метода не исключает, а лишь дополняет современный набор методов и средств тестирования и верификации микропроцессоров и их моделей. Многие авторитетные фирмы-разработчики микропроцессоров признают полезность как можно более ранней загрузки какой-либо операционной системы на разрабатываемой RTL-модели. Успешность этой операции зачастую дает разработчикам больше уверенности в правильности уже проделанной работы, чем десятки тысяч прошедших тестов. В статье рассматривается пример репрезентативного тестового набора, позволяющего использовать готовые пакеты программ пользователя, приводятся примеры источников тестовых программ. Кроме того, предложен общий алгоритм действий при нахождении ошибки в микропроцессоре, даются примеры найденных ошибок в микропроцессоре с архитектурой MIPS64.
Ключевые слова: тестирование микропроцессора, RTL-модель, ПЛИС-прототип, тестовый кристалл, OC Linux.
VERIFICATION OF A MICROPROCESSOR AND ITS RTL-MODEL BY MEANS OF OS LINUX USER APPLICATIONS ChibisovP.A. (SRISA RAS, Moscow, [email protected]) Abstract. This article covers the methods of verification and testing of modern microprocessors. The special attention is given to a method of testing the RTL-models, FPGA-prototypes and test crystals of microprocessors by real user applications for the Linux operating system. The interrelation of these objects and degree of a discussed technique applicability to each of them in a context of the general verification plan are considered either. The article lists the merits and demerits of the method. As simulation speed of programs on RTL-model of a microprocessor is extremely slow, it is offered to use the cut-restore mechanism of a model state for splitting all instruction sequence of an operating system booting into a set of subsequences which are carried out in parallel on different computers. Existence of a large quantity of freely distributed programs with an open source code with the built-in automated self-test mechanisms makes it possible to mark out an applications launch for Linux OS in a separate approach for testing of universal microprocessors. The described method doesn't exclude, but serves as a supplement to a modern set of methods and means of testing and verification of microprocessors and their models. Many authoritative developers and manufacturers of microprocessors recognize the usefulness of the earlier booting of any operating system on the RTL-model under development. Success in this operation often makes the developers more confident that their work is done correctly, than tens of thousands of executed tests.
The article provides the example of the representative test set which makes it possible to use the ready-made user software packages, as well as the examples of the test program sources. Besides, it considers the general algorithm of actions to find a bug in the microprocessor and gives examples of bugs revealed in the microprocessor with MIPS64 architecture. Keywords: microprocessor verification, RTL-model, FPGA-prototype, first-pass silicon, Linux, post-silicon validation.
По данным различных источников, трудозатраты на верификацию и валидацию микропроцес-
сора (МП) составляют до 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 и программ пользователя (см. таблицу).
Объект Скорость вы- Уровень Время за-
верифика- полнения кода, детализа- грузки ОС
ции инстр./с ции Linux
RTL-модель 103 Очень высокая 10-30 суток
С-модель 3*106 Очень 5-15 мин.
(эмулятор) высокая
ПЛИС- 107 Средняя 1-3 мин.
прототип
СБИС про- 108-109 Очень 10-20 с
цессора низкая
В зависимости от назначения разрабатываемого микропроцессора отладочная плата с ПЛИС либо с тестовым кристаллом может содержать контроллеры 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: неверные данные, получаемые в результате выполнения инструкции «mfcl r4,fp1» в следующей ситуации:
madd.D fp0,fp4,fp8,fp2 lw r8,(r9) addiu r2,r8,r3 jr r31
mfcl r4,fp1
в режиме 32-разрядной совместимости FPU (специфический режим микропроцессоров архитектуры MIPS, в котором для хранения 64-разрядного вещественного числа используется пара 32-разрядных регистров). Ошибка возникала в результате конфликта по данным для регистра fp1 между записью пары регистров fp0,fp1 от инструкции madd и чтением от инструкции mfcl. Обходной путь для этой ошибки может быть следующим: при компиляции всех программ использовать ключ компилятора «-mfix-sbl», который позволяет автоматически включить в программу дополнительную инструкцию mov.d f0,f0 следом за инструкцией madd.dfp0, ... и во всех подобных случаях, когда результат вычислительной инструкции вещественной арифметики не используется непосредственно за ней. Ошибка была найдена в тестовом кристалле, что позволило исправить ее до выхода микропроцессора в серийное производство.
2. Выполнение одного из встроенных тестов для пакета perl-5.8.8. Процессор зависает в ситуации
0x4cf0ec: lw $v0,0x0($s2) 0x4cf0f0: lw $v1,0x8024($gp) 0x4cf0f4: lwc1 f2,0x14($v0), причем инструкция Iwcl вызывает исключительную ситуацию 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).
References
1. Pentium FDIV Bug, available at: www.en.wikipedia.org/ wiki/Pentium_FDIV_bug (accessed 24.05.2012).
2. PMC-Sierra RM7000 Family of Microprocessors Errata, Iss. 6, September 2010, available at: www.pmcs.com/myPMC/ download.html?res_id=78161 &filename=2002295_rm7000_errata_ 078161.pdf (accessed 24.05.2012).
3. Bennett J. Design, Verification Club Meeting at Infineon, Bristol, September 2010, available at: www.embecosm.com/ar-ticles/ear6/dvc-or1k-verification.pdf (accessed 24.05.2012).
4. Gong L., Lu J., 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., DAC, 1998, pp. 638-643.
6. Chibisov P.A., Nikolina N.V., Moscow, MEPhI, 2004, pp. 213-216.
7. Set Pack GNU, available at: ftp://ftp.gnu.org/ (accessed 24.05.2012).
8. GPOSDebian, available at: www.debian.org/index.ru.html (accessed 24.05.2012).
9. Set Pack Buildroot, available at: www.buildroot.uclibc. org/ (accessed 24.05.2012).
