Jump to content

    
Hexa

Тактирование высокоскоростных приемопередатчиков zynq-7000

Recommended Posts

Добрый день.

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

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

Share this post


Link to post
Share on other sites
1 час назад, Hexa сказал:

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

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

Share this post


Link to post
Share on other sites
33 minutes ago, fguy said:

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

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

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

Share this post


Link to post
Share on other sites

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

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.

cpll.png

Share this post


Link to post
Share on other sites
1 minute ago, RobFPGA said:

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

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

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

7 minutes ago, Hexa said:

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

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

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

Удачи! Rob.
 

Share this post


Link to post
Share on other sites
13 минут назад, RobFPGA сказал:

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

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

Share this post


Link to post
Share on other sites

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

5 minutes ago, fguy said:

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

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

Удачи! Rob.

Share this post


Link to post
Share on other sites
21 минуту назад, RobFPGA сказал:

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

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

Share this post


Link to post
Share on other sites
16 minutes ago, rloc said:

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

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

Share this post


Link to post
Share on other sites

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

2 hours ago, fguy said:

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

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

2 hours ago, rloc said:

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

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

Удачи! Rob.   

Share this post


Link to post
Share on other sites
44 минуты назад, RobFPGA сказал:

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.