Лекция 2. Задача системного проектирования

Задача системного проектирования для SiP. Декомпозиция проекта. Спецификация

Определим теперь каждый этап процесса проектирования. Конкретные маршруты проектирования (в бизнесе программных средств ведущих EDA компаний Cadence Design Systems и Synophsys), апробированные на конкретных проектах ASIC (в том числе и SIP).

Анализ требований SiP - это определение и описание сложной SiP как конечного продукта с точки зрения ее необходимости для радиоэлектронной аппаратуры (РЭА), где она будет эксплуатироваться. Исходной информацией здесь является набор характеристик будущей SiP, как функциональных, так и нефункциональных, полученных в результате маркетинговых исследований: стоимость, размеры, потребление энергии, производительность, тип корпуса и т.п. Данный этап должен дать однозначный ответ на вопросы: является ли проект осуществимым? Какие усилия необходимо приложить, чтобы осуществить проект? Какая часть проекта может быть сведена к повторному использованию? Может ли данный проект быть построен на основе аналогичных проектов продуктов предыдущего поколения или, в случае платформоориентированного проектирования, может ли данный проект быть построен на базе существующей платформы?

Разработка и анализ алгоритма. На данном шаге создаются, адаптируются и исследуются ключевые алгоритмы работы SiP, как в части управления системой, так и в части обработки данных. Алгоритмы управления часто выражаются в форме автомата с конечным числом состояний. Алгоритмы обработки данных, как правило, записываются на языке специализированных программных средств, в частности, на языке C/C++. Для анализа такого рода структур данных могут быть использованы следующие автоматизированные средства: Mathworks Matlab/ Simulink, Cadence SPW, Synopsys CoCentric System Studio и Ptolemy/ Ptolemy II (разработка профессора Эда Ли из университета Беркли).

Перечислим основные вопросы, ответы на которые должны быть получены на данном этапе. Какие типы обрабатываемых данных и какие управляющие функции необходимы для нормально работы данной SiP? С какой точностью должны обрабатываться данные? Для систем связи, например, необходимо определить, какие методы и алгоритмы кодирования/декодирования будут использованы, можно ли адаптировать существующие алгоритмы или необходимо создавать новые. Способен ли выбранный алгоритм обеспечить требуемую пропускную способность (для систем связи, в частности)? Насколько достоверна используемая идеализированная модель канала? Насколько сложен выбранный алгоритм в реализации на архитектурном уровне?

Архитектура SiP. На данном этапе определяется базовая архитектура будущей SiP. Как было показано в предыдущей главе, чрезвычайно важно выбрать коммуникационную архитектуру, которая станет каркасом для SiP. Выбор неадекватной коммуникационной архитектуры может сделать SiP чересчур громоздкой, что, в частности, сильно отразится на ее себестоимости. Естественно, в первую очередь нужно определиться с программируемыми процессорными ядрами. Здесь разработчик должен ответить на следующие вопросы: будет ли использоваться RISC процессор, будут ли использоваться встроенные DSP ядра, сколько их необходимо, будет ли интегрироваться на кристалл только «голый» процессор или следует воспользоваться готовой процессорной подсистемой? В настоящее время процессорные ядра часто комплектуются целой подсистемой жизнеобеспечения, состоящей из дополнительного набора IP-блоков, куда могут входить всевозможные интерфейсы, контроллеры памяти, устройства диагностики, PLL и т.п. Каковы идеи насчет разбиения на программную и аппаратную части? Какую структуру памяти предпочтительней использовать? Какие требования должны предъявляться к блокам встроенной памяти (размеры, быстродействие, доступ)?

Проектирование на системном уровне является важной частью SiP процесса, но при этом оно часто проводится довольно неформально. SiP архитекторы также часто используют бумагу и доску, как и более продвинутые средства. Однако уже довольно давно на этом этапе часто используются неформальные модели на основе C/C++ для проверки базовых решений по архитектуре. И проектировщики сложных алгоритмов по обработке сигналов в области аудио-видео обработки уже давно используют модели потоков данных (dataflow) и соответствующие специализированные средства для задания своих алгоритмов, определения оптимальных параметров (в частности, разрядности шин) и проверки производительности как в случае программной, так и аппаратной реализации.

