root@apal.mcshh.UUCP (Andreas Mueller) (11/19/90)
-- Does anybody know, how the asyncronus clocking (on 68k20/30/.. boards) is handled? I mean, how do they syncronize the fast clock with the slow 7.1.. MHz clock. I think, syncronizing is only done when the CPU accesses 32 bit ram -> chip ram | chip ram -> 32 bit ram. But this would cause some waits (except the 7.1.. MHz clock is a divider of the CPU clock). Any comments ..... ?:) ----------------------------------------------------------------------------- /***************************************************************************** * Andreas Mueller (A1020) | "Who left a footprint in my chase?" * * UUCP: root@apal.mcshh.UUCP | "Strong typing is for weak minds!" (unknown?) * *****************************************************************************/
daveh@cbmvax.commodore.com (Dave Haynie) (11/20/90)
In article <root.3232@apal.mcshh.UUCP> root@apal.mcshh.UUCP (Andreas Mueller) writes: >Does anybody know, how the asyncronus clocking (on 68k20/30/.. boards) >is handled? Yup. Though this only takes place on the A2630 and A3000 from C=; the A2620 and all other 68020 boards I know of except LUCAS are synchronous. >I mean, how do they syncronize the fast clock with the slow 7.1.. MHz clock. The clocks themselves aren't synchronized. Bus transactions are actually what gets synchronized. >I think, syncronizing is only done when the CPU accesses 32 bit ram -> chip ram | >chip ram -> 32 bit ram. But this would cause some waits... It's done for any 68030 access of 16 bit system resources, which include Chip RAM and Zorro II bus devices. And sure, it causes a number of wait states, there's no getting around that. On the A2630 and A3000, it looks something like this: s0 s1 s2 s3 s4 s5 s6 s7 C7M ----____----____----____----____----____---- CDAC __----____----____----____----____----____-- | | | a b c 030AS* ------------___________________________----- 000AS* ----------------____________________-------- DTACK* --------------------------__________-------- DSACK* ------------------------------------___----- This is just a rough sketch, but here's basically how it works. The 68030 starts a cycle, and some system logic determines (probably based on the address) that it's a 68000 type cycle. To synchronize safely to the 68000 bus, some point prior to the rising edge of C7M at s2 is chosen for sampling of the 68030 address strobe, since this 030AS* can some along any absolutely any time relative to the 68000 bus clocks. In the A3000, the falling edge of the CDAC clock is used (this clock trails C7M by 35ns); in the A2630 I use a "magic trick" based on tightly controlled relative chip delays. The cycle, like a 68000 cycle, runs until DTACK is sampled on the falling edge of C7M after s4. Based on 68000 timing, the 16 bit data will be valid on the falling edge of C7M between s6 and s7. When we reach that point, the 16 bit data is latched and the 68000-equivalent signals negated. With the 16 bit data safely latched, the 68030 cycle is ended. This way, until the cycle time of the 68030 clock approaches the latching time of the bus buffers, the end-of-cycle logic is independent of 68030 clock speed. Anyway, that's a 5 minute explanation of how the A2630 and A3000 run 16 bit cycles. I don't know offhand how the other guys do it, but I suspect they're not all that far off from this. >/***************************************************************************** >* Andreas Mueller (A1020) | "Who left a footprint in my chase?" * >* UUCP: root@apal.mcshh.UUCP | "Strong typing is for weak minds!" (unknown?) * >*****************************************************************************/ -- 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