Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!hplabs!hpda!hpcupt1!hpsal2!markw
From: markw@hpsal2.HP.COM (Mark Williams)
Newsgroups: comp.arch
Subject: Re: Re: Criteria ... [really: California & Texas slug it out]
Message-ID: <2280006@hpsal2.HP.COM>
Date: 24 May 89 17:29:41 GMT
References: <20210@winchester.mips.COM>
Organization: HP System Architecture Lab, Cupertino
Lines: 36


  les@unicads.UUCP (Les Milash) wrote:

> In the midst of a lively debate, folks started talking about:
> >>Consider that the 25Mhz R3000 requires two bus transactions per clock 
> >>cycle, effectively running the bus at 50Mhz.
> in the interest of educating ME, what's a "bus transaction"?

> my guesses are:

> perhaps some bus that's common for R3000s is multiplexed, sending
> addr and data in two wads, and so it means the time it takes signals to 
> travel and be latched, although multiplexing the bus in a fast box seems
> nuts.
> [stuff deleted]

> in other words, is a bus "transaction" any more exalted a thing than a
> bus "cycle"?

> Les

The MIPS R2000 CPU has on-chip cache control and talks directly to two
off-chip caches (I and D).  The cache address lines go to both caches,
with the I cache address appearing on one clock phase and the D cache
address on the other (latches hold the addresses).  This was done to
save I/O pins on the CPU.  As I recall, the cache data busses are
separate (but I could be wrong - it's been 3 years since I looked at this
in detail).  

Obviously, these are not bus transactions between processor and main memory,
but only to cache.  Whether to multiplex address and data on the processor
to main memory bus is an ongoing Holy War not related to the MIPS CPU.

And yes, there is a limit on how fast you can make a scheme like this
work (say 75 Mhz for CMOS?, 150 for ECL?) but I suspect the MIPS
wizards are having fun taking it to the limit.