Path: utzoo!attcan!uunet!shakti!shri From: shri@ncst.ernet.in (H.Shrikumar) Newsgroups: comp.arch Subject: Re: The Future of Buses (and Futurebus) Summary: Phutoore baas. Message-ID: <1178@shakti.ncst.ernet.in> Date: 13 Dec 90 14:10:23 GMT References: <36734@cup.portal.com> Reply-To: shri@ncst.ernet.in (H.Shrikumar ) Organization: National Centre for Software Technology, Bombay, INDIA Lines: 77 In article aglew@crhc.uiuc.edu (Andy Glew) writes: > >The likely successor to VME is VME-64. It's simple, fast, and >available now. The likely successor to VME-64, if there is a lineal >successor, will probably involve noticing that there are extra pins on >most VME boards second connector... I was under the (evidently wrong) impression that VME-64 uses those pins! Could you drop in a brief note on the pinout please ? >FUTUREbus+'s impact will be as an I/O bus -- the profile that DEC is >pushing. The processor to memory connection is too important to be >left a standard bus, especially a standard bus that is as featureful >as FUTUREbus. (Aside: Thats funny, not very long ago when I was involved in the design of a multi-proc UNIX box (the HCL Magnum, 6x68030), we had a future-bus-like bus for the system memory access (which used those very unused pins :-), and VME-32 for I/O. The other way around!) So will all FutureBus's support for cache coherency go waste, and need to be reinvented in the "proprietary" system bus ? A pity! Do you mean ... "A standard is a formal statement of obsolesence." ? Or I think ... Looks to me, is all just a big orchestration by the manufacturers to sell more memory boards at prices they can fix ! ("No third party memory!") #1. How would high density DRAM affect design ? Will the coming of even-higher-density DRAMS see more movement of memory onto the CPU boards so that the "system bus" collapses into a bunch of PCB traces ? Then the only backplane will be for I/O, and (relatively low granularity) memory caching/sharing, both of which FutureBus is good for. #2 How would High Speed Networking affect design ? If one watches the high-speed protocol people, such as people at Uwash, St. Louis, MO, they are worrying about how to handle the guzzling I/O rates of Gigabit networking. And most solutions tend to split memory into several units, each with a high speed interface (sort of like the video-RAM chips, only these are multi-chip boards). And the most general backplane interconnect is a cross-point like one. this would alter the picture considerably, since the each board has lots of memory AND I/O, the backplane then carries only a small fraction of the load. So, will the coming of >64Mb dram+~1Gbps networking deemphasise the bus to a mere shared-semaphore-resolver ? Will Future Bus kick off in that context ? Is that what DEC has in mind (unlikely) ? May those great trapezoidal bus drivers at least survive! One thing seems likely to me, better analysis of the bus-dynamics, such as the FutureBus has done and as all ECL-nsec-squuezers always do, will be a must in future backplane designs. Thats one major first in that FutureBus, so there is future in that technology surely! BTW, how does the equiv of the bus in (for eg.) in a Y-MP compare with the FutureBus - in the departments of cache-coherence, bus-collisions/requests and raw I/O rate ? #3. Are #1 and #2 really valid ? Will all future machines have lots of memory on board ? Looks like an obvious yes to me. Will all future machines want to do High Speed I/O ? Maybe not, but design is likely to be influenced in that direction. Makes sense to put memory, CPU and I/O in one board, if density allows. How far are we looking into the future ? And how foggy is my crystal ball ? >-- >Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi] -- shrikumar ( shri@ncst.in )