¿Hasta dónde se puede empujar un diseño RISC-V y seguir siendo compatible?

La respuesta no siempre es blanco y negro porque el RISC-V El concepto es muy diferente de los proyectos de código abierto anteriores. Pero a medida que crece el interés y la actividad en RISC-V, se están llevando a cabo debates constructivos para abordar algunos de los desafíos de diseñar con un ISA de estándar abierto.

“El estándar RISC-V es algo con lo que las implementaciones son compatibles”, dijo Mark Himelstein, CTO de RISC-V International. “Sin embargo, generalmente no usamos la palabra 'compatible' porque el objetivo final es ejecutar aplicaciones en implementaciones que sean compatibles con un perfil. El cumplimiento es un medio para alcanzar la compatibilidad”.

Uno de los problemas al reducir cualquiera de esas definiciones es el contexto histórico. A diferencia de algunos proyectos de procesador abierto, como OpenSPARC, no hay código fuente involucrado. OpenSPARC proporcionó acceso a las descripciones RTL de los procesadores de Sun Microsystems en lugar de proporcionar un ISA como RISC-V.

“RISC-V se diferencia de los conjuntos de instrucciones RISC anteriores por ser modular”, dijo Roddy Urquhart, director senior de marketing técnico de Codasip. “RISC-V requiere el uso de un conjunto de instrucciones de base entera como RV32I o RV64I, y ha ratificado varias extensiones estándar que son opcionales. También ha definido el espacio de codificación de instrucciones para instrucciones personalizadas. Para cumplir con ISA, una condición necesaria es usar el conjunto de enteros base apropiado, pero si se usa una combinación de extensiones estándar y/o extensiones personalizadas, entonces ISA cumple con RISC-V”.

Aún así, hay muchas piezas en este rompecabezas y mucho margen de maniobra sobre cómo se define.

“Para cumplir con RISC-V, en realidad solo tiene que implementar un subconjunto muy pequeño de instrucciones”, dijo Rob Aitken, distinguido arquitecto de Sinopsis. “Entonces puede decir que su diseño cumple con RISC-V porque implementa el conjunto de instrucciones de números enteros mínimos. La idea detrás de esto era que un acelerador podría atornillarse al sistema, luego podría tener cualquier código de operación, etc., que quisiera para su acelerador, que podría coexistir en el espacio del conjunto de instrucciones con la pieza de instrucción mínima RISC-V. Todo eso está filosóficamente permitido como parte del estándar. Así que efectivamente, 'cumple' solo significa que implementé las partes de RISC-V que dije que implementé, y cualquier otra cosa que hice está dentro del marco de extensibilidad que está definido, y es lo que es. Esa es una bestia diferente a las ISA anteriores que existen, donde si hay alguna extensibilidad, está muy restringida”.

Richard Grisenthwaite, vicepresidente ejecutivo y arquitecto jefe de Brazo explicó: “El cumplimiento es binario: cumple al 100 % o no cumple. Si el software que desea ejecutar se basa en instrucciones que usted no crea, entonces no se ejecutará en su hardware. Y si desea que el software que se ejecuta en su dispositivo forme parte de un ecosistema ampliamente utilizado, entonces no tiene sentido que use instrucciones que no están disponibles en otro hardware; esto podría ser problemático para alentar a los desarrolladores de software a escribir no. -software portátil. Es por eso que Arm y muchos otros proveedores de ISA, incluidos los reproductores de código abierto, están trabajando con una colección de extensiones de nombres que estandarizan la arquitectura de manera efectiva. Si te mantienes dentro de esas extensiones y especificaciones, el cumplimiento no es un problema, pero esto no te deja con la flexibilidad que podrías esperar del código abierto”.

Comprender el cumplimiento en el contexto del diseño con estándares abiertos ISA sigue siendo desafiante.

“Para hacerlo correctamente, se necesitan cantidades increíblemente grandes de recursos”, dijo Simon Davidmann, director ejecutivo de Software Imperas. “El cumplimiento se trata de control. Si desea ser compatible con la definición, alguien debe proporcionar la capacidad para demostrar y hacer cumplir el cumplimiento. Lo que hacen las empresas como Arm es controlarlo de muchas maneras diferentes, como lo han hecho todas las ISA en el pasado. Dicen: 'Esta es nuestra definición. No está permitido cambiarlo de este sobre. Con Arm, no puedes agregar instrucciones, no puedes cambiar la decodificación, no puedes agregar registros, porque si haces algo de eso, no es un 'Arm' y la licencia que te dejan tener no te permite para hacerlo. Incluso Google, Samsung y otros que son licenciatarios de arquitectura no pueden legalmente impedir que sea un brazo”.

