[Longiel 2]

Есть такая особенность в Vivado как подключение тактового сигнала для Debug Hub.

Например, у нас есть проект с одним кварцевым генератором и тремя внешними PLL, которые нужно программировать по SPI. Если у нас в проекте что-то не работает, то открывается отладчик, добавляются сигналы, для сигналов выбираются такты и всё такое. Потом синтезируем, разводим, подключаем, а Debug... не работает. Потому что Debug Hub Vivado затактировала от какого-то PLL, от которого, ясное дело, при старте тактов нет. Беда в том, что когда они появятся отладчик тоже работать будет, не будет - малопредсказуемо... Поэтому нужно лезть в файл XDC, найти там где подключаются такты к хабу и ручками переправить тактовый сигнал на сигнал от кварца. Потом опять синтез, разводка... и дальше уже всё работает. Через неделю в прошивке нужно отладить что-то другое - открываем отладчик, удаляем сигналы, добавляем сигналы, закрываем отладчик, разводим, прошиваем, окна Debug'a чего-то нет... вспоминаем о хабе... ведь после вмешательства вивада, зараза такая, могла опять по своему усмотрению его затактировать...

Причём проблема эта не нова, появилась с начала появления этой САПР и на форумах Xilinx даже не одна тема по этому поводу есть, но всё, что я читал когда-то сводилось к тому, что при изменениях в отладчике народ залазит в XDC и проверяет всё ли там в порядке с хабом.

Интересно как вы боретесь с этой особенностью? От тактов хаба вообще что-то зависит? Потому что складывается впечатление, что на них только какой-то интерфейс с ним завязан.

[andrew_b 14]

Создаёте IP core ILA  с нужным набором входов и вставдляете в код.

 

[1891ВМ12Я 0]

13 hours ago, Longiel said:

Интересно как вы боретесь с этой особенностью?

Можно попробовать систему контроля версий типа Mercurial или Git, при появлении изменения в файлах IP ядра или допустим в отладочном - просто отбрасываю изменения и оно снова становится модифицированным. Это костыль, но работает.

[RobFPGA 27]

Приветствую!

18 hours ago, Longiel said:

Поэтому нужно лезть в файл XDC, найти там где подключаются такты к хабу и ручками переправить тактовый сигнал на сигнал от кварца.

Ну так почему бы сразу  в XDC/TCL не назначать нужный клок для dbg_hub?  Не будет  зависеть от прихотей Vv. 

 

Удачи! Rob.     

[Longiel 2]

6 минут назад, RobFPGA сказал:

Ну так почему бы сразу  в XDC/TCL не назначать нужный клок для dbg_hub?

Так при манипуляциях с дебагом вивада самостоятельно может клок для хаба "перебить". Его можно как-то надёжно "прибить"?

[RobFPGA 27]

3 minutes ago, Longiel said:

Так при манипуляциях с дебагом вивада самостоятельно может клок для хаба "перебить". Его можно как-то надёжно "прибить"?

Ну так вы же  пишете что лазите ручками в XDC  для изменения клока - так почем сразу в этом XDC не прописать проверку  что клок тот что надо  и не править его автоматом если он изменился? 

[Longiel 2]

Предлагаете условие на TCL сочинить в качестве обёртки для кода подключения хаба?

connect_debug_port dbg_hub/clk [get_nets CLK40]

Идея интересная. Правда вивада весь XDC иногда перетряхивает, но попробовать можно)

[RobFPGA 27]

22 minutes ago, Longiel said:

Идея интересная. Правда вивада весь XDC иногда перетряхивает, но попробовать можно)

Ну так что мешает не давать Vv это делать, поместив этот код в unmanaged TCL подключенный последним в списке констрейнов. Или выполнять проверку (и правку если нужно) в скрипте tcl.pre на этапе  optimization.    

[Longiel 2]

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

помести этот код в unmanaged TCL подключенный последним в списке констрейнов

Вот я к этому и пришёл.

Просто может что я не понимаю до конца (да наверняка!) или не так делаю - решил поинтересоваться кто как с этим борется )

[attaboy 0]

1 hour ago, Longiel said:

