RobFPGA

Это всего-лишь требует увеличить число "медленных труб" на выходе GTY/JESD - Если грубо считать то 12 бит 10Gs/s то скорее всего используются 8 линий по 15 Gbit/s, что даёт при 32 бит интерфейсе GTY на линию ~469 MHz (2.13 ns) или ~234 MHz (4.26 ns) для шины 64 бит. Для 8 линий соответственно будет шина 256 или 512 бит. Для VU19 мелочи ... А дальше уже все зависит от вас - хотите обрабатывайте эти 256/512 на лету, а хотите то и буферизируйте как вам удобно

Так и я об этом же - как я выше вам уже говорил - 10Gbit всего-навсего каких то жалких ~1 GByte/s. Это частота 312.5 MHz (3.2 ns) для шины данных в 32 бита, или 156.25 MHz (6.4 ns) для шины в 64 бит. Неужели ваша версия VU+ 19p не способна работать на таких частотах? Может это не VU+ а GOW+ ? ...

Ещё раз - буферизация в общем случае нужна в тогда когда скорости потоков на входе и выходе не совпадают. Как в школьной задачке про две трубы и бассейн ... Если скорости входных и выходных потоков равны то зачем вам буфер? Если на вход GTY (или JESD204) вливается поток по одной быстрой "трубе" в 10G bit/s и такой же поток 10GBit/s из него выливается по 32 медленным "трубам" зачем вам внутри этой корки бассейн/буфер ? А если скорость выходящего потока даже больше чем входящего тем более бассейн/буфер не нужен, в этом случае достаточно простого тазика/регистра ... Поэтому повторюсь - почитайте доки - и сформулируйте ваши желания более понятно - что вы хотите сделать?

И не увидите ... Да и зачем он (буфер) нужен если эти корки выдают данные с той же скоростью что и получают?

Структурно это происходит методом чтения доков, даташитов, .., и в последствии коррекции запросов в соответствии с полученной новой информацией ... А не структурно, по простому - GTY это конвертор сериал в паралель, почти как SPI ... Поэтому если у него на последовательном 1 бит входе 10Gbit то на параллельном 32 бит выходе будет 10/32 = 312.5 MHz (3.2ns) что уже удовлетворяет ваши лимиты в 2ns.

Чет то каша кая то - гигабиты, наносекунды, GTY ... GTY вам как раз и "согласовывает" гигабиты с наносекундами так как принимает быстрые гигабиты последовательно, а выдаёт принятое паралельно медленно на наносекундах которых хватит для записи в память или обработки ... А вот как вы будете буферизировать принятые параллельные данные зависит только от вас (и хотелок дизайна) - либо в FIFO либо в двойной/кольцевой буфер в BRAM/DDR либо хоть сразу по 10G/40G/100G сети на сервер для вечного хранения ...

Никак ... Просто после обычной конфигурации IP корки в меню Generate Output product нужно выбрать Synthesis Options - Global Ну или в tcl set_property generate_synth_checkpoint false [get_files core_name.xci] Значит скорее всего этот корка криптована и доступ с сорцам ограничен. В этом случае обычными средствами Vivado ничего не сделать ...

Вас не устраивает использование обёртки IP в вашем RTL? Тогда можете попробовать компилировать корку не в режиме OOC, а в режиме global, тогда вам в RTL будет доступны все исходные потроха IP и вы можете в своём коде использовать любой ее исходник. Только учтите что самоуправство может ломать констрейны для IP поскольку они часто привязываются к иерархии начиная от враппера корки.

Там пишут немного другое, скорее даже совсем другое ...

Я по витой паре от Ethernet 5кат. гонял 2.5 GBit сердесами от TI, на 10 м! Со скруткой по середине! ... Но это был скорее эксперимент, а не продакшен. Ещё раз IMHO - 200 MHz сейчас не настолько критическая частота чтобы заморачиватся для этого кабелями от PCIe3 в серебряной оплётке с золотыми жилами. В своё время по обычному серому плоскому шлейфу 2.5 mm гоняли 133 MHz на пол метра, безо всяких LVDS, шиной singl-ended TTL, да ещё и с двумя потребителями на конце. И это было в массовом продакшене, в каждом PC ... Поэтому выбор кабелей велик, я бы в вашем случае выбирал сначала по мех. характеристикам, а потом уж по эл. Но желательно конечно хоть что то узнать о кабеле заранее, ну или практический эксперимент покажет что есть ху... P.S. С импульсными, высоковольтными/сильноточными помехами сложнее. Теоретически в трубе внешнего поля не должно быть (если конечно вы это поле не дуете в трубу). Практически же борьба с импульсными помехами напоминает борьбу Дон Кихота с мельницами. Ведь кроме проводов в трубе у вас будут и соединённые этими проводами устройства на концах этой трубы которые как то должны с внешним полем взаимодействовать. Поэтому все очень индивидуально для каждой системы и сильно зависит как от общей конструкции так и от мелких деталей и качества исполнения. И редко все работает с первого раза без итераций на реальном железе PP.S. Может чтобы не бороться с мельницами рассмотреть оптику, например пластиковый фибер на 155 Mbit. В своё время использовали такой для линии связи с МК который работал под импульсным потенциалом до 30 КV c длит. импульсов от 50 - 1000 ns

Отсутствие DC развязки повышает требования к качеству "земли" между платами. А у вас ещё и POE питание по этому же кабелю ... Для DC не обязательны трансформаторы, можно развязать и кондерами. 8b10b не влияют на число ошибок в лини, это зависит скорее от эл. окружения линии. Но надо не забывать что кодирование 8b10b снижают на 20% скорость передачи данных. При равной битовой скорости без кодирования. Ну или требуют повышение битовой скорости. Если пишут HDMI то должно быть 100 Ом, но это могут быть и китайские 100 ом ...

Так нужен не MAC а PHY уровень ...

Тогда уж и на PCIe с SRIO тоже посмотреть, это посложнее будет ...

Нет, неправильно. Кодирование 8b10b работает "само по себе" без необходимости восстанавливать клок. Главное чтобы этот клок был. Если вы будете передавать клок отдельной парой то 8b10b (или другие подобные) нужен будет лишь для устранения проблем c DС развязкой. Например вы передаёте клок отдельной парой, и можно на частоте в 2 раза меньше чем битовый поток. А на приёмной стороне нужно будет лишь выровнять задержку клока на середину окна бита, и принять биты по обоим фронтам на DDR, а затем уже декодировать 8b/10b с выравниванием на слово и контролем четности. Так же и на перечу, 8b10b кодирование и в DDR передача используя для передачи принятый клок. Для 200MHz, c окном ~5 ns, для нормального LVDS кабеля, и обычных условий эксп. даже не нужно делать автоподстройку фазы приёма. Работает и на статическом ручном подборе.

Не знаю как в GOWINe, а в стареньком Spartan3 и Virtex4 LVDS в чистом SPI режиме на ~200MHz работало безо всяких проблем. И даже без DLL/PLL. На внешнем LVDS кабеле 2м с разъёмами. Кабель 5 пар, одна пара - клок. Но естественно это без DC развязки. И я даже пробовал извращался и делал синхронизацию передачи выкалывая несколько тактов клока и детектируя это на приёмной стороне. Тоже работало. Но все же было проще сделать норм 8b/10b кодирование и поднять скорость. Получается универсальнее и DC развязка без проблем P.S, И все это без serdes, чисто на логике