[Hexa 0]

Добрый день.

При использовании высокоскоростных приемопередатчиков GTX возникла необходимость установить опорными тактами на передатчике непосредственно выделенные из приёмника. Кто нибудь делал что нибудь подобное? 

Как я понял из схем из ug476 это можно сделать только одним способом, а именно если опорный клок на приёмник завести через cpll, а на передатчик уже используя qpll (используя другой вход mgtrefclk ПЛИС, на который уже и заводится каким-либо образом выделенная частота), но проблема в том что скорость на которой я работаю 1.2 Gbps, что не входит в диапазон работы qpll. 

[Arlleex 131]

Ты б хоть нарисовал схематично, что хочешь сделать. Не рассматривал варианты внешних CDR, например, раз ПЛИС-а не позволяет?

[fguy 4]

1 час назад, Hexa сказал:

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

Это же не значит что выделенные приемником такты будут 1.2 ГГц - на юзер-клок будет где-то 30-40 МГц при 32 битах данных. А в чем проблема запитать передатчик теми же тактами что и приемник - это как бы норма, тем более на одном GTX?

[Hexa 0]

33 minutes ago, fguy said:

Это же не значит что выделенные приемником такты будут 1.2 ГГц - на юзер-клок будет где-то 30-40 МГц при 32 битах данных. А в чем проблема запитать передатчик теми же тактами что и приемник - это как бы норма, тем более на одном GTX?

Про юзер клок всё понятно, тут внутренее ограничение qpll, его делителями устанавливается скорость линии, которую нельзя получить меньше 3Gbps, там 2 ГУНа с определёнными полосами, выбираются они в зависимости от установленных делителей.

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

[RobFPGA 27]

Приветствую!

44 minutes ago, fguy said:

Это же не значит что выделенные приемником такты будут 1.2 ГГц - на юзер-клок будет где-то 30-40 МГц при 32 битах данных. А в чем проблема запитать передатчик теми же тактами что и приемник - это как бы норма, тем более на одном GTX?

Судя по всему TC хочет реализовать синхронную схему когда битовая частота TX до фазы равна частоте приема на RX.  Проблема в том что в 7-series внутри FPGA это напрямую почти не реализуемо. 
Так как на сколько помню питание реф. клока для GTX всегда идет снаружи. 

Можно попробовать использовать как реф. для TX внутренний сигнал (GTGREFCLK) из глобального клока получаемого из RX, но Xilinx не рекомендует это и пишет что это для лишь для внутреннего тестирования.   

Другой способ для этого  это создание внутренней цифровой DPLL которая подстраивает клок TX  по частоте и фазе к клоку RX. У Xilinx были apnotes на эту тему, но я не помню возможно ли это для Zynq семейства.

     

Удачи Rob.

[Hexa 0]

1 minute ago, RobFPGA said:

Приветствую!

Судя  по всему  TC хочет реализовать синхронную схему  когда  битовая частота  TX до фазы  равна  частоте  прима на RX.

Спасибо, иммено так.

Внутренний сигнал GTRefClk пробовал использовать. В версии Vivado 2014.2 это работало с предупреждением (по крайней мере  так утверждают на форуме xilinx), более поздних версиях это стало критической ошибкой. 

 

У gtx 2 внешних входа тактирования, и проблема даже в том что я немогу использовать для одного канала разные входы (ну кроме использования qpll, который мне тоже не подходит) 

Видимо прийдётся синхронизировать через второй канал приемопередатчика со второй линией связи. 

[RobFPGA 27]

Приветствую!

7 minutes ago, Hexa said:

Внутренний сигнал GTRefClk пробовал использовать. В версии Vivado 2014.2 это работало с предупреждением (по крайней мере  так утверждают на форуме xilinx), более поздних версиях это стало критической ошибкой.

Оно и понятно - видно качество такого референса маловато и Xilinx не может это гарантировать. 

Вот как пример  xapp589  про TX  DPLL для похожего применения. И да - Zynq там тоже есть.  
 

Удачи! Rob.
 

[fguy 4]

13 минут назад, RobFPGA сказал:

Судя  по всему  TC хочет реализовать синхронную схему  когда  битовая частота  TX до фазы  равна  частоте  прима на RX.

А в чем сакральный смысл такой "синхронности"? GTX это асинхронные каналы как ни крути. К тому же для гигабита уже есть более жесткие требования к качеству внешних опорных тактов, а то что восстановлено годится только для юзер-клок и отражает реальную скорость данных.

[RobFPGA 27]

Приветствую!

5 minutes ago, fguy said:

А в чем сакральный смысл такой "синхронности"? GTX это асинхронные каналы как ни крути. К тому же для гигабита уже есть более жесткие требования к качеству внешних опорных тактов, а то что восстановлено годится только для юзер-клок и отражает реальную скорость данных.

Смыслов  может быть  много - начиная от построения синхронных сетей как в апликухе  выше и заканчивая уменьшением latency (за счет избавления от CDC FIFO) при обработке внутри FPGA.

Удачи! Rob.

[fguy 4]

21 минуту назад, RobFPGA сказал:

Смыслов  может быть  много - начиная от построения синхронных сетей как в апликухе  выше и заканчивая уменьшением latency (за счет избавления от CDC FIFO) при обработке внутри FPGA.

Темп данных обычно ниже выставленной скорости канала, а обмен пакетный - понятие латентности и ее снижение в таком случае теряет всякий здравый смысл. Применительно к дсп обработка в плис имеет такую латентность (один поточный бпф 8к фп32 дает 10ки тысяч тактов), что даже задержки в JESD не имеют смысла, а в задачах когда имеют проще перейти на параллельный интерфейс с цап/ацп.

[rloc 43]

3 часа назад, Hexa сказал:

скорость на которой я работаю 1.2 Gbps

Это скорость обычных DIFF_HSDL буферов, к чему GTX?

[quato_a 3]

16 minutes ago, rloc said:

скорость на которой я работаю 1.2 Gbps

кстати, да. к примеру для artix-7 (на котором собрано простейшая zynq) смотрите table 15 в ds181 - DDR LVDS TX/RX до 1250 Мбит/с.

[RobFPGA 27]

Приветствую!

2 hours ago, fguy said:

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

Всегда есть какой то смысл. А для некоторых применений снижение latency на 50-100 ns может иметь очень существенный смысл. 

2 hours ago, rloc said:

Это скорость обычных DIFF_HSDL буферов, к чему GTX?

К тому что к обычными DIFF_HSDL буферам не прилагается схема восстановления RX клока (CDR) из потока данных . Если не использовать GTX придется это как то "колхозить" внутри FPGA или использовать внешний CDR.  
   

Удачи! Rob.   

[rloc 43]

44 минуты назад, RobFPGA сказал:

к обычными DIFF_HSDL буферам не прилагается схема восстановления RX клока (CDR) из потока данных

Как я понял, автор пытается засинхронизировать приемник и передатчик одним клоком. Тогда зачем восстанавливать клок, если его можно передавать со стороны передатчика/приемника напрямую на высокой частоте, а не пытаться умножать на PLL из низкой частоты?

[fguy 4]

Судя по скоростям скорее всего все делается под обычный гигабитный SFP с оптикой, а там GTX самый простой вариант подключения к SFP.