Составители:
36
университета Беркли (США) и Туринского политехнического университета
(Италия);
• PTOLEMY– универсальная система моделирования гетерогенных систем
калифорнийского университета Беркли (США);
• CoWare – система проектирования гетерогенных однокристальных
компонент на основе программируемых схем с перестраиваемой структурой.
Леувен, Бельгия.
1.2.2.2 Концепция платформно-ориентированного проектирования
Методология PBD (Platform Based Design) [36, 69] появилась несколько лет
назад в контексте комплексного системного проектирования аппаратно
-
программных ВсС и занимает особое место среди перспективных технологий
решения задач проектирования. Основные положения данной концепции
отражены в работах [78, 70, 54, 31]. Авторы концепции утверждают, что она
позволит повысить производительность проектируемых систем, снизить их
стоимость, стоимость разработки, а главное – позволит повторно использовать
как аппаратные, так и программные компоненты разрабатываемых систем.
Данная концепция проектирования,
продвигаемая интернациональным
сообществом, возглавляемым группой исследователей из Калифорнийского
университета в Беркли (США) развивалась в значительной мере со стороны
«проектирования аппаратуры»: руководители группы являются техническими
идеологами ведущих фирм-разработчиков САПР электроники и микросхем,
таких как Cadence, Synopsys, Mentor Graphics. Достоинства PBD – унификация
взгляда на программные и аппаратные компоненты системы, явный приоритет
архитектурного этапа проектирования, ориентация на
математическую
формализацию процесса создания и анализа моделей системного уровня (в виде
«моделей вычисления» (model of computation, MoC)).
Основной упор в своей работе авторы делают на качественное повышение
коэффициента повторного использования на всех этапах проектирования ВсС.
В жестких условиях рынка решением является повторное использование
компонентов системы (плат или их частей, драйверов, интерфейсов и т.п.).
Для
лучшей проработки альтернативных решений, что важно для повторного
использования, предлагается рассматривать систему с двух ракурсов и с
различных точек зрения:
• функциональность (что система делает) и архитектуру (как система это
делает);
• взаимодействие (обмен данными) и вычисления (выполнение целевой
функции системы).
Функциональность может определяться либо разработчиком, либо
заказчиком. В
первом случае в процесс разработки включается этап
функционального проектирования. Архитектура определяет интерфейс и
описывает функциональность реализации. При этом она должна не зависеть от
Страницы
- « первая
- ‹ предыдущая
- …
- 35
- 36
- 37
- 38
- 39
- …
- следующая ›
- последняя »
