Flood

Да, 17.2. Какие методы решения?

Столкнулся с новым для себя вопросом при обновлении ревизии печатной платы. Возможно, это называется Back-Annotate (?). Имеется готовый проект - схема + печатная плата. Требуется сделать новую ревизию проекта, слегка изменить схему и т.п. Схема - Orcad, ПП - Orcad/Allegro. Проблема такая - в изменяемой схеме какое-то количество компонентов удаляется, а некоторое число новых добавляется. Соответственно, страдает нумерация refdes - на схеме появляются дыры в нумерации, а также возникают новые позиции. Всего изменяется не более 10% схемы, при этом плата очевидно не требует полной переразводки, нужна только небольшая доработка. После окончания внесения изменений в схему хотелось бы перенумеровать все позиции, чтобы избавиться от дыр. При тупой перенумерации со сбросом refdes страдает связь с платой - съехавшие номера компонентов не обновляются на плате автоматически, возникает хаос. Как бы этого избежать, т.к. как сделать перенумерацию так, чтобы не нарушилась синхронизация с платой?

Именно с ними и перепутал :)

Это и есть ответ на вопрос - MAC-уровень неправильно разделяет пакеты. Из-за разницы частот PCS/PMA ядро может как уменьшить, так и увеличить количество idle-символов, для этого они и нужны. Картина в линии и картина на шине xgmii после приведения частот конечно не будет одинаковой. Чтобы увидеть реальную картину на приемной линии (например, для проверки передатчика) потребовалось бы отключить elastic buffer и работать на приеме по восстановленной частоте. При этом rx clock и tx clock стали бы разными.

CXP это что-то устаревшее, разве нет? И размер такого модуля довольно крупный. Насчет температур - существуют телекомовские модули SFP+ / QSFP+ с расширенным диапазоном температур для сотовых сетей (CPRI / 10G / 25G). Но это 1 или 4 линка всего.

Вы даете информацию очень маленькими кусочками и предлагаете угадать, что и где не так. Что за CRC бьется, кто его считает на приеме? Откуда идут пакеты, как часто (много), и кто обеспечивает им верный CRC - все это совершенно непонятно. В линии - да.

CRC проверяется на MAC-уровне, ядро PCS/PMA этого не делает Клок coreclk (coreclk_out) - это верно

Да, сразу не заметил эту деталь :)

Пропал (если вообще был?) авторедирект с http на https. При входе на http логин не виден (выглядит, будто вход сбросился), но если вручную перейти на https - все ок. Конечно, если логин и куки ставились через https. По-моему, правильнее было бы вообще не отдавать через http страницы форума, возвращая только 302 на htttps версию страницы.

Нет ли у китайцев аналогов Mantis Elite?

Неплохо. А можно скриншот или лучше фото, сохраненное непосредственно с камеры?

Казалось бы, при чем тут ПЛИС? Карта на графпроцессоре AMD.

С другими устройствами сетевая карта работает? pma_pmd_type обычно SR (хотя конечно не знаю что у вас в действительности). Но проблема вряд-ли из-за этого.

Интересный вопрос - а что со связанными клоками? Например, наиболее интересный и простой случай - переход шины через связанные клоковые домены, первый частотой f и шириной 2n, а второй - частотой 2f и шириной n. Такой переход (как в одну сторону, так и в другую) возможен без развязывающего fifo, вопрос - как его корректно реализовать и отконстрейнить?

Да, согласно последнему даташиту, в том числе и 10. Но какой у вас корпус? 484 или 676? Точно! Мои сведения устарели. Но поправка только для корпуса 484: "GTX transceivers in FB packages support the following maximum data rates: 10.3Gb/s in FBG484; 6.6Gb/s in FBG676 and FBG900. Refer to Kintex-7 FPGAs Data Sheet: DC and AC Switching Characteristics (DS182) for details."

Официально это невозможно Дело именно в этом. На 7 серии 10GbE требует металлический корпус FFG / FG. А XC7K70T выпускается только в корпусах без крышки - FBG, где макс. скорость GTX 6 с хвостиком гигабит. И от спидгрейда кристалла тут уже (официально) ничего не зависит. Хотя интересно, у вас -1, -2 или -3 ?

Если сигнал валидности поднимется после стабилизации данных и через время, гарантированно большее тактового периода приемного домена, п. 4 должен быть излишним. Поправьте, если это не так.

Рекомендации по числу конденсаторов даны в 7 Series FPGAs PCB Design Guide (UG483). Меньше 4,7мкФ в этих рекомендациях вообще нет.

Да, форум кое в чем поломался, но сомневаюсь, что можно вернуть все назад, починить новый, и потом когда-нибудь перейти. Это утопия. Если что-то и удастся починить, то это новый форум. Я за сохранение старого форума в read-only, но не более того.

Опыт вещь полезная. Обучение на битой плате с неизвестной схемой - то еще удовольствие, этот путь сложно назвать оптимальным для начинающего. Если на плате паленый чип, и есть запасной (который не жалко пустить на эксперименты) - можно его заменить и надеяться на лучшее. Но менять практически всю обвязку целиком (т.е. и чип, и питание, и клоки) - может быть оправданно только в том случае, если вам жизненно необходима именно эта плата (например, есть ПО, которое работает только на ней и т.п.). В противном случае вы просто цепляетесь за кусок текстолита. Убитое на это время можно было бы потратить на изучение какого-нибудь редактора плат в попытке сделать свой собственный аналог, раз уж хочется освоить весь этот непростой процесс. Пользы будет в целом больше, да и удовлетворение от процесса выше. А уж от результата тем более :)

"Сняты пятаки" - это значит что под BGA чипом не было контактных площадок? Возможно, их потеряли при снятии чипа. Так бывает, особенно если недогреть и тянуть - пятаки аккуратно отрываются. С другой стороны, если перегреть - чип взрывается изнутри :) Радости бессвинцовых технологий... Ей-богу, проще было бы выбросить...

Если бы не это замечание, можно было бы много чего насоветовать, но скорее всего, все это было бы мимо. Наверное, плата битая? Например, проблемы (пульсации, шум) на питаниях MGT вполне могут привести к снижению качества линка при внешнем сохранении работоспособности.

Тут разве что сложно понять, почему отказались от решения на Ethernet. Из-за цены? При ответе "воткнули - все работает" у вопрошающего возникает ложное ощущение, что задача не стоит и выеденного яйца. Ничего ужасно сложного, конечно, нет. Но и потрудиться, чтобы все заработало, все равно придется. И не только плисоводу (вывести поток), но программисту и системщику тоже (конечно, все это может быть и один человек).

Просто вы часто пишете так, будто все тривиально и для решения задачи не потребовалось ничего делать. Отчего со стороны создается (частенько ложное) впечатление, что достаточно воткнуть кабель и все само заработает :) Примерно как в ответ на вопрос, как полететь в космос, сказать - "А какие проблемы? Сделали ракету из металла, летает нормально."

Я бы не сказал, что даже для современного железа это простенькая задачка. Проблема не столько в потоке, сколько в приеме большого числа пакетов, которые не могут быть больше нескольких килобайт (и то это уже jumbo). Один поток 10GE еще ладно, а вот 4 - не поверю что оно просто работает само собой. Тут потребуется объединение прерываний, раскидывание их на разные процессоры, привязка потоков к процессорам и, возможно, маппинг памяти с учетом NUMA. А вот что оно просто так без дополнительной настройки берет и работает с 4-я потоками 10GE пусть даже и джамбо фреймов - как-то не верится.