Calificaciones ARM Cortex M0+ CoreMark

Actualmente, cuando trabajo con microcontroladores, uso PIC de Microchip y estoy bastante contento con ellos. Sin embargo, decidí echar un vistazo a ARM para un posible proyecto próximo. Quería elegir el mejor ARM (el más rápido en los cálculos en el extremo económico/de baja potencia). En el sitio web de ARM ( aquí ), el Cortex M0+ aparece en 2,46 CoreMark/MHz. Pensé que la calificación de CoreMark se aplicaría a todos los microcontroladores con núcleos M0+, pero en la página de Atmel SAM D20, el microcontrolador aparece con 2,14 CoreMark/MHz. Leí en algunos sitios web que el compilador afecta la puntuación de CoreMark. También he visto sitios web que enumeran un M0+ con 1,77 CoreMark/MHz sin hablar de un compilador ( element14). También noté que ARM habla sobre M0+ en un proceso de 40 LP, mientras que el sitio de element14 habla sobre ARM en un proceso de 90 LP. Lamentablemente, no tengo conocimientos sobre la fabricación de procesadores a escala de chip.

Así que mis preguntas son;

  1. ¿Existen variantes del núcleo del procesador M0+? En caso afirmativo, ¿cómo identifica cuál es cuál?
  2. Si se programa en lenguaje ensamblador, ¿todos los microcontroladores con núcleos ARM Coretex M0+ tendrían la misma clasificación CoreMark?

Por cierto, el micro que pretendo usar es de la familia MKL03Z. Más información sería apreciada.

¡Gracias!

Google: infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0350a/… . Es bastante obvio a partir de TFM que se trata de una evaluación comparativa de la CPU más la cadena de herramientas . La capacidad del compilador para optimizar y la configuración del optimizador que se utilice tendrá un impacto mucho mayor que las diversas funciones principales implementadas.

Respuestas (3)

Respuesta corta:

  1. No

Respuesta larga:

Los núcleos ARM tienen características que cada fabricante puede o no decidir implementar (por ejemplo, cachés, ancho de búsqueda de bus, FPU, MPU, etc.; por supuesto, la disponibilidad depende del tipo de núcleo, por ejemplo, 7xx, 9xx, M0, M0+, M3, M7, etc).

Tener o no alguna característica afectará el rendimiento de la CPU.

La siguiente imagen está tomada de la hoja de datos SAMD21. Como puede ver, deciden implementar un multiplicador rápido y un ancho de búsqueda de 32 bits. Esto probablemente permitió que el SAMD21 alcanzara una cifra de 2,46 CoreMark/MHz.

ingrese la descripción de la imagen aquí

La hoja de datos dice:

Los dispositivos SAM D21 funcionan a una frecuencia máxima de 48 MHz y alcanzan los 2,46 CoreMark/MHz

(Por cierto, el SAMD20 también afirma que puede llegar a esa cifra, y no solo a 2,14).

Los dispositivos SAM D20 funcionan a una frecuencia máxima de 48 MHz y alcanzan los 2,46 CoreMark®/MHz.

Si programó en ASM dos Cortex M0+ diferentes, con diferentes opciones (por ejemplo, uno tiene un multiplicador lento y un ancho de búsqueda de instrucción de bus de 16 bits, y el otro tiene un multiplicador rápido y un ancho de búsqueda de 32 bits), entonces los resultados serían diferentes. Los resultados también serían diferentes si la prueba se ejecutara en memorias con diferentes tiempos de acceso.

Además, los resultados de Coremark, que se encuentran en el sitio web de Coremark, especifican la versión del compilador (y los indicadores utilizados para compilar la prueba). Por lo tanto, también dependen del compilador.

Puede encontrar las opciones configurables directamente desde ARM aquí en la sección 1.4. Por lo que vale, uno de sus ingenieros me dijo que Atmel/Microchip generalmente implementa todo lo que ofrece ARM.
Gracias por el comentario @SpehroPefhany. Seguí el enlace para leerlo. Solo una pequeña corrección, que se relaciona con la configuración central de M0. La configuración del núcleo M0+ está aquí ¡Gracias!
next-hack Gracias, esa fue una buena explicación y gracias por señalar la tabla de configuración también :) @SpehroPefhany Desearía que Freescale (NXP) fuera tan claro como Microchip en cuanto a lo que hicieron y no implementaron. ¡Los micros Freescale son tan baratos! Sin embargo, he podido descubrir que el MKL03Z hace una multiplicación de 32 bits de un solo ciclo.
@SpehroPefhany. Gracias por la anécdota! Tal vez por eso, por ejemplo, SAME7 tiene características de tan alto nivel, con respecto a otros cortex M7 de la competencia.

