Как передать все возможные значения счётчика из одного клокового домена в другой? Опции

[MegaVolt]

Есть первый клоковый домен. В нём реализован счётчик. Есть второй клоковый домен. Как можно передать все возможные значения счётчика во второй домен.

Классическая реализация подразумевает запрос - ответ с использованием синхронизаторов.

Есть ли решения позволяющие иметь на второй стороне все возможные значения счётчика.

Поясню. Для однобитного счётчика это позволяет реализовать обычный синхронизатор правда при условии что первая частота меньше второй.

Есть ли решения для большей разрядности и не зависящие от соотношения частот? Искажения кодов не допустимы. Пропуск кода или повторные коды само собой допустимы.

Т.е. вот такие результаты выходов вполне допустимы
1: 1-2-4-5-7-8-10-11-...
2: 1-1-2-2-2-3-3-4-4-4-4-...

Вопрос скорее теоретический. Любопытно возможно ли такое и как реализовать наиболее простым способом.
Возможно есть частные решения для передачи из домена с болей частотой в домен с меньшей. Или наоборот.

[litv]

FIFO

[RobFPGA]

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

Классика :

Код

             ---clk_1---      |         ---  clk2  ----
счетчик -> bin_to_gray -> reg -> reg ...-> gray_to_bin -> reg

Успехов! Rob.

[dima32rus]

1. Код Грея (хорошо подходит для счетчиков).
2. Механизм рукопожатия (handshake).
3. FIFO.

[MegaVolt]

Классика :

Код

             ---clk_1---      |         ---  clk2  ----
счетчик -> bin_to_gray -> reg -> reg ...-> gray_to_bin -> reg

Классика допускает искажение кодов. Причём как в плюс так и в минус. Причём чем большая разрядность тем большее искажение будет.

1. Код Грея (хорошо подходит для счетчиков).

Он искажает коды

2. Механизм рукопожатия (handshake).

Как его применить для получения всех кодов?

3. FIFO.

Не очень понял идею? Что даст замена двух регистров на их аналог в виде памяти?


Пока я вижу вариантом такой:
Есть циклический буфер в который в домене один пишутся коды. На второй стороне идёт вычитывание из памяти по указателю с заранее сформированным инкрементом. Инкремент жёстко зависит от соотношения частот (некий аналог DDS). В результате имеем гарантированно стабильное чтение из памяти. Если правильно поборать фазировку сигналов

Можно ли как то формировать автоматически этот коэффициент для инкремента?

[EvgenyNik]

FIFO не подойдёт, т.к. подразумевается разница частот, а значит буфер или переполнится или будет пустым.

Код

module cnt_copy
(    input    clk1,
     input    clk2,            
     output reg    [7:0]    cnt1,
     output reg    [7:0]    copy2 );
reg    ready1 = 0;
reg    ready2 = 0;
reg    ready1_l1, ready1_l2;
reg    ready2_l1, ready2_l2;
reg    [7:0]    cnt1_l;
always @ (posedge clk1)
     begin
     ready2_l1 <= ready2; ready2_l2 <= ready2_l1;
     cnt1 <= cnt1 + 1;
     if (ready2_l2)
         begin
         if (~ready1)
             begin
             cnt1_l <= cnt1;    ready1 <= 1'b1;
             end
         end
     else
         begin
         ready1 <= 1'b0;
         end
     end    
always @ (posedge clk2)
     begin
     ready1_l1 <= ready1;    ready1_l2 <= ready1_l1;    
     if (ready1_l2)
         begin
         if (ready2)
             begin
             copy2 <= cnt1_l; ready2 <= 1'b0;
             end
         end
     else
         begin
         ready2 <= 1'b1;
         end
     end
endmodule

Результат

Указать таймбара стоит, как раз, на моменте, начиная с которого происходит передача значения "3". Далее тоже видно как передаются значения. С пропусками из-за синхронизации, но без искажения передаваемого значения.

[MegaVolt]

Память двухпортовая само собой.

[RobFPGA]

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

Ну понеслись решения .....
Смотрим требования TC

... Искажения кодов не допустимы. Пропуск кода или повторные коды само собой допустимы.

Т.е. вот такие результаты выходов вполне допустимы
1: 1-2-4-5-7-8-10-11-...
2: 1-1-2-2-2-3-3-4-4-4-4-...

