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

Пространство состояний

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

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

Верификация простейшего свойства

В качестве примера рассмотрим простейшее свойство: «определенный бит состояния всегда сохраняет нулевое значение». Для доказательства такого свойства нам необходимо убедиться, что это свойство выполняется во всех вершинах графа состояний, достижимых из начального состояния. В качестве начального состояния выбирается то состояние, в котором система находится после выполнения сброса/начальной установке.
Конечно, в чистом виде состояния никто не перебирает, вместо этого используются различные нетривиальные подходы для представления групп состояний и техники на основе решений SAT задачи. Но, в силу размерности это всё равно крайне трудоемкая задача.

Ограничение пространства состояний

Практически во всех системах большая часть состояний не является допустимыми. Исключение части недопустимых состояний позволяет радикально ускорить процесс верификации. Это можно сделать путем формулирования вспомогательных свойств (инвариантов), которые определяют, является ли состояние корректным. Такие свойства можно сформулировать на основе информации о структуре системы и логике её работы.
Недопустимые состояния можно разделить на две категории: недопустимые по структуре и недопустимые по выполнению.

Приведу примеры.
Предположим, в структуре передаваемых по модели пакетов есть четырехбитное поле (диапазон значений 0-15), хранящее номер передающего устройства. Но в системе присутствует только 10 передающих устройств (номера 0-9). Соответственно, все состояния содержащие пакеты, в соответствующем поле которых находится значение большее 9, не являются допустимыми по своей структуре.

Другой пример:
Предположим, что в системе есть фрагмент, состоящий из двух параллельных очередей с емкостью 2 пакета (см. рис.). Схема устроена так, что пакеты помещаются и извлекаются из очередей только одновременно, а после сброса очереди пусты. В ходе работы системы очереди такого фрагмента всегда будут содержать равное число пакетов.
Ситуация, когда количество корректных пакетов в этих двух очередях различно, является корректной, но она недостижима ни на каком из путей выполнения системы. Это недопустимое по выполнению состояние.
Кроме того, такие ситуации привносят неожиданные поведения в систему. В частности, если одна из очередей целиком заполнена, а другая пуста, то такой фрагмент полностью блокирует движение пакетов через систему. Так как одна очередь полностью заполнена, то нельзя одновременно поместить по одному пакету в каждую из очередей. Аналогично, нельзя одновременно извлечь из каждой очереди по пакету.

Фрагмент микроархитектурной модели из двух параллельных очередей

Верификация свойства из произвольного состояния

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

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

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

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

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

Аргумент в пользу сетей на кристалле: в глобальных сетях, поток данных может проходить через участки, построенные по различным технологиям, отличающимся способами коммутации, разделения среды, маршрутизации и т.д. Например, при звонке с IP-телефона на сотовый телефон, голосовой трафик может сначала проходить через локальную сеть с коммутацией пакетов, затем через сеть ATM с коммутацией соединений и, наконец, через мобильную сеть построенную по третьей технологии (например, UMTS). Чтобы обеспечить выполнение требований качества обслуживания на всем пути от источника к получателю, необходимо учитывать отличия механизмов качества обслуживания в этих типах сетей. Для сетей на кристалле архитектура заранее известна и проблемы связанные с передачей данных между разными типами сетей не актуальны.

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

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

За последнее десятилетие были предложены подходы к проектированию коммуникационных фабрик, призванные обеспечить гарантии качества обслуживания “по построению”. Их можно условно разделить на две категории. Подходы на основе дифференциации трафика (traffic differentiation) решают проблему конкурирующих запросов введением уровней приоритета, соответствующих разным классам трафика. Однако для сложной системы затруднительно определить необходимое количество уровней приоритетов и избежать таких проблем, как инверсии приоритета и истощения ресурсов (starvation).
Проблема инверсии приоритетов заключается в следующем: если в одной из очередей пакетов высокоприоритетному пакету предшествует низкоприоритетный, то продвижение пакета с высоким приоритетом блокируется до тех пор, пока не будет обработан низкоприоритетный пакет. Такая ситуация потенциально приводит к нарушению требований качества обслуживания для высокоприоритетного трафика. Фактически приоритет обслуживания блокирующего пакета повышается по сравнению с тем классом трафика, к которому он принадлежит. Избежать этого можно, например, повсеместным использованием раздельных очередей для буферизации различных классов трафика.