Активная работа над различными стандартами моделирования на базе C/C++ для системных архитекторов в последние несколько лет привела к появлению SystemC. Потребность в моделировании и анализе сложных устройств (типа SiP) на системном уровне тем выше, чем сложнее эти устройства. На этом этапе должна быть решена задача программно-аппаратной декомпозиции. Также здесь необходимо создать поведенческую модель и проанализировать ее (путем компьютерного моделирования) на предмет соблюдения требований функционирования, производительности и нефункциональных атрибутов планируемой SiP. Наконец, все используемые IP-блоки (как разрабатываемые заново, так и используемые повторно) должны быть идентифицированы.

После идентификации на системном уровне процессоров, коммуникационной архитектуры и других IP-блоков (как HW, так и SW), необходимых для проекта, группа разработчиков должна предпринять действия по приобретению IP-блоков. На практике данный этап может быть достаточно продолжительным по времени, тем не менее, он может выполняться параллельно с другими фазами, например, системным проектированием (предполагается, что внешние IP-блоки уже идентифицированы) или верификацией на уровне транзакций. Удачно, когда группа работает в большой фирме, где существует большой выбор собственных IP-блоков, организованных в удобную базу данных, или, по договоренности, есть выход на внешнюю библиотеку IP-блоков, или в группе есть как минимум один человек с опытом поиска, оценки, покупки и интеграции IP-блоков. Необходимо пользоваться существующими стандартами на IP-блоки, такими как VSIA и/или VCX. Одна из ключевых трудностей – это проведение строгой и исчерпывающей проверки приобретаемых IP-блоков на предмет их достоверности и полноценности, а также выявление возможных ошибок до этапа интеграции.

Верификация на уровне транзакций. Поведенческая модель, построенная на этапе системного проектирования, может служить основой для создания более детализированной модели, использующей абстракции уровня транзакций. Модель уровня транзакций позволяет построить виртуальный прототип системы для проведения функциональной верификации программной и аппаратной частей проекта на уровне архитектуры. Его еще называют золотой макет схемы (golden testbench). Виртуальный прототип позволяет верифицировать как полную микроархитектуру проекта, так и его отдельные части, описанные на аппаратурных языках (Verilog, VHDL), в контексте всего проекта.

Определение архитектуры встраиваемого ПО. Вполне очевидно, что система на кристалле – это не просто СБИС, а комплекс, содержащий также встраиваемое программное обеспечение. Несомненно, что специфика области электроники, в которой будет эксплуатироваться разрабатываемая SiP, оказывает значительное влияние не только на выбор коммуникационной архитектуры или процессорного ядра, но и в не меньшей мере (а часто и в большей) на ПО. В частности, выбор базовой операционной системы реального времени (RTOS - Real-Time Operating System) напрямую зависит от типа процессора (а точнее, от его разрядности), который, в свою очередь, определяется конкретной областью применений будущей SiP. Периферийные устройства SiP должны быть обеспечены драйверами — специализированным ПО, которое обеспечивает взаимодействие прикладного ПО, RTOS и аппаратной периферии. По аналогии с аппаратными IP-блоками (HW IP) здесь имеет смысл говорить о программных IP-блоках (SW IP). Различные готовые пакеты (или библиотеки) специализированных программ – важная часть архитектуры встраиваемого ПО. Программы кодирования/декодирования голоса или изображения часто поставляются в виде готового ассемблерного кода для конкретных DSP или CPU. Таким образом, при создании SiP необходимо четко и полно определить всю архитектуру программного обеспечения: какую выбрать операционную систему, как организовать взаимодействие ОС, прикладного ПО и периферии, какие программные блоки можно получить со стороны и использовать повторно, а какие придется разрабатывать полностью.

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

должно быть достигнуто соглашение между членами команды по поводу физической планировки кристалла;

все IP-блоки должны быть полностью и окончательно сконфигурированы;

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

все аппаратные блоки должны быть реализованы (хотя бы в виде RTL-кода).

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

