Содержание к диссертации
Введение
Глава 1. Процесс проектирования СБИС и его проблемы 13
1.1. Определение базовых понятий 13
1.2. Традиционный процесс разработки систем на кристалле 16
1.3. Современный процесс разработки систем на кристалле 20
1.4. Проблемы современного процесса разработки систем на кристалле 23
1.5. Постановка задачи 28
Глава 2. Анализ и выбор форматов, использующихся при создании спецификаций 30
2.1. Общие подходы 30
2.2. Выбор форматов для анализа 33
2.3. Анализ форматов на основе выбранных критериев 39
2.3.1. Применение форматов при проектировании архитектуры вычислительных систем 39
2.3.2. Сложность создания спецификаций 44
2.3.3. Возможности верификации данных 46
2.3.4. Трансляция на формальные языки 53
2.3.5. Представление архитектуры систем на кристалле 58
2.4. Результаты анализа форматов 66
2.5. Выводы по главе 2 69
Глава 3. Разработка методов 72
3.1. Общий подход 72
3.2. Методы создания и использования поведенческих спецификаций 82
3.3. Методы создания и использования структурных спецификаций 99
3.4. Выводы по главе 3 111
Глава 4. Применение методов создания и использования архитектурных спецификаций систем на кристалле 112
4.1. Описание реализации предложенных методов в виде программной системы ACES 112
4.1.1. Реализация методов создания и использования поведенческих спецификаций систем на кристалле 114
4.1.2. Реализация методов создания 121
4.1.3. Инфраструктура системы ACES и использования структурных спецификаций систем на кристалле 125
4.2. Описание реализации предложенных методов в виде программной системы в концерне «Вега» 132
4.3. Выводы по главе 4 136
Заключение 137
Приложение А. Акты о внедрении результатов
- Традиционный процесс разработки систем на кристалле
- Применение форматов при проектировании архитектуры вычислительных систем
- Методы создания и использования поведенческих спецификаций
- Инфраструктура системы ACES и использования структурных спецификаций систем на кристалле
Традиционный процесс разработки систем на кристалле
Ранее в течение десятилетий проектирование СБИС велось по классической каскадной модели [1]. Классический процесс проектирования вычислительной системы может быть формально разделен на несколько стадий: планирование, разработка спецификации архитектуры, разработка микроархитектуры, описание системы на уровне регистровых передач (RTL), а также логический и физический синтез.
Стадия планирования относится в большей мере к общей стратегии компании, нежели к конкретному проекту. На этой стадии разрабатываются и определяются основные технологии, которые будут использоваться при проектировании вычислительных систем, и решается, какие конечные продукты будут разрабатываться.
На стадии разработки спецификации архитектуры определяются основные требования к системе, её будущие характеристики и основные функциональные блоки.
На стадии проектирования микроархитектуры разрабатываются основные элементы каждого функционального блока с учётом требований к площади кристалла, энергопотреблению и прочих.
На следующем этапе создаётся RTL-код аппаратных блоков системы на языках описания аппаратуры, таких как Verilog или VHDL. RDL-код детально описывает потоки сигналов между аппаратными регистрами и логические операции над данными. После разработки RTL-кода в классическом процессе начинается функциональная верификация системы
Дальнейшие этапы включают в себя планирование топологии кристалла, логический синтез, результатом которого является описание системы на вентильном уровне в виде списка цепей, проектирование систем питания и синхронизации, временную верификацию системы, а также физический синтез – размещение элементов на схеме и трассировка связей между ними. После физического синтеза и следующей за ним физической верификации следует создание физического прототипа СБИС и его тестирование.
Общая схема традиционного каскадного процесса разработки СнК приведена на рис. 1.2.
С усложнением разрабатываемых СБИС возникла проблема: традиционный каскадный процесс не может обеспечить достаточный уровень покрытия верификации системы. Это объясняется тем, что в рамках традиционного процесса проектирования большинство действий по валидации систем проводились уже после создания RTL-кода. Одной из главных причин этого являлось отсутствие полных и завершённых моделей даже отдельных аспектов структуры и поведения системы [3]. Однако описание на уровне регистровых передач является слишком низкоуровневым для того, чтобы в короткие сроки провести полную валидацию системы, содержащей сотни миллионов элементов. Поэтому с усложнением проектируемых вычислительных систем стали прикладываться серьёзные усилия для того, чтобы перейти на более высокий уровень абстракции для описания и верификации систем. Требовалось создать новые способы формального описания системы, причём как аппаратной её части, так и программного обеспечения, и разработать новую методологию создания и верификации такого описания на этапе создания спецификаций архитектуры и микроархитектуры системы. Нужно было обеспечить возможность верификации архитектуры системы на самых ранних этапах её разработки, ведь, как известно, ошибки, допущенные на самых ранних этапах проектирования, «стоят» компании-разработчику дороже всего [4-7].
Разработчики СБИС столкнулись с проблемой выбора новых языков описания системного уровня и методологии проектирования и верификации с использованием этих языков. Любой подобный язык системного уровня должен был обладать двумя основными качествами: иметь возможность объединять множество разнородных моделей и работать на высоком уровне абстракции.
В последние двадцать лет многие возможности были предложены для решения данной задачи [3]:
1. Использование языков описания аппаратуры с некоторыми дополнениями, как, например, расширение языка Verilog до SystemVerilog.
2. Адаптация языков программирования высокого уровня (C/C++, Java) для описания архитектурных спецификаций систем на кристалле.
3. Создание принципиально новых языков системного уровня специально для проектирования систем на кристалле. Данный подход может привести к наилучшим результатам, но работа в этом направлении требует огромных усилий.
4. Расширение возможностей существующих языков высокоуровневого моделирования и применение их вместе с другими языками более низкого уровня для описания архитектурных спецификаций систем.
В современной практике создания высокоуровневых моделей наиболее часто применяются языки, разработанные с использованием первых двух подходов, такие как SystemC и SystemVerilog.
Второй проблемой традиционного подхода является то, что с усложнением проектируемых ВС стало практически невозможно с первого раза получить качественную и безошибочную модель системы на каждом этапе процесса проектирования [8], что привело к необходимости использовать итерации на каждом таком этапе
Третьей проблемой традиционного подхода является возрастающая роль встроенного программного обеспечения в СнК [9]. Необходимо было разработать алгоритм выделения функций аппаратных и программных частей, параллельной разработки этих частей, последующей интеграции и совместной верификации.
Применение форматов при проектировании архитектуры вычислительных систем
Для анализа применения форматов при проектировании проведём исследование существующей открытой спецификации аппаратно-программной платформы. Будем использовать для этих целей описание открытой архитектуры Microsoft Open Cloud Server [24], платформы, разработанной для повышения эффективности использования серверов в дата-центрах Microsoft. Спецификация Open Cloud Server содержит множество IP-блоков, от микропроцессорных кластеров до сетевых плат и блоков долговременной памяти.
Основным критерием сравнения форматов при исследовании является частота использования различных форматов данных в документах спецификации. Для её оценки необходимо найти долю данных в этих форматах в общем объёме спецификаций. Так как крайне сложно сравнить количество информации другими способами, кроме как по количеству страниц, ей занимаемых, мы выберем именно этот способ.
Начальные условия для данного исследования были следующими:
- наиболее полными из находящихся в открытом доступе документов были спецификации для контроллера шасси сервера, запоминающего устройства и блока управления питанием. Именно они были выбраны для оценки частоты использования различных форматов;
- общий объём выбранных для исследования спецификаций составляет 230 страниц, из которых множество занимают различные неинформативные блоки: оглавления, изображения с примерами и так далее. Объём документации с релевантными данными составляет 185 страниц.
В результате исследования выявлено, что в рассматриваемых документах спецификаций представлены данные в следующих форматах:
Текст – 128 страниц, в том числе структурированный текст – 31 страница.
Таблицы – 40 страниц.
Формальные языки – 13 страниц.
Структурные диаграммы – 3 страницы.
Диаграммы коммуникации – 1 страница.
Из проведённого исследования видно, что основная часть спецификации (52% если не учитывать структурированный текст или 69% если учитывать его) представляет собой текст на естественном языке. Это подтверждается и другими исследованиями. Например, в работе [25], посвящённой в основном спецификациям программного обеспечения, говорится, что текст на естественных языках занимает до 90% всего объёма таких спецификаций.
Второй формат, широко представленный в исследуемых спецификациях -табличный. Он составляет 22% от всего объёма данных. Основная часть таблиц в исследуемой спецификации описывает сигналы, порты, через которые они передаются, и системные команды и функции. Стоит отметить, однако, что большинство таблиц, присутствующих в исследованных документах, имеют свободную форму и содержат значительное количество текста на естественном языке.
Несмотря на такую значительную долю таблиц в спецификациях, в литературе практически не встречается описаний табличных спецификаций вычислительных систем, потому как часто таблицы (особенно содержащие неформализованные данные в виде текста) либо ассоциируются с текстовым форматом, либо считаются слишком тривиальными, чтобы описывать представление информации с их помощью. Только несколько работ описывают применение таблиц на поздних стадиях процесса проектирования.
Например, возможности построения температурных моделей плат с помощью стандартного программного обеспечения для работы с таблицами и его агрегирующих функций раскрываются в работе [26].
Формальные языки занимают небольшую долю в исследованных спецификациях – 7%, причём большая часть из них представляет собой не модели системы, а описание скриптовых команд для различных действий по установке и настройке встроенного программного обеспечения. Причина такой малой доли формальных языков в спецификациях в том, что они применяются в основном на более поздних стадиях проектирования ВС. Однако, как говорилось в первой главе, есть и исключения – случаи, когда спецификации целенаправленно пишутся на формальных языках высокого уровня. В качестве ещё одного примера можно привести работу [27]. В ней рассматривается подход к моделированию системы на кристалле на высоком уровне абстракции с использованием языка SystemC для спецификации СнК. В качестве основного преимущества этого языка перед другими приводится тот факт, что множество проектов систем на кристалле де-факто на 80% состоят из программного обеспечения и только на 20% - из аппаратного, а SystemC отлично подходит для описания ПО. Также в статье приводится исследование процесса симуляции функционирования системы с использованием языка SystemC и оценивается производительность этого процесса. В работе [28] приводится формальное описание семантики такой симуляции работы ВС с использованием SystemC. И все же, несмотря на то, что ряд работ предлагает использовать формальные языки высокоуровневого моделирования в качестве языков создания спецификаций, этот подход применяется не слишком часто.
Небольшое количество информации, представленной в виде диаграмм, объясняется, скорее всего, тем, что исследуемые спецификации описывают структурные, а не поведенческие аспекты платформы. Поэтому применение в них поведенческих диаграмм и диаграмм коммуникации сильно ограничено, а структурные диаграммы обычно не составляют значительной доли в объёме описываемых данных. Совершенно другое представление о применении диаграмм в спецификациях ВС может дать литература.
В работах [29, 30] подтверждается, что диаграммы UML, как структурные, так и поведенческие, являются фактически стандартом высокоуровневого описания программных систем. В них также рассматриваются возможности переиспользования UML диаграмм в процессе разработки программного обеспечения. UML диаграммы используются практически повсеместно для описания программных систем, поэтому возможность их переиспользования чрезвычайно важна, так как позволяет экономить значительную часть времени работы аналитиков и архитекторов программных систем.
Однако у диаграмм UML существуют и другие области применения. В частности, процесс создания объектно-ориентированных моделей систем управления данными о продукте, представленных в виде UML диаграмм, рассматривается в работе [31].
Ещё один пример применения диаграмм UML - спецификация поведения киберфизических систем. В статье [32] представлена методика создания таких спецификаций. Для описания специфических для предметной области компонентов предлагается использовать такие механизмы расширения синтаксиса UML диаграмм, как UML профили и стереотипы.
Использование UML диаграмм для создания спецификаций логических контроллеров для встроенных систем рассматривается в работах [33-35]. Для обеспечения соответствия спецификации установленным пользователями требованиям к поведению контроллеров применяется формальная проверка модели, при которой требования приводятся к виду формул темпоральной логики, а диаграммы UML формализуются и переводятся в программный код.
Стоит отметить, что вышеперечисленные работы относятся ко всем видам UML диаграмм.
Методы создания и использования поведенческих спецификаций
Первым шагом разработки методов создания поведенческих спецификаций должен стать выбор моделей данных для их представления[89].
Для поведенческих спецификаций модель данных должна основываться на диаграммах деятельности. В современных процессах проектирования ВС используются в основном два типа таких диаграмм: UML-диаграммы деятельности [17] и нотации BPMN [22]. Соответственно, модель данных для поведенческих спецификаций будет строиться на их основе.
Выбор подмножества примитивов для разрабатываемой модели данных должен основываться на следующих критериях:
1) Читабельность диаграмм любыми потребителями спецификации.
2) Минимизация усилий архитекторов на освоение модели данных.
3) Возможность автоматической трансляции данных.
Рассмотрим набор базовых примитивов UML-диаграмм деятельности и нотаций BPMN и выберем из них необходимые для нашей модели. В набор основных примитивов UML-диаграмм деятельности входят:
1. Действие – примитив, описывающий атомарные операции, являющиеся по сути шагами представляемого алгоритма. Всегда имеет один входящий поток управления и один исходящий.
2. Решение – примитив, представляющий ветвление алгоритма. В UML-диаграммах деятельности присутствует два типа ветвлений: decision и merge. Первый тип соответствует логическому блоку, имеющему один входящий поток управления и несколько исходящих. Второй тип, напротив, имеет несколько входящих потоков управления и один исходящий.
3. Примитивы начала и конца алгоритма.
4. Разветвление и схождение ветвлений алгоритма. Этот примитив необходим для представления параллельного выполнения нескольких шагов алгоритма.
5. Примитив данных показывает, какие данные нужны для определённого действия либо какие данные действие производит.
6. Примитив «поток управления» показывает порядок выполнения действий.
7. Примитив «исключение» показывает ошибки в ходе выполнения алгоритма.
8. Агент – примитив, показывающий, кто выполняет определённое действие. Агенты служат контейнерами для других элементов диаграммы.
Все эти примитивы, за исключением примитивов расхождения и схождения, используются также и в нотациях BPMN. Роль примитивов расхождения и схождения алгоритма в BPMN выполняют примитивы решений (логические блоки). При этом блок decision (оператор «или») выполняет роль примитива расхождения алгоритма, если он имеет один входящий поток управления и несколько исходящих, а блок merge (оператор «и») выполняет роль примитива схождения ветвей алгоритма, если он имеет несколько входящих потоков управления и один исходящий. При этом становится необходимым визуально различать примитивы decision и merge. В нотациях BPMN эти примитивы имеют визуальные различия.
Вторым отличием UML-диаграмм деятельности и нотаций BPMN является наличие в BPMN различных версий примитива «действие». Помимо стандартных действий, нотации BPMN также предлагают циклические действия, а также подпроцессы – действия, ссылающиеся на вложенные диаграммы, определённые в другом месте (свёрнутые подпроцессы) или внутри данного примитива-действия (развёрнутые подпроцессы).
Третьим отличием BPMN является поддержка целого ряда примитивов-событий. Они обозначают какие-либо происшествия внутри или за пределами описываемого диаграммой процесса, которые различным образом влияют на этот процесс. В терминах BPMN начало и конец процесса являются событиями. Помимо них, BPMN содержит множество примитивов-событий, таких как таймеры, ошибки (соответствующие примитивам-«исключениям» в UML-диаграммах деятельности), отмены и компенсации транзакций, сигналы, переходы по ссылкам и другие.
Наконец, четвёртым отличием BPMN является различие в способах передачи управления между действиями внутри одного агента и между действиями разных агентов. В первом случае используется стандартный примитив потока управления, во втором – примитив передачи сообщения, обозначаемый пунктирной стрелкой.
Проанализируем необходимость использования описанных примитивов в модели данных для поведенческих спецификаций архитектуры систем на кристалле, представляющих собой главным образом системные протоколы. Нет никаких сомнений, что базовые примитивы – действия, решения, а также примитивы начала и конца процесса – необходимы в разрабатываемой модели данных. Для удовлетворения первых двух критериев выбора модели примитивы решений могут заменить примитивы расхождения и схождения ветвей алгоритма, как это сделано в нотациях BPMN. Так как большинство системных протоколов не оперируют значительными объёмами данных, примитивы данных могут также быть исключены из разрабатываемой модели. Примитивы «исключений» в большинстве случаев могут быть заменены либо примитивами окончания процесса либо передачей управления процессу обработки исключений, поэтому исключения также не обязательны в разрабатываемой модели данных.
Крайне значимым свойством системных протоколов является важность того, какой компонент системы выполняет то или иное действие, а также различие способов передачи управления между действиями внутри компонента системы и между компонентами системы. Для выражения этого свойства прекрасно подходят примитивы агентов и сообщений.
Ещё одно свойство многих системных протоколов – возможность представления их на различных уровнях абстракции. Для этого необходимо добавить в модель данных поддержку иерархичного представления процессов, для чего можно использовать, в частности, подпроцессы и примитивы перехода по ссылкам, доступные в нотациях BPMN.
Наконец, необходимо решить, включать ли в модель данных различные примитивы-события, доступные в нотациях BPMN. Так как в СнК сложные транзакции либо не используются, либо описываются целым протоколом (протоколом когерентности кэшей, к примеру), события, обозначающие отмену и компенсацию транзакций, не нужны в разрабатываемой модели данных. Для выражения событий передачи сигналов могут быть использованы либо примитивы сообщений, либо примитивы перехода по ссылке. Все варианты событий остановки процесса можно свести к одному, добавив к нему некоторый набор параметров. Наконец, события-таймеры, обозначающие регулярно происходящие события, также малополезны в разрабатываемой модели данных, так как большинство системных протоколов описывают события, занимающие крайне малые отрезки времени и не включающие регулярные действия.
Инфраструктура системы ACES и использования структурных спецификаций систем на кристалле
Инфраструктурная часть платформы ACES выполняет ряд важных функций:
1. Позволяет организовать рабочую среду создателей спецификаций. Для этого ACES предоставляет возможность конфигурировать структуру рабочей директории, содержащей документацию по проекту, а также предоставляет доступ к внешним хранилищам данных для спецификации.
2. Позволяет устанавливать связи между элементами спецификации, позволяя таким образом устранить её фрагментированность.
3. Предоставляет возможность навигации по документам спецификации и поиска различных её элементов по запросам.
4. Позволяет подключать внешние модули для расширения функциональности системы.
В качестве пользовательского интерфейса инфраструктурной части системы ACES выступает оконное приложение для просмотра доступных документов спецификаций, а также созданных с помощью системы ACES таблиц и диаграмм, содержащихся в них. Помимо этого в функции приложения входит поиск необходимых данных в имеющихся спецификациях и запуск глобальной проверки корректности для доступных документов спецификации. На рис. 4.4 представлен интерфейс программы.
Для начала работы необходимо загрузить рабочий проект – специальный файл, в котором определяются корневая директория, содержащая рабочие документы, свойства проекта: название и пути к внешним хранилищам данных, а также правила для проверки данных и создания перекрёстных ссылок между различными элементами спецификации
Внешние хранилища данных архитектурной документации используются для организации совместной работы команды архитекторов. Для этого такие хранилища данных должны предоставлять возможности размещения данных на сервере, управления доступа к ним, а также контроля версий документов. На данный момент в качестве внешнего хранилища данных, используемого системой ACES, выступает платформа Microsoft SharePoint – система управления данными от компании Microsoft. Помимо хранения данных, Microsoft SharePoint предоставляет широкие возможности по автоматизации управления проектами.
Стоит отметить, что проект ACES может быть подключён к нескольким внешним хранилищам данных (или к нескольким разделам одного хранилища). При подключении проекта к внешнему хранилищу данных в корневой директории проекта создаётся ссылка на него.
Так как форматы данных Microsoft Office не предназначены для быстрой обработки больших массивов данных, важнейшей составляющей инфраструктуры системы ACES является общая для всех документов спецификации в проекте внутренняя база данных, хранящая информацию обо всех документах в текущем проекте и позволяющая осуществлять быстрый доступ к данным и их обработку. Наличие такой базы данных позволяет создавать перекрёстные ссылки между различными элементами спецификации, а также использовать разные части спецификации вместе в целях генерации формальных моделей.
Необходимым условием для создания этой базы данных является общий для всех типов спецификаций промежуточный формат представления данных. В качестве такого промежуточного формата был выбран язык XML. Иерархичная структура и расширяемость языка XML позволяет представлять с его помощью как таблицы, так и диаграммы. К тому же, формат XML отлично подходит для обмена информацией с подключаемыми к системе ACES модулями, осуществляющими автоматическую обработку спецификаций. Ещё одним плюсом формата XML является удобство его восприятия человеком.
Внутренняя база данных создаётся и поддерживается в процессе работы в фоновом режиме. Для её построения все созданные в системе ACES таблицы и диаграммы в проекте транслируются в формат XML. Для каждого документа спецификации создаётся соответствующий ему XML-документ. Содержимое этих XML-документов регулярно проверяется на актуальность и обновляется при необходимости, а затем загружается в базу данных, находящуюся в памяти до завершения сеанса работы с ACES. Такая избыточность данных необходима для организации быстрой работы инфраструктуры системы. База данных предоставляет удобный интерфейс для быстрого доступа к данным в любых документах проекта, что является крайне важным для реализации поиска и валидации данных, а также для создания связей между ними.
Рассмотрим теперь различные сервисы, предоставляемые инфраструктурной частью системы ACES.
Важнейшим функциональным компонентом инфраструктуры системы ACES является механизм создания и использования перекрёстных ссылок между элементами архитектурной спецификации. Такие ссылки имеют несколько назначений.
Первое назначение перекрёстных ссылок – обеспечение навигации между логически связанными объектами. К примеру, если параметры элементов диаграммы записаны в таблицу, пользователь из любого элемента диаграммы легко может перейти к его записи в таблице параметров.
Второе назначение перекрёстных ссылок – обеспечение удобства создания и структурирования спецификаций. В качестве примера такого использования ссылок можно привести механизм записи атрибутов элементов диаграмм IFlow в таблицы ACES Tables, где механизм перекрёстных ссылок обеспечивает связность спецификации. Такой механизм даёт возможность ссылаться на один и тот же набор параметров из разных диаграмм, а также возможность быстро заменять конфигурацию диаграммы, изменяя ссылку, что очень полезно при наличии большого набора параметров.
Наконец, третье назначение перекрёстных ссылок между элементами архитектурной спецификации - совместное использование спецификаций для трансляции в исполняемые модели. При генерации исполняемых моделей из спецификаций, созданных при помощи системы ACES, сначала нужные элементы спецификации транслируются в ACES XML, который после этого передаётся на вход подключаемому модулю, отвечающему за создание исполняемых моделей. При наличии ссылок, связывающих выбранные для генерации модели элементы спецификации с другими, имеется возможность включить в XML и их. В примере с записанными в таблицу параметрами диаграммы IFlow это позволит записать в XML и саму диаграмму, и её конфигурацию.
Перекрёстные ссылки в ACES создаются двумя способами. Первый предполагает создание сразу целого класса ссылок. Процедура установки ссылок из описанных в файле конфигурации классов производится в начале сеанса работы с ACES. При обработке описанного примера выполняется поиск всех элементов диаграмм типа "Connecting Object" (коннекторов), среди которых выбираются только коннекторы типа "Message Flow", и эти элементы образуют множество возможных источников ссылки; затем выполняется поиск всех записей в таблицах типа "Message Attributes", и они образуют множество возможных целевых объектов ссылки. После этого процедура установки ссылок сравнивает ключи для каждой возможной пары источник, цель и создаёт ссылки для всех пар, ключи которых совпадают.
Такой способ создания ссылок удобен в случае, когда спецификации содержат большие объёмы однообразной информации.
Второй способ создания ссылок – определение их пользователем явным образом. Для крупных объектов, таких как документы, таблицы или диаграммы, ссылки могут задаваться средствами файлового менеджера ACES, для более мелких элементов спецификации они могут определяться в Excel и Visio.
В качестве примера ручного определения ссылок можно привести такую ситуацию: в элементе диаграммы IFlow «действие» изменяется значение некоторого контрольного регистра, и необходимо определить ссылку из диаграммы на запись в таблице, где определён этот регистр.
Для повышения эффективности работы со спецификациями реализован механизм поиска данных в рабочем проекте ACES. Пользователь имеет возможность как задать текст для поиска, так и ограничить область поиска необходимой информации с помощью различных фильтров, определяющих тип искомого объекта (документ, таблица, диаграмма) и его свойства (например, тип таблицы или диаграммы). Поиск возможен не только в локальной копии репозитория, но и во внешних хранилищах данных.