Передача без конкуренции (contention-free transmisson) основывается на той или иной схеме резервирования ресурсов перед началом передачи. Разделение времени обработки, использование мест в очередях, порядок передачи по разделяемым линиям связи, планируются заранее. Если тот или иной ресурс оказывается невостребованным тем, кому он предназначался согласно плану, то он не используется даже при наличии других запросов на этот ресурс.
Используя статическое резервирование, несложно добиться определенных гарантий производительности. Такой подход позволяет оптимизировать архитектуру под конкретное приложение и пригоден для встраиваемых систем, но приводит к низкой утилизация ресурсов в системах на кристалле широкого спектра применения. Это объясняется опять же тем, что поведение узлов сети может сильно изменяться с течением времени. При динамическом резервировании ресурсов, после того как ресурсы уже зарезервированы, удается добиться и гарантий производительности и хорошей утилизации ресурсов. Но сам процесс резервирования может занять длительное время и задержки на стадии резервирования по-прежнему трудно оценить.

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

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

Качество обслуживания (Quality of Service, QoS) – это способность системы обеспечивать своим агентам определенные измеряемые гарантии по обработке потоков данных. Нас в первую очередь будут интересовать гарантии касающиеся производительности, а потоком данных мы будем называть совокупность сообщений, обладающих каким-либо общим признаком, например, сообщения от одного источника или адресованные одному получателю.
Количественно такие гарантии для потока данных, как правило, описываются тремя характеристиками:
• Форма потока – объем данных, переданных потоком, начиная с некоторого момента времени. Для описания формы потока часто используют показатели средней плотности (rate, bandwidth) и величины всплеска (burst).
• Задержка передачи (latency) – интервал времени между отправлением данных источником и их получением в точке назначения.
• Вариация задержки (jitter) – разница между максимальным и минимальным значениями задержки в потоке данных.

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

Ранее приближенные оценки для подобных свойств получались с помощью аналитических методов [1,6,4], таких, как, например, network calculus. Однако для современных систем межсоединений внутри кристалла подобные методы или не применимы или дают слишком неточные оценки из-за требуемых для применения методов ограничений и упрощений.
Другая интересная задача носит в литературе название «Exploration». Современные коммуникационные фабрики параметризованы множеством параметров: размеры буферов и очередей, алгоритмы арбитража, ширина линий связи, количество используемых классов трафика, и т.д. Быстрый выбор такого набора параметров, который бы оптимизировал метрики качества обслуживания, на сегодняшний день является открытой проблемой. На текущий момент она (не слишком эффективно) решается путем ревью архитектуры и валидации производительности.

Некоторые частные exploration-задачи имеют эффективное решение. Например, задача оптимального выбора емкости буферов и очередей успешно решена для асинхронных и синхронных эластичных структур [5,2,3]. Но это лишь небольшое подмножество структур используемых в современных фабриках.

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

Библиографический список:
1. Boudec, J.Y.L., Thiran, P.: A Theory of Deterministic Queuing Systems for the Internet, lncs, vol. 2050. Springer-Verlag (2004)
2. Bufistov, D., J´ulvez, J., Cortadella, J.: Performance optimization of elastic systems using buffer resizing and buffer insertion. In: Proc. International Conf. Computer-Aided Design (ICCAD). pp. 442–448 (Nov 2008)
3. Bufistov, D.E., Cortadella, J., Galceran-Oms, M., J´ulvez, J., Kishinevsky, M.: Retiming and recycling for elastic systems with early evaluation. In: DAC ’09: Proceedings of the 46th Annual Design Automation Conferen ce. pp. 288–291. ACM (2009)
4. Burns, S.M., Hulgaard, H., Amon, T., Borriello, G.: An algorithm for exact bounds on the time separation of events in concurrent systems. IEEE Trans. Comput. 44, 1306–1317 (November 1995), http://dx.doi.org/10.1109/12.475126
5. Manohar, R., Martin, A.J.: Slack elasticity in concurrent computing. In: Proc. 4th Int. Conf. on the Mathematics of Program Construction. LNCS, vol. 1422, pp. 272–285 (1998)
6. Wilhelm, R.: Timing analysis and timing predictability. In: de Boer, F., Bonsangue, M., Graf, S., de Roever, W.P. (eds.) Formal Methods for Components and Objects, Lecture Notes in Computer Science, vol. 3657, pp.

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

