El diseño, la implementación y la programación de sistemas heterogéneos multinúcleo se están volviendo más comunes, a menudo impulsados ​​por las cargas de trabajo del software, pero las herramientas para ayudar a optimizar los procesadores, la interconexión y la memoria son inconexas.

En los últimos años, han surgido muchas herramientas que ayudan con la definición e implementación de un único procesador, optimizado para un determinado conjunto de software. Si bien empresas como Cadence y Synopsys han tenido herramientas internas para sus arquitecturas patentadas durante décadas, RISC-V ha creado un mercado nuevo y abierto para dichas herramientas. Con la amplitud de opciones disponibles y el ecosistema necesario para respaldarlas, la tasa de adopción ha sido rápida.

Pero tan pronto como un diseño incluye varios procesadores o entornos informáticos heterogéneos, las herramientas se vuelven mucho menos disponibles. Hay escasez de herramientas que puedan ayudar a particionar software u optimizar un procesador considerando el subsistema de memoria o la red de comunicaciones. También hay brechas en las herramientas que pueden analizar el flujo de datos dentro del sistema. Si bien hay un puñado de herramientas que pueden hacer algunas de esas tareas, no hay nada que pueda hacerlas todas, y no hay flujos que combinen varias herramientas para realizar la tarea.

Muchas preguntas surgen tan pronto como el multinúcleo entra en escena. “Hay un frenesí multinúcleo RISC-V”, dice Frank Schirrmeister, vicepresidente de marketing de IP de Arteris. “Típicamente los extiendes de manera similar. Tal vez tenga varios clústeres. Dentro del clúster, puede tener varias unidades de cómputo y tal vez optimice conjuntamente el cómputo y el transporte. Puede decidir tener un acelerador de aplicaciones asociado con el clúster o adjunto a cada núcleo. Cada procesador podría ser un procesador de instrucciones específico de la aplicación (ASIP) muy optimizado que utilice algo como CodAL de Codasip o LISATek/NML de Synopsys. Podría usar la síntesis de alto nivel para construir un acelerador de aplicaciones”.

Lo que falta
Algunas piezas fundamentales de un flujo simplemente no existen y otras no funcionan juntas con la perfección requerida. Pero se están logrando algunos avances.

"Las brechas en la metodología de diseño siempre pueden usar enfoques de diseño RTL tradicionales menos automatizados", dice Zdeněk Přikryl, CTO de Codasip. “A medida que las herramientas de automatización del diseño de procesadores se desarrollen más, podemos esperar que se cierren las brechas y surja una metodología completa de codiseño de hardware/software”.

Quedan enormes lagunas en el flujo. “No hay nada como una herramienta de paralelización automática, incluso para sistemas multinúcleo homogéneos, y mucho menos para un sistema multinúcleo heterogéneo”, dice Tim Kogel, ingeniero principal de creación de prototipos virtuales en Sinopsis. “La gente está luchando por encontrar el modelo de datos correcto. NVIDIA tiene una gran inversión en su franquicia CUDA, desarrollando todo tipo de modelos de programación para abordar eso. Hay mucho que todavía tiene que suceder. Lo que veo hoy es que tiene cadenas de herramientas separadas para los diferentes subsistemas. Por ejemplo, tiene la cadena de herramientas de compilación de aprendizaje automático para sus redes neuronales, y luego tiene la cadena de herramientas de compilación tradicional para la CPU, y luego es un poco de esfuerzo unirlas”.

Cuando se establecen restricciones, las soluciones se vuelven más probables. “La capacidad de RISC-V para integrar estrechamente aceleradores a un procesador es una gran ventaja porque reduce el rango de heterogeneidad necesario para que Linux lo admita”, dice Charlie Hauck, director ejecutivo de Bluespec. “Puede hacer esto sin restringir el rango de heterogeneidad implementado por los aceleradores. Esto minimiza el alcance de los cambios de herramientas necesarios para admitir procesadores específicos de dominio en un entorno de multiprocesamiento heterogéneo. Esto incluye el modelado C/SystemC a nivel de sistema de ciclo aproximado para una exploración arquitectónica rápida para refinar las especificaciones antes de pasar a la implementación y validación”.

