Una vez que hayamos resuelto aquí y aquí qué son los simuladores de computadora y qué son, es hora de hablar sobre cómo se utilizan. Y comenzaré con quizás el área de aplicación más interesante: hablaré sobre cómo los programadores profesionales usan simuladores en el desarrollo de software para escribir y depurar software para hardware que aún no existe.
Se tratará de utilizar modelos no de los dispositivos más sencillos, como, por ejemplo, SoC (System on Chip) o placas de circuitos impresos con muchos dispositivos integrados a bordo. En el desarrollo de estos dispositivos en sí, se pueden distinguir dos etapas. Primero se desarrolla el hardware. Este es un proceso lento; puede llevar un año o más.
Una vez que aparece la primera revisión del dispositivo físico y se realizan las comprobaciones básicas, el dispositivo se transfiere a los desarrolladores de software. A partir de este momento, comienza la segunda fase: el desarrollo de software para el dispositivo. Estos pueden ser firmware, BIOS, BSP / CSP (paquete de soporte de placa y CPU) para varios sistemas operativos, así como controladores.
Por cierto, en el desarrollo de chips, que a menudo se denominan "silicio", estas fases se denominan "pre-silicio" y "post-silicio" o simplemente "silicona".
En teoría, el desarrollo de software es posible antes de que aparezca un dispositivo físico. Sin embargo, en la práctica, muy pocos lo hacen. El desarrollo sin la posibilidad de lanzamientos intermedios y depuración, y esto es exactamente para lo que se requiere un dispositivo, es un negocio muy ingrato, he conocido a pocos masoquistas. Todo el mundo está esperando "hardware", pero, como escribí anteriormente, aparecerá sólo en un año.
Además, hay otro problema con el hardware. La primera revisión se publica en una edición limitada y se distribuye una pieza a la vez. En pocas palabras, no hay suficientes placas y chips para todos. Hay colas, conflictos, se trata de asaltos. Y si accidentalmente quemaste un dispositivo, lo cual es muy fácil, todo el desarrollo se detiene hasta que se encuentra otro dispositivo. A menudo no se encuentra, es necesario producir uno nuevo y luego esperar la entrega. Esto ralentiza enormemente el proceso.
¡Y luego los simuladores acuden en ayuda de los desarrolladores de software!
La creación de un modelo de dispositivo virtual comienza simultáneamente con el diseño del dispositivo físico. Pero dado que la creación y el lanzamiento de un modelo es mucho más fácil, los primeros lanzamientos de tales modelos aparecen convencionalmente no en un año, sino mucho antes. Con estos modelos, los desarrolladores de software pueden comenzar sus tareas de inmediato sin esperar el "hardware".
Sí, no habrá toda la funcionalidad, pero los programadores en las primeras etapas no la necesitan por completo. Hasta que se fabrique el dispositivo, los equipos de arquitectos de hardware, modeladores y desarrolladores de software deben tener planes claros y consistentes que reflejen qué funcionalidad específica se debe realizar en qué etapa. En cada iteración y con cada etapa, el modelo virtual crece con funcionalidad adicional, que, a su vez, es utilizada por los desarrolladores de software para escribir un controlador o crear firmware para esta funcionalidad.
En este enfoque, los desarrolladores de modelos y software utilizan especificaciones comunes. Al ejecutar software en un modelo, esencialmente están verificando el trabajo de los demás.
Una ventaja adicional es la validación del "hardware" a pesar de que el hardware en sí ni siquiera está allí todavía. Suena sorprendente a primera vista, pero estamos hablando de errores arquitectónicos en el diseño del dispositivo, algunos de los cuales pueden detectarse al ejecutar software en un modelo. Y esto es muy bueno, ya que es posible corregir estos errores en el hardware antes de su lanzamiento. De lo contrario, estos errores llevarían a la necesidad de volver a publicar las próximas revisiones, y esto es un placer bastante caro.
Tuvimos un caso en el que se implementaron 10 bloques para procesar el flujo de datos entrantes en un dispositivo complejo, y los registros de control y gestión nos permitieron trabajar con solo la mitad de ellos. Esto se implementó en la versión anterior del dispositivo, y los arquitectos simplemente se olvidaron de expandir esta parte. Cuando creamos el modelo y el otro equipo escribió y ejecutó el controlador, rápidamente resultó que toda la funcionalidad avanzada no estaba disponible. La arquitectura y las especificaciones se corrigieron a tiempo antes de que se creara el prototipo físico del dispositivo.
Las grandes empresas de dispositivos pueden respaldar todo un ecosistema creado en torno a sus productos. Este ecosistema incluye muchas otras empresas, incluidas las que producen software para este equipo. Por ejemplo, estos pueden ser fabricantes de BIOS, los llamados IBV (Independent BIOS Vendors), los más famosos de los cuales son AMI, Insyde, Phoenix. Estas empresas también reciben modelos del fabricante de hardware y comienzan el desarrollo antes de que aparezca el dispositivo físico. Por ejemplo, el simulador Simics se utiliza para plataformas Intel, que se puede leer con más detalle en el artículo Ecosystem Partners Shift Left with Intel para un tiempo de comercialización más rápido .
Obviamente, la creación de modelos requiere costos adicionales. La cantidad de costos, por supuesto, depende del tipo de modelos (funcionales, por ciclo, etc.), pero en general, se puede suponer que el costo de crear un modelo es aproximadamente igual al costo de escribir software para el dispositivo. No todas las empresas están dispuestas a pagar este precio por un lanzamiento anterior, razón por la cual este enfoque es común en las grandes corporaciones. Disponen de presupuestos suficientes para ello, y un lanzamiento más temprano de un producto en el mercado aumenta significativamente sus ingresos. Aunque recientemente, ha habido una tendencia a un uso más generalizado de simuladores para el desarrollo de software en empresas pequeñas.
A menudo, para reducir costos, el modelo no implementa todas las funcionalidades posibles, sino solo la mínima necesaria para ciertos escenarios de uso del dispositivo. Por ejemplo, si no se planea usar un dispositivo de red en VLAN, sino solo para actualizar el firmware y descargarlo a través de tftp, entonces no es necesario implementar la lógica con etiquetas VLAN, pero la funcionalidad para escenarios de arranque del dispositivo a través de la red y las actualizaciones de firmware deben implementarse completamente volumen.
¿Cuál es el resultado final?
Si asumimos que el tiempo de desarrollo del hardware y el software son aproximadamente iguales entre sí (vea la imagen de arriba), entonces el uso de modelos puede reducir significativamente, casi 2 veces, el tiempo de comercialización de un producto (el llamado TTM - Time To Market) , ya que el desarrollo de "hardware" y software se realiza en paralelo, y no de forma secuencial. Para esto, se usa a menudo el término Shift Left, que proviene del campo de las pruebas, donde significaba probar lo antes posible. El mismo término se aplica al desarrollo de software, que parece desplazarse hacia la izquierda en la línea de tiempo cuando se ejecuta en el simulador.
Cuando aparece la primera revisión del equipo, todo lo que queda es verificar la funcionalidad del software en hardware real. Idealmente, los errores y correcciones no deberían ser significativos y esta etapa no introduce grandes retrasos, ya que el código ya se ha escrito y depurado en el modelo.
Este enfoque no es “gratuito”, requiere un presupuesto adicional y un equipo de programadores, por lo que debe comprender claramente cuánto compensarán estos costos en un caso u otro.
Este no es el único caso de uso de simuladores. Hablaré sobre la investigación arquitectónica y la creación de entornos complejos en los siguientes artículos. No cambies.