The Efficiency of Moving Bits - Part 2
In my last post I talked about life as a designer in the early 1980’s… it’s funny to look back and think of what we thought was “amazing technology” – some more of which I’ll discuss today. I’m sure someone reading this could comment on engineering marvels of the 1960’s as well.
I’m going to continue my discussion on moving bits with some comparisons of bus architectures from that time and today. We’ll take a look at how much has changed and the evolution of connecting systems and subsystems together. I’d like to start with the S-100 bus which was essentially the Intel 8080 processor’s external bus, but not many engineers might remember that architecture. I had friends that owned (yes, owned) the IMSAI 8080 and built automated amateur radio repeaters using these machines as controllers. My first “computer” designs used the ISA bus made famous by IBM in the PC released in August of 1981 (I purchased one of those early machines and was the first geek on the block to show it off!).
The ISA or Industry Standard Architecture bus was not a standard (yet) when IBM introduced it in their PC. Actually, the fact that IBM published a technical manual that including a listing of the BIOS (Basic Input Output System) source code and complete schematics, made it quite easy to clone… I still don’t understand that decision. This basic 8 bit bus originally ran at 4.77 MHz (like my old machine did), but later was enhanced and supported an 8 MHz clock, so every 250nS, 8 bits were transferred over the bus. To actually move data into RAM or read an I/O address several cycles of the bus were required to latch the address, allow for settling of the bus, and give time to the peripheral to respond.
As processors improved in speed, buses needed to keep up. The first logical step was to simply speed up the clock (as IBM did from the original PC 4.77 MHz clock to the 8 MHz clock in the XT) or use both edges of the clock. Additionally, by making the bus “wider” with more communication lines (e.g. 8 bits to 16 bits and beyond) also improved performance. The bus wars raged for years getting ever wider and faster. As engineers, we continued to look for ways to move more data between subsystems and this led to us bumping into the physical laws of nature… primarily skew between bus lines and waveform distortion. It was even more difficult if you wanted to extend the bus farther than the 10 inches inside the chassis, which at times seemed almost impossible.
It seemed counter-intuitive that the solution would be to move away from wider buses and serialize the data, but this is exactly what happened. As the speed of the buses increased, there was little margin between each communication line (i.e. data, address, or control signals). A tiny amount of skew would cause errors in the transfer of data. Additionally, the mechanics of connecting large numbers of lines to a circuit card added expense. Serializing the data reduced the number of mechanical connections, reduced or removed issues with skew, and had one additional feature – it reduced the overall power consumed. This was accomplished by moving away from large voltage-swing technologies such as TTL and using devices based on LVDS. Additionally, bus designers could now have point-to-point connections to each peripheral due to low connection count (e.g. PCI Express) which greatly improves bus bandwidth. An example is the DS92LV16 SERDES (Serializer / Deserializer) transceiver. This device simply takes 16 data lines, serializes them, embeds the clock transports it to another DS92LV16 which reconstructs the 16 data lines and clock. This is a transceiver so it has an upstream and a downstream and is LVDS based so it uses 2 wires for each path (4 wires total).
To compare old bus architectures such as ISA with serialized LVDS, we’ll need to define the parameters. In my old ISA designs, I decided to use buffers to drive the data over the back-plane (rows of 62 pin edge connectors). I needed enough drive to make sure the loading caused by a full complement of circuit cards would not degrade the speed of the edges. The buffers were industry standard 74LS24x TTL level buffers. I needed one 74LS245 and two 74LS244 buffers to drive the address lines. There were others for control and bus management, but we’ll use only the 74LS245 for simplicity. The bus was about 10 inches long (0.254 meters) and the transceiver consumed about 250 milliwatts (with a supply current of roughly 50 mA at 5V).
If we apply the equation from last week’s blog post to calculate energy per bit-meter for the old ISA bus we get 15.4 nJ/bit-meter. This is using the bus clock rate, not the bus transfer rate. The calculation for the serialized bus running full duplex to the peripheral, we get 1.6 nJ/bit-meter over the same circuit card – an almost 10 to 1 improvement in data transfer energy efficiency. These calculations are for a single end of the connection. This ISA example does not take into account all the supporting bus electronics since it was a shared bus. The serialized bus is much simpler since it connects directly to a single peripheral and can have multiple peripherals communicating with the host at the same time.
If you look deeper, the older parallel bus architectures are even less efficient at moving data than stated above. If you think about extending the bus to an external chassis (i.e. 1 meter or more), the problems really pile up for parallel buses. Serialized buses simplify everything from the connector to cable (with less wires) and even the number of connections to processors or FPGAs and are far more efficient at saving energy when moving data.
Let me know your stories or opinions by commenting on this blog or dropping me an email. I’d love to hear from you. Until next week…
Recent Comments