Добрый день!
Пытаюсь понять, как можно избавится от джиттера при востановлении символьной синхронизации в цифровом приемнике PSK и QAM-сигналов. В приемнике (на ПЛИС) реализуется восстановление фазы несущей и символьная синхронизация+ последующая обработка-декодирование и т.д. Реализовал тактовую синхронизацию как описано у Гарднера ("Interpolation in digital modems"), соответственно присутствует джиттер восстановленного clock-а (символьного). Когда номинальная символьная частота приемника отличается от символьной частоты принимаемого сигнала (а на практике это всегда так) символьный clock с выхода NCO периодически совершает "скачок", в результате чего получаем clock с джиттером, что не очень удобно с точки зрения построения остальной частотной сетки, привязанной к символьному clock-у, да и выходной clock в итоге получается "грязным". Как вариант - подстроить аналоговый ГУН под частоту символьного clock-a и получить более чистый clock, но это не всегда дает результат (при малых отстройках такта принимаемого сигнала от номинальной тактовой частоты приемника требуется чрезвычайно узкополосная ФАПЧ; при относительно больших отстройках clock получается более-менее). Еще есть другой подход - гибридная тактовая синхронизация (подстраиваем синхросигнал, подаваемый на АЦП, - опять-таки задействуем ГУН). В этом случае clock получаем без скачка, но возникает другая проблема: опорный синхросигнал (который подается на АЦП и используется в ПЛИС для цифровой обработки) становится зашумленным, особенно при малых отношениях сигнал/шум в канале связи. Этот синхросигнал используется помимо всего прочего и как опора для DDS, формирующего выборки cos и sin для восстановления фазы несущей, соответственно вносим в систему фазовый шум. Дополнительный фазовый шум ухудшает работу схемы восстановления несущей, особенно это заметно при малых скоростях передачи данных.
Заранее спасибо всем, кто выскажет какие-либо разумные идеи.

Не стоит цепляться за плохую идею.

А что делать... В приемнике частоты должны быть синхронизированы с тактом принимаемого синала

Данные вы приняли правильно, им на джиттер наплевать, дальше работайте с местными опорными генераторами.

Местные генераторы надо подстраивать под символьную частоту, приемник рассчитан на непрерывный поток данных. Асинхронный вариант не подходит, fifo-буферы переполнятся/ опустеют в любом случае.

Не надо. Переполнение/опустошение решается на уровне протокола передачи данных.

Если предусмотрена возможность пауз, то да. Но не в этом случае

Что за случай, непрерывные потоки сплошь и рядом передают через не синхронные сети?

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

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

Нужна дальнейшая обработка данных (преобразование символов в битовый поток,декадрирование, декодирование; на каждом шаге при этом частота после преобразования будет отличаться в n/k раз от входной, к примеру, после декодирования с кодовой скоростью 3/4 получим частоту данных точно равную 3/4 от входной), в итоге данные и clock передаются на внешний синхронный интерфейс. В модеме CDM600, для примера, выходной clock, сопроводающий данные, синхронен с clock-ом передатчика. Я проверял Я слабо себе представляю как можно было бы обойтись здесь без полностью синхронной сетки частот. Собственно я ее и так формирую сейчас в цифре, но у меня все с джиттером получается в итоге.

Сигналы синхронного межблочного интерфейса:

clock
data[]
data_enable

Fclock может в этом случае быть больше скорости передачи данных data[].

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

Как-то всё валится в одну кучу. Как уже выше было сказано, FPGA тактируется заведомо большим клоком, синхронизация обработки данных осуществляется через enable сигналы, ниакой безджиттерности и лишних клоковых доменов для обработки не требуется. Необходимо чётко сформулировать почему требуется именно синхронная сеть, просто использовать это как средство от других проблем плохая идея.

Поставьте сразу один clock с высокой fclk для всех блоков.

Сигналы
data[] и data_enable формирует блок-источник

clock - тактовая частота всей системы от внешнего генератора. Она в общем случае никак не связана со скоростью передачи данных data[], просто выше ее.