Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!itivax!umich!crim.eecs.umich.edu!projoe
From: projoe@crim.eecs.umich.edu (Joseph A. Dionise)
Newsgroups: comp.realtime
Subject: Re: Shared memory with multiple processors running VxWorks
Keywords: VxWorks/multiple processors/ shared memory
Message-ID: <311@zip.eecs.umich.edu>
Date: 11 Sep 89 07:05:28 GMT
References: <4252@ncar.ucar.edu>
Sender: news@zippy.eecs.umich.edu
Reply-To: projoe@crim.eecs.umich.edu.UUCP (Joseph A. Dionise)
Organization: University of Michigan EECS Dept., Ann Arbor, MI
Lines: 41

In article <4252@ncar.ucar.edu> vanandel@ncar.ucar.edu (Joe Van Andel) writes:
>I am working on a real-time radar signal processing system that will
>use multiple 68020 processors running VxWorks on a VME backplane.
>As I read the manual, I conclude that VxWorks
>doesn't provide facilities for managing shared memory or semaphores
>between tasks executing on different processors.  

   The support is there for "low-level" communication between processors
using shared memory.  We recently setup a shared-memory buffer between 
a pair of 68020's (MVME-133A) and a single 68030 (MVME-147A).  I'll 
outline our setup.

   A single 68020 has a 64K segment (excuse the Intel slip) of 
shared memory located at the upper bounds of its onboard memory.
We tricked vxWorks into not using this memory by modifying the
sysMemTop routine (in sysLib.c) to return the total amount of 
onboard RAM minus the amount of shared memory.  Specifically, 
sysMemTop returns 0x0f0000 = 0x100000 - 0x010000.  This cpu sets 
up the shared memory data structures, initializes the semaphores, 
etc.  We used a very simple queue in the shared memory.  In this 
case, we guarded reads from the queue and writes to the queue, 
since both are destructive.  The other processors use the sysBusTas 
routine to perform a test-and-set across the bus on the global 
semaphores.  If they "win", then reading/writing to the queue takes 
place. 

Our boards enable the RMW (Read-Modify-Write) sequence through the 
use of jumpers (68020) and software (68030).  Hence, the sysBusTas 
routine is really just a call to the 68K tas instruction.  Note
that a cold boot will zero all of the onboard memory (including
any shared memory segments).  If this is not acceptable, then 
the assembly routine romInit must be modified.


################################################################################
#  Joseph A. Dionise                                                           #
#  Robot Systems Division    Internet : projoe@crim.eecs.umich.edu             #
#  University of Michigan    uucp : {..}!umich.uucp!crim.eecs.umich.edu!projoe #
#  1101 Beal Avenue          BIX  : jdionise                                   #
#  Ann Arbor, MI 48109       (313) 936-2830                                    #
################################################################################