Implementación del procesador Cortex-M0
DesignStart en una FPGA de rango bajo
Pedro Ignacio Martos y Fabricio Baglivo Laboratorio de Sistemas Embebidos
Facultad de Ingeniería - UBA Buenos Aires, Argentina
[email protected] / [email protected]
Abstract—Los procesadores de la línea CortexTM-M de ARM ltd.
están orientados a la implementación de microcontroladores y dispositivos mixtos (mixed signal) de bajo costo y bajo consumo; tanto como dispositivos en silicio como softcores o hardblocks en FPGA. Actualmente hay soluciones de Cortex-M en FPGA de Altera (Cortex-M1 como softcore) y de Actel (Cortex-M1 como softcore y Cortex-M3 como hardblock); mientras que Xilinx no ofrece soluciones de Cortex-M para su línea de FPGA. Por otra parte, ARM ha lanzado recientemente una versión reducida y de bajo costo del procesador Cortex-M0 (Cortex-M0 DesignStart™) sintetizable tanto para FPGA como para silicio. En el presente trabajo se muestran los resultados de la implementación de dicho procesador en una FPGA de rango bajo de Xilinx, lográndose de esta manera ampliar el rango de implementaciones de los procesadores Cortex-M en FPGA.
Keywords- Cortex-M0, FPGA
I. INTRODUCCION
A. Descripción de las familias de procesadores de ARM
En la línea de procesadores de ARM, la familia Cortex consiste en cores que van desde soluciones orientadas a microcontroladores de bajo costo hasta procesadores de alta perfomance con capacidad de ejecutar sistemas operativos complejos. Las lineas clásicas incluyen a las familias ARM7, ARM9 y ARM11 y las series especializadas SecurCore™ para aplicaciones de seguridad y criptografía. En la Fig. 1 se puede apreciar la ubicación relativa de cada familia en relación a su capacidad y funcionalidad.
Figura 1. Relación performance-capacidades de las distintas familias de procesadores de ARM
El procesador Cortex-M0 es el miembro de menor rango dentro de la familia Cortex-M de procesadores de ARM. Esta familia permite realizar distintos tipos de compromisos entre costo, simpleza de diseño, consumo, performance y capacidad de procesamiento dentro del segmento Embedded Processors. El Cortex-M0 apunta principalmente a lograr bajo consumo y la menor área de silicio, a fin de competir ventajosamente con procesadores de 8 bits de alta gama o procesadores de 16 bits mientras mantiene la compatibilidad de código con procesadores más potentes de la familia como el Cortex-M3. La menor implementación de Cortex-M0 consume 85μW/MHz y ocupa un área equivalente de 12.000 compuertas. Como referencia, un procesador clásico como el i8051 ocupa típicamente alrededor de 8.000 compuertas [1][2]. En la Fig. 2 vemos la ubicación relativa de cada miembro de la familia Cortex-M en función de su performance y plataforma de implementación.
Figura 2. Comparación entre los distintos miembros de la familia Cortex-M
B. Arquitectura del procesador Cortex-M0
Este procesador esta basado en la arquitectura ARMv6-M (Von Neumann) con un pipeline de 3 etapas, obteniendo un Dhrystone de 0,9 DMIPS/MHz; implementa hasta 32 interrupciones enmascarables más una no enmascarable a través de un controlador de interrupciones integrado (NVIC-Nested Vectored Interrupt Controller) con una latencia fija de 16 ciclos de máquina [3]. La Fig. 3 muestra un diagrama en bloques del procesador Cortex-M0
Figura 3. Diagrama en bloques de un procesador Cortex-M0
Su interfase con otros periféricos es a través de una versión reducida del bus Advanced Microcontroller Bus Architecture (AMBA®), denominada AMBA AHB–Lite. Este bus fue diseñado como un bus de alta performance para transferencias rápidas entre el procesador y periféricos que requieran gran ancho de banda y/o altas tasas de transferencia de datos. Generalmente se lo implementa con un único dispositivo que actúa como maestro y el resto como esclavos, aunque la especificación del bus permite la implementación de múltiples maestros. Sus principales características son que permite transferencias en ráfaga, sus operaciones se realizan en un ciclo de reloj (sincronizado con su flanco), no implementa tri-state y es configurable el ancho del bus (32, 64, 128, 256, 512 y 1024 bits) [4]. La Fig. 4 muestra una implementación del bus y las Figs. 5 y 6 muestran las señales de un dispositivo maestro y un dispositivo esclavo respectivamente.
Figura 4. Ejemplo de un sistema con bus AMBA-Lite
Figura 5. Señales de un dispositivo AMBA-Lite maestro
Figura 6. Señales de un dispositivo AMBA-Lite esclavo
C. Procesador Cortex-M0 DesignStart
El procesador Cortex-M0 DesignStart (M0DS) es una versión reducida del procesador Cortex-M0 standard (M0S) y fue lanzado al mercado el 4 de agosto de 2010. Sus principales diferencias con el procesador M0S son: El procesador M0S posee interfaces del bus AMBA-Lite como maestro y como esclavo, mientras que el M0DS sólo posee la interfase como maestro; el M0S puede implementarse con un multiplicador rápido de 1 ciclo de reloj o con uno lento de 32 ciclos de reloj, mientras que el M0DS sólo implementa el multiplicador lento. El M0S puede implementar de 1 a 32 interrupciones, el M0DS implementa 16 interrupciones fijas. El M0S opcionalmente puede incluir un controlador de interrupción para bajo consumo (WakeUp Interrupt Controller), control selectivo de reloj interno (arquitectural clock gating), hardware e interfaces de debugging (hasta 4 breakpoints por hardware y comunicación serial o JTAG) y un timer de referencia de 24 bits; el M0DS no incluye ninguna de las facilidades antes mencionadas [5][6][7].
II. IMPLEMENTACIÓN
A. Hardware y software utilizado
La FPGA empleada es de una línea madura y de rango bajo de Xilinx: S3E500-4; sus principales características son: 500K compuertas, 10500 celdas lógicas (equivalentes a 1100 bloques lógicos configurables (CLB) o 4600 slices), 20 multiplicadores por hardware, 360Kbits de bloques dedicados de ram, 73kbits de ram distribuida, 4 controladores de reloj y una frecuencia máxima de trabajo de 300MHz [8].
La placa utilizada es una placa básica (starter board) de la firma Digilent, modelo Nexys2. Cuenta con una FPGA S3E500, una interfase de programación y comunicaciones por USB, 16 Mbytes de PSDRAM y 16 Mbytes de Flash ROM, más una PROM de configuración; incluye un oscilador de 50MHz, 8 LEDS, 4 displays de 7 segmentos, 4 pulsadores y 8 interruptores. Hay disponibles 60 pines de I/O de la FPGA [9]. La Fig. 7 muestra un diagrama en bloque de la placa utilizada.
Figura 7. Diagrama en bloques de la placa de desarrollos utilizada
Una de las ventajas de esta placa es que, mediante un software que se obtiene de la página web del fabricante (Adept), es posible utilizar directamente las herramientas de programación de Xilinx (Impact, Chipscope Pro, Xmd, etc.), lo que permite programarla y ver su estado interno fácilmente.
Como herramientas de software se utilizó el entorno de desarrollo para FPGA de Xilinx ISE versión 12.2; para la generación de programas ejecutables en el procesador se utilizó el entorno de desarrollo ARM MDK de Keil Gmbh.
B. Elementos que integran el Cortex-M0 DesignStart Kit
Este kit tiene dos componentes: el procesador, representado por dos archivos en verilog sintetizable y un test bench que permite realizar pruebas básicas. Por otra parte se incluye un documento en formato PDF correspondiente a las notas de lanzamiento (Release Notes) [5].
El test bench se compone de un módulo no sintetizable en verilog que implementa al procesador conectado a una memoria preinicializada con un programa simple. Completan el test bench el código fuente en C del programa; la imagen en formato binario del programa y un makefile que permite obtener la imagen en formato binario a partir del código fuente en C. En la Fig. 8 se vé el diagrama en bloques del test bench.
Figura 8. Diagrama en bloques del test bench
C. Plan de trabajo de la implementación
La secuencia de actividades planificada fue: 1) verificar que el procesador sea sintetizable en la FPGA seleccionada. 2) crear un proyecto en la herramienta ISE de Xilinx que implemente el test bench y verificar su correcto funcionamiento mediante simulación. 3) generar el archivo binario a partir del código fuente utilizando el makefile provisto. 4) verificar en el test bench que el archivo binario generado sea correcto mediante simulación. 5) crear un proyecto en la herramienta ISE de Xilinx que implemente con componentes sintetizables el sistema de test bench. 6) generar un programa que permita interactuar con los recursos de hardware de la placa, a fin de verificar la correcta implementación del procesador. Verificar el mismo mediante simulación en el entorno de desarrollo del programa. 7) Integrar la imagen binaria del programa generado al proyecto que implementa el sistema sintetizable. Verificar su correcto funcionamiento mediante simulación funcional en el entorno ISE. 8) Sintetizar el proyecto con el programa integrado e implementarlo en la placa de desarrollos. Verificar el correcto acceso a los recursos de hardware de la placa.
D. Secuencia de implementación realizada
El ítem 1) se realizó sin mayor inconveniente, resultando en un uso aproximado del 50% de los Slices de la FPGA, lo que
determinó la viabilidad de realizar la implementación. Durante la ejecución del ítem 2), en la simulación se encontró que el procesador no llegaba a ejecutar la rutina principal del programa, sino que entraba en un estado bloqueado. A fin de encontrar la razón de ello, se continuó con el ítem 3), para obtener una simulación de la ejecución del software en el entorno de desarrollo del mismo. Para ello se utilizó el entorno de desarrollo ARM MDK de la firma Keil Gmbh, ya que era la herramienta que se indicaba en las notas de lanzamiento.
Al analizar en detalle el makefile para utilizarlo con el MDK se encontró que el mismo no era consistente: si bien las herramientas de compilación y enlazado eran del MDK (Armcc y Armlink), los parámetros pasados no correspondían a dichas herramientas. Buscando en la documentación de otros proveedores de herramientas de software para procesadores ARM se llegó a la conclusión que los parámetros correspondían a las herramientas del IAR Embedded Workbench de la firma IAR (Iccarm e Ilinkarm); por lo que el makefile provisto era en realidad compuesto por distintos makefiles y no servía para generar el archivo binario a partir del archivo fuente.
Ante esta situación, se decidió implementar un proyecto en MDK con el archivo fuente provisto, obtener un archivo binario, y utilizar este en la simulación para verificar si se repetía el problema del procesador bloqueado. Una vez realizado esto, nuevamente se obtuvo un estado de procesador bloqueado, pero al disponer del proyecto en MDK, era posible comparar la simulación de software en MDK con la simulación funcional del test bench en ISIM de Xilinx. Al realizar dicha comparación, se encontró que la simulación del software en MDK funcionaba correctamente, mientras que la simulación funcional en el ISIM mostraba valores que no correspondían en los buses de datos. Un análisis detallado del problema mostró que el test bench no estaba correctamente implementado: la parte del mismo encargada de inicializar la memoria realizaba una lectura del archivo binario mediante la función de verilog $fread asumiendo que la misma realizaba una lectura de 4 bytes simultáneamente (32bits), cuando la misma en la implementación de verilog de Xilinx realiza una lectura de 1 byte (8bits) a la vez; por lo que se corrigió el test bench a fin de que se realice correctamente la inicialización de la memoria; y de esa manera la simulación de software del MDK coincidió con la simulación funcional de ISIM para el código fuente provisto.
Habiendo subsanado los inconvenientes antes mencionados, se paso a los ítems 5) Sistema Sintetizable y 6) Programa que utilice el hardware de la placa de desarrollos. Se decidió empezar por el programa. A fin de no implementar un dispositivo esclavo con el que comunicar el procesador (lo que agregaría complejidad al proyecto), se decidió implementar un programa que cargara dos valores distintos constantes en una variable con un cierto retardo entre cada carga. Esto generaría un programa que buscara dichos valores constantes en memoria, lo que obligaría a aparecer a dichos valores sobre el bus de datos del procesador, permitiendo su detección. Este programa se simuló en el entorno MDK y se verificó el acceso a memoria en busca de los valores constantes antes mencionados. En la Fig. 9 se observa una captura de la pantalla del simulador de software. Una vez realizada esta verificación,
se cargo el programa en el test bench y se verifico en la simulación funcional con ISIM que los valores elegidos aparecían sobre el bus de datos. En la Fig. 10 se ve una captura de la simulación funcional en ISIM.
Figura 9. Simulación de software mostrando el acceso a memoria
Figura 10. Simulación funcional mostrando el acceso a memoria
Siendo exitosas las simulaciones, se implemento el sistema sintetizable. El mismo consta de las siguientes partes: “Procesador”, con el código verilog del procesador Cortex- M0DS; “Sincronizador de reset”, implementado con un contador que fija una señal en nivel alto al llegar al final del conteo, a fin de generar una señal de reset sincrónica con el reloj del sistema. Memoria”, implementado como una RAM preinicializada con el archivo binario generado en MDK. “Reloj”, que implementa la señal de reloj de referencia, a través de un DCM de la FPGA fijado a 10MHz a partir del oscilador de 50MHz que provee la placa de desarrollos. Y finalmente “Detector de Bus”, que detecta sobre el bus de datos los valores constantes programados y comanda un Led de la placa de desarrollos que se prende cuando detecta un valor programado y se apaga cuando detecta el otro valor. Cabe destacar que fue necesario desarrollar un software que convirtiera el formato binario del archivo de programa al formato COE necesario para inicializar la memoria. Se verificó mediante simulación funcional en el ISIM el correcto funcionamiento del sistema completo, en particular del detector de bus, el cual reaccionó correctamente frente a los datos que aparecían sucesivamente sobre el bus de datos.
Finalmente se implemento completamente el sistema y se programó la placa con el mismo, realizándose las siguientes verificaciones: con la herramienta ChipScope Pro, que permite
ver señales internas de la FPGA, se verificó la aparición de los valores constantes programados; y visualmente se verificó que a los intervalos programados para los accesos a memoria, un led de la placa de desarrollos cambiaba de estado de encendido a apagado, dándose así por validada la implementación del procesador en la FPGA.
III. RESULTADOS Y CONCLUSIONES
El resultado más destacable es que es posible implementar este procesador en una FPGA de rango bajo, lo que permite su aplicación en sistemas embebidos sobre FPGA de bajo costo. Asimismo se amplió el espectro de implementación del procesador Cortex-M0, ya que ahora es posible implementarlo sobre los tres principales proveedores de tecnologias de FPGA (Xilinx, Altera y Actel), lo que lo convierte en una plataforma a considerar en situaciones en las que la portabilidad entre distintos fabricantes de FPGA es un requisito.
Como estadísticas de implementación, en la Fig. 11 se muestran los resultados de uso de la FPGA:
Figura 11. Estadisticas de uso de la FPGA una vez realizada la implementación del sistema
Como resultados de temporización, la herramienta de síntesis y los resultados Post Place and Route indicaron una frecuencia máxima de trabajo de alrededor de 40MHz. Cabe aclarar que no se realizaron ningún tipo de restricciones de temporización o ubicación de componentes en el sistema.
Otra particularidad de este procesador es que es posible acceder directamente a los registros internos del mismo, lo que lo hace útil en aplicaciones educativas, ya que es posible observar la total concordancia entre la simulación de software, la simulación funcional en ISIM, y la verificación de la implementación a través de ChipScope Pro a nivel de registros internos del procesador.
Como aspecto a considerar sería las mejoras al test bench provisto; acortaría mucho el tiempo de desarrollo tener un test bench completo que permita generar el archivo binario a partir del archivo fuente. Esto no fue posible con los elementos provistos, por lo que fue necesario realizar las actividades mencionadas en la implementación.
Como conclusión, este procesador se integra a la familia de procesadores softcore sintetizables sobre FPGAs de Xilinx, junto con el Microblaze y el Picoblaze, ofreciendo la ventaja de ser migrable a otras arquitecturas de FPGA (Actel, Altera). Como línea de trabajo futura se propone crear una
implementación de bus AMBA-Lite y periféricos compatibles con este bus, a fin de aumentar sus capacidades y convertirlo en una opción a tener en cuenta en la creación de sistemas embebidos sobre FPGAs de Xilinx. Una vez realizado esto se buscará desarrollar un sistema con capacidad de ejecutar variantes de embedded Linux, a fin de aplicarlo en el área educativa en el Curso de Sistemas Embebidos dictado por la FI-UBA.
IV. REFERENCIAS
[1] CAST T8051 Core Product Brochure (www.cast-inc.com)
[2] IPextreme M8051EW+ Core – Product Characteristics (www.ip-extreme.com)
[3] ARM Ltd, “ARM DDI 0419C ARMv6-M Architecture Reference Manual”, Septiembre de 2010.
[4] ARM Ltd, “ARM IHI 0033A AMBA 3 AHB-Lite Protocol V.1.0 Specification”, Junio de 2006.
[5] ARM Ltd, “AT510-DC-80001-r0p0-00-rel0 ARM Cortex-M0 DesignStart Release Note”, Agosto de 2010.
[6] ARM Ltd, “ARM DDI 0432C Cortex-M0 Revision r0p0 Technical Reference Manual”, Noviembre de 2009.
[7] ARM Ltd, “ARM DUI 0497A Cortex-M0 Devices Generic User Guide”, Octubre de 2009.
[8] Xilinx, “DS312 Spartan-3E FPGA Family: Datasheet”, Agosto de 2009. [9] Digilent, “Digilent Nexys2 Board Reference Manual”, Junio de 2008.
V. AGRADECIMIENTOS
A la gente del programa universitario de ARM, en particular a William Hohl y Joe Bungo; a Fiona Cole de Digilent Inc.; y la gente del programa universitario de Xilinx (XUP) por su ayuda y cooperación.
VI. MARCAS REGISTRADAS
La información acerca de las familias de procesadores de ARM fue extraida principalmente del sitio web de ARM Ltd. (www.arm.com) publicada en octubre de 2010.
ARM, Cortex, Cortex-M, AMBA, AMBA-Lite, y otras marcas mencionadas son marcas registradas de ARM Limited.
Xilinx, Spartan, ISE, y otras marcas mencionadas son marcas registradas de Xilinx Inc.
Digilent, Nexys2, Adept, y otras marcas mencionadas son marcas registradas de Digilent Inc.
Todas las otras marcas registradas mencionadas son propiedad de sus respectivos propietarios.
Las Figuras 1 a 6 y la Figura 8 son copyright ARM Ltd. Reproducidas con permiso.
