I think "async/sync" and "serial/parallel" are orthogonal concepts. There can be 4 combinations of communication types:

  1. async serial
  2. sync serial
  3. async parallel
  4. sync parallel

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?

  • \$\begingroup\$ There's even Wikipedia articles about these concepts, have you found them? \$\endgroup\$
    – Justme
    Feb 12, 2022 at 11:35
  • 1
    \$\begingroup\$ Yes. I am reading them. And I also post question here in case I am lost in too many concepts... \$\endgroup\$ Feb 12, 2022 at 11:54
  • 1
    \$\begingroup\$ If you talk about a "serial port" without qualification, it's reasonable to assume RS232 simply from its ubiquity. You can now search RS232 and find its characteristics which will answer the main question. The other question : Yes, lots. \$\endgroup\$
    – user16324
    Feb 12, 2022 at 13:52
  • \$\begingroup\$ Related electronics.stackexchange.com/questions/486687/… \$\endgroup\$ Feb 12, 2022 at 17:27
  • \$\begingroup\$ If you want to know more about what the book refers to when it talks about "serial port", here is the author web page for the book, including a freely downloadable index and first chapter which defines what the book is about : janaxelson.com/spc.htm \$\endgroup\$
    – Justme
    Feb 13, 2022 at 13:46

4 Answers 4


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.

  1. Synchronous serial is used by USART, which is an UART with a clock. SPI is also synchronous serial, and I2C.

  2. 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.

  3. 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.

  • 2
    \$\begingroup\$ Your extended definition of synchronous is incorrect. Manchester encoding and data scrambling require clock recovery and these are both regarded as synchronous transmissions. \$\endgroup\$
    – Andy aka
    Feb 12, 2022 at 12:22
  • \$\begingroup\$ You're right, it was unclear, I replaced "should" with "must" \$\endgroup\$
    – bobflux
    Feb 13, 2022 at 18:56

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: -

enter image description here

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.

  • 2
    \$\begingroup\$ I don't see how you can claim the quote is incorrect - it's not saying that all serial data transfer is asynchronous, IMHO it's effectively saying something along the lines of 'What most people call a serial port is a UART' \$\endgroup\$
    – NMF
    Feb 12, 2022 at 12:39
  • 1
    \$\begingroup\$ It is incorrect - there; I said it again. In engineering, we strive for precision and exactitude. \$\endgroup\$
    – Andy aka
    Feb 12, 2022 at 12:44
  • 2
    \$\begingroup\$ The book is about PC serial communication ports, or COM ports, so in that context a serial port specifically means just that specific type of port. Later on the book was extended with USB when it came to PCs. \$\endgroup\$
    – Justme
    Feb 12, 2022 at 12:52
  • 2
    \$\begingroup\$ The serial port is still very much relevant everywhere, so I bet most people would describe "serial port" as the 25-pin or the IBM-specific 9-pin serial interface which uses RS-232 electrical signaling with UART for data framing. It is rare to see other ports being called as serial ports, even if they did use UART for serial comms, such as some RS-422 interfaces, MIDI or DMX512. \$\endgroup\$
    – Justme
    Feb 12, 2022 at 13:08
  • 2
    \$\begingroup\$ @All - Please be nice - see the site's Code of Conduct. As a mod it's impossible to keep everyone happy, but some comments were deleted after things became too personal. Polite constructive criticism is allowed in comments (with the emphasis on polite & constructive) but ad hominem attacks are not. And while I take great care not to be heavy-handed as a mod, these situations happen much too often. If you can't "be nice" in a reply, then don't reply. See here. \$\endgroup\$
    – SamGibson
    Feb 12, 2022 at 15:20

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:

  • non-self-clocked: bit clock is inferred from format. Example: UART.
  • in-band self-clocked: bit clock is encoded in the bit stream. Example: SPDIF
  • out-of-band clocked: bit clock is sent separately. Example: I2S

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.

  • 3
    \$\begingroup\$ In UART data, the receiver's clock isn't recovered from the data being sent; the receiver's clock is fixed and free-running but, it also has to be no more than a few percent different to the transmitter's clock frequency hence, both ends "agree" on the nominal baud rate before hand. In summary: asynchronous data reception does not recover the clock from the transmitted data. Synchronous data reception does recover the clock (or uses a clock transmitted separately by the transmitter as in a USART or SPI). \$\endgroup\$
    – Andy aka
    Feb 12, 2022 at 16:18
  • 2
    \$\begingroup\$ " a UART receiver samples the start bit to determine the bit cell timing." - No, it doesn't. It assumes the bit cell timing, which is why the baud rates at transmitter and receiver have to be very close for reliable communications (<+-5% difference for 8 bits). \$\endgroup\$ Feb 12, 2022 at 17:44
  • 2
    \$\begingroup\$ @Andyaka You confuse the receiver’s master clock with the synthesized bit clock. A designer, in theory, could create a circuit to analyze a UART stream and make a pretty accurate representation of the transmitter’s clock. This isn’t necessary to receive UART data since it re-syncs on frame boundaries, but if it were to do so then in theory higher rates could be supported, since framing would be synchronous. \$\endgroup\$ Feb 12, 2022 at 17:46
  • 2
    \$\begingroup\$ "...no perfect-sync clock reference. The method of solving it depends on the protocol in use" - It is not possible to reliably extract a clock from asynchronous serial. Each frame is self contained and has no relationship to any other. A stop bit will begin some time after the start bit begins, but unless you know the bit time you can't tell if the next '1' is a data bit or the stop bit. You have to know the exact bit rate. Not to say you can't do 'synchronous over async' by putting clock info in the data (eg. sending a particular character to 'train' the receiver). \$\endgroup\$ Feb 12, 2022 at 18:56
  • 3
    \$\begingroup\$ The 'A' in UART is for asynchronous. The receiver free-runs at local clock, and thus can only receive with some tolerance due to the oversampling usually involved. The transmit clock is never regenerated at the receiver as it is not needed. The clocks just need to be close enough for a duration of a frame and the receiver begins frame reception only after detecting a start bit. So it easily allows transmit and receive clocks to free-run and have approximately 2% difference in speed. \$\endgroup\$
    – Justme
    Feb 12, 2022 at 19:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.