[RobFPGA 27]

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

41 minutes ago, rloc said:

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

Как передавать? Отдельной линией с клоком? Да так можно, но это совсем другой принцип построения сети. Но что делать если сеть (Ethernet) уже есть.
В Ethernet восстановленный RX клок отличается по частоте и фазе от локального опорного и cоответвенно от TX клока. 
А если вы имеете ввиду передать восстановленный в CDR RX клок из приемника непосредственно как реф. в TX то увы - в 7-series этого не сделать:

 

Удачи! Rob

[Hexa 0]

3 hours ago, RobFPGA said:

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

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

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

Удачи! Rob.   

Всё так и есть, схема восстановления необходима. 

2 hours ago, fguy said:

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

И да используется оптика с sfp.  На текущий момент sfp имеется только гигабитный на руках. 

Изменено 23 ноября, 2021 пользователем Hexa

[attaboy 0]

16 hours ago, RobFPGA said:

А если вы имеете ввиду передать восстановленный в CDR RX клок из приемника непосредственно как реф. в TX то увы - в 7-series этого не сделать:

А в каких случаях вообще такое извращение нужно? Приходит мысль - чтобы обойтись без локального refclk. Но нет, чтобы восстановить rxclk, нужен какой-то опорный клок.

[fguy 4]

14 часов назад, Hexa сказал:

И да используется оптика с sfp.  На текущий момент sfp имеется только гигабитный на руках. 

Если не секрет то зачем вам синхронизировать TX тактами с RX - на паре цинков оно и так прекрасно работает и с "обычной" запиткой тактами RX и TX? Могу конечно и это попытаться угадать - в ответке цинку стоит какой-нибудь "российский колхоз", который не так легко адаптируется к сигналу как GTX в цинке.

Для работы с SFP можно найти чипы с внешними драйверами и более широкими возможностями конфигурации (например у Cypress), но у меня в проекте оно как то не пошло - GTX для SFP это самый легкий вариант подключения.

Изменено 24 ноября, 2021 пользователем fguy

[RobFPGA 27]

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

1 hour ago, attaboy said:

А в каких случаях вообще такое извращение нужно? Приходит мысль - чтобы обойтись без локального refclk. Но нет, чтобы восстановить rxclk, нужен какой-то опорный клок.

Уже  говорил  для чего :

22 hours ago, RobFPGA said:

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

Без  локального референса в любом случае не обойтись. 
 

Удачи! Rob.

[Hexa 0]

В общем удалось полностью за синхронизировать 2 платы по оптическому каналу, и передаваемый с первого устройства пакет приходит с одной и той же задержкой (отличие между пакетами не более 1нс) от отправки (пакет на первом устройстве сформирован в тактах выделенных из принятых данных второго устройства). 
На текущий момент пришлось использовать второй оптический канал, из которого на одном устройстве одним GTX выделяется опора и заводится на второй вход тактирования GTX ПЛИС, таким образом второй (в моём случае основной) GTX имеет опору TX и RX одинаковой частоты. Предполагаю что используя более высокоскоростные SFP смогу обойтись одним каналом, за счёт использования на RX - CPLL а на TX - QPLL, или можно использовать другую ПЛИС с GTP, на них RX и TX можно тактировать с разных PLL. 

Сейчас пытаюсь решить другую проблему, а именно добиться одинаковой задержки между передачей и приёмом при перезапуске и перенастройке GTX. Думал связано с использованием RX Buffer, но при его отключении задержка при перезапуске всё равно разная, может отличаться на 40-60 нс. 

[RobFPGA 27]

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

3 minutes ago, Hexa said:

Сейчас пытаюсь решить другую проблему, а именно добиться одинаковой задержки между передачей и приёмом при перезапуске и перенастройке GTX. Думал связано с использованием RX Buffer, но при его отключении задержка при перезапуске всё равно разная, может отличаться на 40-60 нс

А какой функционал у вас включен в GTX?  Если нужна детерминированная задержка нужно выключать все внутри (для начала хотя бы elastic buffer) и делать требуемый функционал снаружи, в обычной логике.
Причем и на передающей и на приемной стороне.

 

Удачи! Rob. 

[des00 25]

10 hours ago, RobFPGA said:

А какой функционал у вас включен в GTX?  Если нужна детерминированная задержка нужно выключать все внутри (для начала хотя бы elastic buffer) и делать требуемый функционал снаружи, в обычной логике.
Причем и на передающей и на приемной стороне.

