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.