15
$\begingroup$

In late 1997, the European Space Agency started the LEON project to provide higher performance processors for ESA missions. An open instruction set architecture was a first-level requirement (both to avoid availability issues and to allow customization), but suitability for use in space was also a major consideration.

The ESA chose to use SPARC Version 8 (from 1991/1992 based on the copyright notice in The SPARC Architecture Manual: Version 8, the base ISA was released in 1987). SPARC had some advantages:

  • It was perhaps the only fully open ISA with significant backing.
  • It was a reasonably simple ISA (RISC), friendly to lower-effort implementation.
  • Workstations existed using SPARC v8 compatible processors, so cross compiling could be avoided.
  • Development tools for SPARC were reasonably mature, though presumably more oriented toward server/workstation workloads.

However, SPARC also had some disadvantages:

  • By 1997 (with the introduction of the Pentium II) the future of SPARC in workstations would have begun to be under question (making the cross compiling issue somewhat moot).
  • SPARC was not being broadly adopted as an open ISA, so there was not a significant commodity effect. (This was probably not a major consideration for LEON, but influences the availability of software tools. The openness of SPARC also has limited advantage in terms of patents.)
  • As a classic RISC SPARC had somewhat poor code density. (Code size is a significant factor for space-based computers.)
  • SPARC was not being broadly adopted for use in embedded systems. (This would have influenced the availability of development tools suitable for such systems.)
  • SPARC's register windows would have increased minimum core size, slightly increased hardware design complexity, and involved more complex development for tightly constrained real time operation.
  • SPARC included less useful features like tagged arithmetic. (This was probably not significant since a subset of the architecture could be used.)
  • SPARC's instruction format was somewhat less regular than other RISCs. (This is a rather trivial objection; the size/power difference between instruction decoders for an Alpha-like ISA and SPARC would be less than 1%.)

With somewhat guaranteed use by the ESA of whatever architecture was chosen and the special requirements for space-based systems, it seems that a custom ISA might have been practical. A custom, open ISA would have significant disadvantages:

  • The lack of existing development tools would have added cost and linked compiler development to hardware development (increasing schedule risk). (Non-open tools for SPARC development would have represented some risk to LEON, but this could rightly have been considered a minor issue.)
  • The lack of same-ISA workstations would have added complexity and cost to initial development.
  • Even excluding the cost of producing software development tools, developing a new ISA has significant cost and risk. (Getting consensus without design-by-committee effects is challenging and second system dangers may have been significant.)

Any increase in (early) cost and risk may have disproportionately increased the probability of project failure. On the other hand, a custom ISA could have been more fit for the purpose and might have been able to generate more external adoption in aerospace both of the ISA and of chips developed for the ESA (which would have increased the quality of software, increased the testing of implementations, and reduced hardware costs).

So how did the ESA come to choose SPARC over a custom ISA (or perhaps negotiating a limited perpetual license for another RISC ISA)?

Improve this question
$\endgroup$
6
  • 1
    $\begingroup$ Not sure about the tags. (Really surprised that ESA had not been made a tag yet.) $\endgroup$
    – user56
    Jul 25, 2013 at 0:27
  • 1
    $\begingroup$ To the downvoter: it is polite to provide a comment explaining the downvote. Do you think the question is off-topic? Not useful? Is there some other problem? (Unclear or not showing research effort seems unlikely.) $\endgroup$
    – user56
    Jul 25, 2013 at 17:27
  • 3
    $\begingroup$ You probably have to go further back, Leon was more about taking control of production and development of the ERC32 processor (which implemented sparc-v7). There's a few paragraphs about why it was Sparc here but not too much substantial. $\endgroup$
    – nos
    Jul 26, 2013 at 16:01
  • $\begingroup$ @nos Thank you very much! I did not know that SPARC had been used before LEON. From "Applicable Documents" listed in "32-bit Microprocessor and Computer Development Programme: Final Report" it appears work began was no later than 1991 (no luck finding those docs online) at which time SPARC would have made more sense. With an established 32-bit software ecosystem by the time of LEON, using another ISA would have significantly increased costs and delay. Now I have to rethink (or take as answered) my question. $\endgroup$
    – user56
    Jul 26, 2013 at 16:33
  • $\begingroup$ Hmm before you re-think your original question: If it is ESA, there should be a 'call for proposals', an 'invitation of tenders' or something similar. And there should be an evaluation afterwards. I am basically with nos, but it would not be ESA if there was not a hundreds of pages long document about the decision ... $\endgroup$
    – s-m-e
    Jul 31, 2013 at 16:40

