CC BY
31Дэвид КАТЦ (David KATZ) Перевод: Александр СОТНИКОВ
Другая причина исторически сложившегося разделения разработчиков программ для MCU и DSP на две группы заключается в том, что эти два типа процессоров имеют различные требования к проектированию. Инженеры, ответственные за системный уровень, зачастую не решаются смешивать в одном процессоре код «управления» с кодом «сигнальной обработки». Наиболее распространенное мнение, препятствующее этому, таково: задачи, выполняемые не в реальном времени, будут конфликтовать с задачами, выполняемыми в реальном времени. Например, программистам, отвечающим за такие задачи, как поддержка графического интерфейса пользователя (GUI) или сетевого стека, при таком разделении не нужно будет беспокоиться о том, что их код помешает выполнению задач реального времени, связанных с цифровой обработкой сигналов в системе.
Более того, существуют также исторические различия в моделях программирования под MCU и DSP. В MCU обычно используются внутренние кэш-памяти команд и данных, которые позволяют автоматизировать управление кодом и данными. Другими словами, MCU при таком подходе автоматически управляет процессом упорядочивания кода и данных без вмешательства программиста. Недостаток этого подхода заключается в том, что поведение кэш-памяти зачастую сложно предсказать, а управлять им еще сложнее. Это, в свою очередь, делает реализацию обработки в режиме реального времени труднодостижимой.
Конвергентные процессоры —
ключ к решению проблем при создании цифровых систем
В современной модели разработки доминирует следующий подход: создание программного обеспечения (ПО) под MCU и под традиционные DSP ведется двумя разными командами программистов, которые взаимодействуют между собой только на системном уровне, где эти два функциональных мира пересекаются друг с другом. Это довольно логично, поскольку каждая из групп разработчиков может иметь собственную стратегию, основанную на требованиях конкретного приложения. Так, например, разработчики ПО для сигнальных процессоров, как правило, сосредотачиваются на методах, позволяющих повысить производительность. В то же время вторая группа программистов может преследовать противоположные цели — например, программистам, пишущим ПО для MCU, в ряде случаев удобнее сделать систему «под ключ», которая реализовывала бы все задачи без вмешательства пользователя.
В отличие от MCU, в DSP применяются системы статической памяти. Под программным контролем каналы DMA перемещают данные между периферийными модулями и системами памяти без использования ценных командных циклов ядра процессора. Такая организация обеспечивает детерминизм в управлении, к которому стремятся DSP-программисты, но создает сложности, к которым может оказаться не готово большинство программистов, работающих с MCU.
Еще один ключевой момент — поддержка операционных систем (ОС). Поддержка процессором ОС или ядра ОС реального времени позволяет реализовать на нем несколько уровней выполнения задач. Чтобы сделать возможным достижение заданной производительности, процессор должен иметь контроллер прерываний, поддерживающий несколько уровней приоритета. Также необходимо обеспечить (при помощи аппаратного стека или поддержки указателя кадра стека) переключение контекста. Наличие таких возможностей позволяет разработчикам создавать на базе одного устройства системы, способные выполнять как задачи управления, так и задачи обработки сигналов в реальном времени.
Исторически сложилось так, что в DSP поддержка ОС была ограничена. Основная причина этого кроется в том, что в большинстве DSP отсутствует блок управления памятью (MMU, Memory Management Unit). При помощи MMU в ОС можно реализовать защиту памяти, позволяя за счет постраничного разбиения памяти одной задаче блокировать доступ другой задачи к памяти или
командам. При несанкционированном обращении к защищенной области памяти генерируется исключение. Ядро ОС обслуживает это исключение и предпринимает соответствующие действия.
Важную роль играет и наличие уже разработанного ранее программного обеспечения. Программы, написанные под MCU, обычно подразумевают побайтовую адресацию, 32-битные операции и 32-битное адресное пространство. В свою очередь, программное обеспечение под DSP предыдущих поколений, как правило, ориентировано на 16-битную адресацию, 16-битную арифметику и работу с 16-битным адресным пространством.
Более того, программы для MCU обычно пишутся на языке C, а архитектуры DSP мало подходят для эффективной компиляции таких программ. Компиляция программ, написанных на C, под DSP зачастую давала чрезмерно большой и весьма медленный код. По этой причине имеющееся программное обеспечение для DSP по большей части написано на языке ассемблера. Подобный код может иметь малый размер и высокую скорость исполнения, однако его сложно перенести на другую платформу.
И, наконец, еще одна причина раздельного создания программного обеспечения для MCU и DSP связана с производительностью. MCU оптимизированы для задач управления и зачастую не обладают достаточной производительностью для сигнальной обработки, требующей большого числа вычислительных операций. Например, во многих MCU отсутствует аппаратный блок умножения с накоп-
MIPS 100% на С
Рис. 1. Плотность кода, генерируемого компилятором VisualDSP++
лением (MAC, multiply-accumulate), которым обладают DSP. Аналогичным образом DSP оптимизированы для сигнальной обработки, и во многих случаях они плохо справляются с задачами управления. Например, тактовые частоты, на которых работают DSP, зачастую ниже по сравнению со многими MCU.
Решение проблем с помощью конвергентных процессоров
В процессе преодоления описанных трудностей появился новый класс процессоров, которые совмещают в себе свойства MCU и свойства DSP. Этот класс процессоров имеет целый ряд названий, мы же в этой статье будем называть их конвергентными. Один из примеров таких процессоров — семейство процессоров Blackfin производства компании Analog Devices. Ядро процессоров Blackfin имеет 16/32-битную архитектуру с двумя блоками MAC и возможностью выполнения команд в режиме «одна команда — много данных» (SIMD, Single Instruction Multiple Data). Это позволяет процессорам семейства справляться с высокой вычислительной нагрузкой в задачах цифровой обработки сигналов (ЦОС). Процессоры семейства Blackfin также обладают особенностями, характерными для микроконтроллеров и микропроцессоров — например, побайтовая адресация, MMU, сторожевой таймер и часы реального времени.
Объединение свойств MCU и DSP в конвергентном процессоре может также распространяться и на организацию системы памяти. Например, в процессорах Blackfin система памяти может быть программно сконфигурирована как кэш-память (модель MCU), как статическая память (модель DSP) или как смешанный набор блоков памяти обоих типов. Это позволяет командам разработчиков выбирать ту модель программирования, которая им наиболее подходит.
При работе с этим новым классом процессоров доступна база унифицированного программного кода на С/С++. Это дает возможность разработчикам повторно использовать огромное количество существующего прикладного кода, разработанного ранее. Поскольку конвергентные процессоры оптимизированы и для операций управления, и для операций сигнальной обработки, соответствующие компиляторы могут генерировать код, который будет с одной стороны компактным (с точки зрения плотности кода), а с другой — эффективным (то есть подходящим для задач сигнальной обработки с большим количеством вычислительных операций). Естественно, опытные программисты по-прежнему смогут применять кодирование на языке ассемблера для оптимизации программных циклов, критических с точки зрения времени выполнения.
Конвергентные процессоры могут сделать разработку кода на C/C++ более простой и эффективной, чем прежде. Их высокая произ-
водительность позволяет компилировать и исполнять начальные версии программного обеспечения на значительно более ранних стадиях цикла проектирования и, как следствие, ускорить отладку системы в целом и сократить время до выхода готовой продукции на рынок. Основная цель при этом заключается в том, чтобы сделать влияние программного обеспечения на проектирование системы менее критичным. Рис. 1 иллюстрирует эффективность разработки кода для процессора Blackfin на примере адаптивного многоскоростного (AMR, Adaptive Multi-Rate) кодера.
Однопроцессорные и двухпроцессорные системы
Даже несмотря на появление конвергентных процессоров, в ряде случаев в системе логично использовать два процессора. При традиционном двухпроцессорном подходе каждый из них решает дискретные и зачастую различающиеся задачи. Например, один из процессоров может выполнять все задачи, связанные с управлением: вывод и наложение графики, организация сетевого взаимодействия, интерфейс с устройствами хранения информации и общее управление процессами в системе. В этом процессоре также может исполняться код ОС или ядра ОС. Второй процессор при таком разделении выделяется под решение функций обработки, требующих большого объема вычислений. В качестве примера можно привести систему, в которой пакеты сжатых данных пересылаются по сетевому интерфейсу в первый процессор для предварительной обработки, который затем передает данные во второй процессор, выполняющий декодирование аудио-и видеоинформации.
Двухпроцессорный подход предпочтителен для проектов, создаваемых раздельными командами программистов. Возможность
разделения этих типов функций позволяет распараллелить процесс разработки, устраняя критические зависимости между этапами реализации. Такая модель программирования также упрощает фазы тестирования и аттестации проекта. Так, например, изменение кода, исполняемого одним ядром, не обязательно приведет к необходимости повторного тестирования уже отлаженного ПО второго процессора.
Наиболее очевидный способ создания двухпроцессорной системы — это применение процессоров двух типов — MCU и DSP. Однако такой подход имеет серьезные недостатки. Во-первых, команды разработчиков ПО для MCU и DSP будут использовать разные среды проектирования, разные компиляторы и т. д. Такое удвоение средств разработки влечет за собой увеличение стоимости и сложности процесса разработки. Различия в архитектуре MCU и DSP также приводят к тому, что перераспределять функции в системе после того, как процесс разработки программного обеспечения начался, становится значительно сложнее. Например, предположим, что производительности DSP начинает не хватать, а MCU при этом имеет достаточный запас производительности. В идеале некоторые задачи DSP можно было бы переложить на MCU, однако сделать это будет сложно, поскольку архитектуры MCU и DSP несовместимы.
Решить эти проблемы можно с помощью конвергентных процессоров. Используя в системе два таких процессора, можно сохранить в ней все преимущества двухпроцессорной архитектуры и избавиться от перечисленных недостатков. Поскольку процессоры имеют идентичную архитектуру, обе команды разработчиков могут использовать один набор средств разработки. Кроме того, перераспределение функций в приложении упрощается, поскольку код можно легко перенести с одного процессора на другой.
ADI Blackfin — 750 МГц ARM ARM1136 — 330 МГц Freescale MSC7100 — 330 МГц MIPS MIPS32 24KE - 335 МГц Tl TMS320C55x - 300 МГц Tl TMS320C64x - 1 ГГц
2000 4000 6000 8000 10 000
□ BDTmark2000™
■ BDTIsimMark2000"
Рис. 2. Показатели BDTImaгk2000™ для ряда процессоров (чем больше оценка, тем лучше)
Выбор конвергентного процессора
Несмотря на то, что множество преимуществ дает уже сам факт применения конвергентного процессора, не все они обладают равными возможностями. При выборе такого процессора нужно внимательно подойти к оценке его производительности. Поскольку конвергентный процессор можно использовать как для управления, так и для сигнальной обработки, очень важно оценить производительность процессора при решении обоих типов задач.
Значительное влияние на производительность оказывает эффективность хранения и пересылки данных. Также, наряду с этими факторами, одной из наиболее существенных характеристик процессора является эффективная точность представления чисел. Разрядность устройства обработки сигналов обычно определяется по разрядности типа данных, с которыми оно наиболее эффективно работает. Разрядность стандартного процессора, как правило, определяется по разрядности его регистров и шин данных. Например, процессоры Blackfin поддерживают аппаратную арифметику с 8-, 16- и 32-битными данными, однако оптимизированы они (имеют наиболее обширную поддержку) для 16-битных операций. Таким образом, считается, что процессоры Blackfin — это 16/32битные процессоры.
Из-за того, что разные процессоры поддерживают данные различной разрядности, судить о процессоре исключительно по таким показателям, как тактовая частота ядра, MIPS, MACS, FLOPS и т. д., нельзя. Несмотря на то, что эти показатели дают грубое представление о производительности процессора, они не отражают работу на нем того или иного приложения, поскольку не учитывают эффективность подсистемы памяти или набора команд. Зачастую эти пиковые показатели поддерживаются только в отдельные моменты
времени, а средняя производительность намного ниже. Поэтому для оценки производительности полезно изучить данные, полученные на тестовых приложениях.
Мы рекомендуем ознакомиться с исследованиями независимых групп, занимающихся тестированием процессоров, в частности Berkeley Design Technology Incorporated (BDTI) и Embedded Microprocessor Benchmark Consortium (EEMBC).
Если в вашем приложении значительная роль отводится сигнальной обработке, то вам следует изучить результаты тестов BDTI. Используя свои оценки, BDTI производит сравнение устройств по потребляемой мощности, скорости и цене. На рис. 2 приведено сравнение скорости ряда процессоров, полученное с использованием BDTImark2000 и BDTIsimMark2000 BDTImark2000 и BDTIsimMark2000 — это суммарные показатели скорости в задачах сигнальной обработки, которые основаны на результатах теста BDTI DSP Kernel Benchmarks включающего в себя набор из 12 ключевых алгоритмов ЦОС. Чем больше показатель, тем быстрее процессор. Найти другие показатели и узнать более подробно о тестах BDTI DSP Kernel Benchmarks можно на сайте www.bdti.com/bdtimark/BDTImark2000.htm.
Если в приложении необходима высокая производительность ядра сигнальной обработки и системное управление, характерное для микроконтроллера, то вы можете обратиться к результатам тестов EEMBC. Тесты EEMBC основаны на реальных приложениях и учитывают требования, на практике предъявляемые к встраиваемым системам. Они включают в себя набор «алгоритмов» и «приложений», ориентированных на телекоммуникационные, сетевые, цифровые мультимедийные, автомобильные/промышленные и бытовые устройства, а также офисное оборудование и устройства с под-
ADI Blackfin
AMCC РРС440ЕР
NEC VR4133
Philips PNX1700
ST231
0 5000 10 000 15 000 20 000 25 000 30 000 35 000
Рис. 3. Плотность кода. Результаты тестов EEMBC Consumer Suite (чем меньше оценка, тем лучше)
ADI Blackfin — 756 МГц AMCC РРС440ЕР - 667 МГц NEC VR4133 — 266 МГц Philips PNX1700 - 499,5 МГц ST231 — 300 МГц
і і і і I
і і I
0 10 20 30 40 50 60 70
Рис. 4. Производительность. Результаты тестов EEMBC Consumer Suite (чем больше оценка, тем лучше)
держкой Java. На рис. 3, 4 приведено сравнение плотности кода и производительности, основанное на последних результатах тестов EEMBC. Дополнительную информацию о тестах EEMBC вы можете найти на сайте http://www.eembc.org/.
Шаги на пути к успеху
По мере того, как объем приложений становится больше, а сами они — сложнее, весьма вероятно, что количество команд разработчиков, работающих над проектом, будет увеличиваться и станет значительно больше, чем при традиционном разделении на команду, отвечающую за задачи управления, и команду, отвечающую за сигнальную обработку. Например, при разработке компьютерной приставки к телевизору (set-top box), работающей по протоколу IP, может потребоваться команда, специализирующаяся на сжатии видеоизображений, а также команда, специализирующаяся на организации сетевого взаимодействия. Однако выделение специализированных подразделений разработчиков не обязательно подразумевает необходимость использования в системе большого числа различных архитектур. Напротив, системщикам следует стремиться к использованию конвергентных процессоров, которые будут удовлетворять требованиям всех команд разработчиков. Применение таких процессоров может способствовать увеличению скорости, сокращению объема работ и времени, которое необходимо для выпуска готового продукта на рынок, поскольку все команды разработчиков в этом случае будут работать с одной и той же архитектурой. ■
