I am learning computer architecture and organization.

I have this confusion, can synchronous data transfer be used for transferring large data in case of computer architecture and organization?

I have read that synchronous data transfer can be used for transferring large data but I think it is true only in case of computer networks, in case of computer architecture and organization I think DMA is used for transferring large data. So if someone asks me whether synchronous data transfer can be used for transferring large data in case of computer architecture and organization. Should I say yes or no?

  • \$\begingroup\$ I’m confused as well. Is he talking about asynchronous synchronous transfers or synchronous asynchronous transfers? Sounds like this guy wrote the Atmel SAM libraries where the words synchronous and asynchronous are used concurrently as the phy level method and the higher level software control (ie blocking and non-blocking). \$\endgroup\$
    – Kartman
    May 3 '21 at 9:32
  • \$\begingroup\$ If someone asks, you should say "yes". Given the incredibly vague nature of the question I'm sure someone could come up with an example, and it is impossible to prove a negative. Therefore, "yes" is the correct answer. \$\endgroup\$ May 6 '21 at 15:32
  • \$\begingroup\$ @Elliot Alderson I think may question is clear can you tell me exactly what you found "incredibly vague" in my question so that I can improve it. \$\endgroup\$ May 6 '21 at 15:42
  • 2
    \$\begingroup\$ What does "large data" mean? What does "transfer" mean? What does "in case of computer architecture and organization" mean? Is a PCI bus part of computer architecture? How about SATA? How do you do any transfers at all without using DDR memory busses? \$\endgroup\$ May 6 '21 at 15:47
  • 1
    \$\begingroup\$ What makes you think DMA is not synchronous? Based on your earlier questions and comments, it seems that you have a very unusual, narrow, and probably academic notion of what these terms mean. \$\endgroup\$ May 6 '21 at 17:41

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.


If the data is unimportant in the specific detail of one byte or a smallish number of bytes (such as in the data stream from a digital camera in a CCTV application) then a continuous stream is just fine. Who cares if there is glitchy data every now and then. The majority of the data gets through and old data (glitches included) gets recorded to disc (or dumped if the analysis of that remote data is done live by someone monitoring a screen).

That's a typical application where the specific data contained in one byte (or several bytes) is largely unimportant in the bigger picture (no pun intended) and, for this type of application, a continuous stream of data can be generated. If the monitor looses "lock" briefly then it's unlikely that this will be a problem so, nobody really cares.

However, if you are transferring data from multiple sensors, losing lock of the data means you'll never recover if the data is multiplexed and transmitted continuously without header information contained in the data stream.

the professor said that large number of words cannot be transferred in one go using synchronous data transfer.

Your prof may be referring to my 2nd example above.

Another example is transferring data that needs to be collected without error. You send that data in packets (containing a header and checksum for example) and, if a packet is deemed to be "faulty" (due to checksum errors) then you request the packet again. Your prof may also be referring to this type of scenario.

Of course the packet length can be long (tens of thousands of bytes) if the data link error rate is small because the likelihood of a retransmission request is low and the optimum packet (or frame) length can be quite high. On the other hand, if the data transfer is flaky (as per radio transmission of data to a remote location) then packet length must drop accordingly to suit the error rate. Retransmission of a small packet/frame takes a short time and doesn't disrupt a flaky transmission system too much compared to having to resend ten thousand bytes where only 30 consecutive bytes were "wiped-out" by a short interference surge.


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