CPU frequency / memory wait states at end of the 80s

Question

According to the advertisements of the late eighties, you could find RAM having an access time ranging from 120 to 80 ns (150 to 210 cycle times). A 386SX-25 could execute a typical register to register instruction in 2 cycles of 40 ns.

Would it (and all PCs of the era) need to add wait states that dropped its effective speed to 4 to 6 MHz in order to align to those memory cycle times?

Then, what is the point of having a 3-stage pipeline if you had to wait years before memory could catch up, even assuming a 32-bit data bus (386DX) to fetch instructions in a single word?

The VGA standard was introduced in 1987, according to Wikipedia. How could a computer of the era write all of a graphic framebuffer of 150 KB in less than 200 ms, then?

Were there additional memory access optimizations allowing to speed the cycle? (Not including graphic acceleration techniques, of course.)

Answer 1

According to the advertisements of the late eighies, you could find RAM having an access time ranging from 120 to 80 ns (150 to 210 cycle times).

Which means essentially up to 6 million full access operations per second.

A 386SX-25 could execute a typical register to register instruction in 2 cycles of 40 ns. Would it (and all the PC of the era) need to add wait states that dropped its effective speed to 4 to 6 MHz in order to align to those memory cycle times?

True for complete random access, ignoring page mode. Consecutive access like usually with program, will use page mode, were only the first access needs to be full length.

Then what is the point of having a 3 stage pipeline

Erm, according to intel documentation it's 6 stages (*1)

if you had to wait years before memory could catch up, even assuming a 32 bits data bus (386DX) to fetch instructions in a single word?

Uh-Oh. Timing is way more complex than just counting cycles. There are (at least) two actors, Cpu and memory. For the CPU basic considerations are

1. Basic access time for a 386 type CPU for memory is always two bus cycles (= two clock cycles), named T1 and T2 (*2)

2. The 80386 offered a pipelined addressing mode. When an address was acknowledged during the first access cycle (T1) by asserting /NA (Next Address), then the next address was already supplied during T2 of the previous access. So usage of an external Essentially extending access time to three cycles.

3. The 386DX does 32 bit instruction fetch, so four bytes in one cycle, a 386SX does two.

4. The 386, like all x86, has its BIU (Bus Interfac Unit) running asynchron to the EU (Execution Unit). This allows the Prefetch Unit to fetch instructions independent and ahead of time.

5. The Prefetch Unit maintains a 4 word (16 byte) queue. This is not a synchronous pipeline stage, but a real independent prefetch. The PU issues a read request toward the BIU every time there is room in the queue for (at least) one word (32 bit). This request got lowest priority, thus will be executed whenever there is no other task to do. Essentially using all free cycles to keep the queue topped up

For RAM there comes at minimum the difference between full cycle access, which is 150 ns in your example and CAS only access (page mode) access which can be used for consecutive access, getting it down to 80 ns.

For program execution this works as follow:

1. A 25 MHz 386 got a 40 ns cycle time, thus two cycles give 80 ns for access. So with 150 ns cycle time RAM two TI (wait cycles) are needed for any random access, while only one is needed for consecutive (page mode) access (*3)

2. Address pipelining stretches the time between address output and data read to 120 ns, thus reducing the need for a wait state to only random access and only a single TI. this is especially noteworty for 386SX boards, as the do a lot of consecutive access.

3. 32 bit (386DX) access acts faster than needed by fastest operations, while 16 bit (386DX) even acts faster than needed.

   The mentioned RR type move is two bytes long an takes two cycles to execute. Without wait states the same two cycles fetching two bytes (386SX) or four bytes. So for this (narrow) example the 386DX BIU is fetching instructions twice as fast as the EU can handle them. It's rather the fast instructions with long encoding that may slow execution - but even there it levels out rather fine.

4. The BIU can insert code fetch whenever the PU has room (i.e. requests a word) and no otehr access (usually data) is pending.

5. Being a true asynchronous word wise queue, it doesn't act like a fixed function pipeline stage handling instructions, but more basic (and abstract) as a dynamic buffer on word level, thus working more efficient than instruction based read ahead.

With all of this combined the 386DX executes in a near wait less manner up to 20-25 MHz from standard (fast) page mode RAM. Only for speeds past 20-25 MHz a cache could add performance.

Conclusion: A 386DX could come close to it's maximum performance with 80 ns RAM (and a well designed board).

---

And Now For Something Complete Different

The VGA standard was introduced in 1987, according to Wikipedia. How a computer of the era could write in a graphic framebuffer of 150K in less than 200ms, then?

There are a few misconceptions here

• VGA is not main memory, it is I/O bus, aka ISA-bus.
• ISA Bus is limited to 16 bit (usually with wait states)
• ISA Bus is limited to 6(8) MHz (without overclocking that is *4)
• VLB with faster (and 32 Bit) access wasn't introduced until ca. 1993.
• To make it worse, genuine VGA is limited to 8 Bit transfers

last but not least,

• VGA at that time meant 320x200 and fits in 64 KiB :))

Maximum thruput on 8 MHz 8 bit bus is 8 MB/s (*5) quite enough for 60 frame copies with 64 KiB each. Double buffering could enable a smooth display. Still it would occupy >50% CPU time to frame transfer, leaving not much time to calculate the next frame.

And this is essentially were the most basic misconception lies: The assumption of screen operation in terms of full frames submitted. Games that rely on frame redraw, like DOOM, could simply not display a full screen rendering on a 386. It needed a fast 33 MHz 486 and VLB or PCI VGA cards to even do 320x200 in all beauty.

Long story short: Games were a complete different beast back than then now - almost as much as they were different from an Atari 2600. Similar 'high' resolution usage in any other program. So never 'backport' today's approach and usage of computers back to that time.

---

*1 - Not arguing here, just referencing to page 2-1 of the 80286 Hardware Reference Manual stating "The six-stage pipelined processing of the 80386 ..."

*2 - Inserted wait cycles (TI) are essentially repeated T2 cycles.

*3 - Although that is rather tight and depends a lot on address decoding, multiplexing and forwarding logic. Essentially a case were slower clock 386, like 20 MHz, will be faster than its 25 MHz brother.

*4 - This is also why it was so important to get a board that allowed to increase I/O-clock past 8 MHz

*5 - Lets ignore for this that default was 6 MHz and many boards inserted by standard (and default) wait states. Similar ignoring possible page flipping and alike.

Answer 2

While the 386 did not yet have an internal cache, many 386-era chipsets supported an SRAM based CPU-external cache memory of maybe 32KB or so, consisting of a very fast (for the time) tag SRAM which stored the correspondence between RAM addresses and SRAM addresses, and 4-8 fast SRAMs holding the cache contents. Not sure about the late 1980s, but in the early 1990s those were very common on 386 boards. Often, caches could be upgraded by the user inserting more and/or larger SRAMs and setting some jumpers.

Such a cache would have reduced latency by a lot if and when a RAM address was already in the cache. In case of tight inner loops addressing rather small amounts of data, this pretty much eliminated DRAM latency.

Answer 3

The 80386 bus cycle is two clock cycles minimum.

So a 25 MHz 80386 would have a 80ns bus cycle, and each wait state would add 40ns. So it only takes 2 wait states to use 150ns memory and 4 wait states to use 210ns memory.

True, with 4 wait states at 25 MHz, the memory access cycle is 240ns, or about 4 MHz.

One thing that also has to be considered that on average, even with 0WS memory like SRAM, the bus utilization is 73% (as per 80386 Hardware Reference Manual). Adding 3 wait states makes the bus utilization go to 93%, so memory has to be waited more often, but not all the time.

Because of the instructions are prefetched to the 16-byte (12-byte?) queue and then having the 3-stage pipeline for decoding, it does not have to wait decoding instructions for execution when memory is busy doing data reads and writes, and depending on what kind of processing is being done, an occasional memory load or store may not be a bottleneck.

Compared to previous generation 80286, even for clock-per-clock, the 80386 improves execution times for many instructions, and as the bus is double as wide so 32 bits can be transferred in a single memory cycle by using the 386 specific instructions to do so.

And as mentioned, at some point caches were used to improve performance.

And so if memory accesses happen at around 4 MHz rate, and can be done 4 bytes per access, copying a 150k frame buffer from memory to memory in 200ms is only 1536kbytes/second to be read+written.

Answer 4

Moving away from x86 for a moment, let's talk about the early ARM CPUs used in the Acorn Archimedes series computers. The ARM1 prototype first ran in 1985, and the Archimedes arrived in 1987 using the ARM2 production model.

Maximising memory access performance was a key part of the ARM design, recognising that this had become the main limitation on computer performance. Transistor budgets weren't yet large enough to make on-chip caches really practical (though the 68030, for example, had tiny ones), and the ARM didn't exactly push the bleeding edge in that respect (with fewer transistors than the much older and slower 68000). Instead, a wide 32-bit bus was employed with good use made of the Fast Page Mode of typical DRAMs.

Fast Page Mode simply means that if the "row" addresses of two consecutive DRAM accesses are the same, you don't need to provide the row address again, only the "column" address and the read/write signals. This also skips the actually slow parts of a DRAM access - pulling data out of the "row" of capacitor cells into the "row buffer", and writing it back afterwards. Fast Page Mode accesses therefore take much less time than "random" accesses, and the "random" speed only applies to switching between rows.

Because the ARM is a RISC CPU, it does most of its computation in a large register set and only occasionally needs to use load and store instructions. Most consecutive accesses are therefore instruction fetches in sequence. By the time a load, store, or branch instruction has got far enough in the pipeline to actually be executed, the memory controller has been informed that the sequential access sequence will end and the RAM should be prepared for a "random" access. The ARM also has load/store multiple instructions that use Fast Page Mode.

Given a typical "150ns" DRAM of the time, the 150ns refers to the minimum guaranteed access latency between the "row" address being provided and valid data being output and stable on the bus. The "random" cycle time is more like 230ns, including the actions needed to prepare the DRAM for the next "random" access. But the access latency of a Fast Page Mode access is just 70ns, and the cycle time is 130ns.

This means a 12MHz CPU like the ARM2 can perform sequential accesses to the same DRAM chip every 2 clock cycles, but it needs a total of 3 cycles to perform a random access. If two banks of DRAM are provided (ie. two full-width sets of DRAM chips) with separate /CAS strobe lines, and addresses are interleaved between them, then sequential accesses can occur every single cycle (alternately to each bank) while random accesses still take 3 cycles (to any one bank).

This was a large factor in the performance advantage of the ARM over its contemporaries, most of which required multiple cycles per memory access even when operating sequentially, and also required more memory access cycles on average to perform any given task.

In 1989, the ARM3 introduced an on-chip 4KB cache, and used this to double the clock speed over the ARM2. Reads could be serviced from the cache at full speed, and cacheline fills were always sequential accesses of 16 bytes each (one "random" plus three Fast Page Mode 32-bit cycles). The cache was write-through, so single writes still took the full "random" access time and only Store Multiple instructions were sequential writes. This did make an already very fast home computer (for its time) even faster.