[khach 38]

3 часа назад, makc сказал:

На отдельный вход ПЛИС

Т.е перезагрузки прошивки ПЛИС при резете по кнопке не происходит? И ПЛИС остается в неизвестном состоянии вызванном конвульсиями на шине после нажатия кнопки резета?

[makc 210]

4 минуты назад, khach сказал:

Т.е перезагрузки прошивки ПЛИС при резете по кнопке не происходит?

Не происходит реконфигурации. ПЛИС конфигурируется один раз при включении питания системы.

4 минуты назад, khach сказал:

И ПЛИС остается в неизвестном состоянии вызванном конвульсиями на шине после нажатия кнопки резета?

Вы, возможно, пропустили то, что я писал выше. Повторюсь, логика ПЛИС ресетится штатным образом по сигналу PERST# с шины. Более того, на сбоящей плате так себя ведёт не только кастомная прошивка ПЛИС, но и заново сгенерированный Example Design, который демонстрирует все те же эффекты отсутствия линка сразу после перезагрузки по кнопке. В других слотах, подключенных к PCH, и на десятке других разных мат.плат с ресетом проблем почему-то нет. Следовательно в прошивке ПЛИС он обрабатывается корректно и инициализирует логику ПЛИС после перезагрузки.

[khach 38]

2 минуты назад, makc сказал:

Повторюсь, логика ПЛИС ресетится штатным образом по сигналу PERST# с шины.

А сравнить вычиткой, резетится в то же состоянии что и при первой загрузке конфигурации или есть отличия? Особенно вопросы с PLL возникают, при резете фазы клока дергаются иногда непредсказуемо, как на это реагирует приемник PCI-E

[makc 210]

1 минуту назад, khach сказал:

А сравнить вычиткой, резетится в то же состоянии что и при первой загрузке конфигурации или есть отличия?

Вычиткой чего? Что именно нужно искать? Состояние ядра PCI-E прочитать и сравнить я не могу, есть только внешние проявления в форме состояния LTSSM и т.п.

5 минут назад, khach сказал:

Особенно вопросы с PLL возникают, при резете фазы клока дергаются иногда непредсказуемо, как на это реагирует приемник PCI-E

После ресета PLL работает, locked есть и главное LTSSM начинает менять состояние вполне ожидаемым образом, только до L0 в итоге не доходит.

[khach 38]

А резет то какой? Альтера три типа сброса описывает у себя в доках по PCI-e. Это из Stratix V Hard IP for PCI Express древняя, но кое что там описано по поводу процедуры запуска клока после резетов.

The PCI Express Base Specification 2.1, requires the following three reset types:
■ Cold reset—A hardware mechanism for resetting following power on. The npor
initiates this reset.
■ Warm reset—A hardware mechanism for resetting without cycling the power
supply.
■ Hot reset—A reset propagated across a Link using a Physical Layer mechanism.

Ну и сигналы, которые эти резеты вызывают как дергать. У хилых конечно все по другому, но может что из альтернативных доков поможет.

Насколько я понял, до всего что можно посмотреть софтом как например тут https://pcisig.com/sites/default/files/files/02_01_Troubleshooting_PCI_Express_Link_Training_and_Protocol_Issues_FROZEN.pdf

процесс запуска не доходит.

[Flood 13]

14 hours ago, makc said:

На отдельный вход ПЛИС. На PROG его заводить нельзя, т.к. к моменту окончания ресета ПЛИС должна быть готова к работе через PCI-E. Поскольку ПЛИС конфигурируется в режиме четырехпроводного SPI на довольно высокой частоте, то всё должна успевать с запасом (судя по расчетам и даже с учётом погрешности внутреннего генератора в 50% по частоте). Но осциллографом я это на проблемной плате не проверял, в понедельник проверю.

Мне кажется, первая часть утверждения противоречит второй. Если на PROG этот сброс не заведен, то и контролировать скорость загрузки ни к чему (если бы она была причиной проблем, не работало бы наоборот, в первый раз после подачи питания).

Но, в вашей ситуации я бы в первую очередь исключил все возможные ресет-ассоциированные причины, для чего нужно временно подать PERST# на PROG (а как вариант - еще и на INIT, через схему с OD-выходом).

Для интереса, на исправной плате можно будет убедиться, мешает ли подача PERST# на PROG обнаружению платы в вашей конкретной системе. По опыту могу сказать, что не знаю ни одного примера, когда бы это не работало (правда, у меня вообще нет опыта с Артиксами).

[makc 210]

9 часов назад, khach сказал:

А резет то какой?

