Ada TAsking Coprocessor

The ATAC program overview

Table of contents

A little bit of history

When at Lund University, in summer `87, Joachim Roos made the specification, design and silicon implementation of a first version of the ATAC chip (1.0). The chip was assessed by several compiler vendors (DDC-I, Telesoft). A second version of the instruction set (for the ATAC 2.0 chip) was designed to fix the few problems detected in the first version, but most of all to include new features. The new compiler interface was evaluated by yet a different compiler vendor (Alsys), then the functionalities of this definition were tested with an Ada Sparc compiler connected to a crude software simulation model that captured the functional behaviour of the ATAC.

The ATAC simulator was then improved and expressed at more detail levels to capture the functionality even at the hardware level. The ATAC 2.0 chip was designed concurrently with the development of the simulator, and was subsequently manufactured.

The ATAC-based boards

A hardware board has been designed at ESTEC (MAT board), including a MA31750, the ATAC and 128 K of memory.

MAT BOARD

This board can be either plugged into a Personal Computer, or connected to a workstation through a serial line.

The board has an EPROM including the TLD monitor, and may be configured with external ATAC memory. The MA31750 presently runs at 10MHz while the ATAC is clocked at 20MHZ. Both components are specified to run much faster (16 and 33 MHz respectively).

For more information about the MAT board, please contact: Luca Stagnaro (luca@wd.estec.esa.nl)

The MAT board is an internal prototype, that may be given on loan if needed and according to the current availability. However, a commercial board is planned to be developed in 1996.
This board is intended to feature the MA31750 in version N, a MMU, the ATAC and a VME interface.
Its availability is foreseen in 1996.

The ATAC-based AXS Operating System

AXS intends to offer both a cyclic and a pre-emptive model build on top of the ATAC through a small assembler procedural interface. AXS benefits from the ATAC quality, e.g. the time accuracy is better, the jitter is reduced, overheads are linear with the load, etc.

AXS, offering a very secure cyclic model together with a very flexible pre-emptive model, is seen as offering a smooth transition from one model to the other, so as users get high confidence in both.

The cyclic model of AXS

The MAT board environment has been used internally at ESTEC to build a kernel executive (called AXS), based on the primitives of an existing kernel (called OX [from Trialog]). OX is a straightforward cyclic executive that offers the possibility to change mode and to switch to a recovery mode when procedures overrun their Budget Execution Time (BET). The procedures belong to groups, either an active or recovery group. An active group is run under normal conditions, whereas a recovery group runs when budget overrun has been detected. Each cyclic procedure is a subroutine which is called by OX one after the other. A timer is used to monitor the budget execution time. A timer interrupt gives the minor cycle.

The first step of the AXS development was to keep the OX requirements, while using the Ada language w.r.t. the extensions that it offers. Of course, another goal was to find an implementation using ATAC as much as possible.

A software layer was written to interface ATAC: some real-time features were thus implemented: Ada mechanisms (task creation, delay, exception, rendez-vous, accept, entry), Ada extensions (delay until, asynchronous exception), Ada constructs (select accept or delay).

Based on this layer, the OX features were implemented. The originality of it is that the cyclic procedures are not called by a scheduler. They are "autonomous" and task-like: They are created and activated as tasks, then they read their period and offset with respect to the start of the major cycle, from a global table. This table also holds the group description.

At reset, all the procedures are created in ATAC and activated, then they all read the global table, and they all sleep, except those of the appropriate active group that only delay themselves until the next major plus their own offset.

When an AXS procedure - now in the shape of a task - wakes up, it first makes a rendez-vous with a special BET manager task to make it start monitoring the time budget. Then the procedure is executed. At the end, it makes another rendez-vous with the BET manager to stop the time budget monitoring. Then it delays itself until a time computed as the previous wake-up time plus its period.

In case of an overrun, the BET manager raises an asynchronous exception to the overrunning procedure to stop it, it then changes the state of the global table to enter the recovery mode.

This first step offers a cyclic behaviour just OX-like, and with the following benefits:

Better time accuracy

ATAC handles time very precisely (125 ns resolution) and concurrently with the CPU execution. In the OX implementation, an external timer is used to cyclically interrupts the CPU to indicate the start of the minor cycle. The consequences are (i) that execution time is consumed in handling the interrupt and (ii) that a continuous clock is not available and (iii) according to the way the timer management is made, there could be a slight drift in the cycles which is avoided by ATAC..

Less jitter

When the execution time of a cyclic procedure varies according to the cycle or to the external environment, the time window in which the next procedure execute is experiencing a jitter, that prevents any synchronised action. The use of the ATAC delay_until allows the execution of a procedure at the expected moment, without any influence of the execution time of the previous procedure. This is useful to output data at a precise moment.

Linearity in overheads

Total overhead linearly increases when the number of procedures increases. Each procedure is actually associated to its BET manager, and the total number may therefore increase quickly.

Internal data saving

The internal variables of an OX procedure are not maintained out of a cycle, whereas the local data to each AXS procedure is preserved from one cycle to the other. This is due to the task-like shape of AXS procedures.

Minor cycle less significance

A classical cyclic scheduler uses the notion of a major cycle, which is the sequence that will be repeated cyclically, and the notion of minor, which is a convenient time slicing to map the procedure into. The minor cycle is very often computed as the greater common divisor to the periods of each procedure. It may be that the minor cycle is artificial (e.g. 10 ms with periods of 20 and 30) and is not linked to a physical property of the system. AXS does not need any minor definition. Only the procedures periods are given in the global table. The major cycle is kept in particular to synchronize the mode change.

Easier software maintenance

In a classical cyclic architecture, a large procedure that requires several cycles to execute must be split into slices, each called by the scheduler in a different cycle. The drawback of this approach appears when the large procedure must be modified. The designer must then also change the slicing, and possibly modify the beginning and the end of each slice.
Using AXS with ATAC allows us to keep the large procedure in a single piece, marking each cycle change with a delay_until statement. The design is made simpler. The modification of this procedure is also easier; it is no longer used to modify all the slices, but just to move the delay_until statements.

The price to pay for all these benefits is a somewhat larger overhead due to the rendez-vous and the delay_until execution; on the other hand, there is no longer a scheduler. But the overhead is considerably lower using ATAC than it would be using an Ada run- time system (about 10 times).

The tasking model of AXS

The second step was to complement the AXS specifications with tasks and sporadics. The notion of task implicitly existed, and a procedure can easily be turned into a task by removing the final delay_until next period.

At the highest priority are the BET managers, then the cyclic procedures, then the tasks and sporadics. Each task has its own priority. This prevents the cyclic model from being corrupted by the tasks.

A task can be mapped on an interrupt. ATAC takes care of the interrupts on behalf of the CPU, disturbing it only when pre-emption is necessary. Thus a cyclic procedure will never be disturbed by an interrupt mapped on a task which has a lower priority. This prevents priority inversion. The sporadics can be executed in the room left by the procedures.

Overheads in tasking management are still low because of ATAC. The number of tasks and procedures is virtually unlimited (about 31 without ATAC external memory, but 2048 otherwise) thanks to ATAC, whereas a software run-time system can slow down with the number of tasks.

AXS offers both the cyclic and the pre-emptive model, and the performance of the cyclic application is not modified by the tasks. The implementation of the tasking model with ATAC allows a very light kernel with low overheads.

AXS commercialisation

The AXS prototype has been transferred to Matra Marconi Space in Toulouse (Philippe David: david-philippe@mms.matra-espace.fr) for them to consolidate it, to complement it with some useful services derived from existing Operating Systems as Astres, etc, and to commercialize it. A free license is planned to be available for the European space industry.

The ATAC-interfaced compilers

The 1750 TLD compiler

The TLD 1750 cross compiler system has been modified to include support for the ATAC. The compiler includes a switch (-atac) that indicates whether the ATAC is used or not. When ATAC is switched on, the compiler generates Ada real-time features by way of ATAC instructions (as described in the previous section) instead of by calls to the software run-time system. The 1750 simulator includes the ATAC simulator, so that actual hardware is not needed to perform ATAC experiments. The tasking debugger is transparent to the use of ATAC, either when running on the simulator or on an actual hardware board.

The ATAC supporting compiler is commercially available. For information, please contact: TLD support (tld_ptr@cerf.net)

The 1750 Tartan compiler

The Tartan 1750 cross compiler is currently being interfaced to the ATAC. The code generator itself will not be modified, but the run-time system will call the ATAC instead of the software sub-routines. The interfaced compiler is not yet available.

The Sparc Alsys compiler

The Sparc ERC32 Thomson Software Product (Alsys) compiler is currently into development. The baseline will include the ATAC support. The availability is foreseen for March 1996 (as per November 1995).

The radiation tolerant ATAC2.1x chips

A feasibility analysis for the development of a rad-hard ATAC has been started in end 94 by Matra Marconi Space Velizy (Marc Souyri msouyri@matserv.matra-espace.fr) and R-Tech AB (Joachim Roos joachim@r-tech.se)

The complexity of chip (the equivalent of 90.000 gates including ROM and RAM blocks) put the ATAC at the border of the capability of most of the European rad-hard technologies, therefore leading to a too high risk.

It is now planned to use the MHS MG RT gate array family (0.6 micron process, latch-up free, total dose > 30 kRads) to develop the chip. However, this technology being SEU sensitive, the design will be complemented with SEU protection structures (as for the ERC32).

The availability of the chip is planned for end 1996 or early 1997.

The new ATAC2.1 chip will include selected Ada95 support. From the hardware point of view, it will be bus interface signaling and logic levels backwards compatible. The interface with the compilers will be compatible.

Various other activities

ATACable Ada

The goal of the activity is to build a board including a SPARC and the ATAC, then to evaluate an application (ASDMS: Autonomous Software Data Management System) on it. At the time of the beginning of the study, there was no ATAC supporting compiler available for the SPARC. Therefore the Ada code of the ASDMS software has to be ported on the ATAC through a procedural interface (AXS-like).

The translation of the original Ada code was made a little more systematic, and a method is going to be proposed to translate Ada code into "ATACable" Ada code. It is based on the translation of a task into a procedure, the definition and calls to the entries becoming calls to an ATAC package encapsulating the ATAC procedural interface.

The interest of this method is to be compiler-independent.

Information may be obtained from LABEN 20090 Vimodrone (Milan) Italy: (F. Battini (battini@sparc1.laben.it)

LOTOS specification of the ATAC

This activity intend to exercise the abstract behavioural formal language LOTOS with the ATAC chip. A LOTOS specification of the ATAC is to be produced. From that specification, a method is going to be defined to derive in an automated manner some LOTOS conformance tests. The tests will be executed in a LOTOS simulator. The test will be applied concurrently to the ATAC chip, and the behaviour of the LOTOS specification and of the ATAC chip will be compared. For more information about this activity, please contact CRISA, PTM Tres Cantos 28760 MADRID (Spain) (Fermin Catalan (fcatalan@crisa.es)

ATAC USER GROUP Want to join the ATAC user group mailing list to listen and discuss the latest ATAC news? Then send a request to jeanloup@wd.estec.esa.nl.
Home Return to the ATAC page.
Jean-Loup TERRAILLON (jeanloup@wd.estec.esa.nl)

Last edited 28 November 1995

DISCLAIMER

All information is provided "as is", there is no warranty that the information is correct or suitable for any purpose, neither implicit nor explicit.

This information does not necessarily reflect the policy of the European Space Agency.

COPYRIGHT 1995 EUROPEAN SPACE AGENCY. ALL RIGHTS RESERVED.

This article may be redistributed provided that the article and this notice remain intact. This article may not under any circumstances be resold or redistributed for compensation of any kind without prior written permission from European Space Agency.