Решения, решения:аппаратный ускоритель или DSP?

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

(Источник:CEVA)

В прошлом блоге я упоминал об идеальных приложениях для DSP. Наглядными примерами являются обработка сигналов модема или аудиосигналов. Другой очень распространенный пример - обработка сигнала в радарах для автономных автомобилей, которая очень похожа на обработку сигнала в модеме. Многие из них были построены на основе аппаратного ускорителя в сочетании с небольшим контроллером. Сейчас мы наблюдаем значительную тенденцию среди этих поставщиков решений к переходу на архитектуры, в которых большая часть функциональности основана на программном обеспечении, работающем на DSP, сочетающем обработку сигналов, которая в настоящее время обрабатывается HWA, и даже некоторый контроль. Причина проста:программное обеспечение обеспечивает большую гибкость в функциональности и гораздо более низкую стоимость и возможность более своевременной адаптации к развивающимся стандартам связи.

Глобальное позиционирование - еще одно приложение, в котором в значительной степени используются математические возможности, присущие ЦСП, для расчетов триангуляции. Сначала вы могли подумать, что поддержка GPS - это все, что вам нужно, и, возможно, вы сможете создать действительно быструю реализацию на аппаратном ускорителе. Однако в глобальном стандарте GNSS также необходимо учитывать поддержку ГЛОНАСС (Россия), Galileo (Европа) и BeiDou (Китай). Аппаратная реализация GPS может без надобности ограничить ваши рынки, поскольку поддержка всех вариантов может быть реализована программно, если вы используете DSP.

Пока все в принципе хорошо, но как реализация DSP будет работать по сравнению с пользовательской аппаратной реализацией? Я проиллюстрирую это одним популярным сегодня примером:предположим, вы создаете приложение IoT и планируете использовать NB-IoT для связи. Длина подкадра составляет 1 мс, что определяет ограничивающий предел для определенной обработки, которая должна быть завершена за это время. В этом примере это будет включать алгоритмы физического уровня, управляющий код L1 и стек протоколов. Для типичной маломощной платформы DSP / NB-IoT, работающей на частоте 100 МГц, 1 мс дает вам 100 000 циклов для выполнения этих вычислений.

Чтобы оценить, какую производительность вы можете ожидать от эквивалентной реализации DSP, вам необходимо обратиться к поставщику встроенного DSP. Такая компания уже должна предлагать программные решения на своих платформах для множества приложений, которые будут характеризоваться производительностью и мощностью. Для обеспечения производительности они должны иметь возможность дать вам оценку количества циклов для вашей функции, в данном случае модема NB-IoT, и предоставить вам график, аналогичный приведенному ниже. Каждая точка на графике представляет количество циклов, необходимых для выполнения, а график построен для изменяющегося во времени диапазона нагрузок. На графике также должны быть показаны допустимые пиковые значения циклов для выбранной рабочей частоты.

(Источник:CEVA)

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

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

Быстрый способ получить оценку мощности - это посмотреть, какая часть программного обеспечения войдет в истинный код DSP, используя параллелизм, блоки MAC и т. Д., И сколько будет идти в управляющий код - обычный общий - целевой код функций вызова, принятия решений и других стандартных операций. Обычно вы можете наблюдать за этим разделением, скажем, 40% управляющего кода и 60% кода DSP. Поставщики DSP часто предоставляют типичные значения мощности для этих двух случаев, например, 2 мВт для кода управления и 4 мВт для кода DSP (в каждом случае на частоте 100 МГц). В своих расчетах вы должны учитывать среднюю активность DSP, например, 50% частоты. Итак, в этом примере вы оцените (0,4 * 2 + 0,6 * 4) * 0,5 =1,6 мВт средней мощности (при условии, что средняя активность составляет 50%).

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