Today we are pleased to announce the release of the new Epiphany SDK binaries and source packages, version 5.13.07.10.
The 5th generation of the eSDK is a major step forward for the Epiphany in terms of ease of use and productivity and includes the following significant improvements:
- Workgroup based communication for host as well as client side code,
- A transition to relative addressing for inter-processor communication,
- Multicore communication primitives,
- A simplified interrupt programming model,
- An upgrade to GCC 4.8.
New Epiphany Toolchain
The Epiphany Toolchain, based on the GNU compiler collection and GNU sourceware is now updated to rev. 4.8.x. The new compiler generates better optimized code with smaller footprint.
In order to support the device side workgroup model, we added and modified the program flow synchronization features – barriers and hardware mutexes.
Barrier is an object shared among all members of a workgroup. When a process (program running on an eCore) reaches the barrier, it waits there until all the workgroup members reach that point as well. Only when all members reached the barrier will they continue the normal program execution. Barriers are an important feature helping to prevent software race conditions. The eLib provides APIs for initializing barriers and setting sync points in the programs.
A mutex is a mechanism for enforcing mutual exclusivity in granting right to use a shared resource. For example, when dealing with a hardware device, to which access is made as requests for data. The device is very fast in delivering large amounts of continuous data, but the overhead of random access is very high. Consequently, random access becomes slow as the data packets size become smaller. When designing the system, we’d want only one agent at a given time to access the device, to maximize the data throughput. An easy way to guarantee that is using the mutex mechanism. The workgroup defines a memory location serving as the “lock”. Each core, when requiring access to that device, checks the status of the lock. If it is free, it the core is granted with exclusive access to the resource. If it is not free, the core can wait until it is released and then grab the lock. Once the lock is no more required, it is released by the core holding the right. The eLib provides APIs for easy definition and handling of such mutexes. These can greatly improve access time to devices such as external DRAM.
The use of barriers and mutexes is exemplified in the matmul example in the eSDK release.
We also enhanced the flow of programming and using interrupts. Usually, these events are triggered by some hardware peripheral trying to signal something, or by a different program. When an interrupt event occurs, the program stops doing whatever it does and jumps to the interrupt handler (a.k.a Interrupt Service Routine – ISR). There it performs the work needed to handle the event and when it is done, the flow returns to the main program. Examples for Epiphany interrupt generators are the timers and DMA engines. With GCC 4.8 defining an interrupt handler is as easy as adding an attribute to the function definition. With the new eLib release, registering that handler with a specific event type becomes as easy as a single function call. For usage example, see the interrupt-demo example in the eSDK release.
Data transfer between shared memory and between cores is an important aspect of every parallel application. With the new eLib, we made it easier to address the workgroup members for easily sharing data, using SPMD execution model or other model. New functions use the old and faithful memcpy() style logic to copy data between cores. We made these functions look very similar to their host-side counterparts. Alternatively, the DMA functions were modified and now it is easier than ever to use the DMA to transfer blocks of data, instead of using the CPU itself. With a fix to the Parallella Prototype user’s FPGA bitstream image, it is now possible to have real blocking DMA transfers, in which the DMA is “busy” until the last transaction is written back to local memory (previously, this had to be done with a slow software protocol).
The other major component of the eSDK was not left unchanged. Because the Workgroups model was already introduced in the previous release, this time we concentrated on cleaning up some code, fixing some bugs and adding a couple more functions. With the updated eHal, the host program can can control the execution of the device’s programs. We added a function for starting a whole workgroup after the load. No need to do that one core at a time anymore. The host can now unconditionally halt a process running on a core and the resume its execution.
Command Line Utilities
The new eSDK provides a group of command line utilities for handling the Epiphany system. These are used to reset the Epiphany system, load and start programs on the cores, read and write data from and to device cores and the Epiphany external memory. These utilities make it much easier to debug and follow the flow of processes on the chip.
Obtaining the eSDK Binaries
The runtime eSDK package is provided in two versions:
1. A native eSDK intended to be used on the Parallella / Parallella Prototype systems. It contains the e-gnu toolchain, host library, BSPs and code examples for this system. The archive can be downloaded from the Parallella FTP site at:
2. A cross development eSDK, intended to be used on an x86_64 machines, includes the e-gnu toolchain, an a-gnu ARM cross compiler, for building the host (ARM) application, BSPs and examples. In addition, it contains the Epiphany Eclipse IDE for developing multicore code in an advanced and rich standard development environment. It can be downloaded from:
Obtaining the eSDK Sources
In addition, the source code repositories are available on GitHub for users who would like to build teh eSDK from source and experiment with eSDK enhancements. The repos can be found in the Adapteva page and in the Parallella project page:
We believe that with this release we made using the eSDK easier than ever. Requests for support should be addressed to the Parallella community forums. The forums are quite responsive and are populated with knowledgeable people. Let us know what you think about the eSDK. You may influence the future development of the package. Any feedback is welcome!