элект
В. НЕМУДРОВ, Г. МАРТИН
Системы-
на-кристалле.
Проектирование
и развитие

эяектроники
В. НЕМУДРОВ, Г. МАРТИН
Системы-
на-кристалле.
Проектирование
и развитие
ТЕХНОСФЕРА
Москва
2004

В. Немудрое, Г. Мартин
Системы-на-кристалле. Проектирование и развитие
Москва:
Техносфера, 2004. - 216 с. ISBN 5-94836-029-6
В книге рассмотрены различные аспекты проектирования и развития
нового класса перспективной электронной элементной базы - «систем-
на-кристалле» («system-on-chip» - сокращенно SOC).
Описываются характерные особенности проектирования SOC
(многократное использование в процессе проектирования IP-блоков, введение в
САПР «системного» уровня, спиралевидная модель маршрута
проектирования и т.д.).
Анализируется новая мировая инфраструктура проектирования и
производства SOC, сложившаяся в мире в начале 2000-х годов.
Описана новая методология проектирования на основе многократного
использования IP-блоков (блоков интеллектуальной собственности —
Intellectual Property).
Изложена полная методология проектирования SOC, включающая
системный, функциональный, логический и физический уровни
проектирования SOC.
Описаны особенности и преимущества использования языка System С в
процессе проектирования SOC на системном уровне.
На конкретном примере SOC в прикладной области беспроводной
связи третьего поколения, рассмотрены особенности алгоритмически -
ориентированных методов проектирования SOC. Рассмотрены также
методы «платформенного» проектирования SOC.
Для специалистов, студентов и преподавателей в области современной
электроники.
© 2004, В. Немудров, Г. Мартин
© 2004, ЗАО «РИЦ «Техносфера»
оригинал-макет, оформление.
ISBN 5-94836-029-6

Содержание
Предисловие 12
Глава 1. Краткая история развития SoC 15
Введение 15
Развитие SoC Проектирования 15
Влияние SoC на Электронную Промышленность 18
Важность Стандартов и Промышленных Ассоциаций 19
Роль Правительства в Развитии SoC 21
Ключевые Проблемы в Проектировании SoC 23
Литература 24
Глава 2. Мировой рынок SoC, подходы к реализации, определения .... 25
Развитие Мирового Рынка SoC 25
Основные Проблемы в Проектировании SoC 28
Подходы к Реализации SoC 31
Термины и Определения 33
Литература 34
Глава 3. Инфраструктура проектирования и производства SoC 35
Изменяющаяся Природа Полупроводниковой и Системной
Отрасли: Де-интеграция и Де-вертикализация
Системных Компаний 35
Инфраструктура SoC Проектирования и Взаимодействие
внутри Отрасли - Будущие Перспективы 43
Независимые IP Компании - В Аппаратной Области 44
Независимые IP Компании - В Программной Области .... 45
EDA Компании 46
Полупроводниковые Компании Без Фабрик 48
Чистые Фабрики 50
Системные Компании - Аппаратно-Ориентированные .... 51
Системные Компании - Аппаратная плюс
Программная часть 51
Производители Интегрированных Устройств (IDM) 52
Литература 54
Глава 4. Библиотеки IP блоков для SoC проектирования 55
Введение 55
Стандарты для IP блоков 56

6 Содержание
От IP Блоков к Виртуальным Компонентам 57
Стили Проектирования Системы На Чипе 58
Проектирование на Основе Блоков 59
Платформенное Проектирование 61
Эволюция Проектирования ASIC и ASSP 63
Требования на IP Библиотеки 64
Архитектуры Интеграции и Последствия для IP Блоков 65
Адаптация IP блоков: Коммуникационные Оболочки 66
Качество Интеграции IP, Сертификационные
Методы и Стандарты 66
Литература 67
Глава 5. Процесс проектирования SoC 69
Введение 69
Маршрут проектирования SoC 69
Системный уровень проектирования 77
Новые архитектуры SoC 79
Литература 80
Глава 6. Язык SystemC в проектировании на системном уровне 81
Введение - Преимущества Использования SystemC 81
Контекст SystemC 86
Аспекты SystemC 87
Точность Моделирования 87
Модели Вычислений 89
Функциональное Моделирование 90
Моделирование На Уровне Транзакций 91
Уровень RTL и Связь с Реализацией 92
Верификационные Расширения 93
Заключение - Будущее Развитие Языка SystemC
и SLD (System-Level-Design) Требований 94
Литература 96
Глава 7. SoC-проектирование и верификация с SystemC 97
Введение 97
Построение Модели Функционального
Виртуального Прототипа 98
Модели Использования FVP 100
Создание Встроенных Программ 100
Функциональная Верификация 100
Создание Аппаратной Части 101

8 Содержание
Настройка Системной Архитектуры 101
Создание Кода SW Приложения 102
Иерархия FVP 102
Исследование Проекта на системном Уровне 102
Анализ FVP с помощью транзакций 105
Заключение 106
Литература 106
Глава 8. SoC-Проектирование с учетом алгоритмов
и аппаратные/программные платформы 107
Введение 107
Десять Основных Препятствий на Пути
Беспроводной 3G Технологии 107
1. Стабильные Стандарты 107
2. Улучшение Производительности DSP 108
3. Усложнение Программного Обеспечения 108
4. Снижение Потребляемой Мощности 108
5. Усовершенствованная Система
Управления Питанием 108
6. Увеличение Времени Жизни Батареи 109
7. Операционные Системы 3G технологий 109
8. Улучшенная Радио-Технология 109
9. Понижение Стоимости 109
10. Новые Приложения 109
Переопределение Проблем ПО
Выбор Между Гибкостью и Интеграцией ПО
Программное Обеспечение ПО
Низкая Потребляемая Мощность 111
Сложная и Долгая Верификация Алгоритмов
в Рабочей Полосе Частот (baseband) 112
Пример Мультимедийного Мобильного Телефона 112
Ключевые Направления Развития
в Методах Проектирования 113
Современное Проектирование Алгоритмов, Анализ
и Реализация 114
Улучшенная Технология Верификации 115
Платформенное Проектирование 116
Функционально-архитектурное совместное проектирование .... 117
Существующие и Появляющиеся Проектные Технологии 119
Средства Алгоритмического Проектирования,
Анализа и Реализации 120
Средства Совместного Проектирования (CoDesign) 123

10 Содержание
Создание Маршрута Проектирования
в Беспроводной Области 124
Заключение 125
Литература 126
Глава 9. Аналоговые - смешанные SoC 127
Введение 127
Эволюция методологии AMS проектирования 130
Методологии Сверху-Вниз и Снизу-Вверх 132
Проектирование AMS SoC «Сверху-Вниз» 133
AMS SoC и Повторное Использование IP блоков 135
Заключение 136
Литература 136
Глава 10. Технологические платформы реализации SoC 137
Функциональный уровень проектирования 147
Системный уровень проектирования 151
Перспективы развития технологических платформ 153
Глава 11. Некоторые аспекты эволюции SoC 157
Введение 157
Портативность и Большое Время Жизни Батареи 157
Низкая Себестоимость 158
Набор Возможностей и Гибкость 159
Надежность 160
Быстрый Процесс Разработки с Низким Риском 160
Эволюция Технологических Процессов 161
Выводы 162
Приложение №1. Маршрут проектирования цифровых
и аналого-цифровых СБИС 164
I. Общая структура маршрута проектирования 164
II. Системный уровень проектирования 166
III. Проектирование цифровой части СБИС 167
IV. Проектирование аналоговых и цифро-аналоговых блоков ..169
Перечень программного обеспечения 172
Приложение №2. Платформы и платформенное проектирование.
(Подходы VSIA, определения, типы платформ,приложения) 173
Введение 173
Что Такое Платформенное Проектирование SoC? 174

12 Содержание
Подход VSIA к Платформенному Проектированию 175
Преимущества Платформенного Проектирования 176
Компоненты Платформы 179
Типы Платформ 181
Технологические и Прикладные Платформ 182
Методы и Область Действия 183
Вторичное Проектирование 184
Клиенты и Рынки 185
Архитектуры 186
Заключение 187
Литература 188
Приложение №3. «Системный уровень в САПР Synopsys: о сквозном
маршруте проектирования систем на кристалле, от системного уровня
до уровня СБИС» 189
Введение 189
Маршрут проектирования Synopsys 189
1. Системное проектирование 190
Повторное использование, СФ-блоки 195
2. Логическое проектирование 195
Повторное использование, СФ-блоки 202
Заключение 202
О САПР Synopsys в целом 203
Тенденции развития САПР Synopsys 203
Определения терминов, использованных
в данной публикации 205
Список сокращений и определений 208

Предисловие от авторов
Современный уровень полупроводниковой технологии, с проектными
нормами менее 350 нм, позволяющий размещать на кристалле десятки и
сотни миллионов транзисторов (с возможностью реализовывать на
кристалле, одновременно, процессоры, память, цифровую логику,
аналоговые узлы, интерфейсы и т.д.)» определил революционные изменения в
микроэлектронике и в целом радиоэлектронной индустрии.
Ранее созданные разработчиками систем и аппаратуры
функционально-законченные узлы, блоки, отдельные субсистемы,
конструктивно реализованные в виде печатных плат, с десятками типов
универсальных и специализированных микросхем и отдельных компонентов,
успешно трансформируются в качественно новую реализацию -
специализированные сверхбольшие интегральные схемы типа «система на
кристалле» («System on chip» - далее SoC).
Эти революционные изменения (сравнимые по значимости с
созданием транзистора и первых монолитных интегральных микросхем),
привели к качественно новой методологии и инфраструктуре
проектирования и производства СБИС SoC и систем на их основе:
• Разработчики систем и аппаратуры, определяющие алгоритмы и
архитектуру СБИС SoC, становятся непосредственными участниками
процесса их проектирования на системном уровне;
•Традиционный САПР СБИС дополняется верхним «системным»
уровнем проектирования, единым как для разработки СБИС SoC так
и аппаратуры на их основе;
• Требования сокращения сроков разработки SoC (увеличение
производительности проектирования), уменьшения риска ошибок и
исключение итераций перепроектирования, привели к разработке
и внедрению принципиально новой методологии проектирования SoC.
Она основана на многократном повторном использовании на всех
этапах проектирования SoC ранее созданной интеллектуальной
собственности (Intellectual property - IP), в виде заранее
разработанных, сертифицированных IP-блоков процессоров, памяти,
цифровых и аналоговых узлов, интерфейсов и т.д., а в настоящее время и в
будущем все чаще использование определенной совокупности IP, в
виде различного типа аппаратно-программных IP-платформ
(технологических и прикладных);
• Существенным образом изменилась, и очевидно будет изменяться и
дальше, структура и уровень взаимодействия фирм электронной и
радиоэлектронных отраслей, участвующих в процессе создания и
применения SoC (включая системные фирмы, различного уровня

Предисловие от авторов
Центры проектирования (Дизайн-Центры) SoC,
фирмы-разработчики средств САПР, фирмы-разработчики IP-блоков и
IP-платформ, фирмы-производители SoC и др.).
Если в целом ряде ведущих зарубежных стран, процессы создания
инфраструктуры разработки и применения SoC, начатые в середине 90-х
годов, стали определяющей тенденцией современного развития
электронной индустрии и других отраслей - потребителей ее продукции, то в
отечественной промышленности, процессы по формированию новой
инфраструктуры проектирования и производств SoC только начинаются.
Учитывая крайнюю важность ускорения данного процесса, авторы
ставили целью предлагаемой публикацией привлечь к данной проблеме
широкий круг специалистов в области разработки электронных систем,
аппаратуры, электронной компонентной базы, руководителей
правительственных структур, курирующих развитие высокотехнологических
отраслей промышленности и науки, студентов и аспирантов,
работников Высшей школы и РАН, представителей бизнес-сообщества.
Данная первая публикация является определенным введением в
многоаспектную проблематику проектирования и развития SoC, включая:
• краткую ретроспективу развития SoC;
• оценку состояния и развития мирового рынка SoC;
• изложение основ методологии проектирования SoC, с применением
повторного использования IP, на основе IP-блочного и
платформенного проектирования;
• изложение и анализ отдельных методов и маршрутов
проектирования SoC на основе IP-блоков и аппаратно-программных платформ;
• анализ структурных изменений в электронной и радиоэлектронной
индустрии;
• анализ тенденций развития SoC.
В дальнейшем в рамках планов издательства «Техносфера», при
участии авторов, планируется выпуск ряда современных зарубежных
изданий, которые более детально, описывают отдельные вопросы
разработки и развития SoC.
Главы 1-5, 7, 8, 9, 11 написаны авторами совместно. Главу 6 написал
Г. Мартин. Глава 10 написана В. Немудровым и А. Бухтеевым.
Приложение 1 подготовлено В. Немудровым, Н. Евтушенко, И. Сырцовым.
Приложение 3 подготовлено В. Кравченко и Д. Радченко. Приложение 2
подготовил Г. Мартин.
Авторы благодарны Г. Чангу за консультации и помощь в написании
главы 9.
Профессор
В. Немудрое

ГЛАВА 1
КРАТКАЯ ИСТОРИЯ
РАЗВИТИЯ SoC
Введение
В этой главе мы кратко обсудим как происходило развитие SoC, и
рассмотрим следующие темы:
• Развитие методологии проектирования SoC на основе IP
технологии и все более популярных методов проектирования на системном
уровне (SLD - system level design);
• Влияние SoC на структурные изменения электронной
промышленности
• Важность стандартов и промышленных союзов, таких как VSIA
(Virtual Socket Interface Alliance), и других.
• Роль правительства в поддержке проектирования и производства
SoC
• Ключевые проблемы проектирования SoC.
Развитие SoC Проектирования
«Системы на кристалле» и соответственно SoC проектирование
появилось не на пустом месте. Этот стиль проектирования начал применяться
на этапе освоения технологических процессов производства 1С уровня
350-250 нм, когда стало возможным осуществить интеграцию всех
основных цифровых компонентов конечного продукта на одной
кремниевой подложке. Так в мобильных телефонах, уже при данном уровне
технологии, интегрируются все основные цифровые и управляющие
элементы на единой кремниевой подложке, включая управляющий RISC
процессор, DSP, аппаратные блоки обработки сигналов, память и
интерфейс с памятью, а также периферийные устройства. Подобный
цифровой baseband чип еще далек от действительно полной «системы», так
как аналоговый baseband, RF-устройство, аналоговое управление
питанием и внешние сопротивления и конденсаторы реализованы в виде
отдельных компонентов. Но такие «системы в кремнии» (ранние SoC) уже
четко определили направление эволюции радиоэлектронной
аппаратуры с развитием полупроводниковой технологии.
То, что сегодня является набором нескольких чипов
(интегрированный чипсет), завтра благодаря совершенствованию процессов
производства станет одной интегрированной SoC системой.

Рис. 1.1. Общая блок-схема «Системы на кристалле»
В перспективе могут быть решены все проблемы интеграции
аналоговых, цифровых, RF и даже более экзотических структур, таких как
микроэлектромеханические системы (MEMS), датчики, силовые приводы,
химические «лаборатории на чипе», оптические и биохимические
обрабатывающие элементы.
Поэтому мы можем определить SoC как сложную интегральную
схему, объединяющую в одном чипе или чипсете все основные
функциональные элементы полного конечного продукта.
В общем, SoC проект включает в себя как минимум один
программируемый процессор, внутрикристалльную память, аппаратно
реализованные ускоряющие функциональные элементы. В SoC также
включаются интерфейсы с периферийными устройствами и/или с внешней
средой (рис 1.1). SoC проекты включают как аппаратные, так и
программные компоненты. Так как SoC схемы взаимодействуют с внешней
средой, они часто должны включать аналоговые компоненты, а в будущем
могут содержать также компоненты оптических/микроэлектронных
механических систем (0/MEMS).
Следует подчеркнуть, что «System» в термине SoC (System-On-Chip)
гораздо важней чем «Chip»: то, что основные функциональные блоки
проектируются как часть интегрированного целого, важнее того, что они все
будут физически размещены на одной подложке. SiP («System in package» -
система в корпусе) решения могут оказаться более дешевыми для
интегрированных чипсетов, чем единственная подложка, но при этом мы можем
по-прежнему считать, что SiP проектируется как интегрированная
система, с различными компромиссами в случае разных прикладных областей.

Развитие SoC Проектирования
После того, как технология уровня 350-250 нм предложила
возможность интеграции всей системы на единственной подложке, а
последующие технологические процессы на уровне 180-150 нм и ниже
предложили возможность интеграции еще более сложных систем для
различных прикладных областей, возник вопрос о том, как полностью
использовать все эти возможности (и полностью заполнить данную подложку).
Рассмотрение этого вопроса привело к появлению понятия «разрыва» в
производительности проектирования (design gap), предложенного ITRS
([!])- разницы между числом логических элементов, предлагаемых
технологией на одной подложке (при условии приемлемого процента
выхода годных), и числом логических элементов, которые могут быть
спроектированы, верифицированы и интегрированы на этой подложке за
определенное время средней командой проектировщиков. Создание все
более субмикронных технологических процессов постоянно
сопровождается поисками методов преодоления разрыва в производительности
проектирования.
В качестве фундаментального метода повышения
производительности проектирования было предложено повторное использование
интеллектуальной собственности (IP), начиная с маленьких блоков повторно
используемой цифровой логики, таких как, например, интерфейсы с
шиной, далее к большим блокам, таким как ядра встроенных
процессоров, и, наконец, переходя к наборам блоков, предварительно
интегрированных, предварительно верифицированных - так называемым SoC
«платформам».
Были разработаны хорошо известные модели, показывающие, что
многократное использование IP течении двух-трех поколений развития
полупроводникового производства позволит перейти с низкого уровня,
характерного для начального периода SoC (0-30 %), до очень высокого
уровня (90-99%) [2].
Важным фактором развития SoC революции стало появление
организации Virtual Socket Interface Alliance(VSIA) [3], объединившей
ведущие электронные фирмы, и сосредоточившей свою деятельность на
разработке эффективных методов повторного использования IP и развитии
стандартных требований по созданию, обмену и интеграции IP.
Деятельность VSIA, позволила объединить опыт проектирования и
знания компаний по производству микросхем, системных компаний и
компаний, занимающихся системами автоматизированного
проектирования (EDA).
Вторым важным фактором стало создание «методологии
многократного использования для «soft» IP (Synthesizable RTL) командами из
компаний Mentor Graphics и Synopsys на основе чего появилось руководство
Reuse Methodology Manual (RMM), открытое для использования в 1997
году, а затем в 1998 году опубликованное Майклом Кеатингом и Пьером

Глава 1. Краткая история развития SoC
Брикодом [4.]. Это основополагающее руководство с тех пор прошло
через два дополнительных издания и стало настольным справочником и
первым руководством по проектированию многократно используемых
IP для целого поколения разработчиков.
Другим побочным фактором развития SoC стало осознание того, что
традиционное создание IP блоков и повторное использование на уровне
регистровых передач (synthesizable RTL) уже не годится для
проектируемых сложных систем. Таким образом, переход к SoC привел к поиску
эффективных методов системного проектирования (system level design).
При этом основное внимание уделялось хорошо-проверенным подходам
к системному проектированию, таким как спецификация алгоритмов
(algorithmic capture), моделирование, верификация и реализация
алгоритмов потоков данных (dataflow), (особенно в областях беспродных и
проводных коммуникаций, а также обработки мультимедиа); создание
моделей «платформенной архитектуры» SoC для анализа
производительности на системном уровне и верификации; а также создание моделей
«виртуальных системных прототипов» SoC, используемых создателями
встроенного программного обеспечения для верификации, особенно в
случае программ, зависящих от аппаратной части. И снова мы видим,
что основную роль играет «System» («S» в SoC), и потребность в новых
методах и средствах системного проектирования все более возрастает.
Даже поведенческий синтез (behavioural synthesis), который
первоначально задумывался как метод по улучшению производительности при
традиционном проектировании и синтезе на RTL уровне, стал широко
использоваться как средство ускорения проектирования встроенных
систем.
Влияние SoC на Электронную Промышленность
SoC проектирование оказало очень сильное влияние на электронную
промышленность в целом, и в частности на индустрию 1С. Эволюция
технологических процессов привела к тому, что с каждым новым
процессом единовременные расходы (NRE) на новый проект росли гораздо
быстрее чем ожидалось — например, стоимость шаблонов на уровне 130 нм
приближается к одному миллиону долларов, и ожидается, что их
стоимость будет гораздо выше для процессов на уровне 65, 45 нм и далее.
Если еще учесть увеличение затрат по проектированию отдельных
устройств (несмотря на очень большие успехи в повторном использовании
IP), то стоимость проектирования SoC на уровне 130-90 нм оценивается
от 5-ти до 20-ти миллионов долларов. Ясно, что при таких затратах будет
спроектировано гораздо меньше устройств, чем во времена ASIC
проектирования на этапе от 1000 нм до 250 нм и CMOS процессах. И это
доказывается статистикой стартующих ASIC проектов — за несколько лет

Важность Стандартов и Промышленных Ассоциаций
произошло снижение от более чем 12,000 в год до 4,000 или менее.
Некоторые из этих проектов перешли на ASSP и их можно назвать SoC
устройствами в начальной форме — а некоторые перешли на FPGA (Field
Programmable Gate Array) форматы, которые становятся все более
привлекательны по себестоимости в том случае, когда требуется выпустить
от нескольких сотен до десятков тысяч экземпляров.
Такой сдвиг в стилях проектирования, мотивированный ценой,
привел к нескольким последствиям в электронной промышленности.
Во-первых, если продукт можно эффективно разработать на основе
FPGA, то обычно так и происходит, с значительными преимуществами
по времени и цене проектирования, но при увеличении потребляемой
мощности, и ухудшении производительности по сравнению с ASIC или
заказными компонентами. Во-вторых, если требуется полузаказная или
заказная 1С предпринимаются все большие усилия, чтобы сделать ее
пригодной для нескольких предметных областей - путем превращения
структуры SoC в гибкую платформу, которая может быть использована
для реализации многих продуктов, с помощью программируемости и
многочисленных интерфейсов. Решение спроектировать новую SoC
теперь стало очень важным шагом для многих компаний, и есть
предположения, что цена и возможные последствия таких проектов означают в
случае неудачи немедленный провал начинающих и даже уже не совсем
начинающих компаний — «возможность неудачи», приемлемая раньше
ранним поколениям ASIC проектов, теперь недопустима. Это еще раз
подчеркивает важность стандартизованных методов, средств и
маршрутов проектирования продукта для того, чтобы быть уверенным в
корректной работе продукта и приемлемом уровне производства по
результатам проектирования. В результате индустрия проектирования стала
более консервативной, что оказало влияние на поставщиков средств
автоматизации проектирования (EDA). Вместо отдельных новых средств и
особенностей теперь все большее значение придается созданию более
интегрированных «платформ», обещающим снизить время и риск
проектирования - платформам для проектирования SoC платформ.
Важность Стандартов и Промышленных Ассоциаций
Основой успеха SoC и повторного использования IP явилось
параллельное развитие индустриальных стандартов и соответствующих
организаций, таких как VSIA и FSA (Fabless Semiconductor Association) и др. FSA,
например, сыграла большую роль в защите интересов fabless компаний
ASSP и FPGA , таких как PMC-Sierra, Broadcom, Xilinx, Altera и многих
других, а также в поддержке развития не-интегрированных проектов,
только-производящих (pure-play) фабрик и соответствующей
инфраструктуры индустрии (компаний по монтажу и тестированию).

Глава 1. Краткая история развития SoC
VSIA организация сыграла ключевую роль в прояснении и
стандартизации механизмов создания, обмена и интеграции IP. Она
сфокусировалась на формулировке этапов и принципов создания цифровых и
аналоговых IP, которые затем стали частью процесса интеграции для групп
по SoC проектированию и компаний независимо от того, создают ли они
свои собственные IP блоки или приобретают их у поставщиков IP. VSIA
появилась в сентябре 1996, когда был опубликован основополагающий
документ VSIA по архитектуре, сформулировавший этапы маршрутов
создания «hard» и «soft» цифровых IP блоков начиная с RTL уровня и до
уровня GDS II. В VSIA также были созданы рабочие группы, которые
затем выпустили стандарты и принципы разработки в областях
тестирования, AMS, шины на чипе, защиты IP и проектирования на системном
уровне. VSIA стандарты и принципы использовались многими
проектными группами больших компаний по всему миру в качестве основы
внутренних маршрутов создания и повторного использования IP блоков.
Стандарты по повторному использованию формируют виртуальное
«гнездо» (socket), специально рассчитанное на интеграцию в него
«виртуального компонента», или VC (название, принятое VSIA для повторно
используемых IP блоков).
Хотя в последние годы VSIA начала рассматривать проектирование
на основе платформ и встроенного программного обеспечения, а также
верификацию и качество IP блоков (наследуя и развивая работу Synopsys
и Mentor - OpenMORE принципы и правила по качеству IP), большая
часть работы, осуществляемой VSIA, уже сделана.
Среди других организаций, участвовавших в развитии SoC, можно
назвать RAPID, продвигавшую коммерческие и маркетинговые
интересы ранних IP поставщиков с середины до конца 1990-х; Биржу
Виртуальных Компонентов (Virtual Component Exchange), создавшую правовую
основу и базу для торговли VC, что ускорило выбор/оценку и
приобретение IP; компанию «Design and Reuse», опубликовавшую каталоги IP
блоков и разместившую в Интернете информацию по большому набору IP
блоков со всего мира; а также организацию SPIRIT, сформированную в
2003-м для продвижения стандартного описания «мета-данных» IP в
формате XML, с целью облегчения обмена IP компонентами (для
оценки, обмена и верификации IP блоков важны не только файлы
проектирования, но и мета-данные, описывающие интерфейсы и характеристики
IP). Ожидается, что SPIRIT закончит создание первых стандартов в
конце 2004-го года. Другой важной промышленной организацией является
OCP-IP (Open Core Protocol International Partnership), первоначально
созданная компанией SONICS для продвижения своего стандарта шины
на чипе, и выросшая потом в независимую организацию, продвигающую
стандарты по интеграции IP блоков на чипе в соответствии с
особенностями протокола OCR

Роль Правительства в Развитии SoC
Роль Правительства в Развитии SoC
Правительства многих стран были свидетелями роста SoC
проектирования, появления IP индустрии и изменений в электронной
промышленности, и многие из них выступили со своими инициативами или
приняли участие в коллективных инициативах (на уровне промышленных,
научных и правительственных структур) по продвижению оригинальных
разработок в области SoC проектирования и производства. Ниже мы
обсудим вкратце только некоторые из этих многочисленных инициатив.
Одной из первых и наиболее известной из этих инициатив стал
проект Эльба (Alba) в Шотландии, который появился в 1997-м году. Этот
проект был создан с целью поддержки SoC проектирования в
Шотландии, чтобы дополнить уже существовавшую тогда довольно успешную
отрасль производства 1С. Проект Эльба объединил ведущие
Шотландские университеты в центре страны («Silicon Glen») - Glasgow,
Strathclyde, Heriot-Watt и Edinburgh - и сформировал институт по
интеграции на системном уровне, ISLI (Institute for System-Level-Integration) -
предлагающий обучение и аспирантуру в областях проектирования SoC
и SLI (интеграции на системном уровне). Агентство Scottish Enterprise,
совместно с ISLI и промышленностью, способствовало развитию Эльба-
центра в Ливингстоне (Шотландия), и созданию проектных филиалов -
таких компаний как Cadence Design Systems и Motorola (центр по
встроенному программному обеспечению) - на территории Эльба-центра.
Scottish Enterprise также способствовало созданию Биржи Виртуальных
Компонентов (VCX) (Virtual Component Exchange), которая реализовала
базу для торговли IP блоками, правовую инфраструктуру для оценки и
обмена IP, а недавно стала программной компанией, торгующей
программным обеспечением по IP инфраструктуре. Таким образом, целью
проекта Эльба была поддержка SoC проектирования в Шотландии с
помощью обучения в институте ISLI, проектных филиалов в Эльба-центре,
и инфраструктуры для обмена IP на бирже VCX. Хотя все
первоначальные цели не были полностью достигнуты, текущая активность в
Шотландии в области SoC и встроенных систем заметно больше по
сравнению с тем, что могло бы быть при обычном развитии событий.
В других странах с помощью правительств создавались свои
собственные проектные решения - часто с помощью научного сообщества и
существующих групп поддержки науки правительством. В Канаде этим
занялась Canadian Microelectronics Corporation, финансируемая
правительством некоммерческая компания по поддержке фундаментальных
исследований в микроэлектронике с участием промышленности, она создала
национальную исследовательскую сеть по проблеме «системы на
кристалле» (System-on-Chip), с целью улучшения университетских курсов и
исследований в области SoC по всей стране. Шведское правительство

Глава 1. Краткая история развития SoC
и университеты, такие как КТН в Kista рядом со Стокгольмом, а также
шведские электронные компании сформировали проект SOCWare,
который достиг значиельных результатов в проектировании
коммуникационных устройств.
В Соединенных Штатах отсутствовал централизованный акцент на
SoC проектирование, но можно привести два: типичных проекта на
уровне штатов. Целью проекта Pittsburgh Digital Greenhouse (Цифровая
Оранжерея Питтсбурга) было объединение усилий университетов и
промышленности в Питтсбурге и вокруг него в Пенсильвании на
содействии стартующим промышленным компаниям на базе университетских
разработок, а также коммерциализации университетских исследований
и оригинальных проектов в области электронного проектирования и
программ. Проект Yamacraw в штате Джорджия предназначался для
поддержки промышленного проектирования электроники в штате (в
основном в области Атланты) на основе Института Технологии (Georgia
Institute of Technology).
В Европе очень заметен проект IMEC в графстве Фландрия,
Бельгия, поддерживаемый региональным правительством, целью которого
было проведение базовых и прикладных исследований в
микроэлектронике и связанных с микроэлектроникой областях; работа с ключевыми
университетами, такими как KU Leuven; а также поддержка
начинающих компаний, включая компании в области технологии
проектирования, такие как Target Compilers, CoWare, PowerEscape, и ряда других.
В Азии (Asia-Pacific) и Японии существует несколько крупных
проектов. К ним относится «IP Gateway» на Тайване, поддерживаемый
институтом ITRI (Industrial Technology Research Institute), который
финансируется правительством. Его целью является усиление проектирования на
базе IP среди многих проектных фирм Тайваня,.этот проект является
естественным дополнением к тому, что Тайвань является лидером в
области только-производящих (pure-play) фабрик, таких как TSMC и UMC. В
Корее аналогичным проектом является SIPAC (System Integration and
Intellectual Property Authoring Centre). А в Китае эволюция экономики
страны и сильная конкуренция на региональном уровне привели к
образованию различных «баз проектирования IP» («IP Design Bases») в таких
областях как Шанхай и Пекин, объединяющих задачи обучения
проектировщиков и поддержки начинающих компаний (startups) в области 1С
проектирования. Вдобавок к этому, в Китае существует много
коммерческих и научно-исследовательских проектов по SoC проектированию,
включая проекты университета проектирования в Пекине, созданного
компанией Cadence, а также различные программы в ведущих
университетах, в таких городах как Fudan, Шанхай, Tsinghua, Пекин.
В Японии по инициативе правительства был создан Научный Центр
STARC (Semiconductor Technology Academic Research Centre) и разработана

Ключевые Проблемы в Проектировании SoC
соответствующая Национальная Программа по развитию технологии
проектирования SoC с привлечением ведущих электронных фирм и
университетов Японии, целью которой является разработка новой
методологии и эффективных методов проектирования SoC, которые должны
обеспечить к 2010 г. увеличение производительности проектирования
SoC в 100 раз с повторным использованием IP до 99 % [5].
Общими особенностями всех этих проектов является важность
правительственной поддержки и финансирования для построения
инфраструктуры, необходимой для поощрения активности в проектировании
и производстве SoC-; а также объединение многих партнеров -
правительство действует не в одиночку, а заодно с ведущими
научно-исследовательскими институтами и промышленными предприятиями, так что
общий результат значительно больше, чем мог бы быть достигнут
каждым из партнеров самостоятельно. Значительные результаты поддержки
SoC со стороны правительства в партнерстве с другими
заинтересованными сторонами можно видеть в Шотландии, Европе, Канаде, США,
Японии, Корее, на Тайване и в Китае.
В России также развернуты работы по формированию современной
инфраструктуры проектирования SoC и радиоэлектронной аппаратуры
на их основе [6, 7, 8].
Предполагается, что в рамках реализации комплекса планируемых
инвестиционных проектов и НИОКР в течение 2-х — 3-х лет будет
создана базовая многоуровневая структура Центров Проектирования вы-
сокоинтегрированной электронной компонентной базы и аппаратуры
на ее основе.
В целях ускорения создания данной инфраструктуры необходима
дальнейшая консолидация на данном направлении усилий, прежде
всего, правительства, ведущих предприятий радиоэлектронного
промышленного комплекса, институтов РАН, Высшей школы. Только в этом
случае, в рамках Национальной Программы и реализации комплекса
Проектов SoC можно рассчитывать на создание в ближайшие годы
принципиально новой современной отечественной
научно-технологической и промышленной инфраструктуры разработчиков и
производителей SoC и радиоэлектронных систем.
Ключевые Проблемы в Проектировании SoC
В заключение приведем ключевые проблемы и вопросы в современном
SoC проектировании:
• С увеличением возможностей технологии стиль SoC
проектирования становится все более привлекательным и необходимым
средством создания интегрированных продуктов.
• Высокие единовременные затраты (NRE) и сопутствующие риски

24 Глава 1. Краткая история развития SoC
означают, что SoC проекты должны планироваться и создаваться как
платформы, рассчитанные на различные приложения и дочерние
продукты.
• SoC проектирование возможно только при условии обширного
повторного использования IP. Повторное использование требует
введения стандартов и нового подхода к проектированию.
• Необходимо обучение проектировщиков новым подходам и
многочисленным дисциплинам, связанным с SoC. Правительство,
промышленность и научное сообщество только вместе способно быстро
построить новую инфраструктуру проектирования, которая будет
содействовать средним и малым проектным фирмам и
способствовать развитию обучающих программ в институтах и университетах
специализирующихся на проблемах развития SoC.
• Хотя SoC проектирование распространено в многих странах мира,
оно может быть достаточно успешно ускорено в отдельной стране, с
помощью национальных и региональных Проектов, наиболее полно
учитывающих, особенности местной инфраструктуры
проектирования и производства SoC, местную культуру проектирования,
возможности национальных и региональных институтов и университетов.
Литература
1. International Technology Roadmap for Semiconductors (ITRS), 2001 edition and
subsequent updates (2003).
2. R. Goering, Design rense will cnt costs in half, study says, ЕЕ Times, September 28, 1998.
3. Virtnal Socket interface Alliance, on the web at URL: http//www.vsia.org. This includes
access to its varions public documents, including the original Rense Architecture document
of 1997, as wellas more recent documents supporting IP rense released to the public domain.
4. Michael Keating and Pierre Bricaud, Reuse Methodology Manual for System-on-a-Chip
Designs, Kluwer Academic Publishers, 1998 (1st. edition), 1999 (2nd. Edition), 2002 (3rd.
edition).
5. http://www.starc.or.jp/Kaihantu/develop-e/html.
6. Немудров В.Г., Основные проблемы, задачи и этапы формирования современной
инфраструктуры проектирования СБИС «система на кристалле», Электронная
промышленность, 1, 2003.
7. Немудров В.Г., Малышев И.В., Проблемы разработки сверхбольших интегральных
схем типа «система на кристалле», Системы и средства связи, телевидения и
радиовещания. — 2002, № 1,2.
8. Немудров В. Г., Малышев И. В., Состояние и перспективы отечественных разработок
СБИС типа «система на кристалле», Системы и средства связи, телевидения и
радиовещания - 2003. № 1,2.

ГЛАВА 2
МИРОВОЙ РЫНОК SoC,
ПОДХОДЫ К РЕАЛИЗАЦИИ,
ОПРЕДЕЛЕНИЯ
Развитие Мирового Рынка SoC
Наиболее интересным фактом развития мирового рынка SoC
является его быстрый рост. На данный момент SoC рынок занимает
большую часть мирового рынка ASIC/ASSP. Несмотря на спад в области
электроники в последние несколько лет, текущие и прогнозируемые
данные показывают довольно устойчивый рост рынка ASIC/ASSP, a
процент, занимаемый SLI/SoC на этом рынке, демонстрирует бурный
рост.
Таблица 1 взята из отчета Gartner/Dataquest по статистике рынка и
рыночным прогнозам, вышедшего в июне 2003 [1]. Таблица отображает
доходы в различных секторах полупроводниковой отрасли
промышленности. Gartner/Dataquest определяет SLI как «интегральную схему,
созданную в расчете на конкретное приложение и содержащую
вычислительную часть (ядро микропроцессора, DSP, MPEG или графическое
ядро), память и логику на одном чипе» [1]. В аналогичных терминах
Gartner/Dataquest определяет и SoC. На основе таблицы 1 можно
сделать несколько интересных заключений:
• Доходы в области ASIC и ASSP держатся на уровне 34% от полного
дохода в полупроводниковой промышленности, но при этом
происходит постепенная замена ASSP (application specific standard
products) на ASIC (application specific integrated circuits).
• В рамках секторов ASIC и ASSP наблюдается бурный рост SLI/SoC
продуктов, от 42% в 2001 до 2/3 в 2007. В 2003 году более половины
ASIC+ASSP доходов относится к SLI/SoC.
• Эта статистика подтверждается также опытом проектирования. В
2001-2002 годах редкий ASIC/ASSP проект обходился без хотя бы
одного программируемого процессора, памяти и логики. Так как
таблица отражает доходы, в ней не учтены многие проекты,
находящиеся еще на этапе разработки. Сдвиг к 2007 году ясно показывает,
что в будущем все интересные проекты в области ASIC/ASSP будут
SLI/ SoC проектами [2].

Глава 2. Мировой рынок SoC, подходы к реализации, определения
Таблица 1. Оценка Мирового Потребления, 2001-2007
(в миллиардах долларов) [ 1 ]
Общий доход в сфере
полупроводников
Доход ASIC
Доход ASSP
Доход ASIC/ASSP
Доход SLI/SoC
в ASIC/ASSP
Процент ASIC
от общего дохода
Процент ASSP
от общего дохода
Процент SLI/SoC
от дохода ASIC/ASSP
Процент SLI/SoC
от общего дохода
2001
152,184
16,579
34,960
51,540
21,915
10.9
23.0
42.5
14.4
2002
155,077
15,922
36,863
52,785
26,076
10.3
23.8
49.4
16.8
2003
167,970
16,894
40,668
57,562
31,381
10.1
24.2
54.5
18.7
2004
206,744
19,735
49,690
69,425
40,270
9.5
24.0
58.0
19.5
2005
251,723
22,666
58,265
80,930
59,559
9.0
23.1
73.6
23.7
2006
2007
238,556 251,866
22,635
56,761
79,396
50,904
9.5
23.8
64.1
21.3
23,872
60,774
84,646
56,941
9.5
24.1
67.3
22.6
В статистике по прикладным областям (табл. 2)отражена интересная
дополнительная информация.
Таблица 2. SLI/SoC доход в процентах от общего дохода ASIC+ASSP
по при кладным областям [ 1 ]
Коммуникации
Бытовая электроника
Обработка данных
Автомобильная
Другие
Общий итог
2001
45.3
64.4
27.7
19.5
30.7
42.5
2002
51.8
71.3
33.5
24.5
39.3
49.4
2003
54.6
76.6
39.5
28.8
50.3
54.5
2004
56.1
79.8
43.0
33.2
62.9
58.0
2005
57.3
82.3
48.0
36.3
75.8
61.2
2006
58.8
84.6
51.8
37.7
85.3
64.1
2007
60.6
86.8
55.8
39.5
100.0
67.3
• К 2007 году SLI/SoC будут доминировать во всех прикладных
областях за исключением автомобильной (в связи с тем, что основным
требованием здесь является низкая цена. Эта область также менее
всего интегрирована по многим причинам, проектным, стоимости,
поддержки и времени жизни).
• Бытовые продукты уже в значительной мере SLI/SoC, и станут
таковыми повсеместно к 2007 году. Преимущества SLI/SoC заключаются
в уменьшении размера, веса, потребляемой мощности и в
удовлетворительном исполнении.
• В области коммуникаций SLI/SoC продукты сегодня составляют
большинство в основном благодаря сектору беспроводных
коммуникаций; но рост SoC в этой области невелик - так как многие

Развитие Мирового Рынка SoC 27
проводные коммуникационные продукты, особенно в центральных
и оконечных сегментах проводной сети, требуют высокой
производительности, которой лучше всего достичь при относительно
меньшем уровне интеграции.
• Категория «другие», включающая индустриальные и
военные/аэрокосмические приложения, будет полностью покорена
проектированием в стиле SLI/SoC.
Таким образом, мы наблюдаем рост SoC в терминах абсолютных
доходов, в процентном соотношении, а также в большинстве прикладных
областей. Если мы взглянем на информацию по стартующим проектам
[3], то увидим аналогичные тенденции (табл. 3):
Таблица 3: Мировая статистика по стартующим ASIC и ASSP проектам
и процент ASIC, являющихся SLI/SoC [3]
1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006
ASSP 10025 10884 11116 9928 8950 7749 4957 4345 4001 3714 3381 3018
ASIC 4200 4600 5040 5003 5639 6200 5146 4977 5091 5198 5141 4936
ASIC+ASSP 14225 15484 161561493114589 13939 10103 9322 9092 8912 8522 7954
Оценочный процент
SLI/SoC ASIC 33 40 46 49 52 57 63 69 75
• Мы видим здесь уменьшение в абсолютных значениях количества
стартующих ASIC проектов, которое началось в 1998 и
продолжается до 2006 года, до уровня менее чем 1/3 от уровня 1998 года.
• Постепенное вытеснение ASSP ASIC проектами, но ASIC проекты
также уменьшились до текущих 5000 по сравнению с максимумом в
6200, достигнутым в 2000 году, и останутся в будущем примерно на
том же уровне.
• Захват ASIC сектора SoC/SLI проектами, что подтверждает
приведенные выше данные о доходах.
• Хотя в этом отчете Gartner/Dataquest не приводит статистику по
оценке процентов стартующих ASSP проектов, попадающих в
SLI/SoC категорию, эти проценты определенно подчиняются
аналогичным тенденциям. Число интересных ASSP проектов, не
включающих в себя встроенный процессор (как минимум один), память
и логику, стремительно уменьшается.
Хотя мировые регионы по разному воспринимают SLI/SoC стиль
проектирования, недавнее исследование региона Европы, Ближнего
Востока и Африки, проведенное Gartner/Dataquest [4], показывает, что
процент проектов на системном уровне (SLI) от общего количества
проектов продолжает увеличиваться. В [4] сообщается, что этот процент
увеличился от 23% в 2001 до 30% в 2002. Как указывает Gartner/Dataquest,

Глава 2. Мировой рынок SoC, подходы к реализации, определения
число SLI/SoC проектов увеличилось на 7%, в то время как общее число
проектов уменьшилось на 12%.
На основе всего этого становится ясным, что рост отрасли
проектирования интегральных схем (1С) сосредотачивается на росте SoC проектов.
При этом SoC приводит к появлению новых областей исследования,
включая встроенные программы и новые стили проектирования, такие как
платформенное проектирование. В соответствии с отчетом International
Business Strategies, [5] ключевой тенденцией на рынке 1С является
постепенный переход поставщиков 1С на более высокий уровень, в
платформенную среду и среду приложения. Переход в среду платформенного уровня
требует от поставщиков 1С получения доступа к программной поддержке,
либо на основе внутренней активности, либо путем сотрудничества со
стратегическими партнерами. IBS также добавляет: «архитектурный
подход, заключающийся в интегрировании ядра процессора,
программируемой логики, блоков памяти и AMS интерфейсов, означает переход к
специализации (customization) на уровне платформы и в этой области ожидается
значительный прогресс в течение ближайших двух-пяти лет».
Основные Проблемы в Проектировании SoC
Несмотря на превращение SoC проектирования в основную парадигму
1С проектирования, у этого подхода есть свои многочисленные
проблемы. Проект ITRS (International Technology Roadmap for Semiconductors
сформировал следующие ключевые проектные требования для
ASIC/SoC [6]:
• В областях портативных и беспроводных устройств основным
требованием является уменьшение потребляемой мощности, что
приводит к SoC интеграции (DSP, MPU, I/O, IP и др.).
• В широкополосных сетях (broadband) - большое количество
логических элементов (gates), высокая надежность и, в основном, SoC
реализация.
• В области коммутации пакетов (internet switching) - большое
количество логических элементов (gates), высокая надежность и, в
основном, SoC реализация, с добавлением возможностей по
перепрограммированию, для реализации специализированных функций.
• Бытовая электроника — продукты высокого уровня с возможностью
перепрограммирования, и, хотя в основном применение ASIC, более
широкое использование SoC в дорогих (high-end) цифровых
продуктах, с ядрами для обработки 3D графики, параллельной обработки
данных, и т.д.
• В компьютерной области - в основном SoC-интеграция на основе
специализированных MPU и I/O ядер, выпускаемых в коммерческих
масштабах (off the shelf).

Основные Проблемы в Проектировании SoC
• В автомобильной отрасли - в основном ASSP, но также увеличение
использования SoC в дорогих (high-end) продуктах, при помощи
стандартных аппаратных платформ с RTOS ядром и встроенными программами.
В данный момент для SoC сложными проблемами остаются:
• «Более чем 100% улучшение производительности проектирования,
что требует использования платформенного проектирования и
интеграции структур (fabric) с программируемой логикой
• Уменьшение потребляемой мощности, особенно в случае
маломощных беспроводных и мультимедийных приложений
• Интеграция различных технологий на системном уровне, включая
MEMS и оптоэлектронику
• Развитие методологии тестирования SoC, которая должна включать
в себя возможность повторного использования тестов и аналого-
во/цифровой BIST»
Перечень специфических проблемных задач SoC - проектирования,
отмечаемых ITRS [6], довольно большой:
• Производительность проектировщиков
• Управление мощностью
• Интеграция с производством
• Ограничения на уровень шума и помех и т.д.
К проблемам, относящимся к проектному процессу, следует отнести:
• Увеличение системной сложности и количества транзисторов
• Сокращение времени создания продукта (time-to-market)
• Систематическое улучшение процесса проектирования и проектной
производительности
К проблемам, относящимся к проектированию на системном уровне,
следует отнести:
• Системную сложность, требующую технологии работы с
абстракциями и спецификациями более высокого уровня, динамичность и
гибкость в системном проектировании, возможность повторного
использования на системном уровне, исследование пространства
проектирования, эффективный поведенческий синтез, а также SW
компиляцию и автоматический синтез интерфейсов.
• Уменьшение мощности, потребляемой системой
• Интеграция различных технологий, требующая новых подходов к
совместному проектированию (codesign); невозможность
масштабирования аналоговых схем, требующая аналогового
поведенческого моделирования и синтеза, и планирование реализации сверху-
вниз (top-down) на основе различных структур (fabric).
• Встроенные программы, требующие совместного «SW-SW»
проектирования на основе высоко-программируемых платформ, а также
парадигмы сохранения состояния системы и абстракции, для
поддержки нескольких моделей вычислений.

Глава 2. Мировой рынок SoC, подходы к реализации, определения
• Установление связей верификации с тестированием и слияние
разных культур проектирования - включая ориентированные на
интеграцию архитектуры верификации и тестирования, а также
способность проектных команд к слиянию различных практик и культур
проектирования («HW проектировщики с Марса, SW
проектировщики с Венеры... и эти два мира сталкиваются друг с другом»).
Проблемы в области долговременного системного проектирования
включают в себя:
• Проектирование, центральное место в котором занимают
коммуникации
• Управление мощностью на системном уровне (за пределами 65-нм
процесса нас ждут фундаментальные ограничения в области
потребляемой мощности)
• Непрерывная интеграция различных технологий, включая
электрохимические, электро-биологические и нано-технологии и др.
В задачи логического, схемного и физического проектирования
входят:
• Эффективная и предсказуемая реализация, включая
масштабируемый, пошаговый анализ и оптимизацию, планирование и
оценку/предсказание всех соединений между элементами топологии,
синхронизация и передача глобальных сигналов, композиция
системы из различных компонентов, а также связь верификации и
тестирования.
• Интерфейс проектирования с производством, включая
статистический анализ временных задержек и средства верификации
производства, а также технологию улучшения масок-фотошаблонов (RET)
• Увеличение числа транзисторов и не-идеальная масштабируемость
приборов
• При проектировании микросхем нужно более широко использовать
инновационные технологии в области приборов, включая
поддержку новых семейств микросхем, ориентированных на снижение
мощности и улучшение производительности, а также средств реализации
на SOI (Silicon-on-Insulator) и аналоговый синтез.
При проведении проектного тестирования необходимо обратить
внимание на следующее:
• Интерфейсы высокоскоростных устройств
• Высоко интегрированные SoC проекты
• Оценки надежности, основанные на характеристиках продукта
• Тестирование на заданной частоте (at-speed test), с увеличением
частоты
• Разрывы в возможностях между DFT и генерацией тестов,
средствами анализа неисправностей и сложностью проекта
• AMS DFT и BIST, особенно при более высоких разрешениях

Основные Проблемы в Проектировании SoC
31
• Влияние ограничений тестового оборудовании на качество и выход
годных изделий
• Контролируемость целостности сигналов и новые модели
неисправностей
• Тестирование SoC - интеграция методов тестирования SoC в
тестовую платформу, интеграция различных тестовых методологий,
ориентированных на конкретные структуры (fabric), а также BIST для
встроенной памяти, встроенную само-диагностику, повторное
использование тестов и совместимых средств DFT и BIST
Одновременно с Gartner/Dataquest ITRS также провел анализ
важности технологии проектирования, с помощью сравнения
предсказанной стоимости (на основе производительности проектировщиков)
проекта SoC PDA низкой мощности, сложностью в - 3 миллиона
логических элементов (в 2001 году). При учете прогресса в проектной
технологии, полная стоимость проекта такого устройства в 2001 году
оценивалась в $15.1 миллионов долларов. Если не учитывать значительные
инновации в проектной технологии, произошедшие между 1993 и 2001
годом, оценочная стоимость такого проекта составила бы $342.4
миллионов долларов. Другими словами, такой проект был бы нереален.
Ниже перечислены основные достижения в проектной технологии,
сделанные за это время:
• Выполнение размещения и трассировки (place and route) внутри
компании
• Выполнение одним проектировщиком нескольких вертикальных
задач («tall thin engineer»)
• Повторное использование маленьких блоков
• Повторное использование больших блоков
• А также средства реализации проекта 1С (интегрированные
программы для перехода от RTL к GDSII через синтез, размещение и
трассировку).
Это же исследование предсказывает два важных нововведения в
проектной технологии в целях контроля увеличения стоимости проекта:
• «Интеллигентная тестовая платформа» (продвинутые методологии
и средства верификации на RT-уровне )
• «Методология ESL (Electronic System Level)» - т.е. проектирование
на системном уровне, включающее совместное (codesign)
аппаратно-программное проектирование.
Подходы к Реализации SoC
В связи с существованием многих различных видов SoC существует
много разных подходов проектирования, или базовых типов SoC
реализации. Основные из них:

Глава 2. Мировой рынок SoC, подходы к реализации, определения
Single-Chip SoC (SoC на одном чипе): «Классический» проект
системы на кристалле. Это может быть новая разработка на основе одного
чипа, модификация уже существующего SoC проекта в рамках повторного
использования, блочный проект, использующий различные источники
IP, или модификация интегрированной SoC платформы в расчете на
конкретное приложение. Некоторые вчерашние системы на основе
нескольких чипов завтра могут стать SoC на основе одного чипа,
благодаря прогрессу технологических процессов.
System-in-Package (SiP) или System-on-Package (SoP) или System-on-
Chipset: В этом случае, по различным причинам, связанным с ценой,
оптимизацией производства и технологии корпусирования, требованиями
на межсоединения внутри чипа и развитием продукта, проектируется
интегрированный чипсет, и интеграция проводится не на одном чипе, а
в рамках одного корпуса, возможно гибридного корпуса. Например,
наиболее экономным способом создания высоко интегрированного
мобильного телефона может оказаться реализация на базе SoC -
интеграции чипсета в пределах корпуса (а не на одном кристалле), это позволит
создать цифровые компоненты с помощью высоко оптимизированного
цифрового процесса, a RF и аналоговые компоненты - с помощью
оптимального аналогового процесса. При условии удовлетворения
системных требований по стоимости, производительности, потребляемой
мощности, времени проектирования, конечному пользователю все
равно, набор ли это компонентов или единственный чип.
Конфигурируемые (configurable) SoC: Часто под этим подразумевается
SoC с программируемыми особенностями, включая конфигурирование
внешних и внутренних интерфейсов, но не обязательно с
использованием конфигурируемой логики. К данному типу можно также отнести SoC,
спроектированную в расчете на несколько приложений, и при этом
переход между приложениями осуществляется с помощью только
программного обеспечения при фиксированной конфигурации.
Программируемые SoC (или System-on-Programmable Chip (Altera):
Обычно означает SoC со значительным содержанием на чипе
переконфигурируемой и фиксированной специализированной логики, таких
компаний как Altera, Excalibur, Xilinx Vertex II PRO, или комбинаций
стандартных блоков и специализированных SoC с блоками
переконфигурируемой или перепрограммируемой (field-programmable) логики
(например, фирма IBM лицензировала проектную технологию Xilinx FPGA для
создания именно такого гибридного проекта). В предложениях на основе
FPGA (таких как Xilinx или Altera) переконфигурируемость
предназначена только для конфигурирования на аппаратном уровне; а
фиксированные специализированные процессоры (в случае Vertex II PRO - Power PC,
в случае Excalibur - ARM) спроектированы в расчете на оптимальную
производительность и потребляемую мощность. В эту категорию также

Подходы к Реализации SoC 33
можно включить сложные FPGA структуры (fabrics) с синтезируемыми
процессорами, такими как Xilinx Microblaze и Altera NIOS, в сочетании
с IP блоками в синтезируемом виде.
Структурированные ASIC: Недавно появившийся вариант,
предлагаемый в различных видах несколькими поставщиками, такими как AMI,
LSI Logic, RapidChip, NEC, Toshiba, и т.д. Это 'слоеный' подход к SoC, в
котором слои специализированной логики, содержащие, например,
процессорные подсистемы, комбинируются с MPGA
(metal-programmable gate array) областями для реализации специальных аппаратных
функций. В этом случае достигается компромисс между высоко
программируемыми платформами типа FPGA и ASIC/ASSP SoC - при котором
программирование проводится на фабрике, но требует гораздо меньше
времени и затрат по сравнению с реализацией на основе стандартных
блоков (так как используется только несколько MPGA фотошаблонов);
а производительность и потребляемая мощность значительно ближе к
стандартным блокам (например, отличаются в два раза, а не в десять раз)
по сравнению с FPGA.
Термины и Определения
ASIC — Application-Specific Integrated Circuit — «все интегральные
микросхемы, предназначенные для конкретной прикладной области,
которые дополнительно специализированы под конкретного
пользователя» (Gartner/Dataquest [1])
ASSP — Application-Specific Standard Product - «все 1С продукты,
предназначенные для конкретной прикладной области, которые
продаются более чем одному пользователю» (Gartner/Dataquest [1])
SoC — System-on-Chip - сложная 1С, интегрирующая основные
функциональные элементы конечного продукта в один чип или
чипсет. [2]
SLI - System-Level Integrated Circuit - «интегральная схема,
созданная в расчете на конкретное приложение и содержащая
вычислительную часть (ядро микропроцессора, DSP, MPEG или графическое
ядро), память и логику на одном чипе» (Gartner/Dataquest, [1])
SOPC - System On a Programmable Chip (предложено компанией
Altera) - SoC проект, реализованный на высоко-программируемой и
переконфигурируемой платформе [2].
Конфигурируемая SoC (CSoC) — практически то же самое, что
описано в предыдущем определении, только в этом случае
конфигурирование проводится в основном в течение проектирования и создания
продукта, а не во время его работы, либо это может быть комбинация
традиционных ASIC/ASSP технологий с некоторым количеством
переконфигурируемой логики на чипе.

Глава 2. Мировой рынок SoC, подходы к реализации, определения
SiP — System in Package - или SoP - System on Package - интеграция
в одном гибридном корпусе нескольких микросхем. Альтернатива SoC
(где SoC означает «однокристальную» микросхему), которая может быть
более оптимальной по цене благодаря смешанным технологиям или
использованию специальных оптимизированных по цене процессов [2].
Аппаратно-зависимые программы — HdS (Hardware-dependent
Software) - сюда входят все программы, напрямую зависящие от
аппаратной части. В качестве примеров можно привести:
• Аппаратные драйвера
• Встроенные тесты
• Аппаратно-зависимые части коммуникационных стеков.
• Алгоритмы, реализованные программно на «DSP» (VSIA HdS
классификация, [7]) и др.
Платформа — «интегрированный и объединенный вместе набор
общих особенностей, на основе которого можно создать набор продуктов
или семейство продуктов. Платформа является виртуальным
компонентом (VC).» (VSIA PBD Определения и Классификация, [8])
Платформенное проектирование — «проектный подход,
ориентированный на интеграцию, с упором на систематическое повторное
использование, предназначен для создания сложных продуктов на основе
платформ и совместимых аппаратных и программных виртуальных
компонентов (VC), создан с целью уменьшения риска проектирования, затрат
проектирования и времени создания продукта» (VSIA PBD Определения
и Классификация, [8]).
Литература
1. Gartner/Dataguest, Worldwide ASIC/ASSP, FPGA/PLD and SLI/SOC Application Forecast,
2003, 11 June 2003.
2. G. Martin and H. Chang (editors), Winning the SoC Revolution: Experiences in Real Design,
Kluwer Academic Publishers, 2003.
3. Gartner/Dataguest, ASIC/SOC: Rebuilding after the storm, 4 November 2002.
4. Gartner/Dataguest, ASIC Design Starts Survey: EMEA, 2003 Update, 19 May 2003.
5. International Business Strategies (IBS), System 1С Market Trends: Second Quarterly Report
2003.
6. International Technology Roadmap for Semiconductors (ITRS) 2001, in particular the
Chapters «System Drivers» and «Design». Web URL: http://public.itrs.net/.
7. VSI Alliance, Hardware-dependent Software Taxonomy, Version 1,0 (HdS 1 1.0), August,
2003. Web URL: http//www.vsi.org/
8. VSI Alliance, Platform-Based Design Definitions and Taxonomy, Version 1 1.0 (PBD 1 1.0),
August 2003. Web URL: http://www.vsi.org/

ГЛАВА 3
ИНФРАСТРУКТУРА
ПРОЕКТИРОВАНИЯ
И ПРОИЗВОДСТВА
SoC
Изменяющаяся Природа
Полупроводниковой и Системной Отрасли:
Де-интеграция и Де-вертикализация Системных Компаний
Мы начнем обсуждение изменений в полупроводниковой и
системной отрасли с простой модели того, как обстояли дела во многих
крупных фирмах в большей части индустрии с 70-х годов по 80-е и
даже в начале 90-х.
На рисунке 3.1 приведена структура типичной вертикально
интегрированной системной компании 70-х и 80-х годов — например,
Western Electric, Burroughs, IBM, Nortel, Alcatel, RCA, и многих других
подобных фирм. На диаграмме показаны типы проектных знаний,
дисциплины и возможности, которыми обладали данные фирмы, в
частности и в полупроводниковой области. В то время большие, верти-
Сиг&емйая
\Bd6mm)
Полупроводниковое
производство
Рис. 3.1. Вертикально Ин
тегрированные Систем
ные Компании

36 Глава 3. Инфраструктура проектирования и производства SoC
кально интегрированные системные компании обычно располагали
собственным оборудованием для полупроводникового производства.
Также они часто приобретали микросхемы от внешних поставщиков -
специализированных фирм, таких как TI, Intel, и т.д. — но при этом
сохраняли значительные внутренние знания в технологии
полупроводникового процесса, производства, а также в области EDA, проектирования
IP, системных знаний, которые они использовали для улучшения
конечного продукта. Иногда эти знания охватывали все прикладные области
полупроводниковой отрасли; в других случаях они были сфокусированы
на конкретных технологиях и опыте проектирования, лучше всего
соответствовавших тематике компании. Хорошим примером является
компания Nortel (Northern Telecom), которая в конце 70-х создала кодеки-
фильтры на одном чипе и использовала при этом проектирование на
основе CMOS (КМОП) вместе с новыми технологиями, что обеспечило
выпуск данных микросхем в большом объеме. Все это явилось основой
для производства цифровых коммутаторов (digital switch, DMS), которые
в 80-х годах принесли Nortel большой успех в Канаде, США и других
странах.
В таких системных компаниях очень часто существовала большая
команда EDA разработчиков, которые создавали EDA программы,
позволяющие полностью осуществить системный проект, а также
оказывали большую поддержку проектным командам. В этот момент технология
и инфраструктура проектирования рассматривались как основа
развития и успеха данных компаний.
Хотя первое поколение EDA систем, предназначенных для создания
1С, и использовалась некоторыми большими системными компаниями,
(такие системы как Calma, Applicon и ComputerVision), а в 80-х многие
компании экспериментировали со вторым поколением коммерческих
EDA систем (Daisy, Mentor и Valid), только с появлением третьего
поколения независимых, программных EDA компаний (Cadence,
преобразованный Mentor, Synopsys, и многие другие), большая часть системных
компаний начали рассматривать коммерческие EDA продукты в качестве
возможной замены внутренних EDA продуктов. Во многих случаях
первоначально уникальные внутренние алгоритмы, а также специализированные
методы и маршруты начали уступать продуктам коммерческих EDA
компаний, так как у этих компаний было больше разработчиков, клиентов и
финансирования. Это привело к первой «де-вертикализации»
первоначально интегрированных компаний, как показано на рисунке 3.2.
Конечно, большие системные компании не сразу перешли на
коммерческие EDA программы; и переходить они начали с разной
скоростью. Некоторые вертикально интегрированные системные компании,
такие как IBM, продолжают развитие собственных EDA программ и сегодня.

Изменяющаяся Природа Полупроводниковой и Системной Отрасли
Однако, так как со временем каждая EDA область становилась
«коммерческой» и «широкого потребления» («commodity»): — создание
электрических схем (schematic capture), моделирование, размещение и
трассировка, логический синтез, DRC, экстракция, анализ, ATPG и DFT -
большие системные компании постепенно изменили свою стратегию
EDA инвестирования. Расходы на создание собственных программ
уменьшились, но увеличились расходы на приобретение внешних
коммерческих программ и на внутренние команды по EDA интеграции
(«корпоративные CAD группы»), разрабатывающие маршруты
проектирования для, внутренних проектных команд. Еще остались небольшие
области - например, в средствах и моделях системного проектирования
- в которых внутренние группы были еще популярны. Но в больших
компаниях, таких как Burroughs (позднее объединилась со Sperry и
сформировала Unisys) и Nortel, внутренние EDA группы очень сильно
уменьшились в размерах и превратились в интеграторов программ и
экспертов по методологии и маршрутам проектирования.
Но мир на этом не остановился. Вертикальная де-интеграция
пошла дальше. Конечно, многие из этих тенденций происходили
параллельно, и с разной скоростью в разных фирмах. Но появление этих
тенденций было очень заметно. В начале 90-х годов начали появляться «чистые
фабрики» (Foundries) — также известные как «полупроводниковые
компании без своего собственного продукта». Эти компании, начавшие
появляться вначале на Тайване - в качестве примеров можно привести
Taiwan Semiconductor Manufacturing Corporation (TSMC), UMC,
Chartered Semiconductor (Сингапур) - они сфокусировались на
развитии очень обширных технологических знаний по производству
микросхем. Основной целью их усилий было повышение объемов выпуска
микросхем на основе стандартных CMOS (КМОП) процессов
производства, в основном в области цифровой логики, и предоставление своих
услуг системным компаниям и новым компаниям «без фабрик» (fabless),
которые перешли от ASIC модели к модели СОТ (Customer Owned
Tooling), получившей активное развитие в 90-х годах.
На рисунке 3.3 показано появление «чистых фабрик». Параллельно
вместе с появлением чистых фабрик начали появляться дополняющие
их полупроводниковые компании без своих фабрик (fabless), как
показано на рисунке 3.4.
Полупроводниковые компании без фабрик были наиболее
интересным явлением, так как им достаточно было объединить Проектный и IP
опыт в области полупроводникового проектирования с
соответствующим набором «системных» знаний в определенной прикладной области
для того, чтобы начать создавать конкурентоспособные 1С продукты,
достаточно привлекательные для скептически настроенных системных

38 Глава 3. Инфраструктура проектирования и производства SoC
IP(блоки)
Коммерческая
EDA (САПР) индустрия
Рис. 3.2. Возникновение коммерческой
EDA индустрии
Полупроводниковое
производство
компаний - 1С продукты, которые лучше по набору особенностей, цене
или производительности, чем созданные внутренними проектными
командами системных компаний. Появилось много успешных fabless
компаний, таких как PMC-Sierra, Broadcom и другие. В 2001-2003 годах
большая часть таких компаний пострадала от спада в электронной
промышленности, но мы должны учитывать при этом бурный рост этого
сектора во второй половине 90-х.
Параллельно с появлением fabless компаний начался завершающий
этап де-интеграции в полупроводниковой промышленности -
появление независимых IP компаний, специализирующихся на
проектировании IP в конкретных областях, таких как встроенные
микропроцессоры (самой успешной компанией в этой области в данный момент
является ARM, также можно упомянуть MIPS, Tensilica, ARC и DSP Group
IP (блоки)''
Чистые фабрики
Рис. 3.3. Появление чистых фабрик
Полупроводниковое
производство

Изменяющаяся Природа Полупроводниковой и Системной Отрасли 39
IP (блоки)
Полупроводниковые
компании без фабрики
Рис. 3.4. Появление
полупроводниковых компаний без
фабрики.
Полупроводниковое
производство
(объединилась с ParthusCeva)). Эти IP компании обеспечивают своими
проектными разработками (design cores) очень многих заказчиков —
системные компании, интегрированные полупроводниковые компании и
fabless компании.
На рисунке 3.5. отражен возникающий бизнес в области IP продуктов.
IP бизнес также испытывал подъемы и спады. Производители
«звездного» IP (Star IP) - такого как процессоры, которые достаточно
сильно отличаются от других продуктов благодаря уникальным наборам
инструкций (ISA - Instruction Set Architecture), вместе с
сопровождающими их средствами для написания программ - как в случае компании
ARM, создавшей большой набор продуктов в области беспроводных
Независимые IP компании
Рис. 3.5. Возникновение
независимых IP компаний.
Полупроводниковое
производство

Глава 3. Инфраструктура проектирования и производства SoC
коммуникаций — продолжают чувствовать себя более-менее нормально
даже несмотря на спад 2001-2003 годов. Производители менее
«звездного» IP, сфокусированные на стандартных интерфейсных блоках (PCI,
контроллеры USB шины, и т.д.) понесли большие потери из-за высокой
конкуренции, снижения доступа на данный рынок (low barrier to entry),
быстрого понижения цен и проблем качества, отпугнувших многих
клиентов от IP индустрии.
Область электронного проектирования и производства интересна в
основном тем, что она постоянно меняется. Мир не остановился на
этапе, показанном на рисунке 3.5. В то время, как сильные компании «без
фабрики» продолжают комбинировать проектное IP и системные
знания, появляется новая тенденция - возможная ре-интеграция части
полупроводниковой отрасли. На самом деле, в случае некоторых ключевых
компаний - Intel, IBM, TI, ST Microelectronics - полная де-интеграция
так и не состоялась.
Рисунок 6 иллюстрирует структуру Производителей
Интегрированных Устройств (или Integrated Device Manufacturers - IDM). Многие из
этих компаний продолжают добиваться успеха, комбинируя передовой
опыт в области процесса полупроводникового производства и
инвестирования в технологию с передовым проектированием и проектным IP
(внутренним и внешним), и успешно соревнуются с fabless компаниями
и их партнерами - «чистыми фабриками».
Одним из ключевых факторов успеха IDM является накопление
опыта проектирования в специализированной нише, соответствующей
конечному продукту. Например, и ST и Motorola Semiconductor
пользуются большим успехом на автомобильном рынке благодаря их
уникальному IP и непрерывному накоплению новых знаний в данной
прикладной области. Компания TI занимает одну из ведущих позиций в
производстве чипов для беспроводных продуктов благодаря очень мудрому и
удачному решению сфокусироваться на DSP в области беспроводных
технологий и лицензировать микроконтроллер от ARM (что позволило
создать SoC плату с необходимым набором качеств: RISC+DSP) вместо
того, чтобы попытаться соревноваться на двух фронтах, DSP и RISC (как
сделала Motorola). Intel, конечно, воспользовался своим положением
лидера в области PC процессоров и для сохранения преимущества над
другими компаниями — до сих пор продолжет значительные внутренние
инвестиции в создание стратегических EDA средств.
Наряду с соревнованием между fabless компаниями и
интегрированными полупроводниковыми компаниями мы наблюдаем также
некоторую ре-интеграцию в полупроводниковой области (рис. 3.7).
В этой ре-интеграции отражено продолжающееся развитие упомянутых
ранее тенденций к накоплению большими IDM компаниями системных

Изменяющаяся Природа Полупроводниковой и Системной Отрасли
и проектных знаний в нише, соответствующей их конечному продукту.
Существуют сильные аргументы в пользу того, что объединение
полупроводниковой промышленности продолжится при достижении
технологических процессов уровня 90 и 65 нм, и что со временем чистым фабрикам
и полупроводниковым компаниям без фабрики станет все труднее
конкурировать с IDM компаниями, которые накапливают все больше
системных знаний и с помощью этого постоянно улучшают свои продукты.
В этом сценарии для успешного проектирования и производства
современных SoC в достаточном объеме и по разумной цене на уровне 90, 65
и 45 нм понадобится чрезвычайная комбинация знаний технологического
процесса с системными знаниями в прикладной области. Успеха добьются
только некоторые «избранные» IDM компании, добавляющие все больше
системных знаний к своим проектным процессам и конечным продуктам,
и способные перевести свои SoC платформы на уровень производства
менее 100 нм. Поэтому будет наблюдаться ускоряющееся слияние компаний
и доминирование на рынке всего лишь нескольких IDM компаний - две в
Европе, две-три в США, и несколько компаний в Японии и Азии.
Заметьте, что это только возможный сценарий будущих событий,
хотя он подкрепляется появившейся в последние несколько лет
тенденцией к созданию объединенных «групп по развитию процесса» (таких
как ST-Philips-Motorola в городе Crolles рядом с Греноблем; а также
появление договоренностей между TSMC, UMC и рядом европейских и
американских полупроводниковых компаний).
Другой особенностью этого сценария является сосредоточение
больших экономических сил в руках упомянутых выше улучшенных
IDM компаний - и постепенное «затухание» системных компаний. В то
время как IDM компании собирают системные знания и предлагают все
более сложные SoC схемы с интегрированными процессорами и
программным обеспечением (аппаратно зависимые программы,
посреднические программы (middleware), и даже прикладные программы и
стеки), системные компании все больше фокусируются на маркетинге (оп-
" ределение продукта и интеграция), сборке, продажах и
распространении продукта, а также поддержке продукта после продажи. Все большая
часть интересной проектной работы сосредотачивается сейчас в
усиленных ре-интегрированных IDM компаниях.
Если мы объединим этот сценарий и эту тенденцию с другой
тенденцией поведения системных компаний в конце 90-х и 2001-2003 годах -
заключение контрактов со специализированными компаниями по
производству и сборке (например, «контрактными производителями»,
такими как Flextronics и Solectron) на физическую сборку и распространение
продуктов, то системные компании становятся еще более легковесными
■'.;— занимающимися в основном маркетинговой, продажной и после

42 Глава 3. Инфраструктура проектирования и производства SoC
Системные Дизайн-Центры
Полупроводниковое
производство
Рис. 3.6. Развитие Производителей
Интегрированных Устройств (IDM).
Поставщики Интегрированных
Полупроводниковых Продуктов
продажной поддержкой ценных «брэндов» на рынке. Такой сценарий
включает в себя и де-интеграцию и ре-интеграцию - но в нем
определенно происходит передача больших экономических сил от одних
игроков к другим. Он отображен на рисунке 3.8.
Как мы уже видели ранее в нашей дискуссии, есть несколько
возможных сценариев. И весьма вероятно, что все они будут сосуществовать.
Лидеры рынка, такие как Intel и IBM, продолжат развивать свои
уникальные комбинации знаний и навыков. Некоторые основные игроки
Системные
Дизайн-Центры
\Р(блоки)
Рис. 3.7. Ре-интеграция
в Полупроводниковой
Отрасли.
Полупроводниковое
производство
Вертикально Ре-Интегрированные
Поставщики Полупроводниковых Продуктов

Инфраструктура SoC Проектирования 43
* .■-■■ -ч Системные
^ШШ# Design-Центры
^*щ Контрактные
Производители
:1Р(бйШй¥
Рис. 8. Рост контрактного
производства
Полупроводниковое
производство
Вертикально Ре-Интегрированные
Поставщики Полупроводниковых Продуктов
(такие как компания Motorola Semiconductors Products Sector, в ноябре
2003 выставленная на продажу) могут исчезнуть, либо существенно
трансформироваться. Также могут появиться новые группы и типы
групп с уникальным набором качеств.
Но пока так и не происходит увеличения EDA групп в больших
компаниях - хотя постоянно появляются слухи о том, что это уже
произошло. Даже компании с большими инвестициями в развитие внутренних
EDA продуктов продолжают постоянно переоценивать необходимость
этих вложений и принимают решения о том, стоит ли еще оставаться в
этой области или пора перейти на внешних поставщиков EDA средств.
Скорее всего только EDA программы системного уровня, которые
становятся все больше связаны с IP и программными проблемами, продолжат
получать большие инвестиции на развитие внутри больших компаний.
Инфраструктура SoC Проектирования
и Взаимодействие внутри Отрасли -
Будущие Перспективы
Как аргументировалось в предыдущем разделе, де-интеграция и
миграция опыта между различными секторами индустрии электронного
проектирования и производства привели к появлению новых
промышленных секторов и новых независимых компаний. Попробуем
предположить, что это может означать на мировом уровне для различных частей
инфраструктуры SoC проектирования.

Глава 3. Инфраструктура проектирования и производства SoC
Независимые IP Компании — В Аппаратной Области
Разделение аппаратного IP на «звездное» IP (Star IP) и «менее звездное»
(широкого потребления) скорее всего будет сохраняться и в будущем.
Производители IP широкого потребления (commodity) будут и дальше
поглощаться более крупными компаниями - часто EDA компаниями. С
появлением новых интерфейсных стандартов большие компании в
области IP широкого потребления: отделение Inventra компании Mentor и
компания Synopsys, (обе EDA компании) могут, на начальном этапе,
служить большим препятствием на пути появления небольших
независимых IP компаний в данной части рынка. Таким образом IP широкого
потребления может появляться в специализированных областях, таких как
аналоговые интерфейсы; и производящие такое IP компании скорее
всего будут куплены компаниями по созданию проектных библиотек или
системными или полупроводниковыми компаниями, желающими
улучшить свой конечный продукт.
Независимые компании скорее всего будут сохраняться только в
области встроенных процессоров - компании «звездного» IP - вместе с
возможным появлением новых компаний в этой области - часто
возникающих в результате отделения от более крупной компании, например
так возникла компания StarCore DSP, с корнями в компаниях Motorola,
Agere и Infineon. Так как процессоры очень сильно защищены большим
набором уже существующего программного обеспечения (legacy
software), патентами, фирменными/частными ISA (набор инструкций) и
сложными проектными маршрутами на основе программных средств и
аппаратных моделей, они и дальше могут оставаться независимыми, и,
на основе постоянного развития, поддерживать стабильные отношения
с лицензирующими (процессорную технологию) партнерами. Поэтому
очень вероятно дальнейшее существование таких компаний как ARM.
Однако даже компании в этой области могут испытывать трудные
времена или выйти на рынок с новым продуктом в неудачное время. В этом
случае такая компания вероятно вольется обратно в большую проектную
компанию, из которой она появилась, или объединится с одной из
лицензирующих компаний - как случилось с компанией TriMedia, которая
отделилась от Philips а затем вернулась обратно.
Компании процессорного IP осознают возникшую тенденцию
перехода к платформенному проектированию и сами движутся в этом
направлении. Они ориентируются на предложение более полных
платформенных подсистем на основе своих процессоров (как в случае ARM
платформы PrimeXSys), или на основе другого IP (как в случае SONICS
и их продукта - коммуникаций на чипе). Во втором случае (в случае
SONICS и OCPIP), для того, чтобы предложить проектировщикам

Инфраструктура SoC Проектирования 45
широкий набор IP блоков для интеграции в SoC на основе сети,
необходимо создать вокруг коммуникационной структуры (fabric) свое
сообщество проектировщиков и инфраструктуру.
В будущем в этой области скорее всего появятся IP компании,
предлагающие возможности сети-на-чипе, т.е. произойдет значительный
сдвиг в IP проектировании в сторону проектирования на основе
коммуникаций.
Независимые IP Компании — В Программной Области
В обычном представлении независимые компании в области
программного IP встречаются гораздо реже, чем в области аппаратного IP. Это
может быть потому, что такие компании обычно очень малы, или
потому, что создаваемые ими программы не воспринимаются как «IP».
Например, Операционные Системы Реального Времени (RTOS) являются
одновременно IP, и необходимой базой для создания другого
программного IP, и частью IDE инфраструктуры — таким образом
поставщики RTOS также могут предлагать IDE и программные «платформы»,
включающие стеки и промежуточное программное обеспечение.
WindRiver, например, предлагает все эти элементы. Иногда
промышленные консорциумы, такие как Symbian, объединяются и предлагают
общую программную платформу, содержащую IP элементы. Компания
Microsoft, в своих средах (SDK) по созданию программ на основе
Windows и Windows СЕ, предлагает доступ к программным
компонентам (например, WinAPI), которые с полным правом можно назвать
«программным IP».
При рассмотрении этого сектора мы должны сосредоточиться на
независимых IP компаниях. Очевидно, что такие компании чувствуют
себя не очень уверено, поскольку в случае спада снижение объемов
продукта и, таким образом, лицензионных платежей, значительно сильней
отражается на SW IP компаниях, чем на компаниях с более
сбалансированными доходами.
Если независимым SW компаниям станет трудней сохранять
независимость, одним из вариантов может быть их поглощение
основными компаниями по созданию SoC платформ (такими как, TI, ST, может
даже ARM с их платформой PrimeXSys, Xilinx, Altera), для дополнения
соответствующих платформных продуктов. Другим вариантом может
быть расширение в эту область EDA компаний - но эта область
настолько сильно отличается от той, в которой сейчас работают EDA
компании, что такое расширение маловероятно до тех пор, пока не
появятся определенные новые алгоритмы или методологии (смотри
следующий раздел).

Глава 3. Инфраструктура проектирования и производства SoC
EDA Компании
Появление SoC, спад в стартующих ASIC проектах, а также проблемы,
связанные с переходом на технологические процессы менее 100 нм
привели к большим изменениям в EDA компаниях. Мы наблюдаем здесь
интересную головоломку. Как сказал Alberto Sangiovanni-Vincentelli [l]:
«Если мы экстраполируем данные, станет очевидным один факт:
традиционный EDA рынок, основанный на ASIC, исчезает. Нам нужно
заново обдумать весь процесс проектирования. В данный момент
проблемы проектирования на системном уровне доминируют в
определении/задании новых платформ для будущих электронных систем.»
И тем не менее, несмотря на важность системного проектирования и
встроенного программного обеспечения для будущих SoC проектов,
основные EDA компании (Cadence, Synopsys, Mentor) в последние годы
менее озабочены системным проектированием и больше фокусируются
на проблемах проектирования и реализации при переходе от RTL к GDS
II (и далее, к фазовым фото-шаблонам, RET и связям с производством)
в случае процессов на уровне менее 100 нм. Это предпочтение
традиционным 1С EDA противоречит тому факту, что «...многие компании
медлят с переходом на технологический процесс 90-нм.» [1] Электронное
проектирование на системном уровне (ESL) все больше становится
областью работы малых и средних EDA компаний, включая, в конце 2003-
го года, много стартующих компаний [2].
Кажется ясным, что в EDA секторе нужно переходить от
концентрации на проектных абстракциях промежуточного уровня (методология
ASIC) к двойному фокусу на верхнем уровне (системном) и нижнем
уровне - «связью между проектированием микросхем и производством»
[1]. Как предлагает Sangiovanni-Vincentelli, «эти два уровня являются
наилучшим местом для генерации добавленной стоимости в процессе
проектирования» [1].
Эти заключения также были подтверждены анализом будущих
требований к EDA в Европе. Маршрут автоматизации проектирования
Medea+ Design Automation Roadmap, выпуска 2003 года [3], предлагает
следующие пять основных областей в качестве ключевых требований, на
которых нужно сосредоточить основные усилия:
• Консолидация технологии автоматизации проектирования в таких
областях, как IP функции (HW и SW), совместное
аппаратно-программное проектирование (co-design) а также верификация и back-
end на уровне 10-100 нм (deep submicron)
• Новые решения в области системного проектирования
• Достижение месячных «one-month» циклов проектирования в случае
решений на основе системных платформ - с доминированием
программного обеспечения

Инфраструктура SoC Проектирования 47
• Автоматизация проектирования, ориентированная на высокий
процент выхода годных.
• Раннее создание стандартов
Medea+ также указывает на недавно появившуюся стратегическую
область по созданию программ, в особенности аппаратно-зависимых
программ и отладочных программ [3].
Эти тенденции к одновременному фокусированию на крайнем
верхнем уровне (front-end), т.е. системном и программном уровне, и крайнем
нижнем уровне (back-end), т.е. связи с производством, были отмечены
экспертами как в Северной Америке так и в Европе. В будущем станет
ясно, сможет ли коммерческая EDA отрасль адекватно решить обе
проблемы. Концентрация усилий больших компаний на нижнем уровне (back-
end) очень сильно поддерживается инвестициями и высоким уровнем
внимания со стороны руководителей; но даже в этой области EDA
компании должны наладить новые партнерства с центрами по развитию
современного технологического процесса полупроводникового производства и
с ведущими фирмами в этих центрах; с индустрией полупроводникового
оборудования; и с проектировщиками. В этом смысле очень радуют
попытки сделать открытыми проектные базы данных, от RTL до
производственных, с помощью таких стандартов, как Open Access [4], так как они
позволят всем участникам совмещать, увязывать средства, методы и
маршруты с общими проектными базами данных 1С, решая, таким образом,
будущие проблемы современного 1С проектирования.
В области системного и программного проектирования (front-end),
будущее кажется не таким многообещающим. EDA компании должны
наладить связи с проектировщиками встроенных систем (часто
«экспертами по алгоритмам» и системными архитекторами) и
проектировщиками встроенных программ. Это два совершенно разных сообщества.
Первое сообщество уже иногда использует некоторые EDA средства (такие
как CoWare SPW для анализа алгоритмов потоков данных (dataflow)), но
большая часть этого сообщества пользуется либо доской и мелом и
моделированием на C/C++, либо средствами за пределами EDA, такими
как Matlab и Simulink от компании Mathworks. Второе сообщество
использует большой набор средств и методов от разработанных
самостоятельно до базовых сред по IDEW, предлагаемых компаниями WindRiver,
Greenhills и другими основными поставщиками программных средств и
IP (например, RTOS, промежуточные программы, стеки). Мы также не
должны забывать о компании Microsoft с ее большими ресурсами и
большим терпением при работе на рынке встроенных продуктов
(например, Microsoft много лет предлагает Windows СЕ несмотря на низкий
спрос). Некоторые члены второго сообщества используют средства
программного моделирования, типа SDL и UML, от таких поставщиков,

Глава 3. Инфраструктура проектирования и производства SoC
как Telelogic и IBM Rational, но их очень мало. В принципе EDA
компаниям должно быть легче работать с поставщиками средств
программного моделирования, чем с поставщиками IDE.
Основным препятствием перед появлением сильных EDA
предложений в системной и программной области похоже является убеждение в
том, что эти рынки непривлекательны - в области системного
моделирования доминирует компания Mathworks, а в программной области
отпугивает необходимость больших вложений для создания интересного рынка.
Определенно, поставщики программных средств и программного IP
испытывали в последние годы больше трудностей, чем EDA компании - и
они обладают значительно меньшей базой (ближе к 1-му миллиарду
американских долларов в годовых доходах, в противоположность 4-м
миллиардам в случае EDA). Пока не изменятся какие-либо фундаментальные
характеристики данного рынка, EDA компаниям будет тяжело
инвестировать в эту область в больших масштабах. Больше всего в этой области
необходимо кардинальное улучшение в методологии проектирования
(появление новой «проектной идеологии»), которая предложит очень большие
преимущества в производительности и безошибочности в областях
системного проектирования и создания программ, и, таким образом, может
претендовать на большие доходы, к которым привыкли EDA компании.
С точки зрения конца 2003-го года, еще очень далеко до такого
улучшения. Это одна из причин, по которым некоторые предлагают
рассмотрение новых моделей поддержки EDA инноваций, с целью возможных
значительных улучшений - например инициатива «EDATech» по
поддержке современных R&D в области EDA, по примеру SEMATECH 80-х
и 90-х годов [ 1 ]. Такой академический подход может объединить EDA
отрасль, полупроводниковые/системные компании, и ученых в попытке
добиться значительного прогресса в этой области. Предложение по
созданию EDATech появилось довольно недавно, и его успех пока совсем
не очевиден.
Полупроводниковые Компании Без Фабрик
Для того, чтобы продолжить успешно конкурировать с IDM
компаниями, «fabless» компаниям необходимо принять некоторые
фундаментальные решения. Они должны стать ближе к производственному процессу и
чистым фабрикам, от которых они зависят, чтобы обеспечить плавный
переход от этапа проектирования к этапу производства 1С в больших
объемах, при этом решая современные технологические проблемы. Они
также должны продолжать собирать все больше и больше системных
знаний, чтобы держаться на уровне современных тенденций и
требований в проектировании их продукта.

Инфраструктура SoC Проектирования 49
Один очень ранний и перспективный вид совместной деятельности
между полупроводниковыми компаниями без фабрики был основан на
том, что некоторые проблемы, стоящие перед компаниями, лучше всего
решать вместе на уровне промышленности, нежели каждой компанией
по отдельности. Ассоциация полупроводниковых компаний без фабрик
(Fabless Semiconductor Association) [5] оказала таким компаниям
громадную помощь в решении общих проблем. Сюда входит улучшение
понимания фабриками того, сколько нужно будет произвести чипов, на
основе работы сети распределения товаров и прогнозов на будущее на
уровне всей индустрии; улучшение сертификации фабрик на основе
стандартной методологии сертификации CMOS (КМОП) процесса;
улучшение проектирования с помощью стандартизации моделирования
приборов на уровне SPICE; а также улучшение качества IP с помощью
создания общих стандартов качества IP, и продолжения работы в этой
области через VSIA IP Вся эта работа очень сильно помогла развитию
«fabless» индустрии.
Несмотря на эту совместную работу, такие проекты не могут
заменить очень тесных взаимоотношений между технологиями
проектирования и производственным процессом, существующих в случае IDM.
Следовательно, «fabless» компании должны продолжать поиск новых
путей достижения тесных взаимоотношений с фабриками и
техническими специалистами, от которых они зависят.
Вдобавок к этому, выжить в подъемах и спадах электронной
промышленности смогут только те компании, которые будут быстрее всего
осуществлять наилучшие решения системных проблем, и в то же время
сохранять независимость от системных компаний. Это требует
непрерывного фокуса на поиске новых особенностей, повышающих
привлекательность продукта, и сохранения близких связей с прикладной
областью, стандартами и требованиями покупателей.
Очень интересным в индустрии «fabless» компаний является сектор,
занятый основными FPGA производителями (Xilinx, Altera, Actel, и т.д.),
предлагающих скорее «платформы» (нежели ASSP продукты) на основе
которых системные компании могут создавать свои продукты - как
быстрые прототипы, так и конечные продукты, в зависимости от
специфики конечного продукта. В этой области интересно наблюдать переход от
просто программируемых приборов, содержащих только
программируемые логические элементы, к интегрированным SoC платформам, таким
как Xilinx Vertex II PRO и Altera Excalibur, со встроенными аппаратными
процессорами, высокоскоростными интерфейсами, умножителями
(multiply-accumulators) в стиле DSP, и библиотеками
сертифицированных IP блоков, включая программно-синтезируемые процессоры.
Вопросы, решаемые в этом секторе, конечно, отличаются от вопросов,

Глава 3. Инфраструктура проектирования и производства SoC
стоящих перед ASSP сектором (например, компаний PMC-Sierra,
Broadcom), в котором компаниям нужно предлагать гораздо более
специализированные устройства в соответствующей прикладной области.
Чистые Фабрики
У чистых фабрик ожидается довольно неплохое будущее несмотря на
экономический спад — по крайней мере у ведущих компаний в этой
отрасли. Однако эта область становится более интересной — уже не совсем
«чистой», не так сильно сфокусированной только на производстве как
раньше. Во первых, фабрики, такие как UMC, TSMC и Chartered
Semiconductor не изолированы от развития современных
технологических процессов - они присоединяются или ассоциируют себя с
некоторыми «группами фабрик» для того, чтобы обмениваться опытом с
другими полупроводниковыми компаниями и понизить стоимость развития
нового технологического процесса. Это может привести к интересным
союзам и взаимоотношениям в будущем. Также возникают и другие
связи, между фабриками и с некоторыми IDM компаниями,
использующими фабричное производство как средство понижения собственных
будущих вложений в свои фабрики - использование внешних фабрик
является хорошим способом увеличения объема производства некоторых
продуктов, при условии, что у фабрик есть производственные мощности
и процессы/проекты совместимы. Такие связи есть у многих IDM
компаний, таких как Motorola и ST Microelectronics.
Вдобавок к этому чистые фабрики понимают, что их способность
привлечь новые проекты для производства зависит не только от
наилучшего качества/объема, цены и производственных мощностей, но и от
способности сгладить процесс проектирования. Это привело к
появлению двух интересных видов взаимоотношений:
1. взаимоотношения с EDA компаниями, для проверки маршрутов
физического проектирования и верификации в пределах предлагаемых
фабриками технологий. Можно сказать, что любая EDA компания,
не прошедшая проверку маршрута проектирования с TSMC и не
располагающая соответствующими проектными библиотеками
очень сильно проигрывает на рынке продуктов по переходу от RTL к
GDSII.
2. взаимоотношения с поставщиками IP, для того, чтобы как в случае
синтезируемого IP, так и в случае конечных (hard) IP блоков, эти
поставщики могли выполнить частичную проверку и сертификацию
своих наиболее важных IP продуктов. Сюда входят оба базиса IP как
библиотек элементов, и компиляторы памяти, так и более сложные
HW IP блоки, включая блоки стандартного интерфейса шины и

Инфраструктура SoC Проектирования
встроенные процессоры. Так как IP блоки попадают в проекты через
маршруты проектирования, комбинация фабрик с EDA и IP
компаниями, работающими вместе для удовлетворения требований СОТ
заказчиков IP, приводит к появлению новых схем
взаимоотношений.
Так как фабрики становятся все более тесно связаны с EDA
маршрутами проектирования, библиотеками блоков и поставщиками более
сложных IP блоков, им приходится по необходимости расширять
инфраструктурные взаимоотношения за пределами технологии процесса и
производства. Некоторые фабрики установили взаимоотношения с
различными небольшими проектными компаниями, чтобы лучше понять
динамику проектирования и улучшить свои предложения, особенно для
«fabless» компаний.
Системные Компании — Аппаратно-Ориентированные
На сегодняшний день трудно сказать, существуют ли вообще такие
компании. Если да, то кажется, что время их существования скоро
закончится. В наше время, когда в большинстве встроенных систем и
оборудовании есть как минимум один встроенный процессор; когда
взаимодействия между аппаратной частью, процессорами, компиляторами и
программами становится все более сложными, и когда все интересные
SoC проекты обладают как минимум одним встроенным процессором,
очень редкая компания проектирует и предлагает чисто «аппаратные»
системы.
Системные Компании —
Аппаратная плюс Программная часть
Системные компании имели сложное прошлое и у них все более
проблемное будущее. За исключением самых больших, они подверглись
описанной ранее де-вертикализации и потеряли многие ключевые
проектные и производственные навыки. Это повлияло как на
полупроводниковое проектирование, так и на более высокие уровни
проектирования — платы, корпуса — с увеличением контрактного
производства.
В результате системные компании превращаются скорее в «брэнд»,
и используют опыт анализа рынка для поиска новых рыночных
возможностей, опыт управления проектами для создания системной
архитектуры, идентификации ключевых компонентов и поставщиков,
заключения субдоговоров и приобретения проектов и компонентов (как
Н\¥так и SWrana), и интеграции всех компонентов в конечный
продукт, который затем производится и собирается на контрактной основе.

Глава 3. Инфраструктура проектирования и производства SoC
Конечно, некоторые усилия по собственному написанию программ
(внутри компании) могут оказать очень сильное влияние на
привлекательность продукта, особенно в области интерфейса пользователя и
новых особенностей; и системные компании могут по прежнему
контролировать свои собственные каналы продаж и маркетинга, даже если они
проводят распространение на контрактной основе. Но тенденция к
уменьшению системных компаний по прежнему растет. В этом сценарии
экономическое могущество определенно перешло к
полупроводниковым компаниям без фабрик и 1DM компаниям.
Преимуществами системных компаний в будущем являются их
близость к конечным пользователям, их способность предсказать, какие
продукты будут наиболее привлекательны, а также способность
управлять очень сложными маршрутами проектирования, производства и
распространения продуктов.
Производители Интегрированных Устройств (IDM)
Наш сценарий будущего предсказывает, что все больше и больше
экономического могущества будет сосредотачиваться в руках IDM компаний
— полупроводниковых компаний (а также дочерних компаний,
отделившихся от системных компаний) которые обладают как системными
знаниями, так и технологией процесса производства; которые могут
взаимодействовать с EDA компаниями на всех трех уровнях — системное
проектирование, ASIC и ASSP проектирование, а также связь с
производством, и которые создают достаточно много IP самостоятельно,
чтобы поддерживать соответствующие взаимоотношения с внешними
поставщиками (широкие знания компании TI в области DSP скорее всего
помогают в поддержке здоровых взаимоотношений с ARM как с
поставщиком RISC ядер, потому что в крайнем случае TI может попробовать
создать RISC ядро самостоятельно).
Тем не менее, несмотря на экономический рост и потенциальный
контроль большей части маршрута проектирования, чем в случае любой
другой компании, нет сомнения, что IDM компании, за редким
исключением, чувствуют себя очень сильно зависимыми, как от других
компаний, так и от неустойчивого электронного рынка:
• Их доходы реализуют не сразу, а основаны на объеме продаж.
Наилучшая микросхема с высокими характеристиками, низкой
потребляемой мощностью и низкой ценой ничего не гарантирует до тех
пор, пока на ее основе не созданы очень популярные продукты,
раскупаемые в больших объемах покупателями.
• Проблема проектирования на системном уровне и быстрые
изменения в этой области означают, что IDM компании должны постоянно

Инфраструктура SoC Проектирования
инвестировать в эту область и пополнять свои системные знания,
обеспечивая все большую часть маршрута разработки встроенного
программного обеспечения.
• Необходимость в принятии критических решений о том, покупать
проектное IP или сделать его самостоятельно, включая постоянную
оценку своей компетентности, в особенности в таких областях, как
встроенные процессоры.
• Необходимость контроля над достаточно большими
производственными мощностями для гарантии стабильных поставок (даже при
использовании фабрик в качестве партнеров) означает непрерывное
инвестирование в современные фабрики.
• Необходимость в конкурировании на уровне технологического
процесса, даже если он создан совместно с партнерами, означает
непрерывное инвестирование в развитие технологий и, соответственно, в
модернизацию фабрик. Ни одна успешная IDM компания не
добилась успеха путем полного отказа от фабрик.
Мы можем видеть очень успешные IDM компании - например
Intel; а также менее успешные - такие как компания Motorola
Semiconductor Products Sector (SPS), которая выставлена на продажу
(ситуация ноября 2003 года). Компании TI, IBM Microelectronics и ST
Microelectronics на данный момент более менее успешны. Philips
Semiconductors и Infineon испытывают затруднения. Японские IDM
компании прошли через очень трудный период и продолжают бороться
с проблемами проектирования IP и развития общего технологического
процесса - хотя их совместные программы обладают многими
сильными сторонами. На Тайване, в Китае, и в других странах Азии, местная
электронная промышленность (в противоположность дочерним
компаниям от многонациональных корпораций) сфокусирована в основном
на чистых фабриках.
Так что участь IDM компаний не является такой уж легкой! Тем не
менее, и особенно если проблемы производства на уровнях 90, 65, 45 нм
и далее окажут большое влияние на системные аспекты современных
1С, IDM компании, наиболее успешные в создании интегрированного
проекта и производственных мощностей для современных SoC, и
наиболее эффективно объединяющие системные и программные знания с
опытом проектирования микросхем, могут получить долговременное
преимущество в ключевых частях рынка.

Глава 3. Инфраструктура проектирования и производства SoC
Литература
1. Alberto Sangiovanni-Vincentelli, The Tides of EDA, IEEE Design and Test, November-
December 2003, pp. 59-75. (Based on his DAC 2003 keynote talk).
2. Richard Goering, Are startups taking over ESL?, Electronic Engineering Times,
(ЕЕ Times), November 17, 2003. URL:
http://www.eedesign.com/columns/tool_talk/OEG20031117S0052
3. Medea+, The Medea + Design Automation Roadmap — Design Automation Solutions for
Europe, 4th. Release, June 2003. URL: http://www.medeaplus.org/
4. OpenAccess Coalition. URL: http://www.si2.org/openaccess/andalso
http://www.openeda.org/
5. Fabless Semiconductor Association. URL: http://www.fsa.org/

ГЛАВА 4
БИБЛИОТЕКИ IP БЛОКОВ
ДЛЯ SoC ПРОЕКТИРОВАНИЯ
Введение
Проектирование SoC было бы невозможным, если каждый проект
начинать с самого начала. SoC проектирование очень сильно зависит от
многократного использования блоков Интеллектуальной Собственности
(IP) — называемых «IP Cores». В последние 8-9 лет проявилась
значительная тенденция к многократному использованию IP [1], многократное
использование явилось одним из ключевых факторов в сокращении так
называемого «разрыва в производительности проектирования» (по
определению International Technology Roadmap for Semiconductors (ITRS) -
разрыва между усложнением современной технологии полупроводникового
производства и улучшением производительности проектировщиков (за
счет улучшения средств проектирования и методологий).
Но многократное использование важно не только для улучшения
производительности проектировщиков - хотя в этом оно достаточно
эффективно помогает. Многократное использование также
предоставляет командам проектировщиков механизм создания SoC продуктов,
охватывающих различные дисциплины и области проектирования.
Наличие как hard (после размещения и верификации) так и soft
(синтезируемых) процессорных блоков от различных поставщиков позволяет
проектным командам, не желающим заниматься проектированием
своего собственного процессора с нуля, использовать эти блоки в своих
проектах, таким образом добавляя в интегрированную SoC RISC
управление и DSP функции без необходимости освоения мастерства
проектирования процессоров. В этом смысле преимущества многократного
использования IP выходят далеко за пределы простого увеличения
производительности, поскольку значительно уменьшается риск
проектирования и появляется способ создания SoC проектов, которые ранее были
невозможны из-за слишком большого времени, требуемого на создание
IP с нуля.
Поиск и повторное использование IP блоков дают возможность
приобретений, в предварительно сертифицированной и «упакованной»
форме, опыта проектирования в различных областях, лежащих за
пределами компетенции данной команды проектировщиков, и эта возмож-

Глава 4. Библиотеки IP блоков для SoC проектирования
ность является ключевым требованием успешного развития SoC
проектирования. На данный момент создание SoC сконцентрировано в
основном на интеграции цифровых компонентов плюс, возможно, некоторые
аналоговые интерфейсные блоки, рассматривающиеся как черные
ящики. SoC микросхемы будущего будут включать в себя компоненты из
различных областей за пределами компетенции команды интеграторов,
таких как RF или MEMS, что требует расширения понятия «блочного» IP
также и на эти области. Эта стадия еще не достигнута — требуется
значительная эволюция IP бизнеса и методологий создания, сертификации,
оценки, интеграции и верификации IP перед тем, как можно будет легко
определять и интегрировать действительно разнородные наборы
различных IP блоков в конечную SoC микросхему.
Однако те же самые проблемы существовали и в начале SoC
революции в цифровой области. На данный момент они в значительной части
уже решены, путем создания стандартов, оценки, обмена и интеграции
IP - в основном для цифровых IP блоков, с расширением на
аналоговые/смешанные (AMS) блоки.
Таким образом, создание библиотек многократно используемых IP
блоков в большой степени зависит от развития стандартизованных
процессов SoC проектирования, блочного проектирования IP и интеграции
IP блоков. Библиотеки, соответствующие этим стандартам - путем
предложения соответствующего набора IP - собственно и представляют
возможность многократного использования. Обсудим некоторые
способы создания IP стандартов.
Стандарты для IP блоков
Одной из ведущих организаций по идентификации и созданию таких
стандартов является Virtual Socket Interface Alliance (VSIA) [3],
сформированная в 1996 году и в момент своего пика насчитывавшая более 200
членов из областей IP, системного проектирования,
полупроводникового производства и EDA. Хотя VSIA часто критикуется за
недостаточное распространение своих IP стандартов, VSIA оказала значительное
влияние на электронную промышленность. Многие компании вводят
внутренние программы многократного использования; многие
системные и полупроводниковые компании начинают заниматься созданием
и обменом IP; а многие проектные группы используют VSIA IP
стандарты в качестве основы для создания своих собственных стандартов и
методов проектирования на основе IP.
VSIA, например, в своих ранних архитектурных документах 1996-
1997 годов помогла достичь широкого понимания того, что является
«hard» блоком, а что «soft». Другим важным вкладом в проектирование

От IP Блоков к Виртуальным Компонентам
является проведенная одной из рабочих групп VSIA систематизация
моделей проектирования на системном уровне. Таким образом, стандарты,
спецификации и документы VSIA очень важны для промышленности.
На развитие проектирования на основе IP и появление
посреднической индустрии в этой области (что потребовало гораздо больше
времени, чем ожидалось первоначально в 1996-1997 годах) значительное
влияние оказали также бизнес-проблемы, связанные с оценкой,
приобретением, поставкой и использованием IP Для решения этих
проблем появились такие организации, как Биржа Виртуальных
Компонентов (Virtual Component Exchange — VCX) [4]. Хотя эта биржа еще
существует, сейчас уже ясно, что подавляющая часть деловых
взаимоотношений, связанных с IP блоками, проходит менее формально, в
рамках взаимоотношений между поставщиками и потребителями.
Другая важная группа промышленных стандартов связана с
многократным использованием IP на основе заданной шины или стандарта
коммуникаций на чипе: протокол Open Core Protocol (OCP) и группа
стандартов OCP-IP (OCP International Partnership) [5]. Протокол OCP
вначале был основан на закрытом (proprietary) проекте коммуникаций
от компании Sonics, Inc. Однако потом для улучшения доступности IP
блоков компания вместе с несколькими партнерами (такими как
Alcatel, Ampitron, ATI, Broadcom, Texas Instruments, Nokia, CAST,
Denali, Philips и многие другие) создала совместный стандарт,
способствующий взаимной совместимости на уровне SoC разных IP блоков,
адаптированных для использования с ОСР. Это сильно похоже на то,
что случилось с разнообразными коммуникационными протоколами
на уровне печатной платы (РСВ), которые вначале были закрытыми, а
потом перешли на открытые промышленные стандарты, с целью
облегчения их распространения и увеличения числа компонентов,
имеющих интерфейсы к данным стандартным протоколам.
От IP Блоков к Виртуальным Компонентам
Организация VSIA оказала большое влияние на индустрию SoC и
проектирование на основе IP. Понятие «виртуального сокета» - описание
всех проектных интерфейсов, которым должен соответствовать IP
блок, а также модели проектирования и информация по интеграции,
которые должны поставляться вместе с IP блоком (необходимые для
облегчения интеграции, упрощения «вставки» блока в SoC проект) -
происходит от понятия Печатной Платы (РСВ), где компоненты
покупаются в упакованном виде и стандартным образом интегрируются в
проект платы.
Дополнением «виртуального сокета» является «виртуальный
компонент». В контексте VSIA, а также в более общем контексте интерфейса,

Глава 4. Библиотеки IP блоков для SoC проектирования
IP блок — это проектный блок, который возможно пригоден к
повторному использованию. А виртуальный компонент — это проектный
блок, специально созданный с целью повторного использования,
который был разработан и сертифицирован для максимального повторного
использования. Отдельные IP блоки и виртуальные компоненты
отличаются в следующих аспектах:
• Процессы разработки и верификации виртуальных компонентов
соответствуют установившимся процессам проектирования и
стандартам качества.
• Вместе с виртуальными компонентами поставляются модели и
данные проектирования, ассоциированные документы
проектирования, сценарии, информация по параметрам и другие
дополнительные данные, соответствующие одному из признанных стандартов
повторного использования IP - например VSIA стандартам либо
какому-то другому внутреннему или внешнему набору стандартов.
• Виртуальные компоненты должны хотя бы один раз быть
изготовлены с последующим определением характеристик.
• Виртуальные компоненты должны хотя бы один раз быть
использованы какой-либо внешней командой разработчиков, с
приложенными результатами данного использования.
• Виртуальные компоненты должны сопровождаться оценкой
качества на основе промышленного стандарта по качеству, например
такого как OpenMORE (разработанного компаниями Synopsys и
Mentor Graphics), или стандарта качества VSI Quality (который
воспринимает OpenMORE в качестве одного из входных параметров).
В течение последних десяти лет разработки в области повторного
использования IP фокусировались на задании стандартов и процессов,
позволяющих превратить хаотичное повторное использование IP
блоков в хорошо понятный и надежный процесс приобретения и
повторного использования виртуальных компонентов. В качестве примера
может служить обсуждавшийся выше «сокет» стандарта
коммуникаций OCP-IP.
Стили Проектирования Системы На Чипе
Способ создания, аттестация и использование IP блоков в
проектировании SoC в значительной степени зависит от стиля проектирования
данной SoC. Мы обсудим ниже два основных стиля проектирования
SoC, гораздо более детально рассмотренных в [6].
Выбор стиля проектирования SoC зависит от множества разных
факторов. Сюда входят предполагаемое время на проектирование,
степень требуемой оптимальности по цене, требуемая производительность,

Проектирование на Основе Блоков
ограничения на потребляемую мощность, размер проектной команды
и ее опыт, предполагаемый объем выпуска конечного продукта,
специфика области применения и допустимая степень риска процесса
проектирования. В зависимости от всех этих характеристик один из
нескольких разных стилей проектирования может оказаться лучше
других. Мы рассмотрим только два стиля, придающих большое значение
идее многократного использования.
Проектирование на Основе Блоков
В стиле блочного проектирования SoC проектируется как
комбинация новых IP блоков и IP блоков многократного использования из
библиотек, от поставщиков и от внутренних проектных групп. IP
блоки многократного использования могут быть спроектированы
разными способами — с целью интеграции в конкретные архитектуры на
чипе; с целью адаптации (с помощью оболочек или реконфигурируемых
интерфейсов) в многочисленные стандарты и структуры; с целью
последующей возможной реконфигурации по функциональному
назначению, производительности, размерам буферов и промежуточной
памяти, и т.д. Независимо от того, как широко конфигурируются блоки
и какой у них уровень предварительной сертификации и
параметризации данная модель многократного использования является
специальной, в которой блоки используются повторно в конкретных SoC
проектах только если они требуются, при этом в точном соответствии с
требованиями, и для каждого проекта по своему. Это позволяет SoC
интеграторам быть максимально гибкими — они могут
оптимизировать SoC под конкретные требования приложения и
сконфигурировать все многократно используемые блоки на наилучшее соответствие
SoC спецификациям.
Это также значительно увеличивает возможности многократного
использования этих IP блоков, так как они не настроены на какое-то
частное приложение или область действия и могут быть использованы
(через реконфигурационные механизмы) в широком наборе SoC
проектов. Это относится и к новым IP блокам, разрабатываемым с нуля на
основе блочного подхода для конкретного SoC проекта: при условии,
что в процессе проектирования были применены общие принципы
проектирования многократного используемых IP блоков и
соблюдалось соответствие стандартам интерфейсов и стандартам IP блоков
(таких как VSIA, OCP-IP, и.т.д.), данные блоки могут быть потом
повторно использованы в различных SoC. При этом предполагается, что
проектируемый блок удовлетворяет стандартному требованию по
обработке или интерфейсу и может быть сконфигурирован для использования

Глава 4. Библиотеки IP блоков для SoC проектирования
в различных чипах. Это одна из причин того, что стандартные
интерфейсные блоки (например, реконфигурируемые PCI и USB
интерфейсы) и процессорные «ядра» (ARM, Tensilica, ARC и т.д.) являются в
основном блоками, спроектированными специально с целью
многократного использования, в противоположность частным функциональным
блокам, применимым только к одному или нескольким
немногочисленным проектам.
Однако, достижение подобного максимального потенциала
многократного использования, требует значительных затрат на этапе
проектирования. Усилия по достижению возможности многократного
использования данного IP блока - полная документация, широкая
параметризация и сертификация, и возможность широкого реконфигури-
рования — могут потребовать затрат на 50% — 200% больше, по
сравнению с затратами на создание блока для однократного использования в
данной SoC (т.е. создание «виртуального компонента» из «IP блока»
требует в 1.5-3 раза больше усилий). Это значит, что для оправдания
затраченных усилий блоки должны быть потом использованы повторно
как минимум три раза. Вдобавок к этому при таком блочном подходе
требуется очень широкая верификация, так как блок может потом
использоваться в весьма различных и не совсем предсказуемых
приложениях, благодаря встроенной возможности широкого реконфигурирова-
ния и большому количеству интерфейсов. В результате требуемые
усилия настолько больше усилий по созданию блока однократного
использования для единственной SoC, что решение о превращении IP
блока в виртуальный компонент должно быть тщательно взвешено.
Главным достоинством блочного подхода к проектированию SoC
является то, что можно легко оценить требуемые усилия на основе
подхода проектирования всего чипа с нуля. После принятия решения по
использованию блочного подхода и при наличии более-менее полной
спецификации чипа можно выбрать блоки и сравнить требуемые
усилия по созданию одноразовых и многоразовых блоков; усилия по
созданию многократно используемых блоков напрямую вычитаются из
усилий по созданию всего чипа. Для каждого блока многократного
использования требуется некоторая дополнительная верификация
интеграции (так как блок был создан внешней командой), объем которой
очень сильно зависит от качества используемых библиотек IP блоков.
Таким образом, можно напрямую оценить выгоды от многократного
использования и сравнить их с требуемыми дополнительными
усилиями. Все это придает большое значение процессам приобретения,
сертификации, характеризации и документации библиотек многократно
используемых IP блоков, с целью минимизации усилий на конечную
интеграцию и уменьшение риска проектирования SoC.

Платформенное Проектирование 61
Платформенное Проектирование
Предыдущий раздел был посвящен многократному использованию IP
(или виртуальных компонентов) на базе отдельных блоков. Однако, в
последние несколько лет появился более интегрированный подход к
проектированию сложных SoC и многократному использованию
виртуальных компонентов — названный «платформенным
проектированием». Более полную информацию по данной проблематике можно найти
в [6,7,8,9]. Здесь же мы просто определим платформенное
проектирование с одной точки зрения.
Мы можем определить платформенное проектирование как
методологию планируемого проектирования, которая уменьшает требуемые
усилия, время проектирования и проектный риск разработки и
верификации сложных SoC. В отличие от многократного использования на
основе отдельных блоков платформенное проектирование собирает
группы компонентов в многократно используемую платформенную
архитектуру. Такая многократно используемая архитектура, вместе с
библиотеками предварительно верифицированных и предварительно
параметризованных виртуальных компонентов (ориентированных на HW и
SW приложения) является платформой интеграции SoC.
Существует несколько причин роста популярности
платформенного проектирования в промышленном проектировании. Сюда входят
увеличение в производительности проектирования, уменьшение риска,
возможность более эффективного использования
предварительно-интегрированных виртуальных компонентов из других прикладных
областей и возможность повторного использования созданных ранее SoC
архитектур. В индустриальные платформы входят: - платформы
полностью под приложение, переконфигурируемые платформы и
процессорно-ориентированные платформы [10]. Платформы полностью под
приложение, такие как Philips Nexperia и TI ОМАР, обеспечивают полный
набор средств реализации для конкретных прикладных областей [11].
Процессорно-ориентированные платформы, такие как ARM Prime-
Xsys, базируются на процессоре, с соответствующей шинной
архитектурой шины, базовым набором периферии, вместе с операционной
системой реального времени (RTOS) и базовым набором драйверов.
Переконфигурируемые, или «высоко программируемые» платформы,
такие как Xilinx Platform FPGA и Altera SOPC, предоставляют hard-core
процессора вместе с переконфигурируемой логикой,
ассоциированными IP библиотеками и средствами САПР под данный маршрут
проектирования.
Использование интегрированных платформ SoC изменяет процесс
проектирования SoC в двух основных аспектах:

Глава 4. Библиотеки IP блоков для SoC проектирования
1. Базовая платформа должна быть разработана на основе
специального или формализованного процесса проектирования SoC по выбору
авторов платформы. При создании SoC платформы для
многократного использования в дочерних (производных) проектах важно
помнить, что не всегда нужно доводить всю платформу и ее
ассоциированные библиотеки HW/SW компонентов до полной реализации.
Реализация должна быть выполнена в той степени, насколько это
необходимо для полной характеризации платформы и
ассоциированных библиотек, а также для создания моделей многократного
использования. Также важно то, что в процессе создания платформы
сохраняются в архивируемой и доступной форме все проектные
файлы, необходимые для повторного использования платформы и ее
библиотек в процессе проектирования производных проектов. Сюда
должен входить и способ настройки конфигурационных программ
или скриптов, позволяющий автоматическое создание
сконфигурированной платформы при проектировании производного проекта.
2. Процесс проектирования должен быть разработан и применим для всех
производных проектов, использующих данную платформу
интеграции SoC. При этом должны быть обеспечены процессы извлечения
платформы из архива, введения реконфигурационных настроек для
производных проектов, генерация проектных файлов для
производных проектов, генерация соответствующего окружения для
верификации производного проекта, а также возможность выбора
компонент из библиотек, возможность их модификации и проверки в
рамках всей платформы, и возможность создания новых компонентов
для данного производного приложения (в рамках того, что позволяет
платформа).
Переконфигурируемые или высоко программируемые платформы
вносят свое эффективное дополнение в процесс платформенного
проектирования SoC [12]. FPGA платформы и устройства SOPC можно
рассматривать как «мета-платформу»: платформу для создания платформ.
Проектные команды могут получить данные устройства от таких компаний как
ХШпх и Altera. Эти устройства содержат базовый набор общих
возможностей и IP - встроенных процессоров, шин на чипе, специальных IP блоков,
таких как MACs и SERDES, а также набор других предварительно
верифицированных IP блоков. Затем проектные команды могут модифицировать
эту мета-платформу под конкретную прикладную область, добавляя свои
специализированные IP библиотеки. В конце полученная платформа
предоставляется проектным командам, работающим над производными
проектами, которые могут выбрать базовую мета-платформу и
сконфигурировать ее в рамках, заданных промежуточной платформой (упомянутой
выше), выбирая IP блоки, необходимые для конкретного приложения.

Эволюция Проектирования ASIC и ASSP
Эволюция Проектирования ASIC и ASSP
Эволюция от проектирования заказных (custom), создаваемых с нуля
ASIC и ASSP (Application Specific Standard Parts) к SoC
проектированию на основе многократного использования естественным образом
проходит через процесс блочного проектирования, на этапе которого
эволюция может и остановиться. Решение о переходе от блочного
проектирования (которое естественным образом накладывается на
маршрут проектирования полностью заказной ASIC), к
платформенному проектированию зависит от нескольких факторов.
SoC платформы оправданны не для всех прикладных областей.
Для приложений, требующих наивысшей производительности,
наименьшего потребления питания и/или наименьшей цены (например,
высокопроизводительные процессоры и сервера, высококачественное
сетевое оборудование, или очень низкие по цене смешанные (mixed-
signal) SoC для потребительских приложений), блочное
проектирование может оказаться самым оптимальным, даже если оно ведет к
меньшему многократному использованию, более значительным
усилиям по интеграции и большему риску. Конечно, такие приложения
также должны оправдывать увеличение времени, требуемого на
проектирование и увеличение команды проектировщиков, а связанный с
этим более высокий риск должен компенсироваться
долговременными перспективами продукта или просто его популярностью.
Однако существует много прикладных областей, в которых
проектные команды могут постепенно перейти от блочного стиля
проектирования к платформенному проектированию. Например, если
ожидается, что широкий набор SoC будет использовать общую
процессорную подсистему (такую как например, RISC процессор на базе ARM
вместе с ассоциированной шиной (например АМВА), DMA, и т.д.) то
вполне могут оправдаться усилия на превращение этой процессорной
подсистемы в «мини-платформу» для последующего многократного
использования в производных проектах SoC. Если какой-то
интерфейс или функциональный процессорный блок будет использоваться
в большей части планируемых SoC, то их можно добавить в данную
процессорную подсистему, предварительно их параметризуя и
сертифицируя. Это уже становится похоже на SoC платформу,
ориентированную на приложение, но степень специализации и ориентация
находятся полностью под контролем проектной команды и по желанию
Могут быть расширены, если это позволяет снизить затраты.
Либо проектная команда, поставленная перед задачей создания
Новой SoC, может решить приобрести и использовать внешнюю плат-
Форму (от полупроводникового поставщика, такого как Philips или TI,

Глава 4. Библиотеки IP блоков для SoC проектирования
либо от поставщика IP, такого как ARM, с их платформой PrimeXSys
[11]) и разработать SoC на основе данной платформы вместо того,
чтобы создавать все с нуля или использовать блочный подход.
Обсуждавшиеся ранее «двухслойные» платформы от поставщиков
переконфигурируемых платформ, таких какХШпх, в свою очередь, предлагают очень
интересные возможности в некоторых прикладных областях, в которых
преимущества гибкости и быстрого создания продукта перевешивают
FPGA недостатки по цене, производительности и мощности.
Требования на IP Библиотеки
Требования на IP библиотеки в общем не сильно меняются в
зависимости от разных стилей многократного использования. Во всех
случаях все блоки должны сопровождаться полным набором IP моделей,
документации и других вещей, требуемых соответствующими
стандартами. Они должны быть иерархически организованы и
классифицированы для поддержки быстрого поиска, на основе коммерческих схем,
описанных в Design and Reuse [13] или созданных исследовательскими
проектами (такими какТООЫР [14]). Наконец, мета-данные о IP
блоках (»данные о данных» - документационная информация,
поддерживающая быструю идентификацию, поиск и оценку) должны быть
организованы в базы данных с возможностью быстрого поиска.
Однако в платформенном проектировании, в противоположность
блочному подходу, также важно, чтобы IP библиотеки поддерживали
хранение, поиск и извлечение данных на базе всей платформы, а не
только на базе отдельных блоков. Другими словами, платформа,
которая сама по себе состоит из блоков и семейств виртуальных
компонентов, квалифицированных для использования вместе с платформой
- как программных, так и аппаратных - должна храниться и
позволять поиск как единое целое; и с помощью возможностей
иерархических баз данных индивидуальные блоки, составляющие библиотеку
платформы должны быть связаны друг с другом и связаны с самой
платформой. Ясно, что весьма общие функциональные блоки, такие
как процессорные и стандартные интерфейсы, могут входить в
несколько платформ; поэтому важно иметь схему базы данных,
позволяющую сохранить информацию о блоке один раз, и иметь к ней
доступ несколькими разными путями: как к отдельному блоку в
блочном стиле проектирования SoC и как к части платформы; на основе
конкретного блока проектная команда, должна быть способна
определить в какие платформы он входит, является ли он частью
фиксированной архитектуры платформы или относится к переменным
библиотекам платформы.

Архитектуры Интеграции и Последствия для IP Блоков 65
Архитектуры Интеграции и Последствия
для IP Блоков
Современные SoC архитектуры используют традиционные иерархии
стандартных шин на чипе: например процессорные шины,
высокоскоростные системные шины и более медленные периферийные шины, на
основе стандартов типа АМВА от ARM и CoreConnect от IBM [ 11 ], а
также стандартная шина master-slave. Недавно появился большой интерес в
коммуникационных архитектурах типа сеть-на-чипе, основанных на
пакетной технологии (packet-switching); в литературе описано
множество возможных подходов к этой теме, но она пока остается в основном
исследовательской темой, как в университетах так и в промышленных
исследовательских лабораториях. [15]
Протокол Open Core Protocol, разработанный в SONICS и сейчас
поддерживаемый стандартом OCP-IP [5], представляет «ориентирован -
ный-на-коммуникации» подход к архитектурам интеграции SoC - он
фокусируется на стандартной сети коммуникаций SoC и адаптации к
этой сети различных IP блоков, в отличие от более традиционного
акцента на основные функциональные блоки, такие как процессорные
блоки, принятого в «ориентированных-на-процессор» SoC подходах.
Сосредоточение внимания на сети коммуникаций SoC, как
центральном вопросе архитектуры SoC, кажется весьма обоснованным; это
хорошо видно на примере как ОСР, так и направлений развития сети-
на-чипе. Основная причина в том, что пропускная способность и
задержка в коммуникациях на чипе в такой же степени влияют на
быстродействие SoC, как и быстродействие отдельного IP блока. Если
коммуникационная сеть плохо спроектирована, то SoC не сможет
соответствовать заданным спецификациям - и этому не поможет подстановка
других IP блоков. Проблему можно решить только с помощью полного
пересмотра коммуникационной сети. Поэтому выбор топологии сети,
иерархии (число и типы слоев), детальных протоколов коммуникаций и
точной конфигурации сети все чаще и чаще становится центральным в
проектировании SoC.
С переходом SoC от набора 10-20 блоков к 50-100 блокам и далее,
возможно, к сотням отдельных IP блоков, становится доминирующей
проблема межсоединений блоков (соединение на уровне IP блоков), по
сравнению с быстродействием отдельного блока. В этом случае
проектирование SoC отображает, на более высоком уровне, относительные
изменения в задержке межсоединений по сравнению с задержкой
логического элемента (gate), которые мы наблюдали в проектировании
цифровых ИС при переходе от 500 нм процессов к 350, 250, 180, 130, и в
данный момент 90 нм процессам - изменение в относительной важности

Глава 4. Библиотеки IP блоков для SoC проектирования
коммуникаций на чипе и вычислений внутри блока. Таким образом, с
уменьшением минимальных размеров и усложнением задачи создания
надежной сети коммуникаций на чипе, возрастает важность
проектирования коммуникационных сетей на чипе — включая возможный
пересмотр сложности асинхронных стилей проектирования коммуникаций
по сравнению с синхронными.
Адаптация IP блоков:
Коммуникационные Оболочки
Одним из механизмов адаптации IP блоков к различным
коммуникационным архитектурам является использование коммуникационных
адаптеров, или «оболочек». Этот вопрос широко обсуждается в [6], а контек-
се Интерфейса Виртуальных Компонентов (VCI) от VSIA.
Эксперименты, проведенные с VSIA VCI по адаптации периферийных компонентов
с помощью оболочек, показывают, что ухудшение общих параметров
SoC (размер, производительность и мощность) весьма мало (несколько
процентов) по сравнению с интеграцией без оболочек [16].
Преимущества легкости многократного использования и улучшенной адаптации IP
блоков на основе оболочек значительно превышает небольшое
ухудшение общих параметров SoC.
Качество Интеграции IP,
Сертификационные Методы и Стандарты
Мы рассмотрели аспекты многократного использования в
проектировании SoC и необходимость многократного использования как
внутренних, так и внешних IP блоков проектными командами,
разрабатывающими SoC. Выше при обсуждении процесса проектирования мы
упомянули такие вопросы, как стандарты качества IP и необходимость в
инспекции и квалификации IP. Проблема IP качества остается одним из
главных препятствий на пути SoC проектирования на основе IP [17].
Стандарты качества и метрики от VSIA и OpenMORE помогают только
до определенной степени. Для промышленности было бы очень
полезным создание формальной организации по сертификации качества IP,
гарантирующей соответствие требованиям по передаче IP и качество
интеграции блоков. Такой сертификационный процесс, скорее всего, будет
очень сложен по причине большого количества конфигураций,
возможных для многих IP блоков, и почти бесконечного количества SoC
приложений, в которые могут интегрироваться эти блоки.
Сертифицированные IP блоки могут стать теми самыми виртуальными компонентами,
описанными VSIA.

Литература 67
В отсутствие формальной внешней верификации (и похоже, что до
таких сертификационных лабораторий еще далеко) проектные группы
должны создавать на основе своего опыта проектирования свои
собственные сертификационные процессы и реальные метрики по качеству
многократного использования. Методы платформенного
проектирования помогают в этом благодаря преимуществам предварительной
сертификации и характеризации групп IP блоков и библиотек совместимых
компонентов из данной прикладной области. Лучше этого может быть
только независимая оценка и квалификация.
Плановое и систематическое многократное использование IP
вместе с выбором блоков с наибольшим потенциалом повторного
использования дает высокую вероятность повышения производительности
вскоре после начала программы многократного использования. В то время
как непродуманные попытки повторного использования существующих
проектных блоков, не соответствующих стандартам многократного
использования, обычно приводят к провалу и не способны обеспечить
требуемое качество и производительность проектирования.
Литература
1. Michael Keating and Pierre Bricaud, Reuse Methodology Manual for System-on-a-Chip
Designs, Kluwer Academic Publishers, 1998 (First Edition), 1999 (Second Edition), 2002
(Third Edition).
2. International Technology Roadmap for Semiconductors (ITRS), 2001 edition. URL:
http://public.itrs.net/
3. Virtual Socket Interface Alliance, on the web at URL: http://www.vsia.org. This includes
access to its various public documents, including the original Reuse Architecture document
of 1997, as well as more recent documents supporting IP reuse released to the public
domain.
4. The Virtual Component Exchange (VCX). Web URL: http://www.thevcx.com/
5. Open Core Protocol International Partnership. Web URL: http://www.ocpip.org/home
6„ Henry Chang, Larry Cooke, Merrill Hunt, Grant Martin, Andrew McNelly, and Lee Todd,
Surviving the SOC Revolution: A Guide to Platform-Based Design, Kluwer Academic
Publishers, 1999.
"7. K. Keutzer, S. Malik, A. R. Newton, J. Rabaey, and A. Sangiovanni-Vincentelli, System-
Level Design: Orthogonalization of Concerns and Platform-Based Design, IEEE Transactions
on CAD of ICs and Systems, 19, 12, 1523, December 2000.
8. Alberto Sangiovanni-Vincentelli and Grant Martin, Platform-Based Design and Software
Design Methodology for Embedded Systems, IEEE Design and Test of Computers, Volume
18, Number 6, November-December, 2001, pp. 23-33.
9. IEEE Design and Test Special Issue on Platform-Based Design of SoCs, November-
December 2002, Volume 19, Number 6.

Глава 4. Библиотеки IP блоков для SoC проектирования
10. G. Martin and F. Schirrmeister, A Design Chain for Embedded Systems, IEEE Computer,
Embedded Systems Column, March 2002, pp. 100-103.
11. Grant Martin and Henry Chang (Editors), Winning the SOC Revolution: Experiences in
Real Design, Kluwer Academic Publishers, May 2003.
12. Patrick Lysaght, FPGAs as Meta-platforms for Embedded Systems, Proceedings of the IEEE
Conference on Field Programmable Technology, Hong Kong, Dec 2002.
13. L. Ghanmi, A. Ghrab, M. Hamdoun, B. Missaoui, G. Saucier and K. Skiba, E-Design
Based on the Reuse Paradigm, Proceedings of DATE 2002, Paris, March 2002,
pp. 214-220.
14. R. Seepold, N. Martinez Madrid, A. Vorg, W. Rosenstiel, M. Radetzki, P. Neumann and
J. Haase, A Qualification Platform for Design Reuse, Proceedings of the International
Symposium on Quality Electronic Design (ISQED 2002), March, 2002, pp. 75-80.
15. Axel Jantsch and Hennu Tenhunen (editors), Networks on Chip, Kluwer Academic
Publishers, 2003.

ГЛАВА 5
ПРОЦЕСС
ПРОЕКТИРОВАНИЯ SoC
Введение
Говоря о SoC необходимо помнить, что процесс проектирования SoC
имеет мультидисциплинарный характер, т.е. требует использования
подходов к проектированию из всего спектра электроники.
Разработчики обязаны иметь определенные представления обо всех областях
электроники, но они не обязаны быть экспертами в этих областях.
Повторное использование IP-блоков и платформоориентированное
проектирование позволяет исключить необходимость проектировщикам в
освоении нехарактерных для них предметов. Тем не менее, от DFT (Design
for Test - внедрение в проект тестовых структур) до разработки
цифровой и аналоговой аппаратной части, от верификации до системного
проектирования, от разработки встраиваемого ПО до получения и
интеграции IP-блоков, от выбора аппаратной части до анализа СБИС,
команда разработчиков в целом должна обладать достаточным объемом
знаний. Команда, но не отдельно взятый разработчик!
Маршрут проектирования SoC
Ha рисунке 1 показаны некоторые основные составляющие процесса
проектирования SoC. Это естественно, определенная стилизация и
линеаризация маршрута проектирования. В настоящее время на смену
традиционному ниспадающему («waterfall») типу проектирования
приходит спиралевидная методология проектирования. В ниспадающей
модели перед тем, как перейти к следующему этапу должны быть
завершены все проектные задачи на текущем этапе. В более реалистичной
спиралевидной модели проектирование выполняется одновременно по 4-м
направлениям: разработка ПО, разработка RTL-кода, логический
синтез, физический синтез. При этом в процессе работы группы
разработчиков обмениваются результатами проектирования. Например, при
разработке архитектуры SoC может возникнуть необходимость в полной
или частичной реализации какого-то определенного IP-блока, чтобы
оценить его размеры, потребляемую мощность или
производительность, по результатам такой оценки архитектура может быть частично
или полностью модифицирована. Или, например, с помощью средств

70 Глава 5. Процесс проектирования soc
Анализ
требований SoC
Архитектура
SoC
zz^s:
Разработка и анализ
алгоритма
Коммуникационная
архитектура
ч =
Выбор
процессора
-Z-
Системное проектирование
- АО/ПО разбиение;
- моделирование системы;
- анализ производительности.
X
Верификация на
уровне транзакций
Приобретение IP-блоков
Конфигурирование и планировка
микроархитектуры SoC
Определение архитектуры ПО
Ассемблирование ПО
|и его интеграция в SoC
Архитектура DFT
и ее внедрение
х
Интеграция
аппаратных IP-блоков!
Заключительная сборка и верификация SoC
Программно-аппаратная
верификация
Производство, тестирование, упаковка, лабораторные испытания
Рис. 5.1. Этапы процесса проектирования SoC (идеализированный маршрут)
быстрого синтеза (логического и физического) можно сделать оценку
всей архитектуры SoC. Подобная концепция быстрого прототипирова-
ния части проекта или всей SoC на архитектурном уровне является
неотъемлемой частью всех современных маршрутов проектирования.
Определим теперь каждый этап процесса проектирования (рис. 5.1).
Конкретные маршруты проектирования (в бизнесе программных
средств ведущих EDA компаний Cadence Design Iystems и Synophsys),
апробированные на конкретных проектах ASIC (в том числе, и SOC),
приведенны в приложениях №1 и №3.
Анализ требований SoC - это определение и описание сложной SoC,
как конечного продукта, с точки зрения ее необходимости для РЭА, где
она будет эксплуатироваться. Исходной информацией здесь является
набор характеристик будущей SoC, как функциональных, так и
нефункциональных, полученных в результаты маркетинговых исследований:
стоимость, размеры, потребление энергии, производительность, тип корпуса
и т.п. Данный этап должен дать однозначный ответ на вопрос: является ли
проект осуществимым? Какие усилия необходимо приложить, чтобы
осуществить проект? Какая часть проекта может быть сведена к повторному
использованию? Может ли данный проект быть построен на основе

Маршрут проектирования SoC
аналогичных проектов продуктов предыдущего поколения? Или, в
случае, платформоориентированного проектирования, может ли данный
проект быть построен на базе существующей платформы?
Разработка и анализ алгоритма. На данном шаге создаются,
адаптируются и исследуются ключевые алгоритмы работы SoC, как в части
управления системой, так и в части обработки данных. Алгоритмы
управления часто выражаются в форме автомата с конечным числом
состояний. Алгоритмы обработки данных, как правило, записываются на
языке специализированных программных средств, в частности, на языке
C/C++. Для анализа такого рода структур данных могут быть
использованы следующие автоматизированные средства: Mathworks Matlab/
Simulink, Cadence SPW, Synopsys CoCentric System Studio и Ptolemy/
Ptolemy II (разработка профессора Эда Ли из университета Беркли).
Перечислим основные вопросы, ответы на которые должны быть
получены на данном этапе: Какие типы обрабатываемых данных и,
какие управляющие функции необходимы для нормально работы данной
SoC? С какой точностью должны обрабатываться данные? Для систем
связи, например, необходимо определить какие методы и алгоритмы
кодирования/декодирования будут использованы. Можно ли
адаптировать существующие алгоритмы или необходимо создавать новые?
Способен ли выбранный алгоритм обеспечить требуемую пропускную
способность (для систем связи, в частности)? Насколько достоверна,
используемая идеализированная модель канала? Насколько сложен
выбранный алгоритм в реализации на архитектурном уровне?
Архитектура SoC. На данном этапе определяется базовая архитектура
будущей SoC. Как было показано в предыдущей главе, чрезвычайно
важно выбрать коммуникационную архитектуру, которая станет каркасом
для SoC. Выбор неадекватной коммуникационной архитектуры может
сделать SoC чересчур громоздкой, что, в частности, сильно отразится на
ее себестоимости. Естественно в первую очередь нужно определиться с
программируемыми процессорными ядрами. Здесь разработчик должен
ответить на следующие вопросы: Будет ли использоваться RISC
процессор? Будут ли использоваться встроенные DSP ядра? Сколько их
необходимо? Будет ли интегрироваться на кристалл только «голый» процессор
или следует воспользоваться готовой процессорной подсистемой? В
настоящее время процессорные ядра часто комплектуются целой
подсистемой жизнеобеспечения, состоящей из дополнительного набора
IP-блоков, куда могут входит всевозможные интерфейсы, контроллеры памяти,
устройства диагностики, PLL и т.п. Каковы идеи насчет разбиения на
программную и аппаратную части? Какую структуру памяти
предпочтительней использовать? Какие требования должны предъявляться к
блокам встроенной памяти (размеры, быстродействие, доступ).

Глава 5. Процесс проектирования soc
Проектирование на системном уровне является важной частью SoC
процесса - но при этом оно часто проводится довольно неформально.
SoC архитекторы так же часто используют бумагу и доску как и более
продвинутые средства. Однако уже довольно давно на этом этапе часто
используются неформальные модели на основе C/C++ - для проверки
базовых решений по архитектуре. И проектировщики сложных
алгоритмов по обработке сигналов в области аудио-видео обработки уже давно
используют модели потоков данных (dataflow) и соответствующие
специализированные средства для задания своих алгоритмов, определения
оптимальных параметров (в частности, разрядности шин) и проверки
производительности как случае программной, так и для аппаратной
реализации. Активная работа над различными стандартами моделирования
на базе C/C++ для системных архитекторов в последние несколько лет
привела к появлению SystemC [1]. Потребность в моделировании и
анализе сложных устройств (типа SoC) на системном уровне тем выше, чем
сложнее эти устройства. На этом этапе должна быть решена задача
программно-аппаратной декомпозиции. Также здесь необходимо создать
поведенческую модель и проанализировать ее (путем компьютерного
моделирования) на предмет соблюдения требований
функционирования, производительности и нефункциональных атрибутов планируемой
SoC. Наконец, все используемые IP-блоки (как разрабатываемые
заново, так и используемые повторно) должны быть идентифицированы.
После идентификации на системном уровне процессоров,
коммуникационной архитектуры и других IP-блоков (как HW, так и SW),
необходимых для проекта, группа разработчиков должна предпринять действия
по приобретению IP-блоков. На практике данный этап может быть
достаточно продолжительным по времени, тем не менее, он может
выполняться параллельно с другими фазами, например, системным
проектированием (предполагается, что внешние IP-блоки уже
идентифицированы) или верификацией на уровне транзакций. Удачно, когда группа
работает в большой фирме, где или существует большой выбор
собственных IP-блоков организованных в удобную базу данных, или по
договоренности есть выход на внешнюю библиотеку IP-блоков, или в группе
есть как минимум один человек с опытом поиска, оценки, покупки и
интеграции IP-блоков. Подобным «счастливым» группам решать проблемы
данного этапа гораздо проще. Для других групп с меньшим опытом и
уровнем инфраструктуры придется вплотную заняться исследованием
этих вопросов, и, в первое время придется довериться опыту
поставщиков IP-блоков. Чтобы сгладить некоторые неровности на этом пути
можно воспользоваться существующими стандартами на IP-блоки такими,
как VSIA и/или VCX. Одна из ключевых трудностей, это проведение
строгой и исчерпывающей проверки приобретаемых IP-блоков на пред-

Маршрут проектирования SoC
мет их достоверности и полноценности, а также выявление возможных
ошибок до этапа интеграции.
Верификация на уровне транзакций. Поведенческая модель,
построенная на этапе системного проектирования, может служить основой для
создания более детализированной модели, использующей абстракции
уровня транзакций [2]. Модель уровня транзакций позволяет построить
виртуальный прототип системы для проведения функциональной
верификации программной и аппаратной частей проекта на уровне
архитектуры. Его еще называют золотой макет схемы (golden testbench).
Виртуальный прототип позволяет верифицировать, как полную
микроархитектуру проекта, так и его отдельные части, описанные на аппаратурных
языках (Verilog, VHDL), в контексте всего проекта.
Определение архитектуры встраиваемого ПО. Вполне очевидно, что
система на кристалле это не просто СБИС, а комплекс, содержащий
также встраиваемое программное обеспечение. Несомненно, что
специфика области электроники, в которой будет эксплуатироваться
разрабатываемая SoC, оказывает значительное влияние не только на выбор
коммуникационной архитектуры или процессорного ядра, но и в не
меньшей мере (а часто и в большей) на ПО. В частности, выбор базовой
операционной системы реального времени (RTOS - Real-Time
Operating System) напрямую зависит от типа процессора (а точнее - от
его разрядности), который, в свою очередь, определяется конкретной
областью применений будущей SoC. Так, например, OSEK это
операционная система (ОС) для автомобильных систем, Symbian OS - для
устройств беспроводной связи (мобильные телефоны), PalmOS - для PDA
(Personal Digital Assistants) портативных ПК и т.д. Периферийные
устройства SoC должны быть обеспечены драйверами -
специализированным ПО, которое обеспечивает взаимодействие прикладного ПО, RTOS
и аппаратной периферии. По аналогии с аппаратными IP-блоками (HW
IP) здесь имеет смысл говорить о программных IP-блоках (SW IP).
Различные готовые пакеты (или библиотеки) специализированных
программ - важная часть архитектуры встраиваемого ПО. Программы
кодирования/декодирования голоса или изображения часто поставляются
в виде готового ассемблерного кода для конкретных DSP или CPU.
Таким образом, при создании SoC необходимо четко и полно определить
всю архитектуры программного обеспечения. Какую выбрать
операционную систему? Как организовать взаимодействие ОС, прикладного ПО
и периферии? Какие программные блоки можно получить со стороны и
использовать повторно, а какие придется разрабатывать полностью?
Конфигурация и планировка микроархитектуры SoC. На этом этапе мы
начинаем рассматривать SoC более детально с точки зрения логического
и физического проектирования. Конечно, и во время высокоуровневого

Глава 5. Процесс проектирования soc
проектирования команда разработчиков вынуждена изучать и учитывать
определенные трудности физического проектирования. Но прежде .чем
начать действительно детализировать проект до физического уровня
должны быть выполнены следующие условия:
• должно быть достигнуто соглашение между членами команды по
поводу физической планировки кристалла;
• все IP-блоки должны быть полностью и окончательно
сконфигурированы;
• должна быть до конца определена и сконфигурирована
микроархитектура (тесты, питание, тактовые сигналы, шины, временные параметры);
• все аппаратные блоки должны быть реализованы (хотя бы в виде
RTL-кода).
Кроме этого, необходимо сгенерировать тестовое окружение,
которое будет в дальнейшем использоваться для верификации SoC
программным путем, на основе аппаратной эмуляции или акселерации, с
использованием прототипа или любыми другими методами.
Архитектура DFT и ее внедрение. Дополнительные схемы для
тестирования и самотестирования готовых СБИС (DFT - Design-for-Test)
должны быть обязательно встроены в проект SoC. Положение
затрудняется использованием готовых IP-блоков. Различные IP-блоки от разных
поставщиков и производителей, как правило, имеют разные средства
самотестирования, поэтому при разработке SoC скорей всего придется
комбинировать все эти средства (такие как, BIST - Build-in Self Test, или
SCAN). Можно адаптировать различные тестовые средства к
стандартному тестовому протоколу (например, JTAG) и разработать
объединенный тестовый план.
Реализация и внедрение AMS блоков. Большинство SoC включают в
себя аналоговые и смешанные (цифро-аналоговые) блоки (AMS -
Analog/Mixed Signal), чтобы обеспечить связь с внешним миром. VSI
альянс, в сотрудничестве с другими организациями, разработал пакет
документов с рекомендациями по созданию AMS IP-блоков и их интеграции в
SoC. Данный пакет ориентирован на SoC типа «Big D/Little A» (т.е.
большая часть - цифровая, меньшая - аналоговая). SoC типа «Big A/Big D»
встречаются достаточно редко.
Интеграция аппаратных IP-блоков. Данный этап, как правило,
решается традиционными способами. Большинство проектных групп уже
имеет достаточный опыт в сборе и монтаже готовых проектных блоков,
выполненных другими разработчиками, в соответствии с принятой
архитектурой. Основное отличие SoC от традиционных СБИС в том, что
часто приходится работать с блоками, разработанными на стороне.
Чтобы избежать трудностей здесь следует проводить тщательную
квалификацию и отбор поступающих извне IP-блоков.

Маршрут проектирования SoC
Ассемблирование ПО и его интеграция в SoC. IP-блоки, с
программным обеспечением, точно также, как и чисто аппаратные IP-блоки,
должны быть адаптированы к конкретной SoC, интегрированы и
верифицированы в составе SoC. Очень важно здесь верифицировать работу
программного IP-блока именно в контексте задач, решаемых всей SoC,
и под управлением встраиваемой RTOS (см. ниже).
Программно-аппаратная верификация. Хотя программно-аппаратная
верификация и представлена на блок-схеме маршрута в виде всего
одного блока, на практике это одна из самых трудоемких и ресурсоёмких
задач, от решения которой будет зависеть качество всей SoC. Чтобы
верификация была эффективной необходимо использовать результаты по
разработке тестового окружения, полученные на предыдущих этапах
(«золотой прототип»). Кроме этого важно, чтобы средства верификации
были с поддержкой нескольких языков описания и с поддержкой
смешанного моделирования. Например, необходимо правильно совмещать
SystemC модели и HDL описания аппаратуры.
В настоящее время существует широкий спектр средств
программно-аппаратной верификации: от чисто программных симуляторов, до
эмуляторов и акселераторов аппаратной части, а также прототипов на
ПЛИС (FPGA). В последнее время все чаще используют средства
верификации на основе формальной верификации (без моделирования),
например, контроль свойств моделей. Существует целый ряд подходов для
выполнения совместной верификации АО и ПО одновременно - ко-ве-
рификации. В частности, встраиваемое ПО на уровне инструкций
процессора (ISS — Instruction Set Simulator) может быть полностью
реализовано в виде программной модели (например, на языке C/C++), или
аппаратная часть в виде RTL-кода может быть передана аппаратному
эмулятору (например, Palladium), а программная часть будет выполняться
на рабочей станции в режиме реального времени. Другой подход к
выполнению программно-аппаратной верификации - создание
смешанного прототипа, где вновь разрабатываемые блоки могут либо
эмулироваться, либо моделироваться на рабочей станции, программное
обеспечение исполняется в «живом» процессоре, установленном на печатную
плату, которая через специальный интерфейс подключена к рабочей
станции. Дополнительно к этому, те IP-блоки, которые уже были
реализованы в виде «живых» электронных компонент, также могут
устанавливаться на печатную плату вместе с процессором.
Тенденция к моделированию системы на уровне транзакций, где
абстракция одной транзакции может колебаться в пределах от
безвременных функциональных коммуникаций с помощью сообщений, от
абстрактной модели коммуникационной шины, до функциональной модели
шины с циклической точностью и, наконец, до полной детализации

Глава 5. Процесс проектирования soc
интерфейса на уровне выводов (pin), позволяет выполнять верификацию
всей SoC на нескольких уровнях или путем смешивания различных
уровней описания проекта.
Еще одно сравнительно новое направление в верификации это ас-
серты (assertion) - определенные формальные утверждения
специального вида, для записи которых могут использоваться различные входные
языки (PSL/Sugar [5], ~е~ [6], Vera [7]). С помощью ассертов можно
наблюдать за изменением свойств моделей в процессе симуляции, в
частности, чтобы убедиться, что определенное условие на протяжении
процесса всегда выполняется, или, напротив, что ошибочное условие ни
разу не возникает.
Независимо от наличия средств и инструментов команда
разработчиков должна помнить одну вещь, что только хорошая организация
процесса верификации позволит получить точный ответ на вопрос:
«Как нам узнать, что верификация выполнена?» и перейти к
дальнейшей работе.
Заключительная сборка SoC и верификация. Фаза заключительной
сборки и верификации включает в себя: размещение, трассировку всего
кристалла, физическую верификацию, состоящую из контроля
технологических норм (DRC - Design Rule Checking), проверки соответствия
топологии и схемы (LVS - Layout vs. Schematic) и экстракции паразитных
элементов (RCX - Resistor Capacitor extraction). Схемы,
изготавливаемые по технологиям глубокого субмикрона (DSM - Deep Submicron)
0.18 мкм и меньше, должны проходить анализ на предмет отсутствия в
них характерных для DSM эффектов: падения напряжения на шинах
земли/питания (IR-drop), целостность сигнальных цепей (signal
integrity), целостность цепей земли/питания (power network integrity) и пр.
Производство, тестирование, корпусирование и лабораторные
испытания. После того, как SoC передана на производство, кажется, что у
команды разработчиков есть время отдохнуть. Однако, это время можно
более рационально использовать для того, чтобы более детально
проработать и проверить ПО в контексте аппаратной части SoC. На практике
иногда применяют подход, когда отдельные ошибки в аппаратной части
могут быть локализованы и устранены с помощью ПО.
Когда протестированный и корпусированный на заводе опытный
образец микросхемы SoC передается для окончательной верификации в
лабораторию, идеальный сценарий для проверки это загрузка ПО и
тестирование всей системы целиком в течение нескольких часов. Следует
отметить, что большинство продвинутых команд разработчиков с
хорошо организованной методологией и маршрутом проектирования
регулярно добиваются успеха в разработке SoC без дополнительных
незапланированных затрат.

Системный уровень проектирования
Системный уровень проектирования
Основной целью многократного использования IP-блоков и таких
методов создания SoC, как платформоориентированное проектирование,
является упрощение процессов разработки реализации проекта «back-
end», (RTL в GDS II) Т.е. задача - сделать их быстрыми и с низким
уровнем риска, что естественно приводит к переносу основных усилий и
временных затрат на системный уровень проектирования. Это также
означает, что инструментальные средства back-end и маршруты
проектирования SoC, могут быть похожи на средства, используемые при
разработке ASIC, ASSP и специализированных СБИС. Отличие может быть
только в методологии их использования, и в том, как IP-блоки
создаются/приобретаются и интегрируются. Однако фундаментальная природа
проектирования на основе IP-блоков оказывает более сильное влияние
на системный уровень.
Именно на системном уровне решаются очень важные задачи
выбора и аттестации базовой системной архитектуры, а также выбора
IP-блоков. Это называется «исследованием пространства проектирования»
(DSE - Design Space Exploration). Если используется платформоориен-
тированый подход, тогда в это исследование также входит настройка
(customization) SoC платформы под конкретные задачи. Исследование
пространства проектирования платформы можно рассматривать как
задачу, похожую на общее DSE, с той разницей, что область и границы
исследования гораздо более строго ограничены — могут быть
фиксированы базовая коммуникационная архитектура, процессор. Проектная
команда также может быть ограничена в выборе параметров настройки и
IP-блоков.
К другим задачам относится программно-аппаратная
декомпозиция, обычно ограничивающаяся рассмотрением ключевых функций,
которые могут быть реализованы как в ПО, так и в АО виде, и которые
оказывают большое влияние на производительность системы,
требуемую мощность, пропускную способность коммуникаций на чипе и
другие ключевые характеристики. В многопроцессорных системах
возникают также задачи разбиения ПО-ПО, или вопросы совместного
проектирования («co-design»). Около 80-95% этих решений могут быть приняты
заранее (a-priory), особенно если SoC основана либо на платформе,
либо на базе уже разработанной и эксплуатируемой системы. Решения по
совместному проектированию обычно принимаются для небольшого
набора наиболее важных функций.
Так как задачи разбиения, совместного проектирования (co-design) и
DSE на системном уровне требуют гораздо больше усилий, чем вопросы
АО-ПО декомпозиции, более подходящим для этого термином является

78 Глава 5. Процесс проектирования soc
«function-architecture co-design» [8,9] (совместное
функционально-архитектурное проектирование). В такой модели система одновременно
описывается на двух равноценных уровня.::
• Функциональное назначение - сеть приложений системы,
разделённая на ряд функциональных задач, которые могут
моделироваться с помощью различных вычислительных моделей, таких, как
дискретные события, конечные автоматы (FSM) или потоки данных.
• Архитектурная структура — архитектура коммуникаций, основные
IP-блоки, такие как процессор, память, и основные аппаратные
блоки.
Такой подход подразумевает следующую методологию. Сначала
необходимо построить явные отображения между двумя представлениями
системы: функциональным и архитектурным, а потом наложить на них
разбиение, сделанное для вычислительных задач и коммуникаций.
Полученную гибридную модель можно промоделировать, а затем
проанализировать результаты на предмет изучения пригодности системной
архитектуры в качестве средства реализации конечного продукта. Такой
подход проиллюстрирован на рис.5. 2.
На рисунке 2 шаги под номерами 1 и 2 представляют собой фиксацию
и анализ функциональности и архитектуры SoC в двух эквивалентных
ЩР Системные
функции
Т±
Моделирование
гш
Системная
архитектура
?
Отображение
-г*
Анализ
производительности
Детализация
коммуникаций
Маршрут реализации
Рис. 5.2. Совместное функционально-архитектурное проектирование.

Новые архитектуры SoC
представлениях. На шаге 3 происходит отображение и анализ
пригодности архитектуры для реализации SoC. И, наконец, шаг 4 - детализация
архитектуры (добавление деталей, особенно о коммуникациях, в
системные модели) и детальная реализацию SoC.
Подход совместного проектирования функций и архитектуры
реализован и используется, как в исследовательских, так и в коммерческих
программных средствах САПР [ 10]. Этот подход также может удачно
использоваться в случае платформоориентированного проектирования
SoC [11].
Новые архитектуры SoC
В SoC используются в основном встроенные RISC процессоры - ARM,
PowerPC, MIPS и некоторые конфигурируемые процессоры,
спроектированные специально для интеграции в SoC (Tensilica, ARC). Вдобавок
к этому, во многих потребительских приложениях для обработки аудио и
видео данных используются встроенные DSP процессоры от
традиционных поставщиков - Texas Instruments, Motorola, ParthusCeva и других.
Исследователи в области SoC изучают вопросы компиляции и
синтеза специализированных процессоров, конфигурируемых под
конкретные приложения [12, 13]. Такие процессоры могут сыграть большую
роль в будущем. Это особенно интересно, если учесть все более широкое
использование реконфигурируемой логики, способной выполнять
динамическую адаптацию SoC к требованиям приложений. Однако
сегодня большая часть многопроцессорных SoC использует не более 2-4
традиционных процессоров; сети больших размеров можно найти обычно
только в промышленных или научных лабораториях.
Внедрение гетерогенных многопроцессорных архитектур,
использующих сети на чипе, ещё больше увеличит значимость системного
проектирования и архитектурного анализа SoC. Вполне вероятно, что в
будущем одной из главных задач при проектировании SoC будет создание
архитектуры, конфигурации, и определение наиболее оптимальных
отображений наборов задач на гетерогенные вычислительные и
коммуникационные ресурсы.
Хотя несколько лет назад большая часть встроенных процессоров не
использовали кэш-иерархии на базе памяти, ситуация изменилась, и
сегодня многие RISC и DSP процессоры содержат значительное
количество кэш-памяти 1-го уровня, а также более высоких уровней, как на
чипе, так и за его пределами. Средства и задачи системного
проектирования должны рассматривать структуру, размер и конфигурацию иерархии
памяти как одно из ключевых решений конфигурации всей SoC.

80 Глава 5. Процесс проектирования soc
Литература
1. Thorsten Groetker, Stan Liao, Grant Martin and Stuart Swan, System Design with
SystemC, Kluwer Academic Publishers, May, 2002.
2. Janick Bergeron, Writing Testbenches, 3rd. Edition, Kluwer Academic Publishers, 2003.
3. G. Martin, and С Lennard, Improving Embedded SWDesign and Integration for SoCs,
Custom Integrated Circuits Conference, May 2000, pp. 101-108.
4. Prakash Rashinkar, Peter Paterson and Leena Singh, System-on-a-Chip
Verification: Methodology and Techniques, Kluwer Academic Publishers, 2001.
5. Ben Cohen, Using PSL/Sugarwith Verilogand VHDL, VhdlCohen Publishing, 2003.
6. Samir Palnitkar, Design Verification with e, forthcoming from Prentice Hall PTR, August,
2003.
7. Faisal Haque, Jonathan Michelson and Khizar Khan, The Art of Verification with Vera,
Verification Central, 2001.
8. F. Balarin, M. Chiodo, P. Giusto, H. Hsieh, A. Jurecska, L. Lavagno, С Passerone,
A. Sangiovanni-Vincentelli, E. Sentovich, K. Suzuki, and B. Tabbara, Hardware-Software
Co-Design of Embedded Systems: The POLIS Approach, Kluwer Academic Publishers,
Dordrecht, The Netherlands, 1997.
9. S. Kjolikoski, F Schirrmeister, B. Salefski, J. Rowson and G. Martin, Methodology and
Technology for Virtual Component Driven Hardware/Software Co-Design on the System
Level, paper 94.1, ISCAS 99, Orlando, Florida, May 30-June 2, 1999.
10. G. Martin and B. Salefski, System Level Design for SoCs: A Progress Report - Two Years On,
Chapter 25 in: System-on-Chip Methodologies and Design Languages, editor Jean
Mermet, Kluwer Academic Publishers, 2001, pp. 297-306.
11. G. Martin, Productivity in VC Reuse: Linking SoCplatforms to abstract systems design
methodology, Chapter 3 in Virtual Component Design and Reuse, edited by Ralf Seepold
and Natividad Martinez Madrid, Kluwer Academic Publishers, 2001, pp. 33-46.
12. Vinod Kithail, Shail Aditya, Robert Schreiber, B. Ramakrishna Rau, Darren
С Cronquist and Mukund Sivaraman, PICO: Automatically Designing Custom Computers,
IEEE Computer, September 2002, Volume 35, Number 9, pp. 39-47.
13. T.J. Callahan, J.R. Hauser, and J. Wawrzynek, The Garp architecture and С compiler,
IEEE Computer, April 2000, Volume 33 Issue 4 • April 2000 pp. 62-69.

ГЛАВА 6
ЯЗЫК SystemC
В ПРОЕКТИРОВАНИИ
НА СИСТЕМНОМ УРОВНЕ
Введение -
Преимущества Использования SystemC
Для проектирования и верификации SoC на системном уровне
требуется язык проектирования и верификации, созданный в расчете на
поддержку абстракций проектирования на системном уровне, а также с
учетом сложности современных SoC.
• Системы и SoC содержат как аппаратную часть, так и программную,
реализуемую на программируемых процессорах. Следовательно,
язык проектирования и верификации SoC должен интегрировать
модели как аппаратных, так и программных компонентов. Он также
должен поддерживать симуляторы систем команд
программируемых процессоров, с помощью которых можно выполнять
скомпилированный объектный код.
• Системы и SoC построены из проектных элементов и компонентов,
которые обрабатываются по разному, в разных «моделях
вычислений» — таких как потоки данных (dataflow), конечные автоматы,
дискретные события и аналоговая/смешанная область - модели
этих компонентов формулируются на основе различных
вычислительных предположений. Следовательно, язык проектирования и
верификации SoC должен поддерживать интеграцию различных
вычислительных моделей.
• SoC схемы можно проектировать «сверху-вниз» или «снизу-вверх»;
т.е. начиная либо с моделей высокого уровня, которые далее
детализируются, либо с моделей реализации, которые затем
абстрагируются для улучшения эффективности выполнения, либо со смешанного
набора моделей . Следовательно, язык проектирования и
верификации SoC должен позволять совместное существование и
взаимодействие моделей на разных уровнях абстракции - функциональном,
архитектурном, на уровне транзакций и на уровне сигналов и бит.
• В создании компонентов и моделей SoC могут принимать участие
эксперты из различных областей: аппаратной, программной,
алгоритмической и системной. Следовательно, язык проектирования и

Глава 6. Язык SystemC в проектировании на системном уровне
верификации SoC должен основываться на обозначениях, знакомых
всем этим специалистам.
• В процессе проектирования SoC должна проводиться ее
верификация. Верификация должна проходить на разных уровнях
абстракции, от функционального через уровень транзакций до уровня
реализации. Тестовые платформы верификации должны быть пригодны
для использования на всех этих уровнях, для повышения
эффективности и производительности проектирования. Появляются новые
методы верификации, которые должны также поддерживаться
средой проектирования и верификации. Следовательно, язык
проектирования и верификации SoC должен поддерживать специальные
верификационные примитивы, быть пригодным к употреблению на
всех уровнях и поддерживать повторное использование.
• Проектирование на базе IP-блоков и платформ требует повторного
использования компонентов проектирования и верификации. Это
наиболее вероятно в том случае, когда модели создаются на широко
распространенных и доступных языках и в обозначениях, созданных
с учетом повторного использования. Следовательно, язык
проектирования и верификации SoC должен быть «спроектирован в расчете
на повторное использование».
• Со стороны аппаратной части надо учитывать также этап реализации
SoC, а не только этапы моделирования и проектирования.
Реализация цифровой аппаратной части происходит преимущественно с
помощью RTL синтеза. Следовательно, язык проектирования и
верификации SoC должен поддерживать детализацию реализации или
синтеза до RTL уровня.
• SoC проекты содержат сложные схемы коммуникаций на чипе.
Моделирование коммуникаций на чипе так же важно, как и
моделирование функциональности отдельных блоков. Следовательно, язык
проектирования и верификации SoC должен поддерживать
моделирование коммуникаций на различных уровнях и интеграцию этих
моделей в работоспособную модель системы.
Почему SystemC является подходящим языком для спецификации,
моделирования, проектирования и верификации SoC схем и систем?
Рассмотрим свойства и преимущества этого языка в свете описанных
выше требований:
• SystemC основан на C++ и построен на основе расширения
библиотек и ядра симуляции, написанном на C++. Следовательно, он
способен интегрировать все основанные на C++ модели, включая симу-
ляторы систем команд, программные модели, аппаратные модели и
результаты работы средств моделирования на высоком уровне,
генерирующих С или C++ код.

Введение — Преимущества Использования SystemC
• SystemC использует такие примитивы, как каналы, интерфейсы и
методы, которые дают большую гибкость в моделировании на
основе различных вычислительных методов и обеспечивают
возможность совместной работы этих моделей. Были продемонстрированы
системные модели, комбинирующие HW дискретных событий,
аналоговую часть, потоки данных, программную часть и конечные
автоматы - и все на SystemC.
• SystemC поддерживает модели на всех уровнях абстракции и
использует, в рамках инициативы OSCI (Open SystemC Initiative),
стандартную семантику на уровне транзакций и API, что гарантирует
возможность совместной работы моделей.
• Язык SystemC основан на C++, который в свою очередь основан на
С. Хотя, возможно, C/C++ и не совсем знаком некоторым
специалистам по HW, большинство разработчиков и экспертов в
аппаратной области, программной, области алгоритмов и системной
области более менее знакомы с C/C++. Редкий выпускник технического
вуза сейчас не встречался с C/C++ во время обучения. SystemC
основан на широко известном языке.
• SystemC поддерживает современные методологии верификации с
помощью многоуровневой библиотеки верификации SystemC (SCV
- SystemC Verification library). SCV поддерживает создание тестовых
платформ, запись транзакций (входные сигналы, мониторы,
проверка откликов), рандомизацию переменных, наложение
ограничений/связей, а также применение новых методологий верификации
на основе транзакций.
• SystemC создан в расчете на проектирование на базе IP-блоков и
повторное использование проектных и верификационных
компонентов, на основе C++ и OSCI стандартов по взаимодействию
компонентов на уровне транзакций. SystemC «спроектирован для
повторного использования».
• SystemC поддерживает моделирование аппаратной части и
детализацию проекта до RTL уровня. SystemC обеспечивает
взаимосовместимость аппаратных, сигнальных и битовых структурных
компонентов, и полностью поддерживает как ручную детализацию, так и
методы синтеза до уровня RTL и далее.
• SystemC предоставляет каналы, модули, интерфейсы и методы,
позволяющие гибко, удобно и эффективно моделировать все виды схем
коммуникаций на чипе - стандартные шины, сетевые и типа точка-
точка (point to point). Моделирование коммуникаций на чипе
естественным образом поддерживается в SystemC.
Таким образом, очевидны преимущества SystemC для
проектирования SoC. SystemC естественным образом поддерживает все основные
требования к языку проектирования и верификации SoC.

Глава 6. Язык SystemC в проектировании на системном уровне
В тоже время в течение последних двух лет разгорелась значительная
дискуссия и даже возникла некоторая путаница по поводу ролей,
занимаемых различными уже существующими, а также новыми, либо
модифицированными языками проектирования. Если мы захотим составить
список языков, используемых в проектировании сложных систем или
SoC проекте, получится примерно следующее:
• В большинстве SoC проектов присутствует хотя бы один
программируемый процессор. Поэтому нам скорее всего придется работать с
симулятором набора инструкций (ISS), подсистемой памяти и
шиной (например ARM+AMBA), и все это может быть смоделировано
в SystemC. На самом деле весьма вероятно наличие двух
процессоров, RISC-типа и DSP, каждый со своей подсистемой
моделирования и ISS.
• На этих процессорах будут выполняться какие-то встроенные
программы - системные и прикладные аппаратно-зависимое SW(HdS),
прикладное и посредническое SW. Добавляем соответственно языки
С, C++ и/или Java.
• Команда разработчиков может создавать либо модифицировать
цифровые IP блоки - некоторые из них (например, блоки обработки
сигналов/изображений или кодирования/декодирования)
моделируются в Matlab/Simulink (потоки данных), а некоторые в Verilog или
VHDL.
• В наши дни редкий SoC проект обходится без цифровых IP блоков
приобретенных со стороны - которые описываются на языках
Verilog или VHDL.
• Во многих SoC проектах есть блоки AMS (analogue/mixed-signal)
интерфейсов или тактовые генераторы на основе PLL (phase-locked
loop), приобретенные со стороны либо созданные проектными
командами - они моделируются на Spice, либо на Verilog или VHDL
варианте в случае AMS интерфейсов (Verilog-A, VHDL-AMS) для того,
чтобы AMS интерфейсы могли быть протестированы в рамках
общего проекта SoC, путем подключения их моделей к симулятору
смешанного моделирования.
• Также необходимо создать тестовые платформы (testbench) и тесты
для верификации проекта. Хотя для этого обычно используются
HDL языки, в последнее время растет интерес в
специализированных языках аппаратной верификации (Hardware Verification
Languages - HVLs) - таких как «е» от Verisity, Vera от Synopsys, Open
Verification Library (OVL) на основе HDL, а также создаваемые в
данный момент языки SystemVerilog и Verilog-2005. Конечно, для этих
целей может использоваться и новая библиотека верификации
SystemC - SystemC Verification Library (SCV).

Введение — Преимущества Использования SystemC
• Утверждения - Ассёрты (assertions) и верификация на основе ассер-
тов представляют собой новый способ спецификации проектных
характеристик, как в случае формальной (статической) верификации,
так и динамической (на базе симуляции). Для этих целей могут быть
использованы такие языки как Open Vera Assertions (OVA), Accellera
Property Specification Language (PSL), основанный на Sugar от IBM,
и ассерты языка SystemVerilog. В реальном проекте IP блоки,
приобретенные от различных поставщиков, могут содержать ассерты
заданные на всех перечисленных выше языках.
Если мы теперь подсчитаем все языки и системы обозначений,
используемые в проекте, то получим как минимум девять, и как максимум
может быть даже 16 или 17 различных форматов!
И, тем не менее, существуют способы работы с таким количеством
языков. Сначала мы должны понять, что каждому языку соответствуют
конкретные цели или модели использования. Для каждой задачи
проектирования часто могут быть одинаково пригодны сразу несколько
языков. Наконец, очень маловероятно, что какой-либо единственный язык
может решить все задачи системного проектирования - от
спецификаций на высоком уровне до RTL реализации; от верификации через
моделирование до синтеза; от создания встроенных программ до
аппаратного проектирования.
При рассмотрении широкой области проектирования на системном
уровне очевидно, что SystemC является языком системного
проектирования, покрывающий наиболее важные уровни абстракции в
проектировании на системном уровне, от не временного (untimed)
функционального моделирования HW-SW платформ на уровне транзакций до
реализации на уровне RTL [ 1,2]. Он позволяет проектным командам
моделировать и верифицировать проекты, на действительно системных
уровнях абстракции, а затем детализировать эти проекты, отражая
детали реализации, и, в конце концов, связать системную модель с
реализацией и верификацией аппаратного проекта. В SystemC можно создать
модель-прототип проектной платформы на уровне транзакций, что
позволяет быстро верифицировать тестовые платформы на системном
уровне перед тем, как переходить к дальнейшей детализации. SystemC
является естественным моделирующим языком для решения всех
проблем, возникающих в системах и платформах со смешанной аппаратной
и программной частью.
Далее обсудим язык SystemC и его использование в проектировании
на системном уровне. После краткого рассмотрения контекста SystemC
и его связей с другими языками мы рассмотрим основные уровни
абстракции и модели использования SystemC. Сюда входят:

Глава 6. Язык SystemC в проектировании на системном уровне
• Функциональное моделирование системных алгоритмов.
• Моделирование системных архитектур на уровне транзакций.
• Моделирование на уровне RTL и привязка SystemC к маршрутам
реализации.
• Недавние добавления к SystemC на тему верификации: библиотека
верификации SystemC.
В конце мы обсудим возможное будущее развитие SystemC как
стандарта а также возможные новые особенности SystemC.
Контекст SystemC
Из предыдущего обсуждения ясно, что проектные языки можно
сравнить с комнатами многоэтажного здания: у них есть и потолок и пол
(ограничения сверху и снизу). Так как не существует языка,
охватывающего все здание сверху вниз или снизу вверх, мы должны корректно связать
этажи друг с другом - с помощью лестниц (ручные методы) либо лифтов
(автоматизированные методы), чтобы проектные команды смогли
доставить соответствующую «мебель» (информация о проекте, верификации
и ограничениях) с одного этажа на другой. Таким образом, мы сможем
достичь гармоничного взаимодействия проектных и верификационных
языков.
С одной стороны, SystemC не является оптимальным языком для
HDL и проектирования на вентильном уровне, с другой стороны,
Verilog-2005 (и SystemVerilog) плохо подходят для моделирования на
системном уровне и создания высокопроизводительных системных
прототипов. Именно взаимодействие различных языков позволяет создать
высокопродуктивные маршруты проектирования с минимумом риска.
Учитывая это необходимо помнить о том, что и язык SystemC
ограничен сверху. Хотя новая версия 3.0 скорее всего будет содержать
возможности моделирования и планирования программ, она не станет платформой
по разработке программного обеспечения. Продвижения в мире
моделирования программ с помощью UML дают надежду на появление в этом
году UML версии 2.0, которая обещает значительно улучшенные
возможности по моделированию системных программ и генерации кода,
особенно в случае встроенных систем реального времени [3]. Одной из
многообещающих областей для будущей методологической работы является
создание мира трех языков, в котором программы, заданные и
смоделированные в UML, могут генерировать оптимизированный под
платформу код, который в свою очередь может быть симулирован на уровне
транзакций в рамках платформенной модели на основе SystemC, с
использованием соответствующих моделей ОС. Аппаратная часть проекта будет

Аспекты SystemC
верифицироваться и реализовываться с помощью Verilog-2005 или
VHDL, с использованием созданных ранее функциональных
прототипов. Такой подход является одной из моделей использования
(контекстом) SystemC в проектировании на системном уровне. Конечно SystemC.
можно также использовать для построения не временных (untimed)
функциональных аппаратных моделей, затем трансформируя их в
реализацию на уровне регистровых передач (RTL), и далее синтезировать
или транслировать вручную в реализацию с помощью Verilog или VHDL.
Это также интересная модель использования SystemC в качестве языка
системного проектирования.
Необходимо помнить о том, что контексты использования SystemC
не требуют какого-либо строгого маршрута проектирования, например
сверху-вниз, снизу вверх или как-либо еще. Так как большая часть
маршрутов проектирования итеративна, и редко бывает так, что все части
проекта смоделированы на одном уровне абстракции, важно отметить,
что уровни абстракции моделирования часто комбинируются в единую
системную модель. При этом нужно также учитывать практику
повторного использования, означающую, что редко какой-либо проект
начинается с чистого листа. Как было указано во введении, практические
SoC проекты требуют взаимодействия многих различных проектных и
верификационных моделей на разных уровнях абстракции.
Перечислим распространенные методы проектирования,
использующие разные уровни моделирования: объединение модели уровня
детальной реализации (например RTL) верифицируемого проекта с
абстрактной моделью тестовой платформы, генерирующей тестовые
импульсы и отслеживающей отклики; использование более абстрактной
модели отдельного IP блока, с целью ускорения симуляции или защиты
интеллектуальной собственности блока; детализация одного блока с
уровня спецификации на уровень транзакций и далее в RTL модель, и
последующее объединение данного блока в единую системную модель с
другими блоками, оставшимися на уровне спецификации.
Аспекты SystemC
Точность Моделирования
Как и в случае VSIA (Virtual Socket Interface Alliance) классификации
проектных моделей системного уровня [4, 5], при изучении любой
модели и ее сравнении с конечной реализацией мы можем измерить точность
модели по нескольким независимым направлениям. Сюда входит
структурная точность: степень различия между моделью и фактической
реализацией структуры. Модель может быть точным поведенческим
представлением функциональности модуля и его внешнего интерфейса,

Глава 6. Язык SystemC в проектировании на системном уровне
но при этом ее внутренняя структура может сильно отличаться от
структуры конечной реализации IP блока или модуля. Например, модуль
может содержать аппаратные и программные подсистемы, но при этом
абстрактная функциональная модель может не отражать любую из этих
внутренних структур. Аппаратно реализованный IP блок будет иметь
детальный интерфейс выводов (pins) на основе сигналов, но структура модели
интерфейса может использовать абстрактный интерфейс с более
сложными типами данных с целью более эффективного выполнения модели.
Временная точность системных моделей может очень сильно
меняться. Вначале временная точность может быть просто на уровне
упорядочивания событий - так что хотя время может выводиться в
наносекундах или тактах, важным является только последовательность
выполнения моделей. Время может также рассматриваться как ограничение
на уровне реализации, и выполнение системной модели с
ограничением на время может проводиться в основном для анализа корректности,
выполнения и общей производительности системы. На системном
уровне наиболее точное время обычно с точностью до такта - более
точные временные характеристики важны в основном только на уровне
реализации.
Функциональная точность отражает, насколько точно системная
модель воспроизводит полную функциональность конечной реализации.
С целью упрощения модели, уменьшения времени на ее создание или
повышения скорости выполнения, проектные команды могут опустить
моделирование сложных или редко используемых функциональных
аспектов. Например, могут быть пропущены различные диагностические
или тестовые режимы, если они редко используются; в случае DSP
приложения функциональная модель может использовать арифметику и
типы данных с плавающей запятой, даже если конечная реализация
использует арифметику с фиксированной запятой. В этом случае, хотя
модель и не совсем точно отображает конечную реализацию,
моделирование с плавающей запятой будет гораздо быстрее.
Модели также могут отличаться по точности или полноте
организации данных. Это означает степень соответствия между расположением
данных в модели и в конечной реализации. В модели могут
использоваться гораздо более быстрые схемы расположения данных (если такие
есть) нежели чем в конечной реализации. Другое направление точности
связано с моделированием коммуникационных интерфейсов и
протоколов. В отличие от предельно точных сигнальных интерфейсов и
протоколов на аппаратном уровне моделирование абстрактных коммуникаций
на основе транзакций и абстрактных структур данных позволяет создать
гораздо более быструю модель без потери требуемой точности (конечно
в зависимости от того, как эта модель будет использоваться).

Аспекты SystemC 89
Модели Вычислений
Модель вычислений (model of computation - МоС) является
фундаментальным понятием в проектировании на системном уровне. Интересно
отметить, что это понятие редко обсуждалось на уровне аппаратного
проектирования и поэтому может оказаться интересным для многих
читателей. Модель вычислений неформально можно представить как
конкретный стиль моделирования, лучше всего соответствующий данному
проекту или прикладной области и при этом обладающий свойствами,
полезными в симуляции, синтезе и/или анализе. Например, системную
модель многих приложений по обработке сигналов и изображений
можно создать с помощью модели потока данных - точнее одного из ее
вариантов SDF (synchronous data flow - синхронный поток данных). Если
системная модель соответствует SDF принципам, то можно создать
эффективные симуляционные модели и планы реализации. Другие МоС
могут поддерживать некоторые методы формального анализа.
Более формально модель вычислений можно задать тремя
определениями:
• Базовая временная модель (без времени, либо на основе
действительных или целых чисел, с заданной точностью) и семантика
упорядочивания событий на основе временной модели (строгое
упорядочивание, нон-детерминизм, частичное упорядочивание,
случайное упорядоыивание, и .т.д.).
• Взаимодействие процессов между собой. Семантика событий,
объектов, токенов и передачи данных от одного процесса к другому.
• Условия активации или »запуска» процесса (иногда называемые
«правилами запуска процесса»). В модели потока данных,
например, процесс запускается при условии наличия определенного
количества токенов на входах.
Многие языки проектирования, такие как традиционные HDL
языки, используют одну модель вычислений (отдельное событие,
упорядоченное глобально на общей «временной шкале», наряду с семантикой
«временных интервалов» для сходимости симуляции системы). Хотя
SystemC также использует одну модель вычислений, заложенную в язык
и его симуляционное ядро, эта модель является более общей и
позволяет накладывать на нее различные частные модели вычислений. Она
поддерживает настраиваемые события и возможность синхронизации,
возможность создания проектировщиками специализированных каналов,
портов, интерфейсов и модулей, также в нее входит очень общая
временная модель. Все это позволяет создание специализированных
моделей вычислений. В случае системных моделей, полностью попадающих
в один специализированный класс МоС, можно также оптимизировать

Глава 6. Язык SystemC в проектировании на системном уровне
симуляционное ядро SystemC для достижения более эффективной
симуляции данного класса МоС — например, в случае статически
спланированного потока данных можно создать статически спланированную си-
муляционную модель, которая будет выполняться значительно быстрее.
Язык SystemC поддерживает многие возможные модели вычислений
и его открытость позволяет больше экспериментировать. Было успешно
проведено много экспериментов, например сети процессов и потоков
данных (сети процессов Кана (Kahn)), аппаратное моделирование на
уровне RTL, сетевое моделирование, связывание симуляционного ядра
SystemC с непрерывным временным моделированием и
симулированием (для AMS проектов), и сетевые симуляторы.
Функциональное Моделирование
Функциональные модели системы также известны как исполняемые
спецификации. В общем это проектные спецификации и требования,
транслированные в SystemC модель или иерархию моделей.
Предполагается, что эти функциональные модели совершенно не связаны с
возможной реализацией. Однако, обычно в функциональные модели, в их
разбиение на части и структуру уже заложены некоторые представления
проектировщика о том, как модель может быть реализована хотя бы на
одной платформе. Например, хотя в теории модель кодирования или
декодирования данных может быть одним процессом, независимым от
любого разделения проектной спецификации на аппаратную и
программную компоненты, проектировщик, заранее представляющий себе, как
алгоритм может быть реализован, возможно на основе предыдущего
опыта с похожими алгоритмами в других системах, может создать
модель, состоящую из двух или более последовательных процессов,
некоторые из которых явно предназначены для аппаратной реализации, а
некоторые для выполнения на RISC или DSP процессоре. Поэтому
довольно трудно настаивать на исполняемых спецификациях, которые
полностью независимы от реализации; иногда опыт проектирования,
отраженный в структуре функциональной модели, является слишком
ценным, чтобы им пренебречь.
Функциональные модели могут быть временными (timed) или
невременными (untimed). Так как мы имеем дело с функциональной
спецификацией, то в процессе нисходящего проектирования (top-down) имеет
смысл начать с не-временной функциональной модели и затем добавить
информацию о задержках в процессе детализации. Однако, так как
функциональная модель не зависит от реализации, эта информация о
задержках не должна рассматриваться как часть детальной реализации - это
просто временные ограничения, которые должны быть переданы процессу

Аспекты SystemC 91
реализации — требования к минимальной производительности системы,
наложенные проектируемой системой и ее характеристиками.
Так как функциональные модели обычно абстрактны,
ориентированы на спецификацию и предназначены для быстрого выполнения,
интерфейсы являются абстрактными, двухточечными (point-to-point),
(прямая связь между модулями без промежуточных носителей), с
использованием абстрактных типов данных (для эффективности), и
простых механизмов, таких как FIFO с блокирующимися чтением и
записью, (либо с не-блокирующимися, если в спецификацию системы
заложена возможность потери данных). Это применимо и к временным
функциональным моделям, но информация о задержках в этом случае
может быть добавлена на основе спецификаций производительности
системы.
Для моделирования алгоритмов очень часто используется такой тип
функционального моделирования как поток данных (dataflow),
особенно в прикладных областях обработки сигналов и изображений.
Наиболее общей моделью вычислений является сеть процессов Кана (Kahn),
специальные случаи которой - статическая и динамическая модели
потоков данных. Такие алгоритмические функциональные модели
отображают с помощью акторов (actors) входные потоки токенов данных в
выходные потоки преобразованных данных. SystemC обеспечивает
эффективные способы реализации сетей процессов и моделей потоков данных
- используя потоки, FIFO каналы и методы блокировки чтения/записи.
К таким функциональным моделям легко можно добавить временные
задержки.
Для общего управления очень часто используются конечные
автоматы. Они могут взаимодействовать с моделями потоков данных; а
временные и не-временные модели также могут взаимодействовать с
помощью FIFO каналов.
Моделирование На Уровне Транзакций
Моделирование на уровне транзакций позволяет абстрагировать
взаимодействие между модулями, так что функции модулей определяются
точно, а взаимодействие между ними оптимизировано для ускорения
симуляции. Эта оптимизация достигается с помощью использования
абстрактных типов данных для описания передаваемой между
модулями информации вместо индивидуальных битовых сигналов,
определяемых индивидуальными событиями; а также с помощью интерфейсных
методов, вместо сигнальных событий. В общем, симуляция на уровне
сигналов и выводов заменяется эффективными методами обращений,
которые передают целые структуры данных. Это позволяет увеличить

92 Глава 6. Язык SystemC в проектировании на системном уровне
скорость симуляции в 100-1000 раз по сравнению с симуляцией на RTL.
Вдобавок к этому при моделировании на уровне транзакций некоторые
транзакции вначале могут вообще игнорироваться. Из полного набора
транзакций шины некоторые транзакции ошибок или аварийной
остановки могут не моделироваться вообще, или моделироваться только на
следующем этапе, с целью концентрации начальных усилий на
ключевых транзакциях передачи данных (передача слов и пакетные
чтение/запись) поддерживаемых моделью шины. Стадия арбитража (выяснение
приоритетов доступа к шине) может игнорироваться в начальном
моделировании, и будет добавлена на следующем этапе, либо в процессе
детализации на основе подстановки (из библиотеки).
У специалистов, связанных с OSCI (Open SystemC Initiative),
существует большой интерес в определении стандартного набора типов
транзакций, с целью их использования в системном моделировании и в
обеспечении взаимодействия разных IP моделей, включая транзакции, как с
точки зрения SW программиста ("программная модель»), так и с точки
зрения аппаратного проектировщика ("аппаратная модель с точностью
до такта»). Методы детализации на основе библиотечной подстановки
могут поддерживать использование таких транзакционных моделей на
указанных уровнях, на основе стандартного набора API интерфейсов.
Моделирование на уровне транзакций особенно важно для платфор-
моориентированных SoC моделей, для обеспечения корректного
моделирования и изучения различных эффектов в коммуникациях на
высоком уровне, таких как загрузка шины, конфликты на шине, а также
влияния шины на общую производительность системы. При этом эти плат-
формоориентированные модели могут быть детализированы с
точностью до такта, что необходимо для аппаратного проектирования, и могут
послужить в качестве эталонных моделей или тестовых платформ в
процессе аппаратного проектирования.
Уровень RTL и Связь с Реализацией
Язык SystemC позволяет детализировать существующую модель или
создать новые модели и точно определить степень синтезабельности RTL
моделей, в VHDL или Verilog.
В RTL модели вычислений все коммуникации между процессами
должны проходить на уровне сигналов; процессы могут представлять
последовательную или комбинаторную логику - в первом случае они
чувствительны к фронтам синхроимпульсов, а во втором - ко входному
набору сигналов. Порты RTL модулей должны соответствовать разъемам и
соединениям конечной реализации, и, конечно же, они должны быть
определены с точностью до такта.

Верификационные Расширения
В маршруте проектирования нет необходимости в детализации
SystemC модели до RTL уровня, разве что по соображениям удобства.
Возможность взаимодействия с программами HW симуляции позволяет
объединить вместе модели на SystemC и HDL; поведенческий синтез
позволяет избежать SystemC моделей на RTL уровне; также возможна
трансляция подмножества SystemC в конструкции RTL.
Верификационные Расширения
Библиотека верификации SystemC (SCV) [7,8] предлагает SystemC
сообществу много новых возможностей тестирования, она была создана как
библиотека расширений на основе SystemC и базовых библиотек
SystemC.
SCV позволяет создавать верификационные IP-блоки, которые
можно рассматривать и как IP для проектирования SoC, и как IP для
повторного использования в других проектах. Учитывая, насколько много
усилий (в процессе проектирования) уходит на верификацию (по
неформальным оценкам - 50-70%), возможность создания
верифицированного IP становится очень важной.
В основные верификационные возможности SCV библиотеки входит:
• Самодиагностика (introspection) данных, и возможность
манипулировать элементами данных произвольных типов. На базе этого SCV
может манипулировать заданными пользователем типами и
ссылаться на них - например, структуры, отображающие пакеты и
фреймы. Это обеспечивает возможность PLI (Programming Language
Interface - Verilog) доступа к таким объектам и позволяет определить
все атрибуты или характеристики этих типов.
• Запись транзакций, что делает верификацию на основе транзакций
(TBV) дополняющей частью моделирования систем на уровне
транзакций. При этом TBV, с помощью маркировки набора событий как
одной «транзакции», позволяет записать симуляцию на уровне
отдельных событий и абстрагировать результат на уровень общих
транзакций тестовой платформы, а также позволяет маркировать и
записывать транзакции на этом уровне абстракции. SCV позволяет
группировать связанные транзакции в потоки, что дает возможность
проведения поиска по результатам симуляции, создания
верификационных транзакций высокого уровня, а также наблюдающих и
контролирующих программ.
• Рандомизация - простая, взвешенная и на основе заданных
ограничений. Рандомизация является мощным методом в современных
процессах функциональной верификации. SCV поддерживает несколько
типов, включая простую рандомизацию (в которой значения,

Глава 6. Язык SystemC в проектировании на системном уровне
например, адресов данных, генерируются на основе простой
интервальной функции от набора корректных адресов). Простая
рандомизация позволяет создавать распределение значений на основе более
сложных наборов корректных интервалов, а также позволяет
задавать пустые интервалы.
• Взвешенная рандомизация позволяет связывать вероятностные
распределения со значениями или с подмножеством значений в
заданном интервале, так что сложные распределения (например
биномиальное, Пуассона, нормальное) могут быть ассоциированы с
тестовыми платформами. Это также хороший способ отразить в тестовой
платформе реальные статистические распределения.
• Заданные ограничения позволяют достичь большей абстракции при
генерации на тестовых платформах сложных случайных сценариев.
Они позволяют вводить сложные условия и комбинации при
задании наборов допустимых значений переменных тестирования.
Например, в коммуникационных приложениях можно сгенерировать
распределение пакетов в зависимости от интервалов адресов,
возникновения ошибок, и некоторых других ограничений. SCV
поддерживает механизм задания ограничений и нахождения
удовлетворяющих всем ограничениям решений, при этом: решения
распределяются равномерно по всем допустимым значениям;
производительность механизма приемлема при увеличении числа
ограничений и тестовых переменных; механизм не зависит от порядка и
поддерживает отладку не-решаемых систем (с избыточным набором
ограничений).
• SCV также: предоставляет простую базу данных для хранения и
изучения результатов верификации; предоставляет простой механизм
связывания SystemC с HDL симулятором; совместимый механизм
обработки и отладки ошибок.
Заключение - Будущее Развитие Языка
SystemC и SLD (System-Level-Design) Требований
В приведенном выше кратком обзоре было рассмотрено использование
SystemC для различных задач моделирования, а также затронута
верификационная библиотека SCV. Организация Open SystemC Initiative (OSCI)
[9] предложила хорошо сформулированный план по стандартизации
SystemC 2.01 в ШЕЕ, и собирается продолжить работу над развитием
языка. В данный момент группа развития языка из OSCI работает над
следующими вопросами:
• Работа над справочником по SystemC 2.01, который планируется
передать IEEE для стандартизации.

Верификационные Расширения
• Задана и реализована SystemC версия 2.1, содержащая исправления
ошибок и новые особенности по поддержке моделирования SW
задач — например динамическое создание и удаление потоков.
• Работа над определением того, как должна выглядеть поддержка
модели потоков данных и соответствующих языковых расширений.
• Группа по моделированию на уровне транзакций активно исследует
корректные абстракции TLM моделей IP блоков, а также
стандартные API интерфейсы, позволяющие осуществлять взаимодействие
моделей.
• Рабочая группа в области AMS (analogue/mixed-signal) провела
большую работу по созданию SystemC расширений для достижения
способности взаимодействия в области AMS. Их работа была описана в
нескольких отчетах [6,10].
• Значительная работа проведена над SystemC версии 3.0, который
будет поддерживать программное моделирование и возможность
взаимодействия HW и SW моделей SystemC на основе следующих
особенностей: моделирование RTOS планировщиков, создание задач и
управление ими, а также обмен сообщениями на уровне ОС.
• SVC библиотека скорее всего будет передана ШЕЕ для стандартизации.
Несмотря на всю эту активную работу, остается еще целый ряд
интересных не затронутых областей, в которых можно было бы использовать
SystemC в качестве моделирующей платформы:
• Переход от описания проекта на высоком уровне к конечной
реализации. Например, поведенческий синтез первого поколения на
основе поведенческих форматов обычно неудачен, это происходит по
многим причинам, в основном из-за плохого качества результатов.
SystemC и абстракции на высоком уровне значительно облегчают
моделирование, но оставляют конечную реализацию в основном на
ручные методы детализации. Можно еще многое улучшить в
решении задачи генерации на основе модели высококачественного и
высокопроизводительного кода («системный синтез») с целью
получения аппаратной или программной реализации на заданной
платформе (стандартные ячейки, структурированная ASIC или FPGA в
качестве аппаратной части; в качестве программной - платформо-
ориентированной оптимизированный С-код). Самой
многообещающей по этой теме на данный момент является недавно
появившаяся прикладная область синтеза со-процессоров.
• До сих пор не решена полностью проблема »модели вычислений» в
проектировании на системном уровне. Каким образом лучше всего
смоделировать все составляющие элементы комбинированной HW-
SW системы; как создать системную модель с помощью композиции

Глава 6. Язык SystemC в проектировании на системном уровне
моделей подсистем; как лучше всего верифицировать конечную
систему — все эти вопросы до сих пор весьма актуальны. Построение
маршрутов проектирования, связывающих системные
спецификации и платформенные модели с аппаратной и программной
реализацией требует семантически корректных преобразований, которые
только выиграют от большей формализации.
Все эти вопросы дают растущему сообществу SystemC хорошую
возможность для дальнейшего исследования и развития языка.
Литература
1. Thorsten Grotker, Stan Liao, Grant Martin and Stuart Swan, System Design with SystemC,
Kluwer Academic Publishers, 2002.
2. Bhasker, A SystemC Primer, Star Galaxy Publishing, 2002.
3. Luciano Lavagno, Grant Martin and Bran Selic (editors), UML for Real: Design of
Embedded Real-Time Systems, Kluwer Academic Publishers, 2003.
4. Mark Genoe, Chris Lennard, Joachim Kunkel, Brian Bailey, Gjalt de Jong, Grant
Martin, Kamal Hashmi, Shay Ben-Chorin and Anssi Haverinen, «How standards will
enable hardware/software co-design», Proceedings of CODES 1999, pp. 211-212.
5. Virtual Socket Interface Alliance, VSIA System Lewi Design Model Taxonomy Document
Version 2, July 20001, available on the VSIA web site at URL:
http://www.vsi.org/resources/specs/sld220.pdf
6. Wolfgang Miiller, Wolfgang Rosenstiel and Jiirgen Ruf (editors), System С - Methodologies
and Applications, Kluwer Academic Publishers, 2003.
7. С Norris Ip and Stuart Swan, «A Tutorial Introduction on the new System С Verification
Standard», 29 January 2003, white paper, on the web at URL:
http://www.testbuilder.net/whitepapers/sc_tut.pdf
8. John Rose and Stuart Swan, «SCV Randomisation», 13 August 2003, white paper, on the
web at URL: http://www.testbuilder.net/reports/scv_randomization.pdf
9. Open SystemC International (OSCI) website: URL http://www.systemc.org/
10. European SystemC User Group website: URL http://www-ti.informatik.uni-
tuebingen.de/~systemc/

ГЛАВА 7
SoC-ПРОЕКТИРОВАНИЕ
И ВЕРИФИКАЦИЯ
С SystemC
Введение
В этой главе мы обсудим SoC проектирование и верификацию на
основе SystemC, на примере конкретного проекта. Основой проектирования
и верификации с SystemC в нашем случае будет создание
функционального виртуального прототипа проекта на уровне транзакций [1].
Интегрированная методология верификации компании Cadence определяет
функциональный виртуальный прототип (FVP) как «идеальное
функциональное представление всего устройства (DUV — Device Under
Verification) и соответствующей тестовой платформы». Создание
полного FVP и является задачей процесса SoC проектирования и
верификации на основе SystemC.
Рис. 7.1. Пример Архитектуры Проекта на Основе ARM.

Глава 7. SoC Проектирование и Верификация с SystemC
Проект, используемый нами в качестве примера, включает в себя
встроенный процессор ARM920, высокопроизводительную шину АМВА, а также
периферийную шину АМВА. Он описан более детально в следующем разделе.
На рисунке 7.1 отображена базовая архитектура нашего проекта. Он
состоит из процессорного ядра (core) ARM 920T, памяти и
жидкокристаллического монитора (LCD), соединенных с помощью
многоуровневой высокопроизводительной шины АМВА (АНВ), и связанных через
мост с периферийной шиной АМВА (АРВ). К АРВ подсоединены
таймеры, универсальные периферийные устройства (GPIO), часы реального
времени и контроллер прерываний.
В качестве программного приложения, выполняемого на
встроенном ARM процессоре, используется очень простая С программа,
рисующая квадраты на LCD мониторе, а также выводящая на экран слово
«Hello». Ее выполнение будет проиллюстрировано в этой главе на
модели функционального виртуального прототипа.
Построение Модели Функционального
Виртуального Прототипа
Процесс определения проекта на высоком уровне - задание
архитектуры, основных компонентов, архитектуры коммуникаций на чипе —
также определяет природу модели функционального виртуального
прототипа. В этом случае проектирование на высоком уровне и системная
верификация на основе SystemC дополняют друг друга и могут выполняться
параллельно. То, что уже задано, должно быть верифицировано; то, что
верифицировано, нужно исследовать и проверить на соответствие
архитектуре, чтобы убедиться в соответствии требованиям к продукту по
функциональности и производительности. Мы сразу видим
двойственность этого процесса - исследование пространства проектирования и
функциональная верификация просто являются двумя сторонами
одного и того же процесса проектирования и верификации.
Конечно, в процессе проектирования верификация и
проектирование начинают отличаться уровнем детализации. Проектирование
является итерационным процессом, детализирующим компоненты и
архитектуру коммуникаций до уровня реализуемости - например, до синте-
зопригодного RTL кода. Модель функциональной верификации — FVP
(functional verification model) - необязательно детализировать до такого
уровня. Например, в случае ядра (core) встроенного микропроцессора,
которое может быть заранее реализовано на физическом или синтезо-
пригодном RTL уровне, может потребоваться только конфигурирование
используемой высокоуровневой функциональной модели ядра в рамках
FVP. Такой моделью может быть модель, симулирующая набор
инструкций (instruction set simulation model - ISS) процессора.

Построение Модели Функционального Виртуального Прототипа 99
На рисунке 7.2. приведен Функциональный Виртуальный Прототип
нашего проекта-примера.
ARM Code
Image
arm code.elf)
armsd debugger:
ARM920TCCMISS
SystemCWrapper
SystemC Models
LCD/Con
troller
Multi-Layer AHB
Memory
AHB/APB
Рис. 7.2. Функциональный Виртуальный Прототип примера на основе ARM.
Функциональный Виртуальный Прототип построен на основе
комбинации SystemC моделей основных компонентов проекта -
многоуровневой АНВ шины, компонентов памяти, моста шины и LCD
контроллера; при этом функциональность процессора симулируется
ISS моделью ARM 920T (ARM 920T Instruction Set Simulator Model
(ISS)). Такая ISS модель обладает значительными преимуществами по
сравнению, например, с более низкоуровневой моделью процессора
(RTL-уровня), даже если она доступна в форме SystemC:
- она напрямую, без модификаций, выполняет скомпилированные
или собранные потоки ARM кода;
- она более быстрая. ISS модели процессоров обычно от 100 до
10000 раз быстрее моделей RTL уровня, так как от них требуется
только функциональная корректность, а не точное отображение
работы аппаратной части;
- она напрямую соединена с соответствующими отладочными
программами, которые используются позже при разработке
программ для данного процессора;
- она может взаимодействовать с остальными частями системы,
написанными на SystemC.
ISS можно рассматривать как модель процессора «на уровне
транзакций», где основной транзакцией является корректное выполнение
отдельной инструкции. Существует несколько типов ISS моделей,

100 Глава 7. SoC Проектирование и Верификация с SystemC
которые могут отличаться по временной точности и скорости
симуляции. В случае нашего ARM-примера используется Cycle-Callable модель,
с точностью до такта; но ф. ARM работает вместе с другими компаниями
из Open SystemC консорциума над заданием стандартных «моделей на
уровне транзакций» (Transaction-Level Models — TLM моделей) разных
уровней абстракции, таких как Programmer's View (на уровне
программиста) и Programmer's View with Timing (на уровне программиста, с
временными задержками). [2]
Интерфейсный код, связывающий в нашем примере ISS со всей
системой, создан на основе ARM API.
SW код, выполняемый на FVP примере, также может выполняться и
на конечном реальном устройстве, или на плате (board support package -
BSP), представляющей реальное устройство. Таким образом FVP
позволяет программистам создавать и отлаживать программы до появления
реального устройства. Это особенно важно при отладке аппаратно-зави-
симого SW (Hardware-dependent SW-HdS). После отладки HdS кода
можно начать настройку временных задержек на основе
детализированных моделей процессора (с точностью до такта) и системы в целом.
Модели Использования FVP
Ниже приведены несколько моделей использования функциональных
виртуальных проектных прототипов, созданных на основе SystemC:
Создание Встроенных Программ
С помощью FVP прототипа и модели набора инструкций CPU (ISS),
соединенной с SystemC моделями, программисты могут отлаживать
программы со скоростью в десятки тысяч тактов в секунду. Они также могут
провести дополнительно анализ тестового покрытия. Ассерты
(Assertions) вставленные в аппаратную часть (HW), могут использоваться
программистами, если они проводят смешанные SystemC/Verilog или
VHDL симуляции с помощью FVP модели и соответствующих средств
разработки (таких как платформа верификации Incisive компании
Cadence, поддерживающая симуляцию на SystemC, HDL, или
смешанную - SystemC-HDL).
Функциональная Верификация
FVP прототипы на уровне транзакций могут использоваться для
представления системы на высоком уровне, с целью тестирования различных
подсистем в контексте всего проекта перед тем, как закончить создание
проекта на уровне RTL. Например, RTL версию контроллера прерываний

Иерархия FVP 101
можно протестировать до того, как будет готов RTL код всего проекта.
Так как FVP на уровне транзакций выполняется быстрее, чем
эквивалентный RTL код, можно выполнить больше тестов и улучшить тестовое
покрытие.
Создание Аппаратной Части
FVP прототип является исполняемой спецификацией. Это объединяет
проектную и системную команды.
Настройка Системной Архитектуры
FVP прототип может использоваться системной командой для
выполнения анализа проекта на системном уровне. К такому анализу
относится изучение загрузки шины, пропускной способности, размера
кэша, иерархии памяти, числа процессоров, анализ алгоритмов
арбитража и .т.д.
Создание Кода SW Приложения
Рисунок 7.3 демонстрирует разработку кода встраиваемого прикладного
ПО на процессоре ARM 920T. Конечный результат процесса создания
SW - скомпилированные SW приложения - могут выполняться на FVP,
так как в прототип входит модель, симулирующая набор инструкций
(ARM ISS) и взаимодействующая с остальными частями системы. В
начале симуляции прикладное ПО загружается в память FVP, созданную
на основе модели памяти на SystemC. Все запросы ARM на инструкции
в ISS обслуживаются моделью памяти через SystemC интерфейс.
Ш«ч**ч
|£Нв |d,! V.6» GO
1 <1 Е> Д
| -ш,,|т Kmte9rit
arm...cod е. с
•ДПИмГя1"
ОрЕп wtti qftditl
*■-- 1
J:.\ ш
*
Boo*™
Ф
■:..:^.. 1
M E^teences H,p tw«
a Q »
mrtajtnudtmoftjd ■:■■ .■-,.-<■„, и,..,. .«r^r _№.
Q
*™ tfl
] ■ ■ Th.( tMn.ndc.il»
То Ш It. ch№« ал option Ш ih. tidal)v
|йя
г '
hi tiil.ril : ,1 ., .1 |,| . ,!■:. In ', ,.l t и..-,, и , i 1.. 1 ,.,i:i | j
--)-:,ii ы я li. Tiuv .,:.;- ..,„.-„ i,- mn uni-.ed
i iU'i'l-:]i,ir .'mi.' i*M I mi'i.ni
ill. пиар- l-LiWLh
Isi^iiis^
г
1 I:
I
Criminal»-:
Project; SjsubC ir-b
Ше is i**ier «S cortrol
Ks'ile: s-n md£.c,v $
JWvisi»: i.i.1.1 *
Jjuti! 2ХИ.'0в/Ов 17:55:57 *
^™"
Be^Ji"i"i'Ll!V*.MJ/*/'B 1Г:»:57 metB-s
t-nUal iMI Plat dti 1С
te«isioil,ll МЯ/Ю/М 16:15:37 cbates
Header file ufdatjd arel ns+.ed alcha italus
iJ
Рис. 7.З. Код и компиляция приложения, основанного на ARM.

102 Глава 7. SoC Проектирование и Верификация с SystemC
Иерархия FVP
На рисунке 7.4 показано, что FVP прототип можно просматривать с
помощью собственного окружения HDL-верификатора; данная
методология поддерживает все типы HDL описаний структуры модели.
Продвинутые средства верификации, такие как Cadence Incisive, поддерживают
полный просмотр всех частей проекта, написанных на SystemC, VHDL и
Verilog, в таких случаях как: смешанное проектирование (на нескольких
языках) с SystemC и HDLs - которое становится более
распространенным, так как позволяет, используя SystemC объединять проектирование
«сверху-вниз» («top-down»), с проектированием «снизу-вверх» (с
повторным использованием IP или старых HDL блоков) и с
проектированием «с середины» («middle-out»), в котором могут использоваться либо
SystemC либо HDLs на уровне RTL.
ш ъ ■ ■■ Ш ь
t «I tuil
%) WEMI_HHmir>O'"H0it
lajiietlntljt
fcjnettiijti.5
lijnnji»o.7
t> hi. I'.".: ■ ■
1(1(3 ft" |i * !
f I/ 5ccp» "iHipTFU'"
. BJ HIes /«яl'uiiiiw /*ч.чи"'рМ(51 - i:'
• Agtfic hsnJLs tt Mil ttciiet */
'* Jre w 1mc.1ti.ng iebu99»t oratandl i
"С? 4У Ж *^^ JQ SmYnion- Sour» .. tf Tw^rui [«■ Т„^Г
*li
Рис. 7.4. Просмотр
иерархии модели.
Исследование Проекта на системном Уровне
На рисунке 7.5 проиллюстрировано использование FVP прототипа вместе
с включенными в него IP моделями, а также средствами анализа и
отображения, для исследования проекта, с помощью быстрой TLM симуляции.
В левом окне отображается процесс чтения/записи памяти, а в правом
окне показано содержимое памяти. Исследования работы памяти, вместе с
анализом производительности системного приложения, могут
использоваться при выборе IP компонента для улучшения баланса системы, т.е. для
выбора наиболее подходящей памяти. Это также может использоваться
для проверки функциональной корректности системы и для исследования
производительности. Использование транзакционных моделей
интерфейсных компонентов и симуляция на SystemC обеспечивает более

Исследование Проекта на системном Уровне 103
Рис. 7.5. Симуляция
Памяти с помощью
моделирования на
уровне транзакций.
| fiip го™ pliWyCM wors Help
««.I
"""
Ы* opiiuiis fiii
и
Г
0
\*
о
■с
?п
to
гс
30
34
Г
40
44
40
Lo
54
ffll
5с
60
(4
[«И
0 1 1 I г I ! I S
юоо- :юоо- Г» in- .moo-
IOOO '1000- IlOOO1 1SOC-
low fiuuiJ- 'iuuu- :»
mm- ;innn- nw ,iiim-
IOOO .1000- 40W ■10W-
iooo1 ,i oqd- hVao1 moo-
1000- И0ОО- llOW .1000-
iwwj ft jtuW ;iuuu-
!m- lira- С (м- j 1
loco- liooo- чоо- -am
юоо ;тптг liooo liooo
кос- liooo- -i bob- jiooci"
iooo- 'iooo- iooo- :wnr
iooo- ;im im iioM
IOOO IOOO 1000 IlOOO
moo- № moo- ;iooo-
looo- liooo- liooo- ;iooo-
IOOO' 4000' 4000- jlOOO-
1000 ;IOOO 4000 IlOOO
torn- ,iwi юггг ;nnw
iooo- iow tmr .iooo1
IOOO- IOOO' J77t(00OI ;377<f077d
IJ77H IOOO" .1000" |1000-
%&m+B
r~
быстрое симулирование по сравнению с традиционными RTL подходами
и моделями интерфейсов на уровне сигнал/бит/вывод.
Конечно, функциональную корректность на системном уровне,
особенно в случае мультимедийных приложений, которые могут
демонстрировать видимые искажения, можно также проверять на основе
графических представлений выходных данных системы. На рисунке 7.6
продемонстрирован LCD монитор, отображающий результаты
симуляции транзакционной модели (TLM) на основе SystemC, точно так же,
как показывал бы реальный LCD монитор.
щ-
г
.—
ctop. LCD. Icd_m aster:;
1;.\ ;;
mHStn
1
f ffameb HI Ш]
-™-|
Н 1 ; ||
НН№!
|.,-;|:;Не
£l_ ... Щ®: ^
1
1
Id
В "V »
^:^--r'r;--x?Vrf;y
■ ..-.:.'.■'. ■■■'.'.. ■ '
:: m
File Options Info
lo
I4
|e
с
10
11,4
|l8
|lc
| 20
|24
| 28
| 2c
| 30
I34
1 38
0
jffTfffff
3d613d61
3d613d61
3d613d61
3d613d61
3d613d61
5d156d15
6d156d15
10001
3d613dB1
3d613d61
3d613d61
3d613d61
3d6i3d6i
6d156dl5
1
ГТШТТГ
3d613d61
3d613d61
3d613d61
3d613d61
3d613d61
6d156d15
3d616d15
fffflffff
3d613d61
3d613d61
3d613d61
3d613d61
3d613d61
6dl56dl5
2
10001
3d6i3d6i
3d6l3d61
3d6i3d6l
3d613d61
3
10001
3d613d61
u~- ..- I
3d6l3d6l
3d6i3d61
3d613d61
3d613d61 |3d613d61
6d156d15 |6d1 56d15
13d61
10001
3d613d61
3d613d61
3d613d61
3d613d61
3d613d61
6d156d15
10001
10001
3d613d61
3d6l3d61
3d6i3d6i
3d6i3d6i
3d6i3d6i
6d156dl5
N
lv
Рис. 7.6. LCD монитор, меняющийся в соответствии с симуляцией FVP.

104 Глава 7. SoC Проектирование и Верификация с SystemC
Создание и отладка современных мультимедиа алгоритмов, таких
как MPEG2, JPEG, JPEG2000, МРЗ, MPEG4 часто очень сильно зависит
от возможности быстрой симуляции и отображения результатов почти в
реальном времени, позволяющей визуально определить искажения,
вызванные алгоритмом, и скорректировать эти искажения. FVP прототип
обеспечивает достаточно быструю симуляцию, обеспечивающую
отображение выходных видео-данных с хорошей скоростью — или
достаточно быструю скорость
генерации кадров. Это значи-
, тельно быстрее, чем
симуляция на RTL уровне.
Модель на RTL уровне,
написанная на HDL,
использующаяся, например, для
моделирования
функциональной модели процессора,
сможет сгенерировать
только несколько пикселей за
то время, в течение
которого FVP прототип на
SystemiC, использующий
TLM (транзакционные
модели), сгенерирует
несколько кадров. Таким
образом FVP прототип
значительно усиливает
возможности системного
проектирования и позволяет
исследовать архитектурное
пространство, выбор
компонент, а также детали
алгоритма.
4'"'■."*"' '" J!
*&■ ■ ■ »■ *■ у ч- '■ *V. tв5>0 ,р 1< 3,^ JH * ■ ■■:■ '-■ •&ЯLjffl I S* 1
^^'^f^W*V./.'№|
■ -, .... 4V
,,.'■ v.-. ■'■■-.;■';■■ У" ' A
fe';l
ЩШЩ M\
ИЯ^иЧИп^^Ип^^Я И^щ J
MBit illHIHiillBBlMH
Edil ^iew Locale fcjavigate Mtindow*
go
'- tot«13 On»,
t totsH Ons,
t totals Ons,
e мк1 Ons, set »inl tOODri!
t »ir.I 0ns, set «in! IOOLji,
i м*Э On*, set ,.ii.. lDQOni
t n*x4 On», est »n4 lQQOni
t пвлЁ Опэ, set >inS 10i.ll.Ui;
Hull
a; л; w -й ?i t:
Slav в
Counil Mini Max1 Totan Percent Uflt
36 lOOOOOOOOfS 3G00OOGQ0fJ JZIDOOOOOOOrs 0.5533720W4
ЮЗЗ lOOOCGOOOfc 3O00enOOOft 7O77OO000OOOfc H*.6M£1S«3S
106 1 ODOOUOOOft JCOuOQOOUf» £45U00U00UQf( C.G12+S9376631
1 300000000ft 300000000ft 300000000fs 0.<M7«9S2501S7S
3537 loooooooafs jtmoacaoofs агэзооооооооч zo.esueeo»
i?as aooQuoooofs aoooaoooof! sassooooaooufs
5728 50000000(5 JSOOOQIMOfs вЗЭ^иОЙОаОййГ; 21.47№ы''.,;/
Рис. 7.7. Наблюдение за
симуляцией с помощью анализа
транзакций.

Анализ FVP с помощью транзакций 105
Анализ FVP с помощью транзакций
Конечно, существуют также другие проблемы проектирования и
верификации, которые могут быть проанализированы с помощью FVP
прототипа на более низком уровне, нежели системный. Например, детальный
анализ на уровне такта может использовать транзакционный интерфейс
для наблюдения за транзакциями между блоками, использованием шины
или другими вещами. Среда верификации Incisive компании Cadence
позволяет разработчикам наблюдать за симуляцией на уровне транзакций:
В этом примере транзакции показаны в верхнем левом окне, а
детали отдельной транзакции - в верхнем правом. В нижнем окне
анализируется весь набор собранных транзакций и результат отображается в
терминах использования шины master/slave.
На уровне транзакций анализ проблем и проектных возможностей
гораздо более эффективен, чем на уровне индивидуальных сигналов и
выводов. Конечно, если необходимо пользовательский интерфейс
позволяет проектировщикам получить низко-уровневые детали отдельных
транзакций (уровня сигналов, битов и выводов). Абстракция на уровне
транзакций улучшает не только эффективность системного
моделирования, но и эффективность отладки.
Заключение
В этой главе были проиллюстрированы основные идеи по
использованию SystemC и транзакционного моделирования при проектировании и
верификации сложных систем, на примере проекта SoC образца,
включающего в себя шину и ARM процессор. Эти идеи были использованы
для создания двойного отображения проекта с помощью понятия
Функционального Виртуального Прототипа (FVP), являющегося
фундаментальным в процессе проектирования сверху-вниз (top-down) и
верификации. Такой подход позволяет достичь существенных улучшений в
скорости симулирования, сохраняя при этом приемлемую точность, а
созданный FVP прототип может потом использоваться программистами,
системными проектировщиками, инженерами по верификации и
традиционными разработчиками HW. FVP прототип может быть связан с
конкретными HDL моделями старых блоков и использоваться для
детальной верификации HW блоков с помощью современных средств
симуляции. Это позволяет тестировать блоки отдельно и упрощает их
тестирование в рамках (контексте) всей системы.
Продвинутые средства симуляции и данная методология
проектирования и верификации поддерживают:
• Симуляцию одновременно на нескольких языках (mixed language
simulation) включая SystemC, Verilog, VHDL, и в будущем также
SystemVerilog

(К 106 Глава 7. SoC Проектирование и Верификация с SystemC
• Возможность конфигурирования среды анализа и отладки с
помощью создаваемых пользователем окон и средств
• Включение верификационной библиотеки SystemC (SystemC
Verification library) и ассертов.
• Среду для анализа симуляции с помощью отображения временной
диаграммы сигнала и возможностей по изучению транзакций
• Создание встроенных программ - предоставление программистам
среды выполнения программ, позволяющей доступ к
платформенным моделям (например модель набора инструкций (ISS)
процессора) и HW моделям, на основе SystemC.
Мы можем заключить, что:
• Функциональные виртуальные прототипы на основе транзакцион-
ных моделей могут использоваться для раннего создания
встроенного программного обеспечения и верификации.
• Это требует развития современных средств анализа на уровне
транзакций, которые обеспечивают возможность создания, отладки и
анализа транзакционных (и RTL) моделей.
• Очень важна поддержка проектов со смешанными уровнями
абстракциями и смешанными языками (mixed-abstraction level/mixed-
language).
• Ключевой является возможность поддержки различных моделей и
разных типов пользователей
• RTL разработчики могут эффективно использовать повторно TLM
(транзакционные) модели на системном уровне, основанные на
SystemC.
Литература
1. Cadence Design Systems white paper, The Unified Verification Methodology, доступна в
Интернете по URL:
http://www.cadence.com/whitepapers/4442_Unified_VerificationMethodology_WPl.pdf.
2. G. Martin, SystemC and the Future of Design Languages: Opportunities for Users and
Research, SBCCI 2003, Sao Paulo, Brazil, September 8-11, 2003, pp. 61-62.

ГЛАВА 8
SoC-ПРОЕКТИРОВАНИЕ
С УЧЕТОМ АЛГОРИТМОВ
И АППАРАТНЫЕ/
ПРОГРАММНЫЕ ПЛАТФОРМЫ
Введение
Для проектирования SoC можно использовать несколько разных
методов. В этой главе мы рассмотрим SoC проект алгоритмически
ориентированного приложения, а точнее SoC проект в прикладной области
беспроводной связи. В наши дни беспроводная связь становится все более
распространенной. Технологии 3G, широкополосная CDMA
(множественный доступ с разделением каналов) и GSM уже знакомы почти
каждому. Мы видим, как беспроводные (по стандарту 802.11, с несколькими
под-стандартами, a, b, g и т.д.) компьютерные сети (LAN) а также, в
меньшей степени, Bluetooth, меняют наш стиль работы в офисе и в пути,
а также наш отдых дома. В проектировании ASIC, SoC и встроенных
программ нужны новые системные архитектуры для создания новых
беспроводных систем связи. В этой главе мы рассмотрим проектирование
SoC для приложения беспроводной связи и продемонстрируем, как
средства алгоритмического проектирования и концепция платформенного
проектирования SoC помогают решить многие ключевые проблемы.
Сначала мы обсудим основные проблемы проектирования в этой
области, а потом покажем, почему SoC методологии являются
эффективным средством решения этих проблем.
Десять Основных Препятствий
на Пути Беспроводной 3G Технологии
В своей недавней статье [1] доктор Карл Панасик (Dr. Carl Panasik) из
подразделения Wireless Business Unit компании Texas Instruments описал
Десять основных, на его взгляд, препятствий на пути успешного
внедрения беспроводной 3G технологии:
7. Стабильные Стандарты
Региональные вариации в стандартах 3G стоят на пути создания
единого мирового стандарта. Однако, так как во время внедрения новой

108 Глава 8. SoC — Проектирование с учетом алгоритмов
технологии неизбежны изменения, требуется возможность
дополнительной настройки устройств во время их работы. Поэтому возможность
перепрограммирования необходима для основных базовых и мобильных
3G станций. Это применимо как к беспроводной 3G технологии, так и к
другим стандартам беспроводной связи.
2. Улучшение Производительности DSP
3G услуги связаны с увеличением потока данных, что повышает
требования к DSP или аппаратным блокам, реализующим функции
обработки сигналов, такие как декодирование и декомпрессию. Вдобавок к
этому, важно также ввести разделение по типам данных для
реализации ограничений по качеству услуг (QoS - Quality of Service), чтобы
отделять, например, голосовые данные реального времени от других
пакетов.
3. Усложнение Программного Обеспечения
Высокая толерантность к ошибкам, допустимая в случае передачи
голоса, уже недопустима для более критических приложений, таких как
определение местонахождения в экстренных случаях. Растущая
популярность беспроводной связи требует улучшения использования
имеющейся пропускной способности с помощью более эффективных методов
кодировки. Постепенное улучшение алгоритмов требует возможности
перепрограммирования мобильных устройств.
4. Снижение Потребляемой Мощности
Чтобы не допустить значительного увеличения требуемой мощности с
введением 3G технологии, нужно использовать современные процессы
производства, уменьшать рабочее напряжение и использовать
аппаратные средства (HW) ускорения вычислений для разгрузки программных
средств (SW) DSP. Вариации в типах передаваемых данных потребуют
адаптивной обработки, для уменьшения потребляемой мощности.
5. Усовершенствованная Система Управления Питанием
Для обеспечения ровной передачи 3G системе понадобится постоянно
выполнять фоновую обработку данных, что может привести к
значительному потреблению питания при отсутствии развитой системы
управления питанием. Будущая организация управления питанием
должны перейти от управления больших аппаратных блоков
рассредоточенному управлению индивидуальных блоков периферии на чипе и блоков
памяти.

Введение — Преимущества Использования SystemC 109
6. Увеличение Времени Жизни Батареи
Улучшения в области батарей далеко не соответствуют прогрессу
кремниевых технологий, скорости процессора или других характеристик
сложности устройства. Для увеличения времени жизни батареи, улучшения
функциональности и уменьшения размеров устройств необходимы постоянные
исследования в области материалов и технологий зарядки батарей.
7. Операционные Системы 3G технологий
Мобильные 2G телефоны предназначены в основном одному
применению - обеспечению передачи голосовых данных в реальном времени на
одном канале. В 3G системах будет много применений, как реального
времени, так и в нереальном масштабе времени. Для обеспечения высокой
надежности и многоуровнего режима работы необходимы улучшенные
операционные системы (OS). В качестве промежуточного варианта,
некоторые 2.5G подходы, такие как EDGE (Enhanced Datarate GSM) и GPRS
(Generalized Packet Radio Service) реализуют дополнительные услуги в
качестве надстроек на основе уже существующих беспроводных сетей.
8. Улучшенная Радио-Технология
Многие 3G устройства будут совместимы с 2G сетями в разных
частотных диапазонах; и 3G часто сможет взаимодействовать с
беспроводными локальными сетями (LAN) дома и в офисе. Поддержка разных частот
и стандартов без дублирования аналоговых компонентов приводит к
увеличению зависимости от DSP программ. Дополнительно к этому
необходимо снизить потребляемую мощность RF компонентов.
9. Понижение Стоимости
Стоимость мобильных устройств понижается благодаря росту
кремниевой интеграции, и этот процесс продолжится с появлением новых
производственных технологий. Требования рынка и технологические
оптимизации будут определять, дойдет ли интеграция до объединения всех
аналоговых, цифровых и RF компонентов в единое SoC устройство, или
все будет интегрировано в пределах чипсета.
10. Новые Приложения
Увеличение скорости потока данных в 3G может использоваться по
разному; например, беспроводной телефон может объединять набор
локальных систем в общую сеть. Необходимы новые приложения, которые
смогут убедить пользователей перейти на 3G. Одним из таких
приложений является сильно рекламируемая сейчас цифровая фотография.

I 10 Глава 8. SoC — Проектирование с учетом алгоритмов
Переопределение Проблем
Разделим эти проблемы на несколько основных классов, добавив также
несколько дополнительных проблем, а затем обсудим возникающие на
основе этих проблем требования к новым методологиям и средствам
проектирования.
Выбор Между Гибкостью и Интеграцией
В этот класс мы включаем проблемы «Стабильных Стандартов»,
«Улучшенная Радио-Технологии» и «Понижение Стоимости».
Беспроводная 3G технология является еще одним классическим при-
мерм глобального стандарта со многими вариациями на уровне регионов.
Перепрограммируемость, необходимая для более широкого
распространения продукта, может обеспечиваться многими путями: программы для
контроллеров и DSP; переконфигурируемая аппаратная часть, отдельная
или интегрированная на чипе; и многофункциональные блоки. Ключевую
роль играют компромиссы в проектировании между HW и SW,
позволяющие реализовать эффективную по цене программируемое^ в сочетании с
оптимальный реализацией. Они могут отличаться в зависимости от
природы проекта (например, базовые станции или мобильные устройства, для
которых сильно отличаются ограничения по цене и серийности
продуктов). Требуется тщательная оптимизация алгоритмов, чтобы они
удовлетворяли требуемым спецификациям без значительных дополнительных
усилий в инженерной области - например без использования процессора
с мощностью большей, чем это необходимо в соответствии с развитием
продукта.
Желание интегрировать проект с целью уменьшения цены приводит к
фундаментальному выбору: окажется ли наилучшим для радиоустройства
одна, две или более двух интегральных схем? Современные мобильные
приемники содержат RF часть, аналоговые и цифровые устройства; путь к
интегрированию может проходить разными путями [2], рассматриваются
также варианты с прямым преобразованием, но вопрос «один чип или два» до
сих пор открыт. Благодаря наличию оптимизированных процессов в
области RF и аналого-цифровых блоков желание снизить цену может привести к
созданию интегрированного набора из двух чипов в гибридном корпусе.
Программное Обеспечение
В этот класс мы включаем проблемы «Улучшения Производительности
DSP», «Усложнение Программного Обеспечения», «Операционные
Системы для 3G» и «Новые Применения». Рост в объеме и сложности
программного обеспечения является ключевым фактором 3G эволюции. Хотя 3G
HW также быстро растет, благодаря повышению требований по обработке,

Переопределение Проблем I
в общем, процесс создания HW уже более-менее отработан, и
современные производственные процессы обеспечивают создание всех
необходимых HW частей системы. Проблемой является сложность встроенного
программного обеспечения, использование более сложных операционных
систем и взаимодействие SW реального времени с SW других типов.
Очень важны два решения: выбор того, какие алгоритмы будут
реализованы программно — их требования к характеристикам и
быстродействию процессора, размеру памяти, и потребляемой мощности; а также
разделение функций между HW и SW реализациями, вместе с выбором
того, какой именно процессор в многопроцессорном окружении
используется для каждой SW задачи. Это разделение функций также
оказывает большее влияние на требования к коммуникационным ресурсам
между основными подсистемами.
Низкая Потребляемая Мощность
В этот класс мы включаем проблемы «Снижения Потребляемой
Мощности», «Усовершенствованной Системы Управления Питанием» и
«Увеличения Времени Жизни Батарей».
Если мы отложим вопрос увеличения времени жизни батарей,
которые с точки проектирования имеют более-менее фиксированный
ресурс, ограниченный размером и требованиями к корпусу, то снижение
потребляемой мощности сводится к корректному разделению функций
и корректным алгоритмам. Другие методы, такие как уменьшение
напряжения питания, в основном зависят от технологий изготовления
чипов, доступных в момент проектирования.
Разделение функций дает нам возможность максимально увеличить
долю вычислений в аппаратной части (HW), обычно более эффективной
по мощности, чем программная. Однако мало толку от реализации
сложных вычислений в HW, если они быстро могут измениться с
развитием стандарта или с изменением области распространения продукта. В
конце концов, необходимо провести оценку проекта и сопоставить риск
в связи с аппаратной реализацией алгоритма, с полученным благодаря
этому снижением потребляемой мощности. Независимо от того,
реализован ли алгоритм в HW или в SW, потребляемая мощность снижается с
помощью корректного выбора требуемой разрядности, использования
маломощных HW умножителей и достижения баланса между
требованиями QoS (Quality of Service) и потребляемой мощностью.
Затем, после разделения функций и тщательного выбора
алгоритмов в HW и SW частях, добавляются современные возможности по
управлению питанием. Базовые возможности по управлению питанием
в 2G, такие как отключение крупных системных блоков, должны быть
усовершенствованы до детального управления ресурсами.

I 12 Глава 8. SoC — Проектирование с учетом алгоритмов
Сложная и Долгая Верификация Алгоритмов
в Рабочей Полосе Частот (baseband)
К перечисленным выше трем классам проблем мы добавляем еще
четвертый: сложные и крайне долгие процессы верификации, необходимые
при проектировании 3G устройства. Как обсуждается в [3], верификация
3G алгоритмов по обработке сигналов в рабочей полосе частот (baseband)
с помощью Монте-Карло симуляций на физическом уровне требует
большого количества времени, по причинам более высокой частоты
дискретизации, более сложных алгоритмов, повышенных требований к
качеству (снижение допустимой частоты появления ошибок), и
необходимости одновременной симуляции поведенческой и RTL моделей.
Традиционные методы, использующие HDL симуляцию для HW на RTL
уровне, совершенно непригодны для решения этой проблемы. Особенно
сложны исследования по определению частоты ошибок по битам (Bit
Error Rate - BER).
Пример Мультимедийного
Мобильного Телефона
Для иллюстрации этих требований мы рассмотрим конкретный
проектный пример, типичный 3G продукт: мультимедийный мобильный
телефон (рисунок 8.1).
Основные проблемы проектирования подробных систем описанные
детально в [4] следующие:
• Первое, основная проблема проектирования любого сложного
системного продукта - будет ли он: работоспособным в нормальных
Рис. 8.1. Мультимедийный мобильный*телефон

Ключевые Направления Развития в Методах Проектирования I
условиях эксплуатации, недорогим и, следовательно,
конкурентоспособным, иметь привлекательные особенности, соответствовать
стандартам и обладать надежным маршрутом проектирования от
спецификации до передачи в производство?
• Подсистема цифровой фотографии должна обеспечивать
достаточное качество изображения, быть недорогой (и, таким образом,
реализованной на основе КМОП (CMOS), а не ПЗС (CCD), и решать
сложные проблемы авто-фокусировки и стабилизации изображения
в меняющемся окружении.
• Подсистема изображений должна быть 16-24 разрядной, цветной
системой с низкой потребляемой мощностью, приемлемой частотой
кадров (не менее 15 кадров в секунду) и разрешением (не менее
480x320 пикселей для Интернета).
• 3G - широкополосная система связи CDMA, как минимум в 5-6 раз
сложнее, чем GSM. Она должна поддерживать более высокую
пропускную способность при меньшей потребляемой мощности; более
широкую полосу пропускания с улучшенной линейной
характеристикой и меньшим шумом. Устройства также должны поддерживать
несколько стандартов.
• Добавление беспроводного видео к телефонным функциям
увеличивает сложность проектирования и добавляет необходимость
учета: влияния BER на качество видео, QoS вариаций между типами
передаваемых данных, повышенной эффективности источников
питания, повышенной интеграции и пониженной цены.
• Наконец, развитие рынка блоков Интеллектуальной Собственности
(IP), практика повторного использования проектов и SoC
проектирование многократно увеличили выбор технологий реализации,
между различными baseband платформами, многими
процессорными ядрами (контроллерами и DSP), программным IP (стеки
протоколов, алгоритмы обработки сигналов и изображений), а также
выбор: купить данный блок или сделать самим. Каждое решение в этом
сложном архитектурном пространстве связано со многими
компромиссами, которые должны быть тщательно проанализированы
разработчиками SoC.
Ключевые Направления Развития
в Методах Проектирования
А теперь подведем итог; ясно, что методы и средства проектирования
должны поддерживать:
• Проектирование неоднородных продуктов, охватывающих
несколько прикладных областей

I 14 Глава 8. SoC — Проектирование с учетом алгоритмов
• Набор так называемых «Моделей Вычислений», выраженных в
интегрированных алгоритмах управления и обработки потока данных
• Большой и увеличивающийся объем встроенного программного
обеспечения, разделенного на различные уровни QoS сервисов.
• Цене и уровню потребляемой мощности питания должно уделяться
не меньше, а может быть даже больше внимания, чем
производительности.
• Большой набор архитектур, компонентов и средств по разделению
функций структуры системы, включая высоко интегрированные SoC
платформы, на основе которых можно создавать новые проекты.
Обсудим несколько важных областей эволюции методологий
проектирования и их применение в области 3G.
Современное Проектирование Алгоритмов,
Анализ и Реализация
Мы начнем с необходимости в многофункциональной среде
проектирования с большим набором возможностей, предназначенной для
создания алгоритмов по обработке сигналов и изображений. Такая среда
должна поддерживать спецификацию и ввод описаний алгоритмов,
создание тестовых платформ, быструю симуляцию и анализ. Она также
должна помогать в проведении исследований по оптимизации и
варьировании различных эксплуатационных параметров. Спецификация и
ввод описаний этих сложных алгоритмов требуют поддержки как
методов блочных диаграмм, отображающих поток данных, так и
возможностей C/C++.
В дополнение к основным особенностям такой проектной среды
очень полезно иметь большое количество проектных библиотек,
учитывающих разные стандарты, включая стандарты коммуникаций,
стандарты обработки изображений и основные математические функции.
Алгоритмы сами по себе еще недостаточны для создания
беспроводной 3G системы. Их надо еще реализовать, либо аппаратно, либо
программно, или в смешанном виде, HW+SW. Форма, в которой алгоритм
был введен на высоком уровне, обычно в виде статически или
динамически спланированного потока данных с плавающей точкой, обычно не
совпадает с формой конечной реализации на основе HW блоков или
программ на базе DSP. Необходимо выполнить преобразование в формат
с фиксированной точкой, затем провести оптимизации по количеству
требуемой разрядности и точности. Наконец, для HW реализации с
фиксированной точкой должен быть сгенерирован эффективный HDL код
на уровне RTL; а в случае SW полезно иметь возможность верификации

Улучшенная Технология Верификации I
программного кода (часто написанного вручную на основе DSP с
фиксированной точкой) в пределах спецификации, введенной на высоком
уровне в среде проектирования алгоритмов.
Ключевой возможностью является «полиморфизм»,
поддерживающий эффективное преобразование алгоритмов от сложных типов
данных через переменные с плавающей точкой к переменным с
фиксированной точкой, а затем к аппаратным битовым сигналам.
Улучшенная Технология Верификации
Быстрая и эффективная верификация 3G алгоритмов и их реализаций
является очень важным этапом проектирования. Также важно, чтобы
верификация могла проводиться на разных уровнях абстракции, чтобы
как можно раньше (на более высоком уровне абстракции) найти ответы
на многие важные вопросы (например, является ли корректным данный
алгоритм обработки в рабочей полосе частот) с помощью процессов
симуляции и верификации. В этом случае статически спланированная
симуляция потоков данных с плавающей точкой будет выполняться как
минимум на порядок быстрее, чем программная симуляция на более
низком уровне абстракции.
Во-первых, среда проектирования алгоритмов должна позволить
проектировщикам создавать специализированные под данное
приложение тестовые платформы, которые могут быть повторно использованы
по мере детализации проекта от плавающей точки к фиксированной, от
SW к HW, с возможностью перехода на аппаратные ускорители
симуляций или HW эмуляции. Это особенно полезно в случае основанных на
потоках данных алгоритмах по обработке сигналов и изображений,
которые отображаются более-менее без изменений на уровень реализации.
В этом случае одни и те же модели работы системы (например,
симуляция получения аудио и видео-пакетов, модифицированных шумовыми
характеристиками беспроводного канала связи) могут применяться с
небольшими поправками на всех уровнях абстракции. Аналогично,
выходные данные алгоритмических преобразований на наивысшем уровне
можно сравнивать с выходными данными на уровне фиксированной
точки и на уровне HW или SW реализаций. Такое повторное
использование тестовых платформ является фундаментальным преимуществом
проектной методологии.
Во-вторых, использование абстракций потоков данных как на
уровне плавающей точки, так и на уровне фиксированной, позволяет
создание высоко-оптимизированных технологий симуляции, особенно в
случае статически спланированного потока данных. Эти технологии
предлагают скорость симуляции на 1-2 порядка быстрее чем в случае HDL

I 16 Глава 8. SoC — Проектирование с учетом алгоритмов
симуляторов на уровне RTL. Когда нужно проверить реализацию
алгоритма уровня RTL на тестовой платформе системного уровня, есть
возможность связать соответствующие технологии симуляции с помощью
методов локальной компиляции в один много-поточный процесс. Это
гораздо более эффективно, чем обычная симуляция с многими
процессами, на основе «backplanes», или другие аналогичные методы.
Недавняя работа в области развития моделей [5] привела к
возможности создания связей на основе абстракций между средами RF
симуляции и средами проектирования алгоритмов. В этом подходе
абстрактная модель RF эффектов, ассоциированная с конкретной RF
реализацией, используется в модели радио-канала - реальная модель
шума вместо идеализированной. Затем она связывается с алгоритмом
обработки в рабочей полосе частот, так что эффективность обработки
сигнала можно оценить и оптимизировать в реальных условиях, а не в
идеализированных, избегая больших ошибок в расчете требуемых
аппаратных ресурсов.
И наконец, недавно появились технологии аппаратного ускорения
симуляций и HW эмуляции, позволяющие ускорить долгие
исследования BER, необходимые в области беспроводных 3G технологий,
особенно для мультимедийных приложений. Ключевым условием
эффективного использования ускорения и эмуляции является ускорение всех
ступеней цепочки симуляции: тестовая платформа, генерация и передача
тестовых импульсов, тестирование HW проекта, а также сбор и
накопление/суммирование откликов или выходных данных. Это важная область
активного развития технологии проектирования.
Платформенное Проектирование
Последние несколько лет наблюдается подъем методов
«платформенного» проектирования в случае сложных SoC устройств и интегрированных
чипсетов [6]. Сущностью платформенного подхода является создание
ориентированных на приложение наборов HW и SW компонентов,
интегрированных в сложную SoC архитектуру, вместе с дополнительными
библиотеками компонентов, позволяющими создание дочерних SoC
проектов на основе стандартной платформы. SoC архитектура
фокусируется на базовых архитектурах коммуникаций (шины на чипе, протоколы
шины, передача сообщений на уровне OS и драйвера устройств),
обеспечивающих инфраструктуру для интеграции разнородных компонентов.
Прикладная область накладывает общие требования на пропускную
способность и задержку в сетях связи.
SoC платформы содержат как фиксированные аппаратные и
программные элементы, так и переконфигурируемые/программируемые

Функционально-архитектурное совместное проектирование I
элементы, на основе SW в памяти и перепрограммируемой аппаратной
логики. Базовой HW платформы недостаточно для задания полезной 3G
платформы; для быстрого проектирования дочерних SW компонентов и
интеграции новых HW периферийных компонентов в уже
существующую сеть коммуникаций необходима богатая, многоуровневая SW
архитектура. Это приводит к понятию системной платформы, которая
является компромиссом между желанием 3G проектировщиков отобразить
свое приложение на многие индустриальные платформы и желанием
поставщиков платформ охватить в рамках одной платформы многие
приложения от многих групп системного проектирования.
Многие аспекты SoC платформы были заданы довольно рано в
пространствах проектирования беспроводных 2G технологий и
мультимедиа. 2G платформы предлагаются такими компаниями, как Texas
Instruments, LSI Logic и VLSI Technology (сейчас Philips
Semiconductors). Активная работа в области 3G платформ проводится сейчас
компаниями TI, Motorola, Infineon, ST Microelectronics, Philips и многими
другими.
Ключевой в понятии платформы является идея контролируемой
среды, позволяющей исследование пространства проектирования и
повторное использование архитектур и компонентов. Однако только
платформ недостаточно для эффективного исследования пространства
проектирования, для этого необходима довольно новая дисциплина,
называемая «Функциональное-архитектурное совместное проектирование»
(«Function-architecture co-design»).
Функционально-архитектурное
совместное проектирование
Функционально-архитектурное совместное проектирование [7]
появилось как некое объединение всех существовавших до этого методологий
совместного HW-SW проектирования (рис. 8.2).
В этой методологии создаются и анализируются представления
прикладной функции системы и потенциальных архитектур реализации.
Функциональная модель приложения может быть сформирована
композицией различных Моделей Вычислений, созданных в разных средах
проектирования: статические и динамические потоки данных,
конечные автоматы для управления, SystemC/C/C++ модели, UML модели,
SDL модели, и т.д.
Взаимоотношения между функцией и архитектурой описываются
подробным явным отображением, которое задается как полноценный
объект проектирования и позволяет точно указать архитектурные ресурсы (и
в обработке, и в коммуникациях), как средства реализации прикладной

Глава 8. SoC — Проектирование с учетом алгоритмов
функции системы. Дополнительно к этому, с помощью процессов
детализации функций до уровня набора архитектурных сервисов можно
получить как абстрактные модели реализации высокого уровня, так и
низкоуровневые, более точные модели, которые могут быть использованы для
изучения производительности на различных уровнях детализации.
Функциональный Уровен!
Верификация
Архитектуры
Уровень Отображения
Г Детализация
микроархитектуры
[ HW/SW
Связь
с Верификацией
микроархитектуры
Архитектурный Уровень
Связь
с Реализацией
HW/SW
Рис. 8.2. Функционально-архитектурное совместное проектирование.
PS&
Много
Стандартов
Стандарт А
Рис. 8.3. Исследование Архитектур.

Существующие и Появляющиеся Проектные Технологии I
Отображение функций на процессорные ресурсы предполагает
реализацию в виде SW задач, выполняющихся на контроллерах и DSP, в то время
как отображение на HW блоки предполагает HW реализацию с помощью
специализированных блоков, ASIC или переконфигурируемой логики.
Таким образом функционально-архитектурное совместное
проектирование позволяет проводить большой набор архитектурных
исследований (рис. 8.3).
Возможен выбор среди многих потенциальных архитектур и
оптимальных компонентов. Но лучше всего достоинства данной
методологии проявляются только при совместном использовании с
платформенным подходом [8]. В этом случае исследование архитектур строго
ограничено пространством прикладной области, с использованием
проверенных IP блоков, спроектированных с целью быстрой интеграции в 3G
платформу. Такая комбинация (методологии с платформенным
подходом) обеспечивает высокую продуктивность исследования пространства
проектирования вместе с минимальным риском реализации проекта.
Существующие и Появляющиеся
Проектные Технологии
На рынке существует много средств, позволяющих разработчикам решать
проблемы проектирования в беспроводной области. Они делятся на две
основных категории: средства алгоритмического проектирования,
анализа и реализации; и средства совместного проектирования (co-design). В
первую категорию попадают многие средства на основе потоков данных,
включая Matlab и Simulink компании Mathworks; CoCentric System Studio
компании Synopsys; и SPW от компании CoWare (до сентября 2003 года от
компании Cadence). В научной области особенно хорошо известны
программы Ptolemy и Ptolemy II, написанные командой профессора Ed Lee из
университета Беркли [9]. Далее мы рассмотрим CoWare SPW в качестве
типичного примера сред проектирования такого типа.
В области средств совместного проектирования существует
несколько интересных исследовательских проектов и коммерческих разработок.
Превосходный обзор данной области проведен в 5-й главе новой книги
Питера Марведела (Peter Marwedel) [10]. В средства совместного
проектирования входят SpecC методология и программы от профессора Dan
Gajski университета города Ирвайн (Irvine), работа над OCAPI,
выполняемая в IMEC, работа над POLIS в университете Беркли [11] и многие
другие. К коммерческим средствам относятся проекты «felix» и VCC от
компании Cadence, а также N2C и ConvergenSC от компании CoWare.
Мы рассмотрим средства совместного проектирования на примерах
VCC и CoWare.

120 Глава 8. SoC — Проектирование с учетом алгоритмов
Средства Алгоритмического Проектирования,
Анализа и Реализации
Программа SPW [12] от компании CoWare является одной из ведущих
сред алгоритмического проектирования, анализа и реализации на
основе потоков данных. К ее ключевым особенностям относятся:
• Обширные прикладные библиотеки для беспроводных и
мультимедийных приложений, включающие Wideband CDMA (3GPP, UMTS,
ARIB, IMT2000, CDMA2000), Wireless LAN (Bluetooth и стандарты
802.11, 11a, lib, llg),GSM/EDGE/(E)GPRS, PCS/CDMA, IS 136,
базовое и продвинутое мультимедиа (HDTV, DVD, видеоконференции,
цифровые фотоаппараты, MPEG2, MPEG4, JPEG-2000) и
библиотечные RF блоки.
• Высокая скорость симуляции потоков данных с плавающей и
фиксированной точкой.
• Полиморфические типы данных
• Связь с реализацией в случае RTL HW реализации алгоритмов и
верификации
• Тесное взаимодействие со средствами верификации и перекрестной
отладки платформы верификации Incisive компании Cadence.
• Взаимодействие с AMS и Spectre-RF программами от Cadence для
одновременной аналоговой/цифровой симуляции и верификации
RF проектов снизу-вверх.
• Переход тестовой платформы с уровня плавающей точки на уровень
Рис. 8.4. Алгоритмы OFDM стандарта 802.1 la WLAN в SPW.

Средства Алгоритмического Проектирования 121
с фиксированной точкой и далее на уровень SW и HW реализации
• Совместная симуляция системного окружения и SW реализации на
основе DSP ISS (Instruction Set Simulation) моделей
• Связь с автоматизированными методами HW реализаций
посредством синтеза с помощью программы BuildGates компании
Cadence.
• Импорт моделей и/или совместных симуляций на базе SystemC
2.0, Matlab, C/C++, VHDL-Verilog-AMS, Verilog или VHDL.
• SPW предлагает ключевые возможности по созданию как HW, так
и SW IP блоков в области беспроводных 3G технологий, готовых
для интеграции в конечную 3G систему.
На рисунке 8.4 показаны алгоритмы для OFDM стандарта 802.11а
WLAN, введенные в SPWc помощью графического интерфейса (GUI).
После введения алгоритмов средства анализа SPW позволяют
изучить, как эти алгоритмы будут работать в рамках различных стандартов
верификации беспроводных протоколов, включая реальное
моделирование канала с учетом различных RF особенностей. Средства анализа
предоставляют возможность взглянуть на выходные данные в разных
представлениях (рис. 8.5, рис. 8.6, рис. 8.7).
Select Component Real
Eye Persistence
100 100 400
Select Component Real
Scatter Persistence Eye Persistence
500 100 tOO 400
Scatter Persistence
500
Рис. 8.5. Видеодиаграммы 64 QAM адаптивного эквалайзера.

122 Глава 8. SoC — Проектирование с учетом алгоритмов
Multipath Delay t 0
Multipath Delay 2
Multipath Delay 3
Multipath Delay 4
Multipath Delay 5
Multipath Delay 6
wi n ci ow
Mobile Channel Frequency Response
10
23
35
56
82
ДИШМ
ШпННин1
ИнШшшШШ
МИИДНюИД
дщдддщдц^!
Рис. 8.6. Диаграммы частотных откликов.
.т т
Рис. 8.7. Кривые частоты ошибок по битам (BER)

Средства Совместного Проектирования(СоDesign) 123
После анализа, оптимизации алгоритмов и последующего перехода
от плавающей точки к фиксированной, связи SPW с реализацией
позволяют сгенерировать синтезируемый RTL код с фиксированной точкой,
который можно использовать для совместной симуляции в средствах
RTL/HDL верификации, таких как Incisive компании Cadence, а также
использовать в качестве входных данных для стандартных маршрутов
RTL синтеза. Для тех частей алгоритма, которые будут реализованы в
программном виде, совместная симуляция в SPWHa основе DSP ISS моделей
позволяет быструю и эффективную HW-SW совместную верификацию.
Средства Совместного Проектирования
(CoDesign)
Проекты «felix» и VCC компании Cadence [13] были одними из первых на
пути превращения идей функционально-архитектурного совместного
проектирования в рабочие средства. Хотя программа VCC больше не
поддерживается, она была передовой во многих важных областях
совместного проектирования, а соответствующая технология и методология до сих
пор используются в области автоматизации проектирования.
К особенностям VCC относятся возможность создания
интегрированной модели системных функций на основе различных импортированных и
локальных моделей вычислений, включая поддержку импорта IP,
созданного на основе SPW. В дополнение к этому в VCC существовал большой набор
конструкций архитектурного моделирования, предназначенных для
создания моделей производительности функциональных, обрабатывающих и
коммуникационных компонентов, на нескольких уровнях абстракции и
точности. Графические возможности по функциональной и архитектурной
интеграции, а также отображению (mapping) между двумя ортогональными
видами системы, позволили создание симулируемых моделей
производительности полной интегрированной системы. В процессе исследования
архитектур проектировщики могли на ходу изменить выбор компонентов и
структуру коммуникаций для удовлетворения системным ограничениям.
Комбинация VCC со специализированной библиотекой и
проектными данными предлагалась уже как платформа для проектирования,
позволяющая проводить исследование пространства архитектур в целях
выбора правильной 3G SoC платформы.
Маршрут проектирования на основе VCC не заканчивался на
моделировании и анализе производительности на системном уровне.
Имеющиеся возможности связи с реализацией, позволяли осуществить генерацию
и экспорт до уровня реализации в RTL и С на основе библиотек, для HW
проектирования и интеграции, SW проектирования и интеграции, и
тестовых платформ для совместной верификации.

124 Глава 8. SoC — Проектирование с учетом алгоритмов
К более современным средствам совместного проектирования
относятся N2C и ConvergenSC компании CoWare [12]. ConvergenSC является
генерализованной средой по проектированию и верификации на основе
SystemC, поддерживающей моделирование и исследование шинных
архитектур, а также создание/ввод и анализ системных моделей на основе
SystemC. Также поддерживается моделирование на уровне транзакций и
создание прототипа на уровне транзакций, который может быть передан
аппаратным и программным разработчикам, а также и системным
интеграторам. Набор различных возможностей по анализу позволяет
исследование разных конфигураций системных архитектур на основе шин, а
IP модели поддержки процессоров позволяют интегрировать
встроенные ISS модели. В ConvergenSC есть возможность создания платформы,
позволяющей исследовать различные платформенные архитектуры на
основе проектной модели.
Все это позволяет, например, исследовать типичный
конфигурационный параметр системы - размер кэша, провести анализ транзакций и
конфликтов на шине, выполненный с целью выбора оптимального
количества ведущих шин (master) или ведомых шин (slave) для
окончательного определения архитектуры шины на чипе.
Создание Маршрута Проектирования
в Беспроводной Области
Недостаточно просто создать отдельные средства 3G проектирования.
При разработке средств по созданию алгоритмов и совместному
проектированию был сделан упор на интеграциию ключевых проектных задач
и создание связей между отдельными средствами для получения общей
методологии и маршрута проектирования.
На рисунке 8.8 проиллюстрированы особенности маршрута
проектирования SoC 3G, беспроводной связи, на основе средств совместного
проектирования (IP-блочного и алгоритмического). Этот маршрут позволяет:
• Создание DSP IP (HW и SW) в среде проектирования алгоритмов на
основе потоков данных с ключевыми связями с реальным RF
окружением, созданного путем абстракции на основе RF симуляции.
• Возможность экспорта DSP IP моделей в общую среду Системной
интеграции и совместного проектирования на основе IP. Это
позволяет принять важные решения по разделению функций на HW и SW,
особенно в области управления.
• Совместную симуляцию, использующую скомпилированные
методы, средств написания алгоритмов потоков данных, и HDL
симуляции, и обеспечивающую быструю проверку HW реализаций с
помощью системной тестовой платформы.

Создание Маршрута Проектирования в Беспроводной Области 125
Протокол, OS,
Программы
Приложения
Полная
Спецификация
Системы
^зйанШ-:^::+^' ШЩаШё;
т
1
;Си^мнош[Р
Верификация
ЭДиЭмул
RF Искажения
? ч
ъ
1уля1Дия J-^J Синтез < : .1
Частота
Ошибок
по Битам
Выбор
DSP/ASIC
ч
Детальная
верификация
Путь
к Производству
Рис. 8.8. Маршрут Проектирования в Области Беспроводного 3G.
• Экспорт DSP/dataflow HW проекта на уровень RTL реализации
через логический синтез, в сочетании с расширенными
возможностями проектирования каналов данных, и обеспечением генерации
оптимизированных HW блоков.
• Обеспечить связь с аппаратным ускорением симуляции и.
эмуляцией HW, и тем самым более быструю проверку системы в целом.
Такой маршрут интегрированного проектирования возможен
только при согласованных действиях 3G разработчиков, и отказе от широко
распространенного в прошлом акцента на создание
отдельных/независимых средств для отдельных задач.
Заключение
В этой главе были рассмотрены, с нескольких точек зрения, основные
препятствия в проектировании и распространении SoC проектов
беспроводных 3G систем. Эти препятствия преодолимы с помощью
новых проектных подходов и методологий: современное проектирование
алгоритмов, богатый набор технологий верификации, платформенное
проектирование и функционально-архитектурное совместное
проектирование. Для построения маршрута проектирования 3G SoC можно
использовать различные средства анализа потоков данных и
совместного проектирования, а их связи друг с другом и с дополнительными
средствами реализации и верификации, обеспечивают
проектировщиков богатым набором возможностей в проектировании беспроводных
3G систем.

126 Глава 8. SoC — Проектирование с учетом алгоритмов
Литература
1. Panasik, Carl, Overcoming Obstacles to 3G Wireless Technology, Communications Systems
Design, January, 2001, pp. 11-12.
2. Martin, Grant, Bernard Jackson, Mika Nuotio, and Louis Pandula, Design Parameters
Optimize 3G Handset Development, Wireless Systems Design, June 1999, pp. 15-20.
3. Alamouti, Siavash, John Lundell and Ed Casas, Reducing the Development Cycle for Third
Generation Wireless Communications Systems with Parallel Simulations, Embedded Systems
Conference, April 9-13, 2001, San Francisco, Class 542. Web URL: http://www.escon-
line.eom/db_area/01 sf/542.pdf and also
http://www.cadence.com/whitepapers/paper542.pdf
4. Wilson, Les, and Bo Wu, Introduction to Solving the Design Challenges of a 2.5G/3G Video
Cell Phone, Wireless Systems Design, March, 2001. Available on the web at URL
http://www.wsdmag.com/Articles/Index.cfm? ArticleID=14552&extension=pdf
5. Chen, Jess and G. Strube. Das K-Modell: Ein neues nichtlineares Modell die Simulation des
Basisbandverhaltens von Hochfrequenzschaltungen, Cadence Design Systems GmbH -
Munchen, ITG/GMM-Diskussionssitzung «Entwicklung von Analogschaltungen mit
CAE-Methoden» (Analog99), February 17-19, 1999.
6. Chang, Henry, Larry Cooke, Merrill Hunt, Grant Martin, Andy McNelly, and Lee Todd,
Surviving the SOC Revolution: Л guide to platform-based design, Kluwer Academic Publishers,
1999.
7. G. Martin and B. Salefski, Methodology and Technology for Design of Communications and
Multimedia Products via System-Level IP Integration, Designer Track of Design Automation
and Test in Europe (DATE-98), Paris, France, February, 1998, pp. 11-18.
8. G. Martin, «Productivity in VC Reuse: Linking SOC platforms to abstract systems design
methodology», Chapter 3 in Virtual Component Design and Reuse, edited by Ralf Seepold
and Natividad Martinez Madrid, Kluwer Academic Publishers, 2001, pp. 33-46.
9. URL: http://ptolemy.eecs.berkeley.edu:/
10. Peter Marwedel, Embedded System Design, Kluwer Academic Publishers, 2003.
11. Felice Balarin, Massimiliano Chiodo, Paolo Giuston, Harry Hsieh, Attila Jurecska,
Luciano Lavagno, Claudio Passerone, Alberto Sangiovanni-Vincentelli, Ellen Sentovich,
Kei Suzuki and Bassam Tabbara, Hardware-Software Co-Design of Embedded Systems: The
POLIS Approach, Kluwer Academic Publishers, 1997.
12. URL: www.CoWare.com
13. G. Martin and B. Salefski, System Level Design for SOCs: A Progress Report - Two Years On,
Chapter 25 in: System-on-Chip Methodologies and Design Languages, editors Peter
Ashenden, Jean Mermet, and Ralf Seepold, Kluwer Academic Publishers, 2001, pp.
297-306.

ГЛАВА 9
АНАЛОГОВЫЕ -
СМЕШАННЫЕ SoC
Введение
В этой главе мы кратко обсудим вопросы проектирования и создания
смешанных SoC (mixed-signal SoC). Интерес к смешанным или AMS
SoC, в последнее время растет, и работа в этой области сталкивается со
значительными проблемами в проектировании, верификации и
производстве [1,2]. Наиболее амбициозные компании, такие какТ1, объявили
0 проведении работ по созданию SoC, интегрирующей цифровую,
аналоговую и RF части на одной кремниевой подложке1. Но создание
подобных SoC зависит также от наличия проектировщиков, обладающих
глубоким пониманием того, как можно успешно объединить на одном
чипе аналоговые, цифровые и, возможно, RF компоненты. Такие
проектировщики встречаются довольно редко:
«Свежий выпускник колледжа с дипломом бакалавра по
электронному проектированию может стать полезным цифровым проектировщиком
за шесть месяцев и специалистом за два года. В противоположность этому,
аналоговый разработчик может потратить от четырех до пяти лет, прежде
чем он сможет стать полноправным членом команды и вносить свой
вклад, а специалистом он сможет стать только после шести-семи лет».2
Таким образом, можно видеть, что одним из ключевых факторов,
ограничивающих широкое распространение AMS SoC, является
отсутствие достаточного числа опытных аналоговых проектировщиков.
Вначале нам нужно идентифицировать, что входит в определение
AMS SoC. Многие SoC содержат некоторые AMS блоки - например,
компоненты фазовой автоподстройки частоты (PLL - Phase-Locked
Loops), A/D и D/A конвертеры, блоки периферийных интерфейсов,
такие как интерфейсы с шиной (USB, PCI, и т.д.), и видео/аудио кодеки.
Эти SoC можно рассматривать как «D/a» (В основном цифровые,
немного аналоговые). Только небольшая часть из них отдана под AMS
блоки на периферии, для интерфейсов. В таких SoC AMS блоки можно
рассматривать как черные ящики, и они могут быть успешно
интегрированы командой цифровых разработчиков на основе строгих правил,
обычно предоставляемых поставщиками AMS IP блоков.
1 Peter Clarke, TI Plans to implement «single-chip» cell phone in 2004, Semiconductor Business News, 5
September 2002, URL: http://www.eetuk.com/tech/news/OEG20020904S0032
2 A. Cheng, Standard analog/mixed-signal 1С market, Gartner/Dataquest, August, 2002.

128 Глава 9. Аналоговые — смешанные SoC
В противоположность этому в «A/d» (В основном аналоговые,
немного цифровые) AMS SoC такие аналого-цифровые блоки уже нельзя
рассматривать как черные ящики. В этом случае AMS SoC содержат
значительную AMS часть, обеспечивающую большую часть
функциональности (а не только интерфейсы). Здесь аналого-цифровые блоки
накладывают строгие и сложные ограничения на интеграцию, и для
надежного завершения проекта аналоговые разработчики должны быть
основными SoC интеграторами.
AMS SoC различаются по аналоговым характеристикам, и аналого-
цифровое содержимое ключевым образом влияет на время завершения
проекта. Для создания удовлетворяющего спецификациям, с высоким
процентом выхода годных и низкого по себестоимости проекта
разработчикам AMS SoC необходимо обращаться к передовым достижениям в
области смешанных (mixed-signal) технологий. Можно видеть, что AMS
SoC проекты начинают появляться во многих прикладных областях,
особенно потребительских, в которых устройства должны
взаимодействовать с «реальным миром», к этой категории относятся приложения в
области мультимедиа, беспроводных и проводных коммуникаций,
автомобилестроении и медицины. В качестве примеров можно привести:
• SoC, управляющая интеллектуальным зеркалом в современном
автомобиле, содержит источник питания на 8/18V, внутренний
тактовый генератор на 8Мгц, 8-битный A/D конвертер, 6-битный D/A
конвертер, возможность сброса (reset) и включения (power-on), a
также возможность работы при низком напряжении питания [3].
• Чип управления питанием для беспроводного устройства связи [3],
включающий в себя понижающий преобразователь переменного
тока в постоянный, шесть регуляторов напряжения, контроль зарядки
Li-Ion батареи, интерфейс SIM-карты, микроконтроллер, а также
драйверы интерфейса пользователя для звонка, вибратора и
подсветки.
• CMOS сенсор изображения на одном чипе, для мобильных
устройств [4], использующий вместо ПЗС (CCD) технологии CMOS
датчики и интегрирующий эти датчики с сигнальным процессором
(DSP). Данный сенсор изготовлен на основе CMOS технологии (0.5
микрон), и это говорит о том, что даже такие (не самые новые)
технологические процессы позволяют создавать интересные аналого-
цифровые SoC.
• Интегральная схема для GSM/GPRS [5], в состав которой входит
много смешанных (mixed-signal) IP блоков, включая 1x6b, 1x9b (4.3
Ms/s), 3x10b (2.6 Ms/s), 1x13 бит с непрерывным сигма дельта
преобразованием, 1x14 бит 4-го порядка сигма дельта преобразователь,
петлю цифрового управления, ФАПЧ вместе с синтезатором на 1ГГц,
ФАПЧ кварцевый генератор на 26МГц.

Введение I
• Система Bluetooth на одном чипе [6], с рабочим напряжением 2.7V,
реальной чувствительностью —82 dBm и апертурой 0.83,
изготовленная на основе 350 нм BiCMOS.
• Чип для слухового аппарата [7], с рабочим напряжением в
интервале 1.1-1.7V и током потребления 270 микроампер, с сигма дельта
A/D и D/A конвертерами и компрессором на основе цифрового
фильтра.
• Устройство измерения ускорения на основе CMOS MEMS - AMS
схемы включают в себя не только сопротивления, конденсаторы,
емкости и транзисторы, но также и микроэлектронные
механические системы (MEMS) [8].
Проектирование аналоговых/смешанных SoC является сложным по
многим причинам. Одна из причин - чувствительность к шумам,
особенно при наличии цифровых компонент, которые обычно довольно
сильно шумят; другая причина - тот факт, что проект не обязательно
выигрывает от использования более передовых процессов, и при выборе
конкретного процесса нужно учитывать множество факторов; проекты
очень сильно отличаются по требованиям к характеристикам схемы и их
нельзя свести к описанию на основе нескольких простых параметров,
таких как размер кристалла, быстродействие, себестоимость и мощность
потребления; аналоговые блоки весьма уникальны по своим проектным
особенностям в отличие от похожих друг на друга блоков в цифровых
библиотеках. Вдобавок к этому, у каждого аналогового блока свои
требования по характеристикам, и важность этих характеристик может
значительно варьироваться в зависимости от приложения. В области
аналогового проектирования еще не существует общепризнанных средств
синтеза (хотя начинают появляться новые программы), а средства анализа
требуют много времени и не очень точны. Также проблемой является и то,
что аналоговые проекты отстают от цифровых, как минимум, на одно
поколение технологий, и это очень осложняет использование самого
последнего цифрового процесса в аналоговой или смешанной схеме.
Несмотря на все эти проблемы, AMS схемы занимают довольно
большую часть рынка; в 2001-м году, согласно Gartner/Dataquest3 стоимость
мирового аналого-цифрового рынка составляла 27 миллиардов долларов.
К ведущим производителям AMS схем относятся многие крупнейшие
полупроводниковые компании: ST Microelectronics, Texas Instruments,
Philips Semiconductors, Analog Devices и Infineon Technologies.
Согласно Virtual Component Exchange интересным также является
рынок AMS IP блоков - в январе 2003-го года AMS IP блоки составили
около 30% от самых популярных IP блоков, предлагаемых на VCX4.
3 A. Cheng and N. Reilly, 2001 Analog and Mixed-Signal Market, Gartner/Dataguest, June 2002.
4 VCX Newsletter, February 12, 2003

130 Глава 9. Аналоговые — смешанные SoC
В остальной части главы мы кратко рассмотрим тенденции в
развитии методологии аналогового/смешанного проектирования и как они
связаны с проектированием AMS SoC.
Эволюция методологии AMS проектирования
Смешанное (mixed-signal) проектирование традиционно отличалось
сильной зависимостью от стиля проектирования схем «снизу-вверх»;
отсутствием синтеза; необходимостью повторного проектирования и
нескольких итераций в изготовлении конечного продукта (для достижения
требуемого результата); а также медленными, трудоемкими и сложными
циклами проектирования. По некоторым оценкам «аналоговое
проектирование, занимающее 20% площади на чипе, требует при этом 80%
усилий проектировщиков».
Очевиден значительный контраст по сравнению с цифровым
проектированием, в котором развита общая практика проектирования, -
начинать с языкового (HDL) RTL описания, на основе этого
синтезировать логику, далее к библиотекам стандартных блоков, а потом с
помощью средств автоматического размещения и трассировки быстро
создается приемлемая реализация цифровой логики. Значительную часть
цифрового проектирования можно в данный момент охарактеризовать как
«корректную по построению». В результате получается довольно
короткий цикл проектирования (максимум несколько месяцев), чаще всего
приводящий к успешной реализации в производстве с первого раза.
Альтернативные способы реализации, такие как FPGA, распространили эту
«идеологию» цифрового проектирования на более широкие прикладные
области и еще больше уменьшили риск, время и требуемые усилия.
Несоответствие между практикой проектирования в аналоговой и
цифровой областях являлось в прошлом значительным препятствием в
интеграции аналого-цифровых схем и значительно увеличивало риск и
стоимость проектирования. Методология смешанного проектирования
часто начинается с моделей требуемых системных функций,
выполненных в пакете программ Matlab (либо «домашних» C/C++ моделей, таблиц
или проектного опыта), и включает в себя проектирование на уровне
транзисторов, создание топологии отдельных блоков, верификацию на
транзисторном уровне с помощью SPICE и сложный процесс интеграции
отдельных блоков в общий проект с большими циклами экстракции и
SPICE верификации после стадии размещения (по причине паразитных
эффектов). Это приводит к долгим циклам проектирования - обычно 18
месяцев — и 2-4 повторным попыткам реализации на кристалле.
Поэтому, многие современные попытки улучшения методологии
AMS проектирования SoC учитывают следующие особенности:
Время завершения проекта (time to market): так как первая компания,

Эволюция методологии AMS проектирования
131
предложившая новую интегральную схему, обычно занимает львиную
долю соответствующего рынка (при условии достаточной новизны,
хорошего проектирования и приемлемой стоимости), время до
завершения проекта является жизненно важным фактором методологии
проектирования. Для уменьшения времени проектирования важно
уменьшить число повторных итераций проектирования и реализации на
кристалле, максимизировать эффективность каждого разработчика,
увеличить команду разработчиков и распараллелить их деятельность,
уменьшая, по возможности, их зависимость друг от друга.
Сложность: интеграция AMS SoC привела к увеличению сложности
проектирования на каждом технологическом уровне (process node), а
новые приложения увеличили объем и степень обработки сигналов во
многих AMS SoC.
Эти осложнения часто оказываются непосильными для
проектировщиков, и улучшения в средствах проектирования не могут это
компенсировать: «Для того, чтобы справиться с громадными сложностями в
проектировании и верификации, потребуются фундаментальные изменения в
методологии проектирования и средствах программного обеспечения»5.
Избежание риска: спад в электронной промышленности,
начавшийся в 2001-м году и только недавно начавший замедляться, сделал многие
компании и проектные команды очень чувствительными к возможному
риску. С учетом высоких единовременных затрат (NRE) на CMOS
проектирование и изготовление по передовым технологическим процессам,
повторные циклы проектирования/изготовления могут полностью
исчерпать проектный бюджет, а задержки могут сделать продукт уже
ненужным на рынке. Так как создание AMS SoC значительно более
рискованно, чем цифровое проектирование, учет рисков очень важен в
эволюции методологии.
Повторное использование: повторное использование IP блоков и
платформ приносит неоценимую пользу в проектировании больших
цифровых SoC, учитывая выполнение закона Мура. В области AMS SoC
повторно использовать отдельные блоки довольно сложно, так как
процесс эволюции и специализированные проекты ограничивает время
полезности IP блоков, а большие различия в AMS проектах требуют
значительных конфигурационных усилий для обеспечения эффективного
повторного использования. Сочетание укороченного времени жизни и
больших затрат на разработку топологии ИС ограничивает
возможности повторного использования в AMS SoC (за исключением, конечно,
цифровых компонент).
5 Dr. H. Samueli, co-Chairman and СТО, Broadcom Corp. Invited Keynote Address, Broadband
communication ICs: enabling high-bandwidth connectivity in the home and office, Slide supplement 1999 to the
Digest of Technical Papers, tm. 29-35. International Solid State Circuits Conference. Feb 15-17. 1999.
San Francisco. CA

132 Глава 9. Аналоговые — смешанные SoC
Гибкость в требованиях к продукту: стремление раньше выйти на
рынок часто заставляет начать детальное проектирование еще до того, как
все требования к продукту окончательно зафиксированы; это означает,
что проект должен быть гибким к возможным изменениям в
требованиях (например, в коммуникационных стандартах), и методология
проектирования должна быть готова к внесению значительных изменений в
спецификацию, а также обеспечивать очень хорошую верификацию
соответствия модифицированного проекта новой спецификации.
Высокоскоростное I/O: для многих сетевых и вычислительных
приложений все более важным становится наличие последовательного I/O со
скоростями порядка одного ГГц и более. В результате сложные AMS
блоки уже нельзя разместить на отдельных чипах, а нужно интегрировать
вместе. Любая новая или улучшенная AMS SoC методология должна
способствовать проектированию последовательного I/O в районе 1 Gbit и более.
Методологии Сверху-Вниз и Снизу-Вверх
Традиционная AMS методология проектирования «снизу-вверх»
начинается с разбиения проектных спецификаций на компоненты, возможно
с помощью таблиц, Matlab моделей или C/C++ моделей. Далее
отдельные блоки проектируются на уровне транзисторов и каждый из них сам
по себе верифицируется с помощью программ типа SPICE на
соответствие своей части спецификации. Затем блоки объединяются в требуемую
схему вручную, и вся система снова верифицируется на уровне
транзисторов с помощью длительных расчетов.
Проектирование снизу-вверх в случае AMS SoC обладает рядом
недостатков. В сложных проектах наибольшее влияние на характеристики
может оказывать уровень архитектуры системы и это не учитывается
стилем проектирования «снизу-вверх», возможности по исследованию
структуры AMS SoC и ее оптимизации значительно сокращаются.
Продолжительные расчеты всего чипа ограничивают возможности по
верификации, что приводит к повторным проектным итерациям. Часто
большая часть ошибок появляется в момент объединения блоков, а не
внутри отдельных блоков - и при этом верификация неадекватна именно в
случае комбинированных блоков. Ошибки, найденные при
комбинировании блоков, обычно довольно трудно исправить, так как для этого
требуется перепроектирование отдельных блоков. Разбиение проекта на
блоки приводит к необходимости в неформальном общении между
проектировщиками, ответственными за отдельные блоки, что ограничивает
возможное распараллеливание и использование географически
рассредоточенных проектных команд. Вдобавок к этому стадии проекта часто
требуют строго последовательного выполнения - в результате стиль
проектирования «снизу-вверх» требует слишком много времени.

Проектирование AMS SoC «Сверху-Вниз^
133
Ключевым в области AMS SoC является переход к стилю
проектирования «сверху-вниз». Такой стиль придает гораздо большее значение
архитектуре на системном уровне и стадии исследования структуры
проекта, с использованием для обширной оптимизации проекта таких
средств, как Matlab, Simulink и моделирования с помощью Verilog-AMS,
VHDL-AMS. Вдобавок к этому, эти средства обеспечивают большую
возможность применения методов повторного использования, более
формализуют общение между членами команды, снижая повторные
итерации.
Жизненно важны улучшенные методы и средства верификации,
особенно при интеграции AMS блоков на одном кристалле, для того,
чтобы можно было, как можно раньше обнаружить ошибки и исправить
их. При проектировании «сверху-вниз» важно, чтобы все члены
команды пользовались общим представлением проекта (исходным кодом) и
верифицировали все изменения проекта в рамках всей системы.
Верификация должна стать тщательно спланированным процессом, а не просто
произвольным выполнением симуляций. Вместо проектирования
отдельных блоков и обнаружения проблем только в момент их
объединения жизненно важно создавать ранние прототипы SoC на основе ранних
моделей проекта, абстракций и оценок. Наконец, использование
реализуемых моделей гораздо более предпочтительней текстовых
спецификаций, так как при этом уменьшаются возможные неоднозначности, и
появляется системный контекст для проверки проектов отдельных блоков.
Проектирование AMS SoC «Сверху-Вниз»
Методология проектирование сверху-вниз предлагает много
фундаментальных улучшений в процессе проектирования AMS SoC:
Общие представления (исходный код) проекта: языки моделирования
в аналоговой области, такие как VHDL и Verilog-AMS, позволяют
разработчикам создать исполняемые модели спецификации всего AMS SoC
проекта и передать их проектировщикам после того, как SoC
подверглась разбиению на основные подсистемы или блоки. Это позволяет
проектировщикам верифицировать отдельные блоки в контексте всей
системы и не допускает разрыва, возникающего, например, между
системными проектировщиками, использующими Matlab, и схемными
проектировщиками, использующими HDL и SPICE.
Последовательная верификация изменений: при переходе с
системного уровня на уровень транзисторов и топологии, возможна верификация
всех существенных модификаций с помощью смешанных
(многоуровневых) расчетов, точно отражающих реальное состояние AMS SoC.
Отдельные блоки можно детализировать на следующий уровень, а затем заново
верифицировать в системном контексте с помощью одновременного

134 Глава 9. Аналоговые — смешанные SoC
моделирования, например, транзисторной модели данного блока вместе
с высокоуровневыми моделями остальной части AMS SoC. При этом
также повторно верифицируются интерфейсы между блоками в
контексте всей системы, а в случае обнаружения ошибок можно оценить,
насколько сильно они влияют на систему в целом.
Планирование верификации: AMS SoC слишком велики для
эффективной верификации на уровне транзисторов. Проектирование «сверху-
вниз» с моделированием системы на высоком уровне и тщательной
верификацией вносимых изменений при детализации проекта позволяет
заранее обнаруживать возможные проблемы и корректировать их без
больших затрат времени.
Быстрое начальное прототипирование: Создание виртуальных
прототипов широко используется при проектировании больших цифровых
интегральных схем, важность таких прототипов увеличивается и в случае
AMS SoC. Начиная с моделей и оценок, можно избежать
перепроектирования и повторных итераций с помощью раннего обнаружения и
исправления проблем разбиения и интеграции. Начальные прототипы
создаются на основе моделей верхнего уровня и поведенческих (behavioral)
моделей блоков, оценок размеров блоков, начальных планов
размещения (floorplan) и трассировки на верхнем уровне, а также полученных в
результате этого данных о паразитных элементах, которые можно
использовать в моделировании на верхнем уровне. Все это со временем
детализируется по мере продвижения проекта. В результате повторные
виртуальные прототипы постепенно приближаются к полному проекту
чипа.
Исполняемые спецификации и планы: текстовые спецификации
зачастую довольно плохо написаны, устарели, двусмысленны, и очень часто
написаны, чтобы удовлетворять техническому заданию на проект, а не с
целью их последующего чтения и использования. Исполняемые модели,
с другой стороны, и сценарии применения средств проектирования,
осуществляющие основные стадии проекта, выглядят гораздо лучше. Они
используются каждый день, поддерживаются, не содержат
двусмысленностей и повышают продуктивность разработчиков. При условии их
поддержания в соответствии с проектными данными они становятся
хранилищем опыта для повторного использования и образовательным
средством для новых проектировщиков.
В итоге, неукоснительная реализация процесса проектирования
AMS SoC сверху- вниз включает в себя: планы по расчетам и
моделированию; исследования на системном уровне и верификацию; смешанное
моделирование на разных уровнях; верификацию снизу-вверх;
интегрирование блоков в SoC и завершающую верификацию; а также AMS
тестирование.

AMS SoC и Повторное Использование IP блоков I
Такой тип методологии проектирования сверху-вниз хорошо
проверен; детальное обсуждение фундаментальных исследований, которые
привели к развитию этой методологии, можно найти в [1].
AMS SoC и Повторное Использование IP блоков
Так как проектные команды уже давно пытаются расширить понятие
повторного использования IP блоков на область AMS схем, VSIA с
момента своего появления также работает в области AMS IP блоков.
Рабочая группа VSIA, посвященная AMS блокам, начала свою работу в
декабре 1996-го года, всего лишь несколько месяцев после основания VSIA.
Целью работы этой группы было «развитие стандартов и директив,
способствующих интеграции и тестированию существующих «hard»
(привязанных к процессу), смешанных (mixed-signal) блоков в рамках
преимущественно цифровой системы на чипе.
VSIA AMS DWG (рабочая группа по аналого-цифровым IP-блокам)
работала в предположении существования основного документа VSIA
по архитектуре и стандартов/указаний по реализации/верификации IP
блоков. Эта рабочая группа создавала дополнения и расширения VSIA
спецификаций на случай AMS IP блоков. В результате AMS DWG
добавила новый материал, связанный с дополнительными поставляемыми
документами по IP блокам, системному проектированию,
тестированию и физической реализации блоков, а также внесла необходимые
модификации в контексте «hard» AMS блоков. Например, к правилам VSIA
по физической интеграции цифровых IP блоков AMS DWG добавила
общие физические правила, спецификации по размещению,
межсоединениям, ограничениям связанных с влиянием подложки в случае AMS
IP блоков, включая - спецификации по физической изоляции,
ограничения на размещение, эффекты взаимодействия близлежащих
элементов, ограничения на трассировку, специальные требования к выводам, а
также дополнительные ограничения на питание, заземление и
соединения с подложкой. После начальных спецификаций, появившихся в
1998-м и 1999-м DWG провела дополнительную работу по проблемам
схем для обработки analog- mixed сигналов и правилам проектирования
для AMS IP блоков, которые были выпущены в начале 2002-го года.
К началу 2004-го года результатом работы с AMS IP блоками пока
остается то, что повторное использование скорее исключение, чем
правило (хотя интерес к повторному использованию растет); поставщики
AMS IP блоков довольно редки, за исключением
высокопроизводительных I/O компонентов; большая часть повторного использования
происходит внутри больших проектных компаний - как системных, так и
полупроводниковых — хотя перспективы роста в повторном
использовании AMS IP довольно велики.

136 Глава 9. Аналоговые — смешанные SoC
Заключение
В этом разделе мы обсудили некоторые проблемы, связанные с
проектированием AMS SoC, а также изменения в проектной методологии,
требуемые для упрощения проектирования AMS SoC до уровня цифрового
проектирования. К этим изменениям относится переход на более
строгую методологию проектирования «сверху-вниз», основанную на
высокоуровневом моделировании, детализации на уровне блоков, раннем
создании виртуальных прототипов чипа, верификации блоков и подсистем
в общем контексте, а также строгих процессах проектирования.
Вдобавок к этому мы обсудили повторное использование AMS IP блоков и
роль рабочей группы VSIA AMS (DWG) в продвижении директив,
нацеленных на повышение повторного использования в будущем.
Несмотря на проблемы, связанные с созданием AMS SoC, их
значение будет продолжать расти.
Литература
1. Henry Chang, Edoardo Charbon, Umakanta Choudhury, Alper Demir, Eric Felt, Edward
Liu, Enrico Malavasi, Alberto L. Sangiovanni-Vincentelli, and Iasson Vassiliou, A Top-
Down, Constraint-Driven Design Methodology for Analog Integrated Circuits, Kluwer
Academic Publishers, Boston, 1996.
2. Henry Chang, SoC Design Methodologies, Chapter 2 in Grant Martin and Henry Chang
(editors), Winning the SoC Revolution: Experiences in Real Designiii, Kluwer Academic
Publishers, Boston, 2003.
3. Bruno Murari, Bridging the Gap Between the Digital and Real Worlds: The Expanding Role of
Analog Interface Techniques, IEEE International Solid-State Circuits Conferenceiii, 2003.
4. K. Yoon, C. Kim, B. Lee, and D. Lee, Single-chip CMOS Image sensor for mobile
applications, IEEE International Solid-State Circuits Conference, vol. XLV, pp. 36 - 37, February
2002.
5. D. Redmond, M. Fitzgibbon, A. Bannon, D. Hobbs, C. Zhao, K. Kase, J. Chan, M. Priel,
K. Traylor, and K. Tilley, A GSM/GPRS Mixed-signal baseband 1С, IEEE International Solid-
State Circuits Conference, vol. XLV, pp. 62-63, February 2002.
6. P. T. M. van Zeijl, J. Eikenbroek, P. Vervoort, S. Setty, J. Tangenberg, G. Shipton, E.
Kooistra, I. Keekstra, and D. Belot, A Bluetooth radio in О.Щт CMOS, IEEE International
Solid-State Circuits Conference, vol. XLV, pp. 86 - 87, February 2002.
7. J. W. Fattaruso, J. R. Hochschild, W. Sjursen, L. Fang, D. G. Gata, С. М. Branch, J.
Holmes, Z Jiang, S. Chen, K. Ling, E. Petilli, M. L. Skorcz, R. R. Dickerson, and W. A.
Severin, Analog processing circuits for a 1.1V 270цА mixed-signal hearing aid chip, IEEE
International Solid-State Circuits Conference, vol. XLV, pp. 384 - 385, February 2002.
8. J. Wu, G. K. Fedder, and L. R. Carley, A low-noise low-offset chopper-stabilized capacitive-
readout amplifier for CMOS MEMS Accelerometers, IEEE International Solid-State Circuits
Conference, vol. XLV, pp. 428 - 429, February 2002.

ГЛАВА 10
ТЕХНОЛОГИЧЕСКИЕ
ПЛАТФОРМЫ
РЕАЛИЗАЦИИ SoC
Одним из перспективных направлений в в разработке SoC являются
технологические платформы, под которыми понимаются заранее
спроектированные и изготовленные матрицы элементов и их межсоединений,
которые, вместе с верифицированными на данной матрице (и,
возможно, уже реализованными в теле матрицы) IP-блоками, составляют
платформу для реализации целого класса SoC.
Быстрый прогресс в полупроводниковых технологиях позволяет
делать на одном кристалле целые системы, все более объемные и
комплексные. С другой стороны, такие системы становятся все более и более
специализированными, стоимость производства с переходом на каждую
новую технологию растет экспоненциально, а время как
проектирования, так и производства, увеличивается. Если учесть, что сокращается и
жизненный цикл таких систем на кристалле, то задачи сокращения
с;
с;
о
' Я.
-О
О
2
8
1000
900
800
700
600
500
400
300
200
100
о
1997 1998 1999 2000 2001 2002 2003 2004
0.35т
0.18т
0.25т 0.13т
90пт
Технологии
Рис. 10.1 Стоимость масок при массовом производстве.

138 Глава 10. Технологические платформы реализации SoC
сроков проектирования и стоимости изготовления, разделения этапов
разработки и физической реализации SoC, а также широкого
использования IP-блоков, приобретают глобальное значение, оказывающие
решающие влияние на всю полупроводниковую индустрию.
1. Сроки проектирования. С переходом на каждую новую технологию
происходит увеличение сроков проектирования. Если год назад среднее
время выполнения проекта составляло 36 недель при среднем объеме в 1
млн. вентилей, то по 2003 году это время составило 40 недель при
среднем объеме в 2 млн. вентилей. С переходом на каждую новую
технологию происходит сокращение линейных размеров элементов примерно с
коэффициентом 0.7, что дает удваивание числа элементов при
сохранении того же размера кристаллов. В рамках существующих методологий
проектирования использовать перспективные технологии (с
прогнозируемой степенью интеграции в 100 млн. вентилей на технологии 45нм)
представляется нереальной задачей, особенно с учетом сокращения
жизненного цикла микроэлектронных компонентов.
2. Стоимость изготовления ASIC и SoC. Хотя и существует тенденция
к снижению стоимости производства для каждой новой технологии
после ее внедрения, однако рост стоимости производства в зависимости
от технологии изготовления носит экспоненциальный характер
(Рис. 10.1), что делает новые технологии доступными только для
проектирования микросхем массового применения, таких как процессоры,
памяти, программируемая логика и другие. Таким образом,
проектирование в базисе стандартных элементов более невозможно или не
подходит для проектирования широкой номенклатуры электронных
компонентов, объемы выпуска которых не оправдывают высокой стоимости их
проектирования и производства. Не удивительно, что число проектов
ASIC в мире сокращается быстрыми темпами с 10,000 в 1998 году до
4,500 в 2002 (из которых действительно пошли в массовое производство
только 3,500 проектов). По некоторым оценкам в 2003 году было начато
менее 4,000 проектов ASIC.
3. Разделение этапов разработки и реализации проектов. Появление за
последнее время большого числа компаний, не имеющих собственного
производства (fables), означает фактическое разделение процессов
проектирования и изготовления элементной базы. Логическим
продолжением данной тенденции является разделение системных компаний и
дизайн-центров по проектированию элементной базы и формирование
технологической цепи разработка-проектирование-изготовление. Для
системных компаний, где выполняется 1—2 проекта в год, наличие
собственных дизайн-центров экономически не оправдано. Это связано как с
ростом стоимости средств проектирования топологии, пропорциональной

Технологические платформы реализации SoC I
росту стоимости производства микросхем при переходе на новые
технологические нормы, так и с необходимостью иметь специальные навыки
и опыт работы в области субмикронной и нано топологии, где ошибки
проектирования стоят как никогда дорого. Основной проблемой такой
кооперации является влияние топологической реализации проекта на
его функциональные характеристики, которую сейчас необходимо
учитывать на этапе разработки, а в перспективе она будет во многом их
определять.
4. Использование IP-блоков. Одновременно с появлением
концепции SoC было введено понятие проектирования на основе платформ,
как методологии проектирования таких систем, где под платформой
понимается набор базовых блоков (как правило, процессоров, памятей и
блоков их управления, шинных интерфейсов и др.), на основе которых
строится система. Идея состояла в том, чтобы из набора готовых блоков,
представляющих собой аппаратные ресурсы будущей системы,
спроектировать ее архитектуру, создать функциональное описание системы и
затем поставить их в соответствие друг другу (то есть произвести
назначение функциональных блоков в аппаратные ресурсы) с полным
анализом и глобальной оптимизацией всей системы в целом. Основной
проблемой в данном подходе являются трудности в создании инвариантных
библиотек IP-блоков, переносимых между платформами и готовых для
повторного использования в различных проектах, на разных фабриках и
технологиях.
В целом можно сказать, что назрела необходимость в разработке
новых архитектур и методологий проектирования SoC, способных решить,
хотя бы частично, обозначенные выше проблемы. Практической
реализацией этих тенденций являются новые архитектуры кристаллов,
появившиеся около двух лет назад как переосмысление концепции
базовых матричных кристаллов (БМК) на новом этапе эволюции
полупроводниковых технологий и получившими общее название «структурные
ASIC» (Structured ASIC). Принципиальным отличием от БМК является
то, что, помимо реализованных в матрице логических элементов, в ней
реализованы также их межсоединения, и для функциональной
настройки матрицы необходимо выполнить финальное проектирование от 1 до
5 слоев металла. Структурные ASIC, место которых в диапазоне
возможных реализаций SoC показано на Рис. 10.2, представляют собой
конструктив технологической платформы реализации SoC.
Структурные ASIC (Рис. 10.2) состоят из заранее спроектированной
и изготовленной матрицы типа «море модулей»-«море
межсоединений» (по аналогии с определением «море вентилей» для ASIC).
Логические модули имеют однородную структуру и содержат мультиплексоры,
триггеры, память и другие элементы, аналогично логическим блокам,

140 Глава 10. Технологические платформы реализации SoC
используемым в схемах программируемой логики (ПЛИС). Специальная
архитектура межсоединений, в которой реализованы, как правило, все
цепи питания, синхронизации, тестирования и самодиагностики, и
сегменты сигнальных цепей, обеспечивает функциональную настройку
логических модулей и их межсоединений всего несколькими слоями
металла. В зависимости от конкретной архитектуры и плотности компоновки
матрицы для этого требуется спроектировать от 1 до 5 слоев, включая
слои межслойных переходов. В предельном случае такое
«программирование» матрицы выполняется лишь межслойными переходами.
Роль структурных ASIC
X
) о
09
О
►ремя проектир
ш
■■л-.■<■.■■■■■■ -■■
ASSPs
Высокая
стоимость
Не рекон-
фигуруемые
Структурные
FPGA/PLD
Высокая
стоимость

Реконфигурируемость
Низкая плотность
ASICs
Низкая
стоимость
Максимальная
гибкость
Максимальная
плотн
ASIC
ость
1 1 1 1
Производительность
1 Источник: LSI Logic
Рис. 10.2 Место структурных ASIC в диапазоне возможных реализаций SoC.
Действительно, с учетом стоимости производства полного
комплекта масок для проектирования ASIC (Рис. 10.1), единственным способом
использовать возможности современных полупроводниковых технологий
для разработки SoC является применение программируемых и
конфигурируемых тем или иным способом интегральных схем или их «заготовок»,

Технологические платформы реализации SoC 141
тш$
JVIV
Трассировка
и функциональная настройка
ШШ1ЩГ
Элементы
ввода/вывода
} аоЭо ш d •••
а
а
а
о
а
а
м
ЖР
Море соединений
ФАПЧ
3
с[
О
X
ходы/вь
DQ
гФАПЧ<;
Входы/выходы
>
го
О
.■.>.''',, '
Матрица
модулей
>
Я
.-^
';'*ё'*4
Входы/выходы
ФАПу
3
d
о
X
ходы/вь
со
)
>ФАПЧ
Рис. 10.3 Архитектура структурных ASIC.
настраиваемых на выполнение определенных прикладных задач. При
этом базовые структуры кристаллов проектируются только один раз, а их
окончательное конфигурирование в стоимостном выражении
определяется только используемой технологией и числом заказных слоев и
составляет порядка 10—20 процентов от стоимости производства ASIC.
Архитектура структурных ASIC также призвана максимально
упростить и ускорить процесс проектирования. Помимо удешевления
производства за счет проектирования только нескольких заказных слоев,
разработчики стараются уже в архитектуре максимально учесть все
субмикронные эффекты, такие как электромиграцию, падение напряжения на
линях связей, взаимное влияние сигналов и др., обеспечить
синхронизацию и тестирование схем. Поэтому маршрут проектирования
структурных ASIC существенно упрощен по сравнению с традиционными
ASIC и может включать в себя только 2-3 системы для моделирования,
синтеза и планирования площади кристалла, с проектированием
топологии в специализированном дизайн-центре или на фирме-изготовителе. В

142 Глава 10. Технологические платформы реализации SoC
силу определенной детерминированности топологической реализации
структурных ASIC практически исключаются итерации между этапами
функционального и топологического проектирования, что создает
предпосылки для передачи проектов от системных компаний на реализацию
на достаточно высоком уровне абстрактного представления - уровне
регистровых передач.
В таблице 1 приведена общая стоимость разработки и приведенная
стоимость на одну микросхему в различных партиях для ПЛИС,
традиционных и структурных ASIC для технологии ОДЗмкм. В таблице 2
приведено сравнение по стоимости масок и срокам проектирования для
традиционных и структурных ASIC. Компании, разрабатывающие
структурные ASIC, отмечают значительное сокращение стоимости и сроков
проектирования по результатам выполнения проектов своих заказчиков.
Так, LSI Logic оценивает общую стоимость разработки у своих
заказчиков в 20-25% от стоимости традиционных ASIC с сокращением общих
Таблица 1: Стоимость разработки ПЛИС, традиционных и
структурных ASIC (технология 130нм)
Общая стоимость
разработки:
NRE производителя
Число различных
средств САПР
Стоимость САПР
Число инженеров
Стоимость чипа
Общая стоимость чипа
в партии 1000шт.
Общая стоимость чипа
в партии 5000шт.
Общая стоимость чипа
в партии 500Кшт.
ПЛИС
~$165К
Нет
2-3
~$30К
1 -2
$200 -$1 К
~$ 1000 (ЮЗ)
~$220 (4Q'04)
~$40 (4Q'04)
Структурные ASIC
~$500К
~100К-$200К
2-3
~$120Kto$250K
2-3
~$30-$150
$500 - $650
$100 - $150
>$21
Традиционные ASIC
-5.5М (Обычно)
$lMto$3M
6- 10
>$300К
5-7
~$30
$55К
$1.1К
$11 to $20
Source: SemiView, December 2003
сроков проектирования на 50%.
Методология проектирования на основе принципов использования
интеллектуальной собственности в виде IP-блоков также в полной мере
относится и к структурным ASIC, которые вместе с верифицированными
на данной матрице (и, возможно, уже реализованными в теле матрицы)
IP-блоками, представляют собой технологические платформы для
реализации различных классов SoC. Так, для структурных ASIC компании LSI

Технологические платформы реализации SoC 143
Logic, наряду с библиотеками, состоящими более чем из 400 элементов,
может использоваться библиотека IP-блоков Core Ware, содержащая
процессоры, их периферийные блоки, компоненты шины АМВА,
интерфейсы памяти и другие элементы. Для реализации процессорных
ядер, таких как ARM, MIPS и сигнальный процессор ZSP, кристаллы
имеют специальные оптимизированные зоны, где, если такие
процессоры не используются, можно реализовывать произвольную логику. Эти
процессоры, а также другие IP-блоки, уже верифицированы на данной
платформе и могут использоваться в виде готовых макросов.
Компромиссным подходом в течении достаточно долгого времени
было использование БМК, однако это позволяло решить только одну
задачу снижения стоимости производства. Проектирование на БМК,
аналогично ASIC, ведется на основе библиотечных элементов, но в
рамках единого заранее разработанного и изготовленного конструктива.
Базовые пластины для вентильных матриц изготавливаются массовым
способом, а для создания новой интегральной схемы достаточно
спроектировать и изготовить только заказные слои металла, что удешевляет
их производство. Однако с ростом числа слоев металла при переходе
на новые технологии количество заказных масок стало сравнимым с
требуемым для ASIC. При том, что в вентильных матрицах используется
аналогичный ASIC продолжительный маршрут и дорогостоящие
средства проектирования, а в самой концепции заложена избыточность
площади кристалла, преимущества метода были сведены на нет и
вентильные матрицы практически вышли из употребления.
Независимо от способа реализации SoC и используемых средств
проектирования, маршрут проектирования, приведенный в самом
общем виде на Рис. 10.4, состоит из последовательных этапов детализации
абстрактной модели проекта (заданной на системном, поведенческом
или функциональном уровнях) на физический уровень представления.
Традиционно маршрут проектирования делится на две стадии -
разработку и физическую реализацию. Разработка включает в себя создание
исполняемой спецификации проекта, различные виды
функциональной и логической верификации, и синтез проекта в элементный базис
библиотеки производителя. На стадии реализация проекта обычно
выполняются планирование кристалла, размещение и трассировка и
различные виды физической верификации.
Передача проекта со стадии разрабоки на физическую реализацию
может выполняться на нескольких определенных этапах маршрута
проектирования, в соотстветствии с которыми различают несколько типов
передачи проектных данных:
• СОТ (Customer-Owned Tooling) - системная компания выполняет
все этапы физической реализации проекта и передает полную топо-

144 Глава 10. Технологические платформы реализации SoC
логическую информацию на изготовление;
• физический прототип — системная компания выполняет этапы
планирования кристалла, физического синтеза и, возможно, детального
размещения, с передачей проектных данных в дизайн-центр ASIC;
• список цепей - наиболее традиционная передача логического
представления проекта в базисе библиотечных элементов производителя
после логического синтеза;
• RTL - системная компания доводит проект только до представления
на уровне регистровых передач (до выполнения этапа логического
синтеза).
Чем раньше в маршруте проектирования происходит передача
проекта и чем выше используемый уровень его абстрактного представления,
тем меньше разработчики вовлекаются в детали физического
проектирования и могут сосредоточиться на вопросах системного проектирования
и верификации. «Чистая» передача проекта на уровне RTL без
последующих итераций между стадиями разработки и физической реализации
является основным вопросом построения виртуальных прототипов, где
при представлении проекта на высоком уровне абстракций уже
учитываются все физические аспекты проектирования.
Тадиционная
передача
Передача Передача списка Передача
СОТ размещения цепей RT
Рис. 10.4 Общий маршрут проектирования.

Технологические платформы реализации SoC 145
Все методы реализации SoC лежат между двумя полюсами —
разработка полузаказных интегральных схем (ASIC) и разработка на основе
схем программируемой логики (ПЛИС), где структурные ASIC
занимают промежуточное положение (Рис. 10.2). Какой метод реализации
использовать является вопросом оценки предполагаемых объемов
производства, требуемой производительности и функциональных
характеристик микросхем, временных, инженерных и финансовых возможностей,
а также рисков, связанных с тем или иным методом реализации.
Проектирование на основе ПЛИС предполагает использование
стандартных интегральных схем без каких-либо начальных затрат на
изготовление. Относительно короткий цикл и низкая стоимость средств
проектирования делают реализацию проектов на основе ПЛИС весьма
привлекательной, а риск ошибок проектирования практически равен
нулю и сводится к перепрограммированию ПЛИС. Однако, большая
потребляемую мощность, низкая производительность и очень высокая
стоимость кристаллов по сравнению с ASIC, существенно
ограничивают область применения ПЛИС.
В полной мере использовать возможности современных
полупроводниковых технологий позволяет проектирование ASIC на основе
библиотек стандартных элементов. Такие библиотеки содержат достаточно
широкий набор элементов, начиная от самых элементарных логических
функций, что позволяет достичь наилучших характеристик по
производительности, потребляемой мощности и площади кристалла. При этом
для производства необходимо спроектировать более двадцати масок, что,
наряду с высокой стоимостью средств проектирования и сложностью
выполнения проектов, обуславливает их высокую стоимость. Кроме того,
здесь очень высок риск проектных ошибок, приводящих к
необходимости перепроектирования и повторного изготовления комплекта масок.
Применение структурных ASIC позволяет существенно снизить
стоимость, сроки и риски проектирования, типичные для ASIC,
обеспечив характеристики на один уровень ниже по технологии, и
значительно лучшие сравнительно с ПЛИС (включая плотность компоновки, что
самым радикальным образом снижает стоимость готовых микросхем),
что вполне подходит для большинства приложений. Для эквивалентных
технологий по сравнению с ASIC плотность компоновки ПЛИС
составляет примерно 1% (поскольку 90% площади кристалла используется
только для программирования межсоединений), потребляемая
мощность больше в 10-15 раз, а максимальная достижимая
производительность лежит в пределах 20%. Для структурных ASIC плотность
компоновки в 50 раз выше, чем в ПЛИС, и по сравнению со стандартными
ASIC в среднем она составляет 40-60%, при 70% производительности и
большей в 2-3 раза потребляемой мощности.

146 Глава 10. Технологические платформы реализации SoC
Выбор средств проектирования топологии определяется способом
реализации и совершенно очевиден в случае ПЛИС, который
определяется конкретным производителем. Для ASIC проектирование топологии
сейчас все больше выполняется специальными дизайн-бюро, которые
имеют с своем распоряжении все необходимые средства
проектирования. Для структурных ASIC проектирование топологии выполняется
самим изготовителем, поскольку непостредственно зависит от их
архитектуры, для чего используются, как правило, адаптированные
коммерческие САПР. В любом случае, при проектированиии любых ASIC сейчас
речь идет, как правило, о доведении проекта до списка цепей в
библиотечном базисе производителя и, для технологических норм ниже 0.25
микрон, физического прототипа с размещенными элементами, с
последующий передачей этих проектных данных на завершающие этапы
физического проектирования.
При проектировании топологии ASIC выполняется множество
проектных операций, включая контроль исходного списка цепей,
генерацию схем синхронизации и тестирования, размещение и трассировку,
сопровождаемые контролем электрических и технологических норм,
анализом временных соотношений, целостности сигналов,
перекрестных помех и т.д. Помимо сложности и длительности такого цикла
проектирования, влияние топологической реализации на исходные
функциональные характеристики проекта непредсказуемо, что ведет к
итерационному процессу изменения исходных спецификаций на уровне RTL.
Внесение любого такого изменения требует анализа, исправления и
последующей верификации, а разрешение одной проблемы может вызвать
появление других. Окончательное разрешение всех этих проблем
определяется как сходимость проекта.
В случае структурных ASIC субмикронные эффекты топологической
реализации максимально учитываются в самой их архитектуре, что
определяет сходимость проектов и отсутствие итераций в процессе
проектирования. Типовое время физического проектирования составляет 2
недели с момента передачи списка цепей на реализацию (Таблица 2).
Таким образом, проектирование SoC на структурных ASIC и
создаваемых на их основе технологических платформах (с включением в
структуру SoC процессорных ядер и других IP-блоков) позволяет во многом
абстрагироваться на этапах разработки от физической реализации. При
этом передача проектной информации легко формализуется с
автоматическим контролем исходных спецификаций на возможность их
реализации в заданной архитектуре и элементном базисе структурного ASIC.
Применение структурных ASIC или технологических платформ дает
возможность уделять основное внимание именно этапам разработки и
строить маршруты проектирования верхнего уровня в соответствии

Функциональный уровень проектирования
Таблица 2: Сравнение традиционных и структурных ASIC •
Требуемое число масок
NRE по маскам($) Время проектирования
Традиционные Структурные Традиционные Структурные
ASIC ASIC ASIC ASIC
0.18um 26~28/($160K) 5/($21K) 52~56дней 10 дней
0.15um 30-32 / ($300K) 5/($31K) 60-64 дней 10 дней
0.13um 36-40/($600K) 5/($100K) 72-80 дней 10 дней
Source: Faraday Technology Corp.
с классами решаемых задач, а не по способам реализации, и здесь
интерес представляют первые два уровня проектирования - системный и
функциональный:
• системный уровень, где производится определение и спецификация
основных функций проектируемой системы, создание исполняемой
системной модели, и анализ алгоритмов, протоколов, сценариев
работы и общих функциональных характеристик;
• функциональный уровень, связанный с разработкой спецификаций
функциональных блоков на языках высокого уровня описания
аппаратуры Verilog или VHDL и их верификацией, а также переходом
в элементный базис производителя микросхем средствами
логического синтеза.
Функциональный уровень сейчас является основным при
проектировании цифровых систем независимо от их физической реализации.
Функциональный уровень проектирования
Функциональный уровень предполагает использование двух основных
систем проектирования - моделирования и логического синтеза.
Несмотря на сходство решаемых задач при проектировании ПЛИС и ASIC
на функциональном уровне, системы проектирования для них
различны. Это объясняется совершенно разными подходами при
проектировании ПЛИС и ASIC.
Поскольку программирование ПЛИС выполняется самими
пользователями и ничего не стоит в любой момент перепрограммировать
ПЛИС, то принцип «всегда можно все исправить» лежит в основе
всего подхода к их проектированию, где стоимость ошибок
проектирования практически равна нулю. Поэтому основными факторами,
определяющими потребительские характеристики систем моделирования

148 Глава 10. Технологические платформы реализации SoC
для ПЛИС, являются простота и удобство разработки и отладки
проектов, а также их низкая стоимость. Иное дело проектирование ASIC (в
том числе и структурных), где ошибки проектирования не допускаются
и основополагающим приципом является «сделать сразу все правильно».
Поэтому во главу угла здесь ставится логическая и временная
верификация проекта, при этом стоимость систем моделирования не имеет
большого значения. Иные здесь и цели на данном этапе проектирования. Для
ASIC целью является создание качественного верифицированного кода
на уровне регистровых передач (RTL), с которого будет производиться
синтез в элементный базис производителя. При проектировании ПЛИС
целью является выполнение самого проекта ПЛИС, поэтому
функциональные спецификации зачастую содержат также схемы в элементном
базисе выбранного производителя ПЛИС, а описания на языках VHDL
или Verilog имеют плохой стиль и низкую дисциплину кодирования. Все
это делает, например, реализацию ранее выполненных проектов ПЛИС
в виде ASIC непростой задачей, заключающейся в существенной
переработке функциональных описаний с их детальной верификацией.
Хотя одной из областей применения ПЛИС являлась разработка
прототипов ASIC, эти два направления существовали практически
независимо одно от другого. Сейчас ситуация начинает меняться, и способы
исполнения проектов на основе ASIC или ПЛИС стали двумя полюсами,
между которыми лежит множество способов реализации. Более того, в
чаще возникает необходимость учитывать на стадии разработки сразу
несколько вариантов исполнения. Все больше проектов ASIC сначала
макетируется на ПЛИС с прогнозируемым ростом такого макетирования
в ближайшее время до 80% от общего числа проектов, а многие проекты,
изначально разрабатываемые на ПЛИС, затем переносятся на ASIC, и
наоборот. Сбижение этих полярных способов реализации за счет
появления промежуточных решений в виде структурных ASIC с возможностью
миграции проектов между этими технологиями и возрастающей ролью
ПЛИС как средства прототипирования ASIC предъявляет новые
требования как к средствам моделирования, так и к дисциплине разработки
спецификаций на уровне RTL.
Наиболее популярными системами моделирования являются
системы компаний Aldec, Cadence, Mentor Graphics и Synopsys, и если системы
компаний Cadence и Synopsys в основном используются в маршрутах
проектирования ASIC, то системы моделирования Active-HDL и Riviera
компании Aldec и ModelSim компании Mentor Graphics также имеют
полную поддержку для всех производителей ПЛИС. Так, САПР Active-HDL
обеспечивает единую интегрированную среду проектирования и
моделирования для ПЛИС любых производителей, содержит средства
групповой разработки, управления проектами и библиотеками, кросс-отладки

Функциональный уровень проектирования 149
и анализа тестового покрытия, текстовые и графические редакторы, а
вместе с системой Riviera, включающей в себя ряд специальных средств
для верификации ASIC, предоставляет единую среду проектирования
для всех возможных способов реализации проектов.
Однако, выполнение всех необходимых проектных процедур на
данном этапе не является гарантией, что проект действительно
специфицирован оптимальным образом и может быть реализован в
выбранном элементном базисе. Традиционно эта проблема решается путем ин-
терационных процедур логического синтеза и модификации исходного
кода RTL по его результатам. С ростом сложности и объемов проектов
актуальной стала задача обеспечения качества исходного кода RTL и его
реализуемости на ранних стадиях выполнения проектов еще до этапа
логического синтеза. Первые поколения таких систем были ограничены
лишь проверкой семантики кода на уровне RTL, затем был добавлен
общий контроль структуры проекта. Сейчас все большую популярность
приобретают системы построения виртуальных прототипов, которые
обеспечивают новый уровень контроля исходного кода и учитывают
целостность и завершенность проекта, стиль кодирования, временные
ограничения и достижимость временных параметров, выполняют анализ
площади блоков, нетрассируемых структур и времен распространения
сигналов, и гарантируют, что проект действительно может быть
реализован.
Важным здесь является то, что эти системы дают возможность
разработчику оценить реализацию своего проекта на ранней стадии без
необходимости иметь знания о физических аспектах дальнейших этапов
проектирования. Более того, такой формальный анализ кода на уровне
RTL не только повышает качество проекта и сокращает число итераций
при логическом синтезе, но и в перспективе дает возможность передачи
на завершающие этапы проектирования в специализированные дизайн-
центры не списка цепей в элементном базисе производителя (или
физического прототипа изделия), а виртуального прототипа в виде кода на
языках VHDL или Verilog на уровне RTL.
Как уже отмечалось, фирмы-разработчики структурных ASIC
помимо удешевления производства за счет проектирования только
нескольких заказных слоев стараются максимально упростить и ускорить
процесс проектирования, предоставляя заказчикам не только платформу,
но и определенную методологию проектирования. Так, компании LSI
Logic и NEC для анализа проектов с учетом их реализации на своих
архитектурах используют в своих маршрутах специально настроенный
САПР компании Тега Systems, этот же САПР использует сейчас IBM в
перспективном маршруте проектирования ASIC с приемом от
заказчиков на финальное проектирование кода на уровне RTL.

150 Глава 10. Технологические платформы реализации SoC
Пока же основным способом передачи проекта на проектирование
топологии является список цепей в базисе производителя или
физический прототип, содержащий план кристалла и информацию о
размещении элементов. Единственным инструментом перехода на этот уровень
представления проекта с кода RTL независимо от способа реализации
являются системы логического и физического синтеза соответственно.
Наиболее универсальное решение в области синтеза принадлежит
компании Synplicity, которое покрывает все связанные с этим аспектом
области проектирования, а именно логический и физический синтез для
ПЛИС любых производителей, макетирование ASIC на ПЛИС с
автоматическим разбиением проекта на множество ПЛИС при сохранении
целостности исходного проекта, логический и физический синтез для
ASIC, а также средства отладки прошивок ПЛИС на уровне исходного
RTL описания.
В целом для структурных ASIC могут использоваться традиционные
средства логического синтеза ASIC. Но при этом следует иметь ввиду,
что логические блоки структурных ASIC являются сложными
элементами и содержат мультиплексоры, триггеры, памяти и другие элементы,
типичные для ПЛИС. Поэтому достижение наилучших результатов при
логическом синтезе возможно только при использовании специальных
настроек системы на специфический элементный базис. Пока компания
Synplicity является наиболее видной в плане поддержки структурных
ASIC различных производителей, обеспечивая технологическую
независимость и легкость портирования проектов между различными
методами реализации и макетирования. Здесь опять компании LSI Logic и NEC
оказались едины в использовании системы физического синтеза
Synplicity AmplifyASIC, адаптированной для своих архитектур
структурных ASIC, в своих маршрутах проектирования, которые состоят из
следующих этапов: конфигурация ресурсов ASIC и физическое назначение
этих ресурсов, проверка кода RTL на удовлетворение правилам
проектирования, физический синтез с детальным размещением элементов и
контроль результирующего списка цепей с передачей его на
проектирование топологии.
Хотя эти маршруты проектирования ориентированы на конкретные
структурные ASIC в части адаптации коммерческих САПР к их
архитектурам, реализованная в них методология проектирования на основе
формального контроля проектных норм на функциональном уровне имеет
более широкое прикладное значение. Контроль спецификаций на
функциональном уровне проектирования с предсказуемостью реализации
проекта на последующих этапах существенно сокращает число итераций
и время проектирования, и формализует сам процесс передачи
проектных данных в дизайн-центры. Унификация САПР по классам решаемых

Перспективы развития технологических платформ I
задач на отдельных этапах маршрута проектирования (моделирование,
синтез) дает некоторую технологическую независимость, обеспечивая
проектирование ПЛИС, ASIC (в том числе и структурных),
макетирование ASIC на ПЛИС и перенос проектов с одной технологии на другую
если не одними и теми же средствами, то в рамках единого интерфейса
пользователя, системы команд, с сохранением всех командных файлов и
скриптов и гарантией, что описания будут интерпретироваться
одинаковым образом независимо от способа реализации.
Системный уровень проектирования
В то время как проектирование топологии ASIC переходит в зону
ответственности специализированных дизайн-центров, с постепенным
смещением передачи проектных данных от списка цепей на
технологически независимый уровень RTL, все большее значение
приобретает системный уровень проектирования. В целом на системном уровне
создается общая исполняемая спецификация проектируемой системы,
позволяющая исследовать и оценить различные варианты ее
построения и выбрать оптимальное решение, которое будет реализовано в
дальнейшем.
Понятие системного уровня проектирования достаточно обширно и
фактически включает в себя все, что лежит выше функционального
уровня RTL, который, как мы видели ранее, уже предполагает четкое
понимание способа реализации. Тем не менее, на системном уровне
можно в свою очередь выделить три основных подуровня, а именно:
• уровень «миссии» и выбора общей концепции построения системы:
моделирование операционной среды, в которой будет работать
проектируемая система, определение статических и динамических
сценариев, планирование целевых задач;
• архитектурный уровень, с моделированием и анализом
производительности систем, сетевых архитектур и протоколов, пропускной
способности каналов;
• уровень микроархитектуры, т.е. моделирование и анализ алгоритмов
и протоколов, схем разрешения конфликтов на шинах, методов
управления памятью, программно-аппаратное разделение и
разработка программного обеспечения (драйверы и др.).
Если первые два уровня относятся к вопросу концептуального
построения и анализа систем, то микроархитектура непосредственно
связана с последующим этапом функционального проектирования. По
логике эволюционного продвижения средств проектирования на высшие
уровни абстракции именно данный уровень проектирования получил в
последнее время значительное развитие.

152 Глава 10. Технологические платформы реализации SoC
В первую очередь это связано с применением языка C/C++ и
производных языков на его основе, таких как SystemC, Handel-C, Stream-C и
других, для разработки алгоритмов и реализующих их моделей
аппаратных блоков. Идея построения моделей высокого уровня на языках
программирования не нова, однако сейчас поддержка таких языков
обеспечивается как в системах логического моделирования, так и на уровне
систем автоматического синтеза таких моделей в спецификации RTL на
языках VHDL и Verilog.
Так, одной из популярных систем для разработки и моделирования
алгоритмов цифровой обработки сигналов долгое время является
система Matlab/Simulink. Обычно сделанные в этой системе проекты
используются в дальнейшем как спецификации для ручного кодирования
моделей на уровне RTL. Теперь разработанная компаний Synplicity система
синтеза высокого уровня SynplifyDSP позволяет сгенерировать
синтезируемые RTL модели на языках VHDL и Verilog напрямую из Matlab с
поддержкой автоматического преобразования арифметики плавающей
точки в фиксированную и оптимизацией результирующего кода RTL для
реализации в ПЛИС, обычных или структурных ASIC.
Другой подход используется компанией Celoxica в системе DK2
Design Suite, которая реализует методологию программного
компилируемого проектирования. Среда проектирования позволяет выполнить
общую модель и верификацию проекта на языке С, провести разделение
на программную и аппаратную части и напрямую синтезировать
аппаратные модели на языках SystemC и HandelC в элементный базис ПЛИС
или в синтезируемый код VHDL/Verilog. Эта методология поддерживает
языки С, C++, SystemC и Handel-C, а также компиляцию исходных
кодов в процессорные ядра, например Xilinx MicroBlaze. Это дает
возможность не меняя исходной спецификации алгоритма быстро реализовать
его в макетном варианте на процессорном ядре ПЛИС, затем провести
его оптимизацию с частичной или полной аппаратной реализацией и
потом, при необходимости, сгенерировать код RTL для реализации
проекта на ASIC.
Обеспечение целостости исходных спецификаций высокого уровня
и их трансформация в ходе выполнения проекта на функциональный
уровень проектирования имеет принципиальное значение. Поэтому
сейчас фирмы-разработчики систем логического моделирования
стремятся обеспечить совместное моделирование и поддержку VHDL,
Verilog, C/C++, SystemC и других языков из единой интегрированной
среды проектирования. Например, помимо перечисленных языков,
системы моделирования компании Aldec обеспечивают совместное
моделирование с Matlab/Simulink, имеют встроенные системы отладки
C/C++ и Handel-C и встроенные интерфейсы с системами логического

Перспективы развития технологических платформ 153
и поведенческого синтеза, так что разработчики могут в рамках единой
среды проектирования выполнять разработку и отладку кода,
моделирование и синтез с гибкой настройкой системы на свой маршрут
проектирования.
Перспективы развития технологических платформ
За последнее время направление структурных ASIC получило
значительное развитие. Сейчас около двух десятков компаний, таких как LSI
Logic, NEC, Fujitsu, AMI Semiconductor, Lightspeed Semiconductor, Chip
Express, eASIC и другие, уже предлагают свои решения в этой области,
которые соединяют в себе преимущества ПЛИС и ASIC и направлены
на снижение стоимости и сроков проектирования и производства,
повышения гибкости и программируемости выполняемых проектов.
В целом аналитики полагают, что время широкого использования
ASIC на основе библиотек стандартных элементов проходит. Если
$350
$300
$250
$200
$150
$100
$50
$0
Прогноз рынка
структурных ASIC
годовой доход в млн. Долларов
!^ГГ
—
350
300
250 Ф
200 ¥
Э
"С
150 Я
А
Н
100 §
50
2002 2003 2004 2005 2006 2007
о
D - годовой доход
г- - число проектов
Источник: iSappli Corp,, январь 2004
Рис. 10.5 Прозноз рынка технологических платформ.

154 Глава 10. Технологические платформы реализации SoC
разрабатываемая интегральная схема планируется к производству в
очень больших объемах, или требуется достичь наилучших
характеристик в своем классе, либо размер схемы, выражаемый в количестве
эквивалентных вентилей, очень велик, то, вероятно, наилучшим выбором
является проектирование на основе обычных ASIC. Для большинства
интегральных схем с небольшими или средними объемами выпуска и не
требующих достижения экстремальных характеристик, решением будут
являться структурные ASIC. И, наконец, ПЛИС прочно занимают свою
нишу с сфере низкопроизводительных приложений с малыми объемами
выпуска. Прогнозируемый объем рынка для структурных ASIC
оценивается в 2-5 миллиардов долларов, которые практически целиком
«изымаются» с рынка традиционных ASIC SoC при сохранении положительной
динамики роста рынка ПЛИС.
Возможные способы физической реализации SoC не
исчерпываются выше перечисленными базовыми методами, а существует еще ряд
промежуточных вариантов, которые можно определить как
конфигурируемые системы на кристалле (Configurable System on Chip - CSoC). Эти
методы по своей природе являются комбинированными и строятся на
сочетании в себе нескольких подходов, а именно комбинациях в
различных сочетаниях полностью заказных блоков, таких как
микропроцессорные ядра, блоков на основе библиотек стандартных элементов,
структурных матриц и полей программируемой логики.
Практической реализацией одного из таких методов является серия
микросхем компании Triscend, которые содержат в себе в различных
вариантах поле программируемой логики и 32-х разрядное процессорное
ядро ARM7TDMI или микроконтроллер 8051. Другим подходом,
который используется, например, компаниями Lightspeed и eASIC, является
разработка структурных блоков, которые встраиваются в ASIC.
Кристаллы компании Leopard Logic представляют собой комбинацию
большого структурного блока и нескольких полей программируемой логики.
Покупка Triscend компанией Xilinx в феврале этого года и разработка
программируемых масками серии микросхем Stratix HardCopy
компанией Altera показывают, что и производители ПЛИС, со своей стороны,
стремятся выйти на рынок более эффективных решений, чем
традиционные ПЛИС.
Создание технологических платформ может иметь значительное
влияние на всю электронную промышленность, в частности форсировать
применение ASIC (сейчас число новых проектов ASIC снижается).
Фирма iSuppli (занимающаяся исследованием рынка) ожидает значительный
рост числа новых проектов и объема рынка для технологических
платформ (Рис. 10.5). Оценки компаний Dataquest и 1С Insights даже более
оптимистичны. Dataquest ожидает 200 новых проектов на структурных ASIC

в 2004 году с ростом до 1,000 проектов в год к 2007 году. 1С Insights
оценивает объем продаж (по новым проектам) структурных ASIC к 2008
году более чем в 30% всего от ожидаемого объема ранка ASIC. С учетом
более низкой стоимости выполнения проектов на стаких плотформах 30%
объема рынка означают, что более половины всех новых проектов будут
сделаны на структурных ASIC.
Структурные ASIC сочетают в себе преимущества технологий как
ПЛИС, так и традиционных ASIC — производительность и стоимость
чипов близкие к ASIC с низкой стоимостью изготовления и сроками
проектирования ПЛИС. Однако выбор подходящей технологической
платформы для конкретного приложения является не простой задачей.
Технология и платформа каждого производителя имеют свои
характеристики по производительности, стоимости, соотношению объемов
логики и памяти и др. и могут значительно отличаться друг от друга. Для
практического применения технологических платформ необходимо
принимать в расчет следующие факторы:
• производительность: скорость, мощность, прикладные особенности;
• доступные верифицированные на данной платформе IP-блоки;
• простота проектирования и поддержка САПР;
• стоимость (изготовления и кристалла).
Ниже приведен разброс параметров технологических платформ по
8 производителям и технологиям 90-180нм:
Число заказных масок: От 1 до 10
Максимальное число вентилей ASIC: От 0.5М до 10.5М
Максимальное число битов памяти: От 0.4М до 1 1.57М
Максимальная тактовая частота: От 200 MHz до 500 MHz
Максимальное число выводов: От 259 до 1089
Рассеиваемая мощность (nW/MHz/gate): От 6 до 100
Одной из основных отличительных особенностей технологических
платформ различных производителей является наличие и состав
библиотек IP-блоков, что и делает структурный ASIC полноценной
платформой для реализации SoC.
Возможность выполнения множества проектов на одной
технологической платформе, даже с учетом избыточности по площади (20% для
двух проектов, 50% для 5 и 100% для 10), позволяет значительно снизить
приведенную стоимость кристалла (Рис. 10.6). Авторами стоимость
расчитывалась для объемов производства 2М штук по формуле:
Приведенная стоимость чипа = Стоимость разработки/Объем
партии + Стоимость кристала.

156 Глава 10. Технологические платформы реализации SoC
он 1 1 1 1 1 1
180 nm 150 nm 130 nm 90 nm 65 nm 45 nm
——^ Custom 5 Projects, 1.5x Area
——— 2 Projects, 1.2x Area 10 Projects, 2x Area
Рис. 10.6. Стоимость кристалла для разного числа производных проектов
на одной платформе.
Отсюда видно, что даже для больших объемов производства
применение технологических платформ более чем выгодно при переходе
на новые технологические нормы. Это отражает тот факт, что
стоимость вентиля снижается (с каждым технологическим шагом число
вентилей на единицу площади удваивается при неизменной стоимости
мм2), в то время как стоимость межсоединений (стоимость масок и их
число) растет. Следовательно, избыточность по вентилям перестает
иметь существенное значение и определяющую роль начинают играть
конфигурируемые коммутационные архитектуры. Технологические
платформы являются частью этого процесса, где исследования в
области реконфигурируемых коммуникационных архитектур (RCA) и
сетевых архитектур коммутации IP-блоков также начинают обретать свое
коммерческое воплощение.

ГЛАВА 11
НЕКОТОРЫЕ
АСПЕКТЫ
ЭВОЛЮЦИИ SoC
Введение
Рассмотрим возможную эволюцию SoC в течение следующих 5-6 лет -
например к 2010-му году Конечно, почти невозможно точно
предсказать путь развития SoC на годы вперед, учитывая все изменения,
появляющиеся самым неожиданным образом в технологии, мировой
экономике, а также благодаря тесному взаимодействию потребителей и
разработчиков новых продуктов. Тем не менее, с учетом нашего предыдущего
обсуждения структурных изменений в промышленности и возможных
направлений развития методов проектирования SoC, мы можем сделать
несколько предположений и выдвинуть некоторые гипотезы о
вероятном развитии событий.
Технология System-on-Chip в основном развивается благодаря
процессу создания конечного продукта, и чаще всего это потребительские
продукты массового применения, требующие портативности, гибкости,
надежности, низкой себестоимости, большого времени жизни батареи и
богатого набора возможностей продукта. Благодаря постоянным
изменениям и инновациям в процессе проектировании продукта, можно
предположить, что технология проектирования SoC будет поддерживать
достаточно быстрое, с низким уровнем риска, инновативное
проектирование продукта, и с этой точки зрения, будущее SoC выглядит
оптимистично.
Тем не менее ясно, что ключевые цели и характеристики продуктов,
а также эволюция технологии процесса на уровне 90 нм и далее, будут
движущей силой нескольких тенденций в развитии SoC - иногда
конфликтующих, а иногда дополняющих друг друга. Кратко обсудим, как
эти тенденции повлияют на природу SoC и проектирование продукта.
Портативность и Большое Время Жизни Батареи
Носимые потребительские устройства требуют большого времени жизни
батареи для того, чтобы предоставить пользователям доступ к
современному мультимедиа без необходимости частой перезарядки или замены

158 Глава 11. Некоторые аспекты эволюции SoC
батарей. Учитывая медленный технический прогресс в улучшении
батарей, а также в поиске возможных альтернатив, таких как топливные
элементы, перед проектировщиками стоит задача поиска способов
поддержки новых методов обработки мультимедиа в таких продуктах, как
мобильные устройства 3G, без увеличения потребляемой мощности. Это, в свою
очередь, диктует требование SoC разработчикам, уделять особое
внимание понижению потребляемой мощности. Если какие-то функции
продукта известны заранее, хорошо проверены и будут часто использоваться,
ясно, что их аппаратная реализация окажет большое влияние на
снижение требуемой мощности и, таким образом, на портативность и время
жизни батареи. Аппаратная реализация конкретных функций с
оптимизированной разрядностью и оптимальным использованием базовых
блоков может привести к снижению требуемой мощности в 100 раз по
сравнению с программной реализацией, выполняемой на встроенном
процессоре. Аппаратная реализация также предполагает значительное
увеличение в производительности. Если сложный вычислительный цикл в
программе занимает 95% времени выполнения основной функции, то
замена этого цикла одно-тактовой аппаратной функцией может улучшить
производительность почти в 20 раз. Это уменьшает нагрузку на процессор
в сложном SoC устройстве, что позволяет добавить больше программных
функций - возможно уже в тот момент, когда продукт находится у
пользователя. Таким образом, потребность в портативных и долгоживущих
потребительских продуктах ведет к необходимости в SoC со
значительным объемом аппаратно реализованных функций.
Низкая Себестоимость
Требование по низкой себестоимости потребительских продуктов также
повышает интерес в аппаратно реализованных SoC. Однако они могут
быть реализованы двумя способами - заказные и полузаказные
аппаратные SoC (в форме стандартных ASIC или ASSP), или
переконфигурируемая логика, либо в виде «FPGA платформы», либо в качестве
дополнительного блока к стандартной ASIC/ASSP. Как и раньше, если эти
функции хорошо известны, проверены, имеют большое и предсказуемое
время жизни, заказная реализация или на основе стандартных ячеек
значительно снизит занимаемую площадь кристалла и требуемую мощность и,
таким образом, понизит себестоимость SoC. Однако в случае новых
функций, с изменяющимися стандартами, переконфигурируемая логика
может оказаться более привлекательной. Новые виды SoC, так
называемые «структурные ASIC», являются промежуточными вариантами по
себестоимости и производительности между заказными аппаратными
реализациями и чисто программными реализациями.

Набор Возможностей и Гибкость I
В случае функций с низкими требованиями по производительности,
не требующих значительных ограничений по мощности - например
функций управления и пользовательского интерфейса — программная
реализация может оказаться наилучшим вариантом для понижения
себестоимости SoC, так как в большей части SoC уже есть как минимум
один программируемый процессор, и добавочная флэш-память под
дополнительные программы может оказаться дешевле по сравнению с
добавлением новых аппаратных функций.
Набор Возможностей и Гибкость
Ясно, что будущие продукты на основе SoC требуют возможности
добавления новых функций по требованию, а также большей гибкости,
позволяющей конфигурирование под конкретные приложения в рамках
прикладной области. Общее желание к увеличению гибкости
конфигурирования поддерживает идею программируемых SoC и
проектирования на основе программируемых платформ. Это также поддерживает
идею добавления хотя бы небольшого количества
переконфигурируемой логики, так что продукты можно обновлять (прошивать) под новые
стандарты во время их использования, либо можно быстро
модифицировать в процессе производства, на основе переконфигурируемой или
программной логики.
Другим способом добавления гибкости к продуктам на базе SoC
может оказаться реализация многочисленных функций на базе одной SoC,
даже если еще неясно, будут ли они использоваться в конкретном
продукте - другими словами, спроектировать расширенную «платформу», в
которой неиспользуемые функции, например многочисленные
интерфейсы с шиной и внешними устройствами, можно временно отключать,
таким образом снижая потребляемую мощность. Это может привести к
немного более дорогой SoC, но при этом такая SoC будет применима к
гораздо более широкому набору конкретных продуктов в рамках
соответствующей прикладной области, нежели набор высоко
специализированных ASIC или ASSR Таким образом, экономия от больших объемов
производства и уменьшение затрат на инвестиции различных устройств
может значительно превысить незначительное повышение себестоимости
SoC. Этот аргумент также применим к добавлению дополнительных
процессоров в SoC платформу и пере-проектированию структуры
коммуникаций на чипе, с целью обеспечения больших избыточных ресурсов
производительности и коммуникаций, наличие которых облегчает
последующее создание производных проектов. В самом деле, хорошо заметна
тенденция быстрого роста сегмента много-процессорных SoC (MPSoC)
- использующих для коммуникаций большой набор различных шин

160 Глава 11. Некоторые аспекты эволюции SoC
на чипе и сетевых структур. Использование при этом конфигурируемых
процессоров также означает, что это не однородная структура
процессорных мощностей, а структура, позволяющая подгонку
вычислительных ресурсов под различные подсистемные приложения. Таким
образом, гибкость, необходимая для обогащения продукта новыми
возможностями, может обеспечиваться различными путями. Резко
возрастающие единовременные затраты на проектирование (NRE - Non-Recurrent
Engineering) на уровне 90 нм и далее также стимулируют создание SoC
проектировщиками более гибких платформ.
Надежность
В прошлом надежными проектами обычно являлись наиболее
интегрированные проекты, использовавшие самые передовые технологические
процессы, сразу после достижения этими процессами стабилизации
процента выхода годной продукции и требуемого уровня надежности
чипа. Однако уравнение надежности может измениться в будущем,
благодаря изменениям в сложности технологии, новым проектным
проблемам на уровне менее 100 нм и единовременным затратам
проектирования специализированных чипов на уровне современных
технологических процессов. Интеграция на уровне единственного чипа уже может
оказаться не самой низкой по себестоимости, не самым надежным
способом реализации функциональности продукта - вместо этого более
привлекательными может оказаться интеграция на уровне корпуса
(System-in-Package) или гибридные решения, в которых цифровые,
аналоговые и RF компоненты производятся с помощью разных
высоко-оптимизированных и надежных процессов, а не в рамках одной
интегрированной многофункциональной технологии. Вдобавок к этому, одним из
способов надежного производства продуктов является использование
хорошо проверенных SoC платформ с максимальной программной
составляющей, что позволяет корректировать ошибки во время
эксплуатации продукта или на последних стадиях производства.
Быстрый Процесс Разработки с Низким Риском
Ясно, что для ускорения проектирования сложных SoC и поддержания
при этом низкого уровня риска — с целью достижения максимальной
вероятности того, что полученная SoC будет работать и будет полезна для
соответствующих приложений - ключевым является понятие
повторного использования. Как мы уже видели, наибольший эффект при
повторном использовании достигается при работе со сложными
программируемыми платформами, ориентированными на данную прикладную
область. В этом случае, максимальное использование программ и перекон-

Эволюция Технологических Процессов I
фигурируемой логики позволяет понизить риск проектирования, и
одним из способов значительного уменьшения риска проектирования
чипа является сочетание много-процессорной системы на платформе чипа
и коммуникационных сетей с большой пропускной способностью.
Наиболее сложные ориентированные на приложение платформы,
сопровождаемые обширными программными библиотеками, программным
IP и большим выбором периферийных компонент, предоставляют
большой набор возможностей по быстрому созданию проекта, хотя и по
более высокой цене, чем в случае полностью специализированной
платформы. В этом контексте проблемой является не только ускорение
сложного процесса SoC проектирования, необходимо учитывать общие
единовременные затраты (NRE) на проектирование SoC до получения
рабочего образца. Использование платформ может понизить
единовременные затраты в 10-ть и более раз.
Эволюция Технологических Процессов
Постоянная эволюция технологических процессов от 130 нм к 90 нм, 65
нм, 45 нм и далее приводит к постоянному давлению на SoC
разработчиков, подвергающихся конфликтующим воздействиям. Эта эволюция
также оказывает ключевое влияние на полупроводниковую экономику.
С одной стороны, высокие единовременные затраты при использовании
передовых процессов, довольно медленная адаптация этих процессов
(как минимум три года, в соответствии с IRTS, что означает
значительное повышение по сравнению с двухлетним сроком несколько лет
назад), влияющая на скорость освоения процесса, а также большое число
фабрик, работающих со старыми процессами, могут означать, что
наиболее низкими по себестоимости для большинства ориентированных на
потребителей SoC будут процессы на уровне 180, 150 и 130 нм. Такое
положение дел может сохраняться несколько лет, еще больше усиливая
тенденцию к снижению числа новых проектов на основе передовых
процессов и замедлению изучения таких процессов. Поэтому мы можем
увидеть продолжение замедления в переходе на передовые процессы и
продолжение использования старых процессов в случае многих SoC
проектов. Проектный «разрыв» в производительности
проектировщиков, описанный IRTS, также будет поощрять использование старых
технологий, если не увеличивать практику повторного использования с
помощью платформ.
Другим последствием высокой стоимости новых цифровых 1С
процессов на уровне 100 нм и менее может стать снижение уровня
интеграции новых SoC - отказ от попытки интеграции различных технологий на
общей кремниевой подложке. Так как себестоимость является основным

162 Глава 11. Некоторые аспекты эволюции SoC
фактором для потребительских SoC, может усиливаться тенденция к
производству отдельных чипов по соответствующей наиболее
эффективной технологии, а затем их интеграции в едином гибридном корпусе
(System-in-Package). Это зависит как от цены, так и от возможности
разделения системы на несколько компонентов с минимальным
количеством межсоединений, позволяющим эффективное применение такого
подхода.
Выводы
Мы обсудили ряд факторов, которые будут влиять на эволюцию SoC
в будущем. Хотя многие из них дополняют друг друга, также можно
выделить и конфликтующие тенденции. Ниже приведены наиболее
вероятные (на наш взгляд) предсказания о возможной эволюции SoC:
1. SoC уже можно программировать с помощью встроенных
процессоров, и важность этого только будет расти с увеличением числа
процессоров (MPSoC), от 1-го до 5-ти, 10-ти и далее.
2. Роль конфигурируемых процессоров, позволяющих
конфигурирование под конкретное приложение или подсистему, будет и дальше
увеличиваться, они могут вскоре почти полностью заменить стандартные
встроенные DSR Одним из способов снижения требуемой мощности
SoC будет добавление высоко-оптимизированных инструкций и
оптимизация разрядности, с сохранением возможности
перепрограммирования.
3. Переконфигурируемые платформы станут более популярны в
конкретных прикладных областях, где их процессорные мощности и
возможности по переконфигурированию логики будут соответствовать
требованиям по себестоимости и производительности. С увеличением
единовременных затрат на специализированные SoC, описанная выше
область использования будет только расти и охватывать все большее
количество приложений. Однако SoC с наивысшей производительностью,
наинизшей себестоимостью и требуемой мощностью будут по прежнему
проектироваться на основе заказной и полузаказной логики
4. Структурные ASIC, объединяющие возможность «медленного
переконфигурирования» (на основе программирования фотошаблонов
металлизации) с преимуществами специализированной логики для
процессоров и памяти, и небольшим количеством ориентированных на
приложение блоков, займут заметную часть рынка и станут интересной SoC
альтернативой в случае некоторых приложений, но не смогут вытеснить
ни переконфигурируемые, ни специализированные платформы. Однако
традиционные ASIC (mil mask-set) скорее всего будут в основном
заменены структурными ASIC.

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

Приложение №1
Маршрут проектирования
цифровых
и аналого-цифровых СБИС
I. Общая структура маршрута проектирования
Данный маршрут проектирования регламентирует процесс разработки
сложных СБИС, в том числе и «систем на кристалле».
Общая структура маршрута проектирования представлена на
рисунке 1.
Системный уровень является обязательной частью маршрута
проектирования СБИС. Задачи системного уровня должны быть решены
разработчиками радиоэлектронной аппаратуры и систем, которые
являются заказчиками специализированных СБИС, в том числе «систем на
кристалле» (SoC). На системном уровне решаются следующие задачи:
1. Создается и анализируется высокоуровневая поведенческая
модель всей системы, включая приемно-передающие тракты, каналы связи
и т.п.
2. Выбирается макроархитектура будущей СБИС: программируемые
IP-ядра, шины, контроллеры, память и т.д. Этот этап работ, как правило,
выполняется совместно представителями заказчика и разработчика
СБИС. Также при необходимости здесь производится декомпозиция на
программную и аппаратную составляющие.
3. Разрабатываются спецификации на проектирование СБИС
целиком и отдельных блоков.
Более подробно процесс системно-функционального
проектирования изложен в главе II настоящего документа.
Основой для разработки СБИС является комплект договорных
документов, включая согласованное техническое задание (ТЗ). В состав ТЗ
входят подробные технические спецификации на разработку СБИС.
СБИС может включать в себя аналоговые блоки, цифро-аналоговые
блоки (AMS), цифровые блоки — аппаратная часть (HW) и программную
часть в виде встраиваемого программного обеспечения (ПО). Проекти-

Маршрут проектирования цифровых и аналого-цифровых СБИС
Системный уровень:
создание поведенческой модели;
выбор архитектуры и разбиение HW/SW;
подготовка спецификаций.
HD
Спецификации
ОН
Проектирование
аналоговых и
цифро-аналоговых
блоков
Разработка
встраиваемого
программного
обеспечения
нэ
Проектирование
цифровой части
СБИС
Системная интеграция
Топология
Тесты
Т
Список цепей
J
ИЗ) HD
У Т
На производство СБИС
Рис 1. Общая структура маршрута проектирования
рование AMS и HW рассмотрено в данном документе в разделах III и IV
соответственно. Порядок разработки и отладки встраиваемого ПО
настоящим документом не определяется.
Системная интеграция — это объединение проектной информации
по всем аппаратным блокам и программным составляющим в единый
комплект документации для передачи на производство. Здесь же
происходит программно-аппаратная верификация, задача которой проверить,
насколько корректно работают совместно все составляющие системы на
кристалле: цифровые блоки, аналоговые блоки, ВЧ-тракты и
разработанное ПО.
Проектирование СБИС начинается в точке «1» с получения и
анализа спецификаций, а заканчивается передачей списка цепей, тестов
и/или топологии на производство СБИС (точки «4» и «5»).

166 Приложение Ml
II. Системный уровень проектирования
Процесс разработки должен начинаться с идентификации целей и задач
выполняемых проектируемой системы. На начальном этапе следует
определить основные эксплуатационно-технические свойства: требуемое
быстродействие, допустимую потребляемую мощность, время,
необходимое для разработки, и т.п. На основании этих свойств создается
системная спецификация, которая может выступать частью технического
задания на разработку системы. Как правило, этот этап выполняется без
применения специализированных программных средств САПР.
На следующем этапе необходимо создать высокоуровневую
поведенческую модель всей разрабатываемой системы. Эта задача решается с
использованием программного пакета Incisive(TM) Signal Processing
Worksystem (SPW) - продукт фирмы Cadence Design Systems.
Поведенческая модель системы формируется в виде блок-схемы в графическом
редакторе Block Diagram Editor и может включать в себя следующие типы
блоков:
а) элементы из основной библиотеки SPW;
б) элементы из дополнительных библиотек SPW;
в) высокоуровневые модели IP-блоков;
г) блоки, описанные на языках программирования С, C++;
д) блоки, описанные на языках VHDL, Verilog, SystemC;
е) математические модели в формате программного пакета MATLAB
(М-файлы и МЕХ-файлы).
Сформированная поведенческая модель сохраняется в библиотеке
SPW в виде отдельного схемного символа, который имеет свое название,
графическое представление и порты для ввода и вывода данных.
Для верификации разработанной поведенческой модели
необходимо создать тестовое окружение (Testbench) системы. Кроме символа
системы тестовое окружение, как правило, включает в себя генераторы
входных сигналов и блоки отображения выходной информации. Блоки
генерации и отображения сигналов могут быть выбраны из основной
или дополнительной библиотеки SPW. Необходимо, чтобы тестовое
окружение позволяло полностью верифицировать функционирование
системы.
Верификация разработанной поведенческой модели должна
осуществляться путем компьютерного моделирования с использованием SPW.
Если в процессе верификации обнаружены какие-либо отклонения от
требований системной спецификации, то следует скорректировать
поведенческую модель и повторить моделирование.
СБИС типа система на кристалле может включать в себя одно или
несколько программируемых процессорных ядер. Разработчик должен

Маршрут проектирования цифровых и аналого-цифровых СБИС I
принять решение о том, какие блоки поведенческой модели будут в
последствии реализованы на аппаратном уровне, а какие - на
программном в виде встроенного в СБИС программного обеспечения.
В итоге требуется, чтобы были получены спецификации на
разработку программного обеспечения и отдельно на разработку каждого ап-
паратно реализуемого блока.
Разработка алгоритма функционирования может выполняться
автоматизированными средствами SPW и HDS (Hardware Design System -
продукт фирмы Cadence, полное название - «Incisive(TM) SPW Links to
Implementation») в следующем порядке.
Сначала разрабатывается и верифицируется алгоритм работы блока,
построенный из элементов функционирующих с точностью до
плавающей десятичной запятой (floating point). Здесь разрешается использовать
только элементы библиотек SPW.
На следующем шаге в блок-схеме алгоритма следует заменить
элементы типа floating point на элементы, функционирующие с точностью
до фиксированного количества знаков после десятичной запятой (fixed
point), из библиотеки HDS. Для тех элементов floating point, которые не
имеют аналогов в библиотеке HDS, должны быть созданы
иерархические структурные описание. На промежуточных стадиях перехода
допускается одновременное использование элементов как floating point, так и
fixed point. В результате все элементы должны быть только типа fixed
point.
Для алгоритма на уровне элементов с фиксированной запятой
необходимо установить разрядность блоков. Следует учитывать, что
уменьшение разрядности приводит к снижению точности вычислений, а
увеличение - в сильной степени затрудняет последующую реализацию
СБИС на логическом и физическом уровнях.
На следующем этапе разработчик формирует архитектуру блока. Т.е.
алгоритмической модели на уровне операций ставится в соответствие
архитектурная модель на уровне логических элементов из библиотеки
HDS. При помощи программных инструментов HDS из описания
системы на уровне блоков аппаратной архитектуры производится
генерация в описание уровня регистровых передач - RTL. Генерация
выполняется в автоматизированном режиме под управлением разработчика.
На выходе должно быть получено RTL-описание на языках VHDL или
Verilog.
III. Проектирование цифровой части СБИС
Блок-схема маршрута проектирования цифровой части СБИС
представлена на рисунке 2.

68 Приложение №1
Встраиваемое ПО
Вставка структур
для тестирования
Вентильное
моделирование
Список цепей
Спецификации
Формальный
контроль RTL-кода! *
h®
Разработка
RTL-описаний
4 Модел-иеи Ш
верификация RTL
Логический Li-
синтез
Вентильная Ш
Библ-ки
RTL-
\моделей
Библ-ка

производителей
СБИС
Статический
f верификация Т ; временной анализ
Физический Ш|
синтез
Библ-ка

производителей
СБИС
Верификация 1Ж
топологии
Генерация
тестов
Топология
Тесты
Рис. 2. Маршрут проектирования цифровой части СБИС
1. RTL-кодирование - разработка функционального описания
блока на языках VHDL или Verilog - может выполняться как в ручном, так и
в автоматизированном режимах. Процесс автоматизированной
разработки RTL-кода изложен в разделе II «Системный уровень
проектирования». Используемые программные средства:
- Incisive(TM) Signal Processing Worksystem (SPW2000) - основное
средство для разработки высокоуровневых описаний;
- Incisive(TM) SPW Links to Implementation (HDS2000) - набор
инструментов для автоматизированного создания RTL-описаний;
- Incisive(TM) SPW Communication Library (COMFLT) - библиотека
RTL-моделей;
- Verilog(R) Desktop Simulator (28250) - ПО для моделирования Verilog
описаний;

Маршрут проектирования цифровых и аналого-цифровых СБИС I
- Cadence(R) NC-Sim Mixed-Language Simulator (28000) - ПО для
моделирования Verilog и VHDL описаний.
2. Для моделирования используется тот же набор программных
средств, что и при RTL-кодировании.
Совместное моделирование программной и аппаратной частей
возможно только в среде SPW2000.
3. Логический синтез - процесс автоматизированного создания
электрической (логической) схемы на базе RTL-описания и библиотек
элементов логического уровня от производителя СБИС. Основным
программным средством логического синтеза является BuildGates:
- BuildGates(R) Synthesis (BG100);
- Cadence(R) Datapath Synthesis Option (80100);
- Cadence(R) Low-Power Synthesis Option (80200).
4. Вентильная верификация обычно сводится к статическому
временному анализу списка цепей, полученному в результате логического
синтеза (программный пакет Pearl). В отдельных случаях, когда
размерность списка цепей невелика, можно выполнять моделирование на
вентильном уровне (NC-Sim). Перечень соответствующих программных
средств:
- Pearl(R) Timing Analyzer (32710);
- Verilog(R) Desktop Simulator (28250);
- Cadence(R) NC-Sim Mixed-Language Simulator (28000).
Для реализации этапов «5» и «6» маршрута проектирования высоко-
интегрированных СБИС, в том числе СнК, изготавливаемых по
технологиям «глубокого субмикрона» необходимо специализированное
программное обеспечения такое, как SoC Encounter, NanoRouter и т.п. Для
остальных схем можно использовать следующее ПО:
- Virtuoso(R) STREAM interface (960);
- Cadence (R) chip assembly router (3300);
- Virtuoso(R) compactor (305);
- Assura(TM) design rule checker (72110);
- Assura(TM) layout vs. schematic verifier (72120);
- Assura(TM) parasitic extractor (72130).
На выходе маршрута (рис. 2) должны быть представлены: список
цепей (EDIF, Verilog или VHDL), производственные тесты и/или
топология в формате GDSII.
IV. Проектирование аналоговых
и цифро-аналоговых блоков
Блок-схема маршрута проектирования аналоговых и цифро-аналоговых
блоков представлена на рисунке 3.

170 Приложение №1
Спецификации
<$н
GDSII
Разработка
*|> электрической
схемы
ш
Разработка
топологии
ш
EDIF
Щ
Моделирование
Верификация
га
Подготовка kl
интеграции
Топология, тесты,
список цепей.
Рис. 3. Маршрут проектирования цифровой части СБИС
Исходными данными для проектирования являются технические
спецификации на аналоговый или цифро-аналоговый блок.
1. Процесс начинается с разработки и ввода в базу данных DFII
электрической схемы. Для этого могут использоваться следующие
программные пакеты:
- Virtuoso(R) schematic composer (34500) - схемный редактор;
- Cadence(R) analog design environment (34510) - набор инструментов
для разработки аналоговых схем
- Virtuoso(R) schematic composer VHDL/Verilog interface (21060/21400);
- Virtuoso(R) EDIF 200 reader (940) - для трансляции имеющихся
готовых схемных решений из EDIF-описания в DFII.
2. В зависимости от типа блока (аналоговый, ВЧ или AMS) для
моделирования электрической схемы можно использовать следующее ПО:

Маршрут проектирования цифровых и аналого-цифровых СБИС 171
- Spectre(R) circuit simulator (32500) — Spice-моделирование;
- Spectre(R) RF simulation option (32520) - ВЧ-опция для 32500;
- Cadence (R) NC-Sim Mixed-Language Simulator (28000) -
моделирование Verilog, VHDL;
- Verilog (R) Desktop Simulator (28250) - моделирование только
Verilog-кода.
Для корректного функционирования 28000 и 28250 в составе
редактора 34500 необходимо наличие установленных лицензий 21060/21400.
3. Проектирование топологии аналоговых и цифро-аналоговых
блоков происходит, как правило, в ручном режиме (Full Custom) с
использованием специализированного ПО:
- Virtuoso(R) XL layout editor (3000) - топологический редактор для
разработки Full Custom блоков;
- Virtuoso(R) schematic layout option (302) - опция для 3000 позволяет
организовать непосредственное взаимодействие между топологией
и схемой в 34500;
- Virtuoso(R) STREAM interface (960) - транслятор GDSII^DFII;
- Cadence (R) chip assembly router (3300) - комплект средств для
автоматизированного решения задач физического синтеза (планировка,
размещение, трассировка);
- Virtuoso(R) compactor (305) - средство для оптимизация полученной
топологии.
4. Процедура верификации топологии выполняется в три стадии:
контроль технологических норм, проверка на соответствие тогологии
исходной схеме, экстракция паразитных элементов и последующее
моделирование. Для решений этих задач используется пакет Assura:
- Assura(TM) design rule checker (72110);
- Assura(TM) layout vs. schematic verifier (72120);
- Assura(TM) parasitic extractor (72130);
- Assura(TM) graphical user interface option (72140).
5. Процедура подготовки блока к интеграции в большой степени
зависит от специфики всей разрабатываемой СБИС и технологии ее
изготовления. Часто сюда входит добавление в топологию специальных
экранирующих областей для защиты от «сильношумящей» цифровой
части, добавление в топологию технологических символов и т.д.
На выходе маршрута (рис. 2) должны быть получены: топология
(GDSII или DFII), список цепей (EDIF, Verilog, VHDL, DFII) и
производственные тесты.

Перечень программного обеспечения
72110:
72120:
72130:
72140:
32710:
21060
21400
305
34500
34510
940
3000
302
32120
32500:
32520:
3300:
28250:
28000:
BG100:
80100:
80200:
Assura(TM) Design Rule Checker [3.0])
Assura(TM) Layout Vs. Schematic Verifier [3.0])
Assura(TM) Parasitic Extractor [3.0])
Assura(TM) Graphical User Interface Option [3.0])
Pearl(R) Timing Analyzer [4.3])
Virtuoso(R) Schematic Composer VHDL Interface [DFW 4.4.3])
Virtuoso(R) Schematic Composer Verilog(R) Interface [DFW4.4.3])
Virtuoso(R) Compactor [DFW 4.4.3])
Virtuoso(R) Schematic Composer [DFW 4.4.5])
Cadence(R) Analog Design Environment [DFW 4.4.5])
Virtuoso(R) EDIF 200 Reader [DFW 4.4.3])
Virtuoso(R)-XL Layout Editor [5.0])
Virtuoso(R) Schematic Layout Option [5.0])
Cadence(R) Electronic Design for Manufacturability Option [5.0])
Spectre(R) Circuit Simulator [5.0])
Spectre(R)-RF Simulation Option [5.0])
Cadence(R) Chip Assembly Router [11.0])
Verilog(R) Desktop Simulator [3.2])
Cadence(R) NC-Sim Mixed-Language Simulator [3.4])
BuildGates(R) Synthesis [4.0])
Cadence(R) Datapath Synthesis Option [5.0])
Cadence(R) Low-Power Synthesis Option [5.0])
COMFLT: (Incisive(TM) SPW Communication Library [4.8])
HDS2000: (Incisive(TM) SPW Links to Implementation [4.8])
SPW2000: (Incisive(TM) Signal Processing Worksystem [4.8])

Приложение №2
Платформы и платформенное
проектирование.
(Подходы VSIA, определения,
типы платформ,приложения).
Введение
Когда в 1996-м году организация VSIA (Virtual Socket Interface Alliance)
начала продвигать IP блоки или повторное использование виртуальных
компонентов (VC), самые сложные чипы были на уровне одного
миллиона вентилей. Если каждый VC компонент состоит из 50,000 вентилей,
то в этом случае нужно интегрировать 20 блоков. Сегодня чипы могут
состоять из 40 млн. вентилей, или около 800 блоков для интегрирования.
Но это только небольшая часть проблемы. Шесть лет назад чип еще был
компонентом системы, в то время как чипы следующего поколения
сами являются системами, со сложными подсистемами коммуникаций,
несколькими процессорами и многочисленным встроенным
программным обеспечением.
Даже в случае простого повторного использования блоков или VC
компонентов задача создания и интеграции такой сложной системы
очень трудоемка и требует много времени. Необходимо написать
программное обеспечение и интегрировать его со все более сложной
аппаратной частью, а один кремниевый прототип может стоить более
миллиона долларов только за фотошаблоны (masks) в случае процесса на
уровне 0.13 микрон или менее. Исторически аппаратная часть
проектировалась, создавалась и отлаживалась до создания соответствующего
программного обеспечения. Теперь, когда в SoC схемах аппаратная и
программная часть близки по сложности, традиционная методология
последовательного проектирования требует слишком много времени.
К счастью, промышленность начинает замечать, что для создания
похожих продуктов с похожими рынками сбыта требуются похожие
компоненты и архитектуры, что ведет к распространению
Проектирования на Основе Платформ. Платформенное проектирование встроенных

174 Приложение №2
систем может облегчить решение многих проблем, и оно применимо на
многих уровнях процесса создания продукта.
Что Такое Платформенное Проектирование SoC?
Это организованный метод снижения требуемого времени и возможных
рисков при проектировании и верификации сложной SoC схемы, с
помощью обширного повторного использования наборов аппаратного и
программного IP. Вместо блочного подхода к повторному
использованию IP платформенное проектирование собирает группы.компонентов
в многократно используемую платформенную архитектуру. Эти
архитектуры затем используются в качестве основы для проектирования
вторичных SoC проектов; так как эти архитектуры уже спроектированы и
верифицированы а также, возможно, конфигурируемы, их можно
быстро адаптировать к новому вторичному проекту и сэкономить на
времени проектирования (а также значительно снизить риски). Так как ни
одна платформенная архитектура и набор компонентов не могут охватить
все области проектирования, все платформы ориентированы на
конкретную прикладную область.
Например, можно взять ARM процессор, высокопроизводительную
шину AMBA, DMA контроллер, интерфейсы с памятью и с внешней
шиной, вместе с традиционным набором основных программных
средств (редактор, компилятор, отладчик и ассемблер), и на основе
всего этого создать процессорную подсистему, или «платформу,
ориентированную на процессор», которая затем может использоваться в большом
количестве вторичных SoC проектов. Далее, добавляя DSP процессор и
соответствующую ему подсистему, интерфейс между процессорными
подсистемами, а также средства программирования DSP и пару
аппаратных блоков, получаем платформу, ориентированную на прикладную
область беспроводной связи 2.5G и 3G. Такая платформа, «полностью
содержащая приложение», еще больше поможет при создании SoC
мобильного телефона или PDA - но она потребует больше начальных
затрат (на ее создание), и применима к более узкой прикладной области
нежели описанная выше процессорно-ориентированная платформа.
Проектирование на базе платформ уже реально используется в
промышленности. Ведущие компании, такие как Intel (платформа XScale
для PDA), ARM (платформа PrimeXSys), TI (ОМАР), Motorola
(DragonBall для PDA, Smart Networks для проводных систем
коммуникаций, и Innovative Convergence для мобильных телефонов), Xilinx
(платформенные FPGA, такие как Vertex II Pro), Philips (Nexperia для
приложений по работе с цифровой видеоинформацией) используют
платформы для различных приложений. Вопрос сейчас заключается не в том,

Платформы и платформенное проектирование I
подходит ли платформенное проектирование для различных
прикладных областей SoC, а в конкретных ограничениях и компромиссах и в
том, как лучше поддержать этот стиль проектирования стандартами по
повторному использованию аппаратного и программного IP.
Подход VSIA к Платформенному Проектированию
Сейчас многие считают, что платформенное проектирование очень
перспективно, и тем не менее в промышленности нет хорошо понятного и
точного определения того, что такое платформа, и как можно ее
спроектировать. Многие компании традиционно использовали подходы снизу-
вверх или ориентированные на процессор, когда они интегрируют
хорошо понятные аппаратные компоненты или IP блоки для построения
продуктов в конкретных прикладных областях. Хотя этот модульный
подход был успешным, он ограничен в масштабах и его использование
усложняется в случае увеличения и усложнения требуемых SoC и систем.
Мы начнем с трех основных положений:
• Индустрия встроенных систем может уменьшить риск, затраты и время
проектирования, а также увеличить доходы за счет применения
принципов платформенного проектирования для семейств продуктов.
• В настоящее время не существует стандарта, воспроизводимой
методологии или подхода к определению, спецификации и
повторному использованию платформы, или к заданию зависимостей между
аппаратными и программными VC компонентами, которые могли
бы использоваться на разных уровнях абстракции или интеграции
продукта.
• То, что сегодня платформа - завтра становится компонентом!
Мы предлагаем использование иерархического подхода на основе
интеграционных платформ [1]: На любом уровне абстракции (или
реализации), общие аппаратные или программные функциональные
компоненты интегрируются в единую повторно используемую сущность -
платформу - которая далее интегрируется с дополнительными
компонентами для создания нескольких систем более высокого уровня. В этой
схеме платформы содержат наиболее общие элементы на конкретном
уровне интеграции внутри системы или продукта.
Понятия семейств продуктов, интеграционных платформ а также
управления общими и изменяющимися (дифференцирующими)
свойствами находят все более широкое признание в программном сообществе
в виде линеек программных продуктов (SPL - software product lines) [2].
Многие проблемы, стоящие перед SoC, описываются в SPL литературе.
Этот подход полностью масштабируем, так что проектировщики SoC

176 Приложение №2
могут воспользоваться преимуществами понимания платформенного
проектирования семейства продуктов на всех уровнях интеграции для
любой технологии, продукта или прикладной области.
На рисунке 1 отображена возможная иерархия интеграции для SoC
платформ, состоящая из базовых (core) платформ и SoC. Здесь наиболее
фундаментальными являются базовые платформы: в иерархии нет
платформ более низкого уровня. Базовые платформы могут создаваться в
рамках вертикального маршрута создания продукта, либо независимыми
разработчиками как независимые VC компоненты. Команды
проектирования на уровне SoC будут использовать ориентированный на
интеграцию маршрут проектирования для соединения базовых платформ с
конкретными аппаратными и программными компонентами на чипе (из
прикладной области или ориентированных на данный рынок) для
создания семейства SoC платформ. И наконец, заказчики данного SoC
поставщика интегрируют SoC платформы с их конкретной
специализированной функциональностью за пределами чипа для создания продуктов,
которые в свою очередь могут быть интегрированы на еще более высоких
уровнях. Для успешной интеграции на каждом уровне требуются
соответствующие ориентированные на интеграцию маршруты
проектирования, дополнительная интеллектуальная собственность, средства
проектирования и поддержка.
На основе этого мы предлагаем следующие определения:
Платформа: Платформа содержит общий, интегрированный и
управляемый набор особенностей, на основе которых можно построить
набор продуктов или семейство продуктов. В контексте SoC это
библиотека виртуальных компонентов и архитектурная структура, состоящие из
набора интегрированных и предварительно квалифицированных
программных и аппаратных VC компонентов, моделей, EDA и программных
средств, библиотек и методологии, способных обеспечить быструю
разработку продукта на основе исследования архитектурного пространства,
интеграции и верификации.
Платформенное Проектирование: Подход к проектированию,
ориентированный на интеграцию и подчеркнуто систематическое повторное
использование, предназначенный для создания сложных продуктов на
основе платформ и совместимых аппаратных и программных VC
компонентов, а также снижения рисков, затрат и времени на разработку.
Преимущества Платформенного Проектирования
Платформенное проектирование способствует быстрому созданию
вторичных продуктов с помощью систематического повторного
использования верифицированных компонентов, что приводит к значительному

Платформы и платформенное проектирование 177
StaiFidaordi Modules
Computing
Complex
Modules & Peripherals
Core
Platform
■ iii.«,.,...,.iiiiiiiim
г—~—
Modules & Peripherals
няпняпяопюшяшаи
Ш M, Ш,Щ„_М Ml Ю.Д1 «1 ■ ■ И ,H,
Modules & Peripherals
Рис 1. Основные платформы и семейства SoC продуктов.
сокращению времени проектирования и повышению возможной
прибыли. Основное правило применимо независимо от уровня интеграции:
проектировщик, интегрирующий платформу в систему более высокого
уровня или продукт, использует полностью верифицированную и
характеризованную подсистему.
На рисунке 2 приведены ожидаемые затраты в случае
платформенного подхода к созданию семейства продуктов по сравнению с
традиционным способом создания каждого продукта в отдельности: хотя в
случае платформенного подхода требуется больше усилий на начальном
этапе (для создания семейства), общие затраты на создание всего
семейства значительно меньше.
Effort
5 в
Pr°ducfbneMember
Product Family Appoach
Traditional One-At-A-Time Approach
7
8
Рис 2. Затраты на создание последовательных продуктов в обычном
случае и в случае семейств продуктов.

178 Приложение №2
К некоторым другим преимуществам платформенного
проектирования относятся:
• Уменьшение рисков в случае хорошо характеризованной
платформы, так как вторичный продукт в области применимости
платформы имеет высокую вероятность успеха.
• Проектирование на основе интерфейсов (с упором на заданные
шины, программные сервисы и API) способствует проектированию и
реализации на более абстрактном уровне.
• Спланированное повторное использование приводит к очень
высокой продуктивности и большой гибкости в удовлетворении
требований заказчика.
• Проекты могут быть составлены из различных специализированных
функций из разных источников, включая лицензионное IP, от
внешних компаний.
• Модульное проектирование способствует иерархической
трассировке чипа и расчету временных задержек, уменьшая сложность
проектирования.
• Используются общие стратегии для много-процессорного
системного проектирования, отладки и тестирования на основе стандартных
интерфейсов.
• Вторичные продукты, основанные на платформе, требуют меньше
затрат на верификацию.
• Многократное повторное использование блоков позволяет
амортизировать стоимость разработки и достичь более оптимального
блочного проектирования.
• Маршруты проектирования продуктов и платформ становятся
эффективными средствами учета возможных будущих требований заказчика.
• Затраты можно распределить между различными продуктами сектора.
Учитывая все эти преимущества, мы также должны понимать, для
чего не предназначены платформенное проектирование и семейства
продуктов [2]:
• Случайное частичное повторное использование (платформенное
проектирование направлено на всестороннее, спланированное и
прибыльное повторное использование).
• Создание одной системы с повторным использованием (линейка
продуктов рассматривается как одно целое, а не как одиночные
вторичные продукты «платформенного продукта»).
• Разработка только на основе компонентов (платформенное
проектирование подчеркивает управление общими и уникальными
особенностями внутри архитектуры семейства продуктов).
• Только пере-конфигурируемая архитектура (архитектура платформы
является только одной из управляемых особенностей).

Платформы и платформенное проектирование 179
• Реализация единственного продукта (платформенное
проектирование рассчитано на разработку и поддержку нескольких членов
семейства продуктов на данном рынке).
Компоненты Платформы
Наше определение отражает наше понимание того, чем должна быть
успешная платформа. Если платформа не готова к интеграции в систему
более высокого уровня, то на наш взгляд это еще незаконченная
платформа. Платформенное проектирование должно подчеркивать
самосогласованность в интеграции и архитектуре.
Ниже приведены некоторые базовые утверждения о платформах и
платформенном проектировании:
• Для каждого семейства продуктов существуют наборы общих
функциональных компонентов (т.е. платформы), которые могут
послужить основой нескольких вторичных SoC продуктов.
• Платформенное проектирование зависит от существования:
- заданных и верифицированных платформ
- интегрируемых IP компонентов, ориентированных на
соответствующий рынок
- ориентированного на интеграцию маршрута проектирования
- поддержки средств, приложений и систем
• Экономическое преимущество при создании вторичных продуктов
будет реализовано за счет:
- улучшения возможностей продукта
- уменьшения времени разработки
- повышения прибыли
- повышения качества
• Экономические выгоды будут достаточно велики для компенсации
первоначальных затрат на создание платформ, дополнительного IP,
средств поддержки.
• Платформа на любом уровне существует в виде черного ящика,
(отношение к платформам как к черным ящикам с возможностью
повторного использования является важным принципом
платформенного проектирования;).
Платформы должны иметь:
• реальную реализацию (интегрированный и верифицированный
набор аппаратных и программных функциональных компонентов);
• заданное и полное архитектурное описание (возможно на основе
ранее созданной реализации);
• полный и точный набор моделей, описывающих ее реальное поведение

180 Приложение №2
(может перекрываться с архитектурным описанием, либо
архитектурное описание может описывать больше моделей, чем существует
на данный момент);
• набор средств и методологию интегрирования платформенной
модели в модель системы более высокого уровня;
• набор средств и методологию интегрирования платформенной
реализации в реализацию системы более высокого уровня.
Мы уже немного рассказывали об уровнях реализации и
абстракции, а также о том, насколько важна возможность интеграции
платформы в проект более высокого уровня. Перечислим еще раз те вещи,
которые на наш взгляд важны для реализаций, средств и моделей: Во-
первых, платформа - это черный ящик. В противном случае
разработчики могут попытаться оптимизировать содержимое платформы,
отказываясь таким образом от многих преимуществ систематического
повторного использования, интеграции и верификации, связанных с
платформенным проектированием. Важно помнить о том, что
платформенное проектирование не связано с оптимизацией реализации,
оно направлено на использование подходящей реализации для
снижения времени разработки, рисков, затрат, и повышения качества и
доходов. В платформенном проектировании лучшее - определенно враг
хорошего.
Очевидно, что реализация необходима, но также необходимо и
архитектурное описание, если мы собираемся достичь архитектурной
самосогласованности в рамках всей системы или продукта, созданного на
основе платформы.
Другой ключевой частью являются модели. Они описывают
реальное поведение и позволяют проектной и производственной командам
использовать платформу. Мы не знаем точно, какие модели
потребуются, но думаем, что должны быть способны задать стандартный набор -
на основе стандартных, общих взглядов - для каждого типа платформ,
которые обсуждались нами ранее.
И наконец, сложной задачей является создание вспомогательных
средств для построения моделей и реализаций более высокого уровня. С
одной стороны необходимо, а с другой очень тяжело сделать доступным
все вместе - реализации, модели и вспомогательные средства.
Быстрая разработка продукта хотя и уменьшает риск, затраты и
время разработки SoC, но требует первоначального понимания семейства
продуктов более высокого уровня, в которые будет интегрироваться
данная SoC. Это позволяет нам задать набор систем — SoC, и продуктов,
для которых они предназначены - которые обладают общим набором
особенностей и могут быть созданы на базе общего набора IP блоков.

Платформы и платформенное проектирование 181
Как только задано семейство продуктов, можно далее параллельно
разрабатывать общие аппаратные и программные особенности
интеграционной платформы и уникальные аппаратные и программные VC
компоненты на каждом уровне, на основе соответствующей архитектуры
продукта и платформы. Разработка продукта, называемая также
«вторичное проектирование», сводится далее в основном к интеграции,
фокусируясь на использовании (а не переделывании) заданных платформ и
уникального IP.
С одной стороны вторичный проект потребует совершенно новый
набор средств анализа для того, чтобы быстро детализировать
выбранную платформу, а существующие программные компоненты должны
быть улучшены с расчетом на новую методологию. Однако с другой
стороны, зависимости между спецификацией продукта, архитектурой,
разбиением и маршрутами разработки аппаратной-программной части не
требуют полностью интегрированных вспомогательных средств.
Требуются только тщательно спланированные связи между отдельными
наборами средств, на основе абстракций и моделей.
Типы Платформ
Существует ясное различие между двумя типами платформ в
проектировании SoC: технологические платформы («ориентированные на технологии»)
и прикладные платформы («ориентированные на приложение») (рис. 3).
Рис. 3. Технология и прикладные платформы.

182 Приложение №2
Они в некоторой степени соответствуют определениям платформы
«реализации» и «архитектурной» платформы, обсуждавшимся центром
Gicascale Silicon Research Centre (GSRC) для платформенного
проектирования [3].
Ориентированная на технологии платформа SoC - это подход
снизу-вверх к проектированию и использованию SoC, платформа
обновляется в таких случаях, как появление новой проектной особенности или
технологического процесса. Например, расширение набора инструкций
вычислительного ядра, появление новой технологии изготовления
памяти, или переход к новому технологическому процессу (переход от 180
к 130 нм, и далее ожидаемый переход к 90 и 65 нм), все эти события
приводят к созданию новых технологических платформ.
В противоположность этому, ориентированные на приложение SoC
платформы - это подход сверху-вниз, на основе конкретных
прикладных областей, когда компания или проектная команда переходят к
проектированию семейства продуктов. При разработке линейки или
семейства продуктов платформами называются интегрированные и
управляемые наборы общих особенностей, на основе которых могут быть
построены вторичные продукты, включающие в себя конкретные наборы
особенностей для данной прикладной области - члены семейства
продуктов. В этом случае изменения платформы связаны с изменением
приложения или эволюцией стандартов. Например, добавление
возможности беспроводной передачи данных к PDA приложению или
переход от 2G стандарта беспроводной связи к 2.5G GPRS и далее к 3G
UMTS.
Технологические и Прикладные Платформ
Технологические платформы обычно не зависят от прикладной области
и конкретных приложений, в то время как прикладные платформы не
зависят от конкретных технологий. Однако в случае технологической
платформы, приложения с более высокой производительностью и/или
требованиями к интеграции будут первыми пользователями новой
технологии. Например, первыми пользователями процесса 130 нм в
основном были микропроцессоры и высокопроизводительные ASIC для
проводной связи, а также поставщики FPGA, которые делали упор как на
высокую интеграцию (для преодоления проблемы плотности FPGA),
так и на высокую производительность (так как ключевой областью
рынка для них является сетевая инфраструктура).
Аналогично, прикладные платформы должны переходить на
технологические процессы, предлагающие достаточный уровень
производительности и удовлетворяющие основным требованиям по
функциональности, производительности, экономии и повторному использованию.

Платформы и платформенное проектирование 183
Беспроводные SoC платформы были невозможны до тех пор, пока в
промышленности не появилось достаточно возможностей по интеграции и
производительности на уровне 350/250/180 нм, после чего появились
стандартные платформы 2G и 2.5G. Так как 180 нм процесс еще
недостаточен для 3G, 3G платформа появится на уровне 130 нм или менее.
Методы и Область Действия
Технологические платформы основаны на традиционных методах
проектирования снизу-вверх: библиотеки стандартных ячеек, полностью и
полузаказное проектирование блоков, проектирование на основе
компонентов, и последующая интеграция. Упор делается на компоненты,
заново созданные или библиотечные, и их интеграцию.
Прикладные платформы обеспечивают реальную возможность для
развития методов системного проектирования и проектирования сверху-
вниз, а также контекстно-зависимой интеграции IP «начиная с
середины» (под контекстом подразумевается системный контекст для
платформы в прикладной области).
Так как технологические платформы ориентированы на технологию
и производство, они позволяют обширную модификацию и
оптимизирование компонентов с целью оптимизации всего продукта. В случае
прикладной платформы большой упор делается на стандарты, а
интеграция на уровне продукта старается использовать SoC или базовую
платформу без изменений, либо только конфигурирует платформу в пределах
ее области использования, для уменьшения времени на верификацию и
рисков реализации. Этот подход был назван «повторное использование
без переделывания» - или повторное использование без повторной
верификации.
Эта разница между типами платформ также проявляется в областях
действия платформ. Разработчики технологической платформы хотят
добавить каждый «интересный» компонент и библиотечный элемент,
привлекательный для наибольшего числа клиентов и применимый для
наибольшего числа приложений. Также может прилагаться обширная IP
коллекция для повышения вероятности того, что данная
технологическая платформа окажется полезной для каждого.
Прикладные платформы наоборот стараются уменьшить набор
компонентов в ответе на вопрос: Какой именно набор общих проектных и IP
особенностей нужно включить в платформу, чтобы охватить данную
прикладную область и ожидаемый набор вторичных продуктов?
Ориентированность на приложение подчеркивает использование
экономных моделей в рамках семейства продуктов и средств управления
набором особенностей, дополняющих более традиционные подходы к

Приложение №2
проектированию (рис. 4). Это может оказаться радикальным
изменением для тех, кто привык к последовательному созданию продуктов и
традиционным ориентированным на технологии методам.
В результате этих различий маршрут проектирования для
технологической платформы довольно неформален, или основан на наборе
общих требований заказчика. У прикладной платформы, с другой
стороны, маршрут проектирования гораздо более формализован и
спланирован как для вторичных продуктов (основанных на платформе), так и для
дальнейшей эволюции платформы.
Product Family
Roadmap
(all products)
С J ~ Architecture
0 = Design and
Implementation
Platform Roadmap (Commonalities)
„K
"Ц ^
t
zz
^r
^
Platform Roadmap
Platform
Development
Differentiating IP Roadmap (Variabilities)
m Differentiating IP
Roadmap
Differentiating IP
Development
P, ■ Different Products in the Same Product Family
V; ■ Platform Version
L, ■ Manufacturing Release
S ■ Start of Project
TIM = Time to Market
TBSP - Time Between Successive Products
т~
~^
Z 5 1
г
duct Far
TTM s
nily
'
L
С УС ' Ъ II
„ Product Roadmap
(Family Members)
Product Family
Member
Development
p,5|^-ix *jL
Рис. 4. Семейство продуктов.
Вторичное Проектирование
Продолжая эту тему, нужно отметить, что часто заранее неизвестно,
какие именно вторичные продукты будут проектироваться на основе
технологической платформы - возможно, что известны только начальные
приложения (образцы), которые приведут к независимому появлению
последующих вторичных продуктов. Эти последующие вторичные
продукты проектируются на основе традиционных библиотечных подходов
с упором на базовую аппаратную часть, хотя также и с некоторой
программной частью, особенно для процессорных под-систем.
Прикладные платформы начинают жизнь как часть семейства
продуктов, хорошо определенного набора связанных вторичных продуктов,
которые могут проектироваться одновременно, параллельно друг другу
(рис. 5). Каждый вторичный продукт дополняет платформу конкретными
интерфейсами и функциональными блоками, уникальными для данного

Платформы и платформенное проектирование 185
члена семейства продуктов. Так как прикладные платформы уже содержат
большую часть IP блоков (относящихся к данной прикладной области) в
разработанном и верифицированном виде, особенно аппаратное IP, при
проектировании вторичных продуктов больше внимания уделяется
созданию и модифицированию программной, а не аппаратной части.
В противоположность этому, технологические платформы обычно
эволюционируют благодаря необходимости в появлении будущих
вторичных продуктов, эти пратформы развиваются путем добавления в
библиотеки конкретных аппаратных или программных блоков, так как
вторичные проекты в этом случае обычно являются закрытыми -
собственностью их разработчиков.
Market Segments
Product Family
Members
(Derivative Products:
Platforms plus
differentiating
features)
Application-Driven
Platforms
(Successive
generations of the
product platform)
Building
Blocks
i
j i
\ t
r
\
»
i
I
i
i
i
L
i
i
i
i
i
i
i
A
i
i
I
\
t I
A
A
N
Top Tier
Middle Tier
Bottom Tier
^m
Product
Technologies
Design Flows and
Manufacturing
Processes
Organizational
Capabilities
Source: Based on Marc H. Meyer and Alvin P. Lehnerd, VThe Powerof Product PlatformsO
Рис. 5. Прикладные платформы и «башня семейств продуктов».
Клиенты и Рынки
Так как технологические платформы не привязаны к конкретным
приложениям, их можно предлагать широкому кругу потенциальных
покупателей, так же, как и процессорные подсистемы, которые
рекламируются как IP продукты, пригодные для использования в разных
контекстах. Благодаря абстрактности таких платформ, заказчики играют не
очень большую роль в их создании, возможно только через задание
общих характеристик, особенностей и требуемой производительности.
Примерами технологических платформ являются RapidChip от LSI
Logic и Vertex-II Pro от Xilinx.

186 Приложение №2
Прикладные платформы наоборот часто приводят к тесным связям
с определенными заказчиками и линейками продуктов, и
способствуют более близким взаимоотношениям, как внутри SoC компании, так
и с определенными внешними партнерами. В качестве хорошего
примера можно назвать взаимоотношения компании TI с ключевыми
производителями мобильных телефонов, таких как Ericsson и Nokia по
поводу DSP платформы, включая также новейшую ОМАР платформу
компании TI. Такие глубокие связи с прикладным продуктом и с
заказчиками подразумевают сильную архитектурную зависимость между
платформой, выбором IP и требованиями ведущих потребителей. Это
особенно важно при выборе процессоров, так как вопрос поддержки
устаревших программ оказывает очень большое влияние на эволюцию
процессоров.
Архитектуры
В случае технологических платформ библиотечные компоненты и
выбор базовых средств реализации («fabrics») в большой мере
определяют общие проектные архитектуры. Конечно, добавление конкретных
встроенных процессоров, их шин на чипе, а также связанной с ними
памяти и периферии приносит с собой много архитектурного
«багажа», как аппаратного, так и средств написания программ
(компиляторов, отладчиков, ассемблеров, и.т.д.). Так что даже технологические
платформы, предлагающие подсистемы встроенных процессоров,
несут с собой некоторые конкретные архитектурные подходы. Однако,
так как пользователи обычно стремятся оптимизировать проекты,
основанные на данной платформе, IP блоки и подсистемы
(предлагаемые вместе с платформой) должны быть открыты, чтобы конечную
реализацию можно было оптимизировать по производительности,
потребляемой мощности, затратам или другому параметру. В случае
технологической платформы довольно сложно предложить возможность
конфигурируемости или модификаций и при этом сохранить низкие
риски.
Прикладные платформы с конфигурируемой архитектурой ядра
обычно устанавливают пределы конфигурирования, определяющие
«область применимости» платформы, а все компоненты
рассматриваются как черные ящики, которые нельзя легко изменить. Наибольшую
важность имеет время разработки (time-to-market), и желание снизить
риск приводит к принципу «повторное использование без
модификаций». Чтобы достичь правильных интерфейсов приложения,
прикладные платформы делают упор на многоуровневые и замкнутые API, на
основе которых создаются вторичные части конкретного продукта.

Платформы и платформенное проектирование I
Таким образом технологические платформы склонны часто
меняться, и новые платформы возникают при каждом улучшении процесса
производства или проектирования. Хотя новые технологии процесса
производства также влияют и на прикладные платформы, они
эволюционируют более упорядоченно, в рамках долговременного маршрута и с
сохранением значительной архитектурной стабильности от одного
поколения к другому.
Заключение
Показав разницу между технологическими и прикладными
платформами, мы начали прояснять различные использования термина
«платформа» в применении к разработке SoC.
В то время как недавние появления продуктов на основе
технологических платформ ведут к предположению, что такие SoC платформы
будут доминирующими в будущем, нужно учитывать, что большая
часть прикладных платформ менее заметна, так как они либо
полностью находятся в пределах большой компании, либо являются частью
менее рекламируемых взаимоотношений между компаниями. Более
того, прикладная платформа может быть создана на основе
технологической платформы, а прикладная платформа в следующем поколении
может стать компонентом технологической платформы. Поэтому в
будущем будут существовать оба типа платформ.
Проектирование полных систем на чипе требует значительного
повторного использования предварительно интегрированных и
предварительно верифицированных компонентов, что достигается с
помощью платформенного проектирования. Сюда также входит
необходимость в новых методах и средствах анализа семейств продуктов, а
также в новых возможностях аппаратных и программных компонентов,
улучшающих параллельную и взаимозависимую разработку. В
противоположность традиционному последовательному подходу - «сначала
аппаратная часть, а затем программная», в нашем подходе - «сначала
семейство продуктов, затем платформенные и уникальные VC
компоненты, а затем продукт» взаимозависимость между спецификацией
продукта, архитектурой, разбиением и программной/аппаратной
разработкой не требует полностью интегрированных средств. Требуются
только тщательно спланированные связи между независимыми
цепочками средств, на основе абстракций и моделей.

188 Приложение №2
Литература
1. Henry Chang, Larry Cooke, Merrill Hunt, Grant Martin, Andrew McNelly, and Lee
Todd, Surviving the SOC Revolution: A Guide To Platform-Based Design, Boston, MA,
Kluwer Academic Publishers, 1999
2. Paul Clements and Linda Northrop, Software Product Lines: Practices and Patterns,
Addison-Wesley, 2002
3. "Defining Platform-based Design" by Alberto Sangiovanni-Vincentelli, ЕЕ Design Web
Site, February 5, 2002; http://www.eedesign.com/story/OEG20020204S0062 and
http://www.eedesign.com/story/OEG20020204S0062
4. Marc H. Meyer and Alvin P. Lehnerd, The Power of Product Platforms: Building Value and
Cost Leadership, The Free Press, 1997
5. Jean-Marc DeBaud and Klaus Schmid, A Systematic Approach to Derive the Scope of
Software Product Lines, in Proceedings of the 1999 International Conference on Software
Engineering, ACM, pp. 34-49)
6. J. Bayer, O. Flege, P. Knauber, R. Laqua, D. Muthig, К Schmid, T Widen, and J.-M.
DeBaud, PuLSE: A Methodology to Develop Software Product Lines, in Proceedings of the
Fifth ACM SIGSOFT Symposium on Software Reusability (SSR99), Los Angeles, CA, May,
1999, pp.122-131.

Приложение №3
«Системный уровень в САПР
Synopsys: о сквозном маршруте
проектирования систем
на кристалле, от системного
уровня до уровня СБИС»
Введение
Synopsys обеспечивает полную интеграцию своих продуктов в единый
маршрут, что минимизирует затраты на разработки систем на кристалле
(СнК) от системного к RTL-уровням, далее до логического и до
топологического уровней.
САПР Synopsys системного уровня SystemStudio вполне доступен
даже небольшой фирме, и возможностей SystemStudio достаточно для
проведения системной части работ по проектированию СнК. Модель
исполняемой спецификации системы, сформированная
фирмой-разработчиком системы в SystemStudio, позволит фирме-разработчику кристалла с
помощью средств Synopsys легко проводить синтез логической модели
СнК. Грамотная безошибочная верификация системы на всех уровнях
также обеспечивается тесной интеграцией всех средств Synopsys.
Маршрут проектирования Synopsys
Система на кристалле (СнК) при проектировании представляется на
разных уровнях абстракции, в соответствии в с которыми выделяются
уровни и входящие в них этапы маршрута проектирования
Таким образом, маршрут проектирования Synopsys включает в себя
три основных уровня:
1 - системный уровень, включающий этапы алгоритмического (иногда
называемого функциональным) и архитектурного проектирования:
Этап 1: создание алгоритмической модели, ее верификация
Этап 2: создание модели уровня транзакций, иными словами, модели
макроархитектуры; ее верификация;

190 Приложение №3
Этап 3: создание «золотой модели» СнК как ТЗ для проектирования
системы как аппаратной, и для программной ее частей
2 - логический, или вентильный, уровень
Этап 1: создание синтезируемой RTL-модели СнК на одном из языков
описания аппаратуры (HDL) (Verilog/SystemVerilog/VHDL)
Этап 2: логическая верификация RTL-модели посредством
моделирования
Этап 3: физическая верификация посредством прототипирования на
FPGA.
Этап 4: синтез в базисе вентильных схем; автоматическая генерация
тестовых структур для контроля годности СБИС: SCAN, JTAG,
BIST.
Этап 5: логическая и формальная верификация списка цепей (netlists)
Этап 6: генерация фабричных тестов для контроля годности СБИС
3 — топологический уровень
В данной публикации мы не приводим подробностей разбиения на
этапы.
Для каждого из уровней реализуется идея «горизонтальной»
методологии проектирования, или «спиралевидного» маршрута, когда за
каждым этапом проектирования следует этап верификации, при этом инте-
грированность средств Synopsys обеспечивает верификацию с
использованием описаний на разных уровнях абстракции, а также при
необходимости переход от уровня к уровню.
Synopsys поставляет свыше 50-ти различных инструментов
разработки и верификации СБИС. Остановимся на самых основных для
системного и логического проектирования, см. рис.1.
/. Системное проектирование
для разработки СнК на системном уровне используется инструмнт
System Studio, системный уровень включает два подуровня -
алгоритмический и подуровень транзакций.
Проектирование СБИС, особенно систем на кристалле, - это
процесс многостадийный, в него оказываются вовлеченными несколько
соисполнителей. Все это резко повышает вероятность ошибки, причем
такой, которую можно обнаружить уже после изготовления кристалла.
Колоссальные потери времени и денег (многие сотни тысяч долларов) в
этом случае очевидны. Поэтому в процессе проектирования
первостепенное значение приобретают так называемые исполняемые
спецификации проекта - виртуальные модели разрабатываемой системы,
начиная с ее системного, совершенно абстрактного уровня. Детализируя про-

Системный уровень в САПР Synopsys 191
^^ Кодирование^^ п
\ ок? ^>
\/
к
VCSMX
s' Тесты \
V ок?
Синтез,Оптимизация,
Прототипирование:
Design Compiler/Physical Compiler, 2
DC FPGA, DFTC, TetraMAX
Логический Уровень
/
^
1
\
Верификация
нетлиста:
PrimeTime,
Formality
A
k
VCS MX
у/' Тест \
<^ OK?
Верифицированный
нетлист **-
AlternativeSblutionsAlt-S© June2004v.2. 4
Рис.1. SLD to netlist DesignFlow graphics - Jun 2004 v2.4.doc

192 Приложение №3
ект, переходя с верхних уровней все ближе и ближе к топологии,
разработчики должны иметь возможность постоянно сравнивать то, что у них
получается, с исходными требованиями к будущей СБИС. Вот тут-то
исполняемые спецификации и незаменимы. Современные САПР
позволяют изначально создавать исполняемую модель системы (на
алгоритмических языках высокого уровня, без привязки к конкретной
реализации), постепенно детализировать ее, заменять более абстрактные блоки
сначала архитектурными моделями (на уровне транзакций), а затем и
конкретными описаниями аппаратуры - на RTL-уровне, на вентильном
уровне и т.д. Такие виртуальные модели фактически являются
техническим заданием для разработчиков СБИС. В процессе разработки СБИС
модель постепенно детализируется, но при этом всегда можно
убедиться, что по мере разработки не изменяется заданная функциональность
исходной модели.
Существуют исполняемые спецификации различного уровня
абстракции в соответствии с этапами проектирования СнК:
- модель уровня алгоритмов (С, C++);
- модель уровня транзакций, макроархитектуры (SystemC) создается
на базе алгоритмической модели инкрементально);
- модель RTL-уровня, микроархитектуры (SystemVerilog, Verilog).
- модель логического (вентильного) уровня
Этап 1: создание алгоритмической модели, ее верификация
В самом начале проектирования есть общая идея, спецификация на
бумаге, например, описание стандарта. После ее анализа создается
первая, очень обобщённая модель системы. Это скорее всего C/C++
модель, которая может предусматривать блоки генерации тестовых
воздействий. С помощью этой модели можно проанализировать,
работоспособен ли выбранный математический алгоритм в принципе.
Алгоритмическая модель создается при помощи инструмента System
Studio с использованием C/C++, SystemC, библиотеки алгоритмов,
входящих в System Studio, а также через импортирование Matlab-моделей.
Не нужно все писать вручную, есть библиотеки.
Инструменты: System Studio, Вся работа проводится в System Studio.
Этап 2: создание модели макроархитектуры, иными словами, модель
уровня транзакций; ее верификация;
Цель: исследование различных вариантов макроархитектуры СнК с
целью подобрать состав СнК, соответствующее ТЗ при создании модели
макроархитектуры в System Studio используется богатая, развитая
библиотека СФ-блоков уровня транзакций DesignWare SystemC library и System
Studio Architecture library, входящая в состав System Studio.

Системный уровень в САПР Synopsys
193
Если задача Этапа 1 — понять общую математику СнК, сделать ее
алгоритмическую модель - задача программиста, то дальше на Этапе 2
должен работать архитектор системы. Здесь происходит передача
проекта из рук в руки, и алгоритмическая модель как раз и является той самой
передаваемой исполняемой спецификацией верхнего,
алгоритмического уровня.
Задача архитектора - создать работающую виртуальную модель
системы, с помощью которой можно исследовать различные варианты
архитектуры с учётом возможностей аппаратной и программной
реализации различных функций. Для этого необходим более
специализированный, чем C/C++, язык, такой как SystemC.
SystemC позволяет описывать архитектуру системы. Модель,
описанная на нем, позволяет выполнить такие исследования, как анализ
потоков данных между блоками системы, эффективность
использования памяти, влияние времени считывания/записи и т.д. В основе языка
SystemC лежит C++, поэтому SystemC-модель можно разрабатывать на
базе существующей С++-модели, дополняя её конструкциями,
отражающими архитектуру системы. Но на то, чтобы сделать это вручную,
потребуется достаточно много времени.
SystemStudio позволяет упростить и ускорить процесс создания
SystemC-модели, в нем реализованы средства моделирования,
необходимые для верификации проекта на системном уровне. Кроме того,
разработчику здесь предоставлена удобная графическая среда описания
архитектуры системы в виде блоков, диаграмм, доступен широкий набор
библиотек готовых модулей системного уровня, из которых можно
быстро построить первый прототип всей системы или её части. Можно
варьировать параметрами (например, объёмом памяти или пропускной
способностью шин), выбрать процессорную модель. Для удобства
анализа в графической среде SystemStudio предусмотрена возможность
установки специальных мониторов в любую точку системы. Мониторы
позволяют отслеживать данные о сигналах, активность и статистику
использования шин. Встроенные мониторы присутствуют и в библиотеках
системных модулей.
Естественным дополнением к SystemStudio служит SystemStudio
Reference Design Kit (RDK). RDK представляет собой набор системных
моделей множества стандартов и протоколов в области проводной и
беспроводной связи, шинных протоколов и т.д. Эти модели можно
использовать не только как внутренние модули системы, но и как внешнее
обрамление, обеспечивающее генерацию тестовых воздействий на
входе в соответсвии с тем или иным стандартом и контроль на
соответствие тому или иному стандарту на выходе. Модели RDK могут
эмулировать на входе и такие данные как, например, ошибки линии в Ethernet.

194 Приложение №3
Существенное преимущество SystemStudio по сравнению с
продуктами других компаний - возможность организации
программно-аппаратной верификации системы, что позволяет уже на системном уровне
одновременно отлаживать и макроархитектуру аппаратной части, и
встроенное программное обеспечение. К System Studio Можно
подключить любой программный отладчик (или SDK) и отлаживать
программную часть непосредственно в составе виртуального прототипа системы
вереде SystemStudio.
После окончательного выбора архитектуры, доводки параметров
системы на базе как библиотечных, так и заново созданных
пользователем моделей, созданная SystemC -модель передаётся разработчику
СБИС в качестве исполняемой спецификации макроархитектурного
уровня, уровня транзакций. Она сопровождается наборами тестов и
генераторами псевдослучайных тестовых потоков для регрессионного
тестирования, то есть по-сути является техническим заданием для
разработчиков СБИС.
Разработку и верификацию системных моделей существенно
упрощают и ускоряют развитые библиотеки системного уровня. Основные
из них - это DesignWare SystemC library и Reference Design Kit (RDK).
Библиотека DesignWare не имеет аналогов на рынке средств САПР
благодаря уникальному набору функциональных параметризируемых
блоков (от арифметических устройств до микропроцессорных ядер). RDK
представляет собой набор системных моделей множества стандартов и
протоколов - в области проводной и беспроводной связи, шинных
интерфейсов и т. д. Он удобен, например, при разработке
коммуникационного процессора для системы GSM, а модели всего стека GSM
протоколов для верификации модели этой СБИС можно взять из RDK.
Если модель создается с нуля, то можно использовать встроенную
библиотеку алгоритмических и архитектурных моделей System Studio.
Инструменты: System Studio, DesignWare, DesignWare SystemC library
Вся работа проводится в System Studio с и библиотекой СФ-блоков.
чЭтап 3: создание «золотой модели» СнК как ТЗ
Окончание верификации модели уровня транзакций знаменуется
созданием «золотой модели» СнК, т.е. на ее основе оформляется
документация, которая становится ТЗ для дальнейшего проектирования АО и ПО.
«Золотая модель» СнК - это та же модель уровня транзакций, но
верифицированная, согласованная с заказчиком и документированная
как ТЗ. В данном случае верифицированная означает отмоделированная
и выбранная из нескольких вариантов как удовлетворяющая
требованиям заказчика.
Вся работа проводится в System Studio, что позволяет оформить
документацию в HTML-формате

Системный уровень в САПР Synopsys I
Повторное использование, СФ-блоки
Здесь уместно отметить, что «золотая модель» по сути и является
СФ-блоком. Этот блок готов для повторного использования в задачах
верификации, как самой модели в целом, так и ее отлаженных частей,
которые в свою очередь также могут рассматриваться как СФ-блоки.
При необходимости СФ-блок оформляется как верификационная
модель по соответствующим международным правилам VSIA с
помощью средств Synopsys DesignWare Developer.
Инструменты: System Studio, DesignWare Developer
Логическое проектирование
Этап 1: создание синтезируемой RTL-модели СнК на HDL (Verilog/
SystemVerilog/VHDL) на основе «золотой модели», спецификации
системного уровня с контролем стиля проектирования (LEDA HDL-
Checker)
Инструменты: текстовый редактор, DesignWare, LEDA HDL-
Checker.
Вся работа ведется в основном как вручную в текстовом редакторе,
так и с использованием библиотеки СФ-блоков DesignWare, для
создания синтезируемых кодов, и полуавтоматизированно, посредством
генерации SystemVerilog моделей из SystemC моделей, и в LEDA для
контроля стиля HDL-кодирования.
Замечание: «работа вручную» применяется только здесь, во всех
остальных случаях САПР Synopsys работает полуавтоматизированно, как и
все САПР.
Отметим, что процесс разработки и верификации моделей RTL
—уровня существенно упрощают и ускоряют библиотека DesignWare
Если SystemC -модель в SystemStudio была составлена из
библиотечных блоков, получить RTL-описание не составит труда, поскольку
для библиотечных блоков заранее существует параметризованное RTL-
описание. Сложнее с SystemC-моделями написанными
непосредственно разработчиками. Здесь SystemStudio предлагает воспользоваться
новыми средствами генерации SystemVerilog-моделей из SystemC. Далее,
уже с помощью пакета DesignCompiler можно делать прямой синтез
списка цепей в базисе выбранной вентильной библиотеки стандартных
ячеек, БМК или FPGA. Учитывая, что есть все предпосылки к тому, что
SystemVerilog станет следующим стандартом Verilog, такое направление
представляется очень перспективным.
В результате, САПР Synopsys обеспечивает сквозной маршрут
проектирования от системного уровня к уровню проектирования СБИС.
Это - принципиальный момент. Ведь в САПР других фирм возможности

196 Приложение №3
перехода от системного уровня к проектированию СБИС часто
ограничены набором библиотечных модулей (а библиотек на все случаи жизни
не бывает), что приводит к необходимости создавать весь RTL-код для
последующего синтеза вручную. То есть, имея отлаженную модель на
C++ или SystemC, инженеры дизайн центра будут вынуждены заново
описывать будущую СБИС на языках HDL (Verilog, VHDL, System-
Verilog). Это напоминает знакомую многим ситуацию, когда разработчик
РЭА передает конструктору печатных плат свою схему, нарисованную на
бумаге, а не в виде списка элементов и цепей в стандартном формате.
Вероятность ошибки при проектировании печатной платы в этом случае
возрастает чрезвычайно. Кроме того, довольно часто САПР создания
моделей системного уровня и система генерации Verilog/ VHDL-описаний
библиотечных блоков принадлежат различным фирмам, что нередко
приводит к проблемам совместимости и разделения ответственности.
Этап 2: логическая верификация посредством моделирования
созданной на Этапе 1 RTL-модели.
Верификация выполняется в основном с помощью VCS MX.
VCS MX является универсальной платформой для моделирования, а
также для автоматизации функциональной верификации с
использованием OVA (Open Vera Assertions). Возможности VSC MX обширны:
- моделирование смешанных описаний VHDL/Verilog/SystemVerilog/
SystemC/C++, Verilog-AMS
- моделирование с СФ-блоками системного уровня совместно с
System Studio
- моделирование смешанного цифро-аналогового сигнала совместно
с NanoSim, HSPICE
- совместная работа со средствами формального анализа Formality
- подключение защищенных СФ-блоков
- прямая компиляция OVA (Open Vera Assertions)
- встроенные средства анализа покрытия кода
- обладает великолепными отладочными средствами (VirSim), недо
ступными конкурентам
Инструменты: VCS MX
Вся работа ведется в VCS MX
Этап 3: физическая верификация посредством прототипирования
на FPGA.
Компания Synopsys, будучи традиционно ориентированной на
разработку средств проектирования заказных интегральных схем (СБИС, ASIC)
и систем на кристалле (СнК), также постоянно совершенствует свои
средства для прототипирования на базе FPGA. Идея, реализованная в новом
продукте Synopsys Design Compiler FPGA, - «проектируйте единожны» -

Системный уровень в САПР Synopsys
197
\$i щ*с
' 1
Unified
Visualization
Full-Featured Testbench
V 1^ш '
w ^
Q\jQtam\far\\r\r\
SystemC™/C++ 1
V
4 P
Verilon
Assertions
Checkers J
VHDL
~J^L~
Comperehensive Coverage
| and Analysis
"^S
<4Щ
^
^
> System
Studio
► Magellan™ j
ЯИЯДЛ^ NanoSim®
«■"Phhspice»
^^вв^
*^E
itfinnliSiMlH
__
DesignWare®
►VIP |
С ...„— .„.,.,. ,.,.,.,„■/
Рис.2. VCS MX - универсальная платформа для моделирования смешан
ных описаний
означает, что разработчику заказной интегральной схемы для создания
прототипа схемы на FPGA не потребуется вносить изменений в свой
проект. Все заботы по эффективной адаптации проекта к конструкциям
FPGA должен взять на себя Design Compiler FPGA (DC FPGA).
Возможности программируемых кристаллов возросли, и теперь
вполне можно реализовать на FPGA устройства сложностью до десяти
миллионов вентилей с быстродействием 150-200 МГц. Разработчики
СБИС активно стали использовать FPGA в качестве средства
прототипирования разрабатываемых СнК. Создание прототипа на базе FPGA
фактически становится одним из этапов проектирования СБИС и СнК.
А это уже сфера прямых интересов Synopsys.
Компания откликнулась на такую тенденцию разработкой DC
FPGA. Цель нового продукта Synopsys - дать своим пользователям -
разработчикам ASIC надежное средство прототипирования на базе
FPGA в рамках единого маршрута проектирования СнК.
Недостаток большинства средств проектирования FPGA (в
частности синтеза) - несоответствие стиля кодирования HDL для FPGA
стилю кодирования для СБИС. В результате приходится дважды проходить
этап логического проектирования - один раз для СБИС, другой для
FPGA. Получается что одно и то же нужно проектированть дважды, тем
самым искажается сама идея прототипирования. DC FPGA устраняет
эту проблему: RTL модель создается только один раз, соответственно, и
верифицируется один раз, а не несколько.
Основная идея - прототип должен создаваться из того же RTL-опи-
сания, которое разрабатывается для СБИС, поскольку любые
изменения исходных кодов связаны с риском появления ошибок.

198
Приложение №3
DC FPGA работает на платформах Galaxy Design и Discovery
Verification (рис.2).
DC FPGA полностью совместим с такими продуктами фирмы
Synopsys как:
- Design Compiler (DC) (синтез с уровня RTL-описаний для СБИС);
- Formality (статическая проверка соответствия на функциональную
эквивалентность);
- DesignWare (библиотека IP-блоков);
- PrimeTime (статический временной анализ);
- LEDA (формальный контроль качества RTL-кода);
- VCS MX (смешанное HDL моделирование);
- Vera (Автоматизация разработки тестов);
- Module Compiler (синтез трактов обработки данных);
- HSPICE (аналоговое моделирование).
На рис. 3 наглядно представлены преимущества, которые даёт
использование DC FPGA разработчикам ASIC для создания прототипа.
Традиционный маршрут проектирования прототипов (слева) требует
внесения изменений в исходный RTL-код, создания нового описания
системы правил и ограничений, ручной модификации схем стробирова-
ния синхросигналов (clock gating). Для подтверждения соответствия
прототипа исходному проекту необходима тщательная дополнительная
верификация (ручная или с использованием динамического моделирования).
Рис.3 Универсальные платформы для проектирования Galaxy и для
верификации Discovery.

Системный уровень в САПР Synopsys
199
Фактически, в традиционном маршруте, создание прототипа - это
новый проект, в котором всегда сохраняется вероятность возникновения
ошибок. В маршруте создания прототипов с использованием DC FPGA
(справа) не требуется никаких изменений исходного RTL-кода,
системы правил и ограничений. Изменение схем стробирования
синхросигналов с учетом особенностей FPGA происходит автоматически. В
маршрутах проектирования прототипа и ASIC используется одна и та же
библиотека IP-блоков DesignWare и средства статической проверки
функционального соответствия.
Если говорить о функциональных характеристиках DC FPGA, то в
первую очередь надо заметить, что при использовании DC FPGA
быстродействие получаемых микросхем в среднем на 15% выше чем дают
существующие сегодня на рынке средства синтеза для FPGA. Высокое
качество синтеза обеспечивается как использованием хорошо
зарекомендовавших себя на практике технологий оптимизации Design Compiler
(методы экстракции и оптимизации управляющих конечных автоматов,
изменения положения регистров в конвейере и др.), так и за счёт новой
Desing Once with Design Complier FPGA - Fastest Path to Phototype
ASIC-Strenght
Traditional ASIC Flow Phototyping Flow
Рис.4. Преимущества использования DC FPGA для прототипирования ASIC.

200 Приложение №3
технологии адаптивной оптимизации (Adaptive Optimization
Technology), которая позволяет учитывать специфику архитектуры конкретных
FPGA (например, Xilinx или Altera).
В DC FPGA поддерживается как обычный процесс компиляции
сверху вниз, так и реальный синтез снизу-вверх (и это единственный
продукт который имеет такую возможность). При этом появляется
возможность инкрементального синтеза, большей гибкости в выборе стиля
проектирования. Отдельные модули проекта могут независимо
разрабатываться сотрудниками команды разработчиков, что позволяет
сократить время проектирования за счёт распараллеливания работ. Скорость
выполнения самой программы очень высока за счет поддержки
технологии распределённого синтеза. Особо нужно отметить разработанные
средства автоматического преобразования организации стробирования
синхросигналов с учетом ограниченных ресурсов FPGA в плане
реализации таких схем. Без этих средств разработчик может потратить многие
недели работы, редактируя исходные коды для адаптации под FPGA.
Библиотеки для DC FPGA разрабатываются производителями FPGA,
причем самые последние версии библиотек можно всегда получить
непосредственно с интернет-страниц производителей. Естественно,
следует отметить наличие поддержки разбиения проекта на несколько
микросхем.
DC FPGA абсолютно совместим с Design Compiler для СБИС и
пользователи, знакомые с Design Compiler, не должны испытать
никаких затруднений при работе DC FPGA. Продукт доступен всем
официальным пользователям Design Compiler, которым по душе принцип
«проектируйте единожды» (design once).
Инструменты: DC FPGA
Работа ведется в DC FPGA для синтеза СнК в базисе выбранных
FPGA-платформ.
Этап 4: синтез в базисе вентильных схем; автоматическая генерация
тестовых структур SCAN, JTAG, BIST.
За уровнем RTL, как известно, следует логический (вентильный)
уровень. Для работы на нем предназначено семейство продуктов Design
Compiler. Эти продукты занимают на рынке долю около 85%, и
фактически Design Compiler стал промышленным стандартом. Он представлен в
двух версиях: стандартной Design Compiler Expert и расширенной -
Design Compiler Ultra, обладающий встроенными средствами генерации
трактов данных DataPath и более мощными алгоритмами оптимизации.
Design Compiler (DC) обеспечивает синтез логической схемы в
базисе производителя микросхем. Таким базисом служат библиотеки
стандартных ячеек, ячеек ввода/вывода, компиляторы различного вида
памяти, разработанные под данного производителя микросхем.

Системный уровень в САПР Synopsys 201
С Design Compiler стыкуются различные дополнительные
инструменты. Например, DFT Compiler (DFTC) формирует аппаратные
средства контролепригодности синтезируемой структуры (JTAG,
BIST, SCAN и т.п.), Power Compiler позволяет оптимизировать схему с
точки зрения энергопотребления и т. д. Отметим, что готовые блоки и
библиотечные элементы не транслируются повторно, a Design
Compiler передаются указатели на них. Design Compiler оптимален для
технологии до 0,25-0,18 мкм. На технологиях следующего уровня, с
разрешением менее 0,18 мкм, начинают проявляться более тонкие
физические эффекты. Для работы на этих глубокосубмикроных
уровнях предназначен Physical Compiler (PhC). В отличие от Design
Compiler, этот инструмент использует библиотеки топологического
уровня и синтезирует не только список цепей, но и реальное
размещение элементов на кристалле. Physical Synthesis - идея ставшая
стандартом для UDSM технологий, она позволяет получать адекватные и
предсказуемые результаты еще до этапа топологического
проектирования. В основе лежит принцип одновременного синтеза и
размещения элементов на кристалле с использованием данных
топологических библиотек.
Получив размещение, можно с точностью 5 -10% оценить длину
связей между элементами и по значениям их емкостей и
сопротивлений определить времена задержек распространения сигналов в цепях.
Очень важно, что выходной формат Design Compiler и Physical
Compiler стандартны: netlist - на языках Verilog или VHDL, описание
размещения элементов - в универсальных форматах IEEE PDEF,
DEF, LEF, которые понятны продуктам других компаний.
Инструменты: DC, DFTC, PhC
Работа ведется в DC (или в PhC для 0.18мкм и ниже) для синтеза
СнК в базисе вентильных схем будущей СБИС, а также в DFTC для
обеспечения тестопригодности СнК
Этап 5: верификация списка цепей (netlists)
По завершении логического синтеза необходимо провести
верификацию проекта. Для анализа временных статических характеристик
предназначен пакет Prime Time. Это также весьма распространенный
на рынке продукт. Он позволяет получить адекватное представление о
поведении схемы, проанализировать его в наилучшем и наихудших
случаях, учесть влияние вариации технологического процесса,
обнаружить скрытые ошибки.
Инструменты: VCS MX, Formality, PrimeTime
Вся работа ведется:
- в VCS MX для логической и функциональной верификации СнК,

202 Приложение №3
- в Formality для статической формальной верификации, то есть для
статической проверки (без моделирования) списка цепей на
функциональную эквивалентность исходной RTL-модели,
- в PrimeTime для временного статического анализа
Этап 6: генерация фабричных тестов для контроля годности СБИС
Инструменты: TetraMAX
Вся работа ведется в TetraMAX.
Повторное использование, СФ-блоки
Отметим, что на этапах логического проектирования модель СнК по
сути становится синтезируемым СФ-блоком, и, что важно, остается
прямым наследником «золотой модели» системного уровня.
При необходимости здесь СФ-блок оформляется уже на выбор, либо
как синтезируемая модель, либо как готовый
технологически-зависимый блок, также по соответствующим международным правилам VSIA с
помощью средств Synopsys DesignWare Developer, core Builder,
coreConsultant. Данные средства идеальны для создания своих СФ-бло-
ков с точки зрения создания своего свода правил оформления СФ-бло-
ков, обеспечения безопасности, надежности и сохранности авторских
прав посредством лицензирования созданных СФ-блоков.
Заключение
Итак, ограниченные объемами данной публикации, мы рассмотрели
только самые основные средства Synopsys для системного и логического
уровней проектирования СнК.
Успешное завершение этих этапов позволяет перейти к
проектированию топологии СБИС, которое также можно вести в САПР Synopsys.
Касательно топологии мы лишь отметим, что основным продуктом для
синтеза топологии, для ее размещения, трассировки и оптимизации
служит инструмент Astro. При размещении и трассировке учитывается
влияние взаимных помех между отдельными проводниками и фрагментами
схемы, влияние физических эффектов, проявляющихся при нормах 0,18
мкм и ниже. Предусмотрена и защита от антенного эффекта, когда на
стадии производства остаточный заряд формирующегося проводника
способен повредить уже подсоединенный к нему вентиль. На выходе
Astro вы получаете готовую топологию кристалла в формате GDSII. Для
экстракции RC параметров из уже готовой топологии предназначен
инструмент Star RCXT. Полученные с его помощью RC характеристики
реальной топологии можно проанализировать с помощью того же Astro
или Prime Time SI. Кроме анализа временных параметров проверяются

Системный уровень в САПР Synopsys 203
соблюдения правил проектирования (DRC) и правильности
электрической схемы (ERC), т.е. правильность соединений, наличие неподсоеди-
ненных входов/выходов и т.п. Третья составляющая проверки топологии
— восстановление из нее списка цепей и сравнение с исходным netlist
(LVS). Все эти проверки реализует инструмент Hercules.
О САПР Synopsys в целом
Компания Synopsys (www.synopsys.com) - мировой лидер среди
производителей САПР СБИС. Продукты Synopsys обеспечивают разработку
сложнейших СБИС и систем на кристалле (СнК). Компания также
поставляет СФ-блоки и предоставляет услуги по разработке СБИС, что
позволяет заказчикам упростить процесс проектирования и сократить
время выхода своей продукции на рынок. САПР компании Synopsys
предназначена для работы с любыми КМОП технологиями, вплоть до
глубокосубмикронных (до 0,13 мкм и ниже) на всех этапах маршрута
проектирования.
Тенденции развития САПР Synopsys
Transaction Level simulation - моделирование на уровне транзакций
как фактически стандартный метод верификации, без которого
невозможно спроектировать СнК, так как в этом случае невозможно создать
адекватную модель макроархитектуры СнК, отвечающую требованиям
ТЗ. Относительно модели на уровне транзакций в дальнейшем можно
верифицировать систему на всех последующих этапах.
Assertions - широкое использование assertions, своего рода
утверждений, закладок в процессе моделирования, существенно ускоряющих
как собственно процесс моделирования, так и отладку.
SystemVerilog - основная идея: использовать единый стандартный
язык для описания RTL (HDL) и верификации (HVL, язык
автоматизации создания логических тестов).
Сращивание цифрового и аналогового проектирования на системном
уровне. В System Studio можно создавать модели аналоговых и
смешанных блоков, при этом на уровне транзакций эта модель будет
представлять собой алгоритмическую модель с интерфейсом уровня транзакций.
Средства моделирования и отображения аналоговых (непрерывных
сигналов) в System Studio имеются.
DC FPGA идея - «проектируй единожды». Недостаток большинства
средств проектирования FPGA (в частности синтеза) - несоответствие
стиля кодирования HDL для FPGA стилю кодирования для СБИС. В
результате приходится дважды проходить этап логического
проектирования - один раз для СБИС, другой для FPGA. Получается что одно и то

204 Приложение №3
же нужно проектированть дважды, тем самым искажается сама идея
прототипированйя. DC FPGA устраняет эту проблему: RTL модель
создается только один раз, соответственно, и верифицируется один раз, а
не несколько.
Physical Synthesis - идея, ставшая стандартом для UDSM
технологий, постоянно совершенствуется и развивается, она позволяет получать
адекватные и предсказуемые результаты еще до этапа топологического
проектирования. В основе лежит принцип одновременного синтеза и
размещения элементов на кристалле с использованием данных
топологических библиотек.
HSPICE simulation - принципиально новые алгоритмы для
ускорения SPICE-моделирования на уровне транзисторов, необходимые для
верификации СБИС на новых технологиях 90нм и ниже.

Определения терминов,
использованных в данной публикации.
Уровни абстракции, уровни маршрута проектирования
системный — общее название для уровней проектирования алгоритма и
макроархитектуры СнК
алгоритмический — уровнь анализа алгоритма
функциональный - он же алгоритмический. Пояснение: в отличие от ингода
встречающегося в публикациях понимания, не включает в себя логическое
проектирование
архитектурный — TL, он же уровень транзакций, в котором отражается макроар-
хитектурный состав СнК, то есть из каких блоков состоит система, как они
взаимосвязаны. Позволяет оценить производительность системы, например,
пропускную способность шин;
уровень транзакций - см. архитектурный
логический - RTL, уровень регистровых передач, уровень микроархитектуры,
уровень аппаратной реализации алгоритмов обработка данных, управления
процессами
физический — он же топологический, уровень проектирования топологии
верифицированного нетлиста.
Проектирование, этапы маршрута проектирования
Проектирование - это единый процесс создания и верификации системы или ее
частей, разбивается на различное число этапов на различных уровнях маршрута
проектирования.
Библиотека СФ-блоков
Синтезируемый код - HDL-код, пригодный для синтеза в верифицируемый не-
тлист, то есть такой нетлист, который успешно пройдет верификацию
моделированием.
Стиль кодирования:
- стиль написания синтезируемого HDL-кода, напрмер, стиль RTL-кодирова-
ния, такой стиль отличается от «поведенческого» стиля кодирования
- является основой для более широких понятий, таких как стиль
проектирования, стиль разработчика
Описания инструментов Synopsys, приведен общий список.
Использованные в данной публикации инструменты выделены жирным шрифтом

206 Приложение №3
Средства САПР Synopsys для проектирования
(платформа GalaxyTM)
Design Compiler (DC) - синтез вентильных схем из Verilog/VHDL/SystemVerilog.
Занимает 85% рынка синтеза. Он представлен в двух версиях: стандартной Design
Compiler Expert и расширенной - Design Compiler Ultra. DC Ultra обладает
встроенными средствами генерации трактов данных DataPath и более мощными
алгоритмами оптимизации.
Physical Compiler® (PhC) — совмещает в себе синтез логических схем и их
размещение на кристалле с использованием физических параметров библиотек. Обес-
пе-чивает существенное сокращение времени перехода от уровня регистровых
передач до размещенных вентилей для наиболее сложных проектов.
DFT Compiler (DFTC) - средство синтеза тестопригодных вентильных структур,
таких как SCAN и BIST. Имеет поддержку JTAG интерфейса.
DesignWare (DW) библиотеки включают в себя широчайший набор СФ-блоков,
предназначенных для физической реализации и верификации проектов, в
частности семейство DesignWare включает в себя:
- библиотеку DesignWare (шина АМВА, память, ядра микропроцессоров и
микроконтроллеров, более 18,500 моделей арифметики, трактов данных);
- цифровые и аналоговые блоки DesignWare Cores (PCI, PCI Express, USB 1.1,
USB 2.0, USB 2.0 PHY and USB 2.0 OTG);
- DesignWare Star IP (IBM, Infineon, NEC, MIPS, Philips);
DW Developer - программное средство, позволяющее разработчикам создавать
DW компоненты (СФ-блоки) на базе собственных проектов
Core Builder- программное средство для конфигурирования и параметризации
СФ-блоков с последующим оформлением пакета с верификационными файлами
и документацией
Core Consultant — графическое и командное окружение для поддержки процессов
установки, конфигурирования, верификации и реализации СФ-блоков
Core Assembler - графическое и командное окружение для поддержки создания и
конфигурирования подсистем на базе СФ-блоков
DC FPGA - средство для синтеза Verilog/VHDL моделей в FPGA, имеет единое с
Design Compiler ядро синтеза.
PrimeTime® SI (PTSI) является средством временного статического анализа, а
также анализа целостности данных на уровне вентилей, способен проводить
точный анализ взаимовлияния проводников (crosstalk).
JupiterXT™ - средство проектирования, предназначенное для
автоматизированной планировки и размещения блоков (floorplan) на кристалле
Astro™является сред ством размещения блоков, трассировки и физической
оптимизации кристалла, а также средством анализа и коррекции взаимовлияния
проводников (crosstalk) в кристалле. Позволяет производить оптимизацию как
размещения, так и трассировки. Включает средства планирования кристалла (floor-
plan), синтез деревьев синхронизации и анализа потребляемой мощности.
Cosmos — средство проектирования аналоговых, смешанных и заказных схем.

Определения терминов 207
Star-RCXT™ является промышленным лидером в области средств экстракции RC
параметров для технологий 130 нм и ниже.
Proteus — обеспечивает коррекцию фотошаблона с целью устранения негативных
эффектов дифракции и интерференции
Средства САПР Synopsys для верификации
(платформа DiscoveryTM)
System Studio — среда, позволяющая создавать исполняемые спецификации
проектов на системном уровне с использованием SystemC. Предназначена для
моделирования проектов на уровнях абстракции от алгоритмов до уровня
регистровых передач, для совместной верификации аппаратной части и программного
обеспечения. Имеет встроенные средства анализа алгоритмов с плавающей
точкой и перехода к моделям в фиксированной точкой. Допускает использование
как RTL, так и поведенческого стиля кодирования. Позволяет напрямую
импортировать модели на C++ и Matlab, и имеет интерфейс для совместного
моделирования с другими средствами Synopsys.
DesignWare Verification IP Library - библиотека-подмножество DesignWare,
содержащая модели для верификации.
VCS MX - симулятор смешанных Verilog/SystemVerilog/VHDL моделей,
способный моделировать на любых уровнях абстракции самые сложные проекты.
Имеет встроенные средства анализа покрытия кода (code coverage), встроенную
поддержку языка описания тестов OpenVera TestBench (технология NTB).
Formality® - средство верификации, способное проводить статическую
формальную проверку проекта на функциональную эквивалентность эталону.
Vera® — средство автоматизации функциональной верификации проектов
TetraMAX - средство автоматической генерации SCAN, BIST, SoCBIST тестов
контроля работоспособности. Имеет поддержку JTAG интерфейса.
NanoSim — является средством моделирования на транзисторном уровне для
верификации проектов, включающих в себя цифровые, аналоговые, смешанные
схемы. Имеет интерфейс для совместного моделирования с VCS MX.
НSPICE® - является симулятором аналоговых систем на транзисторном уровне.
Обеспечивает наиболее точные результаты моделирования, а также обладает
обширной библиотекой моделей. Имеет интерфейс для совместного
моделирования с VCS MX.
Star-МТБ - средство для характеризации и создания библиотек в различных
представлениях для проектирования и верификации.
Hercules - средство верификации топологии на соответствие правилам
проектирования (DRC, ERC, LVS)
База данных Milkyway™ является общим хранилищем данных для большинства
средств разработки компании Synopsys, позволяющая обеспечить простое и легкое
взаимодействие между средствами проектирования и средствами верификации

Список сокращений и определений
3G
ABD
A/D
AHDL
АНВ
АМВА
AMS
АРВ
ASIC
ASSP
ATPG
BBD
BER
BIST
CDMA
Third Generation
Wireless Standards
Assertion-Based Design
Analogue-Digital or
Analogue Hardware
Description Language
AMBA High-performance Bus
ARM bus architecture
Analogue/Mixed-Signal
AMBA Peripheral Bus
Application-Specific
Integrated Circuit
Application-Specific
Standard Part
Automatic Test
Pattern Generation
Block-Based Design
Bit Error Rate
Built-in Self-Test
Code-Division Multiple Access
COT Customer-Owned Tooling
CPU Central Processing Unit
D/A Digital-Analogue
DFT Design for Test
DFV Design for verification
DMA Direct Memory Access
DRC Design Rule Checking
DSM Deep Sub-Micron
DSP Digital Signal Processor
DUT Device Under Test
DUV Design Under Verification
ECS I European Chips
and System design Initiative
Стандарты беспроводной связи
третьего поколения
Проектирование на основе утверждений
Аналого-цифровой
Язык описания аналоговых
аппаратных средств
Высокопроизводительная шина АМВА
Архитектура шины от компании ARM
(не сокращение)
Аналоговый/Смешанный сигнал
Периферийная шина АМВА
Специализированная
Интегральная Схема
Специализированная
стандартная интегральная схема
Автоматическая генерация
тестовых последовательностей
Блочное проектирование
Частота ошибок по битам
Встроенное Само-Тестирование
Множественный доступ
с кодовым разделением каналов
Средства производства,
принадлежащие заказчику
Центральный процессор
Цифро-аналоговый
Тестовое проектирование
Верификационное проектирование
Прямой доступ к памяти
Контроль проектных норм
Глубокий субмикрон
Цифровой процессор сигналов
Тестируемое устройство
Верифицируемый Проект
Европейская Инициатива по Чипам
и Системному Проектированию

Список сокращений и определений
EDA
Electronic Design Automation
EDAC Electronic Design Automation
Companies
EDGE Enhanced Datarate GSM
EMEA
ESL
ESW
FIFO
FPGA
FSM
FVP
Europe, Middle East and Africa
Electronic System Level
Embedded Software
First-In, First-Out
communication channel
Field-Programmable
Gate Array
Finite-State Machine
Functional Virtual Prototype
GDS II Graphic Data System II
- standard format
for physical 1С design
GPIO
GSM
GUI
HDL
HdS, HDS
HDVL
HVL
HW
IBS
1С
General Purpose 10
Group Special Mobile;
Global System
for Mobile Communications
Graphical User Interface
Hardware Description Language
Hardware-dependent Software
Hardware Design
and Verification Language
Hardware Verification Language
Hardware
International Business Strategies
Integrated Circuit
Автоматизация Проектирования
Электроники (САПР электроники)
Компании по автоматизации
проектирования электроники
Стандарт GSM
с расширенным потоком данных
Европа, Ближний Восток и Африка
Электроныой системный уровень
Встроенное программное обеспечение
Коммуникационный канал по принципу
Первый Вошел- Первый Вышел
Программируемая пользователем
вентильная Матрица
Конечный автомат
Виртуальный функциональный
прототип
Система обработки графических данных
II — стандартный формат
для физического проектирования ИС
10 - общего назначения
Стандарт Сотовой Связи в Европе
Графический интерфейс пользователя
Язык описания аппаратной части
Аппаратно-зависимое программное
обеспечение
Язык аппаратного проектирования
и верификации
Язык верификации аппаратной части
Аппаратная часть
Международные бизнес-Стратегии
Интегральная схема
Integrated Development
Environment
Integrated Device Manufacturer
Institute of Electrical
and Electronic Engineers
Интегрированная среда разработки
Производитель
интегрированных устройств
Институт инженеров по электротехнике
и электронике

Список сокращений и определений
IF Intermediate Frequency
10, I/O Input-Output
IP Intellectual Property
ISA Instruction-Set Architecture
IS LI Institute for System
Level Integration
Instruction-Set Simulator
ISS
JTAG
LAN
LCD
MAC
Joint Test Action Group
Local Area Network
Liquid Crystal Display
Media Access Control; Also,
Multiply-Accumulator
MEMS Micro Electronic
Mechanical Systems
MoCN Model of Computation
MPSoC Multi-Processor System on Chip
MPU Microprocessor Unit
NoC Network on Chip
OCB On-Chip Bus
OCP Open Core Protocol
OCPIP Open Core Protocol
International Partnership
OFDM Orthogonal Frequency
Division Multiplexing
О MAPI Open Mobile Application
Processor Interface
OMG Object Management Group
OpenMORE MORE=Measure
of Reuse Excellence
OS Operating System
OSC Open SystemC Initiative
OVA Open Vera Assertions
OVL Open Verification Library
PBD Platform-Based Design
Промежуточная частота
Ввод-вывод
Интеллектуальная собственность
Архитектура системы команд
Институт интеграции
на системном уровне
Симулятор системы команд
Объединенная рабочая группа
по автоматизации тестирования
Локальная сеть
Жидкокристаллический дисплей
Протокол управления доступом
к (передающей) Среде,
также Умножитель-аккумулятор
Микроэлектронные
механические системы
Модель вычислений
Многопроцессорная система
на чипе (кристалле)
Блок Микропроцессора
Сеть на Чипе (кристалле)
Шина на Чипе (кристалле)
Открытый Протокол Процессоров
Международное партнерство ОСР
Ортогональное мультиплексирование
деления частоты
Открытый интерфейс процессора
мобильной системы
Рабочая группа по развитию стандартов
объектного программирования
Степень качества повторного
использования
Операционная система
Открытая инициатива по SystemC
Утверждения Open Vera
Открытая библиотека верификации
Проектирование на основе платформ

Список сокращений и определений 21 I
РСВ Printed Circuit Board
PCI Personal Computer Interface
PCS
PLD
PSL
QAM
QoS
RF
RISC
Personal Communication
System(U.S. version of GSM)
Programmable Logic Device
Property Specification
Language (Accellera)
Quad Adaptive Multiplexing
Quality of Service
Radio Frequency
Reduced Instruction-Set
RMM
Computer
Reuse Methodology Manual
RTL
RTOS
SCV
SDF
SDL
SERDES
SiP, SIP
SLD
SLI
SoC
SoP
SOPC
SPW
SW
TBD
TDD
Register-Transfer Level
Real-Time Operating System
SystemC Verification Library
Statically-Scheduled DataFlow
(Synchronous Dataflow)
Specification and Description
Language
Serializer-Deserializer
(High speed serial interface)
System in Package
System-Level Design
System-Level Integration
System on Chip
System on Package
System on Programmable Chip
Signal Processing Worksystem
Software
Transaction-Based Design
Top-Down Design; also,
Печатная плата
32-разрядная системная шина
с возможностью расширения
до 64 разрядов, взаимодействие через
которую происходит без участия CPU
Американская версия стандарта GSM
Программируемое
логическое устройство
Язык описания свойств (Accellera)
квадратурная адаптивная модуляция
Качество услуг
Радиочастота
ЭВМ с сокращенной системой команд
Руководство по методологии
повторного использования
Уровень регистровых передач
Операционная система
реального времени
Библиотека верификации SystemC
Синхронный поток данных
Язык спецификаций и описаний
Высокоскоростной последовательный
интерфейс
Система в корпусе
Проектирование на системном уровне
Интеграция на системном уровне
Система на кристалле (чипе)
Система в корпусе
Система на программируемом
кристалле (чипе)
Система обработки сигналов
Программное обеспечение
Проектирование на основе транзакций
Проектирование сверху-вниз

Список сокращений и определений
Timing-Driven Design
TLM Transaction-Level Model
or Modelling
UML
UMTS
USB
vc
vcc
VCI
vex
VHDL
VHSIC
VSI
WLAN
Unified Modelling Language
Universal Mobile
Telecommunication System
Universal Serial Bus
Virtual Component
Virtual Component Co Design
Virtual Component Interface
Virtual Component Exchange
VHSIC Hardware Description
Language
Very High-Speed
Integrated Circuit
Virtual Socket Interface
Wireless Local Area Network
или проектирование на основе задержек
Модель или моделирование
на уровне транзакций
Унифицированный язык моделирования
Универсальная система мобильных
телекоммуникаций
Универсальная последовательная шина
Виртуальный компонент
Совместимо проектирование
виртуальных компонентов
Интерфейс виртуальных компонентов
Биржа виртуальных компонентов
Язык описания аппаратной части
Сверхбыстродействующая
интегральная схема
Интерфейс виртуального «Гнезда»
Локальная радиосеть
(сеть с беспроводной связью)

Заявки на книги присылайте по адресу:
125319 Москва, а/я 594
Издательство «Техносфера»
e-mail: knigi@technosphera.ru
sales@technosphera.ru
факс: (095) 956 33 46
В заявке обязательно указывайте
свой почтовый адрес!
Подробная информация о книгах на сайте
http://www.technosphera.ru
Телефон издательства:
(095)234 01 10
В. Немудрое, Г. Мартин
Системы-на-кристалле.
Проектирование и развитие
Компьютерная верстка — Г.В. Зайцева
Дизайн книжных серий — СЮ. Биричев
Ответственный за выпуск — Л.Ф. Соловейчик
Формат 60x90/16. Печать офсетная
Гарнитура Ньютон
Печ.л. 13,5. Тираж 3000 экз. Зак. №2969.
Бумага офсет №1, плотность 80г/м
Издательство «Техносфера»
Москва, ул. Тверская, дом 10 строение 3
Циапозитивы изготовлены ООО «Европолиграфик»
Отпечатано на ГУРПП
г. Ржев, ул. Урицкого, дом 91