comp.lang.ada
 help / color / mirror / Atom feed
From: Marin David Condic <condicma@bogon.pwfl.com>
To: Ken Keys <klkeys@west.raytheon.com>
Subject: Re: Processor Synchronization
Date: 1999/01/20
Date: 1999-01-20T00:00:00+00:00	[thread overview]
Message-ID: <36A602E0.DA6E298F@pwfl.com> (raw)
In-Reply-To: 36A51F3A.2207F91@west.raytheon.com

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
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Airplanes are interesting toys but of no military value."

        --  Marechal Ferdinand Foch, Professor of Strategy, Ecole
Superieure
            de Guerre.




  reply	other threads:[~1999-01-20  0:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-01-19  0:00 Processor Synchronization Marin David Condic
1999-01-19  0:00 ` Ken Keys
1999-01-20  0:00   ` Marin David Condic [this message]
1999-01-20  0:00     ` Ken Keys
1999-01-21  0:00       ` Marin David Condic
1999-01-21  0:00     ` Sune Falck
1999-01-21  0:00       ` Marin David Condic
     [not found]     ` <36a83fe3.3666942@news.geccs.gecm.com>
1999-01-22  0:00       ` Marin David Condic
1999-01-20  0:00 ` dennison
1999-01-21  0:00 ` The Bohemian Monk
1999-01-21  0:00   ` Marin David Condic
1999-01-22  0:00     ` Tom Ziomek
1999-01-21  0:00 ` Peter Jensen
1999-01-22  0:00 ` Al Mok
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox