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

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

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

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

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

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

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

FIFO

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

Классика :

Успехов! Rob.

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

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

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


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

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

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

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

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

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

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



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

Удачи! Rob.

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

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

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

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

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

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

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

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

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

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

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


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

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

FYI

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


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

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

Уже легче


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

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

Успехов! Rob

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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


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



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

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

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

????


Успехов! Rob.

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

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

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

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

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

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

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

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

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

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

сделать асинхронный ресамплер на основе 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 сэкономить. И получим ту же частоту что на коде грея...

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

И с чего это Вы решили что так будет ? В приведенном выше рассуждении есть маленькая ошибка приводящая к таким большим неправильным выводам. намек - попытайтесь взглянуть не так широко - посмотрите что будет в пределах 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?