george@wombat.UUCP (George Scolaro) (11/20/88)
In article <7880@nsc.nsc.com> stevew@nsc.nsc.com.UUCP (Steve Wilson) writes: >In article <2659@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes: >>Assuming something like a 20MHz '532, then the clock cycle is 50ns. >>64K cache? Too much? Oh well. > >Seriously, you should be able to put an external cache on the 532 at 20Mhz >with no great shakes. Just going though the numbers in my head I'd guess >you would have to use 50ns static SRAMS for the cache at 20Mhz. I'd >think it might be easier to build a Page mode or Static Column based >DRAM system that supported burst. This might be a useful alternative >Hey Mr. Scolaro, do you read this net? ^^^^^^^^^^^^^ hmmmm, well I must, I suppose... Here is some info that hopefully will be of interest to the people out there that are thinking of putting together a 532 system: 50 ns static SRAMS are too slow to support a cache design at 20Mhz with burst support. The VME532 uses 15ns static rams in its cache to run at 30 Mhz, 33ns cycle time. So a 20 Mhz 532 cache design that would support burst would require better than 50-33+15= 32 ns speed srams 'cos the data setup and address prop are worse for a 20 Mhz part than a 30 Mhz part. On the 532 supporting burst is ESSENTIAL to achieve a decent level of performance, especially if the system has a wait state or so. Even if the system is 0 wait states on all read/write accesses, not supporting the burst will reduce the performance, eg Dhrystone gets a 28% hit with burst turned off. Also note that just because the cycle time while bursting at 20Mhz is 50ns, you need a lot faster dram cycle time than 50ns, little things creep in, you know? setup time, address valid time, buffers (if any), delays in the address mux control signal delays, CAS precharge etc. Basically, given a simple non-interleaved memory design, with data bus tranceivers (74F245), address bus buffers (74AS244), multiplexers (74AS258), etc. a 20Mhz 532 with 100ns fast page mode drams (1m x 1 or 256k x 4, yes they have different times, eg tCAC is 25ns or 30ns resp.) you can do a 532 memory design that while 'in page' has 1 wait state on writes (or depending on how soundly you want to sleep at night, 0 wait states), 1 wait state on the initial access, and 1 wait state per burst. An out of page access will require a re-RAS and new access to start, and that will cost 5 wait states. TI makes a neat 20 pin dip, 74ALS6311, which is basically a 14 (or so) bit latch and 28 (or so) bit comparator that will check the contents of the latch with the current data on its inputs and give a hit/miss indication. It is perfect for detecting an in/out_of page access. Seems to me that a 1 wait state memory design for the 532 is simple enough to do (its all easy once you've done it) and offers sufficiently high performance that it is a good cost/performance tradeoff. Just as a point of interest, 1 wait state drops the Dhrystone performance by around 10% or so, and Dhrystone shows one of the highest hits, since it is very bus bandwidth intensive. Something simple like the sieve, that fits nicely in the on-chip caches, shows 0% penalty. I have run a few other benchmark programs and one wait state typically shows around 1 - 4% penalty, not very noticeable at all, refresh on its own consumes around 3% of the bus bandwidth. Of course the pc/at people are convinced that a 12 mhz machine is many times faster than a 10 mhz machine.... If anyone wants it, I will happily post (schematics are tricky though) the pal equations etc for the 20 Mhz memory design that I described above. Note: it does not have parity, someone else can worry about that..... or not at all.....(power fails are more common around here (one every few months) than parity errors). What we need is an official keeper (so we can put the blame on someone) for any designs, software or hardware, that are made available. The net is fine for electronic data, bus schematics are still a problem. I know someone has requested stuff and he would distribute it BUT I did a silly thing the other day (bad bad fingers) ... rm * in the home directory... wooosh .... arrrggg where's my mailbox gone? -- George Scolaro george@wombat (try {pyramid|sun|vsi1|killer} !daver!wombat!george)