Para ser impulsado por el software, debe comenzar desde allí y trabajar hasta el hardware. “Con la ingeniería de sistemas basada en modelos, comienzan con la funcionalidad general, que cruza múltiples dominios: software, hardware, físico”, dice Neil Hand, director de estrategia para tecnología de verificación de diseño en Software de Siemens Digital Industries. “A medida que comienzan a presionar hacia abajo, observan la división de hardware y software, lo que se incluye en cada procesador. Y, en general, quieren elegir el procesador que hará el trabajo de la manera más efectiva. Si pueden ejecutar el algoritmo en un solo procesador monolítico, probablemente lo harían. Si no cumple con los requisitos, quieren una forma de eliminarlo y decidir qué funcionalidad tiene su propio núcleo integrado o sus propios aceleradores”.

Pero tan pronto como interponga cualquier forma de red entre ellos, debe analizar la sobrecarga de comunicaciones. “Hay subconjuntos del flujo que funcionan”, dice Schirrmeister de Arteris. “Por ejemplo, en nuestro conjunto de herramientas, lanzamos un modelo que lo ayuda a analizar el propio NoC. Calcula cuántos interruptores necesita cuando tiene 10 iniciadores y 15 objetivos. Estas son mis prioridades. Haces ese análisis de arquitectura y luego lo averiguas en contexto. Luego lo exporta a algo como Platform Architect. Esas relaciones existen, pero el mayor problema es que están desconectadas. Incluso si el flujo técnico está ahí, la capacidad de una persona o incluso un equipo para interactuar de manera eficiente para realizar todas estas optimizaciones de análisis basadas en la retroalimentación de la arquitectura está muy distribuida”.

Y es posible que no siempre estén haciendo las preguntas correctas. “Cuando observa las ofertas de las empresas de red en chips, todavía ven el mundo como sistemas que quieren poder realizar cualquier tarea”, dice Russell Klein, director de programa del equipo Catapult HLS en Siemens. “Miran los datos que necesitas mover, qué latencias tenemos, qué ancho de banda se requiere. Pero no están considerando la posibilidad de tomar esta memoria y colocarla 'aquí en esta área de cómputo'. Entonces los datos nunca necesitan moverse o usar la interconexión. Si secuestramos grupos de datos donde se necesitan y los agrupamos con los elementos informáticos, las comunicaciones se pueden minimizar. ¿Qué pasa con el cálculo en memoria? Ese tipo de cosas deben tenerse en cuenta cuando se analizan las interconexiones. ¿Cuál de estos podemos sacar de la interconexión y ni siquiera tener que moverlo en primer lugar? No creo que tengamos las herramientas que sean capaces de entender ese problema y ofrecer soluciones”.

Se requiere mucho más. “Existe una clase de capacidades de exploración y particionamiento y codiseño, y puede abrirse camino a través de la fuerza bruta hoy”, dice Hand de Siemens. “Pero hay más que se necesita. Tenemos muchas capacidades para ayudar a responder la pregunta: '¿He alcanzado mis objetivos?' Pero uno de los desafíos con un flujo de arriba hacia abajo es que necesita poder realizar mediciones, hacer estimaciones, y para eso necesita modelos, necesita información de rendimiento, necesita el software para comprender la sobrecarga del sistema, el compensaciones del sistema. Ese es un problema realmente difícil de resolver. Si tiene un NoC, si tiene memoria compartida o memoria no compartida, estos son grandes impactos en el rendimiento general. Y no puedes abstraer eso en un contenedor de software, desafortunadamente”.

Preparación del software
Para poder encontrar la mejor asignación de software en una pieza de hardware disponible, o para definir la arquitectura de hardware más adecuada para una pieza de software, se requieren amplias capacidades de análisis.

“Cuando tienes un chip complejo con características de hardware sofisticadas, ¿cómo hace uso de eso el desarrollador de software? Ahí es donde radica el mayor desafío”, dice Kogel de Synopsys. “Mucha gente está desarrollando hardware para IA, pero el campo de batalla es el compilador ML. Puede diseñar un hermoso hardware de acelerador, pero si el compilador no puede hacer un uso eficiente de él, lo más probable es que no se use. Ese es un gran problema a resolver”.