И почему тут классика не годится ???

Удачи! Rob.

[MegaVolt]

module cnt_copy

Это я так понял запрос ответ с синхронизацией. Многовато кодов пропускает

И почему тут классика не годится ???

Потому что классика с Греем искажает коды. И чем больше разрядность счётчика тем больше.

[EvgenyNik]

Это я так понял запрос ответ с синхронизацией. Многовато кодов пропускает

Да, это запрос-ответ. Но и

Для однобитного счётчика это позволяет реализовать обычный синхронизатор правда при условии что первая частота меньше второй.

работало бы на такой же "скорости обмена".
Чтобы пропускало меньше кода надо для счёта использовать не саму частоту тактирования, а поделенную на 2..4.

[MegaVolt]

Чтобы пропускало меньше кода надо для счёта использовать не саму частоту тактирования, а поделенную на 2..4.

Так каждый может ))))

Интересно решить оригинальную задачу.

Вариант с двухпортовой памятью как идея очень даже ничего. Ищу другие.

[XVR]

Потому что классика с Греем искажает коды. И чем больше разрядность счётчика тем больше.

Это с какого перепугу она искажает? Вы код Грея с бинарным не перепутали?

Да, частота со счетчика должна быть гарантированно меньше, чем частота синхронизации в приемном домене. Это легко получить откинув младшие разряды (в исходном двоичном счетчике, до преобразования в код Грея)

[dima32rus]

FIFO не подойдёт, т.к. подразумевается разница частот, а значит буфер или переполнится или будет пустым.

У FIFO есть сигналы EMPTY, FULL. Если все сделать правильно, то пропусков не будет. Совсем.

[MegaVolt]

Это с какого перепугу она искажает? Вы код Грея с бинарным не перепутали?

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

Как быть если счёт идёт на большей частоте. И потеря младших бит не выход?

У FIFO есть сигналы EMPTY, FULL. Если все сделать правильно, то пропусков не будет. Совсем.

Если не секрет как именно их использовать? Я пока плохо понимаю саму идею.

[XVR]

Как быть если счёт идёт на большей частоте. И потеря младших бит не выход?

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

[blackfin]

FYI

[MegaVolt]

В этом случае младшие биты будут отражать погоду на Марсе или фазу Луны. Ну или в крайнем случае нечто, зависящее от фаз клоков в 2х доменах, что мало отличается от фазы Луны.

Почему фазу луны? Например при схеме запрос ответ. Они отражают состояние счётчика на момент прихода запроса с точностью быстрого счётчика.

Вам они точно нужны?

Да тут скорее любопытство чем реальная необходимость.


Кстати на счёт кода ГРЕЯ... насколько удобно использование кода для больших длинн данных. Например для 48.

[RobFPGA]

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

Упс.... я вообще с чем то своим перепутал....

Уже легче

Согласен коды грея подходят если при частоте счёта меньше второй частоты.

В каждом dual-clock FIFO стоит как минимум 2 классики для передачи указателей write/read соответственно на сторону read/write
и при этом отношение частот может быть как read > write так и read < write.

Кстати на счёт кода ГРЕЯ... насколько удобно использование кода для больших длинн данных. Например для 48.

Все зависит от рабочей частот ну и от того для чего такой переход нужен.

Успехов! Rob

[dima32rus]

Если не секрет как именно их использовать? Я пока плохо понимаю саму идею.

Если буфер FIFO пуст, то установится флаг EMPTY, прерываете чтение. Ждете, когда появятся данные. Это возникает, когда частота приемника выше частоты источника. Если наоборот, источник грузит данные быстрее, чем их выскребает приемник, то нужно увеличить размер буфера, чтобы не произошло переполнение (флаг FULL). Все зависит от конкретной задачи. Если же Вы хотите обрабатывать бесконечно длинную последовательность данных, то нужно обрезать младшие разряды, как правильно заметил XVR. Иначе никак.

Стесняюсь спросить, а зачем Вам гонять между доменами монотонно изменяющуюся последовательность? Проще передать сигнал запуска через синхронизатор, и, если надо, начальное значение. А считать уже на нужной частоте.

[MegaVolt]

FYI

Как в фифо реализована синхронизация я понимаю. Как применить фифо к задаче не очень

[XVR]

