Содержание к диссертации
Введение
1 Обзор методов и средств функциональной верификации и встроенного функцио нального мониторинга СнК 11
1.1 Введение 11
1.2 Технологическая цепочка проектирования СнК 11
1.2.1 Особенности процесса проектирования СнК 11
1.2.2 Ошибки процесса проектирования реализации и эксплуатации 14
1.3 Эффективность современных методов и средств функциональной верификации СнК 16
1.3.1 Задача функциональной верификации СнК 16
1.3.2 Анализ современных методов и средств функциональной верификации 18
1.4 Функциональный мониторинг СнК 22
1.4.1 Задача функционального мониторинга 22
1.4.2 Методы анализа результатов мониторинга 24
1.5 Встроенный функциональный мониторинг СнК 26
1.5.1 Классификация и критика существующих средств встроенного мониторинга 26
1.5.2 Средства автоматизации проектирования подсистемы функционального мониторинга 29
1.6 Выводы 30
1.7 Постановка задачи 31
2 Метод встроенного функционального мониторинга с динамической актуализацией модели поведения 33
2.1 Введение 33
2.2 Структура метода 33
2.3 Выбор математической модели для описания поведения вычислительного процесса 36
2.3.1 Правила спецификации алгоритма взаимодействия процессов 36
2.3.2 Правила спецификации алгоритма функционирования процессов 37
2.4 Разработка алгоритма динамической актуализации модели поведения 39
2.4.1 Задача наблюдения за функционированием процесса 39
2.4.2 Выделение состояний процесса на основе последовательности произошедших событий
2.4.3 Выделение состояний процесса на основе фактов произошедших событий 44
2.4.4 Выделение состояний процесса на основе структуры модели ожидаемого поведения 45
2.4.5 Профиль наблюдения за функционированием процесса 49
2.5 Анализ актуализированной модели поведения 52
2.5.1 Базовый метод анализа актуализированной модели 52
2.5.2 Определение вероятностных и временных характеристик процесса 56
2.6 Выводы 59
3 Разработка методов и средств автоматизации синтеза системы функционального мониторинга СнК 61
3.1 Введение 61
3.2 Технология автоматизированного синтеза системы функционального мониторинга 61
3.3 Микроархитектура встроенного монитора с динамической актуализацией модели поведения 65
3.3.1 Обобщенная структура монитора 65
3.3.2 Блоки захвата и арбитража событий 67
3.3.3 Блок обработки событий 69
3.3.4 Надежность монитора 74
3.4 Синтез блоков мониторов из высокоуровневого описания модели ожидаемого поведения 74
3.5 Выводы 78
4 Практика встроенного функционального мониторинга СнК 80
4.1 Введение 80
4.2 Сферы применения метода 80
4.3 Система функционального мониторинга для СнК цифровой обработки быстрых радиосвязных сигналов 81
4.4 Система функционального мониторинга для унифицированной информационно-измерительной платформы СнК 84
4.5 Выводы 86
Заключение 87
Список сокращений и условных обозначений 89
Список литературы
- Эффективность современных методов и средств функциональной верификации СнК
- Правила спецификации алгоритма функционирования процессов
- Микроархитектура встроенного монитора с динамической актуализацией модели поведения
- Система функционального мониторинга для унифицированной информационно-измерительной платформы СнК
Эффективность современных методов и средств функциональной верификации СнК
Современные системы автоматизированного проектирования (САПР) фирм Synopsys, Cadence, Mentor Graphics, Xilinx, Altera содержат инструменты для автоматизации процесса трансляции моделей системы между разными уровнями абстракции: уровнем регистровых пересылок (register transfer level, RTL), логическим и уровнем топологии (в рамках стандартного техпроцесса). Процесс трансляции моделей данных уровней хорошо формализован и требует от разработчика минимального участия.
Сегодня существуют также средства высокоуровневого синтеза (High-Level Synthesis, HLS) [2], осуществляющие преобразование высокоуровневых моделей до уровня RTL и дальше до уровня топологии. К таким средствам относятся программные продукты Co-Silicon Compiler (Cadence), Catapult С (Calypto Design Systems), Synphony Model Compiler (Synopsys), Vivado HLS (Xilinx) [3]. Данные средства имеют ограниченную сферу применения и обычно используются для синтеза блоков цифровой обработки сигналов, а также подсистем потоковой обработки данных из описания логики их работы с помощью языков C/C++, Matlab. Ограниченная сфера применения средств HLS обуславливается отсутствием эффективных методов преобразования высокоуровневых моделей.
Переход с более высокого уровня абстракции на более низкий является многовариантным, в то время как критерий выбора лучшего варианта еще недостаточно формализован. С целью уменьшения размерности задачи на отдельных этапах проектирования разработчики делают выбор в пользу использования либо готовых СФ-блоков (component-based design) [1,4], либо проверенной вычислительной платформы (platform-based design) [5].
Проектирование на базе готовых СФ-блоков позволяет абстрагироваться от задач синтеза конкретной внутренней микроархитектуры узлов системы и сосредоточиться на организации взаимодействия между ними. Выбор конкретного узла осуществляется по функции, которую он исполняет и его характеристикам. К текущему моменту существует множество библиотек готовых СФ-блоков и накоплен огромный опыт их использования. Большинство таких СФ-блоков являются интеллектуальной собственность (IP-ядра) компаний-разработчиков и поставляются без описания микроархитектуры, то есть в виде «черного ящика». Внедряя их в свою систему, разработчик получает определенные гарантии относительно качества результатов их работы. В настоящее время разработан ряд стандартов на интерфейсы сопряжения СФ-блоков СнК, что позволит снизить затраты на интеграцию новых блоков в систему.
Проектирование, ориентированное на использование фиксированной платформы, еще в большей степени уменьшает размерность задачи выбора проектных решений. Согласно данному подходу, разработчику предоставляется практически готовая вычислительная система на определенном уровне абстракции, которая затем может быть незначительно расширена путем добавления специализированных функциональных узлов, либо изменением программного обеспечения. Основные же составляющие части такие, как коммуникационная инфраструктура, архитектура вычислительного ядра, набор базовых СФ-блоков, являются фиксированными.
Различные техники и методы проектирования СнК позволяют снизить долю ошибок каждого этапа, но не позволяют полностью предотвратить их появление. При использовании средств САПР уменьшается вероятность ошибок, обусловленных человеческим фактором, но появляется возможность внесения ошибок, обусловленных ошибками в реализации самих средств САПР.
Ошибки могут появляться в проекте на каждом этапе жизненного цикла СнК [6-9]. Как в процессе проектирования, так и на этапах реализации и эксплуатации.
При проектировании СнК могут быть допущены ошибки в спецификации, принятии проектных решений, выборе методов и средств проектирования. При реализации могут появляться ошибки, обусловленные несовершенством технологического процесса (ошибки топологии), ошибками программирования, использованием средств САПР. В процессе натурных испытаний и эксплуатации появляются ошибки, связанные с непрогнозируемыми внешними воздействиями (низкие температуры, радиация, некорректная последовательность и формат входных воздействий), а также в результате «старения» (деградации) элементной базы.
Перечисленные ошибки приводят к вычислительным и невычислительным отказам системы. Под отказами понимаются нарушения исправного состояния объекта [10].
Так к вычислительным отказам относятся отказы, связанные с нарушением алгоритмов работы функциональных блоков СнК, а к невычислительным - отказы в работе элементной базы (нарушения в работе транзиторов). Следствием вычислительных и невычислительных отказов является отклонение поведения системы от нормы. Наблюдая за поведением, мы можем установить факт присутствие ошибки. Это возможно с помощью средств функциональной верификации.
По данным исследования [11] при производстве СнК только 30% устройств готовы к эксплуатации после первого выпуска микросхемы. В среднем же на выявление и устранение ошибок требуется повторить выпуск микросхемы 3-5 раз. Стоимость каждого выпуска при современном технологическом процессе доходит до $4 млн., что значительно увеличивает себестоимость проекта.
По статистике [11,12] 50-60% ошибок (рисунок 1.2), приводящих к перевыпуску микросхем, относятся к ошибкам в алгоритмах работы сложно-функциональных блоков (СФ-блоков). Также СФ-блоки содержат большое количество ошибок, пропущенных на этапе проектирования/реализации, из-за несовершенства существующих средств функциональной верификации (подробнее в разделе 1.3.2).
Если ошибки в подсистеме памяти и элементной базе (ошибки соединения проводников) выявляются на первом/втором экземпляре микросхемы, например, с помощью технологии граничного сканирования [13], то ошибки в алгоритмах работы СФ-блоков требуют 3 и более перевыпусков. 11 доля «пропущенных» ошибок
Часть ошибок остается невыявленной и обнаруживается только в процессе эксплуатации СнК конечным пользователем. Это связано с тем, что поведение СФ-блоков сильно зависит от последовательности входных воздействий, многие из которых не учтены в спецификации и проявляются при эксплуатации. В то время, как алгоритмы работы подсистемы памяти и элементной базы заранее известны. Их можно проверить на фабрике сразу после выпуска микросхемы.
Ошибки спецификации в 60% случаев [11] являются причинами некорректного функционирования СФ-блоков. Авторы [7] отмечают, что многие системы на практике содержат ошибки не потому, что они не удовлетворяют своей спецификации, а потому что спецификация не содержит описания системы во многих нештатных ситуациях, которые не подразумеваются во время проектирования. Утверждается, что это не зависит от образованности разработчика и не является недостатками методологии проектирования. Это фундаментальная характеристика самого процесса проектирования.
В данном контексте, актуальным является разработка методов создания набора входных воздействий, включающего непрогнозируемые, но возможные воздействия, а также методов сбора данных о поведении системы, достаточных для проверки требований функциональной спецификации
Правила спецификации алгоритма функционирования процессов
Количественная информация по событиям уже несет в себе качественную информацию и, как правило, не требует дополнительной обработки. По количественным характеристикам оценивают функциональное покрытие (functional coverage): факт выполнения функциональных свойств из списка. Также проверяют то, что число событий определенного типа не превысило заданный порог.
Последовательность изменения значения параметра во времени в дальнейшем используют для статистического анализа. Вычисляют среднее значение, девиацию и другие характеристики. Часто в качестве значения параметра используют значения времени. Интересующие события в процессе мониторинга помечаются меткой времени. После мониторинга по массиву значений времени вычисляют среднее время обработки задачи, определяют характер нарушения требований реального времени (систематическое, либо случайное).
Журнал событий обладает большой размерностью. Если для хранения идентификатора события используется один байт, то 1 Мб содержит данные о миллионе событий. Учитывая скорость возникновения событий в СнК, 1 Мб содержит информацию о жизни системы за доли миллисекунд. Проанализировать информацию о работе системы на протяжении десятков секунд визуально не представляется возможным. Для преодоления этой проблемы на практике используют формальные методы.
Уменьшить долю рутинной работы при локализации отказа возможно с помощью методов проверки формальных свойств. Для анализа свойств используют такие же средства, как и при динамической верификации [51, 58, 59]. Входными данными при этом являются не данные моделирования, а результаты мониторинга. Интерпретация результатов проверки свойств, то есть поиск причин отказов, производится экспертными методами.
Для автоматизации решения как задачи поиска отказов, так и задачи поиска причин отказов используют методы восстановления формальной поведенческой модели из данных журнала и анализ свойств этой модели с помощью методов Model Checking.
Методы восстановления формальной поведенческой модели по журналу событий можно разделить на две группы [60]: статистические и точные.
К статистическим относятся методы тренировки скрытых марковских моделей и методы на основе нейронных сетей. Статистические методы направлены на получение модели максимального правдоподобия. В результате получается приближенная модель, которая позволяет оценить основные свойства анализируемой системы, но не подходит для поиска причин отказов. Данные методы используются для задачи обратной разработки (reverse engineering), нежели верификации. Это связано с тем, что эти методы характеризуются таким параметром, как устойчивость к шуму и нечувствительны к редким отклонениям поведения системы от типового шаблона функционирования.
Для задачи верификации подходят точные методы. Последовательность событий можно рассматривать, как совокупность слов определенного языка, поэтому для задачи восстановления модели естественным образом подходят методы синтеза распознающих автоматов [61-63].
В таблице 1.2 приведена классификация средств встроенного функционального мониторинга, которые используются в коммерческих проектах СнК. В таблице представлены средства мониторинга, которые используются, как в процессе аппаратной эмуляции (hardware emulation) системы на ПЛИС, так и в процессе натурных испытаний экземпляра микросхемы СнК. - тип монитора (столбец «Тип»): аппаратный (А), программный (П), гибридный (аппаратно-программный, А/П). - количество ресурсов (столбец «Ресурсы»), которые монитор требует для своей работы. Значение данного параметра выражено в процентах от ресурсов всей системы. Вычислительные ресурсы оцениваются в проценте снижения быстродействия (СБ) системы, которое вызвано использованием общих вычислительных ресурсов. Также оценивается площадь (П) на кристалле, требуемая для системы мониторинга. Знак «-» означает, что значение соответствующего параметра 0.001%. - уровень мониторинга (столбец «Уровень»): прикладной алгоритм (ПА), операционная система (ОС), коммуникационная инфраструктура (КИ), микроархитектура (М), уровень схемы (С). В таблице обозначен уровень, на котором чаще всего производится наблюдение с использованием соответствующих средств. Например, с помощью встроенных логических анализаторов ChipScope, SignalTap можно наблюдать действия операционной системы, если эти действия приводят к изменению сигналов линий передач данных, сигналов управления к другим блокам и т.п., но непосредственно мониторинг производится на уровнях коммуникационной инфраструктуры, микроархитектуры или схемы.
Из таблицы 1.2 видно, что в коммерческих проектах функциональный мониторинг выполняется как с помощью программных модулей, являющихся частью прикладного, либо системного программного обеспечения, так и с помощью аппаратных мониторов.
Программные мониторы используют те же вычислительные ресурсы системы, что и целевое программное обеспечение СнК. В связи с этим, значительно снижается быстродействие: от 1% до Таблица 1.2- Классификация средств встроенного мониторинга, используемых в коммерческих проектах СнК
Основным преимуществом программных мониторов является низкая цена внесения изменений в алгоритм мониторинга. Новые мониторы могут быть внедрены в систему посредством перепрограммирования процессоров СнК. Программные мониторы используются не только при решении задачи верификации, но и на этапах отладки, так как позволяют достаточно быстро проводить множество циклов наблюдения с разными конфигурациями мониторов.
Аппаратные блоки мониторов практически не снижают быстродействие целевой системы (менее 5%), так как являются пассивными блоками, которые не задействуют основные вычислительные ресурсы СнК. В большинстве систем функционального мониторинга (ARM CoreSight, Nexus 5001 и др.) сбор результатов наблюдения с аппаратных мониторов осуществляется посредством выделенных каналов передачи данных, что предотвращает загрузку каналов передачи прикладных данных.
В настоящее время существует три типа аппаратных мониторов: встроенные логические анализаторы (ChipScope, SignalTap), мониторы с непрерывным протоколированием событий (ARM CoreSight, Nexus 5001, MIPS on-chip instrumentation), аппаратные мониторы утверждений (MB AC, FoCs).
Встроенные логические анализаторы ориентированы на однократное запоминание последовательности событий на протяжении коротких промежутков времени - сотни микросекунд. Данные мониторы используются для наблюдения за быстрыми событиями на уровне микроархитектуры и схемы - изменениями сигналов управления, циклами коммуникационных шин и т.п. Встроенные анализаторы используются для проверки корректности выполнения отдельных операций функциональными узлами СнК. С помощью средств соответствующих САПР (Altera Quartus II, Xilinx Design Suite) можно получить результаты мониторинга посредством диагностического интерфейса и представить их в виде временной диаграммы. Анализ результатов мониторинга проводится средствами разработчика визуально.
Мониторы с поддержкой непрерывного протоколирования (журналирования) событий используются для наблюдения за системой на протяжении длительных промежутков времени. Время наблюдения ограничено объемом встроенной инструментальной памяти СнК. Для хранения журнала обычно доступно 100-500 Мбайт [83]. Такого объема хватает на минуты наблюдения. Этого не достаточно для обнаружения внезапных и перемежающихся отказов случайной природы, характерных для системы с множеством параллельно работающих блоков [84].
Микроархитектура встроенного монитора с динамической актуализацией модели поведения
Получив минимальную модель GAM, например, такую как показана на рисунке 2.6, можно определить алгоритм выделения состояний процесса.
Исходными данными для алгоритма выделения состояний будет список событий и правила обновления текущей разметки. По приходу каждого нового события изменяется содержимое текущей разметки состояния cur_state_stamp.
В начале наблюдения cur_state_stamp = 0. При возникновении события є Є Е оно добавляется к cur_state_stamp = cur_state_stamp U {е}, Также из cur_state_stamp удаляются события, принадлежащие множеству DL(e) 4 end 5 end Алгоритм 3: Алгоритм определения множества удаляемых событий DL mark{trans) - это событие, которым размечен переход trans, то есть событие, по которому этот переход выполняется. Множество DL(e) для каждого события є Є Е может быть определено до начала наблюдения посредством анализа модели GAM.
Таким образом, алгоритм выделения состояний использует информацию о структуре модели GAM, полученной из эталонной модели МЕВ. Формальная запись алгоритма представлена ниже і cur_state_stamp = (cur_state_stamp П DL(e)) U {e} 2 state_stamp = cur_state_stamp
Алгоритм 4: Алгоритм выделения информации о состоянии с использованием информации о структуре минимальной модели GAM
В разделах 2.4.2, 2.4.3, 2.4.4 определено три метода выделения состояний процесса во время его функционирования в рамках общего алгоритма актуализации модели поведения (2.2).
Определение 1. Актуализация модели поведения - это восстановление модели процесса на основе данных о произошедших событий и данных об его ожидаемом поведении.
Под термином «актуализация» понимается восстановление модели реального функционирования процесса на основе априорной информации, то есть модели ожидаемого поведения (модели ME В). Априорная информация позволяет получить в результате наблюдения модель, в которой можно различить все состояния модели МЕВ. Это необходимо для определения фактов нарушения функционирования на этапе анализа результатов мониторинга.
Будем считать, что каждому процессу ставится в соответствие логический монитор, реализующий подходящий метод наблюдения. Выделим три типа логических мониторов: 1. MS-монитор (monitor of sequences) - монитор, выделяющий состояния на основе последовательности событий, произошедших в прошлом; 2. MF-монитор (monitor of facts) - монитор, выделяющий состояния на основе фактов событий, произошедших в прошлом; 3. OMF-монитор (optimized monitor of facts) - монитор, выделяющий состояния на основе структуры модели МЕВ. Является оптимизированной версией MF-монитора по ресурсам памяти.
Термин «логический монитор» в данном контексте употребляется как синоним термина «виртуальный». Множество логических мониторов в процессе реализации отображается на множество физических мониторов, которые встраиваются непосредственно в структуру проекта микросхемы СнК. При этом один физический монитор может выполнять функции нескольких логических мониторов (подробнее в главе 3).
Определим профиль наблюдения за функционированием процесса, то есть исходные данные для задачи мониторинга.
Определение 2. Профиль наблюдения - исходные данные мониторинга, определяющие область видимости процесса с позиции стороннего наблюдателя.
Действия, представленные на рисунке 2.7, были описаны в предыдущих разделах. Так поиск минимальной модели GAM выполняется в соответствии с алгоритмом 1, определение размера окна наблюдения показано в (2.4), возможность наблюдения только за фактами возникновения событий проверяется согласно (2.9).
Настройки алгоритма наблюдения для MS - и MF - мониторов содержат информацию только о размере окна наблюдения. Настройками алгоритма наблюдения для OMF-монитора является ассоциативный список, связывающий идентификаторы наблюдаемых событий и множество удаляемых идентификаторов событий DL (алгоритм 3, приложение В.2) из текущей разметки состояния. Ассоциативный список формируется на основе модели GAM.
Оценим эффективность разработанных логических мониторов в различных приложениях: при наблюдении за алгоритмами работы ведущих устройств протоколов Modbus (приложение Б.1) и PAR (приложение Б.2).
На рисунке 2.8 представлена зависимость размера графа актуализированной модели AM от времени наблюдения, выраженного в количестве произошедших событий. Размер графа AM измеряется в условных единицах и вычисляется по формуле size(AM) = \QAM\ + 3- ТдМ, где QAM - это множество состояний модели AM, а ТАМ - множество переходов. Таким образом, условно считаем, что для хранения информации об одном состоянии требуется одна условная единица памяти, а для хранения перехода - три условные единицы: для хранения идентификатора состояния источника, идентификатора события, по которому произошел переход, и идентификатора состояния назначения.
На рисунке 2.8 представлены результаты моделирования работы логических мониторов разных типов при условии, что поведение процесса соответствует модели ожидаемого поведения МЕВ. По результатам имитационного моделирования видно, что размер памяти, требуемой для хранения графа AM увеличивается только при фиксации новых шаблонов поведения. После того, как процесс совершит все переходы модели МЕВ, размер AM перестает увеличиваться. Использование OMF-монитора позволяет уменьшить размер графа AM в 2 раза.
Система функционального мониторинга для унифицированной информационно-измерительной платформы СнК
Все процессы системы группируются в домены мониторинга. Для каждого домена в дальнейшем синтезируется своя подсистема функционального мониторинга. Разделение на домены может быть обусловлено проектированием модульной системы, состоящей из нескольких СнК. В данном случае используется одна спецификация алгоритма, но для каждой СнК создается своя подсистема функционального мониторинга. Также выделение доменов мониторинга может быть оправдано при необходимости разделения доступа внутри СнК к информации о поведении различных процессов. Например, чтобы ограничить доступ прикладного программиста к информации о поведении системных процессов.
На основе описания событий и исходной спецификации алгоритма создаются модели ожидаемого поведения МЕВ для процессов. По результатам формируется отчет, в котором описываются характеристики процессов: список неразличимых состояний. Неразличимые состояния могут появляться, если исходная модель - автомат Мили - имеет не минимальную форму. Если присутствуют неразличимые состояния, то разработчик либо должен согласиться с этим, либо доопределить события модели и повторить генерацию МЕВ.
На основе моделей МЕВ для каждого домена синтезируется отдельная подсистема мониторинга, оптимизированная по параметрам производительности и занимаемым ресурсам. Подсистема мониторинга формируется в виде набора IP-ядер, упакованных по стандарту IP-XACT, что позволяет встроить её в существующие маршруты проектирования фирм Synopsys, Xilinx, Cadence.
Результатами мониторинга являются актуализированные модели процессов, которые выгружаются на персональный компьютер разработчика/оператора посредством диагностического интерфейса. Модели AM преобразуются в модели наблюдаемого поведения МОВ.
Для каждого наблюдаемого процесса, то есть для каждой модели МЕВ, создается один логический монитор. Один физический блок монитора в составе СнК может моделировать работу нескольких логических мониторов. Оптимальная конфигурация выбирается на этапе синтеза мониторов, учитывая характеристики моделей МЕВ.
Блоки захвата событий, блок арбитра событий, блок обработки событий синтезируются для конкретной системы функционального мониторинга с помощью средств автоматизации проектирования (подробнее в разделе 3.4). Блоки управления, контроллер ввода-вывода, блок таймера и устройство управления являются унифицированными (одинаковыми) для всех типов мониторов.
В таблице 3.1 представлены результаты синтеза аппаратных блоков мониторов для случаев, когда один физический монитор выполняет функции одного логического монитора. Результаты были получены при синтезе мониторов на ПЛИС xc7z020clg484 (платформа Xilinx Zynq-7000). Также в таблице произведена оценка площади кристалла в количестве эквивалентных вентилей NAND2. По результатам видно, что блоки мониторов занимают не более 1% ПЛИС.
В таблице 3.2 представлены результаты оценки производительности блоков мониторов. Частота системного синхросигнала была равна 100 МГц. По результатам видно, что среднее время обработки событий измеряется единицами микросекунд. представлена динамика изменения значений мгновенного времени обработки событий при наблюдении за разными процессами. По результатом видно, что диапазон изменения значений времени обработки событий фиксирован. Принимая во внимание алгоритм обработки событий разными типами мониторов, можно сказать, что время обработки одного события зависит как от размера актуализированной модели AM, так и от вероятности пребывания процесса в определенных состояниях. Если процесс чаще находится в состояниях, которые были актуализированы в начале наблюдения, то время обновления графа AM будет минимальным. В противном случае будет тратится большее время на поиск текущего перехода среди уже существующих в AM. Из рисунка 3.5 видно, что OMF-монитор в 1.7 (протокол Modbus) и 2.4 (протокол PAR) раза быстрее обрабатывает события, чем другие типы мониторов.
В процессе проектирования подсистемы функционального мониторинга разработчик определяет перечень наблюдаемых событий для процесса в виде списка предикатов. Выполнение предикатов связывается с возникновением определенного события. Каждый блок захвата событий записывает в очередь идентификатор события и значения таймера (временную метку) (рисунок 3.6), то есть (eventid, timestamp). (рисунок 3.4). Блок захвата событий синтезируется для каждого наблюдаемого сигнала OS на основе записи предиката события. Для предикатов, описанных выше, определена операция автоматизированного синтеза в схемную реализацию (рисунок 3.6). Для захвата более сложных событий, связанных с выполнением выражений, которые невозможно представить с помощью пропозициональной логики, необходимо осуществить каскадное подключение разработанного блока захвата событий к синтезированному блоку захвата.
Например, для обработки транзакций системной шины, необходимо разработать блок захвата транзакций, который для разных шин (АМВА, ОСР, Wishbone и др.) будет разным. Факты изменения значений выходных сигналов разработанного блока будут являться наблюдаемыми сигналами, которые следует подключить к входам синтезированного (synthesized) блока захвата, обрабатывающие простые шаблоны изменения сигнала. Таким образом, возможно масштабирование алгоритмов захвата событий (рисунок 3.7).
Арбитр событий (Event Arbiter) опрашивает в цикле (алгоритм Round-robin) очереди событий, сравнивая значения временных меток первых событий. Арбитр выбирает метку с меньшим временем и пересылает идентификатор соответствующего события в очередь, с которой работает блок обработки событий (Event Handler). Таким образом, реализуется выравнивание моментов наступления событий по времени и снижение вероятности возникновения гонок от нескольких источников - нескольких блоков захвата. 3.3.3 Блок обработки событий
В процессе работы монитор актуализирует модель поведения процесса (модель AM) на основе данных о фиксируемых событиях. Динамическую актуализацию модели поведения производит блок обработки событий (Event Handler, EH, рисунок 3.4). Он формирует в своей внутренней памяти граф AM в виде множества состояний Q, множества переходов Т и информации о текущем состоянии cur_state. Содержимое множеств Q,T и переменной cur_state обновляется на каждом цикле наблюдения, то есть по приходу каждого нового события.