Есть задача: в ПЛИС завести поток со скоростью около 10Gbps, как-то обработать его (допустим, для определенности, наложить сктемблер) и выдать наружу без изменения скорости.

В Stratix IV для реализации этих задачь есть 11.3-Gbps Transceivers, которые конфигурируются с помощью мегафункции ATLGX. Но у меня не получилось сформировать выходной поток на частоте синхронной с частотой входного потока. Более того, я пришел к выводу, что это
невозможно.
Прошу подтвердить или опровергнуть мои предположения.

P.S.: всех с наступающим Новым Годом!!!

Вам надо с синхронной или с такой же частотой?

Пока с такой же, но в перспективе с синхронной (наложение и снятие помехоустойчивого кода)

Пусть специалисты меня поправят, но я не вижу необходимости в синхронизации опорных частот входного и выходного потоков. Техническая (не)возможность реализации такого в гигабитных трансиверах FPGA - отдельный вопрос.
Как я понимаю, главное, чтобы задержка данных в FPGA была не более определенного предела, так?

Все зависит от задачи. Допустим вам надо наложить скремблер на входной поток и выдать его наружу. Что будет если входной и выходной потоки будут,пусть и не значительно, отличаться по скорости(т.е. будут не синхронны)? А вот задержка в этом случае совершенно не важна.

что мешает поставить деджиттер на памяти + VCXO ?

ЗЫ. ну или на худой конец сделать все в цифре, заменив джиттер на вандер?

Я что-то Вас не совсем понял. Поставить куда? Мне данные надо обработать в ПЛИС, скорость данных около 10Gbps, для того чтобы завести и вывести в ПЛИС такой поток в самой ПЛИС есть высокоскоростной приёмопередатчик с определённой структурой и настройками, частоты для формирования выходного потока формируются в этом приемопередатчике.
И как к этому приемопередатчику прилепить деджиттер на памяти + VCXO ?

Если я вас правильно понял, вы пишете Значит на приеме, у вас получается асинхронный поток, на частоте более высокой чем частота входного потока с сигналами enable (корку не смотрел, сужу по вашим словам). Такие потоки я называю потоками с цифровым джиттером. Чтобы из него сделать равномерный синхронный поток, нужно взять ГУН и запетлевать к символьной/битовой частоте асинхронного потока. После этого вы получите нужный вам синхронный поток, с частотой == частоте потока. Метод, часто используемый в сетях передачи данных.

Вобщем-то я понял что вы имели в виду, но у меня уже на столе лежит готовая плата и меня интересует вопрос именно настройки трансиверов входящих в состав Стратикса.


Немного не так, но вариант с ГУН подошел бы, если бы на плате или в ПЛИС был этот самый ГУН.

Если я правильно понял des00, то вам нужно что-то типа такого: см. вложение.

Нет, все не то. Описанная в файле схема подойдет для потоков в 100 Mbps но никак не для 10 Gbps. Такие высокоскоростные потоки можно ввести и вывести только через встроенные в ПЛИС трансиверы. Возможности и настройки этих трансиверов меня и интересуют.


Нет, все не то. Описанная в файле схема подойдет для потоков в 100 Mbps но никак не для 10 Gbps. Такие высокоскоростные потоки можно ввести и вывести только через встроенные в ПЛИС трансиверы. Возможности и настройки этих трансиверов меня и интересуют.

Давайте для начала определимся с терминологией. Что Вы в данном контексте подразумеваете под словом "синхронный"?
Насколько я могу судить из последовавшего обсуждения, Вы под этим подразумеваете "с одинаковой скоростью" (bitrate).
Я в свою очередь думал, что Вы подразумеваете "с одинаковой фазой".

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

Да, "с одинаковой скоростью". Я в первом топике имел ввиду именно это, когда писал "без изменения скорости"


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

Пакуете STM64 в OTU2?

