Document 531601
advertisement
Московский ордена Ленина, ордена Октябрьской Революции и ордена Трудового Красного Знамени. ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ им. Н. Э. БАУМАНА Факультет: Информатики и систем управления Кафедра: Проектирование и технология производства электронной аппаратуры (ИУ4) ______________________________________________________________________________ Реферат Система на кристалле. Структурные схемы. Особенности применения. Примеры реализации. Описание функционирования. По курсу: Студент: Проверил: Схемотехника ЭВС, комплексы и сети Гаврилов А.Е. ИУ4-103 (фамилия, инициалы) (индекс группы) Шпиев В.А. (фамилия, инициалы) дата сдачи отметка о защите Москва 2012 1 Оглавление СПИСОК СОКРАЩЕНИЙ И ТЕРМИНОВ ............................................................................................ 3 ВВЕДЕНИЕ ............................................................................................................................................... 4 СПОСОБЫ РЕАЛИЗАЦИИ СИСТЕМ НА КРИСТАЛЛЕ .................................................................... 5 ИСПОЛЬЗОВАНИЕ IP-БЛОКОВ............................................................................................................ 8 ОСНОВНЫЕ ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ SoC................................................................. 9 МАРШРУТЫ ПРОЕКТИРОВАНИЯ ASIC и SoC ............................................................................... 10 СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ SoC............................................................................................ 11 ОРГАНИЗАЦИЯ СРЕДСТВ ПРОЕКТИРОВАНИЯ ............................................................................ 13 СРЕДСТВА СИСТЕМНОГО ПРОЕКТИРОВАНИЯ ........................................................................... 14 СРЕДСТВА ФУНКЦИОНАЛЬНОГО ПРОЕКТИРОВАНИЯ ............................................................ 15 ЗАКЛЮЧЕНИЕ ....................................................................................................................................... 17 СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ ............................................................................... 18 2 СПИСОК СОКРАЩЕНИЙ И ТЕРМИНОВ АО – аппаратное обеспечение; ИС – интегральная схема; ПО – программное обеспечение; ПЛИС – программируемая логическая интегральная схема; СБИС – сверх большая интегральная схема; ASIC – Application Specific Integrated Circuits; ASSP – Application Specific Standard Products; CSoC – Configurable System on a Chip; DSM – Deep Submicron; PSoC – Programmable System on a Chip; SLI – System Level Integration; SoC – System on a Chip; SoPC – System on Programmable Chip; 3 ВВЕДЕНИЕ Интенсивный прогресс в области микроэлектроники за последние 10 лет привел к появлению принципиально нового класса СБИС – "систем на кристалле" (SoC – System on Chip). Это обусловлено, в первую очередь, существенным прогрессом технологии производства интегральных схем – степень интеграции достигает нескольких десятков миллионов вентилей на кристалле [1], а минимальные топологические размеры в ближайшее время составят 0,09 мкм. Очевидно, что для проектирования и тестирования таких СБИС необходимы принципиально новые подходы и средства проектирования. Сегодняшние реалии таковы, что: в условиях рынка прибыль в значительной степени зависит от временных затрат на проектирование; такие технические параметры СБИС, как производительность, площадь кристалла и потребляемая мощность, являются ключевыми элементами в продвижении товара на рынок; увеличение степени интеграции делает задачу верификации качественно более сложной; из-за особенностей технологии глубокого субмикрона (DSM – Deep Submicron) все труднее удовлетворять всем требованиям по временным ограничениям (timing); команды разработчиков высокоинтегрированных СБИС обладают различными знаниями и опытом в области проектирования, и часто при выполнении проектов СБИС расположены в различных частях мира. С другой стороны, при традиционном подходе к проектированию СБИС хороший дизайнер может работать со средней скоростью порядка 100 вентилей в день или 30 строк RTLкода [2] (эти цифры остаются постоянными на протяжении последних пяти лет). В этом случае, чтобы спроектировать СБИС типа ASIC (Application Specific Integrated Circuit) сложностью 100 тыс. вентилей, потребуется 1000 человеко-дней, т.е. команда из пяти человек сможет разработать такую СБИС за год. Следовательно, для разработки сложной СБИС, содержащей порядка 10 млн. вентилей, в течение одного года потребуется команда из 500 человек, что, безусловно, неприемлемо с точки зрения себестоимости разработки. Рисунок 1 – Зависимость стоимости разработки СБИС от технологии По более точным аналитическим прогнозам (рис.1), при переходе на технологии 0,18 мкм и менее применение существующей методологии проектирования влечет увеличение трудоемкости проектов до 250 человеко-лет, что совершенно неприемлемо. Кроме того, в последнее время постоянно растет доля затрат на разработку программного обеспечения (ПО) РЭА (рис.2). Если вести разработку ПО и СБИС раздельно, то увеличивается вероятность 4 выявления ошибок на этапах тестирования или эксплуатации всего комплекса аппаратуры, что приводит к дополнительным трудо- и времязатратам. Рисунок 2 – Отношение затрат на разработку программной и аппаратной части Выход из создавшейся ситуации очевиден – необходимо изменить методологию проектирования СБИС, и наиболее перспективным направлением представляется методология проектирования СБИС типа "система на кристалле". СПОСОБЫ РЕАЛИЗАЦИИ СИСТЕМ НА КРИСТАЛЛЕ В полной мере использовать возможности современных полупроводниковых технологий для достижения максимальной производительности, уменьшения потребляемой мощности и площади кристалла позволяет проектирование ASIC на основе библиотек стандартных элементов. Стоимость разработки при этом чрезвычайно высока в силу использования сложных дорогостоящих средств проектирования и необходимости создания большого числа масок (более двадцати). Кроме того, из-за сложности проектов высок риск ошибок, приводящих к необходимости перепроектирования и повторного изготовления комплекта масок. Рисунок 3 – Стоимость изготовления полного комплекта масок для различных технологий На рис.3 приведены графики изменения стоимости изготовления полного комплекта масок для различных технологий. Видно, что после внедрения новой технологии стоимость производства со временем постепенно снижается, но в целом по новейшим технологиям ее величина растет экспоненциально. Использование новейших технологий оказывается экономически оправданным только при проектировании изделий массового применения, таких 5 как процессоры, память, программируемая логика. Неудивительно, что число проектов ASIC в мире сокращается быстрыми темпами: с 10000 в 1998 году до 4500 в 2002 (из которых в массовое производство пошли только 3500 проектов). По некоторым оценкам, в 2003 году было начато менее 4000 проектов ASIC. Проектирование на основе ПЛИС не связано с затратами на запуск производства, поскольку предполагает использование стандартных интегральных схем. Относительно короткий цикл и низкая стоимость средств проектирования, возможность устранения ошибок путем перепрограммирования делают реализацию проектов на основе ПЛИС весьма привлекательной. Однако большая потребляемая мощность, низкая производительность и очень высокая стоимость кристаллов по сравнению с ASIC существенно ограничивают область применения ПЛИС. Компромиссным подходом в течение достаточно долгого времени было использование вентильных матриц, проектирование на которых, аналогично ASIC, ведется на основе библиотечных элементов, но в рамках единого, заранее разработанного и изготовленного конструктива. Базовые пластины для вентильных матриц изготавливаются массовым способом, а для создания новой интегральной схемы достаточно спроектировать и изготовить только заказные слои металла. Однако с ростом числа слоев металла при переходе на новые технологии количество заказных масок стало сравнимым с их количеством, требуемым для ASIC. При том, что в вентильных матрицах используется аналогичный ASIC продолжительный маршрут и дорогостоящие средства проектирования, а в самой концепции заложена избыточность площади кристалла, преимущества метода были сведены на нет и вентильные матрицы практически вышли из употребления. Рисунок 4 – Архитектура структурных ASIC фирмы Lightspeed Semiconductor Ниша, которую занимали вентильные матрицы, сейчас активно заполняется новыми гибридными технологиями под общим названием "структурные ASIC" (Structured ASIC). 6 Структурные ASIC состоят из заранее спроектированной и изготовленной матрицы макроячеек (рис.4), имеющих однородную структуру (в этом смысле они похожи на ПЛИС). Как правило, все компоненты, схемы синхронизации, тестирования и самодиагностики уже реализованы, и это существенно упрощает разработку. Требуется спроектировать только от одного до трех слоев металла для функциональной настройки макроячеек и реализации межсоединений между макроячейками. Стоимость запуска в производство при этом составляет порядка 10–20% от аналогичной величины для ASIC. Даже с учетом высокой стоимости изготовления по новейшим технологиям (см. рис.3) такие затраты вполне приемлемы для разработки SoC широкой номенклатуры. При разработке структурных ASIC заранее учитываются субмикронные эффекты (электромиграция, падение напряжения на линиях связей), взаимное влияние сигналов, реализация средств синхронизации и тестирования. Поэтому маршрут проектирования существенно упрощен по сравнению с традиционными ASIC и может включать только 2–3 системы для моделирования, синтеза и планирования площади кристалла с последующим проектированием топологии на фирме-изготовителе. Время проектирования топологии также значительно сокращается (три-четыре недели от передачи списка цепей на проектирование топологии до получения готовых прототипов). Направление структурных ASIC, возникнув около двух лет назад как переосмысление концепции вентильных матриц на новом этапе эволюции полупроводниковых технологий, активно развивается. Около двух десятков компаний, таких как LSI Logic, NEC, Fujitsu, AMI Semiconductor, Lightspeed Semiconductor, Chip Express, eASIC, предлагают свои решения в этой области. Можно привести следующие сравнительные оценки методов реализации SoC (для эквивалентных технологий). Плотность компоновки ПЛИС по сравнению с ASIC – 1% ( 90% площади кристалла ПЛИС используется только для программирования межсоединений), потребляемая мощность выше в 10–15 раз, максимальная производительность – в пределах 20%. Для структурных ASIC плотность компоновки в 50 раз выше, чем в ПЛИС, и, соответственно, составляет 40–60% от плотности стандартных ASIC. Максимальная производительность – 70%, потребляемая мощность выше в 2–3 раза, чем для стандартных ASIC. В целом аналитики полагают, что время широкого использования ASIC на основе библиотек стандартных элементов проходит. Конечно, за ними останется область массовых и уникальных по характеристикам изделий, но для большинства интегральных схем со средними объемами выпуска будут использоваться именно структурные ASIC, а ПЛИС прочно займут свою нишу в сфере низкопроизводительных приложений с малыми объемами выпуска. Прогнозируемый объем рынка структурных ASIC оценивается в 2–5 миллиардов долларов, которые практически целиком "изымаются" с рынка традиционных ASIC при сохранении положительной динамики роста рынка ПЛИС. Способы реализации систем на кристалле не ограничиваются вышеперечисленными методами. Существует ряд промежуточных вариантов, которые можно определить как конфигурируемые системы на кристалле (Configurable System on Chip – CsoC). Такие комбинированные методы строятся на сочетании нескольких подходов, могут включать полностью заказные блоки, например микропроцессорные ядра, блоки на основе библиотек стандартных элементов, структурных матриц и полей программируемой логики. Практической реализацией одного из таких методов является серия микросхем компании Triscend, которые могут включать поля программируемой логики, 32-разрядное процессорное ядро ARM7TDMI, микроконтроллер 8051. Компании Lightspeed и eASIC используют подход, при котором разрабатываются структурные блоки, встраиваемые в ASIC. Кристаллы компании Leopard Logic представляют собой комбинацию большого структурного блока и нескольких полей программируемой логики. Системы на кристалле в полной мере можно реализовать и на современных ПЛИС. Такие проекты получили название "системы на программируемом кристалле" (System on Programmable Chip – SoPC). Действительно, здесь могут присутствовать все компоненты, свойственные системам на кристалле в традиционном понимании: процессорные ядра, память, IP-блоки и т.д. Покупка Triscend компанией Xilinx в феврале этого года и разработка компанией Altera серии программируемых масками микросхем Stratix HardCopy показывают, что производители 7 традиционных ПЛИС, со своей стороны, стремятся выйти на рынок более эффективных решений. Средства проектирования по мере усложнения ПЛИС также усложняются, маршрут проектирования начинает походить на маршрут для традиционных ASIC. Включаются этапы планировки площади кристалла, физического синтеза и формальной верификации. Действительно, когда одна итерация цикла проектирования топологии ПЛИС объемом шесть миллионов вентилей занимает сутки, а количество итераций измеряется десятками, оценка временных и прочих ограничений на ранних стадиях, еще до проектирования топологии, становится актуальной задачей. К тому же, поскольку все большая часть проектов ASIC макетируется на ПЛИС (прогноз на ближайшее время – до 80% от общего числа), а успешные ПЛИС проекты могут переноситься на ASIC, желательно, чтобы и в маршруте, и в средствах проектирования заранее учитывалась возможность перехода на другой вариант реализации. Итак, между ASIC и ПЛИС развивается целый спектр методов реализации систем на кристалле, происходит взаимопроникновение, комбинирование подходов с целью поиска вариантов наиболее эффективных с технической и экономической точки зрения. Структурные ASIC оказываются реальной альтернативой как ПЛИС, так и ASIC. Объемы производства, при которых их применение может быть экономически целесообразно, оцениваются от одной тысячи до ста тысяч микросхем в год. ИСПОЛЬЗОВАНИЕ IP-БЛОКОВ Одновременно с появлением концепции системы на кристалле возникли идеи создания методологии проектирования на основе унифицированных наборов готовых базовых блоков (платформ). Интерфейсы компонентов платформы (процессоров, блоков памяти и управления, шинных интерфейсов и др.) в рамках достаточно широкого класса задач должны быть унифицированы, чтобы новые устройства можно было "собирать" из блоков, как конструктор. Причем "собирать" на системном уровне, уровне функционального описания, проводя анализ и глобальную оптимизацию всей системы в целом, а далее использовать готовые аппаратные решения, заложенные в описаниях базовых блоков (IP-блоков). В силу проблем с созданием переносимой универсальной аппаратной начинки блоков, которую можно было бы переиспользовать при производстве по различным технологиям, на различных фабриках в целом внедрение такого подхода в качестве универсальной методологии не оправдалось. Однако это дало толчок развитию индустрии IP-блоков. В результате сейчас существует большой выбор библиотек специализированных IP-блоков для различных прикладных областей и технологий изготовления микросхем, в частности библиотек IP-блоков для ПЛИС, представленных в виде синтезируемых блоков на языках высокого уровня, списков цепей в элементном базисе производителей ПЛИС и готовых макросов с топологической реализацией. Структурные ASIC также обычно сопровождаются библиотеками IP-блоков. Это позволяет говорить о них как о готовых платформах для реализации систем на кристалле. Например, библиотека структурных ASIC компании LSI Logic включает более четырехсот элементов. Кроме того, может использоваться библиотека IP-блоков CoreWare, содержащая процессоры, периферийные блоки, компоненты шины AMBA, интерфейсы памяти и др. Для реализации процессорных ядер (ARM, MIPS, сигнальный процессор ZSP) предусмотрены специальные области. Если такие процессоры не используются, в этих областях можно реализовывать и произвольную логику. Процессоры, как и другие IP-блоки библиотек, верифицированы и могут использоваться в виде готовых макросов. 8 ОСНОВНЫЕ ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ SoC Сегодня нет четко детерминированного определения СБИС типа "система на кристалле", однако практика показывает, что SoC должна изготавливаться по технологии не ниже 0,35 мкм и содержать не менее 1 млн. вентилей. В самом общем виде, в состав SoC могут входить такие компоненты, как (рис.5): микропроцессор (или микропроцессоры) и подсистема памяти (статической и/или динамической). Тип процессора может варьироваться от простейшего 8-разрядного до высокоскоростного 64-разрядного RISC-процессора; шины – центральная (высокоскоростная) и периферийная – для обмена данными между блоками; контроллер внешней памяти (например, DRAM, SRAM или Flash); контроллер ввода/вывода информации: PCI, Ethernet, USB и т.п.; видеодекодер, например MPEG2, AVI, ASF; таймер и контроллер прерываний; общий интерфейс ввода/вывода (например, для вывода на светодиодный индикатор информации о наличии питания); интерфейс UART (universal asynchronous receiver/transmitter) и т.п. Рисунок 5 – Структурная схема SoC Столь сложная и разнообразная структура диктует особые требования к принципам проектирования SoC. В основе методологии проектирования SoC лежит принцип повторного использования Intellectual Property блоков (IP-блоков), разрабатываемых целенаправленно или в рамках какоголибо проекта. По аналогии с системой на плате, где в качестве компонентов выступают готовые микросхемы, система на кристалле конструируется из повторно используемых блоков. IP-блоки могут быть двух типов: soft IP, описанные на RTL-уровне, и hard IP – на топологическом уровне. Иногда выделяют firm IP, в состав которых входят разные типы представлений – от RTL до списка цепей с планировкой субблоков. Отметим, что сегодня для обозначения повторно используемых (reuse) блоков наиболее часто используют термин IP-блок, т.е. блок, представляющий собой объект интеллектуальной собственности. Однако в ходу и другие термины: СФ-блок (в основном в пределах РФ), macro и core (обычно обозначает блоки типа центральный процессор CPU или процессор цифровой обработки сигнала DSP). Некоммерческая международная организация VSIA (Virtual Socket Interface Alliance) (www.vsi.org), основная задача которой – разработка нормативной документации по проблемам проектирования IP-блоков и SoC на их основе, использует собственное обозначение – VC (Virtual Component). 9 Одна из проблем проектирования SoC – создание IP-блоков. Практика показывает, что стоимость reuse-блока в среднем в 10 раз превышает стоимость аналогичного однократно используемого блока, а для процессоров эта величина на порядок выше. По этой причине reuseблоки предназначены, как правило, для решения общих, логически формализуемых задач, например, MPEG-кодер, CPU, DSP, USB и PCI интерфейсы и т.п. При выборе IP-блоков учитывается стоимость готового блока и оцениваются затраты на разработку собственно блока. Другая принципиальная особенность SoC – это наличие программируемых блоков (процессоров). Поэтому SoC – не просто интегральная схема (ИС), а комплекс, в состав которого входят как аппаратная часть (собственно кристалл), так и программная – встраиваемое программное обеспечение (ПО). Следовательно, маршрут проектирования SoC должен содержать операции по совместной верификации и отладке программной и аппаратной частей. Еще одна особенность SoC – устойчивый рост доли смешанных цифроаналоговых систем в общем объеме SoC, поэтому в маршрут проектирования должны быть включены этапы по совместной разработке и верификации цифровой и аналоговой частей SoC. МАРШРУТЫ ПРОЕКТИРОВАНИЯ ASIC и SoC Традиционный маршрут проектирования ASIC (рис.6) начинается с разработки спецификации на проектируемую ASIC. Для сложных СБИС (например, устройства обработки графической информации), в состав спецификации включается алгоритм обработки информации, который затем используется разработчиками для написания RTL-кода. Рисунок 6 – Маршрут проектирования ASIC После функциональной верификации происходит синтез СБИС виде списка цепей. Здесь же выполняется верификация временных временные требования удовлетворены, список цепей передается размещение элементов и трассировка цепей. В конце создается и на вентильном уровне в требований. Как только на физический синтез: тестируется физический 10 прототип СБИС, на основе которого впоследствии выполняется системная интеграция и тестируется ПО. Используя такой маршрут, можно проектировать схемы сложностью не более 100 тыс. вентилей по технологии не ниже 0,5 мкм. Это связано с тем, что проект выполняется по нисходящему принципу и не происходит возврат на предыдущие фазы. Например, RTL-дизайнер не может прийти к системному разработчику и сказать, что его алгоритм нереализуем, или группа логического синтеза не может попросить изменить RTL-код, чтобы добиться необходимых временных параметров. Для схем, изготавливаемых по технологиям глубокого субмикрона, такой маршрут вообще не приемлем, поскольку особенности физической реализации должны учитываться уже на логическом уровне проектирования. Многие зарубежные фирмы переходят от традиционной нисходящей модели проектирования к новой спиралевидной модели (рис.7) [2]. Здесь проектирование выполняется одновременно по четырем направлениям: разработка ПО, разработка RTL-кода, логический и физический синтез. При этом в процессе работы группы разработчиков обмениваются результатами проектирования. Новая модель характеризуется такими полезными свойствами, как параллельная разработка аппаратного обеспечения (АО) и ПО, параллельная верификация и логический синтез блоков, планировка, размещение и трассировка включены в процесс синтеза, разрешен возврат на предыдущие фазы проектирования и корректировка результатов. СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ SoC Фактически весь процесс разработки SoC делится на четыре этапа: разработка архитектуры SoC на системном уровне, выбор имеющихся IP-блоков из базы данных (внутри фирмы, других фирм или поставщиков IP-блоков), проектирование оставшихся блоков и интеграция всех блоков на кристалле. Остановимся на системном уровне. Рисунок 7 – Спиралевидная модель процесса проектирования SoC Начальный этап проектирования заключается в рекурсивной разработке, верификации и уточнении набора спецификаций до такой степени детализации, чтобы на их основе можно было начать создавать RTL-код. Быстрая разработка четких, полных и последовательных спецификаций – сложная, трудоемкая и ответственная задача. Если четко знать, что надо построить, то ошибки при дальнейшей реализации могут быть быстро обнаружены и устранены. 11 В противном случае можно не выявить ошибку на протяжении всего цикла проектирования вплоть до изготовления чипа. Спецификации описывают поведение системы [2], точнее – как управлять системой, чтобы добиться от нее нужного поведения. В этом смысле понятие спецификации в значительной мере связано с понятием интерфейса. Функциональная спецификация описывает интерфейс системы или блока так, как его видит внешний пользователь. Она содержит информацию о контактах, шинах, регистрах и о том, как с ними обращаться. Архитектурная спецификация описывает взаимодействия между частями блока и поведение на системном уровне. Спецификации разрабатываются как для аппаратной, так и для программной части проекта. Для аппаратной части спецификации должны включать список выполняемых функций, внешний интерфейс к другим блокам (контакты, шины, протоколы), интерфейс с ПО (регистры), временные параметры, быстродействие, особенности физического уровня (площадь кристалла, потребляемая мощность). Для программной части в спецификации необходимо описать выполняемые функции, временные параметры, быстродействие, интерфейс к аппаратной части, структуру и ядро. Традиционно спецификации пишутся на естественных языках (русский, английский…), что вносит в них неопределенность и ошибки. Чтобы избавиться от этих проблем, многие компании начинают использовать исполняемые спецификации, описанные на языках программирования высокого уровня С, С++ или вариации С++, например, SystemC (www.systemc.org) [3]. Для описания аппаратуры обычно используют языки VHDL или Verilog. Разработка исполняемых моделей позволяет верифицировать основные выполняемые функции и интерфейсы на ранних стадиях проектирования, задолго до детализации проекта. Рисунок 8 – Маршрут системного проектирования SoC Процесс проектирования SoC на системном уровне (рис.8) начинается с формулирования целей и задач, выполняемых SoC. На начальном этапе следует определить основные эксплуатационно-технические свойства: требуемое быстродействие, допустимую потребляемую мощность и т.п. На основании этих свойств создается системная спецификация, которая может выступать частью технического задания на разработку системы. Как правило, этот этап не требует средств САПР. Затем создается высокоуровневая поведенческая модель всей разрабатываемой системы. Она, как правило, строится в виде блок-схемы. Для верификации разработанной поведенческой модели создается тестовое окружение системы (Testbench), которое включает в себя генераторы входных сигналов, тестовые последовательности и блоки отображения выходной информации. 12 Тестовое окружение должно максимально полно проверять работу системы. Впоследствии на основе этого тестового окружения будут разрабатываться тестовые векторы для верификации проекта на нижних уровнях проектирования и для тестирования опытных образцов СБИС. Поведенческая модель верифицируется путем компьютерного моделирования. Если в процессе верификации обнаруживаются какие-либо отклонения от требований системной спецификации, то модель корректируется и моделирование повторяется. Кроме верификации, на данном шаге можно выбрать оптимальные параметры алгоритма системы. Например, разработчик может найти компромисс между вычислительной сложностью и точностью. Поскольку SoC включает одно или несколько программируемых процессорных ядер, на следующем этапе разработчик должен принять решение о том, какие части поведенческой модели будут впоследствии реализованы на аппаратном уровне, а какие – на программном в виде встроенного в СБИС программного обеспечения. Также необходимо определить, каким образом будут взаимодействовать программная и аппаратная части, т.е. следует разработать интерфейс между АО и ПО. Здесь же определяется общая архитектура SoC: тип процессора, тип памяти и ее объем, аппаратные блоки, интерфейс АО-ПО, тип используемой шины, описание программной части и т.п. В итоге формируется набор спецификаций на разработку программного обеспечения и на разработку каждого аппаратно реализуемого блока. В методологии проектирования ASIC программно-аппаратная верификация выполняется только после изготовления опытного образца. Возникающие при этом ошибки можно исправить лишь соответствующими изменениями ПО, не переделывая сам кристалл. Такой метод неприемлем для SoC, поскольку из-за большой сложности схемы исправить ошибки АО путем корректировки ПО очень трудно, а зачастую просто невозможно. Поэтому в маршрут проектирования на разных уровнях вводится операция программно-аппаратной верификации. Наиболее ответственны в этом смысле этапы функционального и логического проектирования. Программно-аппаратная верификация системного уровня сегодня не является обязательной операцией. Тем не менее, многие разработчики включают ее в маршрут проектирования SoC. В качестве аппаратной части здесь выступают исполняемые спецификации аппаратно реализуемых блоков, в качестве программной – прототип ПО. В результате можно удостовериться, что аппаратная часть, разрабатываемая в соответствии с имеющимися спецификациями, будет корректно работать под управлением встраиваемого ПО в режиме реального времени. ОРГАНИЗАЦИЯ СРЕДСТВ ПРОЕКТИРОВАНИЯ На сегодняшний день реально не существует ни одной интегрированной системы САПР, способной эффективно решать задачи проектирования систем на кристалле во всем диапазоне возможных способов реализации. Производители интегрированных САПР стараются поддерживать внутри своих систем весь маршрут проектирования (от спецификации до физической реализации), но только для определенного класса микросхем. Например, широко известные САПР компаний Xilinx и Altera (как и САПР других производителей ПЛИС) ориентированы исключительно на собственные микросхемы. Средства проектирования ASIC вроде бы не привязаны к конкретным производителям и технологиям, но и они рассчитаны только на проектирование в базисе библиотек стандартных элементов и не поддерживают работы со специфическим элементным базисом и жесткими конструктивами кристаллов. Образно говоря, все интегрированные системы выстроены "вертикально" и опираются на определенный способ физической реализации. Но если предметно посмотреть на такие САПР, окажется, что интегрированные маршруты проектирования все равно состоят из отдельных систем (моделирования, синтеза и др.), каждая из которых имеет свой пользовательский интерфейс, систему команд, базу данных, а взаимодействие между системами основано на стандартных интерфейсах. К счастью, основные этапы проектирования (спецификация проекта, моделирование, верификация, логический синтез, физическая реализация) определены достаточно четко и поддерживаются стандартными интерфейсами. Это позволяет без потери эффективности и дополнительных затрат на интеграцию комбинировать средства проектирования различных производителей, выбирая те, которые наилучшим образом отвечают решаемым задачам. 13 С целью обеспечения единства инфраструктуры и максимальной унификации маршрутов проектирования, на наш взгляд, необходимо отойти от "вертикального" сегментирования средств проектирования по способам физической реализации или производителям САПР, и перейти к "горизонтальному" делению по классам задач, решаемых на отдельных этапах маршрута проектирования. В общем маршруте проектирования можно выделить три больших этапа, или уровня проектирования, а именно: системный уровень, где производится определение и спецификация основных функций проектируемой системы, создание исполняемой системной модели, анализ алгоритмов, протоколов, сценариев работы и общих функциональных характеристик; функциональный уровень, связанный с разработкой спецификаций функциональных блоков на языках высокого уровня описания аппаратуры – Verilog или VHDL, их верификацией, переходом в элементный базис производителя микросхем средствами логического синтеза; уровень проектирования топологии, где выполняется реализация проекта на физическом уровне с детальным размещением, трассировкой, генерацией тестовых структур и верификацией топологии. Выбор средств проектирования топологии определяется способом реализации. Для ПЛИС – это средства конкретного производителя. Для ASIC проектирование топологии сейчас все больше выполняется специальными дизайн-бюро, которые имеют полный набор всех необходимых средств проектирования. Связано это как с ростом стоимости средств проектирования (пропорциональной росту стоимости производства при переходе на новые технологические нормы), так и с необходимостью наличия специальных навыков и опыта работы в области субмикронной и нанотопологии, где ошибки проектирования стоят как никогда дорого. Для структурных ASIC проектирование топологии выполняется изготовителем, как правило, с использованием специально адаптированных под особенности конкретной архитектуры коммерческих САПР. В любом случае, когда сейчас говорят о разработке ASIC, речь обычно идет о доведении проекта до уровня описания списка соединений в библиотечном базисе производителя и (при технологических нормах ниже 0,25 микрон) прототипа размещения элементов, с последующей передачей этих данных на завершающие этапы физического проектирования. Поэтому с точки зрения унификации маршрутов проектирования интерес представляют первые два уровня проектирования – системный и функциональный. СРЕДСТВА СИСТЕМНОГО ПРОЕКТИРОВАНИЯ Понятие системного уровня проектирования фактически включает в себя все, что лежит выше уровня разработки RTL. Здесь создается модель исполняемой спецификации, которая служит эталоном поведения проектируемой системы на всех последующих этапах. В системном проектировании можно выделить три уровня детализации: уровень "миссии" и выбора общей концепции построения системы, включающий моделирование операционной среды, в которой будет работать проектируемая система, определение статических и динамических сценариев, планирование целевых задач; архитектурный уровень с моделированием и анализом производительности систем, сетевых архитектур и протоколов, пропускной способности каналов; уровень микроархитектуры, т.е. моделирование и анализ алгоритмов, протоколов, схем разрешения конфликтов на шинах, методов управления памятью, программно-аппаратное разделение и разработка программного обеспечения (драйверы и др.). Если первые два уровня относятся к задаче концептуального построения и анализа системы, то микроархитектура непосредственно связана с последующим этапом функционального проектирования. Сегодня, когда методология проектирования на RTL-уровне в общем устоялась, именно в области средств проектирования микроархитектуры инновации наиболее активны. В первую очередь это связано с применением языка С/С++ и производных языков на его основе, таких как SystemC, Handel-C, Stream-C и других для разработки моделей аппаратных блоков. Идея использования моделей высокого уровня, реализованных на языках 14 программирования не нова, но сейчас поддержка таких языков обеспечивается не только в системах моделирования, но и в системах синтеза. Так, проекты созданные в одной из популярных систем разработки и моделирования алгоритмов цифровой обработки сигналов Matlab/Simulink, обычно использовались как спецификации для ручного кодирования моделей на уровне RTL. Разработанная компаний AccelChip система синтеза высокого уровня теперь позволяет сгенерировать синтезируемые RTL-модели на языках VHDL и Verilog напрямую из Matlab с поддержкой автоматического преобразования арифметики плавающей точки в фиксированную. Другой подход используется компанией Celoxica в системе DK2 Design Suite, которая реализует методологию программного компилятивного проектирования. Среда проектирования позволяет выполнить общую модель и верификацию проекта на языке С, провести разделение на программную и аппаратную части и напрямую синтезировать последнюю в элементный базис ПЛИС или в код VHDL/Verilog. Поддерживаются языки C, C++, SystemC и Handel-C, а также компиляция исходных кодов в процессорные ядра, например Xilinx MicroBlaze. Это дает возможность, не меняя исходной спецификации алгоритма, быстро реализовать его в макетном варианте на процессорном ядре ПЛИС, провести оптимизацию с частичной или полной аппаратной реализацией и затем, при необходимости, сгенерировать код RTL для перевода на ASIC. Обеспечение целостности исходных спецификаций при их трансформации с верхнего уровня на уровень функционального проектирования имеет принципиальное значение. Поэтому фирмы-разработчики систем логического моделирования стремятся обеспечить совместное моделирование и поддержку VHDL, Verilog, C/C++, SystemC и других языков из единой интегрированной среды проектирования. Например, помимо перечисленных языков, системы моделирования компании Aldec обеспечивают совместное моделирование с Matlab/Simulink, имеют встроенные системы отладки С/С++ и Handel-C и встроенные интерфейсы с системами AccelChip и Celoxica, так что разработчики могут в рамках единой среды проектирования выполнять разработку и отладку кода, моделирование и синтез с гибкой настройкой системы на свой маршрут проектирования. СРЕДСТВА ФУНКЦИОНАЛЬНОГО ПРОЕКТИРОВАНИЯ Функциональный уровень на сегодняшний день остается основным при проектировании цифровых систем независимо от их физической реализации. Задача разработчика на функциональном уровне – создать RTL-описание системы, из которого можно средствами логического синтеза получить работоспособный проект. Поэтому к средствам функционального проектирования обычно относят средства моделирования и отладки RTL-кода а также средства логического синтеза из RTL-описаний. Процесс отладки RTL-кода носит итерационный характер. Уменьшение числа итераций – прямой путь к сокращению стоимости и сроков разработки. Решение этой задачи напрямую связано с созданием средств контроля качества исходного кода, оценки его реализуемости на ранних стадиях выполнения проектов еще до этапа логического синтеза. Кроме того, использование таких средств позволяет обеспечить переносимость проектов с ПЛИС на ASIC. Не секрет, что разработчики ПЛИС зачастую не заботятся о качестве создаваемого VHDL- или Verilog- описания. Ведь всегда можно поправить код и перепрограммировать ПЛИС. А когда работоспособный вариант получен, то до чистки и оптимизации руки, как правило, уже не доходят. В результате, казалось бы, уже выполненный проект при переносе на ASIC требует существенной переработки и детальной повторной верификации. Использование средств контроля качества на ранних стадиях позволяет значительно облегчить задачу переноса. Первые поколения таких систем были ограничены лишь проверкой семантики, сейчас появились системы, которые учитывают целостность, завершенность проекта, стиль кодирования, временные ограничения, выполняют анализ площади блоков, нетрассируемых структур и времени распространения сигналов. Важно здесь то, что эти системы дают возможность разработчику оценить реализацию своего проекта на ранней стадии без необходимости иметь знания о физических аспектах дальнейших этапов проектирования. Более того, такой формальный анализ кода на уровне RTL не только повышает качество проекта и 15 сокращает число итераций при логическом синтезе, но и в перспективе дает возможность передачи на завершающие этапы проектирования в специализированные дизайн-центры не списка цепей в элементном базисе производителя, а RTL-кода на языках VHDL или Verilog. Например, компании LSI Logic и NEC для анализа проектов с учетом возможности их реализации на своих структурных ASIC используют специально настроенный САПР компании Tera Systems. Компания IBM также использует средства Tera Systems в перспективном маршруте проектирования ASIC c приемом от заказчиков на финальное проектирование кода на уровне RTL. Использование предварительного анализа – вещь, конечно, очень полезная, но в любом случае рабочей лошадью для отладки RTL-кода служат средства моделирования. Разработчик создает новые фрагменты кода, запускает моделирование полученной системы, после анализа результатов вносит изменения в код... И так до тех пор, пока не добьется требуемых результатов моделирования. Для ПЛИС, где в основе проектирования лежит принцип "всегда можно все исправить", потребительские характеристики систем моделирования определяются простотой, удобством отладки проектов, низкой стоимостью. Для ASIC (в том числе и структурных) нужно "сделать сразу все правильно". Поэтому основным здесь становится качество логической и временной верификации, даже за счет высокой стоимости систем моделирования. Сегодня наиболее популярными системами моделирования являются продукты компаний Aldec, Cadence, Mentor Graphics и Synopsys. Если средства Cadence и Synopsys в основном используются в маршрутах проектирования ASIC, то системы моделирования Active-HDL, Riviera компании Aldec и ModelSim компании Mentor Graphics поддерживают также всех производителей ПЛИС. Так, САПР Active-HDL обеспечивает единую интегрированную среду проектирования и моделирования для ПЛИС любых производителей, содержит средства групповой разработки, управления проектами и библиотеками, кросс-отладки и анализа тестового покрытия, текстовые и графические редакторы, а вместе с системой Riviera, включающей в себя ряд специальных средств для верификации ASIC, предоставляет единую среду проектирования для всех возможных способов реализации проектов. До тех пор, пока передача проекта на разработку топологии осуществляется на уровне списка цепей, разработчикам функционального уровня необходимо будет иметь у себя средства логического и физического синтеза. При всем многообразии подобных средств наиболее универсальным на сегодняшний день является продукт компании Synplicity. Средства Synplicity позволяют проводить логический и физический синтез для ASIC и ПЛИС любых производителей, поддерживают макетирование ASIC на ПЛИС с возможностью автоматического разбиения проекта (с сохранением целостности) на множество ПЛИС, имеют средства отладки прошивок ПЛИС на уровне исходного RTL-описания. Компания Synplicity наиболее заметна и в плане поддержки синтеза для структурных ASIC. Для структурных ASIC можно использовать и традиционные средства логического синтеза ASIC. Но достижение хороших результатов при логическом синтезе возможно только при специальной настройке на элементный базис используемых структурных ASIC ( обычно более крупный, ближе к ПЛИС, включающий мультиплексоры, триггеры, память). Показательно, что именно систему физического синтеза Synplicity AmplifyASIC, адаптированную под архитектуру своих структурных ASIC, используют такие компании, как LSI Logic и NEC. В заключение надо заметить, что хотя каждый из производителей строит свой маршрут проектирования, ориентированный на конкретную архитектуру, в целом направление структурных ASIC стимулирует развитие адаптивных коммерческих САПР и методологии функционального проектирования на основе средств формального анализа и контроля реализуемости RTL-описаний. Это может иметь широкое прикладное значение. Эффективный контроль и прогнозирование на функциональном уровне существенно сокращают число итераций и время проектирования. А создание адаптивных средств САПР для отдельных этапов проектирования (моделирование, синтез), при стандартизации переходов от этапа к этапу, позволит обеспечить более высокую степень технологической (от способа реализации) и организационной (от производителя САПР) независимости при организации разработок систем на кристалле. 16 ЗАКЛЮЧЕНИЕ Очевидно, что системы на кристалле, базирующиеся на ASIC, являются в настоящее время наиболее рациональным решением. Любой реализованный ASIC дешевле самого изысканного программируемого или конфигурируемого решения. Однако цикл проектирования изделий этого класса сложен и длителен, а стоимость разработки и верификации проектов остается высокой. И до сих пор не реализована даже частичная конфигурируемость микросхем класса ASIC. Поэтому SLI в полном смысле этого слова еще далека от оптимальной реализации на ASIC, так как не достигнут экстремум многопараметрической зависимости «цена — объем производства — многофункциональность — простота разработки и сопровождения». Системы на кристалле, базирующиеся на стандартных изделиях программируемой логики традиционных архитектур, являются приемлемой альтернативой ASIC, хотя и проигрывают последним в стоимости и производительности конечного изделия. И поскольку практически все современные системы содержат в себе потоки данных и управления, то реализация системного уровня интеграции на FPGA общего назначения будет неэффективной. Микросхемы FPGA пока еще не являются приемлемым решением для изделий SoC или SLI, а простое увеличение емкости FPGA не есть ценный с практической точки зрения выход. Сейчас постепенно снижаются требования к объему начальных капиталовложений для заказа и производства ASIC. Так, если в 1998 г. были необходимы начальные инвестиции в изделие ASIC на сумму не менее $100 тыс., то сейчас многие проекты могут быть реализованы при объеме начальных затрат около $20 тыс. Количество микросхем с фиксированной архитектурой (в том числе универсальных), с помощью которых в кратчайшие сроки можно «собрать» требуемое конечное изделие, увеличивается. Однако остается общая проблема получения малогабаритного, функционально насыщенного, универсального, малопотребляющего класса микросхем, которые, помимо всего прочего, должны быть еще и реконфигурируемыми. Представьте: один и тот же тип кристалла CSoC может решить несколько задач, например, заменить линейку серийно выпускаемых микроконтроллеров с различными периферийными блоками. А если выпускается несколько разновидностей таких микросхем CSoC с идеологически разными архитектурными особенностями? Полупроводниковая промышленность должна совместить два в корне различных требования: аппаратный системный уровень интеграции на одном кристалле (ASIC) и временные преимущества для выхода на рынок новой продукции (программируемая логика). Многие фирмы-производители пытаются реализовать эти требования, предлагая различные компромиссы между темпами выхода на рынок конечных изделий и возможностью последующего конфигурирования системы самим пользователем. Оптимальное решение, которое появится в будущем, должно быть изделием общего назначения, стандартным продуктом, реконфигурируемой системой на кристалле, способным предоставить пользователям качественно новые возможности. С ростом количества производителей микросхем CSoC различных архитектур цены на конечную продукцию будут постепенно снижаться, а ассортимент — расти. Вполне возможно, что когда-нибудь родится и некое «универсальное» решение. 17 СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 1. Henry Chang, Larry Cooke, Merril Hunt, Grant Martin, Andrew McNelly, Lee Todd. Surviving the SOC Revolution// Kluwer Academic Publishers, Boston/Dordrech/London, 1999. 2. Michael Keating, Pierre Bricaud. Reuse Methodology Manual, Third Edition// Kluwer Academic Publishers, Boston/Dordrech/London, 2002. 3. Немудров В., Мартин Г. Системы на кристалле. Проектирование и развитие. — М.: Техносфера, 2004, с. 216. 4. Шагурин И., Шалтырев В., Волов А. «Большие» FPGA как элементная база для реализации систем на кристалле//Электронные компоненты, 2006, №5, c.83—88. 18
