Optimización del desarrollo de software previo al silicio

En la era de la tecnología de rápido movimiento actual, el enfoque más común para manejar las necesidades del mercado es un sistema en chip (SoC). Un SoC es básicamente un procesador rodeado de aceleradores de funciones y muchas E / S para los periféricos asociados que admite. Desde la revolución de los datos móviles en 2002, el uso de SoC se ha convertido en un requisito previo para facilitar las funciones clave que definen un teléfono inteligente. De la misma manera, los SoC se han convertido desde entonces en el dispositivo de referencia para crear productos de consumo "inteligentes" como televisores, automóviles y el mercado de Internet de las cosas (IoT) en constante expansión.

La creciente demanda de SoC ha creado un mercado altamente competitivo. Debido a esto, los SoC se están volviendo más complejos, los periféricos en los SoC evolucionan continuamente y el tiempo de comercialización se está reduciendo. Un componente crucial para igualar las complejidades del desarrollo de SoC es la disponibilidad de software. Hay poco margen para errores y el software debe estar listo lo antes posible. Para enfrentar este desafío, el desarrollo de software debe iniciarse antes de la disponibilidad de la parte SoC.

Desarrollo de software de SoC

Tradicionalmente, el desarrollo de software comenzaba después de que llegaba la primera muestra de silicio de la fabricación. Cuando llegaban las muestras de SoC, los equipos de software y validación comenzaban sus actividades de desarrollo y se iniciaba un gran esfuerzo de puesta a punto de SoC. Los equipos que trabajan en el SoC convergerían de todo el mundo para estar bajo un mismo techo durante un período de tiempo limitado para respaldar la aparición del SoC.

El desarrollo de software generalmente tomó meses después de que llegó la primera muestra antes de que estuviera lista para la producción. Mientras tanto, se completaría la validación del silicio, lo que daría una cantidad limitada de confianza para iniciar la producción en masa de los productos asociados.

Sin embargo, debido a la creciente complejidad en el diseño de SoC, lo que normalmente llevaría meses de desarrollo de software ahora podría extenderse a años antes de que el software esté listo para la producción. El creciente número de periféricos compatibles y la evolución de esos periféricos también crearon brechas en la experiencia en la materia. Se requeriría que los equipos de software llenen esos vacíos particulares proporcionando recursos a nuevos desarrolladores con experiencia en esos dominios (audio, video, USB, Ethernet, etc.).

Para poder entregar software listo para producción al principio del proyecto, el desarrollo de software no puede esperar hasta que esté disponible la primera muestra de silicio. Es necesario adoptar un enfoque de cambio a la izquierda en el que el desarrollo de software comience lo antes posible y, mejor aún, al mismo tiempo que comienza el diseño de hardware del SoC. El desarrollo de software previo al silicio también puede ayudar a identificar errores de implementación de SoC y reducir potencialmente el costo de la corrección de metal o las cintas de máscara completa. Se considera que varias metodologías cumplen con estos requisitos.

Enfoques de desarrollo previo al silicio

Para iniciar el desarrollo de software antes de la salida de cinta de SoC, los desarrolladores pueden usar algunos enfoques, como la creación de prototipos de software, el banco de pruebas RTL, las placas FPGA, los emuladores de hardware, etc. es desarrollar software para mostrar todo el SOC en lugar de módulos individuales. Si dividimos el problema en módulos más pequeños, lo primero que se necesita antes de que pueda comenzar el desarrollo del controlador es el conocimiento de cada procesador, acelerador o periférico en desarrollo.

Modelos System C

Se pueden construir modelos de comportamiento C para cada IP del SoC, y los controladores de software independientes se pueden probar en estos modelos de comportamiento. Pero este enfoque tiene un par de problemas. Primero, se requiere un gran esfuerzo de software, lo que significa que se necesita un gran equipo de software o un equipo de modelo dedicado para respaldar la implementación del modelo en sí. Por tanto, el desarrollo de modelos no sería rentable. En segundo lugar, la precisión de los modelos de comportamiento depende de la interpretación del desarrollador. Cualquier brecha de comunicación entre el propietario del diseño de IP y el desarrollador del modelo puede resultar en un comportamiento inexacto. Esto da como resultado una gran cantidad de esfuerzos en vano para solucionar los problemas asociados con la mala interpretación del diseño.

Banco de pruebas RTL

