Decisiones, decisiones:¿Acelerador de hardware o DSP?

En mis dos primeros blogs sobre este tema, hablé sobre por qué los DSP están apareciendo repentinamente en todas partes y por qué, en particular, están comenzando a desplazar algunos aceleradores de hardware personalizados (HWA) como una opción más flexible y preparada para el futuro. En este blog, quiero hablar sobre un análisis más detallado que puede seguir para decidir si debería pensar en un DSP en lugar de una implementación de HWA.

(Fuente:CEVA)

Mencioné en el último blog algunas de las aplicaciones ideales para DSP. El procesamiento de señales para módem o señales de audio son ejemplos obvios. Otro ejemplo muy común es el procesamiento de señales en radares para automóviles autónomos, que es bastante similar al procesamiento de señales en un módem. Muchos de estos se han construido alrededor de un acelerador de hardware combinado con un pequeño controlador. Ahora estamos viendo una tendencia significativa entre los proveedores de soluciones para cambiar a arquitecturas en las que la mayor parte de la funcionalidad se basa en software que se ejecuta en un DSP, combinando el procesamiento de señales que maneja actualmente el HWA e incluso algún control. El razonamiento es simple:el software proporciona más flexibilidad en la funcionalidad y una capacidad mucho más económica y más oportuna para adaptarse a los estándares de comunicación en evolución.

El posicionamiento global es otra aplicación, en este caso aprovechando en gran medida las capacidades matemáticas inherentes a los DSP para los cálculos de triangulación. Al principio, podría pensar que el soporte GPS es todo lo que necesita y tal vez pueda construir una implementación realmente rápida en un acelerador de hardware. Sin embargo, en el estándar GNSS global, también debe considerar el soporte para GLONASS (Rusia), Galileo (Europa) y BeiDou (China). Una implementación cableada para GPS puede limitar sus mercados innecesariamente, ya que el software puede admitir todas las variantes si está ejecutando un DSP.

Hasta ahora, todo va bien en principio, pero ¿cómo funcionará una implementación de DSP en comparación con una implementación de hardware personalizada? Lo ilustraré con un ejemplo popular de hoy:digamos que está creando una aplicación de IoT y planea usar NB-IoT para la comunicación. La longitud de la subtrama es 1 ms, lo que define un límite para cierto procesamiento que debe completarse dentro de ese tiempo. En este ejemplo, eso incluiría los algoritmos de la capa física, el código de control L1 y la pila de protocolos. Para una plataforma DSP / NB-IoT de baja potencia típica que se ejecuta a 100MHz, 1 ms le brinda 100k ciclos para completar esos cálculos.

Para estimar qué tipo de rendimiento puede esperar en una implementación de DSP equivalente, deberá trabajar con un proveedor de DSP integrado. Dicha empresa ya debería ofrecer soluciones de software en sus plataformas para múltiples aplicaciones, que habrán caracterizado por su rendimiento y potencia. Para el rendimiento, deberían poder darle una estimación de recuento de ciclos para su función, en este caso un módem NB-IoT, y proporcionarle un gráfico, similar al que se muestra a continuación. Cada punto del gráfico representa el número de ciclos necesarios para ejecutar y el gráfico se traza en un rango de cargas que varía en el tiempo. El gráfico también debe mostrar los ciclos máximos permitidos dada una frecuencia operativa seleccionada.

(Fuente:CEVA)

Ahora tiene un método para estimar si la carga de su aplicación funcionará a esa frecuencia, o si es posible que necesite aumentar la frecuencia para darle más margen de maniobra. Por supuesto, esta estimación se basa en la implementación del software del proveedor, aunque es razonable esperar que esté bastante bien ajustada. No es necesario que se comprometa a utilizar su software, pero la estimación debe ser lo suficientemente buena como para guiar su toma de decisiones.

Si tiene suficiente margen de maniobra en su frecuencia operativa preferida, tal vez pueda mover más funciones HWA al DSP, o tal vez agregar más características diferenciadoras como soporte de ubicación GNSS. Si, por otro lado, necesita aumentar la frecuencia para cumplir con los requisitos de latencia, también es posible, aunque debe tener en cuenta que aumentar la frecuencia aumentará el área y el consumo de energía.

Una forma rápida de obtener una estimación de la potencia es observar qué parte del software se incluirá en el verdadero código DSP, utilizando paralelismo, unidades MAC, etc., y cuánto se incluirá en el código de control (el general habitual) funciones de llamada de código de propósito, toma de decisiones y otras operaciones estándar. Por lo general, puede observar esta división, digamos 40% de código de control y 60% de código DSP. Un proveedor de DSP proporcionará a menudo números de potencia típicos para estos dos casos, por ejemplo, 2 mW para el código de control y 4 mW para el código DSP (en cada caso a 100 MHz). En su cálculo, debe tener en cuenta la actividad media del DSP, por ejemplo, el 50% de la frecuencia. Entonces, en este ejemplo, estimaría (0.4 * 2 + 0.6 * 4) * 0.5 =1.6mW de potencia promedio (asumiendo una actividad promedio del 50%).

En resumen, debería poder desarrollar una estimación bastante razonable de qué rendimiento y potencia puede esperar para una implementación DSP de su función de aceleración (a menos que esté desarrollando algo realmente inusual; en este caso, debe modelar su aplicación en el DSP). Herramientas de software para obtener una estimación bastante precisa del recuento de ciclos). Cuando considera la flexibilidad adicional que obtiene de una implementación de software y la capacidad de ahorrar costos al combinar varios aceleradores en un procesador, una solución DSP parece bastante atractiva.