I think "async/sync" and "serial/parallel" are orthogonal concepts. There can be 4 combinations of communication types:
From the book "Serial Port Complete", I read this:
In common use, the term “serial port” refers to ports that use a particular asynchronous protocol.
It seems it is referring to the type 1 above - or it is treating serial and async as synonyms of each other?
Do the other 3 combinations exist? Any examples?
Yes, a "serial port" traditonally means the so called COM ports on PCs and other devices, which are serial communication ports that use the RS-232 electrical signaling with an UART to handle the serial communication, and an UART uses the asynchronous start-stop framing protocol for data transmission.
So no, the serial and asynchronous are by no means synonymous.
There many are other kinds of ports that are serial too, but they are just not called as the "serial port".
The other examples exist too.
Synchronous serial is used by USART, which is an UART with a clock. SPI is also synchronous serial, and I2C.
Asynchronous parallel means something happens asynchronously without a clock or data strobe. Sure, you can for example just make a R2R DAC and put it on 8 parallel data lines. There is no clock or strobe signal needed, the resistors will convert the 8-bit value to analog voltage output whenever there is a change on data bus. This is only an example and bad one too.
A lot of devices and chips have synchronous parallel buses. For example synchronous memory modules have parallel bus and a clock for determining when something should happen on the parallel communication bus.
Justme and Andy raised an interesting point in the comments, about the meaning of "synchronous" and "asynchronous".
I first went with a strict meaning of "Synchronous means transmitter and receiver run on the same clock, so there is no need to for clock recovery in the receiver." That covers "source synchronous" if the source transmits the clock on a dedicated clock trace/wire alongside the data, but there are other options, for example both transmitter and receiver could be clocked by something else.
With an UART, characters are sent... when they're sent. Even in a "continuous" stream of data there can be random pauses between characters which are not integer multiples of the bit duration. So the receiver must synchronize on the start bit of each character and then sample the subsequent bits according to the preset baud rate.
Now when the clock is not explicitly transmitted but instead embedded in the signal (Manchester, SPDIF, USB, etc) and has to be recovered by the receiver, I called this "asynchronous" by mistake, but it's in fact synchronous.
To add a layer of confusion, it is absolutely possible to decode slow synchronous protocols like SPDIF, USB1, Manchester, etc with an asynchronous receiver which samples the signal at a much higher frequency. This gets several bits per actual signal bit, then looks at the duration of one and zero levels and/or transition times, and decides what the data should be without having to recover any clock.
Soo... "synchronous" would in fact be a property of the transmitted signal, meaning it is synchronized with a clock of constant frequency (no possibility of random duration pauses between characters like for a UART).
async serial: UART
sync serial with separate clock line: SPI, I2C, I2S, HDMI...
sync serial with embedded clock: SATA, USB, SPDIF...
sync parallel: all synchronous RAM interfaces, DDR, most buses (PCI...), PATA, SCSI...
Having a separate clock line avoids the need for clock recovery, but clock and data must arrive at the receiver with proper timing. Synchronous parallel systems usually require all data bits to arrive at about the same time too.
The difference in arrival time between all these signals is "skew", and if there is too much skew, some of the btis will be early, some will be late, some will be in transition when they should be steady, and it makes a mess. So you get wiggly traces on your motherboard between CPU and RAM to make sure all the lines have the same length. PCI bus was the same story, but in hard mode: adding cards in your PC adds capacitance to the bus along with reflections and signal integrity issues due to tapping a transmission line, which means maximum possible skew increases the further away from the bus master you are, and on top of that it depends on what's plugged. That's why PCI never reached high clock speeds, and PATA required those special snowflake cables to run at high speeds.
In addition, if it's a bus, it'll be half-duplex, only one master is transmitting at a time. If it's RAM, either it reads, or it writes, but not both. And if it's synchronous, then you have another problem: if the length of clock and data are matched, then when the CPU sends data and clock to the RAM, it will all arrive in sync. But when the RAM sends data to the CPU, then it won't be in sync with the clock sent from the CPU due to roundtrip delay. So you get rather complex systems with PLLs and propagation delay compensation, etc. If it's parallel, the higher the bitrate, the more headache, including per-pin skew compensation, etc.
That explains the popularity of serial stuff: PCI-e can use many lanes but they're all independent, there is no main clock, it's all fully asynchronous, and skew requirements between lanes are much less of a problem.
async parallel: hmmm...
That could mean "lots of serial links like PCI-e" but that's not really "parallel".
It's a bit of a paradox to define this last one. If you're controlling a bunch of stuff with GPIOs, it could be argued this is "asynchronous parallel", with each bit having some special meaning to the receiver. However, if it's really a parallel port and the bits are transmitted asynchronously, it means going from "00" to "11" will go through a "10" or "01" state if one signal switches faster than the other. That's only usable if you don't care what happens during the transitions.
Here's your quote (all I have to go on): -
In common use, the term “serial port” refers to ports that use a particular asynchronous protocol.
And, it is incorrect because serial data can be synchronous or asynchronous.
All four types you mention exist: -
Manchester encoding of serial data is a good example of synchronous serial data. So are serial transmissions that scramble the data to ensure the bits are toggling quite often thus allowing a clock to be extracted.
A UART transmission is a good example of asynchronous serial data.
Just a plain ordinary parallel byte can be regarded as asynchronous if the succeeding logic does not have a clock input.
If the parallel byte is presented with a clock signal, then this can be regarded as synchronous. The good old fashioned Centronics printer port falls into this category.
For the objectors and downvoters, this is the book's front page and note that it contains the word USB and, USB is a synchronous data transmission: -
Also note that I was very clear in my opening phrase that the quote was "all I had to go on" hence, without any other context, I was correct in saying that the quote was incorrect. The term "serial port" (in a book called "Serial Port complete") that covers USB has to mean any serial port and, that includes asynchronous as well as synchronous serial ports.
tl; dr: async/sync and serial/parallel are orthogonal concepts. But further, perhaps in the interests of simplicity, the authors chose to overlook the bigger picture: clock coherence.
Synchronous vs. Asynchronous
Asynchronous in the author's context means that the transmitter sends no clocking information to the receiver. The receiver must infer clocking based on other information.
The authors say ‘asynchronous’ but really they mean non-self-clocking. Their naïve misunderstanding does a disservice to both the interface-level and system-level understanding of clocks.
Bear with me here, I'll explain below.
Link partners using a bit-serial digital interfaces can synchronize bit timing in three ways:
UART serial data format includes start/stop bits that provide information to identify frames. UART data isn't self-clocking, only the data bits are sent (plus start/stop, and parity if enabled.) Instead, UART bit boundaries and sample points are understood by shared agreement between the link partners on the sample (baud) rate and format, with timing specified from the start bit.
So when we say a UART link is ‘9600-N-1’: we are specifying this agreement; the UART receiver synthesizes a bit clock based on it. This locally-created bit clock is a facsimile of the sender's bit clock, and is roughly synchronized with it.
Faster serial interfaces don’t tolerate the relatively imprecise bit timing used for UART. Instead, the transmitter provides a clock. There’s two ways it can do that: by a separate wire (out-of-band) or by encoding it with the data (in-band).
SPDIF, used for digital audio, is an example of a self-clocked interface with an in-band clock. It uses biphase-mark (differential Manchester) encoding that guarantees a signal transition on every bit. This allows the receiver to extract the bit clock with less jitter (important for digital audio work) than frame-based methods. For framing, SPDIF uses reserved patterns called preambles to identify blocks of data.
I2S, also used for digital audio, is a example that uses an out-of-band bit clock. I2S data frames are aligned with an out-of-band 'word select’ signal.
Here's the thing. Regardless of the origin of the bit clock, whether it is sent out-of-band, in-band or synthesized (as in a UART), this clock is synchronous to the sender's timebase. It has to be to recover the data, which is also in the sender's clock domain. All three methods arrive at the same place: serial data, clocked in by a bit clock at the receiver.
However, this receive-side version of the bit clock isn't necessarily synchronized to the receiver's timebase. That is, the link partner timebases are not guaranteed to be coherent with each other. They could be in different clock domains. In system terms, this is an asynchronous clock domain crossing. This turns out to be far more important than the details of how the receiver clocks in bits.
Sometimes timebase coherence doesn't matter. Sometimes it matters a lot. A UART transferring a text file doesn't care about coherence, but there is still a clock domain cross internally that might be resolved by a FIFO for example. An audio DAC playing SPDIF absolutely cares about it: missed samples mean clicks and pops in the audio.
Parallel vs. Serial
When we think about multi-bit parallel, there’s a tendency to assume that these are synchronous interfaces, because how else can you deal with the inter-bit skew otherwise? Asynchronous parallel just doesn’t seem possible at first glance.
But it is: by embedding clock timing in each parallel data bit, each can be self-timed and clocked by the receiver.
And that’s exactly what’s done in PCI Express. Each bit - or lane - carries timing information along with data, which the receiver recovers per lane.
The PCIe lanes of course share a common transmit clock, and inter-lane skew is controlled so that the receiver can assemble them into bytes, but nonetheless each lane is self-timed.
PCIe also has the system-level clock coherence issue. It does however support both a coherent timebase (like most PCs do) by providing an out-of-band clock, or a source-synchronous timebase where the receiver recovers the timebase from the stream.