No conozco variantes del núcleo m0+, pero diferentes chips tendrán diferentes conexiones de bus de memoria y controladores FLASH. La memoria FLASH suele ser demasiado lenta para mantenerse al día con los microcontroladores modernos. La mayoría de los microcontroladores contarán con aceleradores FLASH para acelerar el acceso secuencial. Sin embargo, en el acceso aleatorio, como un salto o una bifurcación, podría haber múltiples ciclos de espera involucrados.

Esto podría significar que el controlador puede alcanzar una cifra más alta de Coremarks/MHz cuando el controlador se ejecuta a una velocidad de reloj más baja. Por supuesto, el procesador a una velocidad de reloj más alta completará más cálculos, simplemente diciendo que podría haber más estados de espera involucrados en relojes más altos. Algunos microcontroladores tienen aceleradores FLASH muy buenos, aunque casi no hay estados de espera.

Además, algunos microcontroladores pueden tener suficiente espacio y bloques SRAM para ejecutar el punto de referencia desde SRAM. Esto podría ser más rápido si no hay conflicto con el acceso a los datos. Es probable que ARM realice pruebas con esta técnica, ya que están interesados ​​en evaluar comparativamente su núcleo de CPU y no la implementación de FLASH de un proveedor en particular.

Igual de espectacular es la progresión en la tecnología de compilación. Esto podría ser a veces incluso más indeterminado. Los compiladores pueden optimizar bastante bien en el caso común, pero aún pueden producir código extraño que también cambia en modificaciones de código aparentemente no relacionadas (incluso cuando no está tocando una rutina en particular).

Además, en mi experiencia, algunos indicadores del compilador específicos de la arquitectura pueden hacer que ciertos programas sean más rápidos y otros más lentos. A veces, O2 o incluso Os crean un código más rápido en GCC que O3, que estaba destinado a optimizar la velocidad.

La base de datos de coremark siempre enumera la versión del compilador utilizada y todos los indicadores de compilación del programa. Los evaluadores de referencia no pueden realizar cambios en el código de referencia, por lo que no interfieren demasiado con las optimizaciones que puede realizar el compilador. Asegurarse de que se cumplan estas condiciones es la comparación más justa; pero incluso entonces podría haber diferencias aquí y allá.

Buena respuesta, creo que la "velocidad por MHz" es muy variable según la frecuencia del reloj real. Sin embargo, la MCU podría contrarrestar los estados de espera con caché de datos/instrucciones, por lo que la presencia/ausencia de caché debe tenerse en cuenta en la prueba. Creo que las pruebas serias implicarían pruebas tanto en reloj bajo como en reloj alto. (1 MHz contra 100 MHz o algo así).
Las pruebas serias implicarían la aplicación real, a la velocidad de reloj objetivo, no un punto de referencia sintético...
@SeanHoulihane Siempre. Las CPU están diseñadas para obtener una puntuación alta en los puntos de referencia, porque estos son los casos comunes. Por ejemplo, la corteza m0+ ni siquiera tiene un multiplicador de ciclo único obligatorio. Eso incluso podría significar que un AVR de 8 bits es más rápido. Si su aplicación realiza muchas de estas operaciones, asegúrese de que esté disponible. Pero traducir "su aplicación" a "Necesito al menos x Coremarks" es (casi) imposible, así que siempre pruebe.

La hoja de datos del SAM D20 también se refiere a 2.46. Como puede ver si sigue el enlace en el sitio de Arm al resultado de EEMBC, la configuración de la memoria, el compilador y las banderas del compilador marcan la diferencia en los resultados de un punto de referencia. Dado que el punto de referencia está escrito en C, es necesario usar un compilador en lugar de escribir en ensamblador. Esto está en la naturaleza de los puntos de referencia, incluyen un aspecto de qué tan bueno es el compilador objetivo del núcleo (y qué tan bien se asigna el código C específico al hardware).

Cortex-M0+ se puede configurar con un multiplicador rápido o pequeño. La hoja de datos de la parte aquí identifica que se implementa la multiplicación de un solo ciclo. La página 40 de la hoja de datos identifica que se implementó r0p1 del núcleo Arm.

Un factor importante entre las diferentes partes de MCU de bajo consumo podría ser la arquitectura de la memoria. Por ejemplo, el ancho de la memoria flash, cualquier instrucción intermedia recupera el almacenamiento en búfer, etc. Es posible, por ejemplo, implementar una memoria flash de instrucción de 16 bits de ancho (dado que el conjunto de instrucciones es Thumb), o tener una velocidad de reloj de CPU superior a la velocidad flash (y tal vez una amplia interfaz flash), todo con diferentes ventajas y desventajas.

Leí su pregunta tres veces antes de que hiciera clic en por qué tenía que usar un compilador en lugar de ensamblar, ¡Dios mío: D! Gracias por la respuesta fue útil.
El código real casi siempre se compila. Hay muy pocos desarrolladores que pueden escribir a mano un ensamblador más rápido que el que genera un compilador moderno para un problema complejo.