🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #3531

Re: Dynamic internal state (was Re: Scoreboards / Load-interlocks)

#3531
From: Prasad Raje
Date: Mon, 19 Mar 1990 22:34
48 lines
2738 bytes

>   In article <39538@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes:
>   > If it's what I'm thinking of, its a cute idea. Guarantee that the 'valid'
>   >  bit decays before any of the others, and its easy.
>
>   That is *sneaky*.  Now, refresh the entry in case of a cache hit.  If
>   the entry hasn't been used in a few milliseconds, it will be purged.
>   Not-recently-used!  It may be impractical for other reasons, but it has
>                                                 ^^^^^^^^^^^^^
>   serious hack value.
>   -- 
>	   -Colin


( The suggestion is to use dynamic storage for the valid bit and rely on
its decay to purge unused entries in the cache )

Unfortunately this wont work, for this "other" reason.

The rate of decay of a DRAM memory cell (essentially the charge leakage
from the storage node through a reverse biased p-n junction) is very
difficult to control accurately. After the junction leakage has been reduced
to the order of a few pico amps per micron^2 it is very difficult
to control to even 100% accuracy. The refresh rate of the order of a few
milliseconds is really a safe lower limit on how long the charge will
reliably be stored on the node. There have been recent DRAMs made with
as long as 1 second retention times.

Assuming a storage capacitor of           C = 50 fF
and a leakage current of                  i = 10 pA
using i = C dv/dt, the rate of decay is       0.2 V/ms

So even if you were able to control i very accurately to 10pA, the cell voltage
have decayed only to 4.8V from 5V after 1ms. When the time comes to
decide if the valid bit has "faded away" it will be very difficult to
make a decision in a time that is of the order of sucessive cache
accesses.

In brief, a highly uncontrollable technology-level parameter would 
determine a architecture-level parameter viz. the replacement strategy of 
the cache.

I realize this is straying away from comp.arch, but this thread has been
here for a while now.

cheers
Prasad
Technical Details
Message-ID: <RAJE.90Mar19143422@dolores.Stanford.EDU>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!wuarchive!decwrl!shelby!cis!raje
References: <11337@encore.Encore.COM> <3300106@m.cs.uiuc.edu> <32937@shemp.CS.UCLA.EDU> <132903@sun.Eng.Sun.COM> <39538@apple.Apple.COM> <22182@watdragon.waterloo.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!wuarchive!decwrl!shelby!cis!raje
From: raje@dolores.Stanford.EDU (Prasad Raje)
Newsgroups: comp.arch
Subject: Re: Dynamic internal state (was Re: Scoreboards / Load-interlocks)
Message-ID: <RAJE.90Mar19143422@dolores.Stanford.EDU>
Date: 19 Mar 90 22:34:22 GMT
References: <11337@encore.Encore.COM> <3300106@m.cs.uiuc.edu>
 <32937@shemp.CS.UCLA.EDU> <132903@sun.Eng.Sun.COM>
 <39538@apple.Apple.COM> <22182@watdragon.waterloo.edu>
Sender: news@cis.Stanford.EDU (USENET News System)
Organization: Center for Integrated Systems, Stanford
Lines: 48
In-reply-to: ccplumb@lion.waterloo.edu's message of 19 Mar 90 05:44:16 GMT