Re: MISC-d Digest V99 #87
- To: theFox@xxxxxxxxxxxxxxxxxxx
- Subject: Re: MISC-d Digest V99 #87
- From: Christophe Lavarenne <Christophe.Lavarenne@xxxxxxxx>
- Date: Wed, 1 Sep 1999 17:41:34 +0200 (MET DST)
- CC: MISC, dsp-clusters@xxxxxxxxxxx
- In-reply-to: <199909010945.EAA07380@rgate2.ricochet.net>(theFox@UltraTechnology.com)
- Reply-to: Christophe.Lavarenne@xxxxxxxx
Jeff,
>If you have something that has functions of distributed shared memory
>in hardware I would think you would want to try to remove extra software
>layers to boost performance.
To remove extra software layers, you don't even need to haved distributed
shared memory in hardware with SynDEx (http://www-rocq.inria.fr/syndex),
distributed memory with any support for interprocessor memory transfers is
enough.
From your specification of your application algorithm and architecture,
and from measured characteristics of the algorithm components (computations)
relative to the architecture components (processors and communication media),
SynDEx tries its best to distribute and schedule computations over the
processors, while distributing and scheduling communications over the
interprocessor communication media. If the resulting predicted global
performance matches your requirements, SynDEx then generates a SYNchronized
Distributed EXecutive (hence the SynDEx acronym).
Instead of relying on layers of separately compiled resident executives,
SynDEx generates for each processor a generic macrocode controlling static
memory allocation, and static sequencing and synchronization of computations
and communications. This macrocode is then macroprocessed to be substituted
with processor specific assembly instructions directly accessing hardware
registers for best performance.
For example, on the TMS320C40, the total overhead for completely handling an
interprocessor communication, including the programmation of the DMA and 4
context switches between the computation sequence and the communication
sequence (2 for go programming the DMA and return, and 2 for servicing the
end-of-transfer interrupt and return), is only 51 instruction cycles.
When we are less concerned with speed, as when distributing an application
on a network of workstations without taking control of the bare metal over
Un*x, the macrocode is substituted with C (or any other high level language,
would you like to change basic macrodefinitions) and relies on the resident
operating system (processes, semaphores, TCP/IP sockets).
SynDEx has been used successfully for programming the CyCab, a small electric
vehicule (http://www-lara.inria.fr), with seven processors (one mc68332 for
each four wheel electric motors, one mc68332 for the steering electric jack,
one i80c196 for the front linear camera, and one i80386 for booting the other
processors and for driving a touch screen), a CAN fieldbus connecting the five
mc68332 and the i80386, and an RS232 connecting the i80c196 and the i80386.
Each mc68332 executes motor-control interrupts at 1KHz, and the vehicule
control algorithm is executed at 100Hz, which computations are distributed
among all processors, which means that several interprocessor transfers are
executed every 10ms. This is heterogeneous hard real-time.
CL
--
email: Christophe.Lavarenne@inria.fr tel: +33(0)1.39.63.55.80
http://www-rocq.inria.fr/~lavarenn fax: +33(0)1.39.63.57.86
INRIA, Domaine de Voluceau Rocquencourt Institut National de Recherche
B.P.105 - 78153 LE CHESNAY CEDEX FRANCE en Informatique et Automatique
SynDEx, CAD tool for distributed, embedded, optimized real-time applications:
http://www-rocq.inria.fr/syndex (multi-workstation/DSP/microcontroler/CAN...)