chlebana@physics.utoronto.ca (Frank Chlebana) (11/22/90)
The glossy spec sheet for the 4D/35 says that block mode transfers are supported on the VME interface. We are currently using the 4D/25S to read data from an external VME crate into the SGI. The SGI uses programmed IO to transfer data from the interface board to memory. That is, cpu registers are loaded with the data from the VME address, then stored into the user virtual address. During the transfer the cpu is unavailable for computation. Ideally what I would like is to have a DMA controller handling the transfer. Does the 4D/35 actually use block transfers when it is the VME master? How do you specify that you want to use block transfers, a different address range, load a register or what? Do I still have to use PIO on the 4D/35 or does it have DMA capability when it acts as the VME master? Is the cpu free to do work while the transfer is in progress (SGI is the VME master). 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. Are there any hardware manuals available? 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? Please send helpful information to chlebana@oldkat.physics.utoronto.ca Thanks. Frank Chlebana University of Toronto Dept. of Physics 60 St. George Street Toronto, Ontario. CANADA M5S 1A7
olson@anchor.esd.sgi.com (Dave Olson) (11/24/90)
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.