From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f849b,167419cb5887cd4c
X-Google-Attributes: gidf849b,public
X-Google-Thread: 103376,5495dac456fa22ef
X-Google-Attributes: gid103376,public
X-Google-Thread: 115aec,5495dac456fa22ef
X-Google-Attributes: gid115aec,public
From: Ken Keys <klkeys@west.raytheon.com>
Subject: Re: Processor Synchronization
Date: 1999/01/20
Message-ID: <36A65D72.EDED6643@west.raytheon.com>#1/1
X-Deja-AN: 434990722
Content-Transfer-Encoding: 7bit
References: <36A509DB.95F62C0B@pwfl.com> <36A51F3A.2207F91@west.raytheon.com>
 <36A602E0.DA6E298F@pwfl.com>
Content-Type: text/plain; charset=us-ascii
Organization: Raytheon Missile Systems
Mime-Version: 1.0
Newsgroups: comp.lang.ada,comp.realtime,comp.arch.embedded
Date: 1999-01-20T00:00:00+00:00
List-Id: <comp.lang.ada>

Marin David Condic wrote:
 > 
 > Ken Keys wrote:
 > >
 > > How did you do it when did it in-house? Did you use an RTC or some
other
 > > common (hardware) time reference?
 > >
 > We have a cross channel sync discrete that enables the two processors
to
 > signal each other. Each processor has a watchdog timer that ticks off
 > 1ms interrupts to drive the software and the wdt outputs a
 > synchronization signal at 12.5ms intervals (programmable, of course,
but
 > this is what we use.) The wdt has a restart feature used for
 > synchronization. So it becomes a matter of each channel looking at
the
 > other guy via the discrete to determine when he is in his 12.5ms
frame
 > and agreeing on who will reset so that they are both in the same
frame
 > at the same time. That gets you into coarse sync. From there, you've
got
 > to execute small delays with a real time counter so that both
channels
 > are at the leading edge of the 12.5ms signal at the same time. Then
 > you've declared you are "in sync" and the system initialization can
 > continue on to control active mode. Periodically in the course of
 > operation, you've got to make fine tuning adjustments to keep
yourself
 > in fine sync. This is again a matter of both channels signaling each
 > other via the sync discretes.
 > 
 > What I am curious about is if anybody has done any study of
algorithms
 > for this sort of synchronization. I imagine there are methods of
doing
 > synchronization by sharing opinions about what time it is or with
other
 > sorts of semaphore setups and so on. (I know in the radio business
 > you've got to account for propogation delays and other problems if
you
 > want the radios to sync up. Someone might have some studies of this
sort
 > as well.)
 > 
 > What I'm hoping to do is explain to my class what it is that we do
now
 > for this sort of channel synchronization and then present some
 > alternatives which might be used in future designs. Would we be
better
 > off if we got our hardware built with a time-of-day clock and traded
 > opinions on what time it is? Are there other algorithms that work
better
 > at getting things in sync faster and keeping them in sync with less
 > waste of CPU time? (delays are bad news when you're running real slow
 > processors and have a 1ms cycle time!) In other words, is someone out
 > there more clever than ourselves?
 > 
 > If you know of any references or sources of information, I'd
appreciate
 > hearing about them. Thanks.
 > 
 > MDC

I have never seen multiple processors coupled that closely. Usually,
processors are tied to some external event through interrupts or
whatever. Where the events themselves are unavailable, the input data
are given a timestamp that is referenced to some common clock--not
necessarily a time of day clock. Sometimes this timestamping requires
you to do some interpolation to get the data to line up as in, for
instance, the case of merging information from a Radar sensor with that
from an IR sensor where there are different amounts of processing delay
and differing update rates. Besides, if the data is coming from
something like a video raster, deciding just where in the elapsed time
covered by that raster the data occurs requires some interpretation.

Are your processors in some kind of redundant voting arrangement where
they are executing the exact same code on the same inputs? If so, that
probably represents a fairly specialized case. You might be able to find
some information on that type of case in some NASA pubs.

KLK