¿Por qué los dispositivos relativamente más simples, como los microcontroladores, son mucho más lentos que las CPU?

Dada la misma cantidad de etapas de tubería y el mismo nodo de fabricación (por ejemplo, 65 nm) y el mismo voltaje, los dispositivos simples deberían funcionar más rápido que los más complicados. Además, la fusión de varias etapas de canalización en una no debería ralentizarse en un factor mayor que el número de etapas.

Ahora tome una CPU de cinco años, ejecutando 14 etapas de canalización a 2,8 GHz. Supongamos que uno fusiona las etapas; eso reduciría la velocidad por debajo de 200 MHz. Ahora aumente el voltaje y reduzca el número de bits por palabra; eso realmente aceleraría las cosas.

Es por eso que no entiendo por qué muchos microcontroladores fabricados actualmente, como AVL, funcionan a una velocidad abismal (como 20 MHz a 5 V), aunque las CPU mucho más complicadas fabricadas hace años eran capaces de funcionar 150 veces más rápido o 10 veces más rápido. si reúne todas las etapas de la tubería en una, a 1,2 V-ish. De acuerdo con los cálculos más básicos, los microcontroladores, incluso si se fabrican con tecnología casi obsoleta, deberían funcionar al menos 10 veces más rápido con una cuarta parte del voltaje con el que se les suministra.

Por lo tanto, la pregunta: ¿Cuáles son las razones de las velocidades de reloj lentas del microcontrolador?

Una buena parte de los microcontroladores se fabrican con tecnología casi obsoleta porque se paga la fábrica.
Poder. Tenga en cuenta el consumo de energía de ambas CPU y estarán bastante cerca del mismo rendimiento/vatio, o el micro ganará.
La idea de que más simple == más rápido es simplemente incorrecta. Gran parte de la complejidad de una CPU cisc moderna se concentra en funciones para hacerla más rápida, como cachés de varios niveles, canalizaciones y predicción de ramificaciones.
esa vieja CPU no funciona con una batería pequeña durante meses/años. usó tecnología de punta (léase: costosa) para su época. no tuvo que esperar en flash lento/barato para cada instrucción. rara vez es necesario que un mcu se ejecute rápido, pueden tomar un nuevo verilog por el bien de los desarrolladores e implementarlo en cualquier fundición. Me gusta más el comentario de bicicleta vs coche de fórmula 1, creo que eso lo resume.
Una forma en que Intel está mejorando el rendimiento de mips/vatios es simplemente ejecutando un diseño antiguo mucho más lento.
"reducir el número de bits por palabra" hace una diferencia sorprendentemente pequeña fuera de un multiplicador. Que es una característica opcional en los microcontroladores más pequeños.
.. y puede obtener un microcontrolador de 200MHz si lo desea: marketwired.com/press-release/… - útilmente le dicen que está hecho en 90nm.
20 MHz no es lento en absoluto. Simplemente nos miman las velocidades de GHz para PC, donde la mayoría de los recursos se utilizan para renderizar gráficos sofisticados. Puedes volar a la Luna con un procesador Kilohertz...
El objetivo de una canalización es que ejecutas las instrucciones tan rápido como pasan. Cuando Canadá pone un barril de petróleo en un oleoducto, no necesitan esperar hasta que una refinería de Texas lo saque para poner más.
"¿Los microcontroladores son mucho más lentos que las CPU?" - Un microcontrolador es una CPU :) - solo digo
Lo sorprendente es que usar un nodo más grande con más área sigue siendo más económico que un nodo más pequeño con menos área.
@FourierFlux Supongo que tiene que ver con los costos irrecuperables de las instalaciones y el rendimiento.
Sí, pero en algún momento los nodos más nuevos deberían ser más baratos, no más caros. Es como comprar un reproductor de VHS hoy.

Respuestas (6)

