по известному номеру предыдущего выбранного синхронизатора, плюс, по монотонному возрастанию для начальной синхронизации.
грея не использовать, синхронизаторы сделать на муксах.

Это да вариант. Куча синхронизаторов работающих по очереди со сдвигом фазы на такт в каждом. Их количество зависит от количества тактов необходимых на синхронизацию.

Как вариант решения очень даже. Вот интересно есть ли способы как то это решение оптимизировать?

сделать асинхронный ресамплер на основе elastic buffer(stream based fifo) + DPLL.

ЗЫ. правда будут залипы. но без этого никак

А если так:
1. В домене clk2 создаём счётчик cnt2 (пусть от 0 до 127)
2. В домене clk1 создаём счётчик cnt1, разрядность которого позволяет с некоторым запасом не "кувыркнуться" через ноль, пока счетчик (cnt2) досчитает до 127
3. При достижении счётчиком cnt2 значения 127, сбрасываемся в 0 и формируем запрос в домен clk1 о передаче значения cnt1.
4. Получив запрос, счётчик cnt1 пересылает своё значение и сбрасывается в 0.
5. Таким образом, мы получаем какое количество тактов clk1 накапливается в счётчике cnt1 за время, пока счётчик cnt2 считает интервал в 128 тактов clk2.
6. Представив это значение в формате с фиксированной точкой мы получаем масштабный коэффициент, позволяющий вести эквивалентный счёт от тактов clk2 с представлением времени в домене clk1 в течении следующего интервала, пока не произойдёт обновление информации.
Пример:
cnt2 пробежал интервал в 128 тактов clk2, присланное значение cnt1 = 2309 clk1
Считаем 7 младших бит - дробной частью, тогда в десятичных получаем cnt1/cnt2 = 18,0390625.
Теперь на каждый такт clk2 мы прибавляем к образе cnt1 значение 18,0390625:
18,0390625, 36,078125 и т.д.
На следующем интервале cnt1 покажет число 2314, к примеру, и мы скорректируем наш масштабный коэффициент.

Цифровая PLL впринципе вариант но не самый простой Залипы это что?


Очень любопытный способ Два счётчика считающих отдельно и подстраивающихся друг к другу. Спасибо

элементарный. асинхронный ФД + петлевой фильтр(lead/lag звенья) + NCO (по сути аккумулятор). итого плиток 150-200. ну и elastic buffer еще плиток 30+ блочная память

залипы у меня это повторы последнего числа.

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



Вы не можете разделить эти ситуации. Поэтому пока не конкретизируете сценарий работы этого устройства, какие тормоза синхронизатора допустимы, а какие нет, какое соотношение частот предполагается и.т.д. ... Вы так и будете "теоретически" бегать за коровками
Надо неспешна окинуть взором все стадо-систему, определить приоритеты и и методично начать тра...

Практически задержки будут не менее 3-5 тактов МЕДЛЕННОЙ частоты

Успехов! Rob.

счетчик из 100 МГц домена переведён на 9 МГц. использованы 6 синхронизаторов на муксах с ready-valid интерфейсами.

доделывать не стал, там дальше уже всё понятно.
ресурсов жрёт кошмар. имхо оно того не стоит.

Правильно сформулированная задача - половина решения )

Задача то сводится к следующей:
Передаём через параллельный синхронизатор выход счётчика во второй домен. Часть семплов портиться. Задача выдавать на выход только годные семплы.

Годность определяем по условям.
1. Следующий семпл >предыдущего на величину не более заданной.
2. Некий небольшое избыточное кодирование для защиты младших бит.

Господа критикуйте )

если не секрет что за хитрые синхронизаторы?


а для обработки его выхода часом не нужна частота большая чем оба клока в разы?

а поделить до кратных частот мысль не приходит ?

))))))

Туплю
Я в жизни не делал ЦФАПЧ ))) хотя они всегда нравились

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


Еще раз - поставьте классику. Она обеспечит Вам требуемые условия!
При ЛЮБЫХ отношениях частот (но с одним маааленким HO)
должно быть ограничение что время распространение сигнала от регистра быстрого клока к медленному НЕ БОЛЕЕ периода быстрого клока - и "Усе будет в ажуре шеф!"

Успехов! Rob.

классика это с кодом грея?не очень понял про какие регистры идёт речь и откуда берётся это ограничение?

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


Да именно с ним. А ограничение гарантирует отсутствие ошибок.
cnt_in(clk_1) -> bin_to_gray -> reg_1(clk_1) -> reg_2(clk_2) ->reg_3(clk_2) ... -> gray_to_bin -> cnt_out(clk_2)
Ограничение задает максимальное время распространение сигнала между reg_1 и reg_2. Это время должно быть меньше чем период максимально частоты.

Успехов! Rob.

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

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


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