We know that each component has different frequencies, but what happens when a fast component directly comunicates with a slow one?
$\begingroup$ (I remember the term connected components from graph theory, not hardware.) $\endgroup$– greybeardAug 16, 2020 at 19:50
$\begingroup$ I couldn't find a tag so I didn't had much choice (I edited now) $\endgroup$– LagaggioAug 16, 2020 at 19:53
$\begingroup$ Did you have a specific architecture or type of hardware in mind? For example mixing RAM speeds means you may need to manually over click one or have them running at the slowest of the speeds. Can you add some more specifics about the problem to the question? $\endgroup$– C8H10N4O2Aug 16, 2020 at 20:13
$\begingroup$ Just generally speaking about any component, just what happens when a fast comunicates with a slower one.(Directly) $\endgroup$– LagaggioAug 16, 2020 at 20:44
$\begingroup$ @ C8H10N4O2 What do you mean by over click? Select them manually? $\endgroup$– LagaggioAug 16, 2020 at 23:43
I think what you're asking is how two machines or components, which run at different clock speeds/phases, can communicate. The short answer is that the receiver synchronises to the sender.
In low-speed communication channels (e.g. I²C), this can be achieved with an explicit clock line. Essentially, the sender has a separate wire that is the transmission clock. This is also generally the way that things work with parallel busses (e.g. where you send 8 bits over 8 wires plus a clock).
This doesn't work as well at high speed, because a small difference in the lengths of two wires can cause signals to arrive at different times. It also doesn't work over channels where there you don't or can't have more than one "wire", such as radio.
If you only have one "signal" (be it a single pair of wires, single radio frequency, or what have you), you are in the domain of line coding.
In that case, the receiver can synchronise by looking for edges in the source signal. There is an agreed-upon clock rate, which neither end can reproduce perfectly. But if the sender sends the message
00101001, for example, every time the bit flips from
0, that is something that the receiver can synchronise to.
Exactly how to synchronise clocks is a question for electronics engineers, who can explain techniques like phase-locked loops to you better than I can. It's a little subtle because the receiver can detect edges, but ideally wants to take its sample from the half-way point between the leading edge and the trailing edge, so there has to be some kind of delay involved.
But what if there are no edges? If the transmitter wants to send a whole bunch of zeroes, how does the receiver synchronise then?
The way around this is to design a code which does have transitions. RS-232, for example, specifies that each byte begins with a start bit, and ends with one or more stop bits, and there is a zero between the two frames, so every byte effectively has the bits "101" between bytes.
Medium-speed channels where retransmission is not an option (e.g. digital broadcast, satellite/spacecraft communication, or recording media such as optical disks) will often use error-correcting codes to achieve the same effect. Not only do you get error correction, the extra redundancy gives plenty of opportunity for clock synchronisation.
And then, you get into physical problems to do with the fact that you're communicating over physical wires or physical radio signals.
Over wires, for example, it's desirable to design a code with approximately the same number of 0 bits and 1 bits, a property known as DC balance. Real pairs of wires will act like a capacitor at high speed, and so if you have (say) more 1's than 0's, they will retain a charge and hence resist sending 1's. An example of a code designed for this is 8b/10b, which is used in a lot of modern high-speed serial communications such as HDMI, SATA, Gigabit Ethernet, and USB 3.0.
See this question from electronics.SE for further details.
Radio communication (e.g. Wi-Fi and cellular telephony) has its own problems that I can't really cover here, even if I understood it all. You have to protect against the Doppler effect, destructive interference caused by reflections, and so on.
what happens when a fast component directly comunicates with a slow one?
They must both be able to communicate and the same speed, regardless if it an async or sync type channel.
Consider the channel capacity as the block rate on average or burst mode. In any event each side must either acknowledge ready or not (eg DTR DSR) or (ACK NAK) unless it is something of lower value then it may not and just stream it and hope the recipient can keep up without errors E.g. streaming Video, UDP.
I have a 1Gbps ethernet connection to router, but only 100 /5 Mbps modem so the channel capacity is limited by the thruput limitations of the weakest channel and host which is often somewhere on the web.
A slow firestick might be able to stream HDMI video at a Gbps video speed yet never be able to process video internally at that speed.
To enhance byte thruput, the penalty is latency but the benefit is slack time to load each word. E.g. DS1 digital audio might have 1 byte buffer for low fixed latency per repeater even if MUX’d from 1.544 Mbps to OC96. Whereas a UART usually has 16 byte buffer for Rx to handle interrupts without buffer over-run flag being set.