Regresión sin fin: el hardware se vuelve virtual en la nube

La nube consolida su papel en el diseño de hardware integrado

En el verano de 2018, los profesores John Hennessy y David Patterson declararon un futuro glorioso para el hardware personalizado. La pareja había obtenido el premio Turing de 2017 de la Asociación de Maquinaria de Computación por su papel en el desarrollo del estilo arquitectónico de computadora con conjunto de instrucciones reducidas (RISC) en la década de 1980.

Hacia el final de su discurso de aceptación, Patterson señaló la disponibilidad de hardware en la nube como una de las razones por las que el desarrollo de chips personalizados y las placas en las que se soldarían es cada vez más accesible. Los servidores en la nube se pueden usar para simular diseños bajo demanda y, si tiene suficiente dinero para gastar, puede simular muchos de ellos en paralelo para ejecutar diferentes pruebas. Si la simulación no se ejecuta lo suficientemente rápido, puede mover parte o todo el diseño a arreglos de puertas programables en campo (FPGA). Estos dispositivos lógicos programables no manejarán las mismas velocidades de reloj que un chip personalizado, pero es posible que solo sean cinco o diez veces más lentos, especialmente si el diseño que tiene en mente es algún tipo de sensor para Internet de las cosas (IoT), donde el costo y la energía son factores más importantes que el desempeño vertiginoso.

“La gran noticia que ha sucedido en los últimos años es que hay casos de FPGA en las nubes”, dijo Patterson. “No es necesario comprar hardware para hacer FPGA: simplemente puede ir a la nube y usarlo. Alguien más lo configura todo y lo mantiene «.

Un segundo aspecto de este movimiento está siendo impulsado por proyectos como OpenROAD organizado por la agencia de defensa estadounidense DARPA. Esto tiene como objetivo construir una cartera de herramientas de diseño de hardware de código abierto que permita a las empresas más pequeñas crear chips para sus propias placas en lugar de depender del silicio estándar. En principio, eso facilitaría la competencia con proveedores más grandes que tradicionalmente han podido implementar la personalización para mejorar los costos por unidad.

Durante más de una década, los grandes proveedores de silicio han utilizado la simulación para hacer frente a uno de los principales dolores de cabeza en la creación de chips personalizados. Hacer que el hardware se inicie y funcione correctamente es una cosa. Hacer que el software se ejecute a menudo termina siendo una parte más costosa del proyecto general. Como el software de depuración para un chip que aún no existe es complicado, recurrieron a la simulación para manejarlo. Incluso si el hardware no está completamente definido, a menudo es posible utilizar abstracciones para ejecutar las primeras versiones del software, que luego se refina gradualmente a medida que los detalles se vuelven más claros. La antigua forma de manejo era usar una combinación de hardware y FPGA que se aproximaba al diseño final y hacer que se ejecutara en un banco cercano. Eso está cambiando a un lugar donde no solo los diseñadores de hardware ejecutan simulaciones, es cada vez más el equipo de software.

“Cuando empezamos hace 12 o 13 años, todo el mundo estaba haciendo simulación de hardware para que el SoC funcionara”, dice Simon Davidmann, presidente de Imperas, una empresa que crea modelos de software de núcleos de procesador. “Fundamos Imperas para llevar estas tecnologías EDA al mundo de los desarrolladores de software. Aprendimos con Codesign [la empresa anterior de Davidmann] que el desarrollo de software se volvería más como el espacio del hardware «.

Una segunda tendencia es la atracción de la nube. Los diseños pueden ejecutarse en modelos que intercambian precisión por velocidad en un procesador de servidor en la nube o un modelo cargado en un FPGA o una combinación de ambos. Como Imperas y otros pueden ajustar sus modelos para el rendimiento haciendo coincidir las instrucciones emuladas con las ejecutadas por el procesador físico, una combinación típica es tener un acelerador de hardware personalizado y periféricos emulados en la FPGA y los microprocesadores en modelos de software rápidos.

Davidmann dice que la tendencia hacia el uso de enfoques de desarrollo más ágiles en el espacio integrado está impulsando un mayor uso de la simulación. Incluso el diseño de hardware, que no parece adecuado para una práctica de desarrollo que se basa en cambios progresivos en los requisitos e implementaciones, los ha utilizado. Una de las principales razones de esto es el uso extensivo de pruebas automatizadas. Siempre que se registra el código, ya sea la descripción del hardware o las líneas de software, el entorno de desarrollo realiza un montón de pruebas rápidas y se programan más para la noche. Si el nuevo código desencadena nuevos errores, se devuelve. Si no es así, el desarrollador puede continuar.

Esta integración y prueba continua se basa en que los servidores estén disponibles y listos para ejecutar las emulaciones y simulaciones cuando sea necesario. Eso, a su vez, apunta a la nube, ya que es fácil poner en marcha procesadores para una batería de pruebas bajo demanda. Incluso si el hardware de destino finalmente ha regresado de la fábrica, la simulación aún se usa. Aunque una forma de realizar pruebas a granel en hardware terminado es ejecutar granjas de dispositivos, básicamente estantes apilados con las placas y sistemas de destino, presentan problemas de mantenimiento. “Siempre se están rompiendo y, a menudo, tienen la versión incorrecta del firmware”, dice Davidmann. «Pasar a la integración continua no funciona tan bien con los prototipos de hardware».

Puede enviar rápidamente nuevas versiones a simulaciones en la nube, apagarlas y volver a encenderlas virtualmente. Y, si los fondos lo permiten, ejecute muchos de ellos en paralelo, lo que puede ser vital si un equipo tiene que cumplir con una fecha límite de envío con una forma de firmware lista para el envío.

Ahora, el uso de la simulación avanza aún más en el ciclo de vida, como lo demuestra el lanzamiento de Arm de su iniciativa de hardware virtual la semana pasada. La tecnología central debajo de esto es la misma que se usa para admitir diseños de chips convencionales, incluidos modelos de procesadores rápidos similares a los proporcionados por Imperas y otros.

En su forma actual, Arm Virtual Hardware está limitado en términos de los procesadores que admite. La implementación lista para usar que se encuentra en un programa beta gratuito cubre solo una combinación de procesador: el Cortex-M55 recientemente lanzado y su acelerador de aprendizaje automático complementario. La presencia del acelerador proporciona gran parte de la motivación para el programa de hardware virtual.

Stefano Cadario, director de desarrollo de productos de software, dijo en la cumbre de desarrolladores de Arm la semana pasada, una de las fuerzas impulsoras detrás del programa es el «fuerte aumento en la complejidad del software con varios factores: gestión de la seguridad, actualizaciones inalámbricas y máquinas aprendiendo».

Donde gran parte de la interacción que tiene el dispositivo integrado es con servidores en la nube que entregan actualizaciones de software y autentican transacciones, tiene sentido poder ejecutarlo y depurarlo en la nube. Pero el aprendizaje automático presenta una situación en la que las actualizaciones serán mucho más frecuentes que en la actualidad. Por lo general, los modelos se entrenarán fuera del dispositivo en servidores en la nube, ya que el hardware de destino no tiene el rendimiento o los datos sin procesar para hacer el trabajo por sí mismo. Potencialmente, los dispositivos podrían obtener modelos actualizados todas las noches, aunque lo más probable es que la frecuencia sea mucho más baja que eso.

Los equipos de desarrollo deben asegurarse de que un nuevo modelo no altere a otro software cuando se cargue, lo que indica que las pruebas de regresión se utilizan ampliamente en hardware simulado en la nube. Esa prueba automatizada potencialmente hace posible que los modelos de aprendizaje automático sean actualizados por científicos de datos especializados sin la participación directa de los escritores de software, a menos que haya un cambio lo suficientemente grande como para justificarlo. El resultado es una situación en la que Arm espera que los clientes mantengan rutinariamente simulaciones en la nube durante años, durante todo el ciclo de vida del hardware de producción.

Al igual que con los modelos de procesadores virtuales existentes, la implementación de Arm hace posible medir el rendimiento antes de que un chip regrese de la fábrica. Según Cadario, Cambridge Consultants utilizó una versión de acceso temprano para probar el software para un dispositivo médico y el equipo de Tensorflow de Google optimizó la biblioteca de aprendizaje automático para el acelerador antes en el ciclo de desarrollo de lo que lo haría normalmente.

Arm aún no ha dicho qué otros procesadores, en su caso, se agregarían al programa. Sin embargo, parece probable que no salga de la propia cartera de la empresa. “En lo que somos diferentes es en que apoyamos plataformas heterogéneas”, dice Davidmann. «Tenemos algunos de los desarrollos de software más importantes que utilizan nuestro material porque puede admitir implementaciones heterogéneas».

Seguirá habiendo un lugar para el hardware prototipo, sobre todo porque las pruebas de campo de las ideas todavía tendrán que realizarse antes de que los proveedores se comprometan con el hardware. Pero si hay un impulso hacia el uso de más hardware personalizado, será la simulación en la nube lo que ayude a impulsarlo.