Методология проектирования систем на кристалле. Основные принципы, методы, программные средства.

Н. Д. Евтушенко, В. Г. Немудров, И. А. Сырцов «Электроника» №3 2003 г.

Источник: http://www.mriprogress.msk.ru/news.php@id=7

Cтатья открывает цикл публикаций по проблеме проектирования «систем на кристалле». Изложены характерные особенности СБИС типа «система на кристалле», сформулированы основные принципы новой методологии проектирования, представлена модель маршрута проектирования. Рассмотрен системный уровень проектирования: назначение, задачи, маршрут, программные средства.

Введение

Интенсивный прогресс в области микроэлектроники за последние 10 лет привел к появлению принципиально нового класса СБИС – «систем на кристалле». Это обусловлено, в первую очередь, существенными достижениями в части технологии производства интегральных схем (в настоящее время ведутся работы по внедрению технологии с минимальным топологическим размером 0,09 мкм). Уже сейчас степень интеграции достигает нескольких десятков миллионов вентилей на кристалле. Вполне очевидно, что для проектирования и тестирования соответствующих СБИС («систем на кристалле») необходимы принципиально новые подходы, методы и системы проектирования.

Можно выделить две характерные для «систем на кристалле» особенности: использование IP-блоков в качестве основных структурных элементов и наличие встраиваемых программируемых процессорных ядер. Также следует отметить постоянный рост доли цифроаналоговых СБИС в общем объеме изготавливаемых в мире высокоинтегрированных СБИС. Вследствие этих и многих других причин, традиционный маршрут проектирования обычных СБИС не может использоваться для разработки «систем на кристалле». На сегодняшний день существует объективная необходимость в создании методологии проектирования СБИС типа «система на кристалле».

Данная статья открывает цикл публикаций, посвященных вопросам проектирования «систем на кристалле». В статье кратко изложены особенности характерные для СБИС типа «система на кристалле», сформулированы основные принципы новой методологии проектирования, представлена модель маршрута проектирования.

В рамках данной статьи подробно рассмотрен системный уровень проектирования: назначение, задачи, маршрут, программные средства. Предполагается, что другие фазы проектирования (функциональная, логическая и физическая) будут представлены в следующих публикациях.

1. Перспективы развития проектирования в области микроэлектроники: от ASIC к SoC

Неуклонный рост требований к радиоэлектронной аппаратуре (РЭА) со стороны заказчика, как по функциональным, так и по эксплуатационным качествам заставляет разработчиков создавать все более и более сложные устройства. В то же время значительный прогресс в области технологий производства СБИС (0,35 мкм и менее) позволил создавать чипы со степенью интеграции более 10 млн. вентилей на кристалле [1]. Таким образом, основной проблемой становится проектирование соответствующих СБИС.

Произведем простой расчет. При использовании традиционных методов проектирования хороший дизайнер может выполнять проект со средней скоростью порядка 100 вентилей в день или 30 строк RTL кода [2]. (Эти цифры остаются постоянными на протяжении последних пяти лет.) В этом случае, чтобы спроектировать СБИС типа ASIC (Application Specific Integrated Circuit) сложностью 100 тыс. вентилей потребуется 1000 человеко-дней, т.е. команда из 5-ти человек сможет разработать такую СБИС в течение года. Следуя данной логике, чтобы разработать сложную СБИС порядка 10 млн. вентилей в течение одного года потребуется команда из 500 человек, что, безусловно, неприемлемо с точки зрения себестоимости разработки.

По более точным аналитическим прогнозам (рис. 1), если при переходе на новые технологии (0,18 мкм и менее) пользоваться существующей методологией проектирования, то стоимость проекта увеличивается до 250 человеко-лет, что также неприемлемо для заказчика. (Информация на рисунках 1, 2, 4 предоставлена фирмой Cadence Design Systems.)

Следует отметить, что в последнее время сложилась тенденция постоянного роста доли затрат на разработку программного обеспечения (ПО) РЭА (рис. 2). Если вести разработку ПО и СБИС раздельно, то увеличивается вероятность выявления ошибок на этапах тестирования или эксплуатации всего комплекса аппаратуры.

Выход из создавшейся ситуации очевиден – необходимо изменить методологию проектирования СБИС. Наиболее перспективным направлением в настоящий момент представляется методология проектирования СБИС типа «система на кристалле» (далее просто система на кристалле). В иностранной литературе - System-on-Chip (SoC).

Можно выделить дополнительно ряд причин, по которым необходимо переходить на новую методологию проектирования:

• в условиях рынка прибыль в значительной степени зависит от времени проектирования;

