¿Por qué la ESA eligió SPARC para LEON?

A fines de 1997, la Agencia Espacial Europea inició el proyecto LEON para proporcionar procesadores de mayor rendimiento para las misiones de la ESA. Una arquitectura de conjunto de instrucciones abierto era un requisito de primer nivel (tanto para evitar problemas de disponibilidad como para permitir la personalización), pero la idoneidad para su uso en el espacio también fue una consideración importante.

La ESA optó por utilizar SPARC Versión 8 (desde 1991/1992 según el aviso de derechos de autor en The SPARC Architecture Manual: Versión 8 , la base ISA se publicó en 1987). SPARC tenía algunas ventajas:

  • Fue quizás la única ISA completamente abierta con un respaldo significativo.
  • Era un ISA (RISC) razonablemente simple, fácil de implementar y de bajo esfuerzo.
  • Existían estaciones de trabajo que usaban procesadores compatibles con SPARC v8, por lo que se podía evitar la compilación cruzada.
  • Las herramientas de desarrollo para SPARC estaban razonablemente maduras, aunque presumiblemente más orientadas hacia cargas de trabajo de servidor/estación de trabajo.

Sin embargo, SPARC también tenía algunas desventajas:

  • Para 1997 (con la introducción del Pentium II) el futuro de SPARC en las estaciones de trabajo habría comenzado a estar en duda (lo que hace que el problema de la compilación cruzada sea algo discutible).
  • SPARC no se estaba adoptando ampliamente como una ISA abierta, por lo que no hubo un efecto de producto significativo. (Probablemente esto no fue una consideración importante para LEON, pero influye en la disponibilidad de herramientas de software. La apertura de SPARC también tiene una ventaja limitada en términos de patentes).
  • Como un RISC clásico, SPARC tenía una densidad de código algo pobre. (El tamaño del código es un factor importante para las computadoras basadas en el espacio).
  • SPARC no se estaba adoptando ampliamente para su uso en sistemas integrados. (Esto habría influido en la disponibilidad de herramientas de desarrollo adecuadas para tales sistemas).
  • Las ventanas de registro de SPARC habrían aumentado el tamaño mínimo del núcleo, aumentado ligeramente la complejidad del diseño del hardware e implicado un desarrollo más complejo para una operación en tiempo real estrictamente restringida.
  • SPARC incluía características menos útiles como la aritmética etiquetada. (Esto probablemente no fue significativo ya que se podría usar un subconjunto de la arquitectura).
  • El formato de instrucción de SPARC era algo menos regular que el de otros RISC. (Esta es una objeción bastante trivial; la diferencia de tamaño/potencia entre los decodificadores de instrucciones para un ISA similar a Alpha y SPARC sería inferior al 1 %).

Con el uso algo garantizado por parte de la ESA de cualquier arquitectura elegida y los requisitos especiales para los sistemas basados ​​en el espacio, parece que una ISA personalizada podría haber sido práctica. Una ISA abierta y personalizada tendría desventajas significativas :

  • La falta de herramientas de desarrollo existentes habría agregado costos y vinculado el desarrollo del compilador al desarrollo del hardware (aumentando el riesgo de cronograma). (Las herramientas no abiertas para el desarrollo de SPARC habrían representado cierto riesgo para LEON, pero esto podría haberse considerado un problema menor).
  • La falta de estaciones de trabajo con la misma ISA habría agregado complejidad y costo al desarrollo inicial.
  • Incluso excluyendo el costo de producir herramientas de desarrollo de software, desarrollar una nueva ISA tiene un costo y un riesgo significativos. (Obtener consenso sin efectos de diseño por comité es un desafío y los peligros del segundo sistema pueden haber sido significativos).

Cualquier aumento en el costo y el riesgo (temprano) puede haber aumentado de manera desproporcionada la probabilidad de fracaso del proyecto. Por otro lado, un ISA personalizado podría haber sido más adecuado para el propósito y podría haber generado una mayor adopción externa en la industria aeroespacial tanto del ISA como de los chips desarrollados para la ESA (lo que habría aumentado la calidad del software, aumentado la prueba de implementaciones y costos de hardware reducidos).

Entonces, ¿cómo llegó la ESA a elegir SPARC en lugar de una ISA personalizada (o quizás a negociar una licencia perpetua limitada para otra RISC ISA)?

No estoy seguro acerca de las etiquetas. ( Realmente sorprendido de que ESA aún no haya hecho una etiqueta).
Para el votante negativo: es de buena educación proporcionar un comentario que explique el voto negativo. ¿Crees que la pregunta está fuera de tema? ¿Inútil? ¿Hay algún otro problema? (Parece poco probable que no esté claro o que no muestre el esfuerzo de investigación).
Probablemente tengas que ir más atrás, Leon se centró más en tomar el control de la producción y el desarrollo del procesador ERC32 (que implementó sparc-v7). Hay algunos párrafos sobre por qué fue Sparc aquí, pero no demasiado sustanciales.
@nos ¡Muchas gracias! No sabía que SPARC se había utilizado antes de LEON. Según los "Documentos aplicables" enumerados en "Programa de desarrollo de computadoras y microprocesadores de 32 bits: Informe final", parece que el trabajo comenzó a más tardar en 1991 (no hubo suerte para encontrar esos documentos en línea), momento en el que SPARC habría tenido más sentido. Con un ecosistema de software de 32 bits establecido en el momento de LEON, el uso de otro ISA habría aumentado significativamente los costos y la demora. Ahora tengo que repensar (o dar por respondida) mi pregunta.
Hmm, antes de que vuelva a pensar en su pregunta original: si se trata de la ESA, debería haber una 'convocatoria de propuestas', una 'invitación a licitar' o algo similar. Y debería haber una evaluación después. Básicamente estoy con los no, pero no sería la ESA si no hubiera un documento de cientos de páginas sobre la decisión...
¡ Porque SPARC está hecho por una compañía llamada Sun !

Respuestas (1)

Como dijo @nos, la decisión de ir con SPARC se tomó en 1991. Hubo varias razones (presentación sobre la historia de ERC y León):

ESA realizó dos estudios de arquitectura, evaluando procesadores como MIPS, THOR, MC68020, I386, NS32. La ESA también invitó a la industria a las mesas redondas. Finalmente, SPARC fue seleccionado debido a:

  • Arquitectura abierta sin patentes ni derechos de licencia
  • Bien diseñado y documentado.
  • Fácil de implementar
  • Estándar de software establecido
  • Diseño disponible (CY601)

Si esos fueran criterios de selección, puede ver que una ISA personalizada no cumpliría con los criterios.

El informe final del programa ERC32 (según lo encontrado por @nos) decía esto:

Además, se solicitó "reutilizar" una arquitectura de procesador existente para minimizar los costos de desarrollo de software y hardware. Los estudios industriales y de ESA realizados dieron como resultado, en ese momento, la selección de la arquitectura del conjunto de instrucciones SPARC como línea de base. Esto fue para, por ejemplo, simplificar el desarrollo de software y el tablero de pruebas.

Por lo tanto, la ESA requería específicamente que se utilizara una ISA existente.

Si elige un ISA personalizado, debe crear todo usted mismo:

  • todo el diseño del chip (en lugar de poder usar bloques de construcción existentes como con SPARC),
  • compilador,
  • todo el software, incluido el sistema operativo,
  • compilación cruzada y otros equipos que necesita para desarrollar software para este nuevo ISA

También pierde la conveniencia de tener hardware comercial para los miles de sistemas que necesita en la tierra, para desarrollo, pruebas, etc. Y pierde los miles de años-hombre ya invertidos en probar la arquitectura y el software SPARC. Para 1991, todos los errores en SPARC eran bien conocidos; El software SPARC era maduro y se usaba en todas partes. Una ISA personalizada puede ganar un poco más de eficiencia, pero aumenta la dificultad del proyecto en varios órdenes de magnitud.
( buen artículo sobre Leon , Leon y endurecimiento por radiación , desarrollo de Leon )
Las preguntas frecuentes para LEON dicen:

¿Por qué LEON implementa un SPARC y no un ARM o MIPS?

El diseño de procesadores SPARC se puede hacer sin licencia alguna. De hecho, esta es la razón por la que Jiri Gaisler ha seleccionado SPARC para el desarrollo de LEON, solo vea cuántas veces Intel, MIPS y ARM han demandado a las empresas que desarrollaron procesadores utilizando su arquitectura.

Por ejemplo, a mediados de febrero de 2002, las batallas legales entre Lexra/MIPS y picoTurbo/ARM terminaron con una derrota total de las dos empresas de clonación de CPU (Lexra y picoTurbo). Ambas empresas han sido cerradas y sus clientes transferidos a MIPS/ARM.

Jiri Gaisler dijo: "Más que nunca, estoy feliz con la decisión de ir a SPARC. :-) ¡Y muchas gracias a Sun y SPARC International por la licencia abierta!"

Supongo que no pudiste encontrar nada más que la presentación de ERC. SPARC no estaba más libre de patentes por naturaleza que cualquier especificación abierta; los fundadores no proporcionaron indemnización de patentes (las infames patentes de MIPS probablemente no eran válidas, por cierto, por muy bueno que fuera para otros). SPARC no estaba especialmente bien diseñado como arquitectura y cualquier ISA similar a RISC sería "fácil" de implementar (los cambios en el compilador, el sistema operativo e incluso el hardware entre los RISC pueden ser pequeños). En 1991 (ERC) las ventajas y desventajas eran diferentes a las de 1997 (LEON), pero para entonces la compatibilidad del software sería importante.
En mi "investigación", encontré la siguiente cita de Patterson en SPARC Microprocessor Oral History Panel, Session One, Origin and Evolution : "el hecho de que es el único conjunto de instrucciones estándar, el único conjunto de instrucciones con un estándar y un conjunto de verificación lo hace muy atractivo para grupos pequeños". (Hice +1 en su respuesta y es probable que acepte más tarde, aunque esperaba material de referencia más detallado).
Concentré mi búsqueda en ERC, ya que LEON parece ser una continuación sin tener en cuenta otras arquitecturas.
Acabo de encontrar un documento que era 'una parte del "estudio de evaluación RISC" de ESTEC'. El "Análisis de rendimiento de tres computadoras dedicadas al espacio basadas en RISC" ( PDF ) aparece relacionado y limitado a T800, THOR y SPARC. SLUB Dresden tiene una copia del informe de 378 páginas.
¿Dónde puede obtener placas de desarrollo de bajo costo para este tipo de CPU?
Busque "placa de desarrollo LEON SPARC". El primer resultado que obtuve: hitechglobal.com/ipcores/leon3.htm
¿Por qué la ESA eligió SPARC para LEON?
RespuestasAquíPolítica de privacidad1y, 1v