Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/13/84; site intelca.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!pesnta!amd!intelca!kds From: kds@intelca.UUCP (Ken Shoemaker) Newsgroups: net.micro.68k,net.arch Subject: Re: Re: x86/68x buses Message-ID: <9@intelca.UUCP> Date: Mon, 1-Jul-85 14:05:08 EDT Article-I.D.: intelca.9 Posted: Mon Jul 1 14:05:08 1985 Date-Received: Thu, 4-Jul-85 00:28:16 EDT References: <344@osu-eddie.UUCP> <600@intelca.UUCP> <2275@sun.uucp> <611@intelca.UUCP> <2306@sun.uucp> Organization: Intel, Santa Clara, Ca. Lines: 50 Xref: watmath net.micro.68k:984 net.arch:1522 > I think the 68020 drives the address of prefetches (if there's not > already a cycle on the bus) but will not assert address strobe if it > hits the cache. AS doesn't come out until the addresses are stable > anyway, so the cache lookup is overlapped with the address driver > propagation delay (and setup time on whoever's receiving the > addresses). Serious MMUs start to translate the address before AS > anyway, so it actually helps to not have to latch the address, since regardless of the timing of the address strobe, you really can't start looking up addresses for either your cache, or for your MMU until the addresses are guaranteed stable on the address bus, or have I missed some major advance in non-deterministic logic? > In a 180ns memory cycle it's VERY hard (both for CPU and for memory > subsystem) to run with Ken's proposed 170ns addr->data times. It's > clear that the 68020 can access memory faster than dynamic ram can > respond. There are plenty of solutions developed for mainframes (which I agree that it is not the easiest thing in the world to build a 170ns memory system. I would think that it is obvious that it is even more difficult to build a system that allowed only 115ns to do the same thing... > have had the same problem for a long time); the on-chip instruction > cache is one of them. Ken's overlapping technique may be one that the > 68020 design precludes. Got any stats on how many 286 designs use the > technique, and how much time is really saved (e.g. is addr->data really > the bottleneck)? I don't know how many 286 designs actually use the technique of running two memory cycles at the same time (although the 8207 DRAM controller supports doing this), but my main point was that by providing addresses earlier in a bus cycle (i.e., before the bus cycle even begins!) that you gain the address bus drive time (from the CPU) in the address to data time, since once in the bus cycle, you don't have to wait for the CPU to drive the capacitive loads on the address pins. Although addr->data may not be the ONLY bottleneck in a system, it is a very significant one, and by providing more of it while running the bus at the same speed you can't help but get a faster system, since the alternative is to add wait states. -- ...and I'm sure it wouldn't interest anybody outside of a small circle of friends... Ken Shoemaker, Microprocessor Design for a large, Silicon Valley firm {pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds ---the above views are personal. They may not represent those of the employer of its submitter.