Simple FIFO communication between cores of Epiphany architecture.
If you are interested in using this communication library in your hand crafted or generated code, you only need to look at
master branch, which
(should) holds the latest skeleton of the communication library, with some synchronization boilerplate.
Epiphany SDK version
This repo (building process) assumes you are using the SDK which contains
e-loader command (older approach). There's no support for the new SDK yet.
No idea how the com library is affected by this.
How to use this library on Epiphany
According to the name of this repo, one should not be surprised that this library is developed using Epiphany as the medium. (So far, it's the only architecture this library runs on.) I will provide some info how it's used on Epiphany, which, hopefully, could shed some light on how to port it to some other architecture.
board: This folder contains the code specific to Epiphany. Inside it, each folder is name as
core[coreid], for Epiphany requires one dedicated
ELFfor each core.
coordinates.cis responsible for providing identity for each core (kind of reflection).
main.cprovides the entry for the code running on the core. Since dynamic memory management is too expensive to have on Epiphany, it's expected that in
main.c, all the input/output ports are declared statically so that com library would only do some pointer manipulation.
src/util: This folder contains some utilities that you might find it usable. Some of them is tied to Epiphany, for example
common.cis shared by all the cores on Epiphany to reduce the duplication in each core by using
Single Program Multiple Data(SPMD).
src/actors: This com library is developed for running CAL (one dataflow language) on Epiphany, so this folder is here for holding the code for actors, which provides blueprint for creating instances (just class in some OOP languages). This organization could get rid of a lot of code duplication; how much this matters is only personal opinion.
host: The host is preparing input data and fetching output data, with optional comparison with expect output. What host does is quite subjective, and it's one open question (maybe depending on the application) what logic shoud be placed here.
How to run it on Epiphany
In the ideal case,
make itself is enough, which performs the following steps in sequence:
- Build code for the chip.
- Loading the program to the chip, and run it.
- Build code for host.
- Running the program for host
In order to achieve isolated environment for every application, I create one branch for each app. In addition, there are some auxiliary branches as
well, which is why there are quite a few branches in this repo. Don't worry, for most of them are there merely for debugging purposes. The branches
that you might be interested in are
fir. The following is one very brief introduction to each of them.
idct2d: 2D-IDCT with 64000 input data samples
fir: The three apps all have the same connection pattern; the only difference lies on the operation each actor performs, namely, dot product, FFT, FIR (special dot product), respectively.