robertb@june.cs.washington.edu (Robert Bedichek) (01/14/91)
The documentation from Motorola mentions these things, but doesn't say how to use them or exactly what they do. I guess they are some sort of memory breakpoint facility built outside of the MC88100/88200 chips. But the documentation also suggests that this facility only works with VME accesses. Could someone tell me more about this? Has anyone used this hardware facility? Thanks in advance, Robert Bedichek robertb@cs.washington.edu
michael@mcdchg.chg.mcd.mot.com (Michael Bodine) (01/15/91)
Robert Bedichek (robertb@june.cs.washington.edu) writes: > The documentation from Motorola mentions these things, but doesn't say > how to use them or exactly what they do. I guess they are some sort of > memory breakpoint facility built outside of the MC88100/88200 chips. > But the documentation also suggests that this facility only works with > VME accesses. > Could someone tell me more about this? Has anyone used this hardware > facility? The location monitor implements the "Address-only" cycle on the VMEbus. It's a quick way to communicate an event or an interrupt when no resource is available, say, on a peripheral board to do so. A quick functional description: a device wants to notify the 188 of some sort of event -- usually the exact message would be stored in some location per the software design of the application. The device would access the address of one of the location monitors on the 188; this address is determined by the setting of the Global Control and Status Register per table 3-12 in the 188 manual (MVME188/D1). This access would invoke the Location Monitor Interrupt (LMI) the state of which is reflected in the Interrupt Status Register detailed in table 4-3. An interrupt is generated and the actual location monitor that was accessed would be shown as a bit in the "GLOBAL0" GCSR, table 4-11. The interrupt handler would then reset the interrupt bit and go grab the message or otherwise take note of the occurence of this event. Also, the location monitors can be set up to reside at the same locations on groups of 188 boards so that events can be quickly broadcast to more than one cpu without having to access multiple registers, ie. for purposes of synchronization. I'm sure there are other uses you could make up. -- [ Michael Bodine, michael@chg.mcd.mot.com, Dial: (708) 576-7840, FAX: x8875 ] [ Motorola TSD; Loc IL38; 1100 Woodfield; Suite 334; Schaumburg, Il 60173 ]
heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) (01/15/91)
I think Michael didn't mention one thing that some of my 68K customers have run into when using location monitors. That is that the board that is the target of the LM access, the one that is about to enter an interrupt routine, does *NOT* respond to the VMEbus cycle. The board that makes the access to trigger the LM must be prepared for a bus error (BERR) on that cycle. -- Ron Heiby, heiby@chg.mcd.mot.com Moderator: comp.newprod "Give me voice mail or give me drugs!"/"Mandatory Drug Testing? Just Say NO!!!"
meindert@inducom.UUCP (Meindert Kuipers) (01/15/91)
From article <54451@mcdchg.chg.mcd.mot.com>, by heiby@mcdchg.chg.mcd.mot.com (Ron Heiby): > I think Michael didn't mention one thing that some of my 68K customers > have run into when using location monitors. That is that the board > that is the target of the LM access, the one that is about to enter an > interrupt routine, does *NOT* respond to the VMEbus cycle. The board > that makes the access to trigger the LM must be prepared for a bus > error (BERR) on that cycle. That would be very bad practice. It might take a LOT of microseconds before the bus timer generates BERR*. Thus, it does not make these boards very useful in a real-time environment. very difficult writing the software. 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. ------------------------------------------------------------------------------- +-----+ Inducom Systems B.V. | < Raadhuislaan 27 NL - 5341 GL Oss, Netherlands | o | P.O. Box 627 NL - 5340 AP Oss, Netherlands | INDUCOM SYSTEMS Phone: (31)-(0)4120-41922 +-----+ Fax: (31)-(0)4120-22640 Specialists in OS-9, VMEbus and G-64 Meindert Kuipers, Inducom Systems B.V. UUCP: meindert@inducom.UUCP ...!uunet!mcsun!hp4nl!inducom!meindert -- Coming soon to a VMEbus system near you: VMEtro BusBusters -- -------------------------------------------------------------------------------
heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) (01/17/91)
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!!!"
heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) (01/19/91)
fsset@bach.lerc.nasa.gov (Scott E. Townsend) writes: >What is a little puzzling to me is that the manual makes the point that >accesses to a location monitor address will NOT generate a DTACK. They imply >that the bus timeout mechanism will take care of the problem. ANSI/IEEE Std 1014-1987 (VMEBus) says in 2.3.4 and its Figure 8 that no DTACK is generated. In the text, just before Rule 2.17, is the text: "A third type of module, the location monitor, monitors the data transfer and generates either, or both, of two on-board signals whenever a byte location that it monitors is accessed. ... When the cycle takes too long, a fourth module, a bus timer, intervenes by driver BERR* low, completing the data-transfer handshake, and allowing the bus to resume operation." I find the standard somewhat difficult to read and was not able to find the other information I was looking for, the exact section that declares it illegal to have multiple slaves set up to respond to a single access. Since I cannot find it, I suppose it might be allowed, but I *really* doubt it. Even if it were, since VME is an asynchronous bus, it would be possible for a fast board to have responded to such an access before other (slower) boards recognized the access taking place. -- Ron Heiby, heiby@chg.mcd.mot.com Moderator: comp.newprod "Give me voice mail or give me drugs!"/"Mandatory Drug Testing? Just Say NO!!!"