Начальный этап проектирования заключается в рекурсивной разработке, верификации и уточнении набора спецификаций до такой степени детализации, чтобы на их основе можно было начать создавать RTL-код. Быстрая разработка четких, полных и последовательных спецификаций –сложная задача. В хорошей методологии проектирования это трудоемкий, ответственный и протяженный этап проектирования. Если четко знать, что надо построить, то ошибки при дальнейшей реализации могут быть быстро обнаружены и устранены. В противном случае можно не заметить ошибку на протяжении всего цикла проектирования вплоть до изготовления чипа.
Спецификации описывают поведение системы. Точнее, они описывают, как управлять системой так, чтобы получить от нее нужное поведение. В этом смысле, понятие спецификации в значительной мере связано с понятием интерфейса. Функциональная спецификация описывает интерфейс системы или блока так, как его видит внешний пользователь. Она содержат информацию о контактах, шинах, регистрах и о том, как с ними обращаться. Архитектурная спецификация описывает взаимодействия между частями блока и поведение на системном уровне.
Спецификации должны разрабатываться как на аппаратную, так и на программную части проекта. Спецификации должны включать в себя следующую информацию. Для аппаратной части:
Для программной части:
Традиционно спецификации пишутся на естественных языках таких, как русский, английский, что вносит в них неопределенности, двусмысленности и ошибки. Чтобы избавиться от этих проблем, многие компании начинают использовать исполняемые спецификации. На высоких уровнях для написания исполняемых спецификаций используют языки С, С++ или вариации С++, например, SystemC. Для описания аппаратуры обычно пользуются VHDL или Verilog. Разработка исполняемых моделей позволяет дизайнерам верифицировать основные выполняемые функции и интерфейсы на ранних стадиях проектирования, задолго до детализации проекта.
Процесс проектирования SoC на системном уровне представлен на рис.1. Процесс разработки начинается с идентификации целей и задач выполняемых SoC. На начальном этапе следует определить основные эксплуатационно-технические свойства: требуемое быстродействие, допустимую потребляемую мощность, время, необходимое для разработки, и т.п. На основании этих свойств создается системная спецификация, которая может выступать частью технического задания на разработку системы. Как правило, этот этап выполняется без применения специализированных программных средств САПР.
Рис. 1.  Маршрут системного проектирования SoC
Затем создается высокоуровневая поведенческая модель всей разрабатываемой системы. Поведенческая модель системы, как правило, строится в виде блок-схемы. Для верификации разработанной поведенческой модели создается тестовое окружение (Testbench) системы, которое включает в себя генераторы входных сигналов, тестовые последовательности и блоки отображения выходной информации. Тестовое окружение должно максимально полно верифицировать функционирование системы. Впоследствии, на основе этого тестового окружения будут разрабатываться тестовые последовательности для верификации проекта на нижних уровнях проектирования и для тестирования опытных образцов СБИС.
Верификация поведенческой модели осуществляется путем компьютерного моделирования с использованием специальных программных средств. Если в процессе верификации обнаруживаются какие-либо отклонения от требований системной спецификации, то модель корректируется и моделирование повторяется.
Кроме верификации на данном шаге может быть выполнен выбор оптимальных параметров алгоритма системы. Например, разработчик может найти компромисс между вычислительной сложностью и точностью.
Система на кристалле включает в себя одно или несколько программируемых процессорных ядер. Поэтому на следующем этапе разработчик должен принять решение о том, какие части поведенческой модели будут реализованы на аппаратном уровне, а какие – на программном в виде встроенного в СБИС программного обеспечения. Кроме этого необходимо определить, каким образом будут взаимодействовать программная и аппаратная части, т.е. следует разработать интерфейс между АО и ПО. Здесь же определяется общая архитектура SoC: тип процессора, тип памяти и ее объем, аппаратные блоки, интерфейс АО-ПО, тип используемой шины, описание программной части и т.п.
В итоге формируется набор спецификаций на разработку программного обеспечения и на разработку каждого аппаратно реализуемого блока.
В методологии проектирования ASIC программно-аппаратная верификация выполняется только, после изготовления опытного образца. Возникающие при этом ошибки функционирования, как правило, можно исправить внесением соответствующих изменений в ПО, не переделывая сам кристалл. Такой метод не подходит к процессу проектировании SoC потому, что из-за большой cложности схемы исправить ошибки и погрешности АО путем корректировки ПО очень трудно, а зачастую просто невозможно. Поэтому в маршрут проектирования на разных уровнях вводится операция программно-аппаратной верификации. Наиболее ответственными в этом смысле являются этапы функционального и логического проектирования.
Программно-аппаратная верификация системного уровня на сегодняшний день не является обязательной операцией. Тем не менее, многие разработчики включают ее в маршрут проектирования SoC. В качестве аппаратной части здесь выступают исполняемые спецификации аппаратно реализуемых блоков, в качестве программной – прототип ПО. Таким образом можно убедиться, что аппаратная часть, разрабатываемая в соответствии с имеющимися спецификациями, будет корректно функционировать под управлением встраиваемого ПО в режиме реального времени.
До недавнего времени задачи системного уровня – разработка спецификаций – в большинстве случаев решались без использования специальных программных средств. При переходе к методологии проектирования SoC стала очевидной необходимость автоматизации процесса системного проектирования.
Во-первых, поскольку SoC – высокоинтегрированная СБИС, то в ее состав входит большое количество сложных блоков: процессоры, жесткая логика, память, схемы контроля, аналоговые и цифроаналоговые компоненты и т.п. Проверить работоспособность такой системы, используя только аналитические методы расчета, невозможно. Поэтому, как было сказано выше, возникает необходимость в моделировании всей системы на поведенческом уровне, а для этого требуется специальное прикладное ПО.
Во-вторых, исполняемая спецификация должна быть представлена в определенном формате на языках С, С++, SystemC, Verilog или VHDL. Получить такое описание невозможно без использования соответствующих программных средств.
Кроме этого при переходе к спиралевидной модели проектирования в процессе работы будут возникать постоянные "откаты" от нижних уровней проектирования к верхним. Часто системный уровень сливается с функциональным уровнем проектирования (разработка RTL-кода), образуя системно-функциональный уровень проектирования. В этом случае удобно пользоваться едиными программно-техническими средствами.
В настоящее время в мире существует огромное количество программных средств, которые могут быть использованы для автоматизации системного проектирования. Эти средства можно классифицировать на пять групп.
Первая группа – средства разработки и отладки прикладного программного обеспечения. Достаточно популярным и удобным для представления спецификаций оказался язык программирования С и его модификация С++. Поэтому разработчики системного уровня активно используют средства разработки программных приложений. Ниже приведены наиболее популярные из них:
Основные достоинства это низкая стоимость, простота в освоении и использовании. Главный недостаток связан с отсутствием специализированных библиотек системного уровня, поэтому поведенческую модель разработчику приходится создавать практически "с нуля". Иногда также используют специальные средства для анализа и автоматизации разработки ПО, например, Rational Rose и язык UML.
Вторая группа – средства математического моделирования. Наиболее типичным представителем здесь выступает распространенный программный пакет MATLAB/Simulink. Основными достоинствами здесь, как и в первой группе, являются низкая стоимость и простота в использовании, кроме этого есть возможность выполнять математическое моделирование и наличие библиотек моделей. К недостаткам можно отнести недостаточный объем специализированных библиотек, т.е. большинство моделей приходится создавать вручную, и использование собственного формата данных (M-файлы, MEX-файлы) в качестве базового. Последнее замечание носит, по всей видимости, временный характер, так как фирма The MathWorks, планирует выпустить полноценный транслятор из формата M-файлов в формат C/C++.
В третью группу можно объединить средства моделирования общего назначения, например, MLDesigner или SES/Workbench. Отличительная особенность этих средств в том, что они не привязаны к какому-то конкретному объекту проектирования. С их помощью можно моделировать, например, как архитектуру СБИС, так и систему спутниковой связи или навигации. Достоинства: сравнительно низкая цена, широкий спектр областей применения. Основной недостаток – отсутствие связи с другими уровнями проектирования: функциональным и логическим.
Четвертая группа самая многочисленная. Сюда относятся программные средства, каждое из которых предназначено для решения какого-либо определенного круга проектных задач системного уровня. При этом общий спектр решаемых задач велик: от разработки программно-аппаратной архитектуры до интеграции процессорных ядер и разработки встраиваемого программного обеспечения. В качестве примера производителей данного ПО можно привести названия таких фирм, как Co-ware, Mentor Graphics, Elanix, Summit Design и др. Использование такого специализированного ПО представляется достаточно привлекательным с точки зрения экономии средств.
Пятая группа - это мощные интегрированные программные пакеты, при помощи которых разработчик способен выполнять весь цикл системного и функционального проектирования, а также весь цикл проектирования вплоть до физической реализации. На сегодняшний день в эту группу входят дорогие пакеты ПО только двух фирм Synopsys CoCentric и Cadence Design Systems.
При окончательном выборе программных средств и разработке на их основе маршрута проектирования необходимо дополнительно учитывать целый ряд факторов, например, специфику разрабатываемых устройств, общий объем работ (число одновременно выполняемых проектов), имеющееся на предприятии ПО для функционального и логического уровней проектирования и т.п.
Список литературы
1. Евтушенко Н.Д., Немудров В.Г. , Сырцов И.А. Методология проектирования систем на кристалле. Основные принципы, методы, программные средства // "Электроника", 2003, №3