andrew_b 14 2 января, 2020 Опубликовано 2 января, 2020 · Жалоба 8 минут назад, dxp сказал: Это вместо (* mark_debug="true" *)? Я их использую вместе. Но в project mode. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 34 2 января, 2020 Опубликовано 2 января, 2020 · Жалоба Ещё бы знать, когда это добавлять. В подавляющем большинстве случаев mark_debug делает, что надо, и только иногда шина ломается. Причём, при очередной сборке может и не сломаться - тут результат по прихоти оптимизатора P&R. Или уж тогда для шин всегда это применять. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Strob 0 2 января, 2020 Опубликовано 2 января, 2020 · Жалоба On 1/1/2020 at 9:30 AM, dxp said: Вопрос не в том, как добавить скриптом сигналы в дебаг, а в том что вивада оптимизирует часть сигналов, несмотря на (* mark="true" *) - например, есть шина данных: Вы не попробовали вариант который я написал? Да? Он не отменяет оптимизацию. Он принудительно называет сигналы и объединяет их в шины так, как это было до оптимизации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 34 2 января, 2020 Опубликовано 2 января, 2020 · Жалоба Не очень понимаю, как write_debug_probe даже с ключом -force сможет добыть сигнал (чтобы объединить его в шину), которого, например, нету - оптимизатор его выкинул. И даже если не выкинул, а просто переименовал в какое-то внутреннее имя, которое вам заранее неизвестно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Strob 0 2 января, 2020 Опубликовано 2 января, 2020 (изменено) · Жалоба А, кажется понял... Проблема в оптимизации ДО создания дебаг ядра? Т.е. Именно при синтезе? Ну так атрибуты keep для сигналов и keep_hierarchy для модулей, если хочется сохранить порты модуля. Вроде ни разу не подводили. Просто подобная проблема есть уже после синтеза, когда разваливаются шины в дебаге. Изменено 2 января, 2020 пользователем Strob Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
attaboy 0 12 марта, 2021 Опубликовано 12 марта, 2021 · Жалоба On 4/28/2016 at 3:54 PM, RobFPGA said: Приветствую! Естественно валится - это-ж черновик width_of_probe - надо заменит число нужной Вам ширины probe partial_name_of nets - соответственно имя цепей Естественно ваяя сотни строк такой писанины скучно и с голоду можно помереть поэтому можно и нужно все это оформить в виде такого "комплексного_обеда.tcl" # первое... # create probe proc mk_probe {{ila u_ila_0} {mode DATA_AND_TRIGGER} {len 1}} { set probe_obj [create_debug_port $ila probe] set_property PROBE_TYPE $mode [get_debug_ports $probe_obj] set_property PORT_WIDTH $len [get_debug_ports $probe_obj] } # второе... # add sorted list of pins/nets to last probe port proc add2probe {ila net_obj} { set len [llength $net_obj] if {$len>0} { set net_obj [lsort -dictionary $net_obj] # mark a nets as debug for simple search and view in the schematic set_property mark_debug true $net_obj # get last probe port set probe_obj [lindex [get_debug_port $ila/probe*] end] # set probe_len [llength [get_nets -of [get_pins [get_debug_ports $probe_obj]]]] set probe_len [llength [string map {0 ""} [get_property is_connected [get_pins [get_debug_ports $probe_obj]]]]] # adjust probe width set_property PORT_WIDTH [expr $probe_len+$len] [get_debug_ports $probe_obj] # and connect new nets to end of probe port connect_debug_port $probe_obj $net_obj puts "Connecting $len nets" } } # компот... # get list of nets connected to Q output of register proc get_q_nets {name} { set net_obj [get_nets -of [get_pin -hier -filter "NAME =~ $name/Q"]] return $net_obj } # десерт... ... # вкусняшки... ... # приятного аппетита... # первая порция бесплатно от шеф-повара #mk_probe u_ila_0 - (probe_0 создается автоматом при создании Ila_* ) add2probe u_ila_0 [get_nets -hier -filter {NAME =~ i_pc720_sys/pcie_7x_0/pl_ltssm_state*}] add2probe u_ila_0 [get_nets -hier -filter {NAME =~ i_pc720_sys/pcie_7x_0/pl_phy_lnk_up}] # вторая и остальные порции за деньги mk_probe u_ila_0 add2probe u_ila_0 [get_nets -hier -filter {NAME =~ i_pc720_sys/*m_axis_rx_TUSER*}] add2probe u_ila_0 [get_nets -hier -filter {NAME =~ i_pc720_sys/*m_axis_rx_TLAST*}] add2probe u_ila_0 [get_nets -hier -filter {NAME =~ i_pc720_sys/*m_axis_rx_TVALID*}] add2probe u_ila_0 [get_nets -hier -filter {NAME =~ i_pc720_sys/*m_axis_rx_TREADY*}] # третья - выбираем только самое вкусное mk_probe u_ila_0 DATA add2probe u_ila_0 [get_nets -hier -filter {NAME =~ i_pc720_sys/*m_axis_rx_TDATA*}] #... оффициант ! повторите все для свежего топора ila_1 create_debug_core u_ila_1 ila .... Причем кушать все это можно как на бегу (в командном строке) так и сидя в зале (project_mode GUI) Успехов! Rob. Обнаружил такую вещь. Допустим, я хочу добавить в отладчик шину m_axis_rx_TDATA[31:0]. Если для добавления сигналов я использую строку типа: get_nets -hier -filter {NAME =~ i_pc720_sys/*m_axis_rx_TDATA*} то у меня добавится больше чем 32 сигнала. Все дело в том, что в нетлисте, кроме нужных m_axis_rx_TDATA[31:0] как правило содержатся технологические сигналы тип m_axis_rx_TDATA[0]_neg_0 и т.д. И все эти технологические сигналы удовлетворяют критериям фильтра. Если конечно же использовать вышеуказанную функцию add2probe, которая автоматически определяет размер проба, то отладчик соберется, но в нем будет много мусора - вместо нужных 32-х сигналов будет, скажем, 50-60. Поэтому думаю нужны более жесткие правила фильтрации. Например m_axis_rx_TDATA[*]. В этом случае технологические сигналы не будут удовлетворять условиям фильтра. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 13 марта, 2021 Опубликовано 13 марта, 2021 · Жалоба Приветствую! 15 hours ago, attaboy said: Обнаружил такую вещь. Допустим, я хочу добавить в отладчик шину m_axis_rx_TDATA[31:0]. Если для добавления сигналов я использую строку типа: get_nets -hier -filter {NAME =~ i_pc720_sys/*m_axis_rx_TDATA*} то у меня добавится больше чем 32 сигнала. Все дело в том, что в нетлисте, кроме нужных m_axis_rx_TDATA[31:0] как правило содержатся технологические сигналы тип m_axis_rx_TDATA[0]_neg_0 и т.д. И все эти технологические сигналы удовлетворяют критериям фильтра. Если конечно же использовать вышеуказанную функцию add2probe, которая автоматически определяет размер проба, то отладчик соберется, но в нем будет много мусора - вместо нужных 32-х сигналов будет, скажем, 50-60. Поэтому думаю нужны более жесткие правила фильтрации. Например m_axis_rx_TDATA[*]. В этом случае технологические сигналы не будут удовлетворять условиям фильтра. Это был всего лишь пример концепции для автоматизации имплементации ILA. Мой рабочий вариант фильтрации сигналов/пинов/портов немного сложнее (на пару экранов текста) Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
attaboy 0 13 марта, 2021 Опубликовано 13 марта, 2021 · Жалоба 1 hour ago, RobFPGA said: Приветствую! Это был всего лишь пример концепции для автоматизации имплементации ILA. Мой рабочий вариант фильтрации сигналов/пинов/портов немного сложнее (на пару экранов текста) Удачи! Rob. А можете поделиться рабочим вариантом. Концепция конечно же отличная, но на её "обработку напильником" может уйти достаточно много времени. В частности, кроме вышеуказанной проблемы, я обнаружил ещё одну. Если сигналы выбирать опять же при помощи команды: get_nets -hier -filter {NAME =~ i_pc720_sys/*m_axis_rx_TDATA*} то Вивадо шину собирает не по порядку, и в итоге в окне wave вместо одной шины [31:0] появляются несколько, например [10:0],[11:11],[19:12] и т.д. Работать с такой шиной невозможно. Одно из решений, которое я нашел на просторах интернета (но пока ещё не проверил на практике), использовать команду lsort -dictionary Сложно сказать, какие ещё подводные камни могут содержаться в концепции. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 13 марта, 2021 Опубликовано 13 марта, 2021 · Жалоба Приветствую! 14 minutes ago, attaboy said: А можете поделиться рабочим вариантом. Концепция конечно же отличная, но на её "обработку напильником" может уйти достаточно много времени. Увы, по определенными причинам готовым поделится не могу 17 minutes ago, attaboy said: Одно из решений, которое я нашел на просторах интернета (но пока ещё не проверил на практике), использовать команду Ну так и у меня тоже самое proc add2probe {ila net_obj} { set len [llength $net_obj] if {$len>0} { set net_obj [lsort -dictionary $net_obj] Но этот простой вариант пасует если шина "разорвана" после синтеза. Тут поможет только более сложный анализ с "восстановлением" последовательности шины. А для этого желательно иметь отдельные команды для шин типа add2probe_bus с продвинутым парсингом опций задания пути, имени и нужного диапазона на шине (даже не непрерывного). В общем лишь бы фантазии хватало. Но всегда стоит отдельный вопрос - а нужно ли такой избыточный сервис? Так как искусственное исправление таких ситуаций IMHO снижает информативность о текущем состоянии дизайна после синтеза. Ну а корректность отображения шин можно попытается исправить и на самом wave через virtual bus. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
attaboy 0 15 марта, 2021 Опубликовано 15 марта, 2021 · Жалоба Вот ещё один ньюанс. В принципе он очевиден, но вдруг кому-нибудь будет интересно. В документации на Вивадо говорится, что файлы с расширением *.xdc - это фактически tcl скрипты. Вот например выдержка из UG945: Quote XDCs are not just simple strings; they are Tcl commands that the Vivado Tcl interpreter sequentially reads and parses. "Все животные равны, но некоторые равнее". Почему-то интерпретатор tcl,обрабатывая файл *.xdc, не поддерживает некоторые команды. В частности, указанная в переписке выше команда lsort не поддерживается в файлах формата *.xdc. Поэтому для ограничений, задаваемых такими относительно сложными конструкциями, нужно использовать расширение tcl, а не xdc. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 15 марта, 2021 Опубликовано 15 марта, 2021 · Жалоба Приветствую! 3 minutes ago, attaboy said: Вот ещё один ньюанс. В принципе он очевиден, но вдруг кому-нибудь будет интересно. В документации на Вивадо говорится, что файлы с расширением *.xdc - это фактически tcl скрипты. Вот например выдержка из UG945: "Все животные равны, но некоторые равнее". Почему-то интерпретатор tcl,обрабатывая файл *.xdc, не поддерживает некоторые команды. В частности, указанная в переписке выше команда lsort не поддерживается в файлах формата *.xdc. Поэтому для ограничений, задаваемых такими относительно сложными конструкциями, нужно использовать расширение tcl, а не xdc. Некоторых "животных" можно приручить и на "цепь" посадить, а некоторых "сколько не корми ... они все норовят сами по себе гулять" .xdc файлы на цепи у Vivado, она за ними следит (в project mode) автоматом меняя их содержимое если вы меняете настройки через GUI. Отсюда и ограничение на возможные конструкции языка в .xdc. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
attaboy 0 15 марта, 2021 Опубликовано 15 марта, 2021 · Жалоба 2 minutes ago, RobFPGA said: Приветствую! Некоторых "животных" можно приручить и на "цепь" посадить, а некоторых "сколько не корми ... они все норовят сами по себе гулять" .xdc файлы на цепи у Vivado, она за ними следит (в project mode) автоматом меняя их содержимое если вы меняете настройки через GUI. Отсюда и ограничение на возможные конструкции языка в .xdc. Удачи! Rob. Ну ограничения прямо скажем специфические. Мне непонятно, почему в GUI так ущемляются права lsort. Если я добавлю регистр в отладчик через GUI, Setup Debug, то Vivado включит его командой типа: set_property port_width 4 [get_debug_ports u_ila_0/probe1] connect_debug_port u_ila_0/probe1 [get_nets [list {file/sig_1[0]} {file/sig_1[1]} {file/sig_1[2]} {file/sig_1[3]}]] Если размер регистра битов эдак 256, то получается очень длинная строка. Понятно, что в автоматическом режиме предполагается, что пользователь не заморачивается на чтение всяких там системно созданных файлов. Но к сожалению/счастью иногда их приходится читать, и в этом случае команда lsort могла бы сделать этот файл намного более читабельным. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 15 марта, 2021 Опубликовано 15 марта, 2021 · Жалоба Приветствую! 29 minutes ago, attaboy said: Ну ограничения прямо скажем специфические. Мне непонятно, почему в GUI так ущемляются права lsort. Если я добавлю регистр в отладчик через GUI, Setup Debug, то Vivado включит его командой типа: ... Если размер регистра битов эдак 256, то получается очень длинная строка. Понятно, что в автоматическом режиме предполагается, что пользователь не заморачивается на чтение всяких там системно созданных файлов. Но к сожалению/счастью иногда их приходится читать, и в этом случае команда lsort могла бы сделать этот файл намного более читабельным. Ну так именно по этой причине и не добавляет - внутри Vivado представление плоское как блин. Нет никаких абстракций типа циклов, паттерн-матчиннг, сортировок, ... и других заморочек "... этих мягкотелых неспособных запомнить десяток-другой тысяч сырых строк". А задача конвертации такого представления в удобочитаемую форму сложна и IMHO не есть первоочередной для Vivado. Да и не особо нужна как мне кажется. При возможности полноценного использования .tcl для констрейнов .xdc как таковой и не нужен (ну разве что для начального этапа). В моих проектах давно только один .xdc файл (да и тот обычно пустой) - это тот target куда GUI пишет новые констрейны если что то крутить в нем. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
attaboy 0 15 марта, 2021 Опубликовано 15 марта, 2021 · Жалоба 17 minutes ago, RobFPGA said: Приветствую! Ну так именно по этой причине и не добавляет - внутри Vivado представление плоское как блин. Нет никаких абстракций типа циклов, паттерн-матчиннг, сортировок, ... и других заморочек "... этих мягкотелых неспособных запомнить десяток-другой тысяч сырых строк". А задача конвертации такого представления в удобочитаемую форму сложна и IMHO не есть первоочередной для Vivado. Да и не особо нужна как мне кажется. При возможности полноценного использования .tcl для констрейнов .xdc как таковой и не нужен (ну разве что для начального этапа). В моих проектах давно только один .xdc файл (да и тот обычно пустой) - это тот target куда GUI пишет новые констрейны если что то крутить в нем. Удачи! Rob. Да уж, совсем плоское представление. Взять какие-нибудь конструкции типа: get_cells -hier -filter {NAME =~...} которые одной строкой могут перебрать пол примитивов дизайна. И это все разбирается в *.xdc. В целом я обратил внимание на факт использования команды lsort. Я бы не стал искать логику, почему это так, а не иначе. По-моему это факт из категории "Нужно знать", gotcha. А почему так - непонятно, так решили разработчики. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 15 марта, 2021 Опубликовано 15 марта, 2021 · Жалоба Приветствую! 4 minutes ago, attaboy said: Да уж, совсем плоское представление. Взять какие-нибудь конструкции типа: get_cells -hier -filter {NAME =~...} которые одной строкой могут перебрать пол примитивов дизайна. И это все разбирается в *.xdc. В целом я обратил внимание на факт использования команды lsort. Я бы не стал искать логику, почему это так, а не иначе. Ну так это и есть пример как сложная абстракция внешнего представления конвертируется внутри Vivado в плоский список строк. Вы просто перебираете все строки и сравниваете их со входным паттерном. А вот обратно - из списка строк сделать автоматом компактное абстрактное представление может быть очень сложно. 7 minutes ago, attaboy said: По-моему это факт из категории "Нужно знать", gotcha. А почему так - непонятно, так решили разработчики. Можно пользоваться и таким подходом но IMHO все же лучше понимать почему то или иное так сделано. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