Используемые архитектурные модели представляют собой сети передачи пакетов, состоящие из небольшого набора простых примитивов. Такие модели называются сетями xMAS (xMAS - eXecutable MicroArchitectural Specification). Семантика таких сетей описывается с использованием синхронных уравнений для каждого примитива. За счет этого для каждой сети xMAS существует соответствующая ей синхронная модель.

Набор базовых примитивов xMAS

Требующие верификации свойства архитектуры коммуникационных фабрик определяются для сетей xMAS. А для верификации сеть xMAS преобразуется в соответствующую синхронную модель. Свойства такой модели затем верифицируются c использованием стандартных средств верификации или разработанных самостоятельно.
Например, Синхронная модель xMAS может быть представлена в виде single clock, edge-triggered описания на языке Verilog – одном из языков описания аппаратуры. Такое представление позволяет использовать для верификации наших свойств любые сторонние средства верификации Verilog.

Следует заметить, что хоть такое описание на языке Verilog и является синтезируемым, но оно не используется при создании микропроцессора. Такое описание лишь отражает (высокоуровневую) структуру модели, абстрагируя многие детали реального RTL описания на языке Verilog.

Простая модель xMAS

На этапе трансляции сети xMAS в описание на языке Verilog мы располагаем информацией о высокоуровневой структуре модели (например, что здесь не просто набор регистров, а очередь, а это не просто несколько логических элементов, а логика синхронизации). Используя информацию такого рода можно автоматически обнаруживать дополнительные инварианты, описывающие поведение модели. Добавление дополнительных инвариантов в Verilog-описание обеспечивает индуктивное усиление доказываемых утверждений и, в конечном счете, упрощает их верификацию.
Методология моделирования более подробно рассмотрена в [1], а использование автоматического усиления доказываемых утверждений в [2].

Одним из достоинств такого метода является легковесное автоматизированное доказательство так называемых liveness свойств (отсутствия тупиковых состояний) большого класса реальных примеров из области коммуникационных фабрик.

Модель двух агентов обменивающихся запросами и ответами на запросы

Определение тупикового состояния (deadlock) в моделях xMAS носит локальный характер. Т.е. допускается, что часть модели всегда заблокирована, в то время как остальная модель продолжает обрабатывать пакеты. Такие локальные тупиковые состояния носят название livelock.

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

Продолжение (если таковое появится) будет посвящено проблемам анализа свойств качества обслуживания или же более детальному описанию подхода к моделированию xMAS.

Библиографический список:
1. Chatterjee, S., Kishinevsky, M., Ogras, U.Y.: Quick formal modeling of communication fabrics to enable verification. Proc. IEEE High Level Design Validation and TestWorkshop (HLDVT) pp. 42–49 (2010)
2. Chatterjee, S., Kishinevsky, M.: Automatic generation of inductive invariants from highlevel microarchitectural models of communication fabrics. In: Computer Aided Verification, LNCS, vol. 6174, pp. 321–338. Springer-Verlag (2010)
3. Gotmanov, A., Chatterjee, S., Kishinevsky, M.: Verifying deadlock-freedom of communication fabrics. pp. 214–231 (2011)

Время выхода на рынок или Time-to-Market является одним из основных ограничений при проектировании систем на кристалле (SoC). Команды разработчиков обычно рассчитывают на использование стандартных IP блоков, которые переиспользуются во множестве продуктов, что обеспечивает малое время проектирования.

Поэтому, эффективные решения в области соединения аппаратных узлов на системном уровне (коммуникационные фабрики), способные без дополнительных усилий соединять вместе различные IP блоки, также становятся неотъемлемой частью дизайна. Такая методология проектирования распространяется вплоть до Hi-End серверов и высокопроизводительных систем, где требования к переиспользованию стандартизованых компонентов (особенно, решений в области соединения узлов) между различными сегментами продукции и поколениями устройств растут.

