Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site sauron.UUCP Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ittatc!dcdwest!sdcsvax!ncr-sd!ncrcae!sauron!campbell From: campbell@sauron.UUCP (Mark Campbell) Newsgroups: net.arch Subject: Re: Timing loops (H/W vs. S/W design) Message-ID: <622@sauron.UUCP> Date: Fri, 14-Mar-86 10:12:54 EST Article-I.D.: sauron.622 Posted: Fri Mar 14 10:12:54 1986 Date-Received: Sun, 16-Mar-86 00:44:04 EST References: <156@motatl.UUCP> <530@hoptoad.uucp> <613@sauron.UUCP> <566@hoptoad.uucp> <618@sauron.UUCP> <25@cbm.UUCP> Reply-To: campbell@sauron.UUCP (Mark Campbell) Organization: NCR Corp., Advanced System Development, Columbia, SC Lines: 38 In article <25@cbm.UUCP> grr@cbm.UUCP (George Robbins) writes: > >Speaking of moot problems, the recovery time specification for the Z8530 is >a non-problem in most applications. The data sheet basically specifies that >so many PCLK cycles must elapse between accesses. Unless you are using an >unusually slow PCLK, the overhead of the C style inb()/outb() subrountine calls >will eat up the requisite cycles. Assembly code may need a nop or two to >guarentee cycles. Absolute last word on the subject (we clock at 4MHz, but I'll assume 6MHz): 8530 Set-Up Delay = 6 x T x PCLK + 200ns = 6 x 165ns + 200ns = 1.19us (6MHz, best case) = 6 x 2us + 200ns = 12.2us (6MHz, worst case) MC68020 NOP Time = 2 x 60ns = 120ns (16.67MHz, loop) = 2 x 80ns = 160ns (12.5MHz, loop) 1.19us / 120ns = 10 NOP's; 1.19us / 160ns = 8 NOP's (best case) 12.2us / 120ns = 102 NOP's; 12.2us / 160ns = 77 NOP's (worst case) I'm not familiar with the "C style inb()/outb" routines you mention. However, I would respectfully suggest that if these routines can guarantee a 12.2us delay through normal code execution, you fire the guy who wrote it. You'll probably notice that the number of NOP's required are a bit more than "a nop or two" you predicted. This is compounded by the fact that interrupts are disabled at this time, increasing latency. *This* is compounded by the fact that we have to assume worst case with no H/W chip level support. *This* is compounded by the fact that this software solution still does not solve the problems associated with 8530-related DMA accesses. I included the best case timings to illustrate what the proper H/W can do. I suggest that anyone out there having problems with the 8530 see the April 4 issue of EDN, pages 274-275, for a nice H/W solution for the 8530's recovery time problems. -- Mark Campbell Phone: (803)-791-6697 E-Mail: !ncsu!ncrcae!sauron!campbell