From owner-freebsd-hardware Wed Aug 30 12:26:07 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id MAA26115 for hardware-outgoing; Wed, 30 Aug 1995 12:26:07 -0700 Received: from Relay1.Austria.EU.net (relay1.Austria.EU.net [192.92.138.47]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id MAA26101 for ; Wed, 30 Aug 1995 12:25:59 -0700 From: marino.ladavac@aut.alcatel.at Received: from aut.alcatel.at (dnisun.aut.alcatel.at) by Relay1.Austria.EU.net with SMTP id AA16910 (5.67b/IDA-1.5 for ); Wed, 30 Aug 1995 21:25:43 +0200 Received: from atuhc16 by aut.alcatel.at (4.1/SMI-4.1/AAA-1.29/main) id AA14125; Wed, 30 Aug 95 21:25:48 +0200 Message-Id: <9508301925.AA14125@atuhc16.aut.alcatel.at> Received: by atuhc16 (1.38.193.4/16.2) id AA05827; Wed, 30 Aug 1995 21:25:41 +0200 Subject: Re: Upgrade to my machine To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Wed, 30 Aug 95 21:25:41 METDST Cc: hardware@freebsd.org In-Reply-To: <199508301833.LAA08959@gndrsh.aac.dev.com>; from "Rodney W. Grimes" at Aug 30, 95 11:33 am Mailer: Elm [revision: 70.85] Sender: hardware-owner@freebsd.org Precedence: bulk Rod Grimes wrote: > 16k of static sram takes >768K transistors assuming a 6 transistor cell, > now perhaps the cache is done in quasi-static 4 cell cmos sram, but then > how do they do stop clock ??? Perhaps the cache is invalidated when > coming out of stop clock mode, or maybe that is what happens during the > cycles it takes to shut down. But is it really static? I seem to recollect that original '486 could not change clock rate on the fly, unlike '386 (allegedly, for some on chip dynamic storage problems.) Furthermore, since the L1 cache is on the same chip with the rest of the CPU, refresh can be done completely transparently in the cycles when cache is not read/written to. However, I do not know if there are such spare cycles in Pentium case; there should be some at '486. > Also the claims that the RISC core of the 486 is in excess of a million > transistors in the 1994 data book sets makes me wonder how one could do > 2 of these for the dual issue super scaler pipe in anything less than > 2 million transistors. I cannot argue about that as I'm not familiar with the document, but some manufacturers (e.g. Motorola, TI) use the word 'core' when they refer to the sillicon part of an IC. This, and knowing that Intel's DX4 has 16K cache on chip, it doesn't sound too impossible. > Now we need to add in the MMU, TLB, and BIU to my already almost 2.7 Million > transistors, okay, 600K transistors, 200K gates, yea, I suppose I might > squeeze it into that... oh, and the microcode, that must be atleast > 80 bits by 4k deep, but thats not much given ROM is 1 transistor per bit, > plus decoders (and 4k decoderes aren't much when you use TGMX's :-)) > Perhaps the 3.3 million transistor count is the RISC super scaler core > excluding the cache, MMU, TLB and BIU _and_ microcode. > I don't directly consult for the processor group at Intel so I don't have > ready access to the right data. Published data like this is unclear as > to exactly what it is. Well, a rough guess can be made from the die size and the manufacturing process. This way one could get the high limit (connections ignored in favor of transistors.) The die is, what, 11 mm by 10 mm? Process is .35 micron? Let's say that a 3x3 grid can house a transistor (can it? I have no idea) then you can put cca. 1 million of them onto 1 square mm. There is about 110 square mm of area available. This, of course, proves nothing, neither did I try to do so. It is an honest attempt to estimate how many did they really need. But, then again, who cares :) > Anyway, the real point I was trying to make is there are things that > get _HUGE_ in the CAD applications with respect to memory needs. I No kiddin' :) > > > Can you say that a gigabyte in this world is actually a very small amount > I will hold by that statement, been there too many times. Definitely agree. Too bad it's so damnably expensive for the lowly common folks (like me :( ) Tschuess, /Alby > -- > Rod Grimes rgrimes@gndrsh.aac.dev.com > Accurate Automation Company Reliable computers for FreeBSD