1 Answer 1

Reset to default
8
$\begingroup$

As @nos said, the decision to go with SPARC was made in 1991. There were several reasons (presentation on history of ERC and Leon):

ESA performed two architectural studies, evaluating processors such as MIPS, THOR, MC68020, I386, NS32. ESA also invited industry for round-table discussions. Finally, SPARC was selected due to:

  • Open architecture without patents or license fees
  • Well designed and documented
  • Easy to implement
  • Established software standard
  • Available design (CY601)

If those were selection criteria, you can see that a custom ISA would not satisfy the criteria.

The final report for the ERC32 program (as found by @nos) said this:

Furthermore, it was requested to "reuse" an existing processor architecture in order to minimize both software and hardware development cost. Performed ESA and industrial studies resulted, at that time, in the selection of SPARC instruction set architecture as the baseline. This was in order to e.g. simplify bread-boarding and software development.

So, ESA specifically required an existing ISA be used.

If you choose a custom ISA, you have to create everything yourself:

  • the entire chip design (instead of being able to use existing building blocks as with SPARC),
  • compiler,
  • all software including the OS,
  • cross-compilation and other equipment you need to develop software for this new ISA

You also lose the convenience of having off-the-shelf hardware for the thousands of systems you need on earth, for development, testing etc. And you lose the thousands of man-years already invested in testing the SPARC architecture and software. By 1991, any bugs in SPARC were well-known; SPARC software was mature and in use everywhere. A custom ISA might gain a bit more efficiency, but you increase the difficulty of the project by several orders of magnitude.
(good article on Leon, Leon and radiation hardening, Leon development)
The FAQ for LEON states:

Why does LEON implement a SPARC and not an ARM or MIPS?

Designing SPARC processors can be done without any licenses what so ever. This is indeed why Jiri Gaisler has selected SPARC for the development of LEON, just see how many times Intel, MIPS and ARM have sued companies that developed processors using their architecture.

For example, in mid-February 2002 the legal battles between Lexra/MIPS and picoTurbo/ARM have both ended with a complete defeat of the two cpu-cloning companies (Lexra and picoTurbo). Both companies have been shut-down and their clients transferred to MIPS/ARM.

Jiri Gaisler said: "More than ever, I'm happy with the decision to go SPARC. :-) And many thanks to Sun and SPARC International for the open license!"

Improve this answer
$\endgroup$
6
  • $\begingroup$ I take it you were not able to find anything other than the presentation for ERC. SPARC was no more patent-free by nature than any open specification; the founders did not provide patent indemnification (the infamous MIPS patents were probably invalid, BTW, however much good such was to others). SPARC was not especially well-design as an architecture and any RISC-like ISA would be "easy" to implement (compiler, OS, and even hardware changes among RISCs can be small). In 1991 (ERC) the trade-offs were different than in 1997 (LEON), but by then software compatibility would be important. $\endgroup$
    – user56
    Dec 22, 2013 at 22:16
  • 1
    $\begingroup$ In my "research", I did find the following quote from Patterson in SPARC Microprocessor Oral History Panel, Session One, Origin and Evolution: "the fact that it's the only standard instruction set, the only instruction set with a standard and a verification suite makes it very attractive for kind of small groups". (I did +1 your answer and am likely to accept later even though I was hoping for more detailed reference material.) $\endgroup$
    – user56
    Dec 22, 2013 at 22:21
  • $\begingroup$ I concentrated my search on ERC, as LEON seems to be a follow-on with no consideration of other architectures. $\endgroup$
    – Hobbes
    Dec 23, 2013 at 9:58
  • 2
    $\begingroup$ Where can you get low cost dev boards for this CPU type? $\endgroup$
    – zezba9000
    Jul 20, 2015 at 5:42
  • 1
    $\begingroup$ Search for "LEON SPARC development board". The first result I got: hitechglobal.com/ipcores/leon3.htm $\endgroup$
    – Hobbes
    Jul 20, 2015 at 6:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.