WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

загрузка...
   Добро пожаловать!

Pages:     | 1 || 3 |

В третьей главе рассматривается процесс разработки функциональных тестов процессоров с использованием методики, представленной во второй главе. Функциональные тесты были разработаны для двух MIPS подобных гипотетических архитектур RISC микропроцессоров. Это 16 разрядная модификация процессора DP32 и 32 разрядный процессор DLX с сокращенной системой команд. Целью разработки тестов является оценка эффективности методики и оценка возможности ее автоматизации. Возможность автоматизации означает, что для всех включенных в процесс процедур, их содержательное описание должно быть достаточно определенным и полным, чтобы избежать двусмысленности в понимании, хорошо структурированным, чтобы его можно было легко формализовать, и не содержать противоречий.

На рис. 1 представлена общая схема процесса разработки тестов механизма хранения и передачи данных.

Рис. 1. Разработка тестов механизма хранения и передачи данных

В ходе практической разработки тестов этих механизмов выявлена неполнота описания процедуры исключения функциональных узлов из графа-модели архитектуры при генерировании ГРП. Неполнота описания связана с наличием контуров в графе-модели и произвольной последовательностью исключения узлов. Полученный ГРП зависит от этой последовательности, не все регистры в нем могут оказаться соединенными путями с вершинами IN или OUT. Чтобы исключить это противоречие, в работе предложены два способа генерирования ГРП на основе графа-модели. Первый способ основан на введении порядка исключения узлов:

    • Все выходы на контуры с исключаемых узлов соединяются со входами путей от вершины IN.
    • Все входы в исключаемые узлы с контуров соединяются с произвольными выходами, кроме выходов на контуры.
    • Узлы исключаются в порядке, определяемом расстоянием от вершины IN.

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

Второй способ основан на использовании свойств RISC архитектуры. Множество регистров архитектуры таких процессоров ограничено большим числом однотипных регистров, управляемых и наблюдаемых с использованием команд класса LS. Контуры в графе-модели обусловлены обработкой данных в этих регистрах с использованием команд класса ТМ. В ходе генерирования ГРП все регистры соединяются с вершинами IN и OUT с учетом выполнения соответствующих команд класса LS.

Первый способ предполагает выполнение более сложной процедуры генерирования теста. Второй способ приводит к более длинному тесту.

Процесс разработки тестов механизмов обработки данных учитывает обособленность этой группы механизмов в системах команд класса RISC. Он предусматривает отдельный структурный синтез функций или наборов функций обработки и использование доступных средств автоматического генерирования тестов, основанных на модели ОКН. Используются так же готовые тесты логического уровня для функций, реализованных модулями сторонних разработчиков. Процедура перевода полученного теста логического уровня на уровень системы команд основана на свойствах систем команд класса RISC. Тесту каждой из функций обработки однозначно соответствует подмножество команд класса ТМ. Дополнив их командами обмена данными регистров с внешней памятью, получим тест механизма обработки данных процессора, соответствующий набору функций обработки.

Разработка тестов механизмов управления заключается в генерировании всех тестов-индикаторов для диагностируемого процессора.

В четвертой главе представлена оценка эффективности функциональных диагностических тестов, разработанных в соответствии с рассматриваемым подходом. По данным исследований (J. Abraham, L. Chen, S. Dey и др.), объем встроенного теста для несложных процессоров находится в пределах от 1 до 10 тыс. команд. Что касается качества, то оно считается приемлемым, когда тест покрывает более 90% ОКН вентильной модели процессора.

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

В связи с отсутствием доступной по условиям лицензирования и типу используемой ЭВМ программы имитационного моделирования, способной моделировать систему и одновременно ОКН ее структурных элементов, испытательный стенд основан на логически обоснованной схеме совместной работы двух программ. Это программа моделирования цифровых систем (ModelSim, QuartusII) и программа моделирования ОКН структурных моделей цифровых устройств Modus. Используемый в экспериментах принцип взаимодействия программ состоит (см. рис. 2):

    • в фиксации последовательности битовых слов S(t) на контролируемых системой диагностики входах и выходах процессора в ходе моделирования системы;
    • в последующем использовании этой последовательности как входной для моделирования ОКН вентильной модели процессора.

Для моделирования ОКН программой Modus необходима трансляция вентильной модели процессора с языка Verilog на язык Modus. Корректность трансляции модели доказывается выполнением двух процедур. Первая состоит в подаче на входы обеих моделей одной и той же тестовой последовательности и сравнении последовательностей на выходах моделей. Вторая – в определении качества теста. При совпадении выходных последовательностей и качестве теста более 90% покрытия ОКН полагаем, что модели эквивалентны.

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

Общая схема испытательного стенда представлена на рис. 3.

Рис. 3. Схема испытательного стенда

