Practically every peripheral interface, be it USB, SATA, PCIe, Thunderbolt, and even DisplayPort, uses a serial interface. That is, it transmits one bit at a time across the data channel. That seems kind of inefficient, considering that we used to have parallel interfaces that could transmit many bits at the same time. In fact, the only truly parallel interface that remains is DDR memory and inter-processor communication. So what happened? To understand this, it's best to look at several aspects of getting computers to talk to each other.

How do devices talk to each other anyway?

Through electrical signals of course! But these signals must be understood by all parties before those signals can make any sense. You might think this is as simple as sending a high or low voltage, but there are many characteristics of a signal to come into play here. These include:

• Voltage level: this is necessary for the devices to figure out what's a 1 and what's a 0. Some protocols don't have a 0V and some voltage. The official RS-232 spec for instance uses a positive and negative voltage.
• Baud (bd): this is the fastest the signal can swing between high and low states. This is somewhat interchangeable with bits per second, but technically, for example, 0000 is 0 baud while 1010 is 4 baud, even though both are 4 bps. With compression, the data rate can exceed the baud.
• Control: These are special things that happen within the signal that the receiver can use. For example, in the RS-232 spec, the transmitter sends a "start" bit that's a high value and ends with a stop bit that's a low value. Others can embed a clock signal by changing the signal between bits.

These three attributes define a protocol, or the "language" that the devices speak. Once this is agreed upon, the following happens:

• The receiver remains idle, keeping just enough things up to wait for some kind of "start" flag. In many protocols, an inactive line is 0V to avoid drawing power over the line while nothing is going on.
• The transmitter has a buffer where the next byte being sent out lives. This is kind of like the display buffer in graphics rendering.
• The transmitter sends out the data from the buffer to the receiver.
• The receiver notices there's activity, then fires up the circuitry to capture data
• The receiver polls the data line at the character rate. So if the data rate is 1 Mbd, then it will check the data line 1 million times a second.
• Data is captured into a buffer, then sent off to whoever is supposed to take care of it.

In parallel data transmission, for every bit in the buffer, there's a data line going out from it to a receiver's buffer. So if the system was a 8-bit parallel data line, it would have a byte sized buffer and each bit is connected to the other's bit line. At appropriate points in the transmission, the receiver will copy what's in the buffer to somewhere else.

In serial data transmission, each bit in the buffer is rotated out like a queue. The receiver queues up incoming bytes and at appropriate points, copies the data out to somewhere else.

What are the issues with parallel communication then?

The biggest one with parallel communication is that it requires one data line for every bit of data being sent at once. 8-bit parallel buses need 8 data lines, 16-bit needs 16 data lines, 32-bit data needs 32 lines, etc. To maintain signal integrity so that the receiver knows how to reference the voltage, typically each data line has its own ground line. You can usually get away with less, but for high-speed or lower voltage buses, you really want one ground per data line. So take what I said previously and double the lines. This is presents a problem not only with the cables, but the connector size as well. SCSI grew up to an 80-pin connector, and well, take a look at it:

By Shieldforyoureyes Dave Fischer - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=4671737

The second is that signals can arrive at different times. Electrical communication may seem instant to us, but in when the time domains are nearing nanoseconds, it starts to matter. The reason for this delay is either due to components holding up the signal to the length of the wire itself. The receiver can't know a data bit is late, so it'll take whatever is in the buffer at the prescribed time.

How does serial communication solve the issues of parallel communication?

The first is obvious, serial communication requires at most two wires total: signal and ground (ground is needed to reference the voltage). The second is that since you don't have the requirement of multiple lines needing to have their signals arrive at once, you avoid the issue of late signals altogether. As you can embed a clock signal in the data itself, the receiver need not even know the transmission rate beforehand.

However, when signals are low voltage (typically 5V or less), noise becomes a concern. In cases like this, the data is sent out as a differential pair. That is, there are two data lines, both carrying the opposite signal. If the transmitter sends out a data bit 1, it will send out +/- the voltage of the signal. For example, with USB, a data bit 1 will produce a +5V and -5V signal. The receiver then compares the two signals. If they aren't complementary, the receiver knows that bit is noise and not actual data. While this still carries the problem of signals not arriving at once, 2 lines is much easier to ensure than 8, 16, or 32. Differential signaling is also helpful in that it generates what is called a DC-balanced signal, that is if you took both signals over time and averaged it, the signal would look like a straight line. In this case, 0V.

The bit about differential signaling is important, because not only does it help prevent outside noise from ruining the signal, but at higher baud rates, the data lines themselves generate noise. This is why the Parallel ATA interface went from 40 pins to 80 pins. The extra 40 pins were ground to help shield the signals from themselves.

But aren't some buses like PCI Express, Thunderbolt, DVI, etc. parallel then since they have more than one data line (aside from transmit/receive)?

While it's true that, for example, PCI Express x16 has 16 data lines (32 total for transmit and receive), it's not a parallel interface. The way the above interfaces work is they aggregate transmitters. It's like how RAID 0 in drives work. The transmitter can either stripe data chunks and the receiver can sort them out later or each transmitter can handle a single request. This is how PCI Express can have multiple lanes. You cannot, for instance, take a 32-bit parallel interface, chop off half the wires, and expect it work since it was designed to have all 32-bits be sent out and arrive at once.