Epiphany SDK Insights and Future


The Epiphany SDK started life as a prototype binutils & GCC port by Alan Lehotsky, which would run code on a Verilator model of the Epiphany chip.

Embecosm became involved in March 2009, initially providing an implementation of the GNU Debugger. Then over a period of 6 weeks starting that September we upgraded GCC to a commercially robust implementation, eliminating all regression test failures from the C and C++ compilers. This was still before the first silicon had been spun, and with testing against a Verilator model.

Verilator creates a cycle accurate C++ model from the Verilog of the design and in doing so faithfully replicates the exact behavior of the chip. Sometimes we found errors that just could not be the compiler and these turned out to be, as can be expected, faults in the early silicon design.

Effectively the 100,000 tests of the GNU regression test suite also became part of the pre-silicon verification of Epiphany. We believe this was the first time this technique had been used in a commercial silicon chip design, and Andreas Olofsson believes that this identified 50-60 hardware design flaws and was a key factor in the 1st generation Epiphany chip working first time.


Epiphany GCC was developed with two clear goals: code must be compact so that it will fit within the relatively small memory of each core; the code generated must be high performance.

Embecosm has continued to work closely with Adapteva, placing particular emphasis on developing the vectorizing features of GCC. Epiphany has a 5-stage pipeline and both a floating point and integer execution unit on each core, and the goal is to keep both of those pipelines as full as possible.

The SDK is more than just the tool chain for which Embecosm is responsible, and it also includes e-hal — the Epiphany driver that provides a consist API across platforms,  e-lib — a library to access all the features of the Epiphany hardware,  a GNU debugger server for easy remote debugging of cores, BSPs, documentation and examples, and in the future an Eclipse CASE environment. [1]


Even though its primary objective is floating point computation, with a CoreMark performance of over 12,000 for a single core, Epiphany is fast as an integer processor.

One good way to look at performance is to see how well the compiler can schedule instructions to keep the pipeline full. Modern GPU’s consider reaching 20% pipeline occupancy a good result. Epiphany GCC has achieved up to 87% pipeline occupancy with carefully crafted C code, and occupancy of at least 50% is expected with DSP style code! [1]

Another aspect of performance is energy efficiency and the truly unique property of Epiphany is that it achieves its high performance while consuming just a couple of watts power. Working jointly with Bristol University and supported by Adapteva, Embecosm have been looking at how compiler optimizations can be used to reduce the energy consumption of programs.


Our core activity is to continue to developing the compiler, tuning its performance and taking advantage of the latest optimizations in GCC. However, we also want to add new features and our top priority is support for position independent code (PIC), making it easier to move code between cores.

Longer term we want to provide a robust Eclipse environment. You can already use the tool chain with standard Eclipse CDT, but we want to provide a more complete integration that includes support for the multi-core plugin.

Finally, we are continuing our work on energy minimization. The UK government is funding an open source research project to develop a compiler framework for energy optimization using machine learning techniques. Once again we’ll be working with Bristol University  and Epiphany will be one of the architectures used to develop and evaluate the technology. Which means that over the next 18 months Epiphany will be at the heart of some of the most advanced compiler technology in the world.

How you can contribute

We have only a small team working on the SDK and we are looking to the community to participate. Here are some ideas for how you can contribute:

1. Report bugs on the GitHub issue tracker. Good bug reports include a test case to generate the problem. Really good bug reports include a patch.

2. Send us benchmark examples, particularly where you think the compiler ought to do better. Again the GitHub issue tracker is a good place for such examples, but you can also discuss them on the forums to get community suggestions on optimization.

3. Tell us what new features you would like in the compiler. The forums are the best place for this, but once there is a consensus on what a new feature should look like you can record it as an enhancement request in the GitHub issue tracker.

For the ambitious, we welcome suggested code fixes and improvements. The easiest way to do this is to send us a pull request with your patch.

Epiphany already has a world class open source SDK and with help from the community we can build on this and make sure it gets even stronger.

[1] Text updated at 19:00 GMT, March 18, 2013 to provide correct SDK and pipeline occupancy performance details.

One Comment

Leave a Reply