Для встраиваемых систем выбор кубиков, которые можно сложить во что-нибудь путное, не так уж и велик. То, что находится прямо перед глазами, не дает однозначного выбора.
ARM хорош и к тому же быстро развивается, сопроцессор с плавающей точкой NEON с распараллеливанием выполнения (pipeline) уже само собой разумеющийся атрибут. В последнее время обозначилась новая мода – использовать GPU для решения вычислительных задач, таких как FFT. Программировать под ARM – одно удовольствие, если пользоваться кросс-компилятором на собственной машине, среда Embedded Linux как правило привычна и дружественна разработчику. За все это заплачено отсутствием реального времени и возможностей обработки данных в синхронном режиме. Что же, для этого есть другие инструменты.
FPGA мыслится как первое что можно поставить скажем после АЦП. Синхронная обработка параллельных данных и возможность фильтрации на высокой частоте выборок (до 500 MS/s) определяют ПЛИС как стандарт де-факто на первом месте в сигнальном тракте. После фильтрации и децимации сигнал получается использовать как в DSP, так и в том же ARM. Конечно, с ПЛИС лучше работать не программисту (который может получить вывих мозга), а традиционному инженеру-схемотехнику. В конечном счете, FPGA есть не что иное как миллионы логических элементов, которые нужно просто соединить правильным образом.
Роль DSP также понятна: числодробилка с собственным pipeline, которая к тому же может принимать данные с синхронного интерфейса и вести обработку на несущей частоте. В современных процессорах операция FFT над выборкой 1К чисел с плавающей точкой занимает буквально несколько микросекунд. Сколько гребенок доплеровского фильтра можно сделать с таким процессором!
Рано или поздно кому-нибудь пришла бы в голову мысль скрестить между собой попарно эти кубики. В результате родилась архитектура Zynq, где возник симбиоз ARM + FPGA, и архитектура OMAP, основанная на ARM + DSP. Вот про вторую конфигурацию я бы хотел поговорить подробнее.
ARM+DSP или DSP+ARM?
Идея работать в дружественной среде Linux и одновременно получить те возможности, которые дает DSP, выглядит очень привлекательно. Для радиоинженера логичной бы выглядела связка DSP+ARM (именно в этой последовательности), в которой сигнал через физический интерфейс поступает в обработку DSP, в результате которой извлекаются информационные параметры сигнала, и ARM принимая эти полученные данные доделывает уже остальное: организует третичную обработку, отображение, управление и контроль.
Однако, все получилось немного не так. По замыслу разработчиков архитектуры OMAP, которая позиционируется как мультимедийная, DSP выступает в роли Accelerator Subsystem, фактически как сопроцессор-акселератор на подхвате у ARM. В принципе понятно, для чего это придумывалось: ARM получает данные с какой нибудь камеры, а DSP сопроцессор берет на себя критичные куски алгоритма, для которых требуется производительность. Но мы не привередливые: пусть будет ARM+DSP, где Linux на первой руке получает блоки данных, пусть и в асинхронном режиме, а условный доплеровский фильтр берет на себя DSP. На том и порешили, после двинемся дальше.
Codec Engine
Поскольку мы имеем представление, что будут делать ARM и DSP порознь, сосредоточимся на том, как они будут обмениваться данными. Хотя эти ядра и расположены на одном кристалле, но все таки это два совершенно разных процессора. Интуитивно понятно, как это может быть сделано: для этих процессоров существует некая общая область памяти, которую заполняет ARM и читает DSP и наоборот, если мы хотим сделать обмен данными двунаправленным. Ну и конечно должны быть библиотеки неких функций, которые можно дергать со стороны ARM, что проявится в виде неких сигналов в подсистеме DSP: данные мол готовы, забирайте.
Для тех, кто сталкивался с обеспечением подобного рода взаимодействия, а точнее – с разработкой протокола, известно с какой головной болью это связано. Поэтому благой вестью для нас является то, что компания Texas Instruments, разработчик SoC OMAP 3530, очень сильно постаралась не только для создания такого протокола, но пошла еще дальше – создала целый программный API под названием Codec Engine. Вот как эта структура выглядит на практике:
Codec Engine: передача данных между ARM и DSP
Codec Engine, или CE, берет на себя множество мелочей, в которых так легко сделать ошибку: выделение памяти под передаваемые данные как со стороны ARM, так и со стороны DSP, поддержку функций обмена, средства сборки проекта опять таки со стороны ARM Linux, так и со стороны SYS/BIOS DSP. Кроме этого библиотеки CE включают в себя средства отладки, что вообще замечательно в части DSP, потому как просто так в этот процессор не залезешь.
Механизм обмена между ядрами ARM и DSP я использовал в проекте пассивного радиолокатора, где DSP подсистема использовалась для тяжелонагруженного алгоритма нахождения функции неопределенности сигнала.
Ложка дегтя
Так и стали бы ARM с DSP жить и добра наживать, и потускнел бы заголовок нашей статьи – причем здесь горечь, видны только одни радости? Как обычно бывает, при погружении в каждую технологию начинают всплывать вещи, о которых вначале не подозреваешь. Ничего страшного конечно не происходит, но есть нюанс. Об этой ложке дегтя – далее.
Сам CE – достаточно тяжелое решение. То, что компилируется из исходников, у меня на машине состоит из 103599 файлов – ни много ни мало. Собственные приложения выглядят карликом на фоне этого монстра ) Проект был собран и запущен в работу, и все было ОК. Но как-то появилась необходимость опробовать новые приложения на ARM стороне, которые требовали версии ядра Linux постарше чем 2.16. В чем проблема, накатим новое ядро! И тут опс… Codec Engine не захотел собираться с новым ядром. В чем причина?
Как выяснилось, подсистема Линукс-ядра IOMMU, которая отвечает за отображение памяти на периферийные устройства и которую использует CE, существенно изменилась в версиях Linux старше 3.0.50. Почему именно этот номер версии – потому что это максимум, чего получилось достичь вместе с патчами ядра. Вот тут и обозначился проблемный аспект архитектуры OMAP: на апгрейд Linux на стороне ARM можно ставить крест. Нет, вы конечно можете использовать только ARM ядро, без DSP с любой версией Linux. Но тогда про DSP можно забыть.
Второе. Само собой разумеется, моим приложениям на ARM понадобилась поддержка операций с плавающей точкой, и я решил поставить дистрибутив с аппаратной поддержкой этих операций. И соответственно перекомпилировать CE с новыми библиотеками. И тут началось… как выяснилось Texas Instruments как бы это мягче сказать… не вполне наделил свои исходники возможностями брать конфигурацию с корневых make файлов. Я обнаружил кучу кода, который отказывался компилироваться просто по той причине, что он просто игнорировал замену конфигурации с arm-linux-gnueabi на arm-linux-gnueabihf. Приходилось править его вручную. Было заметно, что в дебрях ветвей CE находятся такие древние файлы, что похоже в TI могло не остаться людей которые могут подсказать что они там делают )
Так что будьте осторожны с такими комплексными архитектурами. После экспериментов со связкой ARM+DSP невольно стала напрашиваться мысль что лучше было бы сделать взаимодействие между ними на аппаратном уровне…
Что касается Zynq, то обмен между ARM и FPGA был выполнен на удивление просто: стандартными средствами Linux DMA через обычное устройство /dev/xdma. Простая поддержка файловых операций, не более того. Интересно, почему по этому пути не пошли Texas Instruments в Codec Engine?
Leave a Reply