mstevens@tekig4.TEK.COM (Michael Stevens) (08/06/88)
There have been numerous requests for info on how fast a RAM chip is
needed for a clock rate of X. Generally, the equation is (assuming 0
wait state operation is desired):
1 / (Clock Speed in Hertz) = RAM speed in nanoSeconds
Examples:
--------
4.77Mhz clock: 1 / 4,770,000 = 210 nS or faster parts.
6Mhz clock: 1 / 6,000,000 = 167 nS or faster parts.
8Mhz clock: 1 / 8,000,000 = 125 nS or faster.
10Mhz: 1 / 10,000,000 = 100 nS or faster.
12Mhz: 1 / 12,000,000 = 83 nS or faster.
16Mhz: 1 / 16,000,000 = 62 nS or faster.
etc.
RAM is generally available in 150nS, 120nS, 100ns, and 80nS in
"reasonable" prices.
If your system runs with 1 wait state, it means that 2 clock cycles
are used to access the RAM (among other things), so a 12Mhz 1 Wait state
system can use 150ns RAMS, but to run a 12Mhz system at 0 wait states
you should use 80ns RAMS. This is why many people have problems when
they increase the crystal frequency and/or try to go from 1 to 0 wait
states without considering their RAM speeds. Note that the CPU or other
system parts can cause the same problems (they are also rated for speed -
you cannot automaticallly assume adding a faster clock will give you a
"faster" system that works reliably).
Note that you may be able to get away with slower RAMs in a particular
configuration at room temperatures. But for running your dual hard
disk and RAM-expanded PC in 95 to 100 degree F temperatures, you will
probably have timing problems show up if you try to "cheat" and use
slower RAMS than you clock speeds indicate. Considerations which may
affect RAM performance include temperature, I/O impedences, system noise,
etc. Fully loaded systems (many slots used, multiple disk drives) will
generally run hotter than lightly loaded (basic configuration) systems.
Also remember that each RAM vendor will give different speed margins
(a 100nS part may run at 87nS or 97 nS or 99.99nS), and even different
lots of parts from the same vendor can have these differences.Ralf.Brown@B.GP.CS.CMU.EDU (08/06/88)
In article <3075@tekig4.TEK.COM>, mstevens@tekig4.TEK.COM (Michael Stevens) writes: }There have been numerous requests for info on how fast a RAM chip is }needed for a clock rate of X. Generally, the equation is (assuming 0 }wait state operation is desired): } } 1 / (Clock Speed in Hertz) = RAM speed in nanoSeconds Only on 0ws 80286 or 80386 machines. The actual formula is 1/clock speed * memory_access_clocks / 2 = RAM speed in ns where memory_access_clock is 4 for 8088, and 2+ws for 80286/386. } 4.77Mhz clock: 1 / 4,770,000 = 210 nS or faster parts. Actually, a 4.77MHz 8088 would let you use 400 ns parts! (if any existed) } 6Mhz clock: 1 / 6,000,000 = 167 nS or faster parts. } 8Mhz clock: 1 / 8,000,000 = 125 nS or faster. } 10Mhz: 1 / 10,000,000 = 100 nS or faster. } 12Mhz: 1 / 12,000,000 = 83 nS or faster. } 16Mhz: 1 / 16,000,000 = 62 nS or faster. [...] }If your system runs with 1 wait state, it means that 2 clock cycles }are used to access the RAM (among other things), so a 12Mhz 1 Wait state }system can use 150ns RAMS, but to run a 12Mhz system at 0 wait states Your system will die a very quick death trying to use 150ns chips at 12MHz, even with one wait state! 8088s use four clocks per memory access, 80286/386 machines use two clocks plus wait states. Dynamic RAMs require a memory cycle time of twice the access time (due to setup and recovery times). It's just coincidence that the two-clock memory cycle on 286/386 machines cancels that factor of two. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I |Ducharm's Axiom: If you view your problem closely enough claimed something?| you will recognize yourself as part of the problem.
cdold@starfish.Convergent.COM (Clarence Dold) (08/09/88)
> 1/clock speed * memory_access_clocks / 2 = RAM speed in ns > Actually, a 4.77MHz 8088 would let you use 400 ns parts! (if any existed) > } 8Mhz clock: 1 / 8,000,000 = 125 nS or faster. I am glad that someone typed in a reasonable response to this. I feel guilty over having watched so much misinformation go by, but my company deals in proprietary hardware, I'm not sure how PC-compatible some of these details are. On a 80186 - 8 MHz processor, in production since 1983, we use 120nSec parts with no wait states, that coincides with your chart. The CPU can't just grab data from a Dynamic RAM (DRAM). On a system with multiple DMA masters, there is a lot of arbitration to wade through. In addition to that, there is settling time on various gates to contend with. At T0, the CPU will drive Status bits S2-S0 to indicate a RAM activity. Address lines will also be presented. Arbitration may or may not ocurr. ALE will be asserted, indicating that bits on the address/data bus are stable. 64k DRAMs require 16 address bits, but only have 8 address pins. 256k DRAMs need 18 bits, provide 9 pins. First the 9 Least significant bits are sent, along with RAS (Row Address Strobe) about 155nSec into the cycle. The high order bits are applied to the same pins and Column Address Strobe (CAS) is applied at about 185nSec into the cycle. ********** A 120nSec rated chip is guaranteed to have stable data on its output 120nSec after this RAS/CAS cycle is started. ********** There is no handshake coming back from the chip. Your system will not 'just run slower' with RAM that is too slow!!! After a calculated length of time, approximately 275nSec total on our system, you assume data is stable, and clock it in by presenting ARDY to the CPU!!! If your chips are slow, data won't be there. Parity might catch the problem, but if you drop two bits, it will get by the parity circuit. The 80186 will latch data on the next trailing edge after finding ARDY. You might be able to set switches to add wait states to RAM access. This will change the calculated time before ARDY is generated. If you're lucky enough to squeak by with some underated chip, you are just that... lucky. Temperature and the whims of nature might get a chip. I think PC's also typically define additional wait states on accesses to the expansion bus, so what won't work on the motherboard might work on an expansion card, but that is a wild guess, and doesn't belong in this posting, which is otherwise legitimate. I feel much better now.
bobmon@iuvax.cs.indiana.edu (RAMontante) (08/09/88)
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??? -- -- bob,mon (bobmon@iuvax.cs.indiana.edu) -- "Aristotle was not Belgian..." - Wanda
cdold@starfish.Convergent.COM (Clarence Dold) (08/10/88)
From article <11431@iuvax.cs.indiana.edu>, by bobmon@iuvax.cs.indiana.edu (RAMontante): > 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 inserted by timing machinery separate from the CPU chip or the RAM itself. When the system is designed, a particular speed of RAM is chosen. Timing circuits are built around those chips. If the economies, or whatever, cause this calculated time to be slower than the minimum time where the CPU could take it, the excess timing is called 'Wait States'. It might be jumper selectable, so that the user could pay more for faster chips, and eliminate the wait states, but it is independent of the RAM installed. There is no actual handshake coming back from the RAM, the handshake that the CPU sees is generated by some timing circuitry.
haugj@pigs.UUCP (Joe Bob Willie) (08/11/88)
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
ldh@hcx1.SSD.HARRIS.COM (08/12/88)
>/* Written 10:24 am Aug 9, 1988 by bobmon@iuvax.UUCP in hcx1:comp.sys.ibm.pc */ >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??? >-- >-- bob,mon (bobmon@iuvax.cs.indiana.edu) >-- "Aristotle was not Belgian..." - Wanda "Wait states" are cycles of the system clock that the CPU, or other DMA device, has to waste (wait) before obtaining the desired results from the memory being accessed.