Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!sdd.hp.com!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!psuvax1!rutgers!mcdchg!heiby
From: heiby@mcdchg.chg.mcd.mot.com (Ron Heiby)
Newsgroups: comp.sys.m88k
Subject: Re: Request for help: Location Monitors on the Motorola MVME188 board
Message-ID: <54562@mcdchg.chg.mcd.mot.com>
Date: 16 Jan 91 20:57:46 GMT
References: <54451@mcdchg.chg.mcd.mot.com> <2026@inducom.UUCP>
Organization: Motorola Computer Group, Schaumburg, IL
Lines: 44

meindert@inducom.UUCP (Meindert Kuipers) writes:
>That would be very bad practice. It might take a LOT of microseconds before
                                     ^^^^^
If this is a real-time environment, there shouldn't be any "might"
about it.  You should know exactly how long your bus timer is set.  If
it is set too long, you should set it shorter.  Further, this
mechanism is generally used only for synchronization of the system.
This typically happens only occasionally.

>the bus timer generates BERR*. Thus, it does not make these boards very
>useful in a real-time environment. very difficult writing the software.
Many of our customers would disagree.  Of course, any time you are
writing software for a multiple CPU system, there are complications
and considerations that do not exist in single CPU systems.

>Also, a lot of CPU-boards are not capable of doing address-only cycles.
>A true address-only cycle does not lead to a BERR*, because the cycle is
>terminated after a certain period.
I don't understand what this has to do with it.  You don't need to do
an address-only cycle with our method, so it doesn't matter that a lot
of CPU boards cannot do them.

As I see it, a location monitor like the one we implement, where
accessing the monitored address leads to a BERR* condition is the only
way to get multiple cpus synchronized.  Let's say that you really
didn't like the BERR*.  If you tried to eliminate it by having the
boards respond to the cycle, then you would potentially have multiple
boards trying to respond.  This is also a BERR* condition.  Maybe you
set it up so that just one board responds.  Now you've got a heck of a
configuration management problem on your hands.

There are other mechanisms available for interrupting specific boards,
depending on exactly which boards you have configured into your
system.  For example, the MVME147S family has bits in its global
control/status registers which (when set from the VMEbus) will
generate an interrupt to that MVME147.  If you don't like or
understand a feature of the board, use one of the other features of
the board that you like or understand better.

BTW, the choices for VMEbus global timer (for BERR* reporting) on the
MVME147S family are 102, 205, or 410 microseconds, or timer disabled.
-- 
Ron Heiby, heiby@chg.mcd.mot.com	Moderator: comp.newprod
"Give me voice mail or give me drugs!"/"Mandatory Drug Testing? Just Say NO!!!"