• такие технические параметры СБИС, как производительность, площадь кристалла и потребляемая мощность являются ключевыми элементами в продвижении товара на рынок;

• увеличение степени интеграции делает задачу верификации качественно более сложной;

• из-за новых особенностей технологии глубокого субмикрона (DSM – Deep Submicron) все труднее удовлетворить всем требованиям по временным ограничениям (timing);

• команды разработчиков высокоинтегрированных СБИС имеют различный уровень знаний и опыта в области проектирования, и часто при выполнении проектов СБИС расположены в различных частях мира.

2. Основные принципы методологии проектирования SoC

В основе методологии проектирования SoC лежит принцип повторного использования блоков (reuse). Т.е. сложные функциональные блоки, разрабатываемые в рамках одного проекта или специально, затем используются в других проектах. По аналогии с системой на плате, где в качестве компонент выступают готовые микросхемы, система на кристалле конструируется из повторно используемых блоков.

В настоящее время для обозначения reuse-блока наиболее часто используется термин IP-блок (Intellectual Property), т.е. блок, представляющий собой объект интеллектуальной собственности. Одновременно с ним используются и другие термины:

• СФ-блок (сложный функциональный блок) - используется в основном в пределах РФ;

• macro;

• core – обычно применяется для обозначения блоков типа CPU (Central Processor Unit) или DSP (Digital Signal Processor);

• VC (Virtual Component) введен VSIA (Virtual Socket Interface Alliance) – некоммерческой международной организацией, основной задачей которой является разработка нормативной документации по проблемам проектирования IP-блоков и SoC на их основе (www.vsi.org);

• блок (Block) – функционально-завершенная часть SoC или ASIC, не обязательно reuse;

• субблок (Subblock) – часть блока.

IP-блоки могут быть двух типов: «мягкие» (soft) описанные на RTL-уровне и «жесткие» (hard) – на топологическом уровне. Иногда выделяют firm IP, в состав которых входят разные типы представлений от RTL до списка цепей с планировкой субблоков.

Одна из проблем проектирования SoC – создание IP-блоков. Практический опыт показывает, что стоимость reuse-блока в среднем в 10 раз превышает стоимость аналогичного разово используемого блока, а для процессоров эта величина на порядок выше. По этой причине reuse-блоки решают, как правило, общие логически формализуемые задачи, например, MPEG2 кодер, CPU, DSP, USB интерфейс, PCI интерфейс и т.п.

Фактически весь процесс разработки SoC делится на четыре этапа:

1. Разработка архитектуры SoC на системном уровне;

2. Выбор имеющихся IP-блоков из базы данных (внутри фирмы, других фирм или поставщиков IP-блоков);

3. Проектирование оставшихся блоков;

4. Интеграция всех блоков на кристалле.

Другая принципиальная особенность SoC это наличие программируемых блоков – процессоров. Поэтому SoC это не просто интегральная схема (ИС), а комплекс, в состав которого входят как аппаратная часть – чип, так программная часть – встраиваемое ПО. Предполагается, что маршрут проектирования SoC должен содержать операции по совместной верификации и отладке программной и аппаратной частей.

В настоящее время не существует четкого детерминированного определения СБИС типа «система на кристалле», работа в этом направлении ведется. Тем не менее, исходя из вышеперечисленного, можно сделать вывод, что SoC должна изготавливаться по технологии не ниже 0.35 мкм и содержать не менее 1 млн. вентилей.

На рисунке 3 представлен пример структуры SoC в общей форме. Как видно из рисунка, в состав SoC входят следующие компоненты:

1. Микропроцессор (или микропроцессоры) и подсистема памяти (статической и/или динамической). Тип процессора может варьироваться от простейшего 8-разрядного до высокоскоростного 64-разрядного RISC-процессора.

2. Шины центральная (высокоскоростная) и периферийная, чтобы обеспечивать обмен данными между блоками.

3. Контроллер внешней памяти для расширения памяти, например, DRAM, SRAM или Flash.

4. Контроллер ввода/вывода информации: PCI, Ethernet, USB и т.п.

5. Видео декодер, например MPEG2, AVI, ASF.

6. Таймер и контроллер прерываний.

7. Общий интерфейс ввода/вывода, например, чтобы вывести на светодиодный индикатор информацию о наличии питания.

8. Интерфейс UART (universal asynchronous receiver/transmitter).

Данная структура во многом искусственна, но, по сути, она отражает естественную структуру системы на кристалле.

Итак, можно выделить следующие принципиальные особенности системы на кристалле:

