Как выбрать процессор для встраиваемой мультимедийной системы? Часть 2

Все статьи цикла:

• Как выбрать процессор для встраиваемой мультимедийной системы? Часть 1
• Как выбрать процессор для встраиваемой мультимедийной системы? Часть 2

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

Данная статья поможет вам сделать более осознанный выбор. Перечислим доступные варианты базовых архитектур:

• специализированные заказные интегральные схемы (ASIC, Application-Specific Integrated Circuit);
• специализированные стандартные интегральные схемы (ASSP, Application-Specific Standard Product);
• программируемые пользователем вентильные матрицы (FPGA, Field-Programmable Gate Array);
• микроконтроллеры (MCU, Microcontroller);
• цифровые сигнальные процессоры (DSP, Digital Signal Processor),
• комбинации DSP/MCU (в виде дискретных или унифицированных компонентов).

ASIC и ASSP

Микросхемы ASIC разрабатываются под точные требования конкретного конечного продукта. Это позволяет обеспечивать оптимизацию по критериям производительности и потребляемой мощности непосредственно на этапе их проектирования. Производству ASIC обычно предшествует решение на неспециализированных микросхемах, которое представляет собой прототип и/или начальную версию продукта, выпускаемую малыми объемами. После того как требования рынка стабилизировались, на основе этого решения можно разработать ASIC, что позволит снизить стоимость конечного изделия при больших объемах выпуска. Таким образом, производство ASIC зачастую является хорошим выбором для сегментов рынка, которые характеризуются стабильностью технологий и требований.

Микросхемы ASSP — родственники ASIC. Так же как и ASIC, они предназначены для использования в каком-то конкретном сегменте задач. Однако, в отличие от ASIC, которые разрабатываются для одной конкретной компании и продаются только ей, ASSP могут приобрести многие потребители, работающие в этом сегменте. В результате, доступная поддержка по ASSP намного обширнее, чем в случае с ASIC, и компании, которые имеют недостаточный опыт разработки ASIC собственными силами, зачастую предпочитают использовать ASSP. Размеры и стоимость ASIC и ASSP, решающих какую-то отдельно взятую задачу, приблизительно одинаковы.

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

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

Например, для технологических процессов с геометрией 90 и 65 нанометров один только комплект фотошаблонов для производства интегральной схемы стоит более $1 млн. Столь немалая цена изготовления вкупе с длительным временем проектирования останавливает компании, рассматривающие вариант с разработкой ASIC. Перечисленные факторы делают применение ASIC при производстве нестандартной аппаратуры затруднительным и являются основной причиной, по которой разработчики встраиваемых мультимедийных систем стремятся использовать более программируемые устройства.

FPGA

Использование в проекте микросхем FPGA позволяет, по сравнению с ASIC, ускорить разработку и, тем самым, сократить время выхода готовой продукции на рынок. Одна из причин уменьшения времени разработки заключается в том, что для FPGA разработана огромная база библиотек, реализующих стандартные составные блоки систем обработки сигналов. Еще одна «привлекательная черта» FPGA— то, что на их базе можно достичь производительности, превышающей производительность программируемых процессоров. Это становится возможным за счет того, что FPGA, как и ASIC, позволяют разработчику оптимизировать аппаратную часть под конкретный конечный продукт. Кроме того, FPGA способны выполнять интенсивные параллельные вычисления, которые невозможны на стандартном микроконтроллере или DSP.

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

MCU

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

Диапазон производительности микроконтроллеров достаточно велик: от 4-битных моделей с частотой 32 кГц до 32-битных устройств с частотой 500 МГц и более. (Обозначение «n-битный» относится к разрядности шин данных, регистров, исполнительных устройств микропроцессора и т. д.). Самым популярным типом MCU, применяемым во встраиваемых мультимедийных системах, являются 32-битные MCU.

Первое, что следует учесть при анализе причин столь высокой популярности 32-битных MCU в мультимедийных устройствах, — это то, что пропускная способность и вычислительная мощность 8-битных MCU недостаточны для гарантии работы таких систем в режиме реального времени. Нельзя сказать, что от 8-битных MCU нет совсем никакой пользы. Напротив, они очень популярны во многих приложениях — от автомобильной электроники до фотоаппаратов. Главные их достоинства — это очень малая потребляемая мощность, миниатюрные корпуса, превосходная плотность кода и крайне низкая цена (ниже $2). Многие 8-битные MCU имеют интегрированную флэш-память, а также средства подключения к Ethernet, что делает их привлекательными для широкого диапазона небольших задач узкой направленности. Кроме того, 8-битные MCU часто используются совместно с 32-битными процессорами в более сложных системах.