Sin embargo, Arm permite a los licenciatarios de arquitectura cambiar un poco el RTL, pero no el código fuente. “Puede agregar una etapa adicional en la tubería, o puede implementarla de manera diferente, lo que Apple ha hecho en su M1 y M2”, dijo Davidmann. “Pero, ¿cómo están a la altura del hecho de que todavía es un brazo? ¿Cómo es compatible con el brazo? Arm proporciona una tecnología importante, dependiendo de la licencia que tengas y de cuánto puedas jugar con ella. Por ejemplo, alguien que solo está licenciando un núcleo pequeño y no se le permite cambiarlo, solo obtendrá algunas pruebas de compatibilidad bastante simples para verificarlo porque no se le permite hacer nada para cambiarlo. Realmente no pueden cambiar el RTL, por lo que no hay mucho por hacer. Pueden sintetizarlo, y podrían apuntar a diferentes cosas y obtener diferentes puertas, pero no se les permite cambiar el RTL, mientras que un licenciatario de la arquitectura Arm como Apple o Google o Samsung o MediaTek puede cambiar las etapas de la canalización. Pueden hacer lo que quieran y, de hecho, algunos pueden empezar desde cero. Pueden decir: 'Tomaremos su documento y lo crearemos como queramos'. ¿Cómo probamos que es compatible? Para los licenciatarios de arquitectura, como parte de sus millones de dólares, obtienen una gran cantidad de tecnología de compatibilidad, que incluye referencias, pruebas y marcos. Luego pueden analizarlo y averiguar si todavía es un brazo o no, y tienen que arreglarlo”.

Además, mientras que los usuarios de procesadores incorporados con frecuencia compilan su software a partir del código fuente, los sistemas operativos enriquecidos y las aplicaciones que se ejecutan en ellos se entregan como archivos binarios.

Urquhart señaló que esto requiere la combinación de un conjunto entero base y extensiones estándar opcionales para ser consistente. “RISC-V International ha estandarizado esto al definir perfiles como RVA22U64, que especifican una combinación obligatoria de extensiones estándar. Por lo tanto, en algunos contextos, el cumplimiento de un perfil adicional a la ISA es importante. Si el diseño se implementa como RTL, por ejemplo, ¿se puede verificar con un modelo de instrucciones precisas? Esto requeriría que el modelo incluya las instrucciones enteras base, extensiones estándar seleccionadas e instrucciones personalizadas”.

Codasip Studio, por ejemplo, puede generar un entorno UVM para hacer esto. Pero para poner esto en perspectiva, el proceso de cumplimiento tiene un impacto en el diseño o el proceso de diseño.

Este año se ratificaron los primeros “Perfiles”, que contienen una generación de extensiones compuestas por instrucciones de estado y comportamiento, que funcionan en conjunto, según Himelstein de RISC-V International. “Las extensiones son obligatorias u opcionales. Las implementaciones que elijan ser compatibles con un perfil deben implementar todas las extensiones obligatorias. Los perfiles brindan a los sistemas operativos y las cadenas de herramientas un objetivo único para admitir en toda la comunidad”.

Si hay problemas de incumplimiento, el proveedor publica erratas y un plan de recuperación. “Si es a propósito, lo que se permite como cambios personalizados, entonces el proveedor simplemente no puede calificar su producto como compatible con el perfil RISC-V”, dijo Himelstein.

Cada arquitectura tiene este problema. “Tenemos un conjunto básico de pruebas que verifican contra simuladores que producen resultados dorados”, señaló Himelstein. “Pero depende del proveedor certificar que ha realizado DV, pruebas de sistema, pruebas de software adecuadas, etc. No somos un organismo certificador. Es la necesidad de tener una economía de software viable lo que impulsa a todos a ser compatibles con Profile, de modo que los proveedores de software puedan tener una versión por tipo de sistema operativo que funcione en múltiples implementaciones. Somos una comunidad, y esa comunidad es una organización de mejora continua. Siempre estamos trabajando para mejorar el simulador y las pruebas”.

Riesgo de fragmentación
La fragmentación es siempre una preocupación en el ámbito del software. Si bien los estándares abiertos de hardware no necesariamente tienen que ser compatibles con compiladores de código abierto, se está realizando un gran esfuerzo tanto en las comunidades LLVM como en las comunidades GCC para admitir RISC-V, y la desviación del estándar de hardware tiene un impacto en el código abierto. implementación de la fuente.

