¿Cuáles son los usos típicos de un procesador de software como MicroBlaze?

Sé que la combinación FPGA-DSP se usa típicamente para electrónica de potencia/ultrasonido/MRI/etc. ¿Es posible que el procesador de software reemplace por completo al DSP incluso en FPGA de gama baja como Spartan 3/6?

Agregado: ¿Cuál sería la razón para tener múltiples procesadores softcore en un FPGA?

Depende de qué tan intensiva en DSP sea su aplicación, básicamente.
Me vienen a la mente los odiados winmodems , aunque allí tenías una CPU de uso general que hacía el DSPing.
Aparentemente, puede hacer radio definida por software en un Virtex 5 y también en Altera Stratix .
Y aparentemente algunos lo han intentado en un Spartan 6 LX45. ¿Qué aplicación tienes en mente?
El principal problema que vi en ese hilo es el útil software Vivado (basado en PC) que funciona para generar filtros, etc. para Virtex no te permite apuntar al Spartan. No estoy seguro de si fue solo una decisión de marketing [segmentación] o si el hardware de Spartan es demasiado bajo.

Respuestas (2)

Siéntase libre de leer rápidamente o saltar hasta el final. ¡Me doy cuenta de que me pasé un poco!


En general, no usaría un procesador de software para reemplazar las cosas DSP. El hardware dedicado generalmente puede manejar mayores volúmenes de datos más rápido porque lo diseñaría para realizar una tarea específica muy bien, en lugar de ser una CPU de propósito general.

Donde los procesadores blandos entran en su elemento es el control y la coordinación.

Si tuviera que diseñar un sistema que necesitara procesar un gran volumen de datos, digamos adquisición de imágenes de alta velocidad de cuadros, no sería posible usar un procesador de núcleo blando para manejar todos los datos, simplemente habría demasiada sobrecarga. en la CPU. Lo que haría es diseñar un firmware dedicado para realizar la tarea de adquisición específica necesaria (por ejemplo, filtrar los datos, almacenarlos en la memoria, etc.).

Sin embargo, aún necesita alguna forma de indicarle cuándo hacer las cosas: cuándo desea capturar, si se le indicó al dispositivo que descargue los datos, etc. Estas cosas no son muy fáciles de hacer en hardware dedicado, no si hay secuencias de eventos con entrada del usuario, básicamente tareas que no hacen lo mismo una y otra vez. En este caso, usaría un procesador de núcleo blando, ya que es mucho más fácil escribir código de procedimiento para algunas tareas.

Otro ejemplo (real), he estado trabajando en un sistema de adquisición de ultrasonido que transmite datos a través de PCIe. Las tareas que realiza son comunicadas por el usuario y es necesario configurar varias partes del sistema. La coordinación del sistema no requiere grandes volúmenes de datos, sino que necesita flexibilidad, por lo que se adapta bien a una CPU de núcleo blando programada con, en este caso, C. Hacer lo mismo en hardware físico requeriría una gran cantidad de recursos. la mayoría de los cuales se usarían con poca frecuencia, por lo que no verían ningún beneficio en comparación con una CPU.

Vale la pena señalar que algunas tareas pueden variar según la entrada del usuario, pero aún son mejores en hardware dedicado. De hecho, una parte del código (la programación de los controladores DMA para almacenar datos en el disparador) se realizó originalmente en la CPU en unas 15 líneas de código, pero debido a que ese bit debe realizarse en el momento en que se produce el disparador, utilizando una CPU que puede ser ocupado con otras cosas no es lo ideal. En cambio, la tarea se programa en un módulo Verilog, pero en el proceso se convierte en una enorme máquina de estado de 500 líneas con aproximadamente 15 estados y una gran cantidad de lógica de soporte, no realmente. Pero a pesar de que utiliza muchos más recursos, el tiempo es crítico, por lo que es una necesidad.

De manera similar, necesito una generación de activación precisa del ciclo del reloj, por lo que un módulo para realizar esa tarea es parte del sistema en lugar de hacerlo en una CPU. Tanto este núcleo como el anterior son ejemplos de cómo puede usar una CPU para realizar algunas tareas, pero para otras críticas puede desarrollar hardware para complementar la CPU, de la misma manera que tiene temporizadores, etc. en un microcontrolador.


