Здравствуйте, не уверен что форум правильный, но попробую.
Задача: делаю модулятор, символьная скорость 364kHz, частота дискретизации ЦАП 364*56 = 20384kHz.
ПЛИС Spartan 6. Проблема в том, что символьная скорость должна точно соответствовать входному потоку битов, а с ним идут два клока - 1024kHz и 8192kHz. Ума не приложу как все это синхронизировать. НОК(8192, 20384) > 5GHz - PLL не потянет.
Пока единственная идея - синхронизировать только символьную скорость (364 из 1024 легко на DCM можно сделать) и где-то в процессе интерполяции делать переход в другой клоковый домен - т.е. частоту дискретизации ЦАП генерировать локальным генератором.

ресамплер дробный поставить и не париться %)

DDS не подойдет?

Внешняя PLL?

Если можно вопрос - в каком именно месте? Я только учусь, математику процесса знаю (модулятор заработал с первого раза), но вот практики маловато.
На сегодня модулятор работает от локального генератора и FIFO на стыке генератора символов и модулятора регулярно или переполняется или опустошается - как ветер подует.


DDS естественно есть, проблема в том чем его тактировать. Задача не в генерации выходного сигнала, а в получении CLK или CE для генератора

я ставлю на выходе демодулятора перед ЦАПОМ. Это позволяет мне, правда за счет усложнения модулятора (возможно вам потребуется его правка), работать на любой частоте ЦАП. в частности делал модемы с ресамплингом на 14/15, 49/50, 20/21. %)
Найдите описание на чип от фирмы Provigent, там из блок схемы поймете как делать и куда ставить ресамплер.


потому что гун локальный привязывать надо %)

Так про это и вопрос - как . Спасибо за идею, буду разбиратся.

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

Нельзя. Данные - звук. И приемник (не наш) его играет в реальном времени. Так что слушатели не поймут

Почему? Слушаете вы к пример ролик на ютубе, ведь клок условно с жёсткого диска гугла не передаётся через всё множество модемов на пути до вас, звук играется с местным генератором на вашей звуковой карте. ИМХО не лучший вариант клоки тащить через все модемы. Лучше сделать чтобы модемы работали со своими генераторами, а звук только в конце ресемплировать по указателю заполнения FIFO.

Приемник не мы делаем. И работает он как работает - изменить нельзя. Ни символьную скорость ни то, что по получении первых N отсчетов начинает играть звук в реальном времени.

передача синхронного трафика по асинхронным каналам, требует более высокой пропускной способности асинхронного канала + мультиплексирование/демультиплексирование

akorud

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

Я в свое время пошел по первому пути и подводил часы в приемнике в периоды тишины. Я думаю, что если Вы решите для себя этот вопрос, то у Вас автоматом появится схема FIFO с двумя асинхронными клоками, которое будет на одном из концов пропускать иногда такты, чтобы сбалансировать поток.

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

8192 пропустить чере 2 DCM (13/16 и 7/2), и потом через PLL 7/8 (чтобы она немного джиттер от DCM отчистила). 8192*13*7*7/16/2/8=20384.

Спасибо, внимательно прочитал Spartan 6 clocking resources и тоже пришел к решению в виде последовательно включенных DCM и PLL.
Сделал 1024 -> DCM 91/1 -> PLL 7/32. 1024*91*7/32 = 20384. В "железе" вроде работает.