16-битные микроконтроллеры (цена на которые начинается с $2) можно рассматривать как логичную альтернативу 8-битным MCU. Эти устройства стоят всего в два раза больше, чем 8-битные MCU, но у них выше пропускная способность, производительность и степень интеграции. Кроме того, они потребляют малый ток в режиме ожидания и, как правило, имеют больший объем внутрикристальной памяти по сравнению с 8-битными моделями. Однако зачастую производительности 16-битных MCU для мультимедийных приложений недостаточно. Кроме того, возможности применения 16-битных MCU ограничивает то, что они имеют малый объем адресуемой памяти.

Другим фактором, работающим против 16-битных MCU, является сложность переноса существующих проектов, разработанных под 8-битные устройства, на 16-битную платформу. Работа с 16-битными устройствами обычно требует разработки программного обеспечения заново, а также использования нового набора средств проектирования. Многие разработчики при необходимости перехода от 8-битных MCU к более производительным устройствам скорее предпочтут 16-битным моделям 32-битные, поскольку в любом случае им потребуется осваивать новые технологии и вкладывать дополнительные средства в разработку.

Поэтому реальная стоимость выполнения системы на базе 32-битного MCU сравнима со стоимостью многих 16-битных решений, а превосходство в производительности над 16-битными MCU будет существенным. Несмотря на то, что разница в стоимости между 32- и 16-битными устройствами может составлять $3 и более, она частично компенсируется повышенной степенью интеграции периферийных модулей, а также гибкостью, которая обусловлена значительно большим запасом по производительности.

Рассмотрим еще ряд причин растущей популярности 32-битных MCU.

Как показано на рис. 1, реализация многих широко распространенных периферийных узлов (high-speed USB 2.0, PCI и т. д.) в 8- и 16-битных MCU громоздка или невозможна. Так, например, поддерживать полный набор сетевых протоколов с использованием 8- или 16-битных регистров данных сложно, поскольку сетевые протоколы в общем случае разрабатывались под 32-битные процессоры.

Также стоит отметить, что 32-битные MCU зачастую позволяют получить более компактный компилированный код и обладают более гибкой моделью программирования. Этот момент заслуживает детального обсуждения. При помощи команд большей разрядности можно описать более гибкий набор операций, поэтому 32-битные MCU лучше подходят для компиляции, чем 8- или 16-битные MCU. (Другими словами, компилятору проще преобразовывать код, написанный на C, в машинные команды на 32-битной машине.) Кроме того, 32-битные устройства зачастую поддерживают 8- и 16-битные коды команд, что в совокупности с возросшей производительностью компилятора обеспечивает повышение плотности кода.

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

Во встраиваемых системах обработки мультимедийных данных MCU могут играть различные роли. В системах начального уровня они могут быть единственным системным процессором, который занимается преимущественно декодированием и отображением видеоизображений при умеренных разрешениях (зачастую QVGA или менее) и простых видеоформатах (например, MPEG4 Simple Profile вместо H.264). В системах среднего и высшего уровня для работы с высокими разрешениями и более сложными форматами необходим DSP или другой оптимизированный процессор. Однако в таких системах MCU по-прежнему может служить в качестве системного контроллера, на котором исполняется операционная система и который управляет выполнением различных задач в системе. Более того, благодаря богатому набору периферийных модулей MCU часто служат мостом между мультимедийным процессором и внешним миром.

DSP

Цифровые сигнальные процессоры появились как средство для преодоления ограничений производительности, присущих MCU. Эти процессоры отличаются наличием специализированных аппаратных конструкций, которые оптимизированы для эффективного выполнения компактных программных циклов. В частности, для DSP характерна возможность эффективно выполнять операции умножения с накоплением (MAC, multiply-accumulate). DSP идеальны для задач, где требуется «перемалывание» буферов данных с высокой эффективностью, которые часто встречаются в мультимедийных приложениях. Для достижения от DSP высокой производительности программисту обычно необходимо писать оптимизированный код на языке ассемблера. Поскольку алгоритмы цифровой обработки сигналов, как правило, помещаются в обладающей малой задержкой небольшой внутренней памяти, плотность кода для этого типа процессоров, в общем случае, является второстепенным фактором.

DSP могут работать с очень высокими тактовыми частотами, и их производительность зачастую сравнивают по количеству миллионов операций MAC в секунду, которое они способны выполнять. Эта метрика носит название “mega MACS”, илиMMACS. Операция MAC— это базовая операция цифровой обработки сигналов, используемая в цифровых фильтрах, быстрых преобразованиях Фурье (FFT, fast Fourier transform) и других алгоритмах. Многие DSP имеют несколько блоков вычисления MAC, что увеличивает их производительность в задачах обработки сигналов. На рис. 2 представлены графики, которые иллюстрируют прорыв в производительности сигнальных процессоров, произошедший за последние годы. Цена процессоров в пересчете на количество MMAC резко упала, а достижимое на отдельно взятом процессоре число MMAC так же резко увеличилось.

