[comp.sys.apollo] Vector Processors for ATBUS Apollos

SRFERGU@ERENJ.BITNET (Scott Ferguson) (06/05/90)

I've been working with a Mercury Systems array processor, and have lost
company support for it unless I begin using it in an IBM AT (hah).
Therefore, I might possibly look for a new product, but can't justify
spending a giant amount of dough.

Does anyone know of a vector processor product that would work in a DN4000
with peak rates of, say 10-20 MFLOPS?

Does anyone know of a board which would use the Apollo's memory instead of
having its own on-board, therefore eliminating the bus transfer bottleneck?


My last array processor was very expensive (20,000) because it had 10 MBytes
of on-board memory. For image processing, you really need it. If I could buy
a board that used the regular system memory, it'd be really nice.

Are you apollo hardware folks thinking about implementing a board with the
Intel i860 vector unit? It's really cheap & easy to implement I've been told,
and being a purely scalar architecture, your low-end machines could really
use a boost. Give 'em a longer product life (although that's not in line
with Marketing's goals).

Also, what kind of FLOPS could I expect from using a floating-point accelerator
with the vec_$ system calls? My vector board is fast, but the memory transfers
ruin the performance. If a scalar fpa board can perform reasonably well and
have no transfer bottlenecks, maybe I'll resort to that.

Thanks,
Scott Ferguson
srfergu@erenj.bitnet

hht@sarnoff.sarnoff.com (Herbert H. Taylor x2733) (06/13/90)

   This leads to an important Apollo futures question. Does Apollo
intend to support a more robust bus than ATBUS for their product line
- other then VME on a DN10000?  We host our HDTV Video Supercomputer
(a.k.a. The Princeton Engine) with Mentor Graphics CAD System running
on Apollo. The DSP90/multibus based systems we are presently using are
running out of gas. We are presently building a system for NIST and
the prospect of hosting a 29Giga Op computer through "ATBUS" is
depressing...
   Perhaps someone out there who "really" understands Apollo's
strategy could explain it to me. 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-|
|\/\/\/|                              Herb Taylor   (609) 734 - 2733   |
|      |                              David Sarnoff Research Center    |
|      |                              Subsidiary of SRI International  |
|(o) (o)                              Parallel Computing Research      |
(   >  / ----------                   CN5300                           |
 \  ~ /  <Wow! The Princeton Engine!  Princeton, New Jersey, 08543-5300|
 /   /   ----------                   email:  herbt@apollo.sarnoff.com |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-|

krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (06/13/90)

HP has repeatedly stated in public that the new 68040 machines that
are about to be released will have EISA/ISA buses available on them.
They are doing a public announcement for customers in Boston on 
June 19th (ie. less than one week from today). You should be able
to get full product literature from HP/Apollo sales office by this
time next week. As for the current product line (the DN3500/4500) ...
the CPU board has one (DN3500) or two (DN3550, DN4500) connectors
for direct access to the CPU/memory bus in the left most AT-bus
slots. This is how Apollo plugs in their floating point accelerator
(the FPA board) and the 3-D graphics accelerator boards. The boards
occupy the AT slot with the CPU/memory connector, drawing their
electrical power from the AT connector, but performing their
data access via the direct CPU/memory connector. Unfortunately,
the CPU/memory bus connection is *not* described in the "Domain
Series 3000 / Series 4000 Hardware Architecture Handbook". You
will have to work through your sales/service office to get
in touch with the hardware design group. I suspect that the
upcoming 68040 products will also have some sort of internal
CPU/memory bus which is seperate from the EISA/ISA periperal
bus. The CPU's these days are just too damn fast to be sitting
directly on a I/O bus.


 -- David Krowitz

krowitz@richter.mit.edu   (18.83.0.109)
krowitz%richter.mit.edu@eddie.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)