[RobFPGA 27]

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

 

по моему хэнд шейк позволит передавать данные из 1 домена в другой не менее быстро, но со 100% защитой.

 

код грея хорош если нет пропусков отсчетов, представьте что clk1 в 10 раз быстрее clk2, тогда reg_1(clk_1) в домене clk_2 будет виден как 0-10-20 и так далее, а в коде грея на такой дельте будет смена далеко не 1 бита, и вся синхроцепочка не имеет смысла, как и преобразование в код грея.

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

 

а если на частоте clk1 сохранять данные в регистр, и выставлять сигнал готовности, то через 2 такта clk2 данные будут уже во 2 домене, а еще через 2 clk1 можно выставлять новые данные. Если подобрать частоту подачи данных, то можно даже 2 clk1 сэкономить. И получим ту же частоту что на коде грея...

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

 

Успехов! Rob.

[Golikov 0]

И с чего это Вы решили что так будет ?

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

 

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

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

 

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

[EvgenyNik 0]

Надеюсь, что будет понятно в продолжение о двух счётчиках, сама идея:

Простой пример (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.

---

Разница в том, что на ПЛИСке один из счётчиков (тот, на чьё значение надо делить) удобно сделать с фиксированным порогом счёта до числа равно двум в некой целой степени, чтобы делить простым сдвигом.

[Golikov 0]

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

 

Почему разработчики систем повышенной надёжности плохо справляются с простыми проектами? :)

 

так почему?

 

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

[EvgenyNik 0]

а у вас недурная подпись в сообщениях :) так почему?

Ага. Потому что, имея ТЗ на коловорот и подключив всё своё представление о том как бывает плохо, когда что-то не учтено, изобретают дрель с вентильным движком :)

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

А я с тем, что он говорит и не спорю.

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

MegaVolt, а Вы можете написать - в каких пределах могут быть clk1 и clk2?

[MegaVolt 25]

иметь максимально линейный перенос шкалы времени (тогда это больше отводит в сторону счётчиков, интерполяций, цифровых PLL и т.п., реализующих интегральные подстройки) или же чёткое квитирование прохождения определённых этапов (это ближе к фифо и около того).

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

 

MegaVolt, а Вы можете написать - в каких пределах могут быть clk1 и clk2?

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

 

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

 

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

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