Приветствую!

И с чего это Вы решили что так будет ? В приведенном выше рассуждении есть маленькая ошибка приводящая к таким большим неправильным выводам. намек - попытайтесь взглянуть не так широко - посмотрите что будет в пределах 2 тактов clk1

Ну а тут вообще каша - сигнал готовности на каждый клок clk1 ?

Успехов! Rob.

Да это я тупанул, clk2 регистр всегда будет выбирать между новым и старым актуальным значением регистра сlk1, которые всегда будут отличаться на 1 бит. Ему же не важно какое он сам имел значение...


нет конечно, сигнал готовности либо когда подтверждение что 2 принял данные, либо с гарантированной задержкой.

Но да Вы правы, код грея лучше, все тоже самое, только проще

Надеюсь, что будет понятно в продолжение о двух счётчиках, сама идея:
Простой пример (clk1 < clk2)
У нас бегущий секундомер натикивает за 5 секунд значение 7.
Но мы то знаем (по синхросигналу), что должно быть 5.
Делим 7/5=1.4.
Происходит 1ый тик нашего неточного генератора, суммируем
0+1 = 1, это меньше чем 1.4, поэтому счёт вычисленных тиков пока 0.
Происходит 2ой тик, суммируем:
1+1 = 2, что более, чем 1.4, поэтому вычитаем 2-1.4=0.6 и увеличиваем счётчик вычисленных тик 0+1 = 1
3ий:
0.6+1=1.6, 1.6-1.4=0.2, вычисленный 1+1=2
4ый:
0.2+1=1.2, вычисленный сохраняем 2
5ый:
1.2+1=2.2, 2.2-1.4=0.8, вычисленный 2+1=3
6ой:
0.8+1=1.8, 1.8-1.4=0.4, вычисленный 3+1=4
7ой:
0.4+1=1.4, 1.4-1.4=0 (сошлось!), вычисленный 4+1=5 (тоже получили что надо)
Таким образом, мы на 7 тиках вычислили 5 требуемых с каким-то более-менее равномерным распределением.
Другой случай (clk1 > clk2)
Тоже самое, но сейчас наш секундомер отстаёт и за 5 секунд натикивает всего 3.
Делим 3/5 = 0.6
1ый тик: 0+1 = 1, что больше чем 0.6, поэтому считаем 1, разница 1-0.6=0.4
2ой тик: 0.4+1 = 1.4, что более, чем 0.6, поэтому 1+1 = 2, разница 1.4-0.6=0.8, что снова больше, чем 0.6, значит считаем 2+1=3, остаток 0.8-0.6=0.2
3ий тик: 0.2+1 = 1.2, 3+1=4, 1.2-0.6=0.6, 4+1=5, 0.6-0.6=0.
Снова сошлось: за 3 тика насчитали 5.
---
Разница в том, что на ПЛИСке один из счётчиков (тот, на чьё значение надо делить) удобно сделать с фиксированным порогом счёта до числа равно двум в некой целой степени, чтобы делить простым сдвигом.

а у вас недурная подпись в сообщениях



так почему?

RobFPGA слушать надо, дело говорит

Ага. Потому что, имея ТЗ на коловорот и подключив всё своё представление о том как бывает плохо, когда что-то не учтено, изобретают дрель с вентильным движком
А я с тем, что он говорит и не спорю.
В конечном счёте все тонкости задачи известны только самому ТС. Не в полной мере ясно - что же, всё-таки, требуется: иметь максимально линейный перенос шкалы времени (тогда это больше отводит в сторону счётчиков, интерполяций, цифровых PLL и т.п., реализующих интегральные подстройки) или же чёткое квитирование прохождения определённых этапов (это ближе к фифо и около того).
MegaVolt, а Вы можете написать - в каких пределах могут быть clk1 и clk2?

В моей голове это одно и то же Ибо идеальное устройство как раз и линейно и правильно фиксирует моменты появления фронтов clk2

В теоретической задаче любыми. И предложенный вариант с кодом грея га 100% удовлетворяет условию

А в реальном применении откуда родилась теоретическая задача соотношение примерно такое 252MHz +/- 0,1ppm -> 100MHz +/- 50ppm

И что пойдёт в дело не суть важно. Важно то что я лучше понял как работает синхронизатор с кодом грея. За что большое спасибо RobFPGA.
А так же увидел кучу весьма интересных решений этой задачи. За что спасибо всем участникам )))