From owner-freebsd-hardware Thu Aug 31 05:58:40 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id FAA04626 for hardware-outgoing; Thu, 31 Aug 1995 05:58:40 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id FAA04620 for ; Thu, 31 Aug 1995 05:58:38 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id WAA01554; Thu, 31 Aug 1995 22:30:49 +0930 From: Michael Smith Message-Id: <199508311300.WAA01554@genesis.atrad.adelaide.edu.au> Subject: On-chip caches (was re: Upgrade to my machine) To: marino.ladavac@aut.alcatel.at Date: Thu, 31 Aug 1995 22:30:48 +0930 (CST) Cc: rgrimes@gndrsh.aac.dev.com, hardware@freebsd.org In-Reply-To: <9508311224.AA23659@atuhc16.aut.alcatel.at> from "marino.ladavac@aut.alcatel.at" at Aug 31, 95 02:24:49 pm Content-Type: text Content-Length: 1851 Sender: hardware-owner@freebsd.org Precedence: bulk marino.ladavac@aut.alcatel.at stands accused of saying: > > > Rod Grimes wrote: > > > > [ is the L1 cache static? ] > > 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 No. Lookup time, time to refresh etc. pretty much preclude this. > 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.) You lose here on propagation delay; you'd have to deepen the pipeline, and with speculative execution the problem just gets worse. > This would be the upper theoretical limit. I would guess that the cache is > really implemented (at least partially) dynamically. I'd be _really_ suprised to see anything other than low-gain static cells in use in an L1 cache; speed is too important to trade off for anything else. > /Alby -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[