CC BY
20
УДК 681.326:519.613
С.А. ЗАЙЧЕНКО, В.И. ХАХАНОВ
АСПЕКТЫ СИНХРОНИЗАЦИИ В СИСТЕМЕ ВЕРИФИКАЦИИ SYSTEM-ON-CHIP НА ОСНОВЕ ТЕМПОРАЛЬНЫХ АССЕРЦИЙ
Рассматриваются аспекты организации высокопроизводительной схемы синхронизации между HDL-симулятором и механизмом анализа ассерций. Уточняются ранее предложенные структуры данных и модель процесса анализа ассерций с учетом возможностей асинхронных прерываний и управления несколькими тактовыми сигналами. Демонстрируются возможности механизма анализа ассерций по верификации пересечений тактовых доменов SoC.
1. Введение
Методология функциональной верификации на основе ассерций (Assertions-Based Verification [1]), предложенная рядом ведущих компаний, представляющих мировую IT-индустрию (IBM, Synopsys, Cadence), в течение последних 5 лет стала неотъемлемой частью цикла проектирования систем на кристалле. Применение ассерций совместно с HDL-тестбенчем существенно повышает наблюдаемость функциональных нарушений, облегчает локализацию ошибок в модели, упрощает ее диагностику. Кроме того, использование ассерций формально документирует и систематизирует требования функциональной спецификации блоков, шин и протоколов [2].
Первое поколение стандартизированных языков описания ассерций, таких как PSL [3] и OpenVera Assertions [4], решило ряд серьезных проблем функциональной верификации:
- введена универсальная верификационная алгебра на базе операторов линейной темпоральной логики (LTL [5]), в равной степени пригодная для тестовых и для формальных методов функциональной верификации;
- сформулированы языковые средства описания типичных для цифровых систем логико-временных соотношений, одинаково выразительные как для инженера, так и систем верификации;
- предложен гибкий маршрут функциональной верификации, ориентированный на обнаружение большинства нарушений спецификации на ранних этапах проектирования, в основе которого лежат принципы инкапсуляции и повторного использования единиц верификации [6].
Дальнейшее развитие методология ассерций получила в новом языковом стандарте IEEE 1800-2005 SystemVerilog [7], призванном интегрировать в единый маршрут ранее разрозненные перспективные нововведения функциональной верификации последних лет: ассерции, объектно-ориентированные элементы тестбенча, транзакционное моделирование (TLM - Transaction-Level Modeling) [8], анализ функционального покрытия (CDV - coverage-driven verification) [9] и генерацию ограниченных псевдослучайных тестовых воздействий (CRV - constrained random verification) [10].
Среди набора функциональных проблем, эффективно разрешаемого на основе ассерций, особое место занимает задача верификации пересечений тактовых доменов (CDC - clock domain crossing) и эмуляции метастабильного состояния (metastability emulation) [11]. Проблемы сферы CDC типичны для ASIC-архитектур, реализующих системы на кристалле в сфере телекоммуникации и мультимедиа, где центральные и периферийные компоненты зачастую работают под управлением разных независимых тактовых сигналов. Маршрут верификации CDC включает автоматический синтез набора ассерций по результатам статического анализа модели (например, при помощи линт-технологий [12]). Синтезированные ассерции отражают функциональные требования к блокам-синхронизаторам и проверяют их стабильность с учетом внесенных на CDC-линии эмуляторов метастабильности (jitter).
В работах [13-15] была предложена модель DRTLQ (Dynamic Register Transfer Level Queues) для реализации анализа ассерций в рамках системы тестовой верификации (HDL-
симулятора), существенно превосходящая по производительности аналогичные решения на основе модели конечных автоматов. Ранее были описаны структуры данных и модель процесса анализа LTL-операторов, обеспечивающих линейную сложность времени вычислений и расходуемой оперативной памяти. В то же время немаловажным фактором, обеспечивающим высокую производительность предложенного решения, являются продуманные низкоуровневые механизмы взаимодействия анализатора ассерций с родительским HDL-симулятором.
В частности, ключевым аспектом интеграции с HDL-симулятором является синхронизация: механизм ассерций активируется под контролем симулятора в моменты возникновения тактовых событий. На производительность верификации в существенной мере влияют такие факторы как простота синхронизации, возможность быстрого сброса и управления состоянием ассерции со стороны тестбенча. Необходимость решения задач верификации CDC вносит ряд дополнительных сложностей по одновременному учету нескольких тактовых сигналов.
Цель исследования - разработка модели процесса синхронизации системы анализа ассерций и родительской верификационной среды, ориентированной на максимально возможное уменьшение накладных расходов на производительность взаимодействия компонентов. К задачам исследования относятся:
1) Анализ подсистемы планировки процессов в HDL-симуляторе, определение места ассерционных процессов в данном контексте, выработка методов оптимизации синхронизирующих нотификаций.
2) Уточнение структур данных модели DRLTQ для организации поддержки операторов прерывания.
3) Расширение модели DRTLQ, ориентированное на управление темпоральными свойствами и последовательностными функциями сразу несколькими тактовыми сигналами, тем самым обеспечивающее потребности верификации проблем CDC.
2. Схема синхронизации ассерций с родительской верификационной средой
Одним из ключевых элементов анализа темпоральных ассерций при динамической верификации SoC является схема синхронизации, под которой понимают событие или набор событий, активирующих работу ассерции. Схема синхронизации определяет моменты времени моделирования, при которых родительская верификационная среда - система моделирования (симуляции) SoC - передает управление непосредственно механизму анализа ассерций. Именно на систему-симулятор возлагается роль активного компонента, контролирующего порядок выполнения процессов, активации ассерций и других подчиненных механизмов верификации, увеличение текущего значения времени при отсутствии событий.
Центральным компонентом симулятора является планировщик процессов (process scheduler):
SCH = {P, A, S, f(p e P,s e S, X),g(p e P), 5(s e S), (1)
где SCH - планировщик процессов; p - множество процессов в симулируемой модели, состоящих из набора инструкций X^.Xn; A - список активных процессов; S - множество сигналов модели; f (p e P,s e S, X) - функция-признак чувствительности процесса от сигнала в конкретном процедурном контексте; g(p e P) - функция, возвращающая возможности влияния процесса на сигнал; 5(s e S) - функция, возвращающая множество процессов, которые являются чувствительными к сигналу.
Под процессом p понимают некоторый вычислительный блок, состоящий из набора инструкций Xj..Xn, считывающий значения входных сигналов s e S и преобразующий их в значения выходных сигналов g(p e P) за один или несколько шагов моделирования. С точки зрения пользователя, процессы - это взаимодействующие вычислительные потоки, обменивающиеся друг с другом информацией при помощи событий. Источником процессов являются описания на языках HDL/HVL. Существуют процессы с ярко выраженной процедурной семантикой, например процессы, порождаемые конструкциями initial и always в языке Verilog. Такие процессы выполняются пошагово, в полном соответствии с инструк-
циями A,j..Àn, указанными в исходном HDL-коде. Также существуют процессы, порождаемые конструкциями с декларативной семантикой, где вычислительное действие не задано в явном виде. Примером могут послужить вычислительные действия по распространению событий и активации других процессов, неявно подразумеваемые структурными связями между блоками модели.
События инициируются изменением значения сигналов. Процессы ô(s е S), реагирующие на изменение значения конкретного сигнала s, незамедлительно активируются в целях повторного вычисления собственных выходов. Под "незамедлительной активацией" имеется в виду установка процесса в конец очереди A на выполнение в текущий момент времени.
Семантика языков HDL такова, что процессы, активированные в один и тот же момент времени, должны выполняться параллельно. Если система-симулятор не предусматривает реального распараллеливания вычислительных задач между процессорами (такой функцией не обладает большинство современных систем моделирования), то фактически процессы выполняются по очереди. Непредсказуемый порядок псевдопараллельного выполнения конкурирующих процессов является типичным источником недетерминированности результатов моделирования и несовместимости различных реализаций между собой. Из-за неоднозначного порядка запуска процессов в модели могут возникать условия сигнальных гонок: в случае одновременного чтения и записи значения сигнала разными процессами порядок их выполнения определяет результаты моделирования.
Работу планировщика процессов можно изобразить следующим образом (рис. 1). Имеется некоторая очередь активных процессов A . В начале сессии симуляции в нее попадают все задекларированные процессы р. Процессы, представленные сгенерированным компилятором набором машинных инструкций A,j..Àn, один за другим выполняются симу-лятором. Выполнение процесса может быть остановлено симулятором либо в связи с завершением (остановка навсегда), либо временно в связи с запросом на ожидание синхронизирующего события самим процессом. Таким событием может быть изменение сигнала (по уровню, по одному из фронтов), а также заданный временной интервал. Остановленный процесс удаляется из очереди активных процессов для ожидания активирующего события. Выполняющийся процесс, в свою очередь, может изменять значения сигналов g(p) и тем самым активировать другие спящие и ожидающие этого изменения процессы.
Переключение активного процесса не происходит моментально. Каждый приостанавливаемый на время процесс должен сохранить полный набор значений задействованных им регистров процессора. Наиболее важным является регистр Instruction Pointer, указывающий на следующую инструкцию, которая будет запущена первой при повторной активации процесса. Поскольку каждый процесс может использовать некоторый объем памяти для временных переменных, то переключение также предполагает сохранение и восстановление содержимого стека.
Рис. 1. Схема работы планировщика процессов в HDL-симуляторе Следует также отметить невозможность переключения между процессами в любой момент. Если исполняемый код процесса не содержит каких-либо обращений к ядру симулятора, способных приостановить процесс (такие инструкции называют wait-инструк-
циями), то завершить такой процесс можно только грубым прерыванием. Подобная проблема существует во всех многозадачных операционных системах: если прикладная программа длительное время не запрашивает системных ресурсов у операционной системы, то остановить такую программу можно только физическим прерыванием.
Скорость работы планировщика процессов во многом определяется структурами данных, ассоциирующими сигналы с набором чувствительных к ним процессов. Такая информация о чувствительности процессов (process sensitivity) к сигналам подготавливается статически (во время компиляции). Чувствительность разделяют на два типа: статическую - процесс всегда реагирует на данное событие (независимо от текущей инструкции X), а также динамическую - процесс может реагировать на данное событие, если его выполнение достигло определенного процедурного контекста (в рамках некоторой пары инструкций Xj..Xn), и не реагировать на событие за пределами контекста.
Не все процессы в рамках одного момента времени моделирования имеют равные приоритеты на выполнение. В соответствии со стандартом языка SystemVerilog планировщик процессов разделяет очередь на ряд упорядоченных сегментов:
А — /„preponed active postponed ^ (2)
A - {pi..i ,'" p1..i ,'" ,pi..i /•
В рамках каждого из сегментов очереди процессы равноправны и выполняются в порядке регистрации в очереди. Новый сегмент не начинается до завершения всех процессов вышестоящего сегмента. В результате выполнения процесса могут быть активированы другие процессы, как в последующие моменты времени (тайм-слоты), так и в том же тайм-слоте, что и инициирующий процесс. Нижестоящий сегмент может инициировать запуск процесса в более приоритетном сегменте, за исключением сегментов Preponed и Postponed (рис. 2).
Такой широкий набор возможностей синхронизации и активации процессов создает определенные технические трудности для управления системы анализа ассерций. В простейшем наиболее распространенном случае активация ассерции связывается с событиями тактовых сигналов (posedge clk):
check_progress : assert property ( @(posedge clk) (valid_in && !stall) ##1 (!stall[->3]) |-> ##1 f3 ); Для обеспечения синхронизации между родительской системой-симулятором и системой анализа ассерций в модели DRTLQ для каждого монитора создается неявный синхронизирующий процесс, инструкциями которого являются X вызовы процедур системы анализа ассерций:
// Waiting for assertion activation event always @(posedge clk)
// Executing assertions kernel analysis with internal statement $AssertionRun(assertion_process); Семантика языков описания ассерций такова, что более чем одна активация анализа темпоральных элементов без изменения значения времени моделирования является недопустимой. Необходимо гарантировать невозможность повторной активации в рамках одного момента времени. Во-первых, синхронизирующего события не должно произойти дважды за один такт. Во-вторых, непосредственный процесс анализа ассерции не должен привести к инициированию других процессов в том же тайм-слоте (такая активация теоретически возможна при наличии определенной пользователем реагирующей инструкции (action block) на результат вычисления ассерции). Таким требованиям может удовлетворить лишь сегмент Postponed, помещение анализа ассерции в который обеспечивает отсутствие неоднозначностей, вызванных сигнальными гонками:
// Waiting for assertion activation event: reacting in Postponed region always @(posedge clk) postponed
// Executing assertions kernel analysis with internal statement $AssertionRun(assertion_process); Выполнение в сегменте Postponed накладывает определенные ограничения на инструкции, допустимые в action block. В частности, такие инструкции не имеют права изменять значения сигналов, вызывающих активацию других процессов. Допустимы лишь присвое-
from previous-time slot
1«-----time slot-----► ния пассивных сигналов, что мо-
жет быть необходимо для управления ходом моделирования с учетом результатов выполнения ассер-ции.
Хотя помещение ассерционного процесса в сегмент Postponed решает проблемы, связанные с преждевременным запуском процесса анализа ассерции, вероятность возникновения сигнальных гонок по-прежнему может повлиять на результат верификации. Если изменение сигнала, находящегося под наблюдением ассерционного монитора, происходит одновременно с контролирующим ассерцию событием, то датчик данного сигнала (signal sampler) [14] может считать одно из нескольких возможных значений, в зависимости от момента чтения. Более сложной ситуацией является считывание датчика при одновременном изменении (как в разных, так и в тех же сегментах очереди процесса) значения сигнала несколькими процессами.
В модели DRTLQ, во избежание неоднозначности, считывание входных значений осуществляется не напрямую из памяти сигнала, а из предварительно подготовленного буфера. Буфер не является сигналом (не имеет связанных с ним чувствительных процессов), и копирование небольшого блока памяти со значением сигнала происходит достаточно быстро. Блок инструкций, копирующий значения наблюдаемых ассерциями сигналов в буфере, помещается в специальный процесс, выполняющийся в регионе Preponed (рис. 3). Безусловно, такая предварительная буферизация несколько негативно влияет на производительность, однако такой подход обеспечивает удовлетворение более приоритетного функционального требования по однозначности результатов верификации.
\
4-Г reactive
i
4-f re-ínactive
^ posponed
to next
time slot -►
Рис. 2. Сегменты очереди процессов в рамках одного момента времени в SystemVerilog
Рис. 3. Разрешение неоднозначности считывания сигналов при помощи Preponed-буфера При наличии сразу нескольких ассерций, активирующихся по эквивалентному событию, имеет смысл осуществить их слияние в единственный процесс с соответствующей схемой
синхронизации. При этом активация ассерций может происходить последовательно, поскольку порядок вычисления ассерций относительно друг друга не имеет никакого значения:
always @(posedge clk) postponed $AssertionRun(assertion_process1) ,
always @(posedge clk) postponed $AssertionRun(assertion_process2) ,
always @(posedge clk) postponed begin
=> $AssertionRun(assertion_process1) , $AssertionRun(assertion_process2) , end
Выгода такого преобразования с точки зрения производительности очевидна исходя из (3), и положительный эффект усиливается с увеличением количества ассерций, группируемых в один процесс:
N х V = N х (tp + ta),tapN = tp + N x ta ^ N x tap1 > tapN , (3)
где n - количество ассерций с одинаковым синхронизирующим событием; tp - время активации процесса (включает реакцию симулятора на событие, переключение контекста выполнения на процесс и восстановление регистров); ta- время анализа одной ассер-
ции; tapi - суммарное время выполнения одиночного ассерционного процесса; tapN - суммарное время выполнения сгруппированного ассерционного процесса.
Лишь в простейших случаях темпоральные ассерции не используют никакой другой схемы синхронизации, за исключением одного тактового сигнала. Достаточно часто в схему синхронизации ассерции включается условие сброса (disable iff), при срабатывании которого должны прерываться все начатые ассерцией вычислительные потоки:
check_progress : assert property ( @(posedge clk) disable iff (-reset) (valid_in && !stall) ##1 (!stall[->3]) |-> ##1 f3 );
В зависимости от языка описания ассерций - SystemVerilog Assertions, PSL, OpenVera Assertions - условия сброса могут быть как синхронными тактовому сигналу, так и асинхронными относительно основного события. Асинхронные условия прерывания (конструкция async_abort в языке PSL) реализуются отдельным дополнительным процессом:
proc_reset: begin
always @(negedge reset) postponed_0
$AssertionReset(assertion_process) ; $KillProcessSchedule(proc_main);
end
proc_main: always @(posedge clk) postponed $Ass ertionRun(assertion_process);
Специально для реализации условий асинхронного сброса ассерций в родительской верификационной среде (симулятор Riviera компании Aldec Inc. [16]) был введен дополнительный сегмент в очереди процессов - Postponed-0, обладающий всеми свойствами Postponed-сегмента, но выполняющийся перед сегментом Postponed. Такое расширение необходимо для корректной обработки ситуации одновременного срабатывания условия сброса и тактового события. Согласно официальным разъяснениям комитета IEEE Computer Society к стандарту языка PSL [17], корректной реакцией системы анализа ассерций на подобную ситуацию является выполнение сброса и отмена выполнения основного цикла анализа ассерции.
Без расширения Postponed-0 в HDL-симуляторе реализация асинхронных условий прерывания могла бы выглядеть следующим образом:
always @(posedge clk or negedge reset) postponed
begin
if (~reset)
$AssertionReset(assertion_process);
else
$AssertionRun(assertion_process);
end
Преимущество введенного расширения симулятора - сегмента Postponed-0 - заключается в устранении условной инструкции. На первый взгляд, это преимущество неочевидно. Однако следует учесть влияние ряда факторов, мотивирующих выбранное решение:
- реализация очереди процессов в конкретном родительском симуляторе такова, что стоимость добавления дополнительного сегмента ничтожно мала; существует незначительное влияние на фазе инициализации симуляции, однако нет никакого негативного влияния на производительность на фазе выполнения процессов;
- возможность разового приостановления процесса, стоящего в очереди в ближайшем тайм-слоте (процедура $KillProcessSchedule), также имеет ничтожно малую стоимость в выбранном симуляторе (сводится к установлению флага), по сравнению с экономией на отмене переключения контекста ненужного процесса;
- частота срабатывания условия сброса в реальных проектах намного меньше частоты тактовых событий; отказ от условной конструкции дает выигрыш в типичной ситуации (нет сброса), причем это не малый выигрыш, учитывая особенности конвейерной архитектуры микропроцессоров, в частности систему предсказания переходов [18].
Иначе обстоит ситуация с реализацией синхронных условий прерывания. В синхронном случае по определению нет проблемы конкурентности сброса и основного тактового сигнала. Также неизбежен условный переход, определяющий выполняемую процедуру:
always @(posedge clk) postponed
begin
if (~reset)
$AssertionReset(assertion_process) ;
else
$Ass ertionRun(assertion_process);
end
С учетом возможных условий сброса видоизменяется ранее предложенная оптимизация по группировке нескольких ассерций в единый процесс. Группировать можно лишь процессы, у которых полностью совпадают как основное тактовое событие, так и условие сброса. Предположим, имеется ассерция A1 с тактовым событием "posedge clk" и условием асинхронного сброса "-reset", а также ассерция А2 с тактовым событием "posedge clk", но без условия сброса. Событийная сигнатура процессов основного цикла ассерций A1 и A2 совпадает (событие "posedge clk"), однако группировать такие процессы в один нельзя. Асинхронное прерывание "-reset" может отменить запуск процесса с основным циклом обработки ассерции А1, и тем самым, отменит анализ ассерции А2, что не является корректным. Напротив, если условие "-reset" будет синхронным, группировка ассерций A1 и A2 является уместной:
always @(posedge clk) postponed begin
if (-reset)
$AssertionReset(assertion_process_A1);
else
$AssertionRun(assertion_process_A1);
$AssertionRun(assertion_process_A2) ;
end
3. Реализация прерывания анализа ассерции в модели DRTLQ
В работе [14] в модели DRTLQ было сформулировано понятие ассерционного процесса, реализующего верификацию логически связанных логико-временных утверждений в процессе моделирования:
AP = {B, E, F, P, M} , (4)
где AP - ассерционный процесс; B - множество верификационных переменных; E -множество текущих обрабатываемых событий; F - список последовательностью функций; P - множество темпоральных свойств; M - ассерционный монитор. Также было введено понятие последовательностной функции f е F, представляющей собой некоторую вычислительную процедуру, которая характеризуется множествами входных, внутренних и выходных событий и осуществляет их пошаговое преобразование от входов к выходам на каждом тактовом цикле верификации.
Процесс анализа одного вычислительного потока ассерции (т.е. продвижение событий от входных переменных к монитору) может занимать несколько тактовых циклов. Ассер-ция, благодаря конвейерной организации вычислений, может анализировать сразу несколько пересекающихся вычислительных потоков. Среди набора последовательностных функций, в контексте рассматриваемой в данной статье задачи следует выделить очереди и репетиции. Именно эти функции являются своеобразными элементами памяти в модели DRTLQ, поскольку только они характеризуются множествами внутренних событий и обработкой события в течение нескольких тактовых циклов. Все другие последовательностью функции преобразовывают входные множества событий в выходные за один шаг.
Задача прерывания ассерции влечет за собой завершение стартовавших вычислительных потоков, для чего требуется уничтожение всех порожденных процессом событий e е E . События, время жизни которых превышает один такт, хранятся только в ограниченном наборе элементов модели, а именно внутри элементов очередей и репетиции. Полное сканирование элементов модели в целях уничтожения событий не рационально, так как типичное число очередей и репетиций не превышает j от числа всех элементов. Лучшее решение состоит в добавлении дополнительного списка последовательностных функций, подлежащих быстрому сканированию в ситуации прерывания ассерции. Однако введение такого дополнительного списка последовательностных функций не имеет смысла в ассер-ционных процессах, для которых на уровне исходных языковых описаний не предусмотрено возможности асинхронного или синхронного прерывания.
Для обеспечения операции сброса введем понятие прерываемого ассерционного процесса (abortable assertion process):
APa = {B,E,F,Fa е F,P,Ma}, (5)
расширяющего ассерционный процесс интересующим списком fa прерываемых после-довательностных функций, а также имеющего специальный вид монитора, учитывающего возможности прерывания.
В простейшем случае вычислительные потоки просто уничтожаются. Существует также отладочный режим прерывания, при котором расширенный ассерционный монитор M A сообщает об осуществленной операции специальным диагностическим сообщением:
KERNEL: Warning: Assertion ABORTED at time: 367ns, start-time: 350ns (4 clk)
KERNEL: Warning: Assertion ABORTED at time: 367ns, start-time: 250ns (з clk)
KERNEL: Warning: Assertion ABORTED at time: 367ns, start-time: 150ns (2 clk)
Очереди и репетиции, составляющие список FA, также заменяются расширенными прерываемыми вариантами: реализация прерывания требует не просто уничтожить внутренние множества событий, но и предварительно транспортировать их непосредственно
монитору ma, сигнализирующему окружению о прерывании вычислительного потока. Обычным (не прерываемым) последовательностным функциям не требуется такая прямая связь с монитором для реализации вычислительных процедур. Монитор, обработав событие, уничтожает всю связанную с ним цепочку активации, т.е. все события, соответствующие одному вычислительному пути с учетом возможных разветвлений.
Оповещение родительской среды о прерывании ассерции не ограничивается приведенным выше диагностическим сообщением в отладочном режиме. Жизненный цикл каждого вычислительного пути отслеживается, и событие прерывания отражается на таких компонентах, стоящих за пределами системы анализа ассерций, как:
- временные диаграммы, наглядно визуализирующие состояние анализа ассерций;
- анализатор активации ассерций, оценивающий степень покрытия функциональных требований сгенерированными тестовыми воздействиями;
- база данных событий симуляции, предназначенная для осуществления отложенного анализа результатов (post-simulation debug);
- точки прерывания симуляции (breakpoints).
Более сложным случаем является сочетание операций прерывания с элементами после-довательностной импликации:
assert property ( @(posedge clk) disable iff (-rst) (req ##3 ack)|=> busy [*3:7] );
В приведенном примере имеется один элемент-очередь и один элемент-репетиция. В случае срабатывания условия сброса необходимо сканировать именно эти элементы. Однако элемент-очередь размещен в левой части импликации. В данном контексте нельзя утверждать о прерывании анализа вычислительного потока, поскольку поток фактически активируется лишь после транспортирования через элемент импликации (|=>). В данном случае семантика прерывания анализа отличается от описанного выше, и множества внутренних событий достаточно уничтожить без оповещения среды.
Прерываемым последовательностным функциям нет необходимости варьировать собственное поведение в зависимости от контекста. Различие принципа обработки - уничтожение с оповещением и без оповещения - должно обрабатываться самим контекстом. Прерываемая функция, дополнительно к основной функциональности, содержит лишь связь с элементом, обрабатывающим транспортирование прерываемых событий. Как монитор
MA, так и элемент-импликация, уничтожают цепочку событий, однако импликация не производит никаких оповещений внешней среды, так как поток вычислений еще не достиг точки активации.
Возможность поддержки асинхронного прерывания требует определенных расширений также в предложенном в работе [15] принципе интерпретации LTL-формул глобального времени. В (6) представлена формальная семантика оператора асинхронного прерывания в применении к темпоральным свойствам глобального времени:
п |=c f async_abort b ^ (п |=c f) | (Vk,0 < k < |п|, nk |= b,п0^-1 |=c f), (6)
где п - некоторый вычислительный путь; b - булево условие асинхронного прерывания; f -дочернее темпоральное свойство; k - некоторое число, разделяющее вычислительный путь на часть до и после момента асинхронного прерывания. Формула с условием асинхронного прерывания может быть полностью удовлетворена (holds tightly) на вычислительном пути п с тактовым событием с в двух случаях:
- формула полностью удовлетворена на этом вычислительном пути без прерывания, и событие прерывания не наступило;
- событие прерывания происходит, и в этот момент формула находится в незавершенном состоянии (т.е. удовлетворенность не установлена на прошедшей части вычислительного пути, но может быть установлена при дальнейшем расширении).
Семантика оператора синхронного прерывания отличается от асинхронного незначительно:
п c f sync_abort b ^ (п c f) | (Vk,0 < k < |п|, пk |= b л c, п0^-11=c f), (7)
основным различием является невозможность самостоятельного влияния условия прерывания - оно может быть учтено только в том случае, если оно справедливо в момент тактового события.
Если формула, использующая условия прерывания, находится на вершине иерархии ассерционного процесса, различий между режимом интерпретации глобального времени и обычным режимом не отмечается. В простом подмножестве ассерционных конструкций [1,3,17] помещение оператора прерывания на вершину является единственно допустимым контекстом. Напротив, в режиме глобального времени прерываемое темпоральное свойство может быть помещено в глубине иерархии. Например:
default clock = posedge clk;
property pi = ( (reql -> eventually! ack) async_abort cancell);
property p2 = ( (req2 -> busy[*3:5]) async_abort cancel2;
assert always (pi && p2);
Если произойдет асинхронное прерывание свойстваp2, не должно произойти фактической отмены анализа ассерции, как это происходит в обычном режиме интерпретации формул. Напротив, все стартовавшие вычислительные потоки свойстваp2 будут досрочно завершены, причем с успешным результатом в соотвествии с (6). В то же время работа
ассерционного процесса продолжится под управлением темпорального свойства & &, которое будет дожидаться результатов вычислительных потоков дочернего свойства p1. Разумеется, в данном примере ассерция будет признана неудовлетворенной и полностью остановит свою работу, если хотя бы один из вычислительных путей pi или p2 даст отрицательный результат.
В режиме глобального времени статус завершения ABORTED может получить лишь та ассерция, у которой на вершине иерархии стоит оператор прерывания. Во всех остальных случаях прерывание интерпретируется как успешное завершение анализа формулы.
4. Анализ темпоральных свойств с несколькими тактовыми сигналами в
DRTLQ
Для современных систем-на-кристалле типичной ситуацией является наличие нескольких независимых тактовых доменов. Под тактовым доменом понимают часть устройства, синхронизируемую одним тактовым сигналом либо семейством сигналов, кратных или противофазных одному тактовому сигналу. Прямой обмен данными между частями системы, синхронизируемыми разными тактовыми сигналами, может привести к так называемому метастабильному состоянию [11]. Источником проблемы на аппаратном уровне является низкоуровневое поведение триггера, предполагающего, что в течение определенного интервала до, во время и после управляющего импульса уровень входного сигнала останется стабильным. На рис. 4 представлена типичная проблемная ситуация между тактовыми доменами. Если во время фронта CLK B сигнал DA будет изменяться (под влиянием тактового домена CLK A), то значение сигнала DB некоторое время не будет стабильным и предсказуемым.
D F DA F DB
CLK А >
CLK А DA ■
CLK В ■
CLK В
/
\
DB
Clacked signal DB Is Initially metastable
L
«1 1
CLK В
samples DA while It Is changing
...and might still be metastable at the next rising edge of CLK В
Рис. 4. Иллюстрация проблемы метастабильности сигналов на пересечении тактовых доменов Задачи верификации проблем синхронизации тактовых доменов обуславливают необходимость поддержки свойств и последовательностей с несколькими тактовыми сигналами в рамках механизма анализа ассерций. Ситуацию на рис. 4 можно было бы описать PSL-ассерциями, проверяющими стабильность данных при передаче между доменами в момент изменения граничного сигнала:
assert property ({DA;-DA})@(posedge clka) | => (PREV(DB) && ~DB) @(posedge clkb); assert property ({-DA;DA})@(posedge clka) | => (-PREV(DB) && DB) @(posedge clkb);
В (8) представлена формальная семантика оператора последовательностной импликации, операнды которого управляются различными тактовыми сигналами:
пИ (fc1 H gc2) HVk,0 < k <|п|, пш Иc1 f, пk.. Иc2 g. (8)
Ассерционные процессы, обрабатывающие темпоральные свойства с несколькими тактовыми сигналами, имеют составную структуру (9). Каждый из тактовых доменов представлен собственным набором верификационных переменных, событий и последователь-ностных функций, в то время как множество темпоральных свойств и монитор остаются общими и независимыми от конкретного тактового домена:
APmclk = {{B,E, F}CLK1, - ••, {B,E, F}clkn ,P,M} . (9)
Тройка{B, E, F} называется тактовым ассерционным субпроцессом. Все элементы тройки ассоциируются с одним конкретным тактовым доменом:
- верификационные переменные считывают значения связанных с ними сигналов и булевых выражений по тактовому событию; если один и тот же сигнал участвует в частях формулы, управляемых разными тактовыми сигналами, он представляется в процессе сразу несколькими верификационными переменными - по одной в каждом субпроцессе, считывающем сигнал;
- события связаны с тактовым сигналом непосредственно: одним из атрибутов события является число пройденных от начала моделирования тактов;
- последовательностные функции присутствуют в очереди примитивов, принадлежащей субпроцессу, исполняемой в момент тактового события.
Для каждого из доменов, задействованных в ассерции, в симуляторе создается отдельный процесс:
always @(posedge clka) postponed
begin
$AssertionSubprocessRun(assertion_process, subprocess_a);
end
always @(posedge clkb) postponed
begin
$AssertionSubprocessRun(assertion_process, subprocess_b);
end
В контексте ассерций с несколькими тактовыми доменами остается в силе возможность группирующей оптимизации синхронизирующих процессов. Каждый из доменных процессов можно группировать с другими при совпадении событийной сигнатуры. В том числе группировка возможна с процессами ассерций одного домена - совпадение синхронизирующего события является достаточным условием.
Темпоральные свойства и монитор, напротив, не связаны ни с одним доменом. Обработка свойств и монитора происходит не через очередь примитивов, как это обстоит с элементами субпроцесса, а по принципу удовлетворения запросов. Запросы, такие как реакция на завершение последовательности, инициируются элементами уровня субпроцесса. Фактически, работа темпоральных свойств и монитора происходит по тактовому событию, однако момент зависит не от свойств и мониторов, а от элемента-инициатора. Например:
property pi = {a; b; c} @ (posedge clkl) ; property p2 = {d; e; f} @ (posedge clk2) ; assert pi && p2;
Темпоральное свойство & & и вышестоящий монитор не зависят от конкретного тактового домена "posedge clk1" или "posedge clk2". Они реагируют на события, инициируемые последовательностями, относящимися к конкретным субпроцессам. Однако нельзя предугадать, какой именно из субпроцессов определит результат свойства. Относительный
порядок возникновения тактовых событий не известен. Также в любой момент провал одной из последовательностей определит исход верификации свойства.
Несколько тактовых доменов создают дополнительные сложности для реализации асинхронного прерывания. Рассматриваются два принципиально различных случая. Во-первых, условие асинхронного сброса может быть связано с конкретным субпроцессом:
property pi = {req; [*2:5]; ack} async_abort (~rst) @(posedge clkl); property p2 = {req; data != prev(data) } | => eventually! (ready) @(posedge clk2); assert always pi && p2;
В таком случае прерывание не интерпретируется как отмена анализа ассерции, а напротив, в соответствии с (6), как успешное досрочное срабатывание свойства p1. Такое досрочное завершение инициируется отдельным процессом с асинхронным событием. Схема синхронизации для данного случая выглядит следующим образом:
always @(posedge clki) postponed begin
$AssertionSubprocessRun(assertion_process, subprocess_i);
end
always @(negedge rst) postponed_0 begin
$AssertionSubprocessReset(assertion_process, subprocess_i);
end
always @(posedge clkb) postponed begin
$AssertionSubprocessRun(assertion_process, subprocess_2);
end
Во-вторых, условие асинхронного прерывания может быть связано с уровнем темпоральных свойств. В таком случае также создается отдельный процесс, инициирующий прерывание. Результат зависит от уровня прерываемого свойства в иерархии формулы. Только если это свойство находится на вершине формулы, это приведет к фактическому досрочному завершению анализа с соответствующим выходным статусом ABORTED.
Следует также отметить, что выходные сообщения системы анализа ассерций отличаются для процессов, зависящих от нескольких тактовых сигналов, по сравнению с ассерци-ями одного домена - по очевидной причине в сообщении отсутствует число тактов: KERNEL: Warning: Assertion FAILED at time: 370ns, start-time: 240ns.
5. Выводы
Полноценный и эффективный ответ на задачи и риски современного цикла проектирования и верификации систем на кристаллах состоит в рациональном применении широкого набора различных методов и автоматизированных программных систем для верификации, предоставляемых компаниями EDA-индустрии. Принципиально важными критериями выбора дорогостоящих EDA-систем являются такие факторы как:
- предоставление гибкого набора верификационной функциональности, совместимого с международными стандартами;
- отказоустойчивость программного обеспечения и высокая производительность вычислений;
- продуманность маршрута использования различных методов верификации, заложенная в продукт (в виде графического/batch-интерфейса, набора примеров и качественной документации).
В статье рассмотрены аспекты синхронизации системы анализа ассерций с родительской верификационной средой - HDL-симулятором. Синхронизация, как граничный процесс между различными компонентами рассматриваемого программного комплекса, во многом является фактором, определяющим производительность верификации в целом. Организация корректной и эффективной схемы синхронизации также является необходимой составляющей для решения сложных актуальных задач верификации пересечений нескольких тактовых доменов.
В ходе исследования были решены следующие поставленные задачи:
1) Был произведен анализ подсистемы планировки процессов в HDL-симуляторе, определено место синхронизирующих ассерционных процессов в контексте компонента-планировщика. На основе принятого архитектурного решения о синхронизации программных компонентов были выработаны и сформулированы низкоуровневые программные оптимизации производительности нотификаций.
2) В целях поддержки операторов прерывания анализа ассерций были уточнены структуры данных модели DRTLQ. Уточнение обеспечивает не только высокую производительность операции сброса ассерции в начальное состояние, но и достаточную информативность диагностических отчетов.
3) В связи с необходимостью поддержки средств верификации CDC-проблем (пересечения тактовых доменов), модель DRTLQ были введены расширения (тактовые ассерци-онные субпроцессы), ориентированные на управление темпоральными свойствами и после-довательностными функциями сразу несколькими тактовыми сигналами.
Главный научный результат исследования состоит в усовершенствовании ранее предложенных моделей и методов функциональной верификации систем на кристаллах на основе темпоральных ассерций, открывающих путь для автоматизации маршрутов проектирования и диагностики систем на кристаллах со сложной схемой синхронизации.
Ключевым практическим результатом исследования является улучшение системы анализа ассерций и усовершенствование принципов ее синхронизации с родительской верификационной средой, делающие предлагаемое решение функционально гибким и высокопроизводительным, а значит, востребованным и конкурентоспособным на рынке EDA.
Список литературы: 1. Foster H., Krolnik A., Lacey D. Assertions-based Design // Kluwer Academic Publishers, 2003. 392p. 2. Dellacherie S. Automatic Bus-Protocol Verification Using Assertions // Proceedings of GSPx-2004. 6 p. 3. IEEE-1850 "IEEE Standard for Property Specification Language (PSL)", 2005. 143p. 4. OpenVera Language Reference Manual: Assertions // Version 1.4.1, Synopsys Inc. 2004. 136 p. 5. Emerson E.A. Temporal and modal logic // In J. Van Leeuwen, editor, "Handbook of Theoretical Computer Science", Elsevier Science Publishers, 1990, volume B. Р. 996-1072. 6. Dahan A., Geist D., Gluhovsky L., Pidan D., Shapir G., Wolfsthal Y., Benalycherif L., Kamdem R., Lahbib Y. Combining System Level Modeling with Assertion Based Verification", Sixth International Symposium on Quality of Electronic Design (ISQED'05). Р. 310-315. 7. IEEE-1800 "IEEE Standard for System Verilog Language". 2005. 586p. 8. Habibi A., Tahar S., Samarah A., Donglin Li, Mohamed O.A. Efficient Assertion Based Verification using TLM // DATE'2006. Р. 33-38. 9. Ziv A. Cross-Product Functional Coverage Measurement with Temporal Properties-based Assertions // DATE'2003. Р. 10834-10839. 10. Yuan J., Pixley C., Aziz A., Albin K. A Framework for Constrained Functional Verification", ICCAD'2003, pp. 142-145. 11. R. Ginosar "Fourteen Ways to Fool Your Synchronizer", ASYNC'03. Р. 89-96. 12. YaromI., Patil V."Smart-Lint: Improving the Verification Flow", Proceedings of Haifa Verification Conference 2006. Р. 81-91. 13. ForczekM, HrynkiewiczK. "Formal properties evaluation", Proceedings of Programmable Devices and Systems Workshop 2003 (PDS-2003). Р.305-311. 14. Хаханов В. И., Зайченко С. А. Модель динамических регистровых очередей для быстродействующего анализа линейных темпоральных ограничений // АСУ и приборы автоматики .№136-2007. С. 10-25. 15. Зайченко С. А., Хаханов В. И. Эффективная функциональная верификация моделей цифровых систем на кристалле на основе ассерций глобального времени // АСУ и приборы автоматики .№137-2007. С. 4-13. 16. "Riviera-PRO Product Overview", http://www.aldec.com/products/riviera, доступно с экрана. 17. Havlicek J., Fisman D., Eisner C. Basic Results on the Semantics of Accellera PSL 1.1 Foundation Language // Accellera Technical Report. 2004. 57p. 18. PaulR. "SPARC architecture, assembly language, programming and C"//Prentice Hall. 1994. 464p.
Поступила в редколлегию 29.12.2007 Зайченко Сергей Александрович, аспирант кафедры АПВТ ХНУРЭ, начальник отдела разработки компании Aldec-Kharkov Ltd. Научные интересы: системы автоматизированного проектирования, моделирования и верификации цифровых систем на кристаллах. Увлечения: литература, музыка, футбол. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. (097)-367-62-93. E-mail: Sergei.Zaychenko@aldec.com
Хаханов Владимир Иванович, декан факультета КИУ ХНУРЭ, д-р техн. наук, профессор кафедры АПВТ ХНУРЭ. Научные интересы: техническая диагностика цифровых систем, сетей и программных продуктов. Увлечения: баскетбол, футбол, горные лыжи. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. (057)-702-13-26. E-mail: hahanov@kture.kharkov.ua
