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

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