Así que para resumir:

Los FPGA son excelentes herramientas flexibles, pero la mayoría de los diseños necesitan una combinación de CPU de núcleo blando, módulos configurables (por ejemplo, temporizadores) y hardware dedicado para una sola tarea.

Las CPU son excelentes para la interacción del usuario, controlar el orden de los eventos y configurar los controladores. Son como el coordinador, el cerebro.

Es posible que algunos diseños deban realizar algunas tareas bastante repetitivas que se pueden configurar para adaptarse a diferentes entradas: módulos de temporizador, pantallas de caracteres, antirrebote de botones, etc. una vez que se vuelve más complicado, comparten los mismos recursos de CPU. Entonces, lo que puede hacer es moverlos a un hardware dedicado que está estrechamente conectado a la CPU: déle a la CPU la oportunidad de realizar otras tareas. Estos ayudan a la CPU a hacer su trabajo e interactuar con su entorno, como sus sentidos.

DSP dedicado, transferencia de datos (DMA), básicamente cualquier tarea que haga lo mismo una y otra vez a altas velocidades, realmente puede beneficiarse de la lógica dedicada en términos de velocidad y también posiblemente de potencia. Estos son como los músculos del dispositivo, hacen todo el trabajo pesado.

Tendrá que disculpar un poco las divagaciones, pero me gusta este campo de EE. Con suerte, lo anterior es comprensible y le brinda una idea adicional del maravilloso mundo de los FPGA.

@tcrosley Entiendo su punto, pero si quiere agregar dos números de 128 bits en un procesador de 32 bits, tomará varios ciclos. El énfasis estaba en un poder . Pero en realidad depende completamente de lo que estés haciendo como un todo. Si todo lo que quisiera hacer fuera la adición, tener una CPU completa no tendría sentido en un FPGA, solo cree una instancia de un sumador. Así que creo que quitaré ese bit.

Como mencionó Tom, el MicroBlaze no es tanto una cuestión de reemplazar un DSP, sino de reemplazar un microcontrolador tradicional que de otro modo podría estar en la placa.

Esto se debe a que el núcleo del procesador de software MicroBlaze no es un sustituto particularmente bueno para un DSP, ya que carece de características especiales de DSP, como instrucciones MAC (multiplicar y acumular), búferes circulares, direccionamiento de bits invertidos y lógica de saturación.

Por lo tanto, un núcleo blando DSP separado, como el que se describe en este documento para Xilinx Virtex-4, sería una mejor opción.

Muchos diseños de DSP se beneficiarían de tener ambos núcleos blandos, ya que muchos, si no la mayoría, de los diseños digitales que incluyen un FPGA también necesitan un microcontrolador general de algún tipo. Siempre que haya suficientes recursos disponibles en la FPGA (ver más abajo), los procesadores suaves como el MicroBlaze no solo eliminan una parte de la lista de materiales (y, por supuesto, su costo asociado), sino que también liberan pines en la FPGA ya que hay no es necesario interconectar entre el FPGA y un microcontrolador. También se libera el espacio necesario para los trazos entre las dos partes.

El MicroBlaze puede funcionar a 210 MHz en un Virtex-5. Las versiones con una MMU pueden ejecutar Linux. Un MicroBlaze mínimo necesita alrededor de 600 LUT y puede crecer hasta 4000 si se agregan una FPU, MMU, caché y otras ventajas. El procesador de software DSP mencionado anteriormente utilizó 1700 LUT.

Dado que un FPGA Virtext-5 puede tener entre 30 000 y más de 200 000 LUT, incluso la inclusión de estos dos núcleos blandos representa solo una fracción del chip. La incorporación de ambos permite que tanto las operaciones convencionales como las DSP se lleven a cabo en paralelo, si se desea, a costa de cierta complejidad adicional para la sincronización entre las dos.

La IP de MicroBlaze es gratuita siempre que la use en un FPGA de Xilinx y tenga licencia de ISE Design Suite Embedded Edition (o equivalente).