3 ms·
Without having read the data sheet… It is probably to keep the devices synchronized. Reading data from an unsynchronized input takes, um, waving hands here, 2 t
by jws 5y ago
Without having read the data sheet… It is probably to keep the devices synchronized. Reading data from an unsynchronized input takes, um, waving hands here, 2 to 10 times the effort and resources.
If you are old enough to remember serial ports on computers, this is the “16 times oversampling!” bullet point. They oversampled and then state machined their way back to figuring out where the sending machine’s clock was thinking the bit changes were.
Bonus fun depressing asynchrony fact: Whenever your chip samples an asynchronous input there is a chance of the logic getting the change just at the wrong time and entering a meta stable state which is neither high nor low for an arbitrarily long time! The best you can do is minimize the probability and probable duration. So, happy new year, all your computers are just rolling dice billions of times per second.
- marcan_42 5y agoThankfully that probability decreases exponentially as you add synchronizer stages, which is what you do for clock domain crossing :-). Two synchronizer stages will give you an MTBF on the order of the square of the age of the universe, by one ballpark calculation I found. This obviously goes down as you do it in parallel many times, but still, we're pretty safe here in practice. I clearly remember having modified/written an FPGA logic analyzer that ended up entering impossible logic lockup states after a few minutes/seconds (Hardware, crashing? What?)... that was when I learned about metastability. Some synchronizers took care of the problem.
- deleted 5y ago[deleted]