Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.edu!rutgers!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.hardware Subject: Re: A3000: 16MHz vs. 25MHz Message-ID: <21745@cbmvax.commodore.com> Date: 20 May 91 17:50:48 GMT References: <1991May11.150058.4684@vax5.cit.cornell.edu> <4502@bnr-rsc.UUCP> <21601@cbmvax.commodore.com> <4520@bnr-rsc.UUCP> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Distribution: comp Organization: Commodore, West Chester, PA Lines: 77 In article <4520@bnr-rsc.UUCP> mascot@bnr.ca (Scott Mason) writes: >In article <21601@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>In article <4502@bnr-rsc.UUCP> mascot@bnr.ca (Scott Mason) writes: >>>In article <1991May11.150058.4684@vax5.cit.cornell.edu> kzyx@vax5.cit.cornell.edu writes: >>>The 68040 implements a very different bus interface from the 68030. >>>The amount of logic required to interface an 040 to a 68000 or >>>68030 slave is nontrivial. >>Well, that's a matter of what you consider trivial. It's certainly not a >>"do it yourself" exercise, unless you're an experienced hardware hacker. >Dave, IMHO you are understating the case. The 68030 is not that different >from the 68000 in the bus interface that it implements. A little >combinatorial logic to translate the slightly different control signals >and synchronizers for a few control signals are about all one would need. It's a little more complex than that. You really do need a state machine for the conversion, because, even though you can get the 68030 doing 16 bit asynchronous cycles thanks to bus sizing, it does most everything on different edges than the 68000. Plus, you rarely want to drive the 68030 at the same clock rate as the 68000. So even where things would have lined up, you can't really take advantage of them. You also need to clock bus arbitration in terms of 68000 clocks, and emulate the VPA/VMA/E clock interface. Most of the Motorola notes on 68020/30 to 68000 bus conversion are insufficient to build a conversion board that's really compatible. And in a system like the A3000 that supports 68000 compatible DMA onto the 68030 bus, you need to go the other way, converting 68000 to 68030 cycles. This takes two extra buffers for bus bridging, so the 16 bit 68000 bus can access either half of the 68030 bus. >The bus protocol of the 68040 is significantly different from the '030 >and '020. One basically ends up implementing the entire bus interface >logic of the '030. As mentioned in the Motorola app. note that you site: > - support for an asynchronous interace Supporting asynchronous vs. synchronous really amounts to an extra clocking stage. That's essentially what happens inside the 68030, when you're using DSACKs* rather than STERM*. > - dynamic bus sizing for 8-, 16-, and 32-bit ports (ed: biggie !!) That's a few more buffers than a 68030->68000 interface, but it's not really that difficult. Handling the 32 and 16 bit ports doesn't take any more parts than the full 68030 to/from 68000 conversion case. The 8 bit ports on the A3000 are few, so in theory you could even keep the 68030 active to service 8 bit ports if you wanted to. Though you really need only one more buffer to service that. > - retry mechanism handled independantly of the 68040 Retry support is good for a complete conversion, but the A3000 doesn't use retry anywhere, so you could get by without it. > - the bus arbitration protocol of the '020 (ed: or '030) emulated That's trivial. >The '040 model for the external interface is significantly more >advanced in some areas, such as multiprocessor support, than the '030, >but it is correspondingly different. Some of the changes, such as >dynamic bus sizing support, are probably because the rich '030 >features were really dragging down the performance. Certainly. Motorola was correct in designing a faster interface for the '040, no matter how you slice it. For example, the memory interface is now efficient enough to cut out a wait state when running at 25MHz with 80ns RAM. That alone is worth dealing with a few annoyances that may creep in for dealing with lower performance things (all 16 or 8 bit ports on the A3000 are I/O or Zorro II related, most run at 68000 speeds anyway, so a little bit of inefficiency in accessing those is no big deal, really). -- 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.