Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!sgi!shinobu!odin!anchor!olson
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: 4D35 VME questions.
Message-ID: <1990Nov23.210233.13417@odin.corp.sgi.com>
Date: 23 Nov 90 21:02:33 GMT
References: <1990Nov21.135845.11240@helios.physics.utoronto.ca>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 45

In <1990Nov21.135845.11240@helios.physics.utoronto.ca> chlebana@physics.utoronto.ca (Frank Chlebana) writes:
| Does the 4D/35 actually use block transfers when it is the VME master?

No, we support block mode transfers only when the VME board is the
master, as far as I can recall.  I believe this is true on all the SGI
machines.  So if you have a 'dumb' VME board, you are stuck with
PIO.  However, if you aren't doing RMW cycles, the 8 deep write
buffer may help performance if the VME board is slow.

| I would like some more technical info regarding accessing the VME adaptor.
| Since the 4D/35 is "build to support release 3.3" of system software I
| believe that the device driver will work on the 4D/35, however I want
| to be able to take advantage of any new bells and whistles.

You may need to re-compile the driver, depending on what it does, and
because of the write-buffer, you may need to assure that the write
buffer is flushed, depending on just what your driver is doing.
Any read will flush the write buffer, or you can call flushbus(),
which will do the right thing on all 4D machines.  The 4D35 doesn't
really have much in the way of new VME features, aside from the
block mode transfers and a higher VME throughput.

| Are there any hardware manuals available?

I believe that hardware documentation will be available to
Geometry Partners, and other 'qualified' developers.  I'm not at all
sure of the policy on this, so contact your local sales office.

| I noticed that the VME interface no longer sits on the system bus. Does
| this allow system bus cycles to occur while VME transfers occur? Will
| I be able to receive ethernet messages, access the SCSI disk etc WHILE
| a VME transfer is in progress?

The VME interface never was directly on the system bus on the PI; it
has always gone through a bus interface chip.  However, since there is
only one memory bus, one can't do VME transfers and other DMA or CPU
accesses to memory simultaneously.  VME traffic will be pre-empted on
the host side for CPU memory access, memory refresh (~1.2 usec), or
'system' DMA.  This does not mean that a VME card needs to re-arbitrate
for the VME bus, but it may see long DTACK cycles occasionally.
--

	Dave Olson

Life would be so much easier if we could just look at the source code.