Hay otros factores que contribuyen a la velocidad.

  • Memoria: el rendimiento real a menudo está limitado por la latencia de la memoria. Las CPU Intel tienen grandes cachés para compensar esto. Los microcontroladores generalmente no lo hacen. La memoria flash es mucho más lenta que la DRAM.

  • Consumo de energía: esto suele ser un gran problema en las aplicaciones integradas. Las CPU Intel reales de 200 MHz consumían más de 10 vatios (a menudo mucho más) y necesitaban un gran disipador de calor y un ventilador. Eso requiere espacio y dinero, y ni siquiera cuenta la lógica externa y la memoria que lo acompañan. Un AVR de 20 MHz consume alrededor de 0,2 vatios, lo que incluye todo lo que necesita. Esto también está relacionado con el proceso: los transistores más rápidos tienden a tener más fugas.

  • Condiciones de funcionamiento: como señala Dmitry en los comentarios, muchos microcontroladores pueden funcionar en un amplio rango de voltaje y temperatura. Ese ATMega que mencioné anteriormente funciona desde -40C a 85C, y puede almacenarse a cualquier temperatura desde -65C a 150C. (Otros MCU funcionan hasta 125C o incluso 155C). El voltaje VCC puede oscilar entre 2,7 V y 5,5 V (5 V +/- 10 % para un rendimiento máximo). Esta hoja de datos del Core i7 es difícil de leer ya que recortan el VCC permitido durante la fabricación, pero las tolerancias de voltaje y temperatura son ciertamente más estrechas: ~3 % de tolerancia de voltaje y temperatura de unión máxima de 105 °C. (5C mínimo, pero cuando estás tirando >100 amperios, las temperaturas mínimas no son realmente un problema).

  • Recuento de puertas: más simple no siempre es más rápido. Si lo fuera, ¡Intel no necesitaría arquitectos de CPU! No se trata solo de canalización; también necesita cosas como una FPU de alto rendimiento. Eso eleva el precio. Muchas MCU de gama baja tienen CPU de solo números enteros por ese motivo.

  • Presupuesto del área del troquel: los microcontroladores tienen que incluir una gran cantidad de funciones en un solo troquel, que a menudo incluye toda la memoria utilizada para la aplicación. (SRAM y flash NOR confiable son bastante grandes). Las CPU de PC se comunican con la memoria y los periféricos fuera del chip.

  • Proceso: Esos AVR de 5V se fabrican con un antiguo proceso de bajo costo. Recuerde, fueron diseñados desde cero para ser baratos. Intel vende productos de consumo a altos márgenes utilizando la mejor tecnología que el dinero puede comprar. Intel también vende CMOS puro. Los procesos de MCU necesitan producir memoria flash en chip, lo cual es más difícil.

Muchos de los factores anteriores están relacionados.

Puede comprar microcontroladores de 200 MHz hoy ( aquí hay un ejemplo ). Eso sí, cuestan diez veces más que esos ATMegas de 20 MHz ...

La versión corta es que la velocidad es más complicada que la simplicidad, y los productos baratos están optimizados para la economía, no para la velocidad.

No olvide la robustez: una CPU típica fallará si el voltaje de suministro cambia en más del 5% aproximadamente, mientras que un ATMega funciona desde cualquier rango de 1.8-5.5V a 4MHz.
@DmitryGrigoryev ¡Buen punto! He actualizado mi respuesta.

Una de las principales razones técnicas subyacentes de las velocidades lentas es que las MCU económicas/pequeñas solo usan memoria flash en el chip para el almacenamiento de programas (es decir, no se ejecutan desde la RAM).

Las MCU pequeñas generalmente no almacenan en caché la memoria del programa, por lo que siempre necesitan leer una instrucción de la memoria flash antes de ejecutarla, en cada ciclo. Esto proporciona un rendimiento determinista y #ciclos/operación, es simplemente más barato/más simple y evita problemas similares a los de una PC donde el código y los datos se mezclan creando un nuevo conjunto de amenazas de desbordamiento de búfer, etc.

La latencia de lectura de la memoria flash (del orden de 50-100 ns) es mucho más lenta que la lectura de SRAM o DRAM (del orden de 10 ns o menos), y esa latencia debe incurrir en cada ciclo, lo que limita la velocidad del reloj del parte.