и все равно ИМХО разбежитесь на выраванивании в десериализаторе. там +-1 бит, потом будет словный выравниватель и пошло поехало. Причем недетерминированно. Когда мне нужно было синхронизировать 12 каналов, я ставил метку времени и внешней логикой привязывал каналы к восстановленной метке.

[RobFPGA 27]

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

2 hours ago, des00 said:

и все равно ИМХО разбежитесь на выраванивании в десериализаторе. там +-1 бит, потом будет словный выравниватель и пошло поехало. Причем недетерминированно. Когда мне нужно было синхронизировать 12 каналов, я ставил метку времени и внешней логикой привязывал каналы к восстановленной метке.

1 бит разбежки при десериализации это понятно. Но откуда берутся остальные 40-60ns у TC?   В синхронном режиме при ручном управлении выравниванием в RX можно добиться словной синхронизации без доп. задержек. И если весь функционал внутри GTX выключен  это  будет фактичекски только сдвиговый регистр фазу десериализации которого подстроили на границу слова. Задержка в таком режиме минимальна и детерминирована. И если обработка  данных в FPGA и передача ведется на едином клоке ( восстановленном из RX) то тоже неоткуда взяться недетерминированной задержке. 

   

Удачи! Rob.

[des00 25]

1 hour ago, RobFPGA said:

Но откуда берутся остальные 40-60ns у TC? 

да легко. он выравнивается в разные стороны. один в минус символ, второй в плюс символ.

Quote

В синхронном режиме при ручном управлении выравниванием в RX можно добиться словной синхронизации без доп. задержек.

ЕМНП там выравнивание идет за счет отбрасывания бита bitslib. два потока могут встать как -1/0 так и 0/-1 (где 0 это точная фаза бита потока), это следствие работы CDR, если выравнивать их дропами, то они как раз и разбегаются на символ.

Quote

 И если обработка  данных в FPGA и передача ведется на едином клоке ( восстановленном из RX) то тоже неоткуда взяться недетерминированной задержке.

ЕМНП там же две CDRки сделанные по приницпу DLL, поэтому, не смотря на то что частота будет одинаковая фаза семплирования может будет разная.

[RobFPGA 27]

1 minute ago, des00 said:

ЕМНП там выравнивание идет за счет отбрасывания бита bitslib. два потока могут встать как -1/0 так и 0/-1, это следствие работы CDR, если выравнивать их дропами, то они как раз и разбегаются на символ.

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

Quote

Manual Alignment
RXSLIDE can be used to override the automatic comma alignment and to shift the parallel
data. RXSLIDE is driven High for one RXUSRCLK2 cycle to shift the parallel data by one
bit. RXSLIDE must be Low for at least 32 RXUSRCLK2 cycles before it can be used again.
Figure 4-36 shows the waveforms for manual alignment using RXSLIDE in
RXSLIDE_MODE = PCS, before and after the data shift. When RXSLIDE_MODE = PCS is
used, the number of bit shift positions when consecutive RXSLIDE pulses are issued is also
determined by the comma alignment boundary set by ALIGN_COMMA_WORD,
RX_DATA_WIDTH, and RX_INT_DATAWIDTH. For example, if the RX_DATA_WIDTH
is 20 bits and ALIGN_COMMA_WORD is 1, after the 9th slide operation, the slide position
returns back to 0. For the same RX_DATA_WIDTH setting, for an
ALIGN_COMMA_WORD setting of 2, the slide position returns to 0 after the 19th slide
operation. Thus in RXSLIDE_MODE = PCS, a maximum of 40 bits of sliding is possible
when RX_INT_DATAWIDTH= 1 (4-byte) and ALIGN_COMMA_WORD = 4.

RXSLIDE_MODE = PMA before and after the data shift. In this mode, the data is shifted
right by one bit for every RXSLIDE pulse issued, but there is some intermediate data with
the bits shifted left before the final data appears on the bus. When
RXSLIDE_MODE = PMA is used, the RX recovered clock phase is shifted by 2 UI for every
alternate RXSLIDE pulse.

 

8 minutes ago, des00 said:

ЕМНП там же две CDRки сделанные по приницпу DLL, поэтому, не смотря на то что частота будет одинаковая фаза семплирования будет разная.

 На TX стороне фаза передачи "привязана" к фазе TX клока, и если этот клок с фазирован с RX то опять же разбежки более чем на бит получится не должно. 

