Управление сложными проектами в интегрированных САПР - часть 5

 

 

19

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

Во-вторых,  методология  нисходящего  проектирования  лучше  удовлетво-

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

В-третьих,  в  настоящее  время  наибольшее  распространение  получили 

САПР,  обеспечивающие  сквозной  цикл  проектирования  с  возможностью  мно-
гоуровневого  моделирования,  в  основе  которого  лежит  описание  объекта  на 
языках HDL, HHDL, VHDL и им подобных [11

−

15]. Базовой методологией про-

ектирования в подобных САПР является нисходящее проектирование. 

Основной недостаток у нисходящего проектирования тот же, что и у вос-

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

В силу перечисленных выше причин на практике редко применяют в чис-

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

 

1.1.5. 

Конвейер проектирования 

 
С  системной  точки  зрения  процесс  проектирования  представляет  собой  

последовательность преобразований описания объекта проектирования. Напри-
мер, процесс проектирования СБИС, выполняемый по методологии нисходяще-
го проектирования, можно представить как последовательность преобразований 

 

 

20

описательных уровней схемы (рис. 1.7). Каждый уровень этой последовательно-
сти  характеризуется  некоторыми  средствами  описания 

−

  языками,  описатель-

ными элементами и так далее [16]. 

 

Поведенческий:  алгоритмы  на
языке 

высокого 

уровня

(

переменные + операторы)

Системный:  язык  спецификаций
системы  (ввод-вывод)

Функциональный:  таблицы  ис-
тинности, 

язык 

регистровых

передач,  логические выражения

Логический: 

языки 

описания

структуры  физических  блоков,
субъэлементы,  вентили

Переключательный:  идеальный
переключатель

Электрический:  реальный  МОП-
транзистор

Шаблон: геометрия

 

Рис. 1.7. Последовательность преобразований   описаний СБИС 

 

Декомпозиция  каждого  описательного  уровня  схемы,  обусловленная  не-

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

[17].  

Работа конвейера может быть организована в синхронном или асинхрон-

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

 

 

21

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

Таким  образом,  процесс  проектирования 

−

  независимо  от  используемой 

методологии 

−

  является  многоэтапным,  т.е.  его  можно  представить  в  виде  по-

следовательности  преобразований  промежуточных  описаний  объекта  проекти-
рования,  выполняемых  проектными  процедурами.  Этап  проектирования 

−

  ус-

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

−

21]. 

В САПР обработка каждого проекта организуется по принципу информа-

ционного  конвейера,  обрабатывающими  элементами  которого  являются  при-
кладные программы, образующие технологический маршрут проектирования, а 
обрабатываемыми  объектами 

−

  фрагменты,  полученные    в  результате 

декомпозиции проекта. 

В работе [22] идея информационного конвейера проектирования получила 

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

 

 

22

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

Работа  последовательно-параллельного  конвейера  проектирования  осу-

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

 

1.1.6. 

Организация параллельного проектирования 

 
Эффективное  использование  САПР  предполагает  не  только  использова-

ние  иерархического  проектирования  и  конвейерной  обработки  проекта,  но  и 
возможность  выполнения  параллельного  проектирования  [23

−

26].  В  современ-

ных САПР сквозного проектирования можно выделить три уровня параллельно-
сти при выполнении проектных работ, а именно: 

одновременное выполнение нескольких различных проектов; 
одновременное  выполнение  ряда  проектных  процедур  одного  и  того  же 

проекта; 

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

быть  решена  в  рамках  интегрированной  САПР.  Однако  при  этом  следует  учи-
тывать специфические факторы, определяющие состояние и функционирование 
конкретных САПР [25]. К числу таких факторов относятся: 

наличие    разнородной    техники,    составляющей    информационно-

вычислительную инфраструктуру интегрированных САПР; 

наличие программных средств проектирования, которые разрабатывались 

в разное время и, как правило, вне рамок единой концепции; 

наличие разнородных баз данных, используемых проектными процедура-

ми (в данном случае 

−

 проектирующими подсистемами);