También la potencia (y por lo tanto el calor) aumentan más que linealmente con la frecuencia.
No creo que la lectura desde flash esté cerca de los 100 ns, ¿verdad? IIRC es dos órdenes de magnitud más grande. Sin embargo, si su controlador flash contiene una caché DRAM pequeña y el código no es demasiado ramificado, la tasa de aciertos de la caché puede ser muy alta (más del 90 %) por lo que su latencia promedio puede ser mucho más baja.
Esta hoja de datos AT91SAM7S que tengo abierta dice para su flash interno "Tiempo de acceso rápido, acceso de ciclo único de 30 MHz en las peores condiciones" para su flash interno. Eso es 33ns. Y tiene un dword de búfer de captación previa. De hecho, Off-die Flash puede tener una latencia más alta.
@Jamil No recuerdo la fórmula exacta, pero creo que era el cuadrado de la frecuencia.

¿Por qué la gente anda en bicicleta o en moto pequeña, cuando tienes un coche de Fórmula 1? Seguramente debe ser mejor conducir, digamos, a 300 km/h y llegar a todas partes al instante.

En pocas palabras, no hay necesidad de ser más rápido que ellos. Quiero decir, seguro que hay microcontroladores un poco más rápidos que permiten algunas cosas, pero ¿qué vas a hacer, por ejemplo, con una máquina expendedora que está en uso continuo durante tal vez 1 hora al día? ¿Qué vas a hacer en un control remoto, por ejemplo, para un televisor?

Por otro lado, tienen otras capacidades importantes, como el bajo consumo de energía, ser MUCHO más simples de programar, etc. Básicamente, no son procesadores y hacen cosas diferentes.

Esa no es exactamente mi pregunta. Entiendo por qué uno puede querer un dispositivo lento de $ 1 en lugar de uno rápido de $ 100 cuando el lento sería suficiente. Lo que no entiendo es por qué el dispositivo de $ 1 funcionaría tan lento como lo hace, dado que la simplicidad generalmente implica velocidad.
@Michael ¿De dónde sacas la idea simple = rápido?
@Michael Una bicicleta es mucho más simple que un automóvil, pero aún es más lenta. En cualquier caso, Matt tiene razón. Algo simple no es automáticamente rápido. Es decir, algo rápido va a ser complicado, solo por consideraciones necesarias para frecuencias más altas.
@MattYoung: esa es la idea detrás de las arquitecturas RISC: las tareas simples se pueden manejar más rápido que las complicadas. Y, en ausencia de tubería de múltiples etapas, el controlador se vuelve mucho más simple.
Los procesadores CISC de alto rendimiento tienden a emitir muchas más instrucciones que los procesadores integrados simples. Están haciendo mucho más trabajo en paralelo, por lo que son más complejos y más rápidos.
@Michael: una forma de lograr velocidad es mantener el conjunto de instrucciones simple para que pueda canalizarse. ¡Sin embargo, eso no significa que todo el hardware simple pueda funcionar en relojes altos! La rapidez con la que puede cronometrar algo depende de cuántos retrasos de puerta haya en la etapa de tubería más larga, o algo así. En un diseño "simple", probablemente haya algunas etapas bastante lentas que limitan el reloj máximo porque no está muy canalizado.
@Michael $ 1 podría ser lujosamente caro para algunas aplicaciones, he leído que los microcontroladores en las tarjetas micro SD cuestan alrededor de 19 centavos
@Michael "esa es la idea detrás de las arquitecturas RISC: las tareas simples se pueden manejar más rápido que las complicadas" ¡No! Las arquitecturas RISC modernas son extremadamente complejas porque tienen que introducir más instrucciones (como SIMD) y admitir más funciones como superescalar, hiperprocesamiento, ejecución desordenada... Su complejidad puede superar fácilmente a las arquitecturas CISC. MIPS hoy en día tiene cientos o miles de instrucciones. "CISC v RISC es en gran parte un debate histórico"
excelente analogía de apertura, precisa Y divertida, volvería a leer.

Hay muchos controladores ARM que funcionan a cientos de MHz o más. ¿Quién necesita un PIC de 500 MHz y está dispuesto a pagar lo suficiente por parte para justificar máscaras de un millón de dólares para un proceso casi de última generación?

Según los informes, el popular ATmega328 está hecho con tecnología de 350 nm, que está bastante por detrás de las CPU Intel de última producción (14 nm para Skylake ).

Incluso los controladores económicos de 8 bits han ido aumentando lentamente en velocidad, y puede obtener controladores PIC de 32 y 64 MHz (por ejemplo, PIC18F14K22) que aún funcionan a 5 V (este último es una consideración en el costo total del sistema).

Una consideración es que estos controladores tienen una arquitectura que está optimizada para espacios de memoria pequeños y velocidades de reloj lentas. Una vez que comienzas a alcanzar altas velocidades de reloj, tienes que reajustar las cosas con preescaladores, etc.

Hubo un intento (finales de la década de 1990) de producir controladores similares a PIC muy rápidos, con la idea de que el firmware podría sustituir a los periféricos si el microcontrolador era lo suficientemente rápido. Por ejemplo, podría hacer un bit-bang en un UART. No creo que hayan tenido tanto éxito comercial: Scenix->Ubicom->Qualcomm (game over).

350nm? Eso lo explicaría. No sabía que alguien fabricaría cualquier cosa usando tecnología de hace 20 años.
Algunos de nosotros todavía estamos diseñando (no solo usando) CMOS de la serie 4000, que es algo así como 3000nm.
Los procesos más antiguos también son potencialmente útiles para las personas que se ocupan de entornos de radiación o sistemas de alta confiabilidad que exigen trazabilidad.
El juego no ha terminado: Parallax Propeller es una continuación de ese concepto.
@DaveTweed O, para un ejemplo de mayor éxito comercial, eche un vistazo a la línea Cypress PSoC.
@duskwuff: No te estoy siguiendo. AIUI, PSoC no se trata de reemplazar hardware con firmware, sino de tener hardware configurable para reemplazar bloques de funciones fijas.
@DaveTweed Es una arquitectura extraña, en algún punto intermedio entre el hardware y el software. Los componentes configurables del PSoC se pueden modificar en tiempo de ejecución y contienen elementos PLD y elementos de "ruta de datos" que son esencialmente microcontroladores muy pequeños para fines especiales.
Según tengo entendido, las partes de Scenix administraron una relación causa/efecto de software que fue mucho más rápida que cualquier otro controlador del que haya oído hablar (probando un pin de puerto y configurando condicionalmente otro en 20 ns en total). Durante mucho tiempo me he preguntado por qué Microchip nunca se molestó en producir algo comparable.
@SpheroPefhany: CD4k CMOS estará con nosotros en el futuro previsible; nada más puede cumplir su función en sistemas mixtos lineales/lógicos (donde se requiere que la lógica se ejecute en el voltaje de suministro lineal de 12/15V). (O eso, o se usará un proceso HVCMOS más moderno como el iCMOS de ADI para hacer un reemplazo).
@Michael: No es solo la era de la tecnología. El tamaño también importa. El tamaño de proceso más grande tiene tasas de defectos más bajas, lo que significa menos rechazos y, por lo tanto, mayor rendimiento, lo que conduce a un menor costo por chip. Si está dispuesto a pagar $ 100 por una CPU (como las computadoras de escritorio), entonces se justifica el costo más alto debido al menor rendimiento. Si solo está dispuesto a pagar 50 centavos, entonces no está justificado.
Para agregar a la idea de crear periféricos definidos por firmware... Algunos de los procesadores Motorolla/Freescale/Nxp HCS12 (como MC9S12XEP100 y otros) tienen un coprocesador XGATE para hacer periféricos de software. Algunas de las partes de Power PC (como MPC5674 y otras) tienen coprocesadores ETPU para implementar periféricos de software.
@user4574 si la memoria no me falla, el concepto se originó con Motorola y sus procesadores dirigidos al mercado masivo de ECU automotriz. Lo llamaron TPU. Los procesadores modernos, como el ARM utilizado en Beaglebone, tienen varias PRU de 33 bits.

