The lecture is very confusing, because he mixes several different meanings of "synchronous" and "asynchronous".
At the lowest level, synchronous means:
- The source and destination of the transmission are synchronized explicitly with a clock so they both know when the bits should be sent, and when the bits are valid and should be read.
This is the case in most memory interfaces, most older/low-speed CPU busses like PCI.
"Source-synchronous" is a variant where the source sends the clock along with the data. If clock and data go through traces with the same propagation time (no skew) they arrive at the destination properly aligned, and the receiver gets both the bits and the clock it needs to know "when" the bits are.
In this context, "asynchronous" means the opposite: there is no dedicated clock signal, which usually indicates the data is encoded in a way that allows the receiver to figure out when the bits are in the signal and how to decode them properly. It could reconstruct a clock with a PLL, or it could use oversampling, or any other technique. For example, UART, USB, Ethernet, SATA, etc.
"Synchronous logic" means a digital circuit in which the changes in the state of memory elements are synchronized by a clock signal. That's your usual logic using flip-flops, registers, etc. The opposite is combinatorial logic, which doesn't use any clock, but can't implement sequential operations like a CPU executing instructions because there is no clock to synchronize to.
But "Asynchronous" can also mean that the peripheral has some form of handshaking to indicate to the CPU if it is ready, or if it has finished the requested operation, or flow control, etc.
Confusion comes from the fact that the signals used to implement this can either be synchronous or asynchronous.
For example if you have a FIFO chip, it'll have some signals like "full" or "data is available, you can read it", "read", "write", and some lines for data bits. Say you want to read from it, first you have to check if there is data in it, then pulse read, then it outputs the data, and you read the data. And before reading again, you have to check that you didn't read the last byte in it, which would mean it's empty and you have to wait for more data.
All this handshaking could be called "asynchronous" but the signals themselves can either be...
asynchronous signals: in this case there is no clock, and for example pulsing "read" would increment the address...
or the signals could be synchronous, with a clock, so holding "read" active would make the FIFO output one byte every clock until it's empty.
It's the same with a SD card: the interface is synchronous, with a clock. But the device uses handshaking: you must wait until it is ready to accept data if you want to write to it.
But "synchronous" can also mean source and destination both agree that each bit, or information packet, or video frame, or audio sample, or whatever, will be transmitted on a regular schedule, for example one video frame per second. This is independent of the low-level electronic implementation of how the data will be transferred.
For example, USB audio sends X packets of audio data per millisecond, whether the device reads them, stores them, or not, it doesn't care. This is real time data, so it is not possible to wait or buffer the data: if it arrives after the time it was supposed to be played back in the speakers, then the data is useless. For lower confusion, USB calls this "isochronous" instead of "synchronous"...
...and then it reintroduces "synchronous" and "asynchronous" depending how the internal clocks of the host and device are synchronized together and who the clock master is.
The lecture also confuses polling, busywait, and other ways of waiting. Also it seems this guy has never heard of scatter gather DMA.
If you want to write to a peripheral that will have handshaking or waits, like a FIFO or a harddisk, then, from slowest to fastest:
Polling/busywait: the CPU waits in a loop, continuously asking the device if it is ready. This can be done with or without clock.
Interrupt: the CPU tells the device "call me back" and starts doing something else instead of wasting time waiting. When the device is ready, it triggers an interrupt that makes the CPU execute (or resume) the code that was waiting for the device to be ready.
There is no fastest option between these two, it depends: if the wait time is lower than the interrupt latency, then polling is faster. If the wait time is very long, then polling would waste a lot of time, and interrupts won't result in faster transfers, but the CPU can do something useful instead of waiting.
Next, DMA: that's when the CPU hires an assistant to do the above. So it tells the DMA core to transfer data from/to the peripheral, and the DMA core does all the low level work, waiting, signalling, etc while the CPU does something else. That's of course much faster, but the way the CPU and the DMA core communicate is the same as it would communicate with the device. For example the DMA core will raise an interrupt when it has finished. It just happens much less often, since the DMA core can transfer a whole block of data with one CPU operation.
Next is scatter gather DMA, when the CPU hires another assistant to talk to the DMA core: instead of passing just one block of data at a time, the CPU gives it a list of blocks to transfer. That reduces the number of interrupts and streamlines the process. It isn't reasonable to do highspeed stuff like USB2 or Ethernet without it.
in the video lecture that I watched the professor said that large number of words cannot be transferred in one go using synchronous data transfer
This is wrong if you take it literally, but I think I get the meaning. You can transfer an unlimited amount of data with a synchronous transfer, but at some point, you'll probably need to know if the device needs to wait, or if it is full, which means some handshaking will have to occur.