Timeline for How to cross clock domains efficiently?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 14, 2017 at 17:02 | comment | added | supercat | ...that would depend upon what was being controlled and the consequences of any possible errant behaviors. | |
| Apr 14, 2017 at 17:01 | comment | added | supercat | @duskwuff: Such presumptions are in a sense "cheating", since any circuit could be made to pass timing analysis if the timing analyzer is told to assume that critical parts will magically work. On the other hand, it would be impossible to make any designs with independent dual clocks pass timing analysis if the analyzer isn't willing to "trust" some kind of synchronizer. For some purposes it might not be a bad idea to add another layer of synchronization on each side to reduce the probability of errant behavior (cheap insurance, if propagation delay isn't a concern), but... | |
| Apr 14, 2017 at 16:58 | comment | added | supercat | @duskwuff: Each signal that passes between clock domains passes through two registers in the new domain before going anywhere else. The reason for using a double-synchronizer is that if an input violates setup/hold constraints of the first register, its output might do anything but would be unlikely to do so in a fashion that would cause the second to do anything other than latch a clean high or a clean low. Timing analysis tools mwy need to be told to presume that the output from the first register in each pair would satisfy the constraints of the second. | |
| Apr 14, 2017 at 5:33 | comment | added | user39382 | Does this pass timing analysis? | |
| Apr 13, 2017 at 22:41 | history | answered | supercat | CC BY-SA 3.0 |