Para abordar este problema de inexactitud, otro enfoque que podría tomarse es utilizar un banco de pruebas Verilog. El banco de pruebas normalmente lo desarrolla y mantiene el equipo de diseño de SoC para su verificación. El banco de pruebas Verilog se basa en la especificación del lenguaje de transferencia de registros (RTL) del SoC, que representa el SoC completo, no solo algunos bloques de IP. En consecuencia, es precisa de ciclo a ciclo. A medida que se desarrolla el RTL, el banco de pruebas se mueve a la par con él. Esto asegura que sea la representación más actualizada y precisa del SoC mientras está en desarrollo. Para fines de desarrollo de software, el banco de pruebas Verilog también se puede utilizar para desarrollar controladores de software.

El software desarrollado con este método es preciso y puede ayudar a reducir el tiempo de activación del software cuando llegan las muestras de SoC después del proceso de fabricación. Pero hay un problema con este enfoque. Debido a que el banco de pruebas Verilog tiene ciclos precisos, es muy lento. Es posible desarrollar software en un entorno de este tipo, pero será extremadamente lento de desarrollar y depurar. Puede llevar meses desarrollar un controlador con esta metodología. El banco de pruebas Verilog se puede utilizar comenzando mucho antes, lo que esencialmente aumenta la cantidad de tiempo necesario en el pre-silicio para tener en cuenta la velocidad lenta de la solución (pero depende de la disponibilidad del banco de pruebas). En un enfoque alternativo, otro equipo de software puede usar esta metodología (solo trabajando en el desarrollo previo al silicio), lo que esencialmente aumenta la cantidad de recursos necesarios, por lo que no elimina este problema similar al problema con el método del modelo de comportamiento C.

En la práctica, no podemos aceptar ciclos de desarrollo largos o inexactos, ni podemos aceptar los costos adicionales necesarios para duplicar o aumentar la cantidad de recursos para mantener un cronograma de ciclo de diseño normal. En consecuencia, tenemos que considerar otro enfoque para el desarrollo de software previo al silicio. Este enfoque implicaría la emulación de cada bloque de IP de SoC en una matriz de puerta programable en campo (FPGA).

Prototipos FPGA

Los FPGA modernos son bastante rápidos y, dado que los FPGA se construyen a partir de RTL, son precisos de ciclo a ciclo. Con el aumento de la complejidad del diseño, los bloques de IP tienen muchas más puertas que hace años. Hace años, las FPGA estaban limitadas por la cantidad de puertas ASIC, lo que significaba que no era posible encajar bloques lógicos más grandes en una sola FPGA. Ahora es posible construir un FPGA para cada bloque y desarrollar un controlador en ellos que sea rápido y preciso.

Esta metodología es más rápida y no requiere que los equipos de software aprovechen su tiempo temprano. Debido a que funciona con cada bloque de IP por separado en lugar de todo el diseño de SoC integrado, este enfoque limita que el software realice un desarrollo completo a nivel de SoC. Omite los detalles de integración de cómo funcionan juntos varios bloques de IP. Por lo tanto, aunque este método reducirá el esfuerzo de activación, aún existen lagunas, ya que omite los detalles de integración de SoC pertinentes. Este método podría ser un enfoque aceptable para los SoC derivados, que tienen un número limitado de cambios, pero no tienen la cobertura completa deseada requerida para el desarrollo de software de SoC.

haz clic para ampliar la imagen

Figura. Sinopsis de soluciones de desarrollo de software pre-silicio. (Fuente:Nitin Garg)

Emuladores de SoC

Para abordar el problema de la precisión, la velocidad y la cobertura, se podría adoptar un enfoque más sólido, que consiste en utilizar emuladores de SoC. Hay muchos emuladores de SoC disponibles comercialmente, que pueden emular SoC muy grandes y complejos. Los emuladores de SoC se basan en RTL, por lo que son precisos y 100 veces más rápidos que el banco de pruebas Verilog, lo que lo hace mucho mejor para el desarrollo de software. Dado que son bastante rápidos, la migración completa del sistema operativo y el desarrollo de controladores se pueden realizar en un período de tiempo razonable. Los emuladores de SoC pueden escalar todo el SoC, por lo que el desarrollo de software se adapta mejor al SoC de producción final.

