Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ncar!gatech!rutgers!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: A2630 Faster RAM?
Message-ID: <15495@cbmvax.commodore.com>
Date: 31 Oct 90 18:23:16 GMT
References: <5329@crash.cts.com>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 54

In article <5329@crash.cts.com> lkoop@pnet01.cts.com (Lamonte Koop) writes:
>I have a question about the A2630 030 accelerator.  It's fairly well known
>that replacing the standard 100ns DRAMs on the board with 80ns RAM will allow
>the board to run somewhat faster.  

Hmm, that's the first I've heard of it.  The A2620, on the other hand, has a
jumper that sets it up for 100ns or 80ns parts, but there's nothing like that
built into the A2630.  In fact, the A3000, which uses 80ns parts, runs the
same 5 clock memory cycle that the A2630 runs (and also some clever ones if
you have static column memory).  The deal is that the A2620 was on the hairy
edge of running with one wait state cut out with 100ns parts, but, basically
due to the ugly timing you get with the 68851 MMU, I couldn't quite cut it
with 100ns parts.  But some 90ns and all 80ns parts would easily work at the
faster timing, so I put in the jumper (J500 as I recall, but it's been awhile).
The A2630 has much tighter timing.  It runs a 200ns memory CYCLE for 100ns
DRAMs, which typically have a 180-190ns minimum cycle time.  Cutting out a
wait state drops the cycle time to 160ns, which would leave you OK with some
80ns parts, if only the right timing resolution was available.  The result was
that to go any faster, safely, you would need 70ns DRAM.  I did the A2630 when
DRAM had just about peaked in price, so we figured there wasn't any prayer of 
getting 70ns DRAM in production at any time during the product's life.  So no
70ns jumper, though with a reprogrammed U600 you could probably get the 
70ns timing done with existing boards.

>Here's the question: HOW?  The A2630 uses a 3 wait state design...what control 
>logic determines if it can run faster?

The A2630 actually runs 2 wait state asynchronous memory cycles (same as 3 
wait state synchronous, they add up to 5 clocks), and the memory timing is
mainly determined by a PAL (U600) and a 20ns tap delay line.  The memory
design is fully asynchronous.  With a faster clock it could have been done
synchronously, as in the A3000, for about the same complexity, but we had
enough FCC nightmares with that board to avoid any faster clocking schemes.

>... but could someone (Dave?) kindly explain what exactly is allowing that 
>faster speed access [something just doesn't seem to fit here]).

With any DRAM system, it's up to the memory control logic to determine when
it should assert DSACKx (asynchronous) or STERM (synchronous) to end a 
memory cycle.  On the A2630, DSACK0* and DSACK1* are driven based on a tap
delay who's input is the RAS* line going to the DRAM.  If this DSACKx
decision were made a tap or two sooner, by changing the aforementioned PAL,
you'd cut out one wait state.  However, there's no guarantee that the memory
in the system would still work, and in the case at hand, I can personally
guarantee that most of the time it wouldn't even work long enough to boot
up you Startup-Sequence.  Unless you swap 70ns DRAMs in for those 100ns parts
and possibly make a few more adjustments.

>--LaMonte

-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	Standing on the shoulders of giants leaves me cold	-REM