Проблема создания системной среды САПР изделий электроники

Архитектура системной среды

Cовременное представление об архитектуре framework, предложенное CFI [11], показано на рис.1. Сервисное программное обеспечение framework подразделяется на компоненты. Каждый компонент имеет программный интерфейс (набор функций), который определяет возможности, предоставляемые компонентом.

Важнейший компонент framework - ядро - предоставляет базовые средства, необходимые для работы других компонентов. Программные модули и компоненты framework обмениваются сообщениями, регламентированными CFI, через ядро.

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

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

Управление методологией предоставляет:

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

Представление проекта

Представление проекта является одной из узловых проблем создания системной среды САПР. Общепризнанный подход к ее решению базируется на использовании информационной модели (IM) и программного интерфейса (PI). Стандартами представления проектных данных являются информационная модель и программный интерфейс, предложенные CFI [12] и ориентированные на работу с иерархическим представлением схемы соединений, используемым во многих задачах моделирования и синтеза БИС. Отметим, что понятия IM и модели данных не эквивалентны. Поставщик САПР или прикладного программного модуля может использовать удобную для него модель данных для хранения проектной информации, но при этом должны быть обеспечены ее представление в виде информационной модели и доступ через программный интерфейс. Таким образом, обеспечивается доступ к проектным данным конкретной САПР без раскрытия внутренних физических структур данных, которые по своей организации могут не соответствовать IM.

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

TYPE cfidrObjectType = ENUMERATION OF
(CFIDR_LIB, CFIDR_CELL, CFIDR_INST, CFIDR_PORTBUNDLE,
CFIDR_PORTSCALAR, CFIDR_PORTINSTBUNDL,
CFIDR_PORTINSTSCALAR, CFIDR_NETBUNDLE,
CFIDR_NETSCALAR, CFIDR_PROP, CFIDR_VIEW);
END_TYPE;

ENTITY cfidrObject
ABSTRACT SUPERTYPE OF
(ONEOF (cfidrNamedObject, cfidrPortInst));
  ObjectType:cfidrObjectType;
ObjectId:cfidrObjectId;
Props:SET[0:?] OF cfidrProp;
WHERE UNIQUE_NAMES(Props);
END_ENTITY;

Для разработчика программных модулей САПР представляет интерес модель на уровне сущностей, таких, как библиотека (Lib), ячейка (Cell), вид (View), цепь (Net), порт (Port) и др. Такая модель, названная базовой моделью соединений (BCM), отражает современную точку зрения на представление иерархического списка соединений.

BCM позволяет рекурсивно описать сложный проект путем связывания менее сложных подпроектов. Конкретная реализация проекта представлена через сущность View, а подпроекты в составе View представлены сущностями Inst (экземпляр).

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

Для представления внутри View соединений между PortInst и Port используется сущность Net. Важной особенностью BCM является наличие понятий Scalar и Bundle (связка). Последнее позволяет описать сборки цепей и портов путем применения Scalar и Bundle к сущностям Net, Port, PortInst. На рис.2 в качестве примера приведен фрагмент информационной модели. Красные линии иллюстрируют связь базовой модели соединений с базовой объектной моделью (Lib, Cell, View, Port являются поименованными объектами).

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

Управление проектными данными

Одно из важнейших требований к системной среде заключается в поддержке коллективной разработки сложных изделий электроники. В целях создания таких средств поддержки на ранней стадии развития framework выполнен ряд исследовательских и практических работ по управлению проектными данными [23-26]. В основном эти работы ориентированы на управление проектными версиями и конфигурациями. Ввиду крайней важности, исследования в этой области продолжаются до настоящего времени [13,14]. Здесь мы коснемся только наиболее важных сторон этой проблемы, рассмотрев в качестве примера работу с конфигурациями проекта в рамках Design Data Management Framework (DDMF) фирмы Valid Logic Systems [15].

DDMF можно рассматривать как обобщенную файловую систему, расширенную в целях обеспечения дополнительных возможностей по управлению данными. DDMF использует коммерческую объектно-ориентированную базу данных. Проектная мета-информация представлена в DDMF как объекты языка C++. Каждый такой объект сопровождается информацией о сответствующих ему проектных данных: имя, владелец, права доступа и т.п.

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

Большинство объектов, хранящихся в DDMF, представлены версиями, которые возникают при внесении изменений. История версий хранится в виде ориентированного графа без циклов.

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

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

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

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

Управление методологией проектирования

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

Исследования в области управления методологией интенсивно проводились в течение нескольких последних лет и проводятся в настоящее время. В университете Карнеги-Меллона, который является в данной области лидирующим научным центром США, пройден путь от ранних, сравнительно несложных систем Ulyses [16], CADWELD [17] и других до комплексной, многоуровневой среды Odyssey CAD Framework, в которой в едином ключе осуществляется управление ресурсами, задачами и процессами [18-23]. Известна также Европейская научная школа с центром в Дельфтском техническом университете, которая получила в рамках проекта NELSIS ряд интересных результатов в области управления проектными задачами [24,25]. Из промышленных разработок получила известность система управления методологией MMS ф. MCC [26,27]. Обзор перечисленных разработок дается в настоящем разделе.

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

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

Пример описания прикладного модуля bdsyn дан ниже. Описание является декларативным и содержит спецификацию файла и аргументов командной строки. Последние поясняются строкой комментария в блоке optional-args.

deftool bdsyn (bds-file blif-file &optional collapse)
(version 1.1)
(tool-name "bdsyn") ;actual name of executable (doc "Behavioral synthesis tool. See 'man bdsyn'")
(optional-args;
("-b" nil "do not do clean-up evaluation")
(collapse nil "how much collapse to do")
("-n" nil "print table of non-assigned variables"))
(args ("-u" nil "provide periodic updates of progress")
("-z" nil "assign 'dont cares" to zero"))
(input-file bds-file nil "BDS file to be translated" "")
(output-file blif-file nil "Berkeley logic interchange file" ">"))

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

(deftask syntest (design)
(file-prefix design ".")
(dependencies (bds blif pla cell array)
(steps
(gen-logic-equations (bdsyn bds blif))
(synthesize-standard-sell
  (syn-standard-cell design blif cell))
(synthesize-gate-array (gem design blif array))
(synthesize-pla (octpla design blif pla))
(compare-results (compare array cell pla)) )))

Мета-язык системы допускает параметризацию задач, что позволяет, например, генерировать процессы моделирования на Spice для их последующего параллельного выполнения.

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

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

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

В отличие от MMS, в системной среде NELSIS [24,25] возможные методологии описываются в виде так называемых карт потоков (Flowmap), которые играют ключевую роль в обеспечении гибкости управления процессом. Карта потока строится с учетом следующих предпосылок. Данные, порождаемые одним модулем, будут использоваться в качестве входных для других программных модулей. В карте модули представляются как функциональные единицы, имеющие входные и выходные порты (Ports) и соединенные каналами передачи данных. Коммутации между модулями описываются в терминах абстрактных типов данных. Предоставление возможности иерархического описания потоков дает ряд преимуществ. Оно позволяет определить сложные проектные функции. Кроме того, можно собрать в одном составном потоке сходные действия, выполняющие практически одну и ту же функцию. Тем самым сокращается сложность пользовательского интерфейса за счет скрытия деталей и организации высокоуровневых проектных задач, а пользователю в процессе проектирования предоставляется возможность выбора одной альтернативы из нескольких возможных при решении одной и той же проектной задачи.

На рис.3,a показан пример иерархии потоков, а на рис.3,b дано изображение составного потока D.

О рассмотренных подходах, воплощенных в MMS и NELSIS, можно сказать, что они базируются на заблаговременном описании потока в виде карты или на языке расширения. Важно подчеркнуть, что задача описывается и заносится в framework заранее, до ее использования в проектировании. А все рассмотренные подходы отличаются друг от друга только способом описания.

В этом смысле принципиально новый метод управления задачами разработан S.W.Director, J.B.Brockman и P.Sutton в рамках системы управления проектными задачами Hercules в системной среде Odyssey CAD Framework [18-23]. Он ориентирован на то, что нужный поток создается пользователем САПР прямо в процессе проектирования. Для этого используются заранее занесенные в систему правила генерации задач. Они описываются в виде так называемой схемы задач (Task Schema).

Схема задач - это граф, описывающий (в терминах сущностей, экземпляров и связей) правила комбинирования программных модулей и данных в проектную задачу. Пример схемы задач показан на рис.4. Здесь сущности представляют собой классы объектов, которыми могут быть как прикладные программы, так и данные. Связи между сущностями определяют те роли, которые эти сущности играют в контексте задачи. Они представлены стрелками, направленными из целевой сущности к поддерживающей сущности. Функциональная связь, помеченная f, означает, что экземпляр поддерживающей сущности является прикладной программой, генерирующей экземпляр целевой сущности. Связь по данным, помеченная d, означает, что экземпляр поддерживающей сущности является файлом данных, необходимым для генерации экземпляра целевой сущности.

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

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

Выводы

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

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

ЛИТЕРАТУРА