Добрый день!!!

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

Рассмотрим систему: АЦП работающий от чистого генератора G1 с джиттером ну положим 1ps. Потом оцифровали, затащили в ПЛИС/проц, сложили в память. Теперь нужно произвести ресамплинг на частоту 100МГц, полученную от другого генератора G2 с джиттером 100ps. Математически произвести такую операцию просто, но вот будет ли применимо к этому правило, относительно влияния джиттера на аналого-цифровое преобразование?

С одной стороны поток данных уже оцифрован и отчеты не зависят от частоты G2, но с другой стороны, на G2 нужно будет формировать периоды генератора G1 для опорных точек интерполяции и тут ИМХО будет тот же самый эффект влияния джиттера. Или я не прав?

UPD. Для большей ясности рассмотрим не проц с "виртуальной" частотой 100 МГц, получаемой из 1ГГц тактовой. А ПЛИС, работающую на частоте 100МГц, на которую и нужно перенести сигнал %) так будет честнее и ближе к нужной мне теме %)

Не очень понятен вопрос.
Сигнал уже оцифрован. Дальнейшие преобразования данных чисто цифровые, то есть джиттер генератора G2 не важен. Да и сама частота 100 МГц условна: цифровая обработка не обязана происходить в реальном времени.
Вот если далее будет ЦАП, затактированный от G2, тогда да, нужно учитывать его джиттер.

Сначала я подумал точно также, но потом развил мысль :

ПЛИС пишет в память ну положим 1000 отсчетов на частоте АЦП - "чистые" 96МГц. Затем ПЛИС нужно выполнить ресамплинг на "грязные" 100МГц. Для этого, нужно считать 96 точек и получить 100, рассчитав дробные задержки. И при расчете дробных задержек, разве джиттер G2 не будет влиять (ведь по сути, по правилу работы того же интерполятора Фарроу, нужно будет сделать NCO генератор на G2, на котором родить частоту G1 по сигналу которой читать данные из памяти) ? Или после того как закапчурили отчеты АЦП это уже стало не реальное время обработки ?

Вот, я именно об этом. Можно считать, что частота G2 - "виртуальная", с нулевым джиттером. Частота G2 - это ведь всего лишь условность, необходимая для того, составить формулы цифровых преобразований. Сцены космических боёв в Звёздных Войнах обсчитывали по несколько месяцев, а на экране прокрутили по 24 кадра в секунду.

понял. спасибо.

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

понятно. задумал новую архитектуру модема, давно хотел отвязаться от частот, связанных с АЦП %)

Возник вопрос.

Изначально ТС нужно было перейти из одной временной сетки в другую.
Для ПЛИС стандартная ситуация, особенно интересно потом доказать
функциональную безопасность такого преобразования.

Ответ в общем виде свелся к тому, чтобы не переходить из сетки 96 МГц
на сетку 100 МГц, а писать в память или передавать по линии связи как есть.

По факту задача не решена, а сетка 100 переведна в разряд "виртуальных".

Но ПЛИС работает в реальном времени по сетке 100, а получает данные
здесь и сейчас по сетке 96, но все же должна обрабатывать данные
и синхронизироваться с периферией по сетке 100. Нестыковка.

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

А у нас (у меня в частности) - реалтайм в обоих случаях.

А так ли нужно для этого ресемплить сигнал, если можно обрабатывать сигнал в сетке 96 МГц c тактовой частотой 100 МГц?

иногда нужно, например при многотактовой арифметике и цифровом восстановлении тактовой частоты, мне как раз 1 такта не хватает %)


мой вопрос лежал не столько в области передачи данных, сколько в области модемных технологий. Когда идет работа с потоком отчетов с АЦП.

Если рассмотреть вопрос реалтайма и преобразования 96/100 МГц, то мои умозаключения сводились к 2-м вариантам :
1. Если частота 100 МГц получается как 25/24 от частоты 96 (т.е. частоты хоть как то привязаны по фазе), то при наличии небольшого буфера на 24 отчета, все легко решается интерполяцией на лету (по крайней мере матлаб говорит что будет работать). Под "легко решается" я понимаю что на выходе будет поток символов на 100МГц + искажения при интерполяции.
2. Если частота 100МГц асинхронна относительно 96МГц, то легко не получиться, т.к. фазы генераторов плывут и рано или поздно будет underflow/overflow. И задача сводиться к обработке на клоке 100МГц + enable. Что даст итоговую частоту < 100МГц (кол-во насколько меньше нужно считать исходя из стабильности генераторов и джиттера).

Могу ошибаться, но ИМХО так.

Если без буфера и поток непрерывный, то когда фронты обеих частот близки (каждые 10 ns * 25 = 250 ns), возможны метастабильные состояния. Получается, нужны два буфера - в один писать на частоте 96 MHz, другой обрабатывать на частоте 100 MHz. Потом - наоборот.

ну я же писал про использование PLL , а двойная буферизация/фифо двойной глубины как бы очевидно %)

без привязки 100МГц к 96 никакой глубины фифо может не хватить.

А я что-то не нахожу Если это пункт 1 (частоты привязаны к фазе), так это ничего не меняет, мсм.

пункт звучал не так

Как бы это меняет все. ИМХО без привязки по фазе никакое фифо/память не поможет реалтаймовской обработке.

Если вы именно про то что нужно делать двойное буферирование, то это как бы очевидно, в противном случае посчитать 25 выходных точек по 24 ем не получится, а именно будут выбиты/неправильно посчитаны последние 2 точки новой частоты, т.к. к моменту расчета 24 ой точки новой частоты (100МГц), нужной 24 ой точки старой частоты(96) еще физически не будет, а она нужна.

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

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