Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!killer!pollux!dalsqnt!rpp386!pigs!haugj From: haugj@pigs.UUCP (Joe Bob Willie) Newsgroups: comp.sys.ibm.pc Subject: Re: RAM speed per clock rate Message-ID: <217@pigs.UUCP> Date: 10 Aug 88 17:07:55 GMT References: <22faf142@ralf> <623@starfish.Convergent.COM> <11431@iuvax.cs.indiana.edu> Reply-To: haugj@pigs.UUCP (Joe Bob Willie) Organization: Big "D" Oil and Gas Lines: 43 In article <11431@iuvax.cs.indiana.edu> bobmon@iuvax.UUCP (RAMontante) writes: >Okay, I've seen some interesting RAM-timing information flow past, and I >understand what a wait state does, but I have one simple question: what >IS a wait state? Is it a CPU clock cycle? Is it some portion of a clock >cycle related to the memory-chip timing (what relationship?)? Does it >come from some mysterious secret delay line somewhere? What??? a wait state is a clock cycle consumed by the memory system hardware. the delay is produced by not asserting the data transfer complete line on the cpu in the number of clock cycles which the cpu expects the transfer to complete in. for example, in the motorola mc68000, the data transfer acknowelege line is refered to as /DTACK. the cpu expects /DTACK to be asserted (zero volts on /DTACK pin) one clock period after /AS (address strobe) is asserted indicating the value on the address bus has stablized. should the memory system not assert /DTACK within one cycle, the difference in cycles are refered to as `Wait States'. the memory system normally runs at 4 clocks per memory reference, so each clock over 4 per memory reference is a wait state. the advantage of the i80286 and i80386 over the mc68000 and mc68020 is that the bus execution unit is not tied to the execution unit. hence, the bus execution unit can continue to prefetch instructions and operands while the execution unit executes the instructions. so, in a typical mix of instructions, whose average length of execution is longer than the typical memory cycle length, wait states don't appear in the instruction timing, PROVIDED, the number of wait states is not excessive. (where _excessive_ is something close to what 16 bit 8MHz 2 wait state memory looks like on a 32 bit 20MHz 80386 system) thus, the answer to the second part of the question, a wait state may not slow your system down proportionately. for example, full speed operation is something like two cycles per instruction and two cycles per instruction fetch for an 80386. adding one wait state would appear to be a 50% reduction in speed. however, because of the prefetch queues and such on the 386, you do not see an actual 50% slow down. (as a rough guess, i think for 32 bit memory, you don't see a 50% slow down until you get to about 4 wait states, assuming 8 bit instructions which will actually execute in 2 clocks [ and there aren't many of those ;-]) -- jfh@rpp386.uucp (The Beach Bum at The Big "D" Home for Wayward Hackers) "Never attribute to malice what is adequately explained by stupidity" -- Hanlon's Razor