Cold и Warm. После Cold работают все платы, после Warm одна из пяти плат не работает. Hot Reset платами игнорируется.

9 часов назад, khach сказал:

Альтера три типа сброса описывает у себя в доках по PCI-e.

Логично, ведь они первоначально описаны в спецификации на PCI-E. Так что в этом нет ничего нового.

9 часов назад, khach сказал:

Ну и сигналы, которые эти резеты вызывают как дергать. У хилых конечно все по другому, но может что из альтернативных доков поможет.

Всё у них также, во время Cold и Warm с шины приходит сигнал PERST#. Hot Reset сигнализируется служебным сообщением по шине. PERST# обрабатывается.

9 часов назад, khach сказал:

Насколько я понял, до всего что можно посмотреть софтом как например тут https://pcisig.com/sites/default/files/files/02_01_Troubleshooting_PCI_Express_Link_Training_and_Protocol_Issues_FROZEN.pdf

процесс запуска не доходит.

Да, а анализатора трафика PCI-E у меня нет.

11 минут назад, Flood сказал:

Мне кажется, первая часть утверждения противоречит второй. Если на PROG этот сброс не заведен, то и контролировать скорость загрузки ни к чему (если бы она была причиной проблем, не работало бы наоборот, в первый раз после подачи питания).

Не вижу никакого противоречия. ПЛИС должна быть готова к работе до окончания активного уровня на сигнале сброса PERST#, чтобы увидеть его, сбросить все узлы и запуститься синхронно с RC.

14 минут назад, Flood сказал:

Но, в вашей ситуации я бы в первую очередь исключил все возможные ресет-ассоциированные причины, для чего нужно временно подать PERST# на PROG (а как вариант - еще и на INIT, через схему с OD-выходом).

Зачем? Особенно в виду вышеописанного мною требования готовности ПЛИС к запуску. Это, кстати, описано в документации на применение ядра PCI-E от Xilinx.

16 минут назад, Flood сказал:

Для интереса, на исправной плате можно будет убедиться, мешает ли подача PERST# на PROG обнаружению платы в вашей конкретной системе. По опыту могу сказать, что не знаю ни одного примера, когда бы это не работало (правда, у меня вообще нет опыта с Артиксами).

На основании чего вы подключали PERST# к PROG? Я таких рекомендаций от Xilinx не помню и это с моей точки зрения противоречит логике запуска устройства, описанной в стандарте PCI-E.

[Flood 13]

43 minutes ago, makc said:

На основании чего вы подключали PERST# к PROG? Я таких рекомендаций от Xilinx не помню и это с моей точки зрения противоречит логике запуска устройства, описанной в стандарте PCI-E.

Семь бед - один ресет. Подключение PERST# на PROG снимает подавляющее число связанных со сбросом вопросов. И это первое, что стоит попробовать. Хотя бы в отладочных целях. Если PROG - edge sensitive и не держит сброс по низкому уровню (зависит от поколения чипов, не помню как там в 7 серии с этим), но еще и INIT-ом можно придержать (иногда надо, иногда нет).

Логике может и противоречит, но работает даже на огромных кристаллах без включения Tandem Config. Важное замечание - работает, но не обязано.

Одновременно с плюсами глобального сброса, происходит нарушение специфицированных времен готовности после снятия сброса и снижение квалификации HDL-разработчика - т.к. размышления о сбросах в проекте становятся во многом вырожденными и откладываются в долгий ящик.

Условно, становится невозможно проверить, правильно ли реализован сброс - ведь всегда все работает 🙂

[makc 210]

10 минут назад, Flood сказал:

Семь без - один ресет. Подключение PERST# на PROG снимает подавляющее число связанных с сбросом вопросов. И это первое, что стоит попробовать. Хотя бы в отладочных целях.

Это нарушает требования спецификации. 🤔 В чём состоит ваша гипотеза? Что должен проверить этот эксперимент и как вы предлагаете интерпретировать его результаты?

Я пробовал принудительно вручную подавать ресет на плату в момент включения и отпускать его уже после запуска - это ничего не изменило и после очередного ресета плата исчезает (не поднимается линк).

12 минут назад, Flood сказал:

Логике может и противоречит, но работает даже на огромных кристаллах без включения Tandem Config.

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

15 минут назад, Flood сказал:

Условно, становится невозможно проверить, правильно ли реализован сброс - ведь всегда все работает 🙂

Сброс реализован правильно, согласно описаниям от Xilinx и спецификации PCI-E. Иначе бы все платы вели себя одинаково.

[Flood 13]

37 minutes ago, makc said:

Сброс реализован правильно, согласно описаниям от Xilinx и спецификации PCI-E. Иначе бы все платы вели себя одинаково.

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

[makc 210]

2 минуты назад, Flood сказал:

все дело в конкретной микросхеме непонятного происхождения и спидгрейда, например.

С учётом пиленной маркировки такая вероятность есть, но с другой стороны это была одна партия, микросхемы были новые (не реболл) и она же работает везде, кроме проблемных MSI. Поэтому есть надежда, что это излечимо.

[dxp 53]

Пару слов про требование готовности PCI устройство. Согласно спеке ATX устройство должно быть готово к работе (енумерации аппаратурой хоста) не позднее 100 мс. Это довольно малое время, учитывая сложность современных устройств. В начале работы с PCIe сильно парился по этому поводу, потому что тот же Artix 200 при всём желании не успевал загрузиться за 100 мс чисто физически на максимальной скорости при внешнем тактировании (там что-то порядка 130 мс уходило). 

Но потом выяснилось, что требование-то это никто не отменял, но реально оно давно не соответствует необходимости. Оно возникло во времена 386 РС, когда PCI внедрялся в эту платформу, тогда процы были маленькими, системные платы относительно простыми, объёмы памяти смешными (по нынешним временам), там процессорная система через 100 мс уже была готова чекать конфигурацию периферийных устройств. 

Современный РС при подаче питания занимается самодиагностикой (и прочим) несколько секунд! Это настольный. Замерял на серверной платформе (какой-то Xeon, не самый современный), там вообще 29 секунд он находился где-то внутри себя и только после этого только появлялся BIOS screen. 

Наверное инициировать загрузку по окончании PERST# идеологически неверно (а правильно было бы формировать сигнал конфигурирования из него внутри платы), но учитывая тайминг готовности современных CPU, я бы не опасался, что Artix 25 не успеет загрузиться до начала енумерации.

[makc 210]

1 минуту назад, dxp сказал:

Современный РС при подаче питания занимается самодиагностикой (и прочим) несколько секунд! Это настольный. Замерял на серверной платформе (какой-то Xeon, не самый современный), там вообще 29 секунд он находился где-то внутри себя и только после этого только появлялся BIOS screen. 

Серверные платформы - случай особый, т.к. во-первых у них запуском платы обычно занимается BMC, а во-вторых слоты расширения обычно сидят на далёких от процессора шинах, которые запускаются с очень большой задержкой (как в вашем примере). У меня десктопная плата и шина непосредственно подключена к процессору, поэтому есть далеко ненулевая вероятность, что там может быть всё существенно быстрее. Более того, я сталкивался с мат.платами, на которых ресет "дребезжит", т.е. вместо одного длинного импульса там может быть множество коротких и один длинный или наоборот. 

5 минут назад, dxp сказал:

Наверное инициировать загрузку по окончании PERST# идеологически неверно (а правильно было бы формировать сигнал конфигурирования из него внутри платы), но учитывая тайминг готовности современных CPU, я бы не опасался, что Artix 25 не успеет загрузиться до начала енумерации.

Вероятность такой проблемы мала, но нужно проверить и её. Обжегшись на молоке, начинаем дуть на воду.

[dxp 53]

5 минут назад, makc сказал:

Серверные платформы - случай особый, т.к. во-первых у них запуском платы обычно занимается BMC, а во-вторых слоты расширения обычно сидят на далёких от процессора шинах, которые запускаются с очень большой задержкой (как в вашем примере). У меня десктопная плата и шина непосредственно подключена к процессору, поэтому есть далеко ненулевая вероятность, что там может быть всё существенно быстрее.

Не-не, на том сервере 5 PCIe Gen3 x8 торчало непосредственно из CPU (4 выходили слотами в сторону морды (19" стоечное исполнение) -- для подключения NIC, 1 по райзер плату, туда накопители цеплялись). Т.е. PCIe линки были непосредственно подключены к CPU.

29 секунд он думал до выдачи BIOS screen. Это точно до начала опроса внешних периферийных устройств. 

[makc 210]

1 минуту назад, dxp сказал:

Не-не, на том сервере 5 PCIe Gen3 x8 торчало непосредственно из CPU (4 выходили слотами в сторону морды (19" стоечное исполнение) -- для подключения NIC, 1 по райзер плату, туда накопители цеплялись). Т.е. PCIe линки были непосредственно подключены к CPU.

Значит BMC был очень задумчив. На MSIке, судя по схеме, PERST# идёт от хаба (PCH) на порт процессора и на слот. Т.е. теоретически задержка тоже может быть большой, но на глаз её не видно - явно меньше секунды.