Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!rutgers!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.hardware Subject: Re: A3000: 16MHz vs. 25MHz Keywords: accelerator, amiga, 68040, 68030, 68000, replacement, conversion Message-ID: <21812@cbmvax.commodore.com> Date: 22 May 91 20:58:02 GMT References: <21601@cbmvax.commodore.com> <4520@bnr-rsc.UUCP> <21745@cbmvax.commodore.com> <4540@bnr-rsc.UUCP> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Distribution: comp Organization: Commodore, West Chester, PA Lines: 63 In article <4540@bnr-rsc.UUCP> mascot@bnr.ca (Scott Mason) writes: >In article <21745@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >:In article <4520@bnr-rsc.UUCP> mascot@bnr.ca (Scott Mason) writes: >:: [ Me, understating the 68030->68000 interface, like many Amiga >:: HW hackers :-) ] >:It's a little more complex than that. >: [ Dave, commenting about synchronous dependancies for full 68000 >: compliance ] >Fortunately, I have only had to deal w/ async slaves. Everyone has to deal with async slaves; there aren't any truely synchronous slaves on any 68000 bus, since the 68000 bus is inherently asynchronous. They do have timings that let you treat it synchronously, which is what the Amiga chips do. But regardless of whether the slave behaves basically synchronous or basically asynchronous, the master has to be 68000 compliant or things will die. A synchronous master (one that bases its operations directly on the Amiga system clocks) can deal with this pretty easily. The real trick is synchronizing to asynchronous master. >The Amiga seems to have taken maximum benefit from sync operation to the >68000, and must place the most stringent requirements of any target on the >timing of an accelerator, even an accelerated 68000. Well, the interleaved cycle of the Amiga system chips is acting very much as a synchronous-timing 68000 device. While, as a slave, it seems to be making the 68000 jump through hoops, the actual timing is pretty lax by today's TTL standards. All the A26x0 68000 interface logic, for example, is LS logic and mainly 20-25ns PALs. The A2630 memory logic, on the other hand, is all F series logic and at least one 10ns PAL (on the edge for a 1988 design). >:: [ 68040 to 68030 interface discussed] >:: - dynamic bus sizing for 8-, 16-, and 32-bit ports >Actually, this is more than just a matter of multiplexing the bytes >around. The 68040 expects to run just one cycle for any fetch. The >68030 will run up to four bus cycles to complete a fetch. The bus >interface must detect cases when the port size was smaller than the >access size, and execute multiple bus cycles to assemble the data. Again, the A3000 doesn't require the full and complete conversion logic you might invision. True byte wide ports are only for I/O, uncached, and only accessed with byte wide instructions, for instance (OK, they were a bad idea in the first place, and not mine). In any case, once you have a cycle generator, it's absolutely no big deal to make it handle a couple of cycles. An optimal A3000 68040 card will probably have a gate array on it anyway, to deal with the 68040 to 68030 conversion correctly. Because the 68040 is so dependent on burst cycles, you want to take advantage of 68030 bus burst reads and writes. If you provide a four word bidirectional FIFO, you can have full speed 68030 bursts with write buffering and let the 68040 run asynchronously to the 68030 bus. Not that anyone has done it this way to date, but it is the best way to do it, and such a gate array won't run more than $10-$15, while even a few bidirectional latching buffers can run over $20. Though such a gate array is hardly required; I have seen several reasonably simple 68040 card designs for the A3000 to date. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.