Направления исследований в области framework
Архитектура системной среды
Представление проекта
Управление проектными данными
Управление методологией проектирования
Выводы
Литература

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


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

Первые промышленные framework были разработаны фирмами Cadence Design Systems [1] и EDA Systems [2] во второй половине 80-х годов. Ранний этап развития framework подробно представлен в обзоре [3] и в монографии [4]. За прошедшее после этого десятилетие была глубже понята концепция системной среды САПР, сформировались направления исследований и международные инфраструктуры, поддерживающие эти направления, и, как следствие, были получены многочисленные научные и практические результаты.

Направления исследований в области framework

Отличительной особенностью исследований в области системной среды САПР является их основополагающий характер. Framework, как среда для создания конкретных промышленных систем проектирования ИС, определяет архитектуру будущей САПР, возможности управления проектом, диктует стандарты подключения прикладных программных модулей и организации пользовательского интерфейса. В целях выработки общих требований, архитектуры и стандартных спецификаций системной среды в США в 1988 году был создан консорциум CAD Framework Initiative (CFI), объединяющий в настоящее время на добровольной основе более 40 фирм-поставщиков средств САПР [3-9]. Деятельность CFI, а также ее Европейской ветви EuroCFI, достаточно подробно охарактеризована в литературе [10]. Здесь мы отметим, что основными направлениями деятельности CFI, а также коммерческих и исследовательских организаций в области framework, в настоящее время являются:

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

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

    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;

    Ниже показано описание задачи синтеза, в которой использован прикладной модуль 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, университета Карнеги-Меллона, Дельфтского технического университета и ряда фирм.


    ЛИТЕРАТУРА

    1. H.-F.S.Law, et al. Skill, an interactive procedural design environment. - Proceeding IEEE Customer Integrated Circuits Conf., Portland, OR, May 1986, pp. 544-547

    2. J. Brouwers, M. Gray. Integrating the electronic design process.- VLSI System Design, June 1987

    3. D.S.Harrison, A.R.Newton, R.L.Spickelmier, T.J.Barnes. Electronic CAD Framework.- Proceeding of the IEEE, Vol.78, # 2, February 1990, pp. 393-417

    4. T.J. Barnes, D.S. Harrison, A.R. Newton, R.L.Spickelmier. Electronic CAD Frameworks.- Kluwer Academic Publishers, USA, 1992, 195 p.

    5. S.Evanczuk. Surwey Shows Limited User Involvement. - The Initiative, Fall 1991, p. 18

    6. B. Carver, A. Sanders. The CFI Procedural Interface. - DEC Professional, Nov. 1990, pp.38-42

    7. A. Graham. CFI - Who we are and what we plan to do. - Computer Design, October 1, 1990, p. 88

    8. Ш.ван Тайл. Современные консорциумы - что это такое. - Электроника, 1995, вып., с. 75-81

    9. J. Miller, E. Abel. CFI Gains Momentum In Europe. - The Initiative, Fall 1991, pp. 14-15

    10. В.А. Шепелев. Проблема организации framework САПР СБИС. - Системы и средства телекоммуникаций, М., 1993, вып. 5-6, с. 4-17

    11. Architecture Tiger Team. Framework Views Provide Architectural Insight. - The Initiative, Fall 1991,pp.8-12

    12. Design Representation. Electrical Connectivity. Programming Interface. Electrical Connectivity. - Version 1.0.0-112592, CFI, 1992

    13. G. Heidenreich, M. Minas, D. Kips. A New Approach to Consistency Control in Software Engineering. - Proc. 18th International Conference on Software Engineering, IEEE, 1996, pp. 289-297

    14. Y-J. Lin, S.P. Reiss. Configuration Management with Logical Structures. - Proc. 18th International Conference on Software Engineering, IEEE, 1996, pp. 298-307

    15. S. Banks, C. Bunting, R. Edwards, L.Fleming, P. Hackett. A Configuration Managrment Sysytem in a Data Management Framework.- Proceeding of 28th ACM/IEEE Design Automation Conference, June, 1991, pp. 699-703

    16. M. Bushnell, S.W. Director. Automated Design Tool Execution in the ULYSSES Design Environment.- IEEE Trans. on Computer Aided Design, Vol. 8, # 3, March, 1989, pp. 279-287

    17. J. Daniel, S.W. Director. An Object-Oriented Approach to CAD Tool Control Within a Design Framework.- Proceeding 26th Design Automation Conference, June, 1989, pp. 197-202

    18. J.B. Brockman, T.F. Cobourn, M.F. Jacome, and S.W. Director. The Odyssey CAD Framework. - IEEE DACT Newsletter on Design Authomation, Spring, 1992

    19. J.B. Brockman, S.W. Director. The Conceptual Schema: A New Basis for CAD Framework organization. - In Techcon'90 - Extended Abstract Volume, Semiconductor Research Corporation, 1990, pp. 35-38

    20. J.B. Brockman, S.W. Director. The Hercules CAD Task Management System. - Proceedings of the International Conference on Computer-Aided Design, IEEE/ACM, November, 1991, pp.254-257

    21. P.R. Sutton, J.B. Brockman, S.W. Director. Design Management Using Dinamically Defined Flows. - Proceedings of the 30th ACM/IEEE Design Authomation Conference, 1993, pp. 648-653

    22. M.F. Jacome, S.W. Director. Design Process Management for CAD Frameworks. - Proceedings of the 29th ACM/IEEE Design Authomation Conference, 1992

    23. J.C.Lopez, M.F.Jacome, S.W.Director. Design Assistance for CAD Frameworks. - Proceedings of the First GI/ACM/IEEE/IFIP European Design Authomation Conference, 1992

    24. K.O.ten Bosch, P.Bingley, P.van der Wolf. Design Flow Management in the NELSIS CAD Framework. - Proceeding of 28th ACM/IEEE Design Automation Conference, June, 1991, pp. 711-716

    25. P. van der Wolf, P.Bingley, P.Dewilde. On the Architecture of a CAD Framework: The NELSIS Approach. - Proceedings of the First GI/ACM/IEEE/IFIP European Design Authomation Conference, 1992

    26. W.Allen, D.Rosental, K.Fiduk. Distributed Methodology Management for Design-in-the-Large. - IEEE, 1990, pp. 346-349

    27. W.Allen, D.Rosental, K.Fiduk. The MCC CAD Framework Methodology Management System.- Proceeding of 28th ACM/IEEE Design Automation Conference, June, 1991, pp. 694-698

    Канаев М.Б.