Если разработке системы соединений не уделялось должного внимания, то потенциально возникающие тупиковые состояния (deadlocks и livelocks) создают большие трудности для быстрой интеграции системы на кристалле. Распределенная природа системы межсоединений и сложное взаимодействие между различными IP блоками делают возникающие проблемы сложными для понимания и отладки. Ряд сценариев, приводящих к тупиковым состояниям можно обнаружить, только рассматривая систему на кристалле целиком. И лишь очень немногие инженеры занятые разработкой системы имеют представление о функционировании системы в целом, а значит, могут корректно и за разумное время локализовать возникающие ошибки и определить их природу.

Распределенное взаимодействие и поиск ошибок в системе на кристалле

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

Текущие средства формальной верификации не способны анализировать системы такой сложности напрямую – коммуникационная фабрика и её окружение составляют существенную часть всех логических элементов внутри процессорного кристалла (какую именно часть – не скажу )

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

Сравнительно недавно моими коллегами был достигнут значительный успех в этом направлении, с использованием простого набора функциональных примитивов для построения моделей[1], автоматической генерации индуктивных инвариантов[2] и анализе условий возникновения тупиковых состояний[3]. Этот подход успешно применяется и позволил как обнаружить ряд ряд тупиковых состояний в реальной микроархитектуре, так и доказать их отсутствие при внесении предложенных исправлений.

Однако, есть потребность в значительном расширении методов верификации, для того, чтобы иметь возможность анализировать более широкий класс систем и их свойств. Например, анализировать свойства высокоуровневых протоколов используемых блоками, таких, как когерентность кэша (cache coherency) или целостность памяти (memory consistency), принимая во внимание особенности микроархитектурной реализации (чего не позволяют современные подходы к верификации целостности кэша).

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

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

Библиографический список:
1. Chatterjee, S., Kishinevsky, M., Ogras, U.Y.: Quick formal modeling of communication fabrics to enable verification. Proc. IEEE High Level Design Validation and TestWorkshop (HLDVT) pp. 42–49 (2010)

2. Chatterjee, S., Kishinevsky, M.: Automatic generation of inductive invariants from highlevel microarchitectural models of communication fabrics. In: Computer Aided Verification, LNCS, vol. 6174, pp. 321–338. Springer-Verlag (2010)

3. Gotmanov, A., Chatterjee, S., Kishinevsky, M.: Verifying deadlock-freedom of communication fabrics. VMCAI'11, LNCS, vol. 6538, pp. 214–231 (2011)

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

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

Система соединений Intel Atom CE4100 и подключенные к ней блоки

Кольцевая шина SandyBridge-EX и подключенные к ней блоки

Однако, с проектированием коммуникационных фабрик связано множество трудностей, которые я попробую вкратце обрисовать.
Сейчас коммуникационные фабрики используются в процессорах для практически всех сегментов компьютерного рынка: от высокопроизводительных серверных и графических решений, до настольных и встраиваемых систем. Архитектура фабрик для hi-end систем обычно представлена регулярными кольцами (rings) и решетками (meshes) и существенно отличается от используемой во встраиваемых системах. В составе систем на кристалле коммуникационные фабрики нередко решают задачи ввода/вывода и выполнения протокола целостности кэша. Поэтому дизайн коммуникационных фабрик предъявляет повышенные требования к качеству (корректность, производительность, энергопотребление, надежность) и скорости интеграции в современные и будущие продукты.

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

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

Если рассматривать проблему проверки характеристик фабрики, то оказывается, что текущие средства формальной верификации не способны анализировать системы такой сложности. Как правило, проводимый анализ производительности и корректности основывается на имитационном моделировании. При этом высока вероятность упустить существенные граничные случаи, что не позволяет получить надежных гарантий производительности. А убедиться в отсутствии тупиковых состояний (так называемых deadlocks и livelocks) при таком подходе просто невозможно. Кроме того, ряд тупиковых сценариев в принципе невозможно обнаружить, анализируя части системы по отдельности – необходимо рассматривать коммуникационную фабрику в конкретной конфигурации, вместе с подключенными к ней агентами.

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