Microsoft Word впвс book 2011 sev pa doc

1.2.2.1.1 Технология CoDesign 
Предлагаемый в рамках CoDesign процесс проектирования схематично 
представлен на рис. 1.7. 
Рис. 1.7. Процесс проектирования в рамках Codesign [47] 

---

35 
CoDesign предлагает следующие этапы технологии проектирования: 
• Разработка требований; 
• Разработка модели поведения системы на базе формального подхода (сети 
Петри, CFSM и т.д.); 
• Формальный анализ модели, верификация, симуляция, уточнение 
требований; 
• Декомпозиция на аппаратную и программную составляющую; 
• Выдача ТЗ для разработчиков программной и аппаратной составляющих или 
автоматическая генерация кода. 
Переход к разделению на программную и аппаратную компоненту может 
происходить по целому ряду методик:
• Simulated annealing algorithm (Henkel, Ernst); 
• All hardware solution (Gupta, De Micheli); 
• Алгоритм динамического программирования, основанный на алгоритме 
Ранца (Jantsch); 
• Алгоритм динамического программирования PACE (LYCOS) [56]. 
В целом эти методики представляют собой последовательность синтеза и 
анализа вариантов разделения. В некоторых методиках происходит переход от 
чисто программной к аппаратной реализации (например, Simulated annealing 
algorithm), в некоторых от аппаратной к программной (например, в All hardware 
solutions).
После разбиения на аппаратные и программные компоненты в системах 
CoDesign осуществляется автоматическая генерация кода из FSM в язык C и 
VHDL (или аналогичные). В ряде систем, в качестве примитивов программной 
системы используют классические механизмы, используемые в ОСРВ.
Примерами инструментальных средств сопряженного проектирования 
являются: 
• Cierto VCC – система комплексного проектирования в технологии CO-
DESIGN от Cadence Design System; 
• COSYMA – универсальная система для оценки и синтеза аппаратно–
программных компонент, Баруншвейского университета в Германии; 
• LOCOS – система синтеза и декомпозиции графовых потоков данных для 
аппаратно-программных системных компонент, Датского технического 
университета; 
• POLIS – универсальная система для проектирования гетерогенных 
аппаратно-программных компонент, совместный проект калифорнийского 

---

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)). 
Основной упор в своей работе авторы делают на качественное повышение 
коэффициента повторного использования на всех этапах проектирования ВсС. 
В жестких условиях рынка решением является повторное использование 
компонентов системы (плат или их частей, драйверов, интерфейсов и т.п.). Для 
лучшей проработки альтернативных решений, что важно для повторного 
использования, предлагается рассматривать систему с двух ракурсов и с 
различных точек зрения: 
• функциональность (что система делает) и архитектуру (как система это 
делает); 
• взаимодействие (обмен данными) и вычисления (выполнение целевой 
функции системы). 
Функциональность может определяться либо разработчиком, либо 
заказчиком. В первом случае в процесс разработки включается этап 
функционального проектирования. Архитектура определяет интерфейс и 
описывает функциональность реализации. При этом она должна не зависеть от 

---

37 
реализации. Кроме архитектуры авторы вводят понятие μ-архитеткуры или 
микроархитектуры. μ-архитектура — функционально завершенный набор 
вычислительных компонент (микропроцессор, периферия, программируемая 
логика, память). При проектировании разработчик должен руководствоваться 
следующими принципами [78]: 
• время и цена разработки определяют процесс принятия решений; 
• проектирование должно вестись на высоком уровне абстракции; 
• нужно делать надежные, устойчивые системы; 
• в системе должно быть несколько сложных и много простых аппаратных 
компонентов; 
• программирование этих компонентов будет производиться на разном 
уровне. 
В параграфе 1.2.2.2.1 представлен краткий обзор элементов методики PBD 
и инструментальных средств, поддерживающих это направление. 
Как и большинство подобных концепций, концепция PBD не обладает 
достаточной завершенностью, чтобы предложить разработчику относительно 
конкретные рецепты проектирования. Тезисы предлагаемой методики верны и 
известны многим разработчикам. Проблема в том, что методика говорит как 
проектировать, то есть как нужно делать, а не что нужно делать.