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

Метод формальной спецификации аппаратуры с конвейерной организацией и его приложение к задачам функционального тестирования

А. С. Камкин kamkin@ispras.ru

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

1. Введение

Современные электронные устройства является очень сложными системами, производство которых можно начинать только после тщательного проектирования. Проектирование электроники осуществляется с помощью специализированных языков описания аппаратуры (HDLs, Hardware Description Languages), например, Verilog или VHDL [1], позволяющих абстрагироваться от деталей расположения и соединения отдельных элементов электронной схемы. Проект устройства на таком языке является исполнимой программой, у которой имеются параметры, соответствующие входам устройства, и называется моделью1. После окончания проектирования

1 Такие модели также называют HDL-моделями или RTL-моделями, поскольку проектирование ведется на уровне регистровых передач (RTL, Register Transfer Level).

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

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

Для проверки корректности моделей аппаратуры используют различные методы функциональной верификации [3,4]. Наиболее широко используемым на практике методом верификации является имитационное тестирование {simulation-based verification)2. Этот метод состоит в программной имитации работы устройства, описываемого моделью, с помощью симулятора, в рамках ряда специально разработанных тестовых сценариев, которые представляют собой основные варианты использования функций этого устройства, возможные при его эксплуатации. Главной задачей тестирования является проверка соответствия поведения системы предъявляемым к ней требованиям. Для возможности автоматизации такой проверки требования к системе должны быть представлены в машиночитаемой форме, которую называют формальными спецификациями.

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

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

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

108

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

2. Аппаратура с конвейерной организацией

Модели аппаратуры на HDL-языках представляют собой системы из нескольких взаимодействующих модулей. Как и в традиционных языках программирования, модули используются для декомпозиции сложной системы на множество независимых или слабо связанных подсистем. Каждый модуль имеет интерфейс - набор входов и выходов, через которые осуществляется соединение модуля с окружением, и реализацию, определяющую способ обработки модулем входных сигналов: вычисление значений выходных сигналов и изменение внутреннего состояния. Для удобства будем считать, что спецификация и тестирование осуществляются на уровне отдельных модулей.

Как правило, модули цифровой аппаратуры работают синхронно под управлением тактового сигнала. Фронты тактового сигнала разбивают непрерывное время на дискретный набор интервалов, называемых тактами. Что делать модулю на текущем такте, определяется значениями входных сигналов и внутренним состоянием модуля. Часть входов модуля определяет операцию, которую модулю следует выполнить, - такие входы называются управляющими', другая часть определяет аргументы операции, - такие входы называются информационными. Среди реализуемых модулем операций обычно присутствует «пустая» операция ХОР (No Operation), означающая бездействие, отсутствие операции. Состояние модуля также можно разбить на две составляющие: состояние управления и состояние данных. Первая из них является частью управляющей логики модуля и используется для управления процессами выполнения операций. Состояние данных, как видно из названия, представляет собой внутренние данные модуля.

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

Тягоеый mw пуль с

Сигнал подами

ппзряики

Результат

0Щ>рЗЦИМ

г—

: t

■ ; 1 ! i

\ s !

1 I 111"'L i ‘ i

| ^ 1 I О

Hatiano выполнения Результат выполнен и л

лпяртшии

Рис. 1. Временная диаграмма сигналов для однотактной операции.