Imagine que uno quiere producir automóviles. Un enfoque sería usar un montón de equipos en la fábrica de forma secuencial, construyendo un automóvil a la vez. Este enfoque se puede realizar con una cantidad modesta de equipo moderadamente complicado, por lo que se pueden utilizar muchos equipos para realizar más de un paso. Por otro lado, gran parte del equipo en la fábrica aún estaría inactivo la mayor parte del tiempo.

Otro enfoque es establecer una línea de ensamblaje, de modo que tan pronto como el equipo que manejó el primer paso de producción haya terminado esa operación en el primer automóvil, pueda proceder a iniciar la operación correspondiente en el próximo automóvil. Tratar de reutilizar una pieza de equipo en varias etapas del proceso de fabricación sería complicado, por lo que en la mayoría de los casos sería mejor usar más piezas de equipo, cada una optimizada para realizar una tarea muy específica (por ejemplo, si es necesario taladrar 50 orificios de 10 tamaños diferentes, entonces una configuración de equipo mínimo incluiría un taladro con 10 brocas y un mecanismo de cambio rápido, pero una línea de ensamblaje podría tener 50 taladros cada uno con una broca instalada permanentemente y sin necesidad de un cambio rápido) .

Para cosas como DSP o GPU, es posible lograr velocidades muy altas de manera relativamente económica porque la naturaleza del trabajo a realizar es muy consistente. Desafortunadamente, muchas CPU necesitan poder manejar variaciones arbitrarias de instrucciones de diferente complejidad. Hacer eso de manera eficiente es posible, pero requiere una lógica de programación muy compleja. En muchas CPU modernas, la lógica necesaria para "hacer el trabajo" no es demasiado complicada o costosa, pero la lógica necesaria para coordinar todo lo demás sí lo es.

