63432 (573400), страница 2
Текст из файла (страница 2)
Различают нисходящее (сверху вниз) и восходящее (снизу вверх) проектирование. При нисходящем проектировании выполняются прежде этапы использующие высокие уровни представления устройств, чем этапы использующие более низкие иерархические уровни. При восходящем проектировании последовательность противоположная.
При рассмотрении дерева проекта можно указать на две концепции проектирования: восходящее проектирование (снизу вверх) и нисходящее (сверху вниз). Здесь словом "верх" обозначается корень дерева, а слово "низ" относится к листьям. При нисходящем проектировании работу можно начинать уже тогда, когда разработчику уже известны только функции корня, - и он (или она) производит, прежде всего, разбиение корня на некоторое множество примитивов нижележащего уровня.
После этого разработчик переходит к работе с нижележащим уровнем и осуществляет разбиение примитивов данного уровня. Подобный процесс продолжается до тех пор, пока дело не дойдет до узлов-листьев проекта. Для характеристики нисходящего проектирования важно отметить то, что разбиение на каждом уровне оптимизируется согласно тому или иному объективному критерию. Здесь разбиение не связывается рамками того, "что уже имеется".
Термин "восходящее проектирование" не совсем правилен в том смысле, что процесс проектирования по прежнему начинается с определения корня дерева, однако в этом случае разбиение осуществляется с учетом того, какие компоненты уже имеются и могут использоваться в качестве примитивов; другими словами, разработчику при разбиении приходится исходить из того, какие составные части будут представляться в узлах-листьях. Эти самые "нижние" части будут проектироваться в первую очередь. Нисходящее проектирование кажется самым подходящим подходом, однако его слабость в том, что получаемые компоненты не являются "стандартными", вследствие чего стоимость проекта увеличивается. Поэтому наиболее рациональным представляется сочетание методов восходящего и нисходящего проектирования.
Согласно прогнозам подавляющее большинство инженеров-разработчиков средств электронной и вычислительной техники будут пользоваться нисходящей методологией. Они станут, по сути, инженерами-системотехниками, причем значительную часть своего времени будут затрачивать на проектирование изделий на поведенческом уровне.
В настоящее время проектирование электронных систем осуществляется по восходящей методологии, причем первым этапом процесса проектирования является обычно ввод описания схемы на структурном уровне (очевидно, на уровне ИС и дискретных компонентов). После определения структуры вводится описание поведения этой системы на том или ином языке описания этой аппаратуры и осуществляется модулирование. В этом случае электронная часть проекта выполняется вручную, то есть без применения инструментальных средств проектирования.
Усложнение проектируемых систем приводит к тому, что разработчики практически теряют возможность интуитивно анализировать проект, то есть оценивать качество и характеристики спецификации проекта системы. А моделирование на системном уровне с использованием архитектурных моделей (как первый этап процесса нисходящего проектирования) представляет такую возможность.
В случае нисходящего проектирования, описанные выше два этапа восходящего проектирования, выполняются в обратном порядке. При нисходящем проектировании основное внимание уделяется поведенческому представлению разрабатываемой системы, а не ее физическому или структурному представлению. Естественно, что конечный результат нисходящего проектирования также представляет собой структурное или схемное представление проекта.
Здесь дело в том, что для нисходящего проектирования необходимы системные архитектурные модели, а для восходящего - структурные модели.
Преимущества (для всех САПР):
1) Методология нисходящего проектирования служит предпосылкой для параллельного проектирования: координированной разработки аппаратных и программных подсистем.
2) Внедрению метода нисходящего проектирования способствуют средства логического синтеза. Эти средства обеспечивают преобразование логических формул в физически реализуемые описания уровня логических вентилей.
Благодаря этому:
упрощается физическая реализация
эффективно используется время проектирования
эффективно используются технологические шаблоны
Однако для сложных проектов, масштабы которых выражаются несколькими сотнями тысяч логических вентилей, желательно иметь возможность глобальной оптимизации благодаря моделированию и анализу на системном уровне.
3) Методология нисходящего проектирования базируется на том, что автоматически создается спецификация проекта по исходным функциональным требованиям. Именно функциональные требования являются исходным компонентом при проектировании сложных систем. Благодаря этому подобный подход позволяет уменьшить вероятность неработоспособной системы. Во многих случаях неработоспособность проектируемой системы вызывается несоответствием между функциональными требованиями и спецификациями проекта.
4) Еще одним потенциальным преимуществом нисходящего проектирования является то, что оно позволяет разрабатывать эффективные тесты для верификации и аттестации проекта, а также тест-векторы для контроля изготовленных изделий.
5) Результаты моделирования на системном уровне могут послужить основой для количественной оценки проекта уже на начальных стадиях проектирования. На более поздних этапах для верификации и аттестации проекта необходимо моделирование на уровне логических вентилей. Однородная среда проектирования позволит сравнить результаты моделирования, получаемые на первых и на последующих этапах проектирования.