В отличие от однотактной операции, результат многотактной операции вычисляется постепенно такт за тактом. Пусть операция А выполняется модулем за L тактов. Тогда на каждом такте i е {1,.... 1,\ модуль выполняет некоторую микрооперацию . Iа окружение после окончания каждого такта получает некоторый частичный результат. Представление многотактной

операции^ в виде последовательности микроопераций (Aj,.......I,-) называется

декомпозицией операции А на стадии3.

В этой статье акцент делается на конвейерные модули, то есть модули, в которых операции подаются на выполнение последовательно одна за другой, но процессы их выполнения могут пересекаться по времени (см. рис. 2). Такие модули широко распространены, особенно в практике проектирования микропроцессоров. Можно выделить два типа конвейеров: конвейеры без блокировок (pipelines without interlocked stages) и конвейеры с блокировками (pipelines with interlocked stages). В конвейерах первого типа выполнение последовательных стадий, относящихся к одной операции, осуществляется на последовательных тактах: если стадия Д- была выполнена на такте_/, то стадия Ai+i будет выполнена на такте /+1. В конвейерах второго типа это свойство, вообще говоря, не выполнено - между тактами, на которых выполняются последовательные стадии, могут быть задержки: если стадия А,- была выполнена на такте _/, то стадия А,-+j будет выполнена на такте /+1+6. где 5 > О

- величина задержки между стадиями, которая определяется на основе состояния управления модуля.

3 В данной статье термины «стадия» и «микрооперация» являются синонимами.

110

Операция А

Операция В

Ai

В1

В2

Вп

{А2, Б,}

-------------------•------------------------------------------*

текущий такт время

Рис. 2. Выполнение двух операций на конвейере.

Блокировки в конвейере предназначены для того, чтобы избежать конфликтов использования ресурсов между операциями и сохранить целостность потока данных. Например, в приведенной ниже ассемблерной программе инструкция add складывает содержимое регистра г2 с содержимым регистра гЗ и сохраняет результат в регистре rl. Следом за ней идет инструкция sub, которая использует значение регистра г 1. В этом случае доступ к регистру г 1 из инструкции sub блокируется до тех пор, пока инструкция add не запишет в него результат - в противном случае инструкция s ub считает некорректное значение.

add rl, г2, гЗ // запись в регистр rl

sub r4, r^L, г5 // чтение из регистра rl

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

3. Формальная спецификация конвейера

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

3.1. Вспомогательные понятия

Введем основные понятия теории автоматов, на которых базируется контрактная спецификация конвейера.

Определение. Автоматом называется четверка {Б, X., 7, Г), в которой:

• £ - множество состояний;

• X— множество стимулов;

• 7 - множество реакций;

• Гс^хХхГх^-отношение переходов.

Каждый переход I е Т имеет вид (л,. х,. у,, где:

• з* £ З1- пресостояние;

• хг £ X- стимул;

• у( £ 7- реакция;

• я* £ 51- постсостояние. ■

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

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

Определение. Пусть V - некоторое множество переменных. Функцией означивания переменных из V называется отображение V, которое каждой переменной х е V ставит в соответствие ее значение у(х) е Оотх. ■

Множество всех функций означивания переменных из V будем обозначать символом Боту и называть множеством значений переменных из V. Определение. Расширенным автоматом называется шестерка (£, V, I и О, X, 7, 7), в которой:

• £ - множество состояний;

• V - множество контекстных переменных;

Функция означивания контекстных переменных называется контекстом расширенного автомата.

• /иОс V— множество входных и выходных параметров;

Заметим, что в данном определении множество входных и выходных параметров является подмножеством множества контекстных переменных.

• X-множество стимулов;

С каждым стимулом х е X связано множество входных параметров

1пх с I.

Множество значений входных параметров стимула х будем обозначать Domx.

• Y - множество реакций;

• Т - отношение переходов.

С каждым переходом t е Т связаны два подмножества множества контекстных переменных:

о Usetс V\0 - множество используемых контекстных

переменных;

о Def с V \ I - множество определяемых контекстных переменных. Каждый переход t е Тимеет вид (.v,. х,. у,, у,. 8t, л'(). где: о st е S - пресостояние;

о Xf е X— стимул;

о yt е Y - реакция;

о yt: Domx х DomUse —> {true, false} - охранный предикат;

о St: Domx х DomUse —> DomDef- функция обновления контекста;

о s’t е S — постсостояние. ■

Определение. Конфигурацией расширенного автомата называется пара (s, v) е S х Domv, состоящая из состояния и контекста. ■

В дальнейшем будем рассматривать расширенные автоматы с выделенной начальной конфигурацией (s0, v0). Такие автоматы называются инициальными и описываются семерками (S, V, (s0, v0), / и 0,Х, Y, Т). Будем использовать следующие обозначения:

Tran(s) = {/ е Т | st = 5}

Init(s) = {xt\t е Tran(s)}

Определение. Предусловием стимула х в состоянии s называется предикат pres x:DomxxDomv^>- {true, false}, определяемый равенством

pres, x(p, v) = vy e Соиф, X) у, где Cond{s, x) = {yt \st = s,xt = x}. Если Cond{s, x) = 0, pres x полагается равным false. ■

Определение. Пара x\p\. состоящая из стимула х и набора значений его входных параметровр, называется инициализированным стимулом. ■

Множество всех инициализированных стимулов будем обозначать символом Рагат(Х). Аналогичное определение и связанные с ними обозначения имеют место и для переходов расширенного автомата.

Определение. Пара t\p\, состоящая из перехода t и набора значений входных параметров р соответствующего стимула х, называется инициализированным переходом. ■

Определение. Инициализированный переход t\p\ называется допустимым в конфигурации (s, v), если st = s, xt e Init(s) и yip, v) = true. ■

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

3.2. Спецификация конвейера без блокировок

Для наглядности сначала определим контрактную спецификацию для случая конвейера без блокировок.

Определение. Контрактной спецификацией конвейера без блокировок длины L называется шестерка (V, v(J. / и О. X и {т}, Z и {е}, р), в которой:

• V - множество контекстных переменных;

• v0 £ Domv - начальный контекст;

• /иОс V — множество входных и выходных параметров;

• Xu {т} - множество стимулов;

С каждым стимулом хеХи{т} связано множество входных параметров 1пх с I.

Множество значений входных параметров стимула х будем обозначать Domx.

Множество PL = (Xu {т |)' называется множеством состояний управления, а его элемент 7г0 = (х,..., х) - начальным состоянием управления.

Для каждого стимула х также заданы:

• 1х- Рь —>■ {true, false} - охранный предикат стимула;

• prex: Domx x Domv —>■ {true, false} - предусловие стимула.

Множество стимулов включает выделенный стимул х, называемый тактовым стимулом, для которого выполнены следующие свойства:

• Inz = 0;

• ух = true;

• preT= true.

• Zu{ е} - множество стадий;

Для каждой стадии z заданы:

• Usez с V\0 - множество используемых контекстных

переменных;

• Def cV\I - множество определяемых контекстных переменных;

• postz: DomUse х DomDef^>- {true, false} - постусловие стадии.

Множество стадий включает выделенную стадию е, называемую пустой стадией, для которой выполнены следующие свойства:

• Usee = 0;

• Def = 0;

• poste = true.

• p: Xu {x} -^(Zu !s:|)' - функция композиции операций.

Последовательность стадий р(х) называется операцией стимула х. Функция р обладает следующим свойством: р(х) = (•<:...., е)4. ■

Для интерпретации контрактной спецификации конвейера будем использовать

оператор сдвига конвейера и оператор связывания стадий конвейера.

Определение. Функция °: (Xи {х}) х Р,- —> Рь, определяемая равенством

х0° (хь ...,хь) = (х0, ..., ХЬЛ), называется оператором сдвига конвейера. ■

Определение. Функция 9: PL —>■ 2Z, определяемая равенством

0(Л) = (Pl(7tl), ..., Рь(Пь)} \ {б}, называется оператором связывания стадий конвейера. ■

Смысл этих операторов достаточно прост: оператор сдвига конвейера добавляет в начало конвейера новый стимул, сдвигая при этом

4 Стимул х и соответствующая ему последовательность пустых стадий (е,..., е) формализуют операцию ЫОР.

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

Определение. Множество стадий называется конфликтным, если для некоторых стадий у Ф z из этого множества выполнено хотя бы одно из следующих условий:

• Usey п, Def ф 0 - конфликт типа «чтение-запись»;

• Defy п, Def Ф Qj - конфликт типа «запись-запись».

Если ни для каких стадий у Фг ни одно из перечисленных условий не выполнено, множество стадий называется согласованным. ■

Определение. Состояние управления л называется согласованным, если для

всех 1 < / Ф j < таких ЧТО р,(7Т,) Ф 6 И р;(7Г;) Ф 6, выполняется Р;(7Г;) Ф Р/(Л/) И

множество стадий в(п) является согласованным. ■

Определение. Контрактная спецификация конвейера называется согласованной, если для всех стимулов х и состояний управления л из того, что л согласованно и ух(л) = true, вытекает, что х ° л согласованно. ■

В дальнейшем будем рассматривать только согласованные контрактные спецификации конвейера. Пусть Е = (V, v(J. / и О. X и {т}, Z и {е}, р) -контрактная спецификация конвейера без блокировок длины L. Ее можно интерпретировать как инициальный расширенный автомат Д = (S, V, (п0, v0), / и 0,1и {т}, Y и {^}, Т) с выделенными тактовым стимулом х и пустой реакцией устроенный следующим образом:

• «S' = Pl - состояниями расширенного автомата Д являются состояния управления контрактной спецификации Е;

• 7г0 = (х,..., х) - начальным состоянием является начальное состояние управления;

• Y = 2Z - реакциями расширенного автомата Д являются множества стадий контрактной спецификации Е;

• | = 0- пустой реакцией является пустое множество стадий;

• отношение переходов Т расширенного автомата Д для всех % е S и х е Xu {х} таких, что ух(п) = true, содержит все возможные переходы t = (п, х, у, у, 5, л'), в которых:

• Usef uz е (и | l se~

множество используемых контекстных переменных получается объединением соответствующих множеств для стадий из 0(71');

• ~ е 0(я')^^/г

множество определяемых контекстных переменных получается объединением соответствующих множеств для стадий ИЗ 0(7Г');

• 7г' = X ° 71

постсостояние получается сдвигом конвейера;

• .у = 0(0

реакция определяется как результат связывания стадий, выполненного в постсостоянии перехода;

• У (p,v)=prex(p,v)

охранный предикат определяется как предусловие соответствующего стимула;

• результирующий контекст v' = 5(р, v) для всех v е Domv, таких чтоprex(p, г) = true, удовлетворяют предикату:

фж,х(Р, V, V) = Vzsetf)POStlv\Use, v'be/). ■

Определение. Предикат Фщх(р, v, v') называется тестовым оракулом стимула х в состоянии управления п. ■

Тестовому оракулу отводится основная роль в проверке правильности поведения тестируемого устройства (см. раздел «Проверка правильности поведения»).

Определение. Автомат, лежащий в основе расширенного автомата Л(Е). интерпретирующего контрактную спецификацию Е, называется управляющим автоматом спецификации Е и обозначается Q(E). ■

Управляющий автомат является формальной моделью управляющей логики устройства. На основе обхода графа состояний управляющего автомата осуществляется генерация тестовой последовательности (см. подраздел 4.2).

3.3. Спецификация конвейера с блокировками

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

Определение. Состоянием обработки стимула или процессом называется пара (х, /), в которой:

• хе!и{т} - обрабатываемый стимул;

• I е {I,..., L} - номер стадии обработки стимула. ■

Определение. Состоянием управления называется множество состояний обработки стимулов. Пустое множество состояний обработки стимулов называется начальным состоянием управления. ■

Множество всевозможных состояний управления для конвейера длины L будем обозначать символом PL.

Определение. Контрактной спецификацией конвейера с блокировками длины L называется шестерка (V, v0,/uO,Iu {т}, Z и {е}, р), в которой:

• V - множество контекстных переменных;

• v0 £ Domv - начальный контекст;

• /иОс V — множество входных и выходных параметров;

• Xu {т} - множество стимулов;

Для каждого стимула х е Xu {т} заданы:

• 1пх с / - множество входных параметров;

• Рь —>■ {true, false} - охранный предикат стимула;

• prex: Domx х Domv —>■ {true, false} - предусловие стимула.

• Z и {е} - множество стадий;

Для каждой стадии zeZu {е} заданы:

• Use: с: 1' \ О - множество используемых контекстных переменных;

• Def c.V\I— множество определяемых контекстных переменных;

• '!■/'■ Рь —>■ {true, false} - охранный предикат стадии;

• postz: Domv х Domv —>■ {true, false} - постусловие стадии.

• р: Xu {т} ->(Zu {e})L - функция композиции операций. ■

Заметим, что по сравнению с определением контрактной спецификации

конвейера без блокировок в данном определении появились охранные предикаты стадий - именно они используются для описания блокировок конвейера.

Определение. Процесс (х, I) называется активным в состоянии управления п, если уг(л) = true, где z = р/(х). В противном случае процесс называется

заблокированным. ■

Определение. Множество Enabled(n) = {(х, /) е л \ у2(тт) = true, где z = р/(х)} называется множеством активных процессов в состоянии управления л. ■ Определение. Множество Locked(n) = л\ Enabled(n), являющееся дополнением множества Enabled(n), называется множеством заблокированных процессов в состоянии управления л. ■

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

Определение. Функция °: (Xu {т}) х Рь —>■ Рь, которая для всех пар (х, л) принимает значение х° л, равное объединению следующих множеств:

• Locked(л);

• {(х, /+1) | (х, I) е Enabled(л) л I < L};

• {(х, 1)}, если х Ф х; 0, если х = х.

называется оператором сдвига конвейера. ■

Определение. Функция 9: PL —>■ 2Z, определяемая равенством

9(7г) = (р/(х) | (х, I) е Enabled(я)} \ {е}, называется оператором связывания стадий конвейера. ■

4. Приложение к задачам тестирования

Рассмотрим применение контрактных спецификаций конвейера для решения основных задач тестирования: проверки правильности поведения и генерации тестовой последовательности.

4.1. Проверка правильности поведения

Определим отношение соответствия меяеду контрактными спецификациями конвейера и инициальными расширенными автоматами5. Рассмотрим контрактную спецификацию £ = (Vs, v0s, Ls u 0s, Xs u {xs}, Zsu {6s}, ps) конвейера без блокировок длины L и инициальный расширенный автомат Д = (S1, Iя, (sj, vj), / и О1, X1 u {х7}, Y1 u {|7}, I1) с выделенными тактовым стимулом х7 и пустой реакцией с7. Введем несколько вспомогательных понятий.

Определение. Сюрьективное отображение <p,v Рь ->■ S1, обладающее свойством cps^(0) = Sq , называется функцией соответствия состояний. ■

5 Для возможности формального определения отношения соответствия

предполагается, что реализация описывается расширенным автоматом.

Определение. Отображение q>x*- Param(Xs u {xs}) —> ParamQи {х7}), обладающее тем свойством, что «р-,-*(Xs) = х7 тогда и только тогда, когда Xs = x's называется функцией соответствия стимулов. ■

Определение. Биективное отображение ф/ : Y1 u {|7} —> 2Z, где Z = обладающее тем свойством, что ф/ (у) = 0 тогда и только тогда, когда У = z называется функцией соответствия реакций. ■

Определение. Отображение Ф^: Domv(r> —> DomnS), где F(7) = F7 и F(5) = Vs, обладающее свойством ф^(v07) = v0s, называется функцией соответствия контекстов. ■

Определение. Будем говорить, что инициальный расширенный автомат соответствует контрактной спецификации для заданных функций соответствия <фх^, Ц>Х~*, фY~, фг”), если ДЛЯ всех nS е Pl,

хх[рх] е Param(Xs u {xs}) и v7 е DomV(i) из того, что yx(ns) = true, вытекает, что X7 е Initii'), причем если prex(ps,vs) = true, ТО pres Jp1, v7) = true, где

•s-7 = фз^С7^), jJ\pI]= tyx^(^\pS\) и Vs = ф^(У), при этом для каждого

инициализированного перехода /[р7] е Enabled^, хг, v7) выполнено •5Л = фх^(УХ), фу^О^ = 0(7r'S) И Фn,x(pS,VS,v'S) = true, ГДе 7l'S = / ° 7IS И

у,х = ф^'0. ■

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

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

специфицированных переходов, который будем называть спецификационным подавтоматом.

Проверка правильности поведения осуществляется для заданных функций соответствия, которые выполняют функции преобразования данных из спецификационного представления в реализационное (<p,v * и «р-,- >) и наоборот из реализационного представления в спецификационное (ф-/ и ф\-' ). Компоненты тестовой системы, которые реализуют такие функции, называются адаптерами. Схема проверки правильности поведения, приведенная ниже, основана на определении отношения соответствия:

(7is, vs) (0, v0s);

if(/ Ф фх^С^) V Vs Ф ф^(V7))

{ еггог(«Ошибка инициализации»); }

// пока тест не завершен Y/hileCisTestComplete()) {

// получить очередной стимул от тестовой системы <— getNextStimulusQ;

//проверить выполнимость охранного предиката и предусловия стимула

^ЩУхС^) /\ргех(р^ УЯ)) {

// преобразовать стимул в реализационное представление

/[р7] <- ф/Ч^Ь5]);

// подать стимул на реализацию арр1у8йти1ш(у?\р\);

// подождать один такт м>аиОпеСус1е();

//получить состояния, реакцию и контекст реализации / <— getState();

У <— getReaction(};

V7 <— getContext();

// преобразовать реакцию/контекст в реализационное представление / <- ф7^(У);

// вычислить новое состояние управления ^ <- х15 ° л8;

^фх^(7ГХ))

{ еггог(«Ошибка несоответствия состояний»); }

1Г(у^0(тгх))

{ еггог(«Ошибка несоответствия реакций»); }

Vх, V'"))

{ еггог(«Ошибка несоответствия контекстов»); }

}

}

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