Lo siento si me lo perdí, pero ¿qué relevancia tiene esto para las CPU frente a los microcontroladores 'más lentos'? Solo parece centrarse en CPU frente a procesadores especializados (normalmente incluso más rápidos).
@underscore_d: El primer párrafo cubre los microcontroladores más simples: son como la pequeña tienda que construye un automóvil a la vez. El segundo párrafo señala que hay algunos controladores económicos que pueden realizar muchas operaciones muy rápidamente, pero están limitados en el tipo de operaciones que pueden realizar. Lo que es difícil es poder realizar una combinación arbitraria de operaciones mientras las superpone en un grado significativo (pero muy variable). Si uno tiene un subsistema que en cada ciclo puede aceptar dos números y genera el producto de dos números que se enviaron hace cuatro ciclos, y...
... otro que en cada ciclo aceptará dos números y generará la suma de los que se enviaron hace dos ciclos, tratando de averiguar cuándo se deben enviar los valores, cuándo estarán disponibles los resultados, cuándo se deben cargar y guardar las cosas a los registros, etc. puede volverse muy complicado, especialmente si uno quiere evitar rellenar todas las tuberías para que coincidan con la más larga.
Gracias; eso lo aclara. Sí, tiene sentido que las CPU rápidas de propósito general incurran en la mayoría de sus costos, tanto financieros como de energía, en "andamiaje": canalización, caché, programación, control de RAM, etc. Cosas que no solo son prohibitivamente costosas sino que a menudo no son necesarias. para micros. Del mismo modo, nunca deja de sorprenderme lo que se puede hacer con una frecuencia de reloj relativamente pequeña en un procesador diseñado específicamente para una aplicación. ¡Cosas fascinantes en ambos lados!
@underscore_d: La arquitectura MIPS se diseñó con la premisa de que los compiladores serían responsables de algunos de los problemas de programación, lo que permitiría simplificar el hardware. Creo que el concepto nunca se hizo realidad, porque los procesadores más nuevos a menudo requieren más etapas de canalización que los más antiguos, pero el código escrito para un procesador con canalizaciones más cortas no funcionará en un procesador con otras más largas en ausencia de interbloqueos de hardware.
Como usuario del SX48 de Ubicom-neé-Scenix, nada menos que a 100 MHz, el silicio era excelente, pero las herramientas eran una mierda. Para programar estos chips de manera efectiva, tenía que intercalar el código para múltiples periféricos: el núcleo era completamente determinista en cuanto a tiempo. Hice que lograra algunas cosas ingeniosas, pero no tuve tiempo para trabajar en el desarrollo de herramientas, así que solo hice lo mínimo necesario para terminar el producto y seguir adelante. Tales arquitecturas requieren programación en una fusión de C y un lenguaje de descripción lógica para describir las restricciones de tiempo. Eso es posible, pero el mercado no pudo soportar los costos de desarrollo, obviamente.
Realicé la adquisición de datos en él y los datos filtrados por FIR de un ADC SPI de 120 ks/s y 16 bits mientras me comunicaba con un host a través de una conexión serial asíncrona de 1 MBit/s. El procesamiento lento se realizó utilizando una VM que ejecutaba un código de bytes de "secuencias de comandos" simple. Una vez que la adquisición estaba en marcha, quedaban pocos ciclos de reloj, apenas, pero funcionó y fue sólido como una roca. El código fue enhebrado por una herramienta personalizada que escribí que tomó los subprogramas de ensamblaje que tenían que ejecutarse en paralelo, junto con las restricciones de tiempo en ciertas transiciones de E/S, y produjo el programa final intercalado con precisión de ciclo que no se pudo depurar. .
La depuración fue imposible porque no me quedaba flash para el "blob" de depuración que la herramienta tenía que cargar en el chip para ejecutar la función de depuración. El código estaba completamente desenrollado y apenas lo hice encajar: había tal vez dos docenas de bloques básicos (código de línea recta) en todo el asunto. Entonces, si bien el silicio ciertamente podría hacerlo y con una herramienta mejor, probablemente podría haber eliminado algún código duplicado para guardar el flash, existía el espectro de quedarse sin ciclos. Y cada vez que hacía que uno de los subprocesos fuera "más elegante", tenía que actualizar la herramienta con una mayor comprensión de lo que significaba el ensamblaje.
Entonces, lo que se suponía que había sido un proyecto de microcontrolador bastante poco controvertido se convirtió en un proyecto de investigación de generación de código y eso me hizo usar esa parte en dos productos y desecharla con prejuicios tan pronto como volví a implementar el firmware para otro micro. Esta cosa tenía espacio de datos bancarios y espacio de código bancario, y en realidad no lo suficiente de ninguno de los dos. Por lo tanto, un concepto PIC "simple" no se adapta a relojes más rápidos a menos que tenga herramientas de desarrollo costosas y complejas y pueda convencer a los clientes de que los respaldará. Entonces, OP debe tener cuidado de por qué lo desean: estado allí y no fue genial.
@Kubahasn'tforgottenMonica: Encuentro curioso que la línea de chips de estilo PIC de 100 MHz no se haya extendido para usar un espacio de código más amplio para eliminar la necesidad de código y banco de datos, ya que, por lo que entiendo, las partes de Scenix podrían sondear un I /O pin y cambie una salida en función de su valor en menos de 30 ns, que es algo que los chips ARM aún más rápidos no pueden hacer. Por cierto, en un proyecto que hice con el PIC 16C505, usé una forma de doble subproceso que en realidad se benefició del espacio de datos almacenados, ya que tenía dos subprocesos que usaban el mismo código pero se ejecutaban en diferentes bancos de datos. Aún así, si uno fuera a...
...simplemente expanda el código con la parte de Scenix a 14 bits, y hágalo de modo que cuando no use el FSR, los dos bits usados ​​para seleccionar el banco de RAM o el banco de destino GOTO simplemente se carguen desde esos dos bits adicionales del instrucción, que debería haber hecho muchas cosas mucho más convenientes sin aumentar la longitud de las tuberías lógicas.
Una vez que expandía el núcleo SX para hacer todo eso, ya no podía ejecutarlo tan rápido en el proceso anterior. Y también: el tiempo de cambio de pin de 20 ns es inútil en la práctica, porque cuando haces eso no puedes hacer nada más, y me atrevo a decir que hay 0 aplicaciones que hacen que valga la pena operar silicio extraño en bucles estrechos que solo cambian pines. Podría hacerlo más barato con una GAL externa o incluso con una lógica de gominola. Incluso si SX no tuviera paginación extraña, sin herramientas, la velocidad era inutilizable. Parallax era un usuario y pronto se dieron cuenta de que necesitaba varios núcleos rápidos para que se pudiera utilizar. Y así la Proposición 1 :)
E incluso en la Proposición 1, si quería que un engranaje hiciera varias cosas simples en paralelo, tenía que enhebrar a mano el código ensamblador, por lo que, en la práctica, la mayoría de la gente ejecutaba solo un "periférico" por engranaje, y el desarrollo de esos periféricos virtuales era una tarea sencilla. dolor. En Prop 2, los cogs son más rápidos, por lo que las interrupciones se pueden usar para cambiar subprocesos, o puede transmitir varios subprocesos desde la memoria del concentrador e intercalarlos en una VM ejecutora, aún funcionando tan rápido por subproceso como se ejecutaron los cogs de Prop 1, todo mientras se codifica " normalmente”, sin intercalado manual. La Proposición 2 aún podría usar mejores herramientas, pero el tiempo lo curará.
@Kubahasn'tforgottenMonica: ¿Hay alguna razón por la que me esté perdiendo que agregar dos bits más de espacio de código obtenidos en paralelo con el resto y usarlos en lugar de bits bancarios aumentaría el tiempo de ruta crítica? Supongo que si la memoria se decodifica parcialmente usando bits bancarios, y si los datos extraídos del espacio del código llegan lo suficientemente tarde como para que el resto de la decodificación esté en la ruta crítica, usar bits bancarios en lugar de bits flash podría ser un poco más rápido, pero yo no esperaría que esos fueran el camino crítico. La situación principal en la que la velocidad de respuesta de E/S es útil...
... es cuando se comunica con interfaces sincrónicas que no se ajustan a la forma en que funcionan los periféricos SPI normales (por ejemplo, porque se usan tres cables (reloj, tx y rx) para manejar el protocolo de enlace y el encuadre sin requerir el uso de pines adicionales para esos propósitos). Aunque la otra razón por la que me parece interesante es que el tiempo de respuesta de E/S en un chip de este tipo es más rápido que en los procesadores de gama alta.

