Содержание к диссертации
Введение
1 Функциональное тестирование микропроцессора 8
1.1 Основные направления развития функционального тестирования 8
1.1.1 Модульный подход 8
1.1.2 Микрооперационный подход 9
1.1.3 Модель регистровых передач 10
1.1.4 Функциональная декомпозиция
1.2 Функциональное тестирование RISC-микропроцессоров 13
1.3 Проблемы проверки управляющего оборудования 19
1.4 Задачи, решаемые в последующих разделах 24
2 Архитектура SPARC V9 25
2.1 Структура микропроцессора 25
2.1.1 Устройство предварительной выборки и диспетчеризации команд 27
2.1.2 Кэш-память команд 27
2.1.3 Организация конвейера 28
2.1.4 Целочисленное исполнительное устройство 29
2.1.5 Устройство загрузки/записи 29
2.1.6 Устройство работы с вещественными числами 30
2.1.7 Графическое устройство 31
2.1.8 Устройство управления памятью 31
2.1.9 Управление интерфейсом памяти
2.1.10 Кэш-память данных 33
2.1.11 Управление внешней кэш-памятью 33
2.2 Форматы данных з
2.3 Организация регистровых файлов 34
2.3.1 Целочисленные регистры общего назначения 35
2.3.2 Регистры вещественных данных 36
2.3.3 Регистры управления и состояния
2.4 Форматы команд и способы адресации 38
2.5 Архитектурная модель микропроцессора 38
3 Диагностические модели микропроцессора 42
3.1 Граф -модель 42
3.2 Проверка механизмов обработки данных 48
3.3 Механизмы хранения данных 52
3.4 Механизмы передачи данных
4 Проверка работоспособности управляющего оборудования RISC-микропроцессора 58
5 Практические результаты
5.1 Определение требований к программному комплексу 68
5.2 Архитектура программы самотестирования 70
5.2.1 Выбор языка программирования для интерфейсной программы .71
5.3 Автоматизированное построение проверяющих процедур 73
Заключение 77
Список литературы 79
- Микрооперационный подход
- Целочисленное исполнительное устройство
- Организация регистровых файлов
- Архитектура программы самотестирования
Микрооперационный подход
Остановимся на особенностях некоторых из перечисленных архитектур.
Особенностью архитектуры РА-RISC является внекристальная реализация кэша, что позволяет реализовать различные объемы кэш-памяти и оптимизировать конструкцию в зависимости от условий применения. Хранение команд и данных осуществляется в раздельных кэшах, причем процессор соединяется с ними с помощью высокоскоростных 64-разрядных шин. Кэш-память реализуется на высокоскоростных кристаллах статической памяти (SRAM), синхронизация которых осуществляется непосредственно на тактовой частоте процессора. Микропроцессор аппаратно поддерживает различный объем кэш-памяти: кэш команд может иметь объем от 4 Кбайт до 1 Мбайт, кэш данных - от 4 Кбайт до 2 Мбайт. Чтобы снизить коэффициент промахов применяется механизм хеширования адреса. В обоих кэшах для повышения надежности применяются дополнительные контрольные разряды, причем ошибки кэша команд корректируются аппаратными средствами. Конвейер целочисленного устройства включает шесть ступеней: 1) чтение из кэша команд (IR); 2) чтение операндов (OR); 3) выполнение/Чтение из кэша данных (DR); 4) завершение чтения кэша данных (DRC); 5) запись в регистры (RW); 6) запись в кэш данных (DW). Процессор может в каждом такте выдавать на выполнение одну целочисленную команду и одну команду с плавающей точкой.
Архитектура MIPS была одной из первых RISC-архитектур, получившей признание со стороны промышленности. Она была анонсирована в 1986 году. Первоначально это была полностью 32-битная архитектура, которая включала 32 регистра общего назначения шириной в 32 бита, 16 регистров вещественных чисел и специальную пару регистров для хранения результатов выполнения операций целочисленного умножения и деления. Размер команд составлял 32 бита, в ней поддерживался всего один метод адресации, а адресное пространство также определялось 32 битами. Выполнение арифметических операций определялось стандартом IEEE 754.
Архитектура POWER во многих отношениях представляет собой традиционную RISC-архитектуру. Она придерживается наиболее важных отличительных особенностей RISC: фиксированная длина команд; архитектура регистр-регистр; простые способы адресации; простые (не требующие интерпретации) команды; большой регистровый файл; трехоперандный (неразрушительный) формат команд. Однако архитектура POWER имеет также несколько дополнительных свойств, которые отличают ее от других RISC-архитектур: набор команд был основан на идее суперскалярной обработки. В базовой архитектуре команды распределяются по трем независимым исполнительным устройствам: устройству переходов, устройству с фиксированной точкой и устройству с плавающей точкой; архитектура POWER расширена несколькими "смешанными" командами для сокращения времени выполнения. Возможно единственным недостатком технологии RISC по сравнению с CISC, является то, что иногда она использует большее количество команд для выполнения одного и того же задания. Было обнаружено, что во многих случаях увеличения размера кода можно избежать путем небольшого расширения набора команд, которое вовсе не означает возврат к сложным командам, подобным командам CISC; отсутствие механизма "задержанных переходов".
Методика реализации условных переходов основанная на расширении свойств регистра условий. Это проявляется в наличии специального бита в коде операции каждой команды, что делает модификацию регистра условий дополнительной возможностью, и тем самым восстанавливает способность компилятора реорганизовать код, и в наличии восьми регистров условий для того, чтобы обойти проблему единственного ресурса и обеспечить большее число имен регистра условий так, что компилятор может разместить и распределить ресурсы регистра условий, как он это делает для универсальных регистров.
Масштабируемая процессорная архитектура компании Sun Microsystems (SPARC - Scalable Processor Architecture) является наиболее широко распространенной RISC-архитектурой, отражающей доминирующее положение компании на рынке UNIX-рабочих станций и серверов.
Первоначально архитектура SPARC была разработана с целью упрощения реализации 32-битного процессора. В последствии, по мере улучшения технологии изготовления интегральных схем, она постепенно развивалось и в настоящее время имеется 64-битная версия этой архитектуры.
В отличие от большинства RISC архитектур SPARC использует регистровые окна, которые обеспечивают удобный механизм передачи параметров между программами и возврата результатов. Архитектура SPARC была первой коммерческой разработкой, реализующей механизмы отложенных переходов и аннулирования команд. Это давало компилятору большую свободу заполнения времени выполнения команд перехода командой, которая выполняется в случае выполнения условий перехода и игнорируется в случае, если условие перехода не выполняется.
Приведенный выше анализ необходим для определения основных тенденций в развитии современных RISC-архитектур и выбора объекта исследования, сочетающего в себе основные из них. Использование таких критериев при выборе объекта позволяет распространить исследования, проведенные в работе, на целый класс подобных устройств.
Кроме того, подобный анализ позволил выделить основные черты RISC-архитектуры, существенно влияющие на создание процедур функционального тестирования микропроцессора: единая разрядность команд; ограниченный набор команд простых и регулярных форматов; малое число (2-3) способов адресации; регистровая обработка данных; в большинстве случаев команда выполняется за один такт. Исключение составляют команды с плавающей точкой и графические команды; ограниченное число команд (типа LOAD и STORE) обращения к памяти.
Целочисленное исполнительное устройство
Рассмотрим кратко назначение модулей блок-схемы и отдельных связей между ними. На схеме сплошными линиями обозначены пути передачи данных и команд, пунктирными - управляющей и оповещающей информации, штриховыми - адресной информации.
В группе модулей ПОДДЕРЖКА отражены устройство управления памятью (MMU), устройство загрузки/записи (LSU) и система кэширования, включающая в себя раздельные кэш команд (I-Cache) и кэш данных (D-Cache).
Группа модулей УПРАВЛЕНИЕ отражает конвейерное управление МП. Принципиальной особенностью является четкое отделение в аппаратуре конвейера функций управления. Буферы и соответствующие информационные связи вынесены в блок BUF; это касается и связей по данным через шинные формирователи конвейеров. При этом информационные связи рассматриваются в широком смысле, т.е. для обрабатываемых данных, а также для команд, адресов и данных о состоянии МП, формирование которых программно доступно. Тогда отраженный на схеме конвейер представляет собой автомат, состояния которого определяют множества параллельно активизируемых функций, соответствующих отдельным фазам обработки команд; сама обработка данных и адресов реализуется функциональными модулями.
Группа модулей ОБРАБОТКА разделена на группу функциональных модулей и локальную память. Функциональные модули включают модуль обработки целочисленных данных IEU, имеющий в своем составе 2 АЛУ, умножитель, делитель и сдвигатель; модуль для работы с вещественными данными FPU, в состав которого входит блок для работы с графикой GRU, а также модуль обработки адресной информации для команд и данных.
В локальной памяти выделены четыре блока. Блок регистров общего назначения GPR (General Purpose Registers) содержит регистровый файл для целочисленных данных. Блок FP регистров (FPR) включает в себя регистровый файл для работы с вещественными данными и регистр состояния работы с вещественными данными (FSR). Блок SR (status registers) включает регистры управления/состояния, в которые помимо прочих, включены: регистр состояния для работы с целочисленными данными (CCR), регистр состояния регистрового файла вещественных данных (FPRS) и указатель текущего окна регистрового файла (CWP). К этой группе регистров относятся также счетчик команд (PC) и счетчик следующей команды (пРС).
Блок BUF включает, в основном, буферные регистры (и шинные формирователи), выделенные из состава конвейерного оборудования.
Функции буферов связаны с функциями конвейерного управления:
На первых двух ступенях конвейера, 12 команд выбираются из кэш, декодируются и помещаются в буфер выборки (PR-Prefetcher).
Выбранные команды группируются и распределяются по исполняющим устройствам с целью максимальной загрузки конвейера и избежания остановок конвейера в результате возникновения конфликтов. Для разрешения конфликтов по данным используется буферы зависимости по данным (DDB-Data Dependency Buffers), которые включают шинные формирователи результата, обеспечивающие обход, буферы продвижения данных, таблицу регистров переименования. Конфликты по управлению разрешаются с помощью буферов процедурной зависимости (PDB-Procedural Dependency Buffers), содержащих стэк возвратов (return stack), в котором отслеживаются переходы в парах команд CALL/RETURN.
На следующем этапе конвейера, в соответствии с командой, происходит обработка данных.
После этого на стадии кэш, результаты исполнения команды помещаются в DDB и могут быть использованы следующей командой. На последнем этапе происходит запись результатов обработки в регистры или в память. В заключение следует отметить, что рассмотренная архитектурная модель необходима для построения более формализованной диагностической модели МП. 3 Диагностические модели микропроцессора Глава посвящена построению диагностической модели МП, выделению его основных механизмов, а также построению соответстующих процедур тестирования.
Организация регистровых файлов
На представленной схеме отражен регистровый файл, включающий множество регистров 91, управляемое многофункциональное ALU, реализующее множество функций Ф, мультиплексор MX и демультиплексор DMX, осуществляющий выбор регистров-приемников и регистров-источников.
Учитывая структурную и функциональную независимость различных исполнительных устройств, а также тот факт, что каждая команда в RISC микропроцессоре однозначно позволяет определить устройство, которое будет использоваться для ее выполнения, можно распространить подобное представление на всю обрабатывающую часть микропроцессора.
Регистры множества Э1 являются по определению [60] эквивалентными, т.е. характеризуются одним и тем же способом доступа к ним. Команды RISC-микропроцессора можно классифицировать следующим образом: класс ТМ (команды классов Т (Transition - передача) и М (Manipulation - обработка) с операндами, размещенными в эквивалентных регистрах); класс LS (команды обращения к памяти типа LOAD); класс В (команды ветвления Branch). Как уже было отмечено, в [45] обоснованы модели неисправностей Р I Р и К I ZR, отсутствие которых гарантирует работоспособность управляющего оборудования, ответственного за надлежащий выбор регистров и операций микропроцессора. На основе предложенной обобщенной модели обрабатывающей структуры RISC микропроцессора и представленных моделях неисправностей в работе были сформулированы следующие предположения. Гипотеза 1. Любой дефект оборудования управления, существенный для выполнения команд класса ТМ (transfer / manipulation), обнаруживается тестом, направленным на обнаружение неисправностей типов г/У/ ф и/или RV R. Rem Гипотеза 2. Любой дефект оборудования управления, существенный для выполнения команд класса LS (load / store), обнаруживается тестом, направленным на обнаружение функциональных неисправностей запоминающих устройств, например маршевым тестом памяти с использованием соответствующих команд LOAD и STORE.
Основными предпосылками для подтверждения подобных гипотез, могут служить следующие свойства RISC-архитектуры:
1)для RISC-архитектуры характерны высокая степень управляемости в том смысле, что выполняемые операции и адреса операндов (номера регистров) задаются раздельными полями команды микропроцессора;
2) независимо от любой сложности аппаратуры управления (суперконвейерность, суперскалярность, неупорядоченность выполнения команд и т.п.), результат выполнения команды всегда наблюдается на некотором этапе обработки;
3) дефекты оборудования управления имманентно имеют «интегральный» характер, т.е. проявляются на некоторых множествах команд и операндов. Маловероятным является наличие дефекта в управляющем оборудовании, который бы проявлялся только на одной команде с конкретными значениями операндов. Кроме того, справедливость гипотезы 1 подтверждается чрезвычайной общностью моделей неисправностей ф/ ф и R / , которые по сути соответствуют произвольным отображениям множеств 91 и Ф во множество всех подмножеств 2 и 2 (в первом случае, как при записи, так и при считывании регистров), что формально выражается в виде ЧЛ— 294 и Ф— 2Ф. Справедливость гипотезы 2 подтверждается свойствами полного маршевого теста, обнаруживающего все общепринятые функциональные неисправности памяти, включая неисправности множественного доступа с / при записи и чтении. Преимуществом подхода, основанного на гипотезах 1 и 2, является тот факт, что проверка оборудования управления осуществляется опосредованно, не затрагивая деталей реализации аппаратуры. Вышеперечисленные модели неисправностей позволяют сформулировать основные требования к построению тестовых наборов для обнаружения такого рода неисправностей. В диссертационной работе подобные тестовые наборы были обозначены как тест-индикатор для обнаружения неисправности декодировния j-операций ТЮ (j) и тест-индикатор регистра для обнаружения неисправности выборки регистров TIR. На основе требований, предложенных в [42], была разработана следующая процедура для построения ТЮ:
Процедура 4.1. 1. Составим матрицу М(Е, J) где Е - множество операндов, a J -множество всех операций. Строки матрицы соответствуют наборам ек из множества Е = {еь е2,..., ек}, а столбцы - операциям из множества J = {1ь 12, ..., Ij}. В каждую ячейку поместим результат выполнения операции Ij из множества J на данном наборе операндов.
Архитектура программы самотестирования
Рассмотренная выше архитектура программы позволяет адоптировать ее под другой МП с подобной архитектурой путем замены функционального ядра. В связи с этим актуальной становится задача автоматизированного построения функций ядра. Для решения этой задачи был разработан и реализован следующий алгоритм (рисунок 5.4).
На вход программного комплекса подается некоторое формальное описание архитектуры МП, которое переводится во внутреннее представление. Подобное решение позволяет использовать на входе практически любое описание архитектуры за счет изменения или добавления преобразователя описания в удобный вид. В данном случае под описанием архитектуры мы понимаем данные, существенные для построения функциональных тестов в рамках рассматриваемого нами функционального подхода.
Такие данные, как это было показано в предыдущих главах, должны содержать сведения о командах и методах адресации, а также сведения о регистрах и путях передачи данных (ГРП). Используя эти данные и приведенные выше простые процедуры, легко построить тестовые последовательности для проверки механизмов МП (тест-индикаторы).
Для создания компилируемого файла на основе полученной тестовой последовательности предлагается использование широкораспространенной технологии XSLT (extensible stylesheet language transformation). Данная технология предполагает отображение некоторых данных представленных в виде XML (extensible markup language) [7, 8, 51] с помощью языка стилей XSL (extensible stylesheet language). Использование этой технологии для хранения и представления данных позволит абстрагироваться при создании тест-индикаторов от синтаксиса команд конкретного МП и вынести этот синтаксис в xsl описание, которое легко модифицируется, что, в свою очередь, повышает универсальность и переносимость такой системы.
Представленная архитектура программного комплекса для автоматизированного построения тестовых процедур была апробирована в программе для генерации тест-индикаторов проверки управляющего оборудования. В приложении приведен список команд исследуемого МП и программный код синтезирующей программы на языке Java, реализующего генерацию ТЮ. Кроме того, в приложении приведено xml описание тестовой последовательности для части команд МП и пример xsl описания для генерации ассемблерного кода, а также полученный программный код.
Рассмотрим подробнее программную реализацию предложенного алгоритма на примере программ построения ТЮ. Использование в качестве языка программирования, языка Java, позволило применить при создании подобной программы объектно-ориентированный подход [30]. Применение такого подхода обеспечивает гибкость при создании программы и позволяет достаточно легко ее модернизировать под новые требования. Это достигается за счет введения понятия объекта как некой логической единицы, которая содержит данные и правила их обработки. Исходя из этого, ключевым объектом для построения ТЮ выступает некоторая команда, которая в рамках функционального подхода представляется некоторой функцией, преобразующей входные данные. Подобный объект представлен в виде класса TstFunction. Как уже было сказано, данный класс содержит всю информацию о реализуемой функции. Для представления функции в классе используется метод обратной польской записи [15, 16, 27, 29]. Подобный метод распространен при построении различного рода программных трансляторов и является, в некотором роде, стандартом, что позволяет легко добавлять конверторы из различных синтаксических описаний в необходимый вид. В соответствии с данным методом, конструктор объекта задается массивом (стеком) элементарных логических и арифметических операций, которые описывают последовательность вычисления функции. Основными методами объекта "команда" являются методы getResult -вычисление функции над операндами и методы getTIO и toString, служащие для представления тестовых операндов в виде xml и реализуемой функции в виде таблицы истинности соответственно.