Пока нет
При упаковке STM64 в OTU2 можно пользоваться стаффингом, тогда выходной поток OTU2 не обязан быть синхронным с входным STM64. Другой вопрос, что, как правило, этими стаффингами никто не пользуется и эти потоки синхронны.
Ну и если бы Вы внимательно читали топик то, увидели бы что у меня скорость входного и выходного потоков равны.
Однако, если Вы упаковывали STM64 в OTU2 без использования стафинга на Стратиксе, то сможете ответить на мой вопрос.

запускал "с одинаковой скоростью" хотя и на 9.8304 Gbps(cpri)
не могу понять какие могут быть проблемы с этим.

Тоесть у Вас частота выделенная в CDR(встроенного в ПЛИС) из входного сигнала используется для формирования выходного потока?
Используете мегафункцию ALTGx?

Это как раз потому, что мало у кого есть схема с условным ГУН на выходе .


Да, но написано, что в будущем будут "синхронны", а еще про скремблер и помехоустойчивый код :D.


Да Вы сами давно на него ответили.
Весь вопрос не в том, можно или нет, а в том, как преодолеть отсутствие в железе нужной Вам фичи.

Ну да писал . Просто уже и так путаница с терминами пошла, так что оставим пока только скремблер.


Это Вы про стаффинг или про ГУН?

Даже если такое возможно, то скорее всего джиттер будет слишком высок.

А что мешает повесить на reference clock всех трансиверов какую-нибудь подходящую внешнюю частоту?
Или на плате совсем нельзя ничего менять?

Да полно там генераторов, только что это даст? Мне сигнал надо выдать не на частоте сформированной на основе частоты этого генератора, а на частоте сформированной на основе частоты, восстановленной из входного сигнала.

для моего случая референс клок -307.2 МГц recovered clk был такой же.
так и не пойму где тут проблема

Референс клок - это частота генератора, стоящего на вашей плате. Так?
recovered clk - это частота входного битового потака/32. Так?
Обе частоты равны 307.2 МГц, но они не синхронны, их фазы плывут друг относительно друга.
Входной поток у вас синхронен с recovered clk, а на выход вы должны подавать данные, синхронные с референс клок. Т.е. входной и выходной потоки у вас равны по скорости, но не синхронны.
А у меня входной поток закрываестя скремблером и подаётся на выход, т.е. входной и выходной потоки равны по скорости и синхронны.

Ключевое слово - "PLL". Или я чего-то сильно не понимаю в Ваших рассуждениях.

На внешний reference clock для трансивера можно подавать хоть 10 МГц (см. даташит). FPGA на внутренних PLL его умножает и синхфронизирует по фазе с recovered clock. Но для тактирование я внутренней логики всегда используется именно умноженный reference clock (ибо джиттер ниже).

Более того, скорость входного потока может динамически меняться. И умноженный reference clock будет динамически синхронизироваться с recovered clock (в определенных пределах, конечно).

То что вы пишите очень похоже на правду, толлько вот у мегафункции трансивера есть два клока RxClkOut - "умноженный reference clock синхронный по фазе с recovered clock" и TxClkOut(важно что out) по которому я должен подавать данные на выход, так вот этот TxClkOut - умноженный reference clock не синхронный по фазе с recovered clock.
Ну и врядли reference clock синхфронизирует по фазе с recovered clock в PLL.

хм....
1) Фазы не плывут или плывут, мне пофиг см п2
2) хотите синхронности разделите клок домены. мне так и пришлось сделать. тоесть 307.2 МГц это реф клок. а есть ещё кор клок он 245,76.
тоесть имеем TX часть где write clock 245.76 а read clock 307.2 (тут же 8b10b coder) потому и частота выше
так же имеем RX часть где write clock 307.2 (тут же 8b10b decoder) и 245.76 read clock.
как вы понимаете 245.76 МГц это core clock. и надеюсь Вы уже поняли что без PLL тут никак.
если же девайс будет подключаться например оптикой, то в случае ведомого(slave) девайса тут тем более никак без внешних -> PLL+jitter cleaner+VCXO
если же pcie(тоесть подлючение локальное - межплатное) то источник реф клока ясное дело где+кто %) тоесть в это случае не нужны PLL+jitter cleaner+VCXO

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