“En el mundo RISC-V, parte del estándar que tardó mucho tiempo en ratificarse es la extensión del vector al estándar RISC-V”, explicó Catherine Moore, directora de ingeniería de software de Software de Siemens Digital Industries. “Muchos proveedores de hardware realmente necesitaban esa extensión antes de que fuera ratificada, por lo que muchos proveedores de hardware se fueron e implementaron lo que pensaban que sería el estándar e implementaron su propia versión del estándar, etc. Así que ahora estas cosas son difíciles. codificado en su versión del estándar, que se desvía de lo que finalmente se ratificó. Como resultado, han tenido que desarrollar herramientas de compilación para respaldar su derivación del estándar, y lo que vemos, por supuesto, es fragmentación”.

Eso, a su vez, crea una oportunidad para los grupos que brindan servicios de software personalizados para herramientas de compilación de código abierto.

“Cuando estos estándares de hardware se fragmentan, es una gran oportunidad de soporte, porque la mayoría de las personas que están creando componentes de código abierto quieren que se envíen y acepten en las comunidades de código abierto en las que se están construyendo”, dijo Moore. “Pero GCC, por ejemplo, no aceptará ningún envío que se desvíe del estándar, por lo que los proveedores que tienen implementaciones únicas de la extensión de vector en RISC-V necesitan admitir ese soporte externo a la comunidad que está disponible a través de GCC o LLVM. ”

Las ramificaciones de la fragmentación son significativas y el efecto es que será más costoso mantenerlo porque la parte del estándar que se implementa de manera diferente en el diseño está fuera de la comunidad.

Aun así, RISC-V permite un conjunto de instrucciones personalizado. “Hay una extensión en el estándar RISC-V que permite a los proveedores crear sus propias instrucciones personalizadas”, dijo Moore. “La fragmentación está separada de eso porque hay un estándar sobre cómo crear las instrucciones separadas. Hay una codificación que marca las cosas como separadas y propietarias. Esas cosas deben ser consideradas parte de este estándar. Implementar una extensión de manera diferente a la forma en que se ratificó el estándar es lo que genera problemas, al menos en el mundo del software”.

Hacer sonar la alarma
Para que un diseño RISC-V sea compatible con otro ISA, se requiere una gran cantidad de pruebas de verificación de compatibilidad.

“RISC-V no promueve el cumplimiento de la misma manera que lo hace un brazo”, dijo Davidmann de Imperas. “No tienen los recursos para proporcionar las pruebas de compatibilidad. Lo que tienen es trabajo voluntario, creando pruebas comunitarias abiertas, que básicamente son compatibilidades muy sencillas. No creo que haya muy buenas suites de compatibilidad todavía. Con nuestro primer trabajo, cuando nuestro modelo y nuestro simulador de referencia estaban en el grupo de compatibilidad, creamos algunas pruebas y creamos una referencia para tratar de ayudar con esto, pero no había recursos disponibles. En las empresas comerciales, debe pensar que Intel hace una fortuna con el silicio, por lo que puede invertir mucho en cosas de verificación de compatibilidad. Arm gana mucho dinero con las licencias de los núcleos, por lo que estos tienen enormes flujos de ingresos, y lo que hacen es invertirlo en su ecosistema, y ​​mucho se reduce a la compatibilidad. El ecosistema RISC-V no tiene financiación. Todo el mundo es un individuo. Lo que han hecho en la compatibilidad dice: 'Aquí hay algunas pruebas simples, debe ejecutarlas. Cuando los haya ejecutado, envíenos sus datos y le permitiremos usar la insignia de que es compatible con RISC-V.' Pero esa no es una póliza de seguro comercialmente sólida”.

Además, el cumplimiento es un componente necesario pero no suficiente de la verificación.

“Un diseño de microarquitectura puede tener una variedad de errores que no tienen nada que ver con ISA o el cumplimiento del perfil”, dijo Urquhart de Codasip. “Por ejemplo, puede haber condiciones de carrera o problemas de interfaz con interrupciones o cachés. Dado que el diseño de un procesador tiene un espacio de estado muy grande, la verificación del RTL es mucho más compleja que los bloques aceleradores cableados. Por lo general, se combinan una variedad de métodos para encontrar errores, incluidas pruebas directas, métodos aleatorios restringidos y verificación formal”.

Aitken de Synopsys estuvo de acuerdo en que las pruebas de cumplimiento son complicadas. “Esto es cierto ya sea que se trate de una ISA abierta o cerrada. Es realmente que el cumplimiento de un objeto personalizable o extensible se vuelve más desafiante. ¿Qué quieres decir con eso? Si tiene un código de operación ilegal en Arm o x86, simplemente dice "instrucción ilegal", fin de la historia. Pero en un diseño RISC-V, dependiendo de cuál sea el código de operación, en realidad podría ser un código de operación ilegal que se implemente. Podría ser algo que alguien agregó. ¿Tienen que decírselo a alguien? Hay muchas áreas grises que pueden existir en este espacio, y debido a que es potencialmente un desastre, las personas lo evitan eligiendo subconjuntos bien definidos que simplemente eluden toda la cuestión".