1. SoC конструируется из сложных функциональных блоков, которые могут быть как разработаны «с нуля», так и получены от поставщика IP-блоков. Поэтому в маршруте проектирования должен быть этап архитектурного проектирования, в задачи которого входит разработка общей архитектуры SoC. При выборе IP-блоков также учитывается стоимость готового блока и оцениваются затраты на разработку собственного блока.

2. SoC имеет в своем составе встраиваемое ПО, поэтому в маршруте должны быть этапы совместной верификации программного и аппаратного обеспечения (АО) – программно-аппаратной верификации (HW/SW co-verification);
   

3. SoC должна изготавливаться по технологии не ниже 0.35 мкм;

4. Наблюдается устойчивый рост доли смешанных цифро-аналоговых систем в общем объеме SoC (рис. 4), поэтому в маршруте проектирования должны быть включены этапы по совместной разработке и верификации цифровой и аналоговой частей SoC.

3. Маршрут проектирования SoC

Традиционный маршрут проектирования ASIC представлен на рис. 5.

Процесс проектирования начинается с разработки спецификации на проектируемую ASIC. Для сложных СБИС таких, как устройства графической обработки информации, в состав спецификации включается алгоритм обработки информации, который затем используется разработчиками для написания RTL-кода.

После функциональной верификации происходит синтез СБИС на вентильном уровне в виде списка цепей. Здесь же выполняется верификация временных требований. Как только временные требования удовлетворены, список цепей передается на физический синтез: размещение элементов и трассировка цепей. В конце создается и тестируется физический прототип СБИС, на основе которого впоследствии выполняется системная интеграция и тестируется ПО.

Используя такой маршрут можно проектировать схемы сложностью не более 100 тыс. вентилей по технологии не ниже 0.5 мкм. Это связано с тем, что проект здесь продвигается поэтапно от одной фазы к другой и никогда не происходит возврат на предыдущие фазы. Например, RTL дизайнер не может прийти к системному разработчику и сказать, что его алгоритм нереализуем, или команда логического синтеза не может попросить изменить RTL-код, чтобы добиться необходимых временных параметров. Для схем, изготавливаемых по DSM-технологии, такой маршрут вообще не будет работать, поскольку особенности физической реализации должны учитываться уже на логическом уровне проектирования.

Многие фирмы за рубежом переходят от традиционной нисходящей модели маршрута проектирования к новой спиралевидной модели (рис. 6) [2]. Здесь проектирование выполняется одновременно по 4-м направлениям: разработка ПО, разработка RTL-кода, логический синтез, физический синтез. При этом в процессе работы группы разработчиков обмениваются результатами проектирования.

Новая модель характеризуется следующими полезными свойствами:

• параллельная верификация и логический синтез блоков;

• планировка, размещение и трассировка включены в процесс синтеза;

• разрешен возврат на предыдущие фазы проектирование и корректировка результатов.

4. Системное проектирование SoC

Настоящая статья открывает серию публикаций, посвященных проблеме проектирования SoC. В рамках этой статьи рассматривается только первый этап проектирования систем на кристалле – системный. Другие стадии проектирования будут рассмотрены в следующих публикациях.

Начальный этап проектирования заключается в рекурсивной разработке, верификации и уточнении набора спецификаций до такой степени детализации, чтобы на их основе можно было начать создавать RTL-код. Быстрая разработка четких, полных и последовательных спецификаций –сложная задача. В хорошей методологии проектирования это трудоемкий, ответственный и протяженный этап проектирования. Если четко знать, что надо построить, то ошибки при дальнейшей реализации могут быть быстро обнаружены и устранены. В противном случае можно не заметить ошибку на протяжении всего цикла проектирования вплоть до изготовления чипа.

Спецификации описывают поведение системы [2]. Точнее, они описывают, как управлять системой так, чтобы получить от нее нужное поведение. В этом смысле, понятие спецификации в значительной мере связано с понятием интерфейса. Функциональная спецификация описывает интерфейс системы или блока так, как его видит внешний пользователь. Она содержат информацию о контактах, шинах, регистрах и о том, как с ними обращаться. Архитектурная спецификация описывает взаимодействия между частями блока и поведение на системном уровне.

Спецификации должны разрабатываться, как на аппаратную, так и на программную части проекта. Спецификации должны включать в себя следующую информацию. Для аппаратной части:

• выполняемые функции;

• внешний интерфейс к другим блокам (контакты, шины, протоколы);

• интерфейс с ПО (регистры);

• временные параметры;

• быстродействие;

• особенности физического уровня (площадь кристалла, потребляемая мощность).

Для программной части:

• выполняемые функции;

• временные параметры;

• быстродействие;

• интерфейс к аппаратной части;

• структура, ядро.

