Path: utzoo!utgpu!bnr-vpa!bnr-fos!leibniz.uucp!schow
From: schow@leibniz.uucp (Stanley Chow)
Newsgroups: comp.arch
Subject: Do you have bandwidth?
Message-ID: <407@bnr-fos.UUCP>
Date: 15 Apr 89 06:12:27 GMT
Sender: news@bnr-fos.UUCP
Reply-To: schow@leibniz.uucp (Stanley Chow)
Organization: Bell-Northern Research, Ottawa, Canada
Lines: 68

Since Micheal Slater has already posted a good summary of the '040 and
486; there is not much point in starting a new battle in the 68K vs i86
war. (At least wait till there is more public information).

In the mean time, I offer a new topic to burn up bandwidth (that is, 
net.bandwidth, not bus.bandwidth).
 
In a recent series of articles about address modes and other topics,
some posters claim that memory bandwidth is not a problem - to quote
Brian Case, "bandwidth can be had in abundance". I happen to think that
we do not enough bandwidth now. What to other people think?
 
Just to make sure there are enough pieces so that everyone can post a
different answer, I will start with a list of pieces and you can fill
in the interfaces. Please try to at least type what you mean and by all
means, put in a couple of real (or maximum) numbers.
 
[Feel free to talk about parallel/multi-processing.]
 
    Piece of system
 
    Execution Core (possibly many)
    On-chip Cache  (possibly split)              chip
			 ---------------------------------
    Off-chip Cache (possibly multi-level)        board
    Main memory    (possibly multi-level)
    Bulk memory    (for lack of a better term)
 
 
Specific interfaces that may be of interest:
 
1) Execution Core  to  On-chip I-Cache.
 
    It seems people can already build cores that are faster than the
    on-chip cache. One can always throw silicon at a multiplier to make
    it faster (I know, there are limits with loading, ..).
 
 1a) Straight line execution
 
    Even in this simpler case, I understand that most chips are limited
    by the cache, not the core. Any chip designers want to comment?
 
 
2) Execution Core  to  On-chip D-cache.
 
    A very hard problem by all accounts. Everyone (almost) adds delay
    slots one way or another.
 
 
3) On-chip  to  off-chip.
 
    A well know problem. How wide do you think buses will get? How fast?
 
 
4) How should off-chip cache be controlled? By the cpu chip?
 
 
5) Invent the interface problem of your choice. This can be made as hard
   or as easy as you want.
 
 
 
Stanley Chow   ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public
 
 
Please don't tell my boss I am starting this discussion, he thinks I
am working hard on software!