🚀 go-pugleaf

in article <931@trlluna.trl.oz>, aduncan@rhea.trl.oz.au (Allan Duncan) says:

> How is the async running of the 2630 done?  Is it the same kludge as the
> Lucas board, with potential metastates and truncated instruction cycles?

Well, any fast board talking to the A2000, asynchronous or not, is going to
run into wait states.  But a good design should never have the potential of
going metastable.  The A2630 design is reasonably simple.  A fast PAL decodes
any on-board access as soon as a cycle starts; on-board access can be for
the FPU, the memory, or daughterboard.  If no on-board activity is called
for, a state machine for 68000 cycles is started.  This machine clocks out
AS* and DS* equivalents on the proper 7MHz edges, and one in the proper part
of the cycle, it samples the DTACK* line, first on the falling and then the
rising edge of the 7MHz clock.  Once DTACK* is indicated, the next falling
edge latches the data, for reads, and also asserts the on-board DSACK1* to
terminate the 68030 cycle.  So what's actually seen is the 68030 trailing 
just a bit behind the 68000 cycle.  Fortunately, at 25MHz, it's fast enough 
to end its lagging cycle and start a new one without necessarily adding a
68000 wait state, though the start-up synchronization delay possible can
occasionally add a 68000 wait state.  This synchronizer is pretty special
purpose, based on specific knowledge of what's on the A2630.  The nice feature 
of this design is that it's 68030-speed independent; the only limiting 
condition is the speed of the data latches between the 68030 and 68000 busses.

> Allan Duncan	ACSnet	aduncan@rhea.trl.oz

-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough