If you missed the previous parts in this article series please read:
If you would like to be notified when Russell Hitchcock releases the next part in this article series please sign up to the WindowsNetworking.com Real Time Article Update newsletter.
In my last two articles I wrote about various memory technologies including; hard disk drives, RAM, MRAM, and holographic data storage. Of course, the technology used for the physical data storage is only part of what will determine the performance you see. To fully understand the performance of your memory, you must understand how the memory connects to the CPU and how it can be manipulated.
Generally, memory connects to the CPU the same way that any peripheral connects to the CPU; via a system bus. The next time you have your computer apart, take a look at the underside of your motherboard. Here you will see a lot of wires; this is the system bus.
Different system buses are defined with system specifications. A system bus specification will include things like; the numbers of wires, the size of the wires, what each wire should be used for, and what connectors should be used. Modern bus specifications have advanced features and are quite complex, with multiple wires for data transmission in both directions, and multiple wires for control signals. The complexities of these system buses are really blurring the lines between buses and networks.
One of the oldest and continuously used bus specifications is the inter integrated circuit or I2C, specification. With only two bidirectional wires, one for data and one for a clock signal, this is a relatively simple specification.
Figure 1: A representation of an I2C bus, courtesy of www.wikipedia.org. Vcd is the power, SDA is for data, and SCL is for the clock signal
Inter Integrated Circuit
Developed in the early 1980s by Philips Semiconductor, I2C was developed as a low speed standard for onboard serial communications. Originally developed for use in television sets, it only took a few short years to become widely adopted. I2C is still used today in many applications, like computer monitors.
Before I2C every device used by a microcontroller had to be connected directly to the microcontroller. The problem with this was that as you increased the complexity of the system, you had to increase the amount of pins on the microcontroller to accommodate the additional devices.
With the addition of a bus on the circuit board, each device could connect to the bus and the microcontroller would only need to connect to the bus. All that was needed was a set of rules for how to use the bus. Even this early bus sounds a lot like a network, doesn’t it?
The current version of the I2C specification is version 3.0. This version supports four categories of bus speeds:
- Standard 100 kb/s
- Fast 400 kb/s
- Fast mode plus 1 Mb/s
- High speed mode 3.4 Mb/s
One really cool capability of I2C is called clock stretching. What clock stretching means is that, the slave device can hold the clock signal down in a low position. This is useful because when a slave receives a read request, it can hold down the clock while it prepares to send the information to the master and then release the clock when it is ready to send.
Other companies were also busy in the early 1980s developing their own bus specifications. IBM was one of these companies. One of their early busses was the Industry Standard Architecture or ISA, bus. Actually, when it was developed IBM called it the XT bus.
IBM specifications
Developed in 1981 as an 8bit bus, ISA was later modified to be a 16 bit bus architecture. The ISA bus supports speeds of up to 8Mb/s. During the 1980s, ISA gained widespread popularity, but it wasn’t perfect. One major drawback to ISA was that the specification lacked detailed information on bus timing and the rules governing bus use. As a result many companies were forced to implement their own version of ISA with unique specifications. These unique versions of ISA were rarely compatible and caused a lot of headaches.
Another drawback to ISA was the intensive configurations required to connect a device to the bus. In 1993, ISA Plug and Play was developed to alleviate this problem. This plug and play architecture allowed the computer’s operating system to do the configuring instead of the user. This was a major step forward in computer architecture and many of today’s computers still support ISA plug and play.
In the late 1980s IBM attempted to replace the aging ISA bus with the Micro Channel Architecture or MCA, bus. This specification offered a 32 bit bus and automatic configuration.
While MCA alleviated the constraints of ISA’s 16 bit bus and allowed for communications at up to about 40MB/s, there were also disadvantages which greatly hindered industry adoption of this bus specification. One disadvantage was that MCA was a proprietary technology, which of course meant that any company which wanted to use MCA had to pay IBM. Needless to say, not many people liked this idea.
Extended Industry Standard Architecture
Shortly after IBM developed MCA, IBM’s competitors, including Compaq and HP, came up with a solution. They organized themselves, often referred to as the “Gang of Nine”, and developed the Extended Industry Standard Architecture or EISA. Actually, they also renamed IBM’s XT bus the ISA bus so that they wouldn’t infringe on IBM’s trademark.
Like MCA, EISA was a 32 bit bus architecture. But, like its name suggests, EISA was an extension of the early ISA bus specification which meant that it was backwards compatible with ISA devices. And of course EISA was an open specification. EISA supported parallel communications at a speed of 8.33MB/s.
Figure 2: Picture of Three EISA slots. Courtesy of www.wikipedia.org
Largely due to the fact that EISA was an open architecture, it quickly gained popularity in the industry. This popularity however, was short lived. EISA was soon superseded by Intel’s PCI bus.
The PCI bus is now being replaced by PCI Express or PCIe. This bus specification is really cool and blurs the line between network and bus even further. PCIe is a serial bus but pretends to be a parallel bus. It does this by having a hub on the motherboard. This hub can route device to device communications. It also allows more than one pair of devices to communicate at the same time, thus leading to parallelism. The PCIe specification allows for communications at up to 8GB/s, while PCI allows for just 133MB/s.
Direct Memory Access
As I mentioned earlier, modern computer busses can be quite complex. One complexity which greatly improves performance (at least from the user’s perspective) is direct memory access, or DMA.
DMA allows certain hardware subsystems, like graphics cards and sound cards, to access memory directly for read and write operations independently of the CPU. Of course, the CPU is still required to initiate the transaction, but DMA eliminates the need for the CPU to be involved in tedious memory transactions and thus allows the CPU to be used for other tasks.
One newer bus specification is the AMD-backed HyperTransport specification, which is developed by the HyperTransport consortium. HyperTransport supports even faster communication speeds and advanced features such as DDR, or Double Data Rate. DDR allows devices to send data on both the rising and falling edges of a clock cycle. Basically this doubles the throughput.
Another interesting feature of HyperTransport is that it supports two kinds of write commands. One write command, used for DMA, is referred to as a posted write command. Unlike the unposted write command, the posted write command does not require a confirmation signal from the target device. This combined with the fact that HyperTransport is packet based, means that HyperTransport could really be considered a network. In fact it can also be used to connect multiple computers together.
For further reading, please check out the links provided in this article. There’s lots of interesting features of these bus specifications that I think many of you will enjoy reading about. If you have any questions about any of these, or any other specification you know of, feel free to send me an email and I’ll do my best to answer your questions.
If you missed the previous parts in this article series please read:
If you would like to be notified when Russell Hitchcock releases the next part in this article series please sign up to the WindowsNetworking.com Real Time Article Update newsletter.
