Разновидности проектирования - Разновидности проектирования. Иерархия ВС и уровни моделирования

С иерархией объекта тесно связаны понятия нисходящего и восходящего проектирования. Часто их называют иначе - проектирование "сверху вниз" и "снизу вверх" (рис. 5).

разновидности иерархического проектирования

Рис. 5. Разновидности иерархического проектирования

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

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

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

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

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

Таким образом, иерархию объекта можно представить в структурной форме в виде дерева проекта, показанного на рис. 6.

структурная декомпозиция проекта

Рис. 6. Структурная декомпозиция проекта

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

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

Такие модели в отличие от поведенческих называют структурными, а процедура их построения в математической форме выглядит так:

Где D, U, E, C - соответственно устройство (Device), узел (Unit), элемент (Element) и компонент (Component).

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

Обычно это происходит по двум причинам: либо проектирование ведется на уровне корпусов ИМС (Chip Level Design) и примитивом может оказаться как логический элемент, так и большая интегральная схема, либо проектировщик использует многоуровневое моделирование, при котором неразработанные еще части проекта временно представляются в виде поведенческих моделей.

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

Такие повторяющиеся в проекте части удобно представлять в виде макромоделей. Здесь прослеживается прямая связь между командой и макрокомандой.

Для пользователя макрокоманда записывается одной инструкцией и выглядит как простая команда. В действительности, в ней "спрятано" много простых команд и система (например, транслятор) выполнит необходимую замену.

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

Такие ложные примитивы называют иерархическими примитивами, сохраняя за ними обозначение, принятое для фрагментов схемы в виде прямоугольника со скругленными углами (рис. 8).

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

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

Восходящее проектирование выполняется в противоположном направлении, то есть снизу вверх (Down Up Design).

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

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

Вся история развития микросхемотехники являет собой пример проектирования снизу вверх - от элементов (МИС) к узлам (СИС), потом к устройствам (БИС) и блокам (СБИС).

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

Объект проектирования декомпозируется на фрагменты (подсхемы) и проектирование каждого из них ведется в определенном смысле самостоятельно. На каждом уровне иерархии этот принцип применяется вновь.

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

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

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

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

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

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

При многоуровневом моделировании различные части объекта (фрагменты) представлены с разной степенью детальности, то есть на различных уровнях иерархии. Например, проектируемая в данный момент времени часть объекта раскрыта до вентильного уровня и имитируется структурной моделью, а остальные фрагменты представлены на соседнем более высоком регистровом уровне в виде поведенческих моделей.

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

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

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

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

Похожие статьи




Разновидности проектирования - Разновидности проектирования. Иерархия ВС и уровни моделирования

Предыдущая | Следующая