Архитектура DFT и ее внедрение. Дополнительные схемы для тестирования и самотестирования готовых СБИС (DFT - Design-for-Test) должны быть обязательно встроены в проект SiP. Положение затрудняется использованием готовых IP-блоков. Различные IP-блоки от разных поставщиков и производителей, как правило, имеют разные средства самотестирования, поэтому при разработке SiP скорей всего придется комбинировать все эти средства (такие, как BIST — Build-in Self Test или SCAN). Можно адаптировать различные тестовые средства к стандартному тестовому протоколу (например, JTAG) и разработать объединенный тестовый план.

Реализация и внедрение AMS блоков. Большинство SiP включают в себя аналоговые и смешанные (цифро-аналоговые) блоки (AMS - Analog/Mixed Signal), чтобы обеспечить связь с внешним миром. VSI альянс в сотрудничестве с другими организациями разработал пакет документов с рекомендациями по созданию AMS IP-блоков и их интеграции в SiP. Данный пакет ориентирован на SiP типа «Big D/Little А» (т.е. большая часть - цифровая, меньшая - аналоговая). SiP типа «Big A/Big D» встречаются достаточно редко.

Интеграция аппаратных IP-блоков. Данный этап, как правило, решается традиционными способами. Большинство проектных групп уже имеет достаточный опыт в сборе и монтаже готовых проектных блоков, выполненных другими разработчиками, в соответствии с принятой архитектурой. Основное отличие SiP от традиционных СБИС в том, что часто приходится работать с блоками, разработанными на стороне. Чтобы избежать трудностей, здесь следует проводить тщательную квалификацию и отбор поступающих извне IP-блоков.

Ассемблирование ПО и его интеграция в SiP. IP-блоки с программным обеспечением точно также, как и чисто аппаратные IP-блоки, должны быть адаптированы к конкретной SiP, интегрированы и верифицированы в составе SiP. Очень важно здесь верифицировать работу программного IP-блока именно в контексте задач, решаемых всей SiP, и под управлением встраиваемой RTOS.

Программно-аппаратная верификация. Хотя программно-аппаратная верификация и представлена на блок-схеме маршрута в виде всего одного блока, на практике это одна из самых трудоемких и ресурсоёмких задач, от решения которой будет зависеть качество всей SiP. Чтобы верификация была эффективной, необходимо использовать результаты по разработке тестового окружения, полученные на предыдущих этапах («золотой прототип»). Кроме этого, важно, чтобы средства верификации были с поддержкой нескольких языков описания и с поддержкой смешанного моделирования. Например, необходимо правильно совмещать SystemC модели и HDL описания аппаратуры.

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

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

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

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

Заключительная сборка SiP и верификация. Фаза заключительной сборки и верификации включает в себя: размещение, трассировку всего кристалла, физическую верификацию, состоящую из контроля технологических норм (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).

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

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

Системный уровень проектирования

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

К другим задачам относится программно-аппаратная декомпозиция, обычно ограничивающаяся рассмотрением ключевых функций, которые могут быть реализованы как в ПО, так и в АО виде и которые оказывают большое влияние на производительность системы, требуемую мощность, пропускную способность коммуникаций на чипе и другие ключевые характеристики. В многопроцессорных системах возникают также задачи разбиения ПО-ПО, или вопросы совместного проектирования («co-design»). Около 80-95 % этих решений могут быть приняты заранее (a-priory), особенно, если SiP основана либо на платформе, либо на базе уже разработанной и эксплуатируемой системы. Решения по совместному проектированию обычно принимаются для небольшого набора наиболее важных функций.

Так как задачи разбиения, совместного проектирования (co-design) и DSE на системном уровне требуют гораздо больше усилий, чем вопросы АО-ПО декомпозиции, более подходящим для этого термином является «function-architecture со-design» (совместное функционально-архитектурное проектирование). В такой модели система одновременно описывается на двух равноценных уровнях:

Функциональное назначение — сеть приложений системы, разделённая на ряд функциональных задач, которые могут моделироваться с помощью различных вычислительных моделей, таких, как дискретные события, конечные автоматы (FSM) или потоки данных.

Архитектурная структура - архитектура коммуникаций, основные IP-блоки, такие, как процессор, память и основные аппаратные блоки.

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