Overview
Prev Chapter 361. TILE-Gx Architectural Support Next

Name

Overview — eCos Support for the TILE-Gx Family of Processors

Description

This package CYGPKG_HAL_TILEGX provides architectural HAL support for running eCos aplications on a Tilera TILE-Gx processor. In many ways this is a very unusual architecture for running eCos, and therefore the TILE-Gx eCos port is also somewhat different from ports to other architectures.

This section of the package documentation gives a brief description of the TILE-Gx hardware, how it is typically used, and the main limitations of the eCos port. Later sections describe the process of preparing hardware for running an eCos application, the various configuration options provided by the port, and some of the implementation details.

The Hardware

A TILE-Gx chip contains of an array of CPU cores, known as tiles. It also contains a set of memory interfaces and I/O peripherals. The cores, memory and peripherals are connected via a mesh interconnect. One of the peripherals, USB, can be used to connect the TILE-Gx chip to a host PC for software development.

Each tile is a fully-fledged and fairly conventional CPU, aimed at running an advanced operating system like Linux. It has a register bank of 64 64-bit registers, some of which have a dedicated purpose such as communication over the mesh network. There are also a considerable number of special purpose registers or SPRs. Many of these are intended for system software, for example to control the memory management unit and the interrupt subsystem.

Each tile has a split instruction/data primary cache and a secondary cache. The hardware also implements a distributed tertiary cache over the mesh interconnect. Assuming the MMU is set up correctly on each tile the hardware will maintain cache coherency. Shared memory can be used for exchanging large amounts of data between tiles. The mesh interconnect also provides two buses, the I/O Dynamic Network or IDN and the User Dynamic Network or UDN. These allow the transfer of fairly small packets, up to a couple of hundred 64-bit words of data, between tiles.

On power up the hardware runs a hypervisor boot image, typically loaded from a serial ROM although alternative images can be loaded from a host PC over USB. Usually the hypervisor proceeds to run an SMP Linux kernel on all the tiles, and applications run as processes on top of Linux in a protected environment. The kernel runs on top of the hypervisor, and control over the various peripherals and memory resources is shared between the two in complicated ways. It is possible to partition the chip's tiles such that Linux only runs on some of them, while others run a bare metal executable or BME application. A BME application replaces the hypervisor and runs with full access to the hardware. The eCos port uses this functionality to run eCos applications on some of the tiles.

Limitations

The eCos port to the TILE-Gx architecture is subject to some important restrictions, and application developers should be aware of these.

  1. At the time of writing eCos does not provide full SMP functionality. It is possible to run eCos applications on multiple tiles at the same time, but these tiles all run their own private instance of eCos. Each tile is allocated its own private memory. Once the eCos applications are running on the various tiles they can communicate over the UDN bus or over shared memory, and they can also communicate with Linux processes running inside the Linux partition. The TMC support package CYGPKG_HAL_TILEGX_TMC in packages/hal/tilegx/tmc provides some support code for this, and more importantly some detailed examples.
  2. Also at the time of writing eCos does not support operating in 64-bit mode. In practice this is not a major problem. Although TILE-Gx is a 64-bit architecture the instruction set provides full support for running in 32-bit mode, and tile-gcc has a -m32 flag to support this. Running in 32-bit mode should have no detrimental effect on performance. In fact it may improve performance very slightly because pointers in data structures will consume less memory, allowing more data to fit into the caches and reducing the memory bandwidth requirements. The main restriction is that the address space of an eCos application is limited to two gigabytes (it should be four gigabytes but tile-gdb appears to get confused at times when dealing with 32-bit pointers with the top bit set).
  3. The eCos ports depends on various bits of Tilera software. The port has been performed with the TileraMDE-4.1.0.148119 release of the Multicore Development Environment. If there are incompatible changes to the MDE, for example if the hypervisor code for loading and starting a BME application is rewritten, then such changes could stop the eCos port working in strange ways. The TMC package's examples for setting up shared memory between a Linux process and an eCos application are also particularly vulnerable to breakage given the rapid rate of development of the Linux kernel.

  4. The Tilera support for BME applications is limited. That means that sharing resources between the Linux partition and BME tiles running eCos is generally difficult, and at times may be impossible. For example there is no easy way for eCos to allocate additional physical memory: after bootstrap all unallocated memory belongs to the Linux partition and the hypervisor. If more memory is needed then the allocation has to be performed by a Linux process and the details of the allocation can then be passed on to the eCos application, allowing the latter to map the memory into its address space.

    Particular difficulties are likely to arise when it comes to peripherals. Sharing a peripheral between an eCos application and a Linux device driver will typically be impossible: the latter will not have been written to allow sharing, and any spinlocks or other locking mechanisms that may exist will not be accessible to an eCos application.

Prev Up Next
Chapter 361. TILE-Gx Architectural Support Home Hardware Setup