Традиционно спецификации пишутся на естественных языках таких, как русский, английский, что вносит в них неопределенности, двусмысленности и ошибки. Чтобы избавиться от этих проблем, многие компании начинают использовать исполняемые спецификации. На высоких уровнях для написания исполняемых спецификаций используют языки С, С++ или вариации С++, например, SystemC (www.systemc.org) [3]. Для описания аппаратуры обычно пользуются VHDL или Verilog. Разработка исполняемых моделей позволяет дизайнерам верифицировать основные выполняемые функции и интерфейсы на ранних стадиях проектирования, задолго до детализации проекта.

Процесс проектирования SoC на системном уровне представлен на рисунке 7. Процесс разработки начинается с идентификации целей и задач выполняемых SoC. На начальном этапе следует определить основные эксплуатационно-технические свойства: требуемое быстродействие, допустимую потребляемую мощность, время, необходимое для разработки, и т.п. На основании этих свойств создается системная спецификация, которая может выступать частью технического задания на разработку системы. Как правило, этот этап выполняется без применения специализированных программных средств САПР.

Затем создается высокоуровневая поведенческая модель всей разрабатываемой системы. Поведенческая модель системы, как правило, строится в виде блок-схемы. Для верификации разработанной поведенческой модели создается тестовое окружение (Testbench) системы, которое включает в себя генераторы входных сигналов, тестовые последовательности и блоки отображения выходной информации. Тестовое окружение должно максимально полно верифицировать функционирование системы. Впоследствии, на основе этого тестового окружения будут разрабатываться тестовые последовательности для верификации проекта на нижних уровнях проектирования и для тестирования опытных образцов СБИС.

Верификация поведенческой модели осуществляется путем компьютерного моделирования с использованием специальных программных средств. Если в процессе верификации обнаруживаются какие-либо отклонения от требований системной спецификации, то модель корректируется и моделирование повторяется.

Кроме верификации на данном шаге может быть выполнен выбор оптимальных параметров алгоритма системы. Например, разработчик может найти компромисс между вычислительной сложностью и точностью.

Как было сказано выше, система на кристалле включает в себя одно или несколько программируемых процессорных ядер. Поэтому на следующем этапе разработчик должен принять решение о том, какие части поведенческой модели будут в последствии реализованы на аппаратном уровне, а какие – на программном в виде встроенного в СБИС программного обеспечения. Кроме этого необходимо определить, каким образом будут взаимодействовать программная и аппаратная части, т.е. следует разработать интерфейс между АО и ПО. Здесь же определяется общая архитектура SoC: тип процессора, тип памяти и ее объем, аппаратные блоки, интерфейс АО-ПО, тип используемой шины, описание программной части и т.п.

В итоге формируется набор спецификаций на разработку программного обеспечения и на разработку каждого аппаратно реализуемого блока.

В методологии проектирования ASIC программно-аппаратная верификация выполняется только, после изготовления опытного образца. Возникающие при этом ошибки функционирования, как правило, можно исправить внесением соответствующих изменений в ПО, не переделывая сам кристалл. Такой метод не подходит к процессу проектировании SoC потому, что из-за большой cложности схемы исправить ошибки и погрешности АО путем корректировки ПО очень трудно, а зачастую просто невозможно. Поэтому в маршрут проектирования на разных уровнях вводится операция программно-аппаратной верификации. Наиболее ответственными в этом смысле являются этапы функционального и логического проектирования.

Программно-аппаратная верификация системного уровня на сегодняшний день не является обязательной операцией. Тем не менее, многие разработчики включают ее в маршрут проектирования SoC. В качестве аппаратной части здесь выступают исполняемые спецификации аппаратно реализуемых блоков, в качестве программной – прототип ПО. Таким образом можно убедиться, что аппаратная часть, разрабатываемая в соответствии с имеющимися спецификациями, будет корректно функционировать под управлением встраиваемого ПО в режиме реального времени.

5. Программные средства САПР для системного уровня

До недавнего времени задачи системного уровня – разработка спецификаций – в большинстве случаев решались без использования специальных программных средств. При переходе к методологии проектирования SoC стала очевидной необходимость автоматизации процесса системного проектирования.

Во-первых, поскольку SoC – высокоинтегрированная СБИС, то в ее состав входит большое количество сложных блоков: процессоры, жесткая логика, память, схемы контроля, аналоговые и цифроаналоговые компоненты и т.п. Проверить работоспособность такой системы, используя только аналитические методы расчета, невозможно. Поэтому, как было сказано выше, возникает необходимость в моделировании всей системы на поведенческом уровне, а для этого требуется специальное прикладное ПО.