Hoy, esos entornos están distribuidos. “Tener un entorno de software que le permita hacer ese análisis es valioso”, dice George Wall, director del grupo de marketing de productos para el procesador IP Tensilica Xtensa en Cadencia. “Pero eso es probablemente más de un entorno de software. Probablemente haya algunos entornos muy centrados en el procesador que podría considerar, como un ISS con un modelo SystemC a su alrededor utilizando las herramientas de desarrollo de su proveedor de procesadores. Y luego probablemente haya una pieza de mayor nivel con la plataforma virtual”.

Incluso RISC-V está luchando por mantener el ecosistema de software cuando se utiliza la libertad total. “Para mantener bajo control la complejidad del software, debe estandarizar las variantes del conjunto de instrucciones”, dice Kogel. “Para el número entero y el punto flotante, y para cada conjunto de instrucciones, tienen un conjunto predefinido, que debe usar para beneficiarse de la infraestructura general. Entonces, en lugar de abrirlo completamente, se definen perfiles estándar. Pero si elige no usarlos, entonces está solo”.

Los perfiles restringen el hardware para ayudar a simplificar el ecosistema de software. “El ecosistema de software RISC-V se está preparando”, dice Přikryl de Codasip. “Tenemos diferentes grupos dedicados a perfiles y plataformas que resumen muy bien lo que se espera como referencia y cómo se pueden usar las características específicas del dominio. Con esto en su lugar, el ecosistema de software puede crecer muy bien, porque está claro cómo se deben manejar las diferentes partes de la pila de software”.

Las cosas se vuelven menos claras cuando se trata de heterogeneidad. “Estamos viendo personas que colocan hipervisores en sistemas heterogéneos”, dice Jeff Hancock, jefe de gestión de productos de software integrado de Siemens. “Claro, eso podría considerarse de subproceso único en los núcleos de la aplicación, pero en la industria automotriz ejecutan Linux y Android Auto, por ejemplo, en un hipervisor, en un quad A53 o algo así. Y luego tienen estos núcleos R que están en el mismo chip que ejecuta Autostar. Entonces, incluso en un solo SoC que tiene múltiples núcleos, en realidad están ejecutando entornos de tipo heterogéneo”.

Se están creando soluciones específicas de dominio. “Vemos la iniciativa SOAFEE de Arm en el dominio automotriz”, dice Kogel. “Este es un intento de formalizar el desarrollo de software de manera que pueda pasar sin problemas del desarrollo nativo de la nube a la implementación, tratando de encapsular las cosas con los acopladores y la virtualización. Se necesitan iniciativas de varias empresas como esta para llegar a algo a este nivel”.

Pero el software tiene que cambiar. “Ya sea que tenga ocho núcleos Intel en su computadora portátil o una docena de núcleos en su teléfono, el modelo de programación sigue siendo una aplicación de un solo subproceso”, dice Klein de Siemens. “Y ese es el factor limitante. Mientras la gente del software exija que programemos con un solo núcleo y la ilusión de que somos lo único en el procesador, hasta que podamos superar eso, tendremos que seguir intentando construya procesadores más grandes y acelere las cosas dentro de ese modelo. Tan pronto como rompes ese modelo, suceden todo tipo de cosas realmente geniales. Pero eso no es un problema de tecnología de hardware. Eso es un problema de software, cultural”.

Se han hecho intentos para particionar un único subproceso en varios núcleos. “Los arquitectos que construyen estos sistemas están averiguando cómo pueden desglosar las cosas y hacerlas en paralelo”, dice Simon Davidmann, fundador y director ejecutivo de Software Imperas. “Las aplicaciones no son un hilo de C, porque sería muy difícil hacer algo con eso. No hay magia en paralelizar el código C”.

Poder tomar software arbitrario y apuntarlo a hardware arbitrario es el santo grial. Solo un paso de eso es poder derivar un modelo de flujo de datos, y ese es un problema muy difícil de resolver en el caso general.

“Funciona para marcos de ML porque, para empezar, tiene un modelo de datos más adecuado”, dice Kogel. “TensorFlow tiene el paralelismo inherente y las dependencias de datos definidas de una manera mucho más agradable que una pieza arbitraria de código C, C++. Actualmente, lo que vemos es que las personas están utilizando el rastreo, tratando de rediseñar estas dependencias para ejecutar aplicaciones en plataformas virtuales o en hardware de destino para extraer las dependencias reales. Es un problema difícil hacerlo automáticamente en función del análisis de código estático o dinámico. Hemos visto intentos en esta dirección, pero aún es más un tema de investigación. Traería un gran beneficio si pudiera resolverse”.

