Control plane interface

[fmotta]

I have seen some tailored code examples for the simple case of matrix processing and a hello world app for the parallella cores. Please provide some documentation on how the control plane (ARM) processor(s) interact with the parallella.

- Is the parallella a look-aside ?
- Is it available tot he ARM over a standard bus?
- Does it emit interrupts to the ARM or doorbell-like interface?
- Does the ARM have to poll an address?
- Can I load the applications via the ARM?
- Can I load my own chosen program per core via the ARM?
- Do I need to write my own loader/ELF parser?
- ???

[aolofsson]

[fmotta]

[fmotta]

Oh - and yes - The common memory map with fixed address spaces for each of the E-core made it evident that there is no chance of a "secure" application. A friend asked about virtualization and I chuckled.

[ysapir]

@fmotta,

As of now, the Parallella (actually, its prototype system) was only tested running Ubuntu Linux. It is not impossible that other Linux distros will be compatible with this machine, but we do not plan to test that in the very near future.

The loader can act in a couple of modes. One is to load each core with its own image. The second is to load in "broadcast" mode, where the same image is being loaded on all cores (obviously, you can achieve the same by manually loading the same image on selected cores).

The loader source code, as well as the rest of the eSDK will be provided later on.

It is possible (though, with a performance penalty) to fetch instructions from a neighbouring core's SRAM, as well as from DRAM (with even bigger penalty). You can write your programs in a core-agnostic manner (or "relocateable" if you wish) such that any dependency on the core ID is resolved using run-time querying of the ID via the e_coreid() API. As long as you make sure that the data space remains separated you should be OK to go.

[fmotta]

[ysapir]

[fmotta]

[ysapir]

It is not the Linux loader that is loading the chip with the images. The Epiphany loader is a callable API (callable by the host, that is) that merely copies a binary image onto the chip cores. You build your image using the Epiphany compiler and linker, linking your code modules with whatever runtime library required for your application (newlib, eLib, etc.) and the CRT0. The linking is static, as we don't support shared objects on the chip (b/c we don't run an OS). Thus, the resulting binary (.elf executable) contains all the code it needs to run the program, placed, by the linker, in its final address locations (on a core's SRAM, using local addresses, or outside of a core, on another core or DRAM, using global addresses).

This binary is all you need to run a program on the chip. So, the e-loader copies this binary to the chip, considering the target core, and optionally runs the program by sending the special interrupt signal. To make it clear - the e-loader does not do any manipulation on the binary image (other than change its global address prefix, to direct the data to the desired core).

As of now, the Parallella architecture is comprised of the ARM running Linux, which "sees" the general purpose DRAM space (used by Linux). Then, there is the Epiphany chip that has its dedicated DRAM space (ERAM). This ERAM is not seen or used by the Linux, in a manner equivalent to graphics GRAM on graphics boards.

The host can access the ERAM similar to the way it can access other memory-mapped devices. That is, you need a driver or other means to "get out" of the Linux virtual memory space. For this we have the e-host API, which serves as the Epiphany driver. The Epiphany is limited to accessing the ERAM. It cannot signal the host in any way other than share a memory mailbox in ERAM or its SRAM. It is the host's responsibility to poll this mailbox.

[fmotta]