La diferencia entre cumplimiento y verificación para una ISA fija es un poco más clara que para una ISA extensible. “¿Esta cosa implementa las instrucciones que se supone que debe hacer? Esa es una pregunta fácil de responder”, dijo Aitken. “¿Hace las otras cosas que dice que hace? ¿Lo hace de una manera compatible? Hay un área gris entre donde termina y donde comienza algún tipo de error de implementación, y se debe en parte a la distinción entre ISA y arquitectura o microarquitectura y una implementación específica de esa microarquitectura. Si solo hay uno, ¿dónde existe el problema? Como usuario de una cosa, es posible que no tenga ni idea. Incluso como desarrollador de la cosa, es posible que no esté realmente seguro de en qué parte de ese continuo se encuentra su problema. Si está "aquí" e interpretamos mal la especificación, entonces es un problema de cumplimiento. Si interpretamos la especificación correctamente, pero la implementamos mal, eso podría ser un error de arquitectura, un error de microarquitectura o un error de implementación dependiendo de lo que hizo exactamente porque lo implementó mal”.

¿Cómo sabe el desarrollador con certeza? "No lo haces", dijo. “Solo sabes que eventualmente tendrás que averiguar qué es lo que está mal y arreglarlo. Pero la descripción precisa de lo que se rompió y cómo lo describimos no es necesariamente clara. Entonces todo se reducirá a la visión pragmática de 'No funcionó antes, y funciona ahora'. Revisa la caja.' ¿Por qué no funcionó antes? Bueno, es complicado.

Una nota de advertencia
Al final del día, las pruebas de compatibilidad en RISC-V no son una verificación, lo que significa que cuando terminen, podrían cubrir el 10 % o el 20 % de la especificación en términos de capacidades reales, dijo Davidmann. “Donde RISC-V realmente se mete en problemas es que hay tantas elecciones que un cliente puede hacer con la implementación que en realidad es muy difícil escribir pruebas que funcionen para todos estos diseños diferentes. La libertad que han brindado con RISC-V es brillante en una industria que intenta construir chips definidos por software, pero esta libertad significa que es una completa pesadilla en términos de compatibilidad. La industria de RISC-V realmente no ha entendido la complejidad de este desafío de compatibilidad, y no están poniendo los recursos en ello en absoluto”.

Grisenthwaite de Arm agregó: “El cumplimiento es realmente parte de la verificación, pero es importante tener especificaciones precisas y completas sobre lo que se necesita construir para cumplir. Cuando se trata de instrucciones individuales, eso es sencillo; para otros elementos, es más complejo, y los incumplimientos sutiles pueden ser un problema tan grande como las fallas flagrantes si el software se basa en el comportamiento involucrado. Y es importante recordar que el cumplimiento es un subconjunto de la verificación, lo que implica observar mucho más de cerca los problemas que son específicos de una implementación en particular, incluidas las anomalías de rendimiento. La verificación es obviamente fundamental para el proceso de diseño, a menudo es el componente que consume más tiempo, y una metodología de verificación se vuelve confiable y resistente porque se ha implementado en millones de diseños en un amplio ecosistema de usuarios”.

Una arquitectura extensible lo hace aún más difícil.

“Si desea un ISA extensible, eso se vuelve mucho más desafiante”, concluyó Davidmann. “Hay una empresa con los fondos para invertir en esto. La inversión comunitaria no funciona con los aficionados. Cuando Arm tuvo un problema con Linux, crearon Linaro, lo que supuso una inversión de 30 o 40 millones de dólares al año. Esto no puede ser un club de aficionados. Debe haber ingenieros comprometidos a tiempo completo. Para RISC-V, probablemente debería tener un equipo de 20 personas a tiempo completo creando tecnología de compatibilidad. Sus referencias, capacidad de verificación y sus pruebas. ¿Un par de aficionados en Asia? Lo siento, eso no va a llegar. El impacto de todo esto es que si está licenciando un procesador, necesita saber dos cosas. ¿Cumple con el estándar para que todo funcione? ¿Tienes otros errores en él? Esas son las preguntas que sus clientes le harán a todos los proveedores de IP, y RISC-V International hoy en día no se preocupa por los problemas de cumplimiento al nivel que debería. Dicen que está en papel. Sus acciones no indican que se preocupen por eso”.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• EVM Finanzas. Interfaz unificada para finanzas descentralizadas. Accede Aquí.
• Grupo de medios cuánticos. IR/PR amplificado. Accede Aquí.
• PlatoAiStream. Inteligencia de datos Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://semiengineering.com/the-uncertainties-of-risc-v-compliance/