El problema siempre ha sido las dependencias de datos. “Una cosa acerca de las redes neuronales es que tienen una estructura regular y son vergonzosamente paralelas”, dice Klein. “Hay tanto paralelismo allí que se vuelve mucho más fácil entrar y comprender qué se puede particionar en diferentes aceleradores sin introducir ninguna dependencia de datos. A medida que avanzamos hacia el software de propósito general, los algoritmos generalizados, eso sigue siendo un problema que nadie ha descifrado. ¿Cómo tomamos el programa C que alguien escribió, con la ilusión de que será el único en la computadora y será una aplicación de un solo subproceso, y podrá moverlo a múltiples CPU pequeñas? Eso sigue siendo un problema muy difícil. Y nuevamente, la comunidad de software no parece estar aceptando los beneficios potenciales de ir allí”.

El problema existe en todas las áreas de aplicación. “La mayoría de los equipos de diseño y los proveedores de IP dentro de AI/ML se han centrado en la regla número uno: proporcionar potencia de procesamiento que coincida con la carga de trabajo”, dice Steve Roddy, director de marketing de cuádrica. “Pero han descuidado la regla número dos: no cargar al desarrollador de software de aplicación. La mayoría de las soluciones de ML han descargado una parte del procesamiento de gráficos de una CPU o DSP heredada, pero no toda la carga de trabajo de gráficos de ML. Esto complica aún más la vida del desarrollador de software”.

El cambio es difícil. “Queremos llegar allí”, dice Cadence's Wall. “Es un problema inmensamente desafiante tener un entorno de desarrollo de software completamente desacoplado de la arquitectura. Incluso si uno aprovecha algo como OpenMP, siempre habrá algún nivel de dependencia arquitectónica”.

Se está dejando mucho sobre la mesa. “Lo que dejas sobre la mesa en términos de rendimiento y eficiencia, y la capacidad general del sistema cuando diseñas el hardware y luego lo tiras por la borda o lo vendes a otra empresa y luego escribes el software, es enorme”. dice Klein. “Hay tanta pérdida de capacidad, tanta pérdida de eficiencia, tanta pérdida de rendimiento. Conozco muy pocas organizaciones donde las personas necesarias se sientan y diseñan el hardware mientras piensan en la arquitectura del software que se ejecutará en él. En lo que casi siempre se enfocan es en diseñar hardware para ejecutar cualquier aplicación de un solo subproceso y tratar de encajar en ese molde. Eso puede estar empezando a desmoronarse”.

Se necesita un equipo. “Comprender los problemas requiere un esfuerzo de equipo”, dice Schirrmeister. “Requiere un conjunto de arquitectos y es una tarea increíblemente compleja. Al mismo tiempo, la complejidad del sistema está creciendo tremendamente rápido. Nos acercamos a una era en la que las herramientas pueden estar lo suficientemente conectadas para que esto realmente funcione. Estamos conectando las herramientas verticalmente y algunos flujos están en su lugar. Hay algunas de las herramientas de optimización de la arquitectura. Ciertamente no tenemos las personas que pueden manejarlo todo, así que ese es un problema de educación. Pero si lo combina con el aprendizaje automático y la inteligencia artificial, entonces tenemos una oportunidad, si puede permitirse que los ciclos pasen por variaciones significativas”.

Conclusión
Durante los últimos 25 años, la gente ha estado analizando el potencial de herramientas a nivel de sistema que podrían abarcar hardware y software. Ser capaz de optimizar ambos y mapear uno con el otro tiene ventajas obvias, pero claramente nunca han sido suficientes para superar el problema de la productividad del software. Llegar al mercado más rápido es más importante que un producto que funciona más rápido, consume menos energía o es más barato. Muchos en la industria piensan que el cambio es inevitable, pero se han equivocado durante mucho tiempo.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Automoción / vehículos eléctricos, Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• Desplazamientos de bloque. Modernización de la propiedad de compensaciones ambientales. Accede Aquí.
• Fuente: https://semiengineering.com/not-all-there-heterogeneous-multiprocessor-design-tools/