Дискретные DSP + MCU

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

Существует несколько различных способов интеграции MCU и DSP в системе. Начинающие разработчики могут использовать в своем проекте отдельные кристаллы MCU и DSP. Несмотря на то, что такая организация может быть дороже и занимать немало места, она позволяет с максимальной гибкостью распределять задачи, решаемые системой, между кристаллами. В качестве альтернативы можно воспользоваться микросхемами, которые выпускают некоторые производители, основанными на гетеродинном мультиядерном подходе, в которых отдельные кристаллы процессоров DSP и MCU объединены в одном корпусе.

В применении раздельных MCU и DSP есть некоторые преимущества. Во-первых, специалисты, работающие с DSP и с MCU, имеют разные стратегии программирования. Так, например, разработчики, пишущие программы для сигнальных процессоров, с удовольствием занимаются малейшими нюансами архитектуры процессора и реализуют различные приемы для повышения производительности c учетом этих нюансов. С другой стороны, программисты, работающие сMCU, зачастую предпочитают просто писать программы, не заботясь о том, как работает процессор.

Другая причина исторически сложившегося разделения на группы разработчиков программ для MCU и DSP заключается в том, что эти два типа процессоров имеют различные требования к проектированию. Инженеры, ответственные за системный уровень, зачастую не решаются смешивать в одном процессоре код «управления» с кодом «сигнальной обработки». Наиболее распространенное мнение, препятствующее этому, — то, что задачи, выполняемые не в реальном времени, будут конфликтовать с задачами, выполняемыми в реальном времени. Например, программистам, отвечающим за такие задачи, как поддержка графического интерфейса пользователя (GUI) или сетевого стека, при таком разделении не нужно будет беспокоиться о том, что их код помешает выполнению задач реального времени, связанных с цифровой обработкой сигналов в системе.

Недостаток подхода “DSP+MCU” заключается в том, что при его использовании происходит жесткое разделение между функциями управления и функциями цифровой обработки сигналов. Так, например, если DSP перегружен, то MCU может не справиться с оставшейся порцией вычислительных задач. Следовательно, окончательный продукт не всегда можно будет приспособить к новым требованиям. Другая сложность состоит в том, что при использовании раздельных ядер MCU и DSP необходимо работать с двумя разными наборами средств разработки, что усложняет проектирование.

Параллельно с развитием быстрых 32-битных MCU наметилась тенденция включать в них больше характерных для DSP функций, например блоки MAC. Однако поскольку тактовые частоты и вычислительные архитектуры MCU не очень годятся для «перемалывания» данных с частотами, характерными для мультимедийной информации, эта философия годится только для задач классической обработки сигналов. Таким образом, подобные MCU с «расширенными возможностями DSP» являются менее чем идеальной платформой для сложных мультимедийных приложений.

Конвергентный процессор

Конвергентный процессор совмещает в себе свойства MCU и DSP. Важно понимать, что конвергентный процессор— это не DSP с архитектурными улучшениями, ориентированными на функции управления, и не микроконтроллер с расширенными возможностями DSP. Конвергентный процессор оптимизирован как для выполнения вычислений над потоками мультимедийных данных в реальном времени, так и для задач управления. Типичный пример архитектуры этого типа— процессоры семейства Blackfin компании Analog Devices.

Как и DSP, конвергентные процессоры обычно обладают высокими тактовыми частотами и малым отношением рассеиваемой мощности к единице измерения производительности (мВт/MMACS). Как и MCU, конвергентные процессоры имеют дружественную компилятору архитектуру. По сравнению с подходом “MCU+DSP”, применение конвергентного процессора позволяет сократить потребляемую мощность и занимаемое на печатной плате пространство, а также снизить сложность и стоимость системы.

Применение конвергентных процессоров также упрощает процесс разработки. Рассмотрим процесс разработки для подхода “MCU + DSP”: в то время как программа для MCU обычно пишется на C с использованием библиотечных функций, программа для DSP, исполняемая в реальном времени, для достижения максимальной производительности, как правило, пишется на ассемблере. Эти два сильно различающихся пути порождают необходимость в двух командах программистов, обладающих разными навыками и использующих два разных набора средств разработки.

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

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

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

Литература

1. Катц Д., Джентайл Р. Как выбрать процессор для встраиваемой мультимедийной системы? Часть 1 // Компоненты и технологии. 2008. № 7.