Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdahl!nsc!stevew
From: stevew@nsc.nsc.com (Steve Wilson)
Newsgroups: comp.sys.nsc.32k
Subject: Re: The 'cost' of a '532 system (Long).
Keywords: cheap nsc 532
Message-ID: <8013@nsc.nsc.com>
Date: 23 Nov 88 17:49:01 GMT
References: <433@sdrc.UUCP> <2659@sultra.UUCP> <1041@raspail.UUCP> <17658@gatech.edu> <2677@sultra.UUCP>
Reply-To: stevew@nsc.nsc.com.UUCP (Steve Wilson)
Distribution: eunet,world
Organization: National Semiconductor, Sunnyvale
Lines: 22

In article <2677@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes:
>This is fixed.  Nothing to do with the CPU speed.  If you want to avoid
>wait-states, just use the "paging scheme" hinted at by Steve Wilson.  This
>should give you the 50ns eaten by the MMU at least.  And this is without
>using 15ns cache chips.  Furthermore, since when did I/O feed the CPU.
>The '332 and '532 (and maybe even the '032 -- Steve??) allow dynamic
>resizing of the bus. 

The 32032 doesn't support dynamic bus sizing.  As for the page mode
scheme see George Scolaro's recent posting for more details. (Where
do you think I got the idea from ;-)  Though I still think the 50ns 
number is ok (George, I really did take address drivers and data bus
drivers into account when I came up with that number...) Trying to
support burst fills on a 532 with 50ns SRAMS even at 20 Mhz would be an
expensive proposition though.  There are ways to do it, but managing it 
gets abit tricky, and how you interface it to your DRAM system is also
a consideration.  Another detail of the cache is that you couldn't 
possibly use 50ns SRAMS to implement the TAG.  You'd probably want
to use some of the faster TAG chips.  These guys aren't cheap either.

Steve Wilson
National Semiconductor