Tus deseos se hicieron realidad :) Parallax Propeller 2 funciona a 300 MHz, tiene 8 núcleos, 512 kB de RAM compartida, 2 kB de RAM de núcleo local + otros 2 kB compartidos por pares de núcleos, la mayoría de las instrucciones se ejecutan en 2 ciclos de reloj, por lo que 150 MIPS por núcleo o 1,2 GIPS pico por chip, 64 pines inteligentes muy flexibles: puede tener 64 ADC de 15 bits de 1 MSPS si puede usarlos, creados con un proceso moderno de TSMC (35 nm, pero no me citen al respecto; no pude encontrar las publicaciones del foro donde que se discutió).

Entonces, en cuanto a la pregunta de “por qué no lo hacen”: ¡pero lo hacen! Y es una parte increíble, si se me permite decirlo.

Esa cosa está estúpidamente sobrevalorada. Es mejor comprar un pi.
@FourierFlux ¿$10 en cantidad para obtener 64 canales de ADC/DAC y un microcontrolador muy rápido es demasiado caro? No si realmente necesita sus funciones. Y es difícil en tiempo real, así que si lo necesita, olvídese de pi a menos que quiera aprender a codificar en ensamblador para VideoCore. Y pi tampoco tiene ADC y DAC de uso general, solo E/S de audio. Ah, y la documentación completa para el pi solo está disponible bajo un acuerdo de confidencialidad y tiene miles de páginas. En ese caso, pi solo es más barato si tu tiempo es libre. Todo lo que hay que saber sobre P2 cabe en menos de 100 páginas (densas, cierto).
La placa de evaluación tiene más de 150, no pude encontrar una forma más económica de obtenerla en una placa prefabricada.
¿Por qué los dispositivos relativamente más simples, como los microcontroladores, son mucho más lentos que las CPU?
RespuestasAquíPolítica de privacidad1y, 0v