El uso de emuladores de SoC para el desarrollo y diseño de software previo al silicio reduce el tiempo y el esfuerzo de activación del software, ya que puede eliminar o reducir las brechas generales de desarrollo. El software también se puede depurar utilizando herramientas JTAG estándar en un emulador de SoC. Los emuladores se pueden usar para múltiples tareas como desarrollo y verificación de ROM, desarrollo de firmware y sistema operativo, y verificación de nivel de IP o SoC. Otra característica interesante de los emuladores de SoC es que pueden conectar el SoC a componentes reales como los que aparecen en una placa de desarrollo. Por ejemplo, es posible conectar un dispositivo NAND real o virtual al SoC en un emulador y desarrollar ROM, controladores de SO y similares.

Los emuladores de SoC ofrecen muchas más posibilidades que otros enfoques de desarrollo de software. Los emuladores pueden conectar el SoC simultáneamente a UART, I2C, varias pantallas, dispositivos de almacenamiento, dispositivos PCIe, dispositivos de conectividad como Ethernet y Wi-Fi y dispositivos de captura como cámaras y sensores. En otras palabras, los emuladores de SoC pueden representar una placa de desarrollo real, por lo que uno puede abrir un marco completo como Android y ejecutar un caso de uso completo antes de grabar el SoC. Por ejemplo, arrancar Android y decodificar algunos fotogramas de video en el emulador SOC puede llevar algunas horas, pero podría ser muy útil para analizar el rendimiento del SOC.

Debido a la creciente disponibilidad de periféricos en un SoC, la emulación de SoC también es muy útil para la evaluación comparativa del rendimiento, que puede resaltar las debilidades en el diseño antes de la salida de cinta. Esta funcionalidad puede reducir los riesgos o las grabaciones posteriores asociadas con deficiencias de rendimiento no identificadas en el SoC. Los emuladores de SoC también hacen posible conectar el SoC a un modelo de software o FPGA de terceros si es necesario para IP de terceros.

La depuración de un problema después de la llegada de la muestra de SoC también es útil con un emulador, dado que ejecuta el mismo sistema operativo, controladores y marco que el hardware real. A menudo, existe la necesidad de replicar los problemas observados en el silicio a los emuladores, para que puedan investigarse a nivel de la señal. El uso del mismo software entre el emulador y el silicio proporciona una reproducción más rápida y precisa de los problemas, dando acceso completo a los detalles dentro del chip.

Al comparar los diferentes enfoques de desarrollo de software de SoC, el uso de emuladores de SoC es una mejor opción desde una perspectiva de desarrollo previo al silicio y posterior a la depuración del silicio. El costo para los equipos de software de ejecutar emuladores de SoC puede parecer caro. Pero las contribuciones que brindan los emuladores de SoC al hacer que el software de producción esté disponible antes y ayudar a reducir los riesgos y costos, pueden resultar invaluables cuando se considera el impacto en el tiempo para los objetivos del mercado. Otros enfoques de desarrollo de software no tienen la misma cobertura, lo cual es arriesgado y puede requerir una mayor cantidad de recursos del equipo de software. Teniendo en cuenta todos los factores, el uso de enfoques de desarrollo de software distintos de los emuladores de SoC puede resultar mucho más costoso en comparación.

Figura 2. Velocidad de ejecución comparativa de cada solución. (Fuente:Nitin Garg)

Según la ley de Moore, el número de transistores se duplica cada dos años en un circuito integrado (IC) debido al aumento de la funcionalidad del IC. La mayoría de los SoC de 64 bits basados ​​en ARM tienen de 100 a 300 millones de puertas lógicas. De los enfoques actuales de desarrollo de software de SoC, los emuladores de SoC han demostrado escalar y respaldar las necesidades de los equipos de desarrollo de software que enfrentan los desafíos asociados con las crecientes complejidades de los SoC en el competitivo mercado actual.

Referencias

1. Trimberger, Stephen M. "Tres edades de FPGA". PDF de texto completo IEEE Xplore: 2015, ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7086413.
2. MORENA, JEAN-MARIE. "Por qué los diseños de SoC modernos adoptan la emulación". Diseño informático integrado , 5 de septiembre de 2018, embedded-computing.com/embedded-computing-design/why-modern-soc-designs-embrace-emulation.
3. "Emulación Soc". Emulación Soc , 2019, www.aldec.com/en/solutions/hardware_emulation_solutions/co-emulation–soc-emulation.
4. "Incorporación de más componentes en circuitos integrados". http://www.cs.utexas.edu/ , 2006, cs.utexas.edu/~fussell/courses/cs352h/papers/moore.pdf.