Программные продукты и системы

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

Выбор подмножества процедур, которые целесообразно реализовать аппаратно, и способов их реализации не является однозначным. Существует определенный баланс между функциями, которые более эффективно выполняются в специализированных средствах, и теми, которые выгоднее выполнять (или вынужденно будут исполняться) в центральном процессоре системы. Для его достижения требуется использование унифицированного подхода к разработке аппаратно-программных систем, динамично учитывающего свойства реализуемого алгоритма, возможности и ограничения аппаратных средств. Такой подход называют сопряженным проектированием [1-5]. Основа методологии сопряженного проектирования – параллельная, взаимосвязанная проработка программных и аппаратных средств, которая позволяет добиваться качественных показателей проекта и снижения сроков проектирования.

В настоящей статье излагается структура системы поддержки сопряженного проектирования и представляются ее основные программные модули.

Структура системы сопряженного проектирования и общие требования к ее компонентам. Концепция сопряженного проектирования предполагает решение следующих взаимосвязанных вопросов.

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

·     Создание библиотек возможных исполнителей алгоритмов, типичных для предполагаемых областей применения. Каждый объект такой библиотеки представляет некоторую задачу и включает несколько вариантов программной реализации, например в форме С++-кодов, а также несколько вариантов реализующих структур, например представляемых как описания на языках схемотехнического проектирования типа VHDL. Эти варианты сопровождаются количественными характеристиками возможных исполнителей, такими как время исполнения, затраты памяти, используемые ресурсы микросхем программируемой логики.

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

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

Центральной проблемой создания системы сопряженного проектирования является создание базы данных (БД) и обеспечение взаимодействия с ней различных программных модулей на всех этапах выполнения проекта, в связи с этим программное приложение строится вокруг стандартной реляцион- ной БД (РБД). Взаимодействие с БД удобно осуществлять с использованием объектно-ориентированного подхода. Это позволяет обращаться к ней через обращения к методам класса, при этом часть данных хранится непосредственно в объекте, а другая часть получает их из базы через соответствующий SQL запрос. Такой подход позволяет на каждой стадии решения задачи в оперативной памяти хранить только самые необходимые данные. Система сопряженного проектирования открытая, то есть должна позволять БД возможными реализациями задач изменять критерии оптимизации и т.д.

Рассмотрим взаимодействие объектов в системе на каждом этапе создания проекта. Последовательность этапов проектирования представлена на рисунке 1.

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

На рисунке 2 показан фрагмент диаграммы классов, описывающей проект. Диаграмма изображена в соответствии с нотацией Буча [7] и дает общее представление о системе. Конструкция <имя>Set означает контейнер для хранения объектов типа <имя>. Вся информация о проекте формируется в объек- те класса Circuit. На этом этапе пользователь вы- бирает требуемый компонент (Component) из таблицы ComponentTable базы. Компоненты (component), порты ввода/вывода (port) и настройки компонента (generic) задаются в соответствии с синтаксисом и семантикой языка VHDL.

После добавления компонента на схему проекта автоматически считываются параметры портов ввода/вывода из таблицы БД PortsTable.

Порт ввода/вывода на диаграмме классов представлен классом Port. Пользователю требуется соединить порты между собой сигналами (Signal). Таким образом, порт будет иметь ссылку на сигнал, а он, в свою очередь, набор ссылок на порты, которые на него ссылаются.

Для каждого компонента пользователь задает набор настроек (VaryGenericSet), при этом для каждого параметра настройки можно задать не одно значение, а последовательность значений (NumSet), которые могут перебираться в процессе оптимизации.

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

После установки и соединения компонентов пользователь запускает распаковку характеристик реализаций для всех выбранных компонентов. При этом для каждого компонента перебираются все возможные комбинации значений параметров настройки (VaryGenericSet) и для каждой комбинации строятся реализации компонентов (Model). Численные характеристики реализации компонента синтезируются генератором характеристик (PerformMaker). Объект этого класса инициализируется из файла с расширением .pfm и именем из поля FileName таблицы БД текущего компонента. Генератор характеристик формирует только приблизительные характеристики на основе аппроксимации массива ключевых точек. Для каждого компонента генерируются следующие характеристики: число занимаемых логических ячеек на кристалле, время вычисления первого результата, время вычисления последующих результатов при конвейерной обработке. В процессе генерации эти данные заносятся в структуру характеристик (Perform), которая хранится как член класса исполнителей (Model).

После выполнения распаковки характеристик реализаций проект содержит взаимосвязанные компоненты, имеющие список характеристик для каждого исполнителя.

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

Известен довольно широкий спектр методов структурной оптимизации, базирующихся на различных критериях качества и стратегиях поиска решения. Метод ветвей и границ удовлетворительно работает для случаев линейных ограничений [8]. Метод выравнивания загрузки [3] реализует последовательное перенесение исполняемых фрагментов задачи в недогруженные компоненты или включение новых компонентов на место перегруженных на основе оценок, получаемых с применением теории массового обслуживания, или на основе оценок времени передачи информации по критическому пути [7]. При большой размерности задачи и нелинейных критериях используют стохастические методы [8], основанные на случайных перемещениях точки, отображающей реализацию проекта в пространстве структурных переменных.

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

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

Компоновка. Для решения задачи объединения модулей, назначенных для аппаратной реализации, создан линкер аппаратных модулей на основе описания компонентов в языке VHDL.

Принята концепция, основанная на автоматической генерации сводного текстового VHDL модуля типа структурного архитектурного тела, в котором использованные компоненты представлены синтаксической конструкцией вхождения (component instantiation statement). Причем ссылки на тексты, представляющие прототипы компонентов, выбираются из БД. Это во многом связано с невозможностью фрагментарной загрузки в современных микросхемах программируемой логики.

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

Если в процессе реализации прикладной задачи в программно-аппаратной среде выполняется обращение к компоненту, реализованному программно, из аппаратного модуля вызывается аппаратный менеджер, с помощью которого передаются данные программному менеджеру через интерфейс ПК (ISA, PCI). Менеджер вызывает метод Calculate соответствующего класса, передавая ему адрес буфера обме- на. В моменты окончания вычисления в ядре программный менеджер передает данные в аппаратную часть.

Компоненты системы записаны на языке C++ и отлажены на тестовых задачах. В настоящее время проводится интеграция модулей в единый программный комплекс.

Список литературы

1.        Franke D., Purvis M. Hardware/software codesign. Proc. 13th intern. Conf. Software Eng.// IEEE PS Pres. 1991. p. 344–352.

2.        Graham R. The revolution in systems engeneering. //IEEE Spectrum, 1999, september p. 43-51.

3.        Kalavade A.P. System-level codesign of mixed hardware-software systems (ftp://ic.eecs.berkeley.edu/pub/HWSW/publications).

4.        Kumar S., et al. A framework for hardware/software codesign. //IEEE Computer, 1993. december. p. 39 - 45.

5.        Schulz S., Rozenblit J., Mrua K., Buchenrieder K. Model-based codesign. //IEEE Computer, 1998, august p.60-67.

6.        Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++, 2-е изд./Пер. с англ. - СПб.: Невский диалект, 1999.

7.        Mursaew A.Ch, Shishow O.V. Logical-linquistic approach to structural synthesis of mixed systems.// Proceedings of the Int.Conf on Computer-aided design of discretwe devices. Minsk, 1995.

Цвиркун А.Д. Основы синтеза структуры сложных систем. - М.: Наука, 1982