I already tried googling but I cannot find an exact answer. Some say it is synchronous, some say asynchronous.
For example, see these links:
https://www.quora.com/Is-Ethernet-synchronous-or-asynchronous
Ethernet has no separate wire for clock signal, so does it make it asynchronous?
But Ethernet also does not use start and stop bits, so does it make it synchronous?
And by the way, can we encapsulate Ethernet into RS-232? That is, can we use RS-232 to carry or transport Ethernet?
Ethernet has no separate wire for clock signal, so does it make it asynchronous?
Not having a separate wire means nothing.
Some Ethernet data uses Manchester encoding and some use data scrambling. Both allow the receiver to lock-in to the data and are therefore regarded as synchronous. Note that you don't need to transmit clock separately to data to have a synchronous data link; if the clock can be merged with the data and successfully recovered as an entity in its own right then that makes it a synchronous transmission.
I am certainly not speaking for all variants of Ethernet; just the ones I have some knowledge of i.e. 10 Mbits/sec (Manchester encoding) and 100 Mbis/sec (Scrambling).
Maybe read A Beginner’s Guide to Ethernet 802.3 written by Analog Devices.
can we use RS-232 to carry or transport Ethernet?
Then it wouldn't be Ethernet. You can use RS232 to carry a payload of data at a fairly modest speed over a short distance so, if you can live with that limitation (why would you?) then you can repackage an ethernet frame and send it via RS232.
I think you're getting multiple answers, because the real answer is that you can't quite wedge what the various flavors of Ethernet are into the definitions of "synchronous serial" or "asynchronous serial". In fact, not all Ethernet flavors are entirely serial, because they involve parallel wires.
Ethernet has no separate wire for clock signal, so does it make it asynchronous?
But Ethernet also does not use start and stop bits, so does it make it synchronous?
Most Ethernet flavors have framing bits, that establish both the start of the frame and that prime the bit timing recovery circuitry of the receivers. You could, given enough beer, convince me that these are "just start and stop bits" -- but after I sobered up, I may no longer agree.
Ditto convincing me that they cannot be start and stop bits.
And by the way, can we encapsulate Ethernet into RS-232? That is, can we use RS-232 to carry or transport Ethernet?
In a sense, yes. You could design a protocol that would encapsulate Ethernet frames and send them via RS-232. Or semaphore, if you could find a patient enough pair of sailors. Or just about any other sufficiently flexible means of transmitting digital information. Delay would be an issue, so you'd probably need something that acts more like a switch than a bridge.
Since most Ethernet communications is using Internet Protocol, your best bet is to not try to wrap Ethernet in serial, but rather to use PPP, which is well-established, solid, and just works.
It really depends on which particular Ethernet interface is in question, there is no "the" Ethernet interface so there can be no single answer.
For example, Ethernet between a MCU and PHY typically uses the MII bus, which is synchronous interface. It even has two clocks, one for transmitting data, and one recovered for receiving data. The RMII combines the clocks into one which means the PHY has to have a data FIFO to tolerate clock differences between devices.
And it is true that for example 10 Mbps and 100 Mbps sent over copper wires have no separate clock. But the data is sent with a coding to allow the reciver to recover a clock. 10Mbps Ethernet uses Manchester coding where there is always a transition in the middle of a bit. As the bus is idle the data preamble gives the receiver time to lock on to the clock for every packet. 100Mbps Ethernet uses 4b5b coding of data to provide clock transitions, and an IDLE symbol is being transmitted continuously so the receiver never loses synchronization while the link is up.
So, does it have a clock line? Yes at the PHY MII level, no at the medium, as it is embedded in the data. Is this synchronous or asynchronous? It depends on the definition. The clock must and will be recovered at the receiving end to receive the data symbols correctly.
Regarding if Ethernet traffic can be sent over RS-232, you have to first understand that RS-232 is a standard for only an electrical interface, it does not take any part which data is sent and how to send it. I have to assume you mean the typical usage of RS-232 serial ports which use an UART to transfer data. Yes, SLIP protocol was used already over 30 years ago to transfer IP packets over a serial interface instead of Ethernet interface. So yes, you can basically send Ethernet data over RS-232 if you want.
Ethernet, in its various forms, embeds clock timing in the stream (such as the Manchester encoding used for original 10Mbit Ethernet), or provides a means to identify and recreate the clock to properly decode symbols using special markers.
Either way, the timing for this embedded clock comes from the transmitting source, and the receiver is obliged to recreate it locally. It does so as long as it can see a signal from the transmit link partner, for the duration of a packet. The receiver compensates for any mismatch (drift) between the two clock sources as it recreates its local clock.
UART receivers also recreate a local clock using two things: a shared understanding of the baud with the transmitter, and alignment of its sampling clock using the start bit. But unlike Ethernet, the UART recovered clock is only effective for one frame time (typically 10 bit times including start and stop for 8N1 serial.) It’s not continuous. Successive UART frames have no known phase or delay to each other.
This is a long-winded way of saying that UART is asynchronous, while Ethernet is semi-asynchronous, or more precisely, plesiosynchronous at the packet level. That fancy term that sounds like a the name of a dinosaur just means that the link partners use a similar clock frequency, but the clocks at each end are not locked to each other.
Ethernet packet-to-packet timing isn’t defined by a clock however, so in a broader sense Ethernet is asynchronous.
The Ethernet receiver has to compensate for any drift between the transmitter and its local clock. As it is, Ethernet is packet-oriented, with data flow is managed in higher levels of the protocol stack to avoid over- or under-run conditions.
As far as how data get sent, that's a higher-level question.
You can encapsulate serial UART (byte-oriented) streams over Ethernet, as an application-to-application connection. A common way to do this is by a software mechanism called sockets. A socket is basically a serial data tunnel through an IP network, and looks like a physical serial port to the application.
You can also send IP streams over a UART, using protocol like PPP or SLIP. This method is how a serial modem provides an internet connection. PPP still persists within cellphones for example, as the protocol used to connect the phone’s application processor to the baseband radio, and it shows up with other modems as well.
So you can wrap serial in IP and send it over Ethernet, or you can wrap IP in serial and send it to a network. Confusing? You bet. Lucky for us, there’s a roadmap that explains this, called the OSI layered network model. More here.
As you look OSI, consider the interfaces and how they’re used and use the OSI model to help determine the ‘who encapsulates who’ untangling. OSI also is helpful in understanding how to make application frameworks that are network-independent.
”smells like seven layers, that beaver eatin’ Taco Bell” - Les Claypool
Ethernet wave forms bring both data bits and synchronization bits.
Clock bits are encoded in the waveform and are recovered in realtime by the receiver.
The receiver uses the recovered clock bits to synchronize the recovery of the data bits.
Ethernet is a synchronous interface because the stream contains both data and clock information.
Asynchronous for sure. Commonly for a bus synchronous means there is a separate clock signal used by the receiver to sample the data.
Ethernet: no separate clock, and clock signal is recovered from the encoded wave pattern.
RS232: no separate clock, and the sampling clock is generated from native clock at the receiver. So you need to tell the receiver the clock speed of the transmitter or the receiver can't receive the data correctly. This works since UART is received word by word, at the begining of each word, the clock is aligned with the transmitter and the clock won't shift too much during a single word.
Ethernet doesn't have start bit, but it will have start pattern.
Asynchronous usually means that the data stream is not coded in a way that facilitates clock recovery. The transmitter and receiver clocks are not synchronized - they free-run, and the encoding is such that the receiver resynchronizes itself at some "start of frame" marker, but never adapts the clock frequency. That's RS-232 (among others).
On the other hand, all Ethernet copper and fiber is coded to facilitate clock recovery and thus the receiver clock aligns to the transmitter clock. Ethernet is definitely synchronous, even though no separate clock lines are needed: the data is self-clocking synchronous.
UARTs, as usually implemented, are not synchronous because the frequencies of the clocks are independent. Only a time reference is shared via the start bit, but the rising/falling edges are not used to adjust the frequency of the receiver. The oversampling used by UARTs is not clock recovery - it's clock phase realignment at the start bit. The frequency never changes.
With Ethernet, the receiver clock gets continuously phase-locked onto the recovered transmitter clock, forcing the frequencies to be equal as well.
It is possible to turn the "asynchronous" serial connection into a synchronous one. It requires special hardware though:
The transmitter must synchronize transmit edges to the x1 baud clock. Normal UARTs begin the start bit at the "next available" edge of a x16 baud clock, i.e. they issue the start bit as soon as possible, and not at the next x1 bit slot as referenced to previously transmitted symbol.
The transmitter must not revert to the idle state, and should be transmitting idle symbols instead.
The receiver must have a PLL with a narrow capture range - say +/-10% of the baudrate. The loop filter needs a time constant of several tens of bit periods, so that the clock phase can carry across the missing edges between the start bit and the stop bit.
When that's done, the receiver operates on a x1 clock, and a simple shift register can be used to deserialize the data, using the start bit as a trigger to copy the data to the output register, and reset the shift register to the idle state (all 1s).
I have seen UARTs implemented that way in some old homebrew computers. Perhaps the designer just used what they had on hand, without having to wait for a UART to arrive.
Ethernet is neither synchronous nor asynchronous serial communication. It uses a packet-switched network protocol based on frame-based transmission. It is different from traditional serial communication.