Почему фазу луны? Например при схеме запрос ответ. Они отражают состояние счётчика на момент прихода запроса с точностью быстрого счётчика.

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

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

[MegaVolt]

Если буфер FIFO пуст, то установится флаг EMPTY, прерываете чтение. Ждете, когда появятся данные. Это возникает, когда частота приемника выше частоты источника.

Мне думается тут будут проблемы. Если я читаю по EMPTY то первое значение я вычитаю с задержкой на синхронизацию. Последующие насыпавшиеся в FIFO за время синхронизации я вычитаю уже без начальной задержки. Т.е. значения не совсем будут связаны с начальным счётчиком.

Если наоборот, источник грузит данные быстрее, чем их выскребает приемник, то нужно увеличить размер буфера, чтобы не произошло переполнение (флаг FULL). Все зависит от конкретной задачи. Если же Вы хотите обрабатывать бесконечно длинную последовательность данных, то нужно обрезать младшие разряды, как правильно заметил XVR. Иначе никак.

Во втором случае в идеале хотелось бы чтобы лишние коды пропускались сами.

Опять же пока не очень понимаю чем FIFO отличается от схемы запрос ответ?

Стесняюсь спросить, а зачем Вам гонять между доменами монотонно изменяющуюся последовательность? Проще передать сигнал запуска через синхронизатор, и, если надо, начальное значение. А считать уже на нужной частоте.

Ну например передача шкалы времени из одного домена в другой с минимальной погрешностью.

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

Именно эта задача. Просто то что спрашиваю я выросло из этой.

1. Начальная задача: запрос - защёлкивание - ответ.
2. Мысленно увеличим число запросов до максимума. Логично предположить что это меандр с половинной частотой.
3. Сделаем два канала запросов сдвинутых на период
4. Объединим результаты запросов
5. На выходе имеем все возможные коды.

Уже легче

В каждом dual-clock FIFO стоит как минимум 2 классики для передачи указателей write/read соответственно на сторону read/write
и при этом отношение частот может быть как read > write так и read < write.

Само собой. Но скорость работы самих синхронизаторов вполне стандартная. И не очень понятно как получить все коды.

[XVR]

Именно эта задача. Просто то что спрашиваю я выросло из этой.

1. Начальная задача: запрос - защёлкивание - ответ.
2. Мысленно увеличим число запросов до максимума. Логично предположить что это меандр с половинной частотой.

Все, тут будет затык. Вы не сможете принять этот поток запросов на приемной стороне (в медленном клоковом домене), не хватит пропускной способности. Нужно будет либо пропускать некоторые данные (снизив тем самым поток на передающей стороне) либо передавать по нескольку запросов в параллель (расширив тем самым пропускную способность на приемной стороне)

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

[dima32rus]

Мне думается тут будут проблемы. Если я читаю по EMPTY то первое значение я вычитаю с задержкой на синхронизацию. Последующие насыпавшиеся в FIFO за время синхронизации я вычитаю уже без начальной задержки. Т.е. значения не совсем будут связаны с начальным счётчиком.

Биения будут иметь место, да. Но по-другому никак. Если частоты не равны, то вам все равно придется либо время от времени ждать, либо пропускать.

Во втором случае в идеале хотелось бы чтобы лишние коды пропускались сами.

В таком случае просто не обращаете внимания на флаг FULL. Все лишнее само отрежется.

[XVR]

Поправка - сами коды счетчика можно передать в параллель. Для этого нужно разделить его на N штук счетчиков (N - отношение частот в доменах) и запустить их так, что бы каждый прибавлял на 1 за N клоков, при этом первый счетчик инкрементировался на 1м клоке, 2й на 2м и т.д. Потом все значения перевести в код Грея и передать в медленный домен

[MegaVolt]

Все, тут будет затык. Вы не сможете принять этот поток запросов на приемной стороне (в медленном клоковом домене), не хватит пропускной способности.

Так это решение для приёма данных с быстрого счётчика. Все запросы должны проходить.

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

Сейчас накидаю вариант

Биения будут иметь место, да. Но по-другому никак. Если частоты не равны, то вам все равно придется либо время от времени ждать, либо пропускать.

Боюсь биения будут сильно больше чем те что должны быть от разности частот. Хотя нужно помоделировать...

В таком случае просто не обращаете внимания на флаг FULL. Все лишнее само отрежется.

Надо попробовать.

