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

УЧРЕЖДЕНИЕ ОБРАЗОВАНИЯ

БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ИНФОРМАТИКИ И РАДИОЭЛЕКТРОНИКИ

Кафедра РЭС

РЕФЕРАТ

На тему:

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

МИНСК, 2008

1. Иерархия вычислительных систем и уровни моделирования

Материальный мир склонен к иерархии. Это значит, что любой объект можно представить как совокупность взаимодействующих частей, которые в свою очередь состоят из более мелких деталей. Например, сложные объекты вычислительной техники состоят из блоков, те в свою очередь - из устройств, устройства - из узлов, узлы из элементов, элементы - из компонентов (рис 1.)

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

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

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

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

Для вентильного уровня (Gate Level) - это логические элементы и триггеры (МИС). На транзисторном уровне - это радиодетали: транзисторы, диоды, резисторы, конденсаторы и прочие радиокомпоненты.

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

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

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

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

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

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

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

Рис. 1. "Египетские" пирамиды

Рассмотренная иерархия ВС представляет не только познавательный интерес. Она структурирует наше мышление и систематизирует мировоззренческое восприятие проблемы, раскладывая в буквальном смысле по полочкам - уровням изучаемый материал.

Посмотрим, как легко и естественно привязываются к уровням иерархии ВС различные виды моделирования и поведенческие описания (модели) структурных примитивов (рис. 2).

Рис. 2 Виды моделирования

Иерархия ВС позволяет разобраться и классифицировать взаимодействия примитивов на каждом абстрактном уровне (рис. 3)

Рис. 3 Виды взаимодействия структурных примитивов

Наконец, с помощью рассмотренной иерархии ВС легко выяснить, какие уровни поддерживает та или иная система моделирования (СМ) или САПР. Это позволяет сравнивать их между собой и выбирать наиболее подходящую (рис. 4).

Рис. 4 Системы и языки моделирования, поддерживающие отдельные уровни иерархии ВС

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

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

Окно проекта это узаконенный термин. Им обозначают группу уровней, с которыми работает конкретный разработчик. Таким образом, если Вы проектируете ЭВМ с использованием только БИС, то окно проекта может быть сужено всего до двух уровней: архитектурного и процессорного.

2. Разновидности проектирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература

Автоматизация проектирования радиоэлектронных средств: Учебное пособие для ВУЗов./ О.В. Алексеев, А.А. Головков, И.Ю. Пивоваров и др.: Под ред. О.В. Алексеева. - М.: Высшая школа, 2000.

Корячко В.П., Норенков И.П., Курейчик В.М., Теоретические основы САПР. М., «Энргоатомиздат», 2007г. - 400 с.

САПР. Системы автоматизированного проектирования. Уч. пособие для технических ВУЗов в 9-ти книгах. под ред. Норенкова И.П. М., «Высшая школа», 2006 г.

Деньдобренко Б.Н., Малика А.С., Автоматизация конструирования РЭА. Учебник для вузов. М., «Высшая школа», 2000 - 384с.