Во-вторых, исполняемая спецификация должна быть представлена в определенном формате на языках С, С++, SystemC, Verilog или VHDL. Получить такое описание невозможно без использования соответствующих программных средств.

Кроме этого при переходе к спиралевидной модели проектирования (рис. 6) в процессе работы будут возникать постоянные «откаты» от нижних уровней проектирования к верхним. Часто системный уровень сливается с функциональным уровнем проектирования (разработка RTL-кода), образуя системно-функциональный уровень проектирования. В этом случае удобно пользоваться едиными программно-техническими средствами.

В настоящее время в мире существует огромное количество программных средств, которые могут быть использованы для автоматизации системного проектирования. Эти средства можно классифицировать на пять групп.

Первая группа – средства разработки и отладки прикладного программного обеспечения. Достаточно популярным и удобным для представления спецификаций оказался язык программирования С и его модификация С++. Поэтому разработчики системного уровня активно используют средства разработки программных приложений. Ниже приведены наиболее популярные из них:

• Microsoft Visual Studio (www.microsoft.com);

• Inprise Borland C++ Builder (www.borland.com);

• Borland Kylix C++ (www.borland.com) - в операционной системе Linux.

Основные достоинства это низкая стоимость, простота в освоении и использовании. Главный недостаток связан с отсутствием специализированных библиотек системного уровня, поэтому поведенческую модель разработчику приходится создавать практически «с нуля». Иногда также используют специальные средства для анализа и автоматизации разработки ПО, например, Rational Rose и язык UML (www.uml.ru).

Вторая группа – средства математического моделирования. Наиболее типичным представителем здесь выступает распространенный программный пакет MATLAB/Simulink (www.mathworks.com). Основными достоинствами здесь, как и в первой группе, являются низкая стоимость и простота в использовании, кроме этого есть возможность выполнять математическое моделирование и наличие библиотек моделей. К недостаткам можно отнести недостаточный объем специализированных библиотек, т.е. большинство моделей приходится создавать вручную, и использование собственного формата данных (M-файлы, MEX-файлы) в качестве базового. Последнее замечание носит, по всей видимости, временный характер, так как фирма The MathWorks, планирует выпустить полноценный транслятор из формата M-файлов в формат C/C++.

В третью группу можно объединить средства моделирования общего назначения, например, MLDesigner (www.mldesigner.com) или SES/Workbench (www.hyperformix.com). Отличительная особенность этих средств в том, что они не привязаны к какому-то конкретному объекту проектирования. С их помощью можно моделировать, например, как архитектуру СБИС, так и систему спутниковой связи или навигации. Достоинства: сравнительно низкая цена, широкий спектр областей применения. Основной недостаток –отсутствие связи с другими уровнями проектирования: функциональным и логическим.

Четвертая группа самая многочисленная. Сюда относятся программные средства, каждое из которых предназначено для решения какого-либо определенного круга проектных задач системного уровня. При этом общий спектр решаемых задач велик: от разработки программно-аппаратной архитектуры до интеграции процессорных ядер и разработки встраиваемого программного обеспечения. В качестве примера производителей данного ПО можно привести названия таких фирм, как Co-ware (www.coware.com), Mentor Graphics (www.mentor.com), Elanix (www.elanix.com), Summit Design (www.sd.com) и др. Использование такого специализированного ПО представляется достаточно привлекательным с точки зрения экономии средств.

Пятая группа это мощные интегрированные программные пакеты, при помощи которых разработчик способен выполнять весь цикл системного и функционального проектирования, а также весь цикл проектирования вплоть до физической реализации. На сегодняшний день в эту группу входят пакеты ПО только двух фирм:

• Synopsys (www.synopsys.com): CoCentric System Studio, Design Ware, VCS, VCSi, Scirocco, SystemC HDL Co-Sim, CoCentric SystemC Compiler;

• Cadence Design Systems (www.cadence.com): Incisive-SPW, Incisive unified simulator, Incisive-XLD, Incisive-AMS, NC-SystemC, NC-Verilog, NC-VHDL.

Главным недостатком обоих пакетов является их большая стоимость, что весьма существенно в условиях российского рынка.

При окончательном выборе программных средств и разработке на их основе маршрута проектирования необходимо дополнительно учитывать целый ряд факторов, например, специфику разрабатываемых устройств, общий объем работ (число одновременно выполняемых проектов), имеющееся на предприятии ПО для функционального и логического уровней проектирования и т.п.

Литература

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. Thorsten Grottker, Stan Liao, Grant Martin, Stuart Swan. System Design with SystemC// Kluwer Academic Publishers, Boston/Dordrech/London, 2002.