• гз’Тез’/Со/яр/е/е - проверяет завершена ли генерации тестовой последовательности;

• getNextStimulus - получает очередной инициализированный стимул от генератора тестовой последовательности;

• арр1у8Ити1ш' - подает инициализированный стимул на реализацию;

• и>аИОпеСус1е - ожидает один такт;

• getState - получает состояние управления реализации;

• getReaction - получает реакцию реализации;

• getContext - получает контекст реализации.

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

получения состояния управления getState и функция соответствия состояний fps ' неопределенны. В этом случае проверки вида s' ф <pv >(ns) опускаются. Сравнение у1 Ф 9(ns) также не осуществляется, поскольку реакции устройства (внутренние действия по обработке стимулов), как правило, не наблюдаемы. Проверки, которые выполняются на практике, базируются на предикате Фд x(ps. vs, v's). то есть на наблюдении за изменениями контекста (состояния данных и выходов модуля).

В схеме проверки правильности поведения заложена следующая классификация ошибок в модулях микропроцессоров: ошибки

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

4.2. Генерация тестовой последовательности

Основная особенность конвейерных модулей заключается в сложной организации управляющей логики. В данном разделе рассматривается метод генерации тестовой последовательности, нацеленный на создание различных ситуаций именно в управляющем компоненте модуля. Метод основан на контрактных спецификациях конвейера. Пусть задана спецификация Е = (V, v0,/uO,Iu {т}, Z и {е}, р>.

Определение. Тестовой последовательностью для контрактной спецификации Е называется произвольная последовательность переходов расширенного автомата Л(Е), интерпретирующего спецификацию Е, допустимая в начальной конфигурации (0, v0). ■

Формализацией управляющей логики модуля, описываемого спецификацией Е, является управляющий автомат Q(E). С точки зрения спецификации цель тестирования задается как покрытие всех достижимых состояний управляющего автомата. Предлагаемый метод генерации тестовой последовательности основан на обходе графа состояний управляющего автомата.

Для обхода мы используем неизбыточные алгоритмы, то есть алгоритмы, для работы которых достаточно информации о пройденном подграфе. Входной информацией неизбыточных алгоритмов обхода графов является неизбыточное описание графа [6]

Определение. Неизбыточным описанием графа состояний называется тройка

(V, X, enabled), где:

• V - множество вершин;

• X-множество стимулов;

• enabled: V —> 2х - функция, которая для каждой вершины графа возвращает множество допустимых в ней стимулов. ■

В работах [6-9] исследованы неизбыточные алгоритмы обхода разных классов графов. В частности, в статье [8] рассмотрен неизбыточный алгоритм обхода (/.ф,„б на классе детерминированных сильно-связных конечных графов, а в [6]

- алгоритм а.пфт на классе графов, имеющих детерминированный сильносвязный полный остовный подграф. Следует отметить, что алгоритм а применяется и в тех случаях, когда граф заведомо детерминирован. Дело в том, что этот алгоритм относится к «жадным» алгоритмам и в ряде случаев позволяет значительно сократить длину тестовой последовательности. Заметим, что управляющий автомат является конечным (если множество стимулов конечно) и детерминированным. Несложно показать, что граф состояний управляющего автомата является сильно-связным, если в нем нет тупиковых состояний, то есть состояний % Ф 0, таких, что Enabled(n) = 0 (на практике это условие тоже выполнено - наличие тупикового состояния сигнализирует об ошибке в спецификации). Таким образом, условия применения неизбыточных алгоритмов выполнены.

Неизбыточное описание графа состояний управляющего автомата имеет вид (PL,Xu {т}, enabled), где множество допустимых стимулов для каждого состояния 7г определяется следующим образом:

enabled(n) = {х е Xu {т} | ух(п) = true}.

При тестировании управляющей логики конкретные значения параметров стимулов не важны - можно использовать любые значения, удовлетворяющие соответствующему предусловию. В предложенном методе предполагается, что для любого стимула х и контекста v существует набор параметров р е Domx, который удовлетворяет условию prex(p, v) = true. На практике это не всегда так, то есть возможны ситуации, когда для некоторого стимула х существует контекст v, для которого не существует значений параметров, удовлетворяющих предусловию. Получается, что в одном и том же состоянии управляющего автомата в некоторых ситуациях предусловие стимула выполнено, а в некоторых нет. Эта проблема решается добавлением в состояние обходимого графа конвейера дополнительной информации, на основе которой определяется выполнимость предусловий.

5. Сравнение с существующими подходами

В данном разделе приводится сравнение предлагаемого метода спецификации и тестирования аппаратуры с конвейерной организацией с существующими

6 В указанной работе этот алгоритм обозначается символом А2.

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

5.1. Методы спецификации аппаратуры

В настоящее время для спецификации аппаратного обеспечения широко используются так называемые языки верификации аппаратуры (HVL, Hardware Verification Languages) [1]. К таким языкам относятся PSL, OpenVera, SystemVerilog и другие. HVL-языки включают в себя конструкции языков программирования, языков описания аппаратуры, а также специальные средства, ориентированные на верификацию. Средства спецификации, используемые в современных языках верификации аппаратуры, базируются на темпоральной логике линейного времени (LTL, Linear Temporal Logic) и темпоральной логике деревьев вычислений (CTL, Computation Tree Logic) [1]. Логика CTL используется преимущественно для формальной верификации систем. Для целей симуляции и тестирования больший интерес представляет логика линейного времени. Все языки, использующие LTL, имеют схожие средства спецификации. Они оперируют с ограниченными по времени последовательностями событий, для которых можно обращаться как к прошлому, так и к будущему. Из простых последовательностей можно строить более сложные с помощью логических связок, таких как II и ИЛИ, или используя регулярные выражения. На последовательностях событий можно с помощью темпоральных операторов задавать утверждения (assertions).

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

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

5.2. Методы генерации тестовой последовательности

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

Для построения тестов, покрывающих отдельные ситуации, часто используют методы проверки моделей [10-18]. Генерация тестов, полно покрывающих управляющую логику устройства, как правило, основана на обходе графа состояний автоматной модели [19, 20]. Автоматная модель либо извлекается автоматически на основе статического анализа кода реализации [19, 21], либо строится вручную [14,20]. Автоматическое извлечение модели является сложной задачей, требующей либо наличия в коде аннотаций разработчиков [19], либо привлечения эвристик [10, 11]. Для сложного аппаратного обеспечения автоматическое извлечение автоматной модели управляющей логики практически неосуществимо. При построении модели вручную возникает другая проблема - построенную модель сложно отлаживать [20]. Поскольку на основе такой модели предполагается генерация тестов, важно, чтобы модель точно описывала тестируемый компонент, так как в противном случае цели тестирования не будут достигнуты.

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

6. Опыт практического применения метода

Описанный в статье метод спецификации и тестирования аппаратуры с конвейерной организацией был применен для тестирования модулей промышленного микропроцессора с М1Р864-совместимой архитектурой [22]: буфера трансляции адресов (TLB, Translation Lookaside Buffer) и модуля кэшпамяти второго уровня (L2 cache). Для разработки тестов использовался инструмент CTESK из набора инструментов UniTESK [23], расширенный библиотекой PIPE, реализующей основные концепции предлагаемого подхода.

6.1. Тестирование буфера трансляции адресов

Память тестируемого буфера трансляции адресов состоит из 64 ячеек, которые составляют объединенный TLB (JTLB, Joint TLB). Кроме того, для повышения производительности модуль содержит два дополнительных буфера из 4 ячеек каждый: TLB данных (DTLB, Data TLB) и TLB инструкций (LTLB, Instructions TLB). DTLB используется при трансляции адресов данных, ITLB - при трансляции адресов инструкций. Наличие двух дополнительных буферов

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

Модуль TLB реализует операции чтения, записи, проверки наличия ячейки в буфере, а также операции трансляции адресов данных и инструкций. Интерфейс модуля состоит из приблизительно 30 входов и стольких же выходов. Модуль реализован на языке Verilog, его описание (не считая библиотек) составляет около 3500 строк кода. Формальные спецификации и тесты были разработаны одним человеком приблизительно за 2.5 месяца, а их объем составил около 3500 строк кода. В результате тестирования было найдено 10 ошибок в реализации модуля, включая критичные. Найденные ошибки не были обнаружены при тестировании микропроцессора с помощью других методов7.

6.2. Тестирование модуля кэш-памяти второго уровня

Тестируемый модуль кэш-памяти второго уровня имеет объем 256 Кбайт и состоит из 8192 строк. Каяедая строка содержит данные (4 двойных слова по 64 бит), тэг (18 старших бит физического адреса) и биты служебной информации. Память модуля является смешанной - в ней могут храниться как данные, так и инструкции. Кэш-память адресуется физическим адресом путем прямого отображения.

Модуль кэш-памяти реализует операции загрузки и сохранения данных (в разных режимах), выборки инструкций, а также управляющую операцию для изменения данных и управляющих битов. Интерфейс модуля содержит около 70 входов и 30 выходов. Реализация модуля на языке Verilog составляет около 3000 строк кода. Формальные спецификации и тесты были разработаны одним человеком приблизительно за 4 месяца, а их объем составил около 4000 строк кода. В результате тестирования были найдены 9 ошибок в реализации модуля.

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

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

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

126

К настоящему моменту нами получен большой опыт использования технологии UniTESK и инструмента CTESK для спецификации и тестирования моделей аппаратуры [24]. Опыт показывает, что некоторые шаги разработки тестов могут быть полностью или частично автоматизированы [25]. Детальное исследование этого вопроса и разработка инструментальной поддержки для дальнейшей автоматизации разработки тестов является одним из приоритетных направлений дальнейшей работы.

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

Литература

[1] S.A. Edwards. Design and Verification Languages. Technical Report, Columbia University, New York, USA, November 2004.

[2] B. Beizer. The Pentium Bug - An Industry Watershed. Testing Techniques Newsletter, TTN Online Edition, September 1995.

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

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

[5] D. Patterson and J. Henessy. Computer Organization and Design. 3rd Edition, Morgan Kaufmann, 2005.

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

[7] И.Б. Бурдонов, А.С. Косачев, В.В. Кулямин. Использование конечных автоматов для тестирования программ. Программирование, 2000, №2.

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

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

2004, №1.

[10] D. Moundanos, J. Abraham, and Y. Hoskote. A Unified Framework for Design Validation and Manufacturing Test. ITC'1996: International Test Conference, 1996.

[11] D. Moundanos, J. Abraham, and Y. Hoskote. Abstraction Techniques for Validation Coverage Analysis and Test Generation. IEEE Transactions on Computers, Volume 47, 1998.

[12] D. Geist, M. Farkas, A. Landver, Y. Lichtenstein, S. Ur, and Y. Wolfsthal. Coverage Directed Test Generation Using Symbolic Techniques. FMCAD'1996: Formal Methods in Computer Aided Design, 1996.

[13] P. MishraandN. Dutt. Automatic Functional Test Program Generation for Pipelined Processors using Model Checking. HLDVT'2002: High-Level Design Validation and Test Workshop, 2002.

[14] P. Mishra and N. Dutt. Architecture Description Language Driven Functional Test Program Generation for Microprocessors using SMV. CECS Technical Report 02-26, 2002.

[15] P. Mishra andN. Dutt. Graph-Based Functional Test Program Generation for Pipelined Processors. DATE'2004: Design, Automation and Test in Europe Conference and Exhibition, 2004.

[16] P. Mishra and N. Dutt. Functional Coverage Driven Test Generation for Validation of Pipelined Processors. DATE'2005: Design, Automation and Test in Europe Conference and Exhibition, 2005.

[17] H.M. Koo and P. Mishra. Test Generation using SAT-based Bounded Model Checking for Validation of Pipelined Processors. ACM Great Lakes Symposium on VLSI, 2006.

[18] H.M. Koo and P. Mishra. Functional Test Generation using Property Decomposition for Validation of Pipelined Processors. DATE'2006: Design, Automation and Test in Europe Conference and Exhibition, March 2006.

[19] R. Ho, C. Yang, M. Horowitz, and D. Dill. Architecture Validation for Processors. ISCA'1995: International Symposium on Computer Architecture, 1995.

[20] S. Ur and Y. Yadin. Micro Architecture Coverage Directed Generation of Test Programs. DAC'1999: Design and Automation Conference, 1999.

[21] Y. Hoskote, D. Moundanos, and J. Abraham. Automatic Extraction of the Control Flow Machine and Application to Evaluating Coverage of Verification Vectors. ICCD'1995: International Conference of Computer Design, 1995.

[22] MIPS64 Architecture For Programmers. Revision 2.0. MIPS Technologies Inc., 2003.

[23] http://www.unitesk.com.

[24] M. Chupilko, A. Kamkin, and D. Vorobyev. Methodology and Experience of Simulation-Based Verification of Microprocessor Units Based on Cycle-Accurate Contract Specifications. SYRCoSE'2008: The 2nd Spring Young Researchers Colloquium on Software Engineering, 2008.

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

2005.