8. Основные этапы (уровни) проектирования SoC. Системный уровень проектирования.

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

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

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

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

• Выбор имеющихся IP-блоков из базы данных (внутри фирмы,

других фирм или поставщиков IP-блоков);

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

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

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

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

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

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

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

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

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

синтеза;

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

корректировка результатов.

Системное Проектирование

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

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

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

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

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

протоколы);

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

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

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

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

потребляемая мощность).

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

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

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

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

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

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

На высоких уровнях для написания исполняемых спецификаций используют языки С,С++

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

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

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

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

Кратко

Основные уровни проектирования

• Техническое задание

• системное проектирование

• функциональное проектирование

• логическое проектирование

• топологическое проектирование

• верификация и подготовка к производству

• файлы и документация для изготовления SoC

Системный этап проектирования (system-level description) – это основой уровень, который состоит из поведенческого описания в терминах функций, выражений и алгоритмов, он является уровнем выбора общей концепции построения системы, включающим моделирование операционной среды, в которой будет работать проектируемая системы, определение статических и динамических сценариев, планирование целевых задач.

Системное проектирование:

• Техническое задание

• анализ задач и требований, разработка системной спецификации

• разработка алгоритма

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

• разработка тестового окружения (Testbench)

• верификация поведенческой модели

• разбиение системы на АО и ПО, разработка спецификаций, интерфейсов и определение крупных СФ-блоков

• совместная программно-аппаратная верификация

• спецификация, структура SoC, поведенческая модель,тестовое окружение, требование к СФ-блокам