Поправка - сами коды счетчика можно передать в параллель. Для этого нужно разделить его на N штук счетчиков (N - отношение частот в доменах) и запустить их так, что бы каждый прибавлял на 1 за N клоков, при этом первый счетчик инкрементировался на 1м клоке, 2й на 2м и т.д. Потом все значения перевести в код Грея и передать в медленный домен

Ага. Или N счётчиков или N регистров за одним счётчиком.
А N регистров вполне заменит кольцевой буфер на памяти.

Вопрос только как правильно читать в случае не кратных частот.

[RobFPGA]

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

Само собой. Но скорость работы самих синхронизаторов вполне стандартная. И не очень понятно как получить все коды.

Вы не решите эту задачу пока не зафиксируете требования к передаче.

Есть ли решения для большей разрядности и не зависящие от соотношения частот? Искажения кодов не допустимы. Пропуск кода или повторные коды само собой допустимы.

Т.е. вот такие результаты выходов вполне допустимы
1: 1-2-4-5-7-8-10-11-...
2: 1-1-2-2-2-3-3-4-4-4-4-...

????


Успехов! Rob.

[MegaVolt]

Вы не решите эту задачу пока не зафиксируете требования к передаче.

Пропуски и повторы допустимы если они вызываны разностью частот. И не допустимы если они вызваны тормозами синхронизатора.

Иначе говоря мне нужно на второй стороне иметь отображение счётчика. Где каждому такту второй частоты сопоставлен НОВЫЙ код насколько возможно его получить с учётом запрета на метастабильность. Само собой возможны 3 варианта:
1. clk1 < clk2 появятся повторные коды ибо нового кода ещё нет в природе
2. clk1 < clk2 появятся пропуски т.к. счётчик успеет сгенерить несколько кодов за один такт второй частоты
3. метастабидльность остаётся тот код который был до этого.

Варианты где мы в результате супер правильно синхронизации имеем на выходе один НОВЫЙ код за NNNNN тактов не подходят.

Код грея для случая clk1 < clk2 является отличным решением задачи.

Интересует решение и для второго случая когда clk1 > clk2

[krux]

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

[MegaVolt]

в порядке бреда предложу сгородить изврат....

Как выбирать из регистров если частоты не кратный. А в реальном мире они просто не могут быть кратны ибо это чудо.

[krux]

Как выбирать из регистров если частоты не кратны

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

[MegaVolt]

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

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

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

[des00]

Интересует решение и для второго случая когда clk1 > clk2

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

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

[EvgenyNik]

Пропуски и повторы допустимы если они вызываны разностью частот. И не допустимы если они вызваны тормозами синхронизатора.
Интересует решение и для второго случая когда clk1 > clk2

А если так:
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, к примеру, и мы скорректируем наш масштабный коэффициент.

[MegaVolt]

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

Цифровая PLL впринципе вариант но не самый простой

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

Залипы это что?

А если так:
...
Теперь на каждый такт clk2 мы прибавляем к образе cnt1 значение 18,0390625:
18,0390625, 36,078125 и т.д.
На следующем интервале cnt1 покажет число 2314, к примеру, и мы скорректируем наш масштабный коэффициент.

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

[des00]

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

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

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

[RobFPGA]

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

Пропуски и повторы допустимы если они вызываны разностью частот. И не допустимы если они вызваны тормозами синхронизатора.

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

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

Успехов! Rob.

[krux]

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

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

[MegaVolt]

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

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

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

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

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

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

элементарный. асинхронный ФД

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

[des00]

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

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

[MegaVolt]

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

))))))

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

[RobFPGA]

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

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

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

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

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

Успехов! Rob.

[MegaVolt]

Еще раз - поставьте классику. Она обеспечит Вам требуемые условия!

классика это с кодом грея?

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

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

[RobFPGA]

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

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

Да именно с ним. А ограничение гарантирует отсутствие ошибок.
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.

[Golikov A.]

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

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


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

[RobFPGA]

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

по моему хэнд шейк позволит передавать данные из 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 A.]

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

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

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

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

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

[EvgenyNik]

Надеюсь, что будет понятно в продолжение о двух счётчиках, сама идея:
Простой пример (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 A.]

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

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

так почему?

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

[EvgenyNik]

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

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

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

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

[MegaVolt]

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

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

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

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

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

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