Объем функциональных тестов процессоров, разработанных по представленной в главах 2, 3 методике, DP32 – 1116 команд, DLX – 1269 команд. Качество теста для модели последовательного процессора DP32 достаточно высоко и составляет 96,6% покрытия ОКН его вентильной модели. Качество теста для модели конвейеризованного процессора DLX значительно ниже и составляет 71,87% покрытия ОКН. Предполагаем, что снижение качества теста обусловлено наличием в конвейеризованном процессоре аппаратуры, ответственной за параллельную обработку команд.

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

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

  • существование регистров для временного хранения данных частично выполненных команд и передач данных между этими регистрами;
  • существование передач данных между регистрами, управляемых зависимостями по данным и по именам;
  • существование остановов выполнения команд для разрешения конфликтов.

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

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

В качестве модели механизма хранения и передачи данных конвейеризованного RISC процессора для программ без конфликтов принят ГРП уровня архитектуры системы команд. В граф добавлена информация, позволяющая сгенерировать тест без конфликтов по данным и полученная из спецификации архитектуры (см. рис. 4).

Рис. 4. Часть ГРП механизма, управляемого полями команд

Входы и выходы узлов ГРП помечены номерами тактов (ступеней конвейера), в которые выполняется запись или чтение соответствующих регистров при выполнении команд. На рис. 4 узлам R0, R1 соответствуют регистры общего назначения, узлу PC – регистр счетчика команд, вершинам IN, OUT –внешние порты, Add, Sub, Ld, St, B, Bi – команды процессора.

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

В построенном ГРП множество R регистров, обращение к которым может привести к конфликтам по данным, включает все регистры Ri с номерами тактов записи m и чтения n, для которых nm. Конфликт по данным возникает, когда число k других команд, находящихся в программе между командами, зависимыми по данным, удовлетворяет неравенству: 0k<(m-n). Конфликт устраняется добавлением команд простоя между зависимыми командами. Число команд простоя Idata, которое следует добавить: Idata = m – n – k. Таким образом, тест механизма хранения и передачи данных конвейеризованного процессора для программ без конфликтов получается устранением конфликтов в тесте соответствующего механизма последовательного процессора на основании данных об архитектуре конвейера.

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

В качестве модели механизма хранения и передачи данных, управляемого зависимостями по данным, принят граф-модель (ГМ) архитектуры конвейера (см. рис. 5).

Рис. 5. Упрощенный граф-модель архитектуры конвейера RISC процессора

Он получается из ГМ архитектуры системы команд процессора объединением находящихся на одной ступени конвейера групп узлов в общие функциональные узлы. Условием объединения является обращение группы узлов к регистру конвейера в одном такте. Модель включает конвейерные регистры и два типа функциональных узлов – узлы хранения данных и узлы обработки данных. На рис. 5 узел RegFile соответствует узлу хранения данных, ALU – узлу обработки данных, узлы RS1, RS2, RD1 – RD4 – конвейерным регистрам, IN и OUT – внешним портам, Add, Sub, Ld, St – команды. Входы и выходы узлов хранения данных помечены номерами ступеней конвейера, в которые происходит запись или чтение данных.

Диагностирование механизма заключается в активизации последовательностями команд (с тестовыми операндами и адресами) всех путей передачи данных между узлами графа-модели в случае конфликта (обозначены на рис. 5 пунктиром). Идея создания конфликта состоит в построении последовательности команд, где первая записывает тестовые данные в узел хранения, а следующие за ней их читают для выполнения операции или вывода на внешние порты. Между командами записи и чтения данных в тестовую процедуру вставляется последовательность команд простоя. Наибольшее число Ihaz команд простоя при проверке конфликтов типа RAW (Read After Write) для узла хранения: Ihaz = m – n – 1, где m и n – номера такта записи и чтения этого узла, соответственно. В тест включаются все последовательности команд с числом команд простоя от нуля до Ihaz.

Разработанные по этой методике функциональные модели интегрированы в общую методику диагностирования RISC процессоров, качество тестов проверено экспериментально. Объем нового теста конвейеризованного процессора DLX – 2871 команда. Качество теста достигает 95,5% покрытия ОКН его вентильной модели.

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

Основные результаты и выводы диссертации:

  1. Предложена методика функциональной декомпозиции процессоров с параллелизмом уровня системы команд для их тестового диагностирования.
  2. Разработаны функциональные модели и процедуры тестового диагностирования механизмов хранения и передачи данных конвейеризованных RISC процессоров.
  3. Разработан общий процесс генерирования диагностических тестов.
  4. Разработана и обоснована схема испытательного стенда для определения качества функциональных диагностических тестов.
  5. С использованием экспериментального прототипа этого стенда оценена эффективность подхода к тестовому диагностированию.
  6. Представленная методика функционального тестового диагностирования позволяет разработать на ее основе автоматизированный процесс построения тестов, использующий спецификацию архитектуры системы команд как основные исходные данные.
  7. По результатам выполнения этих тестов можно с высокой степенью достоверности судить о техническом состоянии процессора.

ОСНОВНЫЕ ПУБЛИКАЦИИ ПО ТЕМЕ ДИССЕРТАЦИИ

Pages:     | 1 || 3 |






© 2011 www.dissers.ru - «Бесплатная электронная библиотека»