[des00 25]

13 minutes ago, RobFPGA said:

же разбежки более чем на бит получится не должно. 

да, но вы же работаете снаружи корки не с битовым потоком, а со словным. И интерфейс у вас на широком слове. И вот эта разбержка на бит может перейти в разбежку на символ. Т.к. сам символ у вас соберется позже/раньше.

Попробую на пальцах. Есть битовый поток, положим слово у нас 6 бит. Слово мы кладем с нулевого бита на стороне передатчика. Отравили Т Е В И Р П.

В каналы пришло

х х Т Е В И Р П х х х  - положим удачно попали что буква Т - пришлась на нулевой бит сдвигового регистра,

х х х Т Е В И Р П х х х х   - а вот здесь вам нужно додвинуть поток бит  влево на 1 битовый интервал. ЕМНП штатно для этого нужно будет сделать 5 сдвигов вправо. И в итоге слово соберет свои 6 бит на один выходной символ позже.

Ну оке, решили выровнять регистром на широком слове, поставили, но при другом включении порядок прихода бит может поменяться). ЕМНП это влияние CDR + эквалайзера. И в итоге снова мимо. Если бы работали на уровне битов, проблем было бы меньше, но не тянет плиса.

[RobFPGA 27]

Just now, des00 said:

да, но вы же работаете снаружи корки не битовым потоком, а со словным. И слово у вас собирается на широком слове. И вот эта разбержка на бит переходит в разбежку на символ. Т.к. сам символ у вас соберется позже.

Как так?  - Как раз bitslip  и призван выровнять начало десериализации на первый бит слова. Поэтому на входе RX каждый такт будет правильное выровненное слово. 
В  TX тот же процесс но в противоположную сторону - каждое новое слово на низкой частоте TX (которое в фазе c RX) запускает сериализацию.  Получается чисто синхронная схема без недетерминированных задержек.

Разбежка на задержки в 1 бит в RX остается но эта недетерминированность чисто за счет неопределённости фазы восстановленного клока в CDR. 

Недетерминированность в слово тут может быть если bitslip делается не честно, пропуском бит (изменением фазы начала десериализации), а методом переключения битов с выхода широкого (2x выходной разрядности) сдвигового регистра. Но на сколько я помню  это не так.   

[des00 25]

Quote

Недетерминированность в слово тут может быть если bitslip делается не честно, пропуском бит (изменением фазы начала десериализации), а методом переключения битов с выхода широкого (2x выходной разрядности) сдвигового регистра. Но на сколько я помню  это не так.   

ЕМНП там пропускается одна фаза счета: не добавляется следующий бит в сдвиговый регистр и нет инкрементирования счетчика выходного слова.

Может мы про разные GTX/GTH говорим или я готовить не умею, но на 7-Series у меня разбегались потоки. даже те которые шли с одной плисы, с двух GTX на два GTX другой плисы. В итоге я поставил небольшое FIFO + метки времени и все выравнивалось автоматически.

ЗЫ. Еще вспомнил проект на Ария 5. Делал заворот на двух плисах, хотел задержку оптического кабеля измерить, в символах. В GTX все по минимуму, все синхронно, ничего лишнего на завороте. В итоге +-1 символ относительно среднего, от включения к включению. Даже если просто оптику перетыкать, не выключая плис.

[RobFPGA 27]

38 minutes ago, des00 said:

Может мы про разные GTX/GTH говорим или я готовить не умею, но на 7-Series у меня были разбегались потоки. даже те которые шли с одной плисы, с двух GTX на два GTX другой плисы.

Два отдельных потока могут разойтись как раз и за недетерминированности фазы CDR на 1 бит. И естественно разных задержек в физике. Тут уж никуда не деться. 
Но после выравнивания слова bitslip-ом выглядеть это должно как разная фаза восстановленного RX клока на низкой частоте. Но если на стороне передачи TX клок общий и фазированный то и разница фаз RX на приемной стороне тоже должна быть постоянной.  Опять же тут важен и TX канал. Так как в TX есть возможность крутить фазу передатчика (TX Phase Interpolator PPM). Причем динамически. На чем собственно и пытаются делать DPLL для синхронизации частоты и фазы TX по восстановленному клоку RX. 
 

Увы у меня не было практической задачи выравнивания и синхронизации нескольких каналов. А вот задач по минимальной и детерминированной latency по пути RX - TX полно