RobFPGA

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

Я по витой паре от 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]

Так пишут же - в группе куда назначены IODELAY нет IODELAY_CTRL ... У вас в дизайне может быть несколько групп в которые назначаются некоторые IODELAY и каждую из которых должен быт назначен свой IODELAY_CTRL Для этого соответствующий параметры имени группы в IODELAY и IODELAY_CTRL. Вам надо влепить где то IODELAY_CTRL и задать ему имя группы как в контроллере. Ну или наоборот - задать имя группы в контроллере как в уже стоящем IODELAY_CTRL

Плохой вариант для оценки быстродействия и ресурсов. Правильно сделать как выше и предлагали - тестовый топ с обязательными доп. регистрами на всех входах и выходах вашего модуля. А чтобы не напороться на нехватку пинов для такого то все эти доп. регистры можно сделать сдвиговыми - тогда на топе будет всего 1 вход и 1 выход ...

В не-реалтаймовых OS никакой "реально достижимый риалтайм" невозможен. Поскольку реалтайм OS это не столько малое время реакции на событие, а сколько минимально-гарантированное время. Если OS не реалтайм то никаких гарантий нет, поэтому и реалтайм недостижим. Достижимо лишь некое среднее время с дисперсий и выбросами в максимум вплоть до космоса ...

Example это внешний проект по отношению к библиотеке/корке ... Так что IO задержки определяются физикой конкретной платы.