Вот я к этому и пришёл.

Просто может что я не понимаю до конца (да наверняка!) или не так делаю - решил поинтересоваться кто как с этим борется )

Вообще самый надежный способ - изначально задавать все отладчики в скриптах. При некоторой сноровке это даже быстрее, чем через GUI. И не нужно каждый раз открывать отладчик, что-то удалять, добавлять, потом выяснять, что GUI Vivado все понял не так. Со скриптами все проще - подключил нужный список сигналов, пересобрал проект, и готово. Плюс появляется более глубокое понимание структуры проекта, что тоже важно для проектов сложнее "моргателя светодиодов".

[Longiel 2]

Я поначалу пытался подключать сигналы прямо в XDC. Но у меня как-то всё не задалось, получалось всё дико монструозно, затянулось и я в конце концов сдался.

1 час назад, attaboy сказал:

Вообще самый надежный способ - изначально задавать все отладчики в скриптах.

Но тогда придётся в исходники залазить и маркировать сигналы для отладки?

[attaboy 0]

Да. Но это бывает необходимо и при использовании GUI. (*mark_debug="true"*) - насущная директива отладки, независимо от используемого метода.

Но ведь отладка в принципе предполагает изучение исходников и поиск потенциально проблемных мест. Можно конечно добавить в отладчик максимум сигналов в надежде на то, что там будет нужный, но этот метод работает только при околонулевой загрузке ПЛИС.

[_4afc_ 25]

У меня просто сделан Debug.v в котором внутренние регистры (*mark_debug="true"*)  и клок через BUFGCE

Ставлю его в топе или отлаживаемом модуле. Естественно все данные должны быть под этим клоком.

Проблем с пересбором или запуском pll - нет.

[Longiel 2]

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

Но ведь отладка в принципе предполагает изучение исходников и поиск потенциально проблемных мест.

Просто при вытаскивании сигналов через отладчик синтезировать проект заново не потребуется. А если трогаешь исходники - попадаешь на синтез. Синтез обычно идёт меньше разводки и размещения, но... на крупных проектах терять по 40-50 минут тоже не хочется.

 

Я просто понять пытаюсь как это у вас выглядит. Настроечные данные для скриптов это: название сигнала, путь к модулю, путь к дебагу... наверное этого достаточно?

3 минуты назад, _4afc_ сказал:

У меня просто сделан Debug.v в котором внутренние регистры (*mark_debug="true"*)  и клок через BUFGCE

Ставлю его в топе или отлаживаемом модуле. Естественно все данные должны быть под этим клоком.

Если разрядность входного порта в Debug.v параметризировать, то получится удобно подключать. А внутри что - всё по ИЛИ в дебаг пин?

В сам отладчик какие сигналы подключаете - внутренние регистры в Debug.v? Минус правда сразу вылазит - потом сигналы надо переименовать в отладчике, если их много, конечно.

Изменено 29 ноября, 2021 пользователем Longiel

[RobFPGA 27]

2 hours ago, Longiel said:

просто понять пытаюсь как это у вас выглядит. Настроечные данные для скриптов это: название сигнала, путь к модулю, путь к дебагу... наверное этого достаточно?

Я когда то приводил тут на форме свой подход подключения debug через  скрипты.  При подключении после синтеза  есть проблема переименования сигналов или их отсутствие в результате оптимизаций при синтезе.  Поэтому атрибут MARK_DEBUG на ключевых сигналах в исходниках позволяет сохранить их в целости. Но к этому атрибуту (да и к любым другим)  можно вешать свои добавки.

Например  (* MARK_DEBUG = `GOBAL_DBG, MYDBG_GROUP = "name" *) Это  позволяет быстро не меняя исходники включать/выключать дебаг, а в с скрипте  легко находить нужные сигналы фильтруя их про признаку MYDBG_GROUP .
Кстати в том же скрипте  после подключения всех требуемых сигналов для текущего дебага  можно отменить все остальные  MARK_DEBUG  чтобы при P&R  было больше оптимизаций.  Естественно это если вы в последствии не планирует ускорять дебаг за счет использования ECO режима для быстрого P&R при изменении набора сигналов.