CC BY
14
УДК 004.415.53
В.П. Иванников, А.С. Камкин, M.M. Чупилко
ПРОВЕРКА КОРРЕКТНОСТИ ПОВЕДЕНИЯ HDL-МОДЕЛЕЙ ЦИФРОВОЙ АППАРАТУРЫ НА ОСНОВЕ ДИНАМИЧЕСКОГО СОПОСТАВЛЕНИЯ ТРАСС
V.P. Ivannikov, A.S. Kamkin, M.M. Chupilko
VERIFYING CORRECTNESS OF HDL-MODEL BEHAVIOR ON THE BASIS OF DYNAMICAL TRACE MATCHING
Проверка корректности поведения HDL-моделей является неотъемлемой частью динамической верификации аппаратуры. Как правило, она основана на сравнении поведения HDL-модели с поведением эталонной модели, разработанной на языке программирования. В процессе верификации на обе модели подается одна и та же последовательность стимулов; реакции перехватываются и сравниваются друг с другом. Из-за абстрактности эталонной модели сопоставление трасс не является тривиальной задачей: порядок событий может не совпадать, а некоторые события одной трассы могут отсутствовать в другой. Рассмотрен метод динамического сопоставления трасс для моделей аппаратуры разного уровня абстракции. Метод успешно применен в нескольких промышленных проектах по верификации модулей микропроцессоров.
ДИНАМИЧЕСКАЯ ВЕРИФИКАЦИЯ; МОДУЛЬНАЯ ВЕРИФИКАЦИЯ; HDL; СОПОСТАВЛЕНИЕ ТРАСС; ЧАСТИЧНО-УПОРЯДОЧЕННЫЕ МУЛЬТИМНОЖЕСТВА.
Correctness checking of HDL-model behavior is an integral part of dynamical verification of hardware. As a rule, it is based on comparing of HDL-model behavior and reference model behavior, developed in high-level programming languages. Being verified, both models are applied with the same stimulus sequences; their reactions are caught and checked against each other. Due to the abstractness of the reference model, the checking is not a trivial task as event sequences can be different and some events of one trace may miss in the other one. A methodology of dynamical trace matching for hardware models of different abstraction levels is considered in the paper. The methodology has been successfully used in a number of industrial projects of unit-level microprocessor verification.
DYNAMICAL VERIFICATION; UNIT-LEVEL VERIFICATION; HDL; TRACE MATCHING; PARTIALLY ORDERED MULTISETS.
Несмотря на развитие формальных методов, динамическая верификация остается основным методом проверки сложной цифровой аппаратуры [1]. Объектом верификации выступают не сами устройства, а их модели, разработанные на специальных языках описания аппаратуры (Hardware Description Languages — HDL), например, на Verilog или VHDL (такие модели называются HDL-моделями) [2]. С одной стороны, HDL-модели представляют основу для автоматизированного производства интегральных схем; с другой стороны, это
имитационные модели, поведение которых можно анализировать в специальных средах (симуляторах). Для автоматизации проверки корректности поведения HDL-моделей разрабатываются мониторы, перехватывающие события на входах и выходах (стимулы и реакции) и проверяющие допустимость получаемой трассы [3].
Существует множество подходов к формальному описанию поведения, позволяющих автоматизировать создание мониторов: расширенные регулярные выражения [4], контрактные спецификации [5], системы пра-
вил [6], темпоральные утверждения [7], однако указанные формализмы не покрывают всех потребностей индустрии. Большинство компаний, проектирующих аппаратуру, для оценки проектных решений используют исполнимые модели, разработанные на языках программирования (прежде всего, на С и С++) [8]. Экономически целесообразно использовать эти модели и для верификации создаваемой аппаратуры, в частности, для проверки корректности поведения ИБЬ-моделей.
При наличии исполнимой модели применяют следующую схему проверки корректности поведения: эталонная модель (по терминологии тестирования соответствия, спецификация) выполняется совместно с проверяемой ИВЬ-моделью (реализацией); на спецификацию поступает та же последовательность стимулов, что и на реализацию; реакции обеих моделей перехватываются монитором и сравниваются. Основная проблема указанной схемы связана с обобщенным характером спецификации, из-за чего порядок реакций, выдаваемых спецификацией и реализацией, а также их состав могут различаться. Перед тем как использовать эталонную модель для мониторинга, необходимо понять, насколько она абстрактна и насколько можно доверять производимым ею трассам.
В статье предлагается способ построения мониторов для ИБЬ-моделей аппаратуры, адаптируемый для эталонных моделей разного уровня абстракции. Рассматриваемый подход может быть формализован на основе модели частично упорядоченных мультимножеств [9]. Поведение спецификации и реализации описывается временными трассами над общим алфавитом. Сведения об абстрактности спецификации позволяют обобщать последовательности выдаваемых реакций в частично упорядоченные мультимножества, в которых для каждой реакции задан допустимый временной интервал. Монитор проверяет, что трасса реализации является линеаризацией обобщенной трассы спецификации (или ее подмножества) и реакции реализации удовлетворяют ограничениям, заданными временныыми интервалами.
Основные понятия и обозначения
В дальнейшем будем использовать следующие обозначения: Е — конечный алфавит событий; Т — временная область (для определенности, N). Последовательности событий называются словами. Е* обозначает множество всех (конечных) слов над алфавитом Е.
В контексте динамической верификации HDL-моделей удобно структурировать алфавит событий, разбив его на два множества: множество входных событий (стимулов) I и множество выходных событий (реакций) O, а также сопоставив каждому событию его порт: port : Е ^ {1,2,..., к}. На содержательном уровне стимул представляет собой посылку запроса к устройству, а реакция — выдачу ответа. При этом события на разных портах могут происходить параллельно.
Определение 1 (Временное слово [10]). Временным словом (timed word) w над алфавитом Е и временной областью Т называется конечная последовательность (a1, t1)...(an, tn) временных событий (a,tt) е Ех Т, удовлетворяющая следующим ограничениям:
1) для каждого 1 < i < n выполняется неравенство ti < ti+1;
2) для всех 1 < i, j < n, таких что i ф j и tt = tj, port (e(.) ф port (j. □
В параллельных системах, к которым относится аппаратура, используется концепция независимости событий: два события считаются независимыми, если между ними нет причинно-следственной связи (для таких событий не накладываются ограничения на их относительный порядок). Эта идея лежит в основе двух формальных моделей параллельных вычислений: (1) трасс Мазуркевича [11] и (2) частично упорядоченных мультимножеств [9]. В настоящей статье мы будем придерживаться более общей второй модели.
Определение 2 (Частично упорядоченное мультимножество [9]). Е -размеченным частичным порядком называется кортеж (V, X), где V — конечное множество вершин, ^с V х V — отношение частичного порядка и X : V ^ Е — функция
4
разметки. Два Х-размеченных частичных порядка называются эквивалентными, если они изоморфны относительно ч и X (либо совпадают, либо отличаются только названием вершин). Частично упорядоченным мультимножеством (pomset, partially ordered multiset) над алфавитом Е называется класс эквивалентности Е -размеченных частичных порядков. □
Для удобства мы будем использовать конкретного представителя (конкретный размеченный частичный порядок) для обозначения частично упорядоченного мультимножества. Линеаризацией частично упорядоченного мультимножества (V, ч, X) называется размеченный полный порядок (V, <, X), где чс< .
Определение 3 (Временная трасса [12]). Временной трассой над алфавитом Е и временной областью Т называется четверка (V, ч, X, 9), где (V, ч, X) — частично упорядоченное мультимножество, а 9 : V ^ Т — функция времени, удовлетворяющая следующему условию: для всех x,y е V, из x ч y вытекает 9(х) < 9(у). □
Множество всех трасс над алфавитом Е и временной областью Т обозначается М9(Е, Т) или, для краткости, М. Заметим, что определенные ранее временные слова являются частным случаем временных трасс (это трассы с тривиальным отношением частичного порядка на множестве вершин — отношением равенства).
Для заданной непустой трассы ст = (V, ч, X, 9) введем обозначения:
begin(a) = min XeV {9(x)}; end (ст) = max xeV {9(x)};
Vlt^+д,] = {x е V I 9(x) е [t, t + At]};
CT[t,t + At] = (V[t,t + At], 4 V[t,t + At], X\Vit,t + At^ 9|V[t t + At] ).
Пусть ТГ(Т) — множество временных интервалов во временной области Т, то есть ТТ(Т) = {[t, t + At] I t, t + At е Т}.
Определение 4 (Интервальная трасса). Интервальной трассой над алфавитом Е и временной областью Т называется четверка ст = (V, ч, X, 9), где (V, ч, X) — частично упорядоченное мультимножество, а S : V ^ И (Т) — функ-
ция, сопоставляющая каждой вершине временной интервал. □
В дальнейшем мы будем иметь дело с расширенными интервальными трассами, описываемыми пятерками ст = (V, ч, X, 9,8). В таких трассах с каждой вершиной х е V связан как момент времени 9(х), так и временной интервал 8(х) = [9(х) - Дt—х), 9(х) + Дt+ (х)]. Будем считать, что функции Дt± : V ^ Т ограничены: существуют константы ДТ± > 0, такие что | Д^(х) |< ДТ± для всех х е V, и, кроме того, их значения зависят только от событий: если Х(х) = Х(х'), то Дt ±(х) = Дt ±( х').
Динамическая верификация на основе исполнимых моделей
Временное слово (временная трасса с тривиальным частичным порядком) описывает конкретное выполнение ИБЬ-модели (реализации), в то время как расширенная интервальная трасса описывает поведение эталонной модели (спецификации). Наша цель — проверить в динамике (оп-Ше-Ау), что трасса реализации (временное слово) соответствует трассе спецификации ст^. (расширенной интервальной трассе). Поясним, почему в качестве спецификацион-ной трассы рассматривается расширенная интервальная трасса. В процессе выполнения спецификация порождает конкретную трассу ^ описываемую временным словом. Прямое сравнение двух временных слов, w1 и на равенство возможно только для потактово точной спецификации. Как правило, спецификация абстрактнее реализации, особенно в отношении временных свойств. Для того чтобы использовать абстрактную спецификацию для проверки поведения реализации, в ее коде с помощью специальных средств задаются ограничения на порядок реакций и время их возникновения (рис. 1). Подробнее об этом говорится в разделе «Инструментальная поддержка и опыт применения».
Отношение соответствия. В дальнейшем мы будем называть временные трассы с тривиальным частичным порядком (порядком, заданным отношением равенства) трассами выполнения. Если Е = I и О, то трассы выполнения над алфавитом I будем
Рис. 1. Схема проверки соответствия между реализацией и спецификацией
называть входными последовательностями, а трассы выполнения над алфавитом O — выходными последовательностями. Отметим, что тривиальный частичный порядок в трассах выполнения отражает тот факт, что реализация рассматривается как «черный ящик», и причинно-следственные связи между ее событиями если и известны, то не от самой реализации. Множества входных и выходных последовательностей обозначаются Ie (Е, Т) и Ое (Е, Т) соответственно. Для краткости будем использовать сокращенные обозначения: I = Ie(Е, Т) и О = Ое (Е, Т).
Определение 5 (Поведение). Детерминированным поведением над алфавитом Е = I u O и временной областью Т называется (частичная) функция В : I х Т ^ О, удовлетворяющая следующим ограничениям:
1) для всех w е I и t е Т выполняется неравенство end(B(w, t)) < t;
2) для всех w е I и t е Т справедливо равенство В (w, t) = В (w[0t р t). □
Поведение описывает, каким образом входная последовательность преобразуется в выходную последовательность, принимая во внимание момент времени, в который производится наблюдение.
Предположим, что у нас имеется исполнимая спецификация. Рассмотрим, как ее можно использовать для динамической проверки поведения реализации. Для этого расширим определение поведения, позволив спецификации возвращать расширенные интервальные трассы. Обо-
значим множество всех таких трасс символом Ое5 = Ое5 (Е, Т). Таким образом, поведение спецификации — это функция В : I х Т ^ Ое5, удовлетворяющая указанным в определении ограничениям (используемые обозначения имеют смысл и для расширенных интервальных трасс).
Пусть X и Б — поведение реализации и поведение спецификации соответственно. Для заданной входной последовательности w е I и момента времени t е Т рассмотрим выход реализации и спецификации: Xt) = V, =, Xх, ех) и 0 = V, ч 5, , е5, 55). Введем обозначения:
pastXt^, t) = {у е X^) I 9г(у) < ^ - ДГ(у))};
pastI(w, t) = {у е Xt) I ех(у) < ^}; pastДtt) = {х е t) I 95(х) < (t - Дt + (х))};
pasts t) = {х е t) I е5(х) < t}; match(х, у) = (Хх(у) = (х)) л (ех(у) е 55(х)).
Заметим, что в определении pastДt (w, t) используется функция Дt-, заданная для выходной трассы спецификации (для трассы реализации, не являющейся расширенной интервальной трассой, функции Дt± не определены).
Определение 6 (Отношение соответствия). Говорят, что поведение реализации X соответствует поведению спецификации 5 , если domX = ^^^^ (X и 5 определены на одном множестве входных последовательностей) и для всех w е domS и t е Т существует бинарное
4
отношение M(w, t) с {(х, y) е pasts (w, t) х х past1(w, t) I match(x, y)}, называемое сопоставлением, такое что:
1) M( w, t) взаимно однозначно;
2) для каждой реакции спецификации х е pastS (w, t) существует реакция реализации y е pastT (w, t), такая что (х, y) е M(w, t);
3) для каждой реакции реализации y е pastS (w, t) существует реакция спецификации х е pastS (w, t), такая что (х, y) е M(w, t);
4) для всех (х, y), (х', y') е M(w, t) если х^ X то 0г(y) <9г(y').
Если для некоторых w е domS и t е Т сопоставления не существует, то говорят, что 1 не соответствует S, при этом w называется контрпримером. □
Рис. 2 иллюстрирует определение отношения соответствия для некоторой входной последовательности (будучи неважной, она на рисунке не показана) и момента времени t = 4. Верхняя часть рисунка показывает реакции реализации (черные кружки с белыми надписями: b, a и c), нижняя — реакции спецификации (белые кружки с черными надписями: a, b, c и d). Обозначим вершины трассы (собственно, кружки) символами yb, ya и yc (для реализации) и ха, хь, хс и ха (для спецификации). Между
вершинами реализационной трассы нет причинно-следственных связей. Вершины спецификационной трассы частично упорядочены (непосредственное предшествование событий показано стрелками: ха — xc, xb — xc, xa — ^ и хь — ^^) и помечены временными интервалами (8( ^^) = [0,2], 8^) = [1,25], 8^) = [0,4] и ( = [1,5]). Сопоставление реакций отмечено пунктирными линиями ((хa, уa), (хь, Уь) и (хс, ус)). Легко видеть, что изображенное отношение является сопоставлением (в смысле данного выше определения): (1) оно взаимно однозначно; (2 и 3) оно включает все реакции с истекшим «временем жизни»; (4) оно сохраняет спецификационный порядок: (а) xa < xc и 9(30 = 2 < 3 = 0(у); (Ь) Хь< xc и 9(уЬ ) = 1 < 3 = 9(ус). Безусловно, каждаяпара этого отношения удовлетворяет условию сопоставления реакций: (а) А^а) = А(уа) = а и 9(Уа) = 2 е [0,2] = 8(Xa^^ (Ь) А(у) = А(у) = Ь и 9(у) = 1 е [1,3] = З^Ь; (с) ) = А(у) = с и 9(у) = 3 е [0,4] = З(xc).
Динамическое сопоставление трасс. Монитор, осуществляющий сопоставление трасс реализации и спецификации, может быть представлен как временной автомат [10] с двумя типами входных портов: (1) порты для получения спецификационных реакций и (2) порты для получения реали-
Рис. 2. Соответствие между реализацией и спецификацией
зационных реакций. Когда автомат обнаруживает расхождение в трассах реализации и спецификации, он переходит в определенное состояние, информируя, тем самым, что реализация не соответствует спецификации.
Ниже представлено формальное описание монитора в виде системы действий с условиями (guarded actions) [13]. Каждое действие атомарно и выполняется, как только соответствующее условие становится истинным. Действия и условия зависят от внешней переменной t, отражающей текущее время, и реакций, выдаваемых реализацией и спецификацией в ответ на одну и ту же последовательность стимулов (I и S соответственно). Значение переменной t монотонно возрастает в процессе верификации. Запись у е I[t] (х е S[t]) означает, что в момент времени t реализация (спецификация) выдает реакцию у(х). Пометка [t еТ(у)] в действии onSpecOut говорит о том, что перебор реакций у е pastj осуществляется в порядке возрастания ег (у).
Пусть X — подмножество вершин трассы спецификации, ч — заданное на множестве X отношение частичного порядка, у — вершина трассы реализации. Введем следующие обозначения:
min_,(X) = {х е X \$х' е X. х' ф х л х' ч х};
match(X, у) = {х е X \ match(х, у)}.
Кроме того, определим две функции, на которых основано описание монитора: первичный арбитр (arbiterS) и вторичный арбитр (arbiterj) :
[min_, (X) если X ф 0, [ф иначе (ф g X);
arbiterS ( X ) =
arbiterI (X, y ) =
а^ тт х^м х ,у ){е5(х)} если match(X, у) ф 0, ф иначе.
Первичный арбитр для заданного множества X вершин спецификационной трассы возвращает его подмножество, состоящее из минимальных по отношению частичного порядка ч элементов. Вторичный арбитр сопоставляет вершину у реализационной трассы с вершинами специфи-кационной трассы из множества X.
Ниже приведен порядок проверки условий и запуска действий в момент времени t (при несоблюдении этого порядка возможны ложные сообщения об ошибках):
1) инициализация (onInnitialize);
2) прием реакции (onSpecOut, onImplOut);
3) превышение лимита времени (onSpecTime, onlmplTime);
4) завершение (onFinalize).
Когда говорят, что некоторое свойство Ф выполняется в момент времени t, имеется в виду, что ф выполняется после завершения всех действий, активированных в момент t. Для многопортовых систем (что типично для аппаратуры) монитор можно разбить на слабо связанные компоненты, параллельно обслуживающие отдельные порты.
Утверждение 1 (Корректность). Входная последовательность является контрпримером тогда и только тогда, когда монитор завершается с verdict = false.
Схема доказательства. Докажем, что если verdict = false, то w, входная последовательность, — контрпример. Согласно описанию монитора, имеются две возможности, когда переменной verdict присваивается значение false:
1) при выполнении действия onSpecTime;
2) при выполнении действия onlmplTime.
В обоих случаях можно показать, что
w — контрпример. Рассмотрим для примера случай 1. Пусть t — время завершения работы монитора (вызова оператора terminate). Выполнение действия onSpecTime в момент времени t подразумевает, что существует реакция спецификации х е pastS, такая что (((х) + At+ (х)) < t (следовательно, х е pastAt(w, t)). Предположим, что существует сопоставление M (то есть w — не контрпример). Тогда найдется реакция реализации y е pastj (w, t), такая что (х, y) е M (см. п. 2 определения отношения соответствия). По какой-то причине эта реакция не была сопоставлена монитором с реакцией х. Не ограничивая общности рассуждений, положим, что реакция y пришла раньше реакции x. Возможны две причины, по которым эти реакции не были
4
Действие 1 onSpecOut[x],xe S[i] Бели: true Вход: х
pasts <= pasts u {jc} if xg arbiters{pasts) then
for all ye past, 6T{y) ] do if x = arbiter,({x}, y) then pasts <= pasts \{x} pastj <= past, \{j} match <= match и {(x, y)} break end if end for end if
Действие 2 onImplOut[y], у e I[t] Если: true Вход: у
past, <= past, u{y} x <= arbiter, (arbiter^ (pasts), j) if x Ф ф then
pasts pasts \{x} past, <= past, \{;y} match <= match u { (jc, y)} end if
Действие 3 onSpecTime[x],xe pasts Если: (0s(x) + Ai+(x)) <r Вход: x
pasts <= pasts \ {x} verdict <= false trace («Missing output») terminate
Действие 4 onImplTime[y], у e past, Если: (у) + AT (?))<* Вход: у
past, <= past, \{y} verdict <= false trace («Unexpected output») terminate
Действие 5 onlnitialize Если t = 0 Вход: 0
pasts <= 0 past, <= 0 match <= 0
Действие 6 onFinalize Если
max (end(S) + A T+, end (/) + A T~)<t
Вход: 0 verdict <= true terminate
сопоставлены при выполнении действия onSpecOut для реакции х:
a. при получении реакции х было выполнено условие х g arbiterS (pastS) (см. описание действия onSpecOut и определение функции arbiter,);
b. к этому моменту реакция y уже была сопоставлена с другой реакцией спецификации (обозначим эту реакцию х*).
Рассмотрим случай а. Условие х g arbiterS (pastS) выполняется, только если существует реакция спецификации х' ф х,, такая что х' ч х и х' е arbiterS (pastS) (см.
определение функции arbiterS). Если таких реакций несколько, пусть х' — та из них, на которой достигается минимум функции 0S. Пусть у' — реакция реализации, такая что (х', y') е M. Отметим, что реакция у' пришла не позже реакции у (это следует из п. 4 определения отношения соответствия), и она не была сопоставлена с реакцией х' (в противном случае в момент прихода реакции х было бы выполнено условие х' g pastS и, как следствие, х' g arbiterS (pastS). Заметим, что решение о сопоставлении реакции х' с одной из
реакций реализации должно быть принято не позднее момента времени t, даже если (0S (х') + At+ (х')) > t : поскольку х' ч х, то
0г(y'*) < 0г(y*) < (0S(х) + At+ (х)) < t,
где y * и y ' * — произвольные реакции реализации, которые могут быть сопоставлены с х и х' соответственно. Причиной, по которой реакции х' и y' не были сопоставлены, может быть только b. Таким образом, случай a для пары реакций (х, у) сводится к случаю b для пары реакций (х, у).
Рассмотрим теперь случай b. Пусть Nx — общее число реакций реализации, произошедших до момента времени t включительно. Очевидно, что реакция х* (с которой была сопоставлена реакция y) произошла не позже реакции х. Пусть y* — реакция реализации, такая что (х*, y*) е M. Отметим, что реакция y* произошла не раньше реакции y (в противном случае, поскольку в действии onSpecOut реакции реализации рассматриваются в порядке возрастания времени их прихода, реакция х* сопоставилась бы с реакцией y* или иной реакцией, отличной от y, которая произошла раньше). Покажем, что выполнено условие match(х, y * ) :
Ч (У ') = Ч (х *) = Ч (у) = X s (х );
(Xs (х•) = Xs(х)) ^ (At+ (х•) = At+ (х)) ^
(0S ( х ) -At - ( х )) <0j ( y ) <0j ( y •) < < (0S(х•) + At+ (х•)) < (0S(х) + At+ (х)).
Тем не менее реакция y*, как и реакция y, не была сопоставлена монитором с реакцией х. Применяя аналогичные рассуждения в отношении (х,y*) и последующих пар реакций, получим, что общее число реакций реализации не ограничено числом NT, что противоречит определению этого числа. Следовательно, сопоставления не существует, а значит, w — контрпример, что и требовалось доказать.
Теперь докажем, что если w — контрпример, то монитор завершается с verdict = false. Предположим противное, т. е. то, что монитор не завершается с verdict = false (это равносильно невыполнению действий onSpecTime и onImplTime ). Рассмотрим произвольный момент времени t, не пре-
восходящий время завершения работы монитора (если он завершается). Покажем, что отношение match, построенное к моменту t, является сопоставлением (выполнены свойства 1—4 из определения отношения соответствия). Во-первых, match — взаимно однозначное отношение (поскольку при каждом обновлении match используются только новые, не принадлежащие match, реакции). Во-вторых и в-третьих, match включает все реакции спецификации х е past A (w, t) и все реакции реализации y е pastA (w, t) (в противном случае выполнилось бы одно из действий onSpecTime или onImplTime, что привело бы к завершению монитора с verdict = false ). В-четвертых, если (х, y),(х', y') е match и х ч х', то 0x(y) < 0x(y') (если х ч х' и х ф х\ то сопоставление пары реакций (х, у) осуществляется не позже сопоставления (х, y'): условие х' е arbiterS(pasts) может быть выполнено только после того, как реакция х будет удалена из множества pastS ). Из существования сопоставления вытекает, что w — не контрпример, что противоречит условию утверждения. Следовательно, монитор завершается, причем verdict = false, что и требовалось доказать. □
На практике встречается аппаратура, в которой операции в некоторых ситуациях отменяют другие операции (конфликтующие с ними и имеющие более низкий приоритет). Например, операция записи может быть отменена другой операцией записи, адресующейся к той же ячейке памяти и запущенной сразу после рассматриваемой операции. Из-за абстрактности спецификации в ее терминах не всегда возможно выразить условия, при которых происходит отмена операций и соответствующие реакции не посылаются наружу. Принимая во внимание сказанное выше, определение спецификационного поведения может быть расширено: каждая спецификационная реакция дополнительно помечается признаком возможной отмены. Предложенный подход к организации мониторов может быть перенесен и на этот случай. Следует, однако, учесть, что если некоторое событие отменяется, то также отменяются все зависимые от него события.
4
Обзор существующих работ
В работе [14] используется модель автомата с частично упорядоченными входными/выходными событиями (Partial Order Input/Output Automaton — POIOA) для представления поведения спецификации и реализации. В статье предложен метод построения тестового набора, гарантирующего обнаружение ошибок определенного типа. Если (1) реализация сообщает о приеме неподдерживаемых стимулов, (2) можно установить порядок выдачи реакций, (3) время ответа реализации ограничено, и (4) каждый единичный переход в спецификации соответствует единичному переходу в реализации, можно определить соответствие между реализацией и спецификацией. Реализация соответствует спецификации, если она принимает допускаемые спецификацией стимулы и выдает описываемые спецификацией реакции в допустимом порядке. Определение отношения соответствия, данное в этой статье, близко к используемому нами. Главными отличиями нашего подхода являются поддержка необязательных реакций и контроль временнЫх интервалов.
Статья [15] описывает подход к проверке поведения временныых систем, основанный на инвариантах трассы. Рассматриваются два типа инвариантов: (1) инварианты ожидания, выражающие то свойство, что после заданной трассы всегда ожидается определенное событие (в определенном временном интервале), и (2) инварианты наблюдения, утверждающие, что между двумя заданными событиями всегда наблюдается определенная последовательность событий. Корректность поведения реализации проверяется в два этапа: (1) проверка соответствия инвариантов спецификации, выраженной в форме временного конечного автомата (Timed Finite State Machine — TFSM); (2) проверка выполнимости инвариантов для трассы реализации. Подход представляет теоретический интерес, однако его промышленное использование может быть затруднено необходимостью постоянного согласования проверяемых инвариантов со спецификацией.
В работе [16] рассматривается метод тестирования параллельных систем с помощью неявно заданных асинхронных конечных автоматов (Asynchronous Finite State Machines — AFSM). Поведение реализации проверяется только в стационарных состояниях, в которых не ожидается выдача реакций. Используется следующая процедура: (1) собираются все события и определяется их частичный порядок; (2) строятся и проверяются все возможные линеаризации множества событий (проверка базируется на пред- и постусловиях, определенный: для каждого события). Считается, что реализация соответствует спецификации, если допускается хотя бы одна из построенных линеаризаций. Применение подхода возможно только для ограниченного класса входных последовательностей: требуется, чтобы регулярно возникали стационарные состояния. В нашем случае такого ограничения нет.
Инструментальная поддержка и опыт применения
Предложенный метод к проверке корректности поведения HDL-моделей реализован в инструменте C++TESK [17]. Библиотека инструмента содержит классы и макросы для создания компонентов систем динамической верификации аппаратуры (эталонный: моделей, мониторов, генераторов стимулов и др.). Возможности C++TESK для разработки эталонный: моделей аппаратуры (и, соответственно, мониторов) включают средства для посылки и приема пакетов данныж (примитивы send и receive), ветвления и объединения параллельных процессов (fork и join), моделирования временных задержек (delay) и задания зависимостей между пакетами (depends).
Ниже приведены описания некоторых примитивов C++TESK, наиболее важныж для затрагиваемой в статье темы (для наглядности их синтаксис несколько отличается от используемого в инструменте):
• delay(n) — моделирует временную задержку (выполнение процесса прерывается, а возобновление работы планируется через n единиц времени);
• receive(in) : pkg — ждет до тех пор, пока
входной пакет не будет получен на входном порту (in), а затем возвращает этот пакет (pkg);
• send(out, pkg, opt) - посышает выходной пакет (pkg) через выжодной порт (out), указывая, является ли данный пакет обязательным или опциональным (opt);
• depends(pkg1, pkg2) - указывает, что выжодной пакет (pkg1) зависит по данным или связан причинно-следственной связью с другим пакетом (pkg2), входным или выходным.
Заметим, что каждый раз, когда пакет данных выдается наружу с помощью примитива send, он помечается временныым интервалом [t -At-, t + At+], где t - время начала посышки, а At± — пользовательские параметры выжодного порта. Для каждого порта также задается режим работы: fifo (режим по умолчанию) или unordered. В режиме fifo при посылке пакета добавляется зависимость этого пакета от последнего пакета, переданного через тот же выходной порт и
находящегося в очереди ожидания (еще не сопоставленного с пакетом реализации), в режиме unordered никакие зависимости не добавляются. Дополнительные ограничения на порядок пакетов, если они нужны, задаются с помощью примитива depends.
Инструмент позволяет создавать модели аппаратуры на разных уровнях абстракции (относительно точности моделирования времени): (1) модели без учета времени (описывающие общие причинно-следственные связи между пакетами данных без моделирования временныых задержек между ними: At± = да ), (2) модели с приближенным учетом времени (частично специфицирующие внутренние схемы арбитража пакетов, но учитывающие время лишь примерно: At < T, где T имеет значение нескольких десятков тактов) и (3) потактовые модели (реализующие точное или почти точное моделирование времени: At± < 1).
Инструмент C++TESK использован для динамической верификации моду-
Опыт применения предложенного метода
Название модуля Стадия разработки Точность разработки
от до
Буфер трансляции адресов Поздняя/ завершающая Приближенная Потактовая
Модуль арифметики (FPU) Поздняя/ завершающая Без учета времени -
Кэш-память 2-го уровня (L2) Промежуточная/ поздняя Приближенная -
Коммутатор северного моста Промежуточная/ завершающая Приближенная Потактовая
Модуль доступа к памяти Ранняя/ промежуточная Без учета времени Потактовая
Контроллер прерываний Ранняя/ промежуточная Без учета времени Приближенная
Модуль поиска по таблице страниц Поздняя Приближенная -
Контроллер банка кэш-памяти L2 Поздняя Потактовая -
Буфер команд Поздняя/ завершающая Потактовая -
Кэш-память 3-го уровня (L3) Промежуточная Приближенная -
4
леи промышленных микропроцессоров, разрабатываемых в НИИСИ РАН и ЗАО «МЦСТ». Наш опыт уже был описан в [18], но с тех пор он расширился. Последняя информация о применении инструмента и заложенного в нем метода представлена в таблице. Как видно из нее, подход поддерживает верификацию как с помощью абстрактных эталонных моделеИ (доступных на ранних стадиях проектирования), так и с помощью потактово точных моделеИ (доступных на заключительных этапах). Что важно, подход позволяет использовать для верификации С++-модели, изначально создаваемые для других целеИ (в частности, компоненты системного симулятора микропроцессора). Таким способом, например, был проверен модуль поиска по таблице страниц.
Статья сфокусирована на использовании исполнимых моделеИ для динамиче-скоИ верификации ИБЬ-моделеИ. Проблема не так проста, как кажется на первыИ взгляд. Проверка того, что реализация и спецификация выдают одинаковые реакции в одинаковые моменты времени в боль-
шинстве случаев не является адекватноИ. Спецификация в силу своеИ абстрактности может не учитывать многих особенностеИ реализации, таких как упорядочивание событиИ и их распределение во времени. В работе предложены механизмы, позволяющие настраивать точность проверки поведения, учитывая степень абстрактности спецификации. К ним относятся: (1) описание отношения зависимости событиИ, (2) расширение временных меток событиИ до временных интервалов и (3) пометка некоторых событиИ как необязательных. Основываясь на предложенных механизмах, разработан метод проверки поведения ИБЬ-моделеИ. Метод был реализован в инструменте С++ТБ8К и применялся в более чем 10 проектах по верификации мо-дулеИ микропроцессоров. Наши дальнеИ-шие исследования связаны с диагности-коИ ошибочного поведения ИБЬ-моделеИ на основе более глубокого анализа трасс, выполняемого после сеанса верификации. Целью такого анализа является упрощение локализации ошибок путем определения характера расхождениИ наблюдаемого поведения ИБЬ-модели от эталонного.
СПИСОК ЛИТЕРАТУРЫ
1. Wile B., Goss J., Roesner W. Comprehensive Functional Verification: The Complete Industry Cycle. Morgan Kaufmann, 2005.
2. Bergeron J. Writing Testbenches: Functional Verification of HDL Models. Kluwer Academic, 2000.
3. Glasser M. Open Verification Methodology Cookbook. Springer, 2009.
4. Sen K., Rosu G. Generating Optimal Monitors for Extended Regular Expressions // Electronic Notes in Theoretical Computer Science. 2003. No. 89(2). Pp. 162-181.
5. Ivannikov V., Kamkin A., Kossatchev A., Kuliamin V., Petrenko A. The Use of Contract Specifications for Representing Requirements and for Functional Testing of Hardware Models // Programming and Computer Software. 2007. No. 33(5). Pp. 272-282.
6. Barringer H., Rydeheard D., Havelund K. Rule Systems for Run-Time Monitoring: From Eagle to RuleR // In Proc. of 7th Internat. Workshop on Runtime Verification. Revised Selected Papers. 2007. Pp. 111-125.
7. Bauer A., Leucker M., Schallhart C. Runtime Verification for LTL and TLTL // ACM Transactions on Software Engineering and Methodology. 2011. No. 20(4). Pp. 14:1-14:64.
8. Mintz M., Ekendahl R. Hardware Verification with C++: A Practitioner's Handbook. Springer Science+Business Media, LLC. 2006.
9. Pratt V. The Pomset Model of Parallel Processes: Unifying the Temporal and the Spatial // In Seminar on Concurrency. 1984. Pp. 180-196.
10. Alur R., Dill D. A Theory of Timed Automata // Theoretical Computer Science. 1994. No. 126(2).
Pp. 183-235.
11. Mazurkiewicz A. Trace Theory // In Advances in Petri Nets 1986, Part II on Petri Nets: Applications and Relationships to Other Models of Concurrency. New York: Springer-Verlag, 1987. Pp. 279-324.
12. Chieu D., Hung D. Timed Traces and Their Applications in Specification and Verification of Distributed Real-time Systems // In Proc. of the 3rd Symp. on Information and Communication
Technology. 2012. Pp. 31-40.
13. Dijkstra E.W. Guarded Commands, Nondeterminacy and Formal Derivation of Programs // Communication of the ACM. 1975. No. 18(8). Pp. 453-457.
14. von Bochmann G., Haar S., Jard C., Jourdan G.V. Testing Systems Specified as Partial Order Input/Output Automata // In Proc. of the 20th IFIP TC 6/WG 6.1 Internat. Conf. on Testing of Software and Communicating Systems: 8th Internat. Workshop. 2008. Pp. 169-183.
15. Andres C., Merayo M., Nunez M. Formal Passive Testing of Timed Systems: Theory and Tools // Software Testing, Verification & Reliability. 2012.
No. 22(6). Pp. 365-405.
16. Kuliamin V., Petrenko A., Pakoulin N., Kossatchev A., Bourdonov I. Integration of Functional and Timed Testing of Real-Time and Concurrent Systems // In Perspectives of System Informatics. 2003. Pp. 450-461.
17. ISPRAS: C++TESK Homepage [электронный ресурс] / URL: http://forge.ispras.ru/projects/ cpptesk-toolkit/
18. Chupilko M., Kamkin A. A TLM-Based Approach to Functional Verification of Hardware Components at Different Abstraction Levels // In Proc. of the 12th Latin-American Test Workshop. 2011. Pp. 1-6.
REFERENCES
1. Wile B., Goss J., Roesner W. Comprehensive Functional Verification: The Complete Industry Cycle, Morgan Kaufmann, 2005.
2. Bergeron J. Writing Testbenches: Functional Verification of HDL Models, Kluwer Academic, 2000.
3. Glasser M. Open Verification Methodology Cookbook, Springer, 2009.
4. Sen K., Rosu G. Generating Optimal Monitors for Extended Regular Expressions, Electronic Notes in Theoretical Computer Science, 2003, No. 89(2), Pp. 162- 181.
5. Ivannikov V., Kamkin A., Kossatchev A., Kuliamin V., Petrenko A. The Use of Contract Specifications for Representing Requirements and for Functional Testing of Hardware Models, Programming and Computer Software, 2007, No. 33(5), Pp. 272-282.
6. Barringer H., Rydeheard D., Havelund K. Rule Systems for Run-Time Monitoring: From Eagle to RuleR, In Proceedings of 7th International Workshop on Runtime Verification. Revised Selected Papers, 2007, Pp. 111-125.
7. Bauer A., Leucker M., Schallhart C. Runtime Verification for LTL and TLTL, ACM Transactions on Software Engineering and Methodology, 2011, No. 20(4), Pp. 14:1-14:64.
8. Mintz M., Ekendahl R. Hardware Verification with C++: A Practitioner's Handbook, Springer Science+Business Media, LLC, 2006.
9. Pratt V. The Pomset Model of Parallel Processes: Unifying the Temporal and the Spatial, In Seminar on Concurrency, 1984, Pp. 180-196.
10. Alur R., Dill D. A Theory of Timed Automata, Theoretical Computer Science, 1994, No. 126(2), Pp. 183-235.
11. Mazurkiewicz A. Trace Theory, In Advances in Petri Nets 1986, Part II on Petri Nets: Applications and Relationships to Other Models of Concurrency, New York, USA, Springer-Verlag, 1987, Pp. 279-324.
12. Chieu D., Hung D. Timed Traces and Their Applications in Specification and Verification of Distributed Real-time Systems, In Proceedings of the 3rd Symposium on Information and Communication Technology, 2012, Pp. 31-40.
13. Dijkstra E.W. Guarded Commands, Nondeterminacy and Formal Derivation of Programs, Communication of the ACM, 1975, No. 18(8), Pp. 453-457.
14. von Bochmann G., Haar S., Jard C., Jourdan G.V. Testing Systems Specified as Partial Order Input/Output Automata, In Proceedings of the 20th IFIP TC 6/WG 6.1 International Conference on Testing of Software and Communicating Systems: 8th International Workshop, 2008, Pp. 169-183.
15. Andres C., Merayo M., Nunez M. Formal Passive Testing of Timed Systems: Theory and Tools, Software Testing, Verification & Reliability, 2012, No. 22(6), Pp. 365-405.
16. Kuliamin V., Petrenko A., Pakoulin N., Kossatchev A., Bourdonov I. Integration of Functional and Timed Testing of Real-Time and Concurrent Systems, In Perspectives of System Informatics, 2003, Pp. 450-461.
17. ISPRAS: C++TESK Homepage. Available: http://forge.ispras.ru/projects/cpptesk-toolkit/
18. Chupilko M., Kamkin A. A TLM-Based Approach to Functional Verification of Hardware Components at Different Abstraction Levels, In Proceedings of the 12th Latin-American Test Workshop, 2011, Pp. 1-6.
4
ИВАННИКОВ Виктор Петрович — директор Института системного программирования РАН. 109004, Россия, Москва, ул. Александра Солженицына, д. 25. E-mail: ivan@ispras.ru
IVANNIKOV, Viktor P. Institute for System Programming of the Russian Academy of Sciences. 109004, Alexander Solzhenitsyn Str. 25, Moscow, Russia. E-mail: ivan@ispras.ru
КАМКИН Александр Сергеевич — старший научный сотрудник отдела технологий программирования Института системного программирования РАН. 109004, Россия, Москва, ул. Александра Солженицына, д. 25. E-mail: kamkin@ispras.ru
KAMKIN, Alexander S. Institute for System Programming of the Russian Academy of Sciences. 109004, Alexander Solzhenitsyn Str. 25, Moscow, Russia. E-mail: kamkin@ispras.ru
ЧУПИЛКО Михаил Михайлович — научный сотрудник отдела технологий программирования Института системного программирования РАН.
109004, Россия, Москва, ул. Александра Солженицына, д. 25. E-mail: chupilko@ispras.ru
CHUPILKO, Mikhail M. Institute for System Programming of the Russian Academy of Sciences. 109004, Alexander Solzhenitsyn Str. 25, Moscow, Russia. E-mail: chupilko@ispras.ru
© Санкт-Петербургский государственный политехнический университет, 2014
