Date: Thu, 31 Aug 95 14:24:49 METDST From: marino.ladavac@aut.alcatel.at To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Cc: hardware@freebsd.org Subject: Re: Upgrade to my machine Message-ID: <9508311224.AA23659@atuhc16.aut.alcatel.at> In-Reply-To: <199508302001.NAA09303@gndrsh.aac.dev.com>; from "Rodney W. Grimes" at Aug 30, 95 1:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Rod Grimes wrote: > > > > Rod Grimes wrote: > > [ is the L1 cache static? ] > Not possitive on the true staticness of it. Though the 486 can not > change clock rates, the SL enhance 486 can, as well as all Pentiums. > This is the clock stop SL/enhancement features. To change clock > frequencies you do a stop clock, shut the clock clear down, the start > the clock up at the new frequency. > > > > 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. > I am pretty sure they are not fully dynamic, thus they do not require > refresh, as fully dynamic would mean having to do a write back cycle > after the destructive read that dynamic memory cells use. (You dump > the stored charge of the cell into the bit line when you read a DRAM > cell). Since I do not know much about chip innards, and manufacturing technologies, this question is really a shot in the dark, but: would it be possible to implement the cache in a following manner: cache itself is dynamic. The line that is presently read is buffered in some fully static memory, and refreshed after the read completes. Basically, this implies a L0 cache, fully static but very small. The likelihood that the same L1 cache line will be read in the next cycle is small, and if it occurs, the data is still available in L0 cache. It should be sufficient to have only a few lines of L0. If the L1 cache is being refreshed and the requested lines are not available in L0, read is stalled (cannot be noticed by the user as cycle counting has been progressively impossible with introduction of caches and pipelines.) > My sighted data was for the 486DX2, not the 486DX4, sorry for leaving > that detail out (I thought I had it in there, but above it appears > missing :-(). My mistake. You did, in the previous mail. > > 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? > Not noted in the data books, not avaliable in die form :-(. > > Process is .35 micron? > A80502-60 and 66 are 5V 0.8 micron technology sporting ``3.1M transistors'' > A80502-75/90/100 are 3.3V 0.6 micron technology sporting ``3.3M transistors'' > > 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. > Smallest transistor I could build with 0.6 micron technology is 1.8 micron > by 1.2 micron, and that is assuming multiple transistors in the same well, > quite common in cmos logic design. So, it would seem that one needs at least a 4x3 grid to house a transistor (we need some room between transistors, right? Or did you include that gap in the numbers above?) This gives about 230,000 transistors per sq. mm. for a total of cca. 25 million on a 11x10 mm die. This would be the upper theoretical limit. I would guess that the cache is really implemented (at least partially) dynamically. /Alby > -- > Rod Grimes rgrimes@gndrsh.aac.dev.com > Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9508311224.AA23659>