RobFPGA

Структурно это происходит методом чтения доков, даташитов, .., и в последствии коррекции запросов в соответствии с полученной новой информацией ... А не структурно, по простому - 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, чисто на логике

По согласованной витой паре или обычным LVDS кабелям на пару метров 200 MHz без проблем передаётся. Кодирование 4b5b / 8b10b / 64b66 / ... нужно лишь тогда когда данные в линиях LVDS развязаны по DC или надо восстанавливать клок. Если отдельной парой кинете клок то на приёмной стороне будет нужна лишь подстройка фазы, и то статическая (на 200 MHz), автомат это если уж совсем кабеля левые.

Модуль без использованных выходов может оптимизироваться при синтезе/P&R Поэтому либо как то используйте выход RDY либо атрибутами (KEEP, DONT_TOUCH) запретите оптимизацию.

Ну так откройте синтезированный дизайн, найдите IDELAY и IDELAY_CTRL и посмотрите в property какие там группы. А заодно и проверьте в открытом дизайне находит ли по указанным в констрейне путях соответвуюшие примитивы.

Да где угодно, или в коде : module blabla (...); ... (* IODELAY_GROUP = "ABCD" *) // Specifies group name for associated IDELAYs/ODELAYs and IDELAYCTRL IDELAYCTRL IDELAYCTRL_inst ( .RDY(RDY), // 1-bit output: Ready output .REFCLK(REFCLK), // 1-bit input: Reference clock input .RST(RST) // 1-bit input: Active high reset input ); ... или в xdc set_property IODELAY_GROUP "ABCD" [get_cells blabla/IDELAYCTRL_inst]