Nick_K 0 9 сентября, 2019 Опубликовано 9 сентября, 2019 · Жалоба 1 hour ago, Vengin said: Я так понимаю, предлагается вместо формулы вставить константу, равную рассчитанному значению: Абсолютно нет! Я говорю что эту расчитанную константу не нужно запихивать в Генерик/Параметр. Используйте константу напрямую везде где она необходима. Не нужно лишнего переприсвоения. Параметризация будет сама разбросана. 1 hour ago, Vengin said: 1) Можно или нельзя напрямую из HDL кода подтягивать параметры, если в рассчётах параметров используются только стандарные библиотечные мат функции типа log2? Да можно. Вопрос как вы это сделаете. Криво через 4 вложения или напрямую используете константу 1 hour ago, Vengin said: А в какой Vivado это? Я пытаюсь на 2017.4. Может в версиях постарше постепенно решают проблемы.. В самой свежей. 17-тая может и не тянет. В 19 всё ок Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Vengin 0 9 сентября, 2019 Опубликовано 9 сентября, 2019 · Жалоба 32 минуты назад, RobFPGA сказал: Приветствую! Никто и не пытается флудить - но простую (для вас) проблему надо еще и понять. Из того что я понял - XPATH это некий стандарт описания констант и мат функций при применении которых в HDL паковка последних в IP будет сопровождаться автоматический парсингом. То есть вам в HDL надо переделать математику чтобы она использовала только такие функции. Например такой вариант вашего примера распознается и вычисляется правильно (для шины di) entity tst_xpath is generic ( DATA_WIDTH : natural := 64; ADDR_WIDTH : natural := 32 -- ceiling(log(2,DATA_WIDTH)) ); port( clk : in std_logic; addr : in std_logic_vector(ADDR_WIDTH-1 downto 0); di : in std_logic_vector(ceiling(log(2,DATA_WIDTH))-1 downto 0); do : out std_logic_vector(DATA_WIDTH-1 downto 0) ); end tst_xpath; Но не все так радужно - для GENERIC это почему-то не работает :( Удачи! Rob. О, а я пробовал с GENERIC - не клеилось, на портах и не проверял. Как и упоминалось на форумах Xilinx какой-то очень сырой и своеобразный этот парсер IP Packager. Да и не совсем понятно, что этот подход (использование XPATH функций) даёт? Допустим IP Packager не ругается на модифицированный HDL (с использованием XPATH функции вместо стандартный). Но ведь при этом сам HDL код уже не скомпилишь для симуляции/синтеза. В чём тогда смысл? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 35 9 сентября, 2019 Опубликовано 9 сентября, 2019 · Жалоба Приветствую! 1 minute ago, Vengin said: Да и не совсем понятно, что этот подход (использование XPATH функций) даёт? Допустим IP Packager не ругается на модифицированный HDL (с использованием XPATH функции вместо стандартный). Но ведь при этом сам HDL код уже не скомпилишь для симуляции/синтеза. В чём тогда смысл? Смысл в стандартизации (надо же прогресс как то двигать) - типа пишем HDL единообразно и не паримся с паковкой в различных IP пакерах. Ну а для того чтобы скомпилировалось в симуляции/синтезе напишем еще одну стандартную библиотеку или package. Ни кто ведь вам не мешает сделать XPATH врапперы над обычными функциями ieee math. Но одно ясно - без мозолистых рук вам не обойтись Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 9 сентября, 2019 Опубликовано 9 сентября, 2019 · Жалоба Я наверное сам виноват, что не показал на примере, но вот написано то же самое: 2 hours ago, Nick_K said: А зачем Вам эта вся головная боль? Наличие генерика DATA_WIDTH обосновано полностью, но параметр ADDR_WIDTH - это чисто внутренняя структура. поменяйте в портах ADDR_WIDTH на natural(ceil(log2(real( DATA_WIDTH )))) а в коде сделайте константу ADDR_WIDTH_С а пользуйтесь ею. И не будет проблем и мороки. Иначе ADDR_WIDTH можно нечаянно поменять в топе (особенно в IP коре, особенно нерадивому юзеру) и будут потом проблемы ADDR_WIDTH убрать и в порт прописать natural(ceil(log2(real( DATA_WIDTH )))) далее по модулю объявить constant ADDR_WIDTH_C: natural := (ceil(log2(real( DATA_WIDTH )))); и пользоваться ею... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Vengin 0 9 сентября, 2019 Опубликовано 9 сентября, 2019 · Жалоба 55 минут назад, Nick_K сказал: Я наверное сам виноват, что не показал на примере, но вот написано то же самое: ADDR_WIDTH убрать и в порт прописать natural(ceil(log2(real( DATA_WIDTH )))) далее по модулю объявить constant ADDR_WIDTH_C: natural := (ceil(log2(real( DATA_WIDTH )))); и пользоваться ею... Подход понятен. Но проблемы это не решает (по крайней мере в VHDL). Если даже убрать параметр Generic ADDR_WIDTH и в явном виде прописать ширину порта: addr : in std_logic_vector(natural(ceil(log2(real( DATA_WIDTH ))))-1 downto 0); Получаем ошибку: [IP_Flow 19-627] Port 'addr': XPath expression failed: Unsupported function call or array usage "real" found in expression "(natural(ceil(log2(real(spirit:decode(id('MODELPARAM_VALUE.DATA_WIDTH')))))) - 1)". Кстати попробовал в Vivado 2019.1 - те же ошибки. А ещё попробовал Verilog код, и там тоже не всё так гладко: module top # ( parameter DW = 32, parameter AW = $clog2(DW) ) ( input clk, input [AW-1:0] addr1, input [$clog2(DW)-1:0] addr2, input [DW-1:0] din, output [DW-1:0] dout ); endmodule IP Packager выдаёт warnings: [IP_Flow 19-5101] Packaging a component with a SystemVerilog top file is not fully supported. Please refer to UG1118 'Creating and Packaging Custom IP'. [IP_Flow 19-329] [HDL Parser] Unable to determine the value format for HDL parameter 'AW' with value 'spirit:log(2,DW)'. The parameter type is not supported in this release. [IP_Flow 19-533] HDL Parameter 'AW (Aw)': Missing data type Не нравится именно parameter AW = $clog2(DW). В итоге получается модуль, у когорого шина addr1[0:0], addr2[4:0]: Наверное чем иметь такой ненужный геморрой с этим IP Packager лучше в Block Design выпихнуть наружу порты, которые нужно подключать к корке и склеивать это всё уже в HDL. Бррр... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 9 сентября, 2019 Опубликовано 9 сентября, 2019 · Жалоба 37 minutes ago, Vengin said: В итоге получается модуль, у когорого шина addr1[0:0], addr2[4:0]: А скиньте ещё скрины "Customization Parameters" и "Ports and Intefaces" из приведённого примера, пожалуйста. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 35 9 сентября, 2019 Опубликовано 9 сентября, 2019 · Жалоба Приветствую! 41 minutes ago, Vengin said: Не нравится именно parameter AW = $clog2(DW). В итоге получается модуль, у когорого шина addr1[0:0], addr2[4:0]: Ну все предсказуемо Гы, немного поэкспериментировал - на строке ... input [log(2, DATA_WH)-1:0] addr2, ... пакер в 19.1 уходит бесконечную медитацию бросив перед этим в лог ворчливое WARNING: [IP_Flow 19-5150] The Range '(log(2DATA_WH) - 1):0' is present ... Прикольно парсер работает не уж то региональные настройки (. ,) могут влиять на это? Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Vengin 0 9 сентября, 2019 Опубликовано 9 сентября, 2019 · Жалоба 1 час назад, Nick_K сказал: А скиньте ещё скрины "Customization Parameters" и "Ports and Intefaces" из приведённого примера, пожалуйста. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 35 9 сентября, 2019 Опубликовано 9 сентября, 2019 · Жалоба Приветствую! Если хотите чтобы в V/SV правильно парсило функции для parameter не забывайте добавлять тип параметра module tst_xpath2 #( parameter integer ADDR_WH = 32 , parameter integer DATA_WH = $clog2(ADDR_WH), parameter string NAME = "some_name" ... А иначе пакер автоматом тип string лепит Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 9 сентября, 2019 Опубликовано 9 сентября, 2019 · Жалоба 34 minutes ago, Vengin said: Я даже ради спортивного интереса у себя сделал проект - всё работает. Скиньте свой, будем поглядеть. P.S. Всмысле свой проект-пример. Не основной Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Vengin 0 10 сентября, 2019 Опубликовано 10 сентября, 2019 · Жалоба 16 часов назад, Nick_K сказал: Я даже ради спортивного интереса у себя сделал проект - всё работает. Скиньте свой, будем поглядеть. P.S. Всмысле свой проект-пример. Не основной Вот tst_ip_packager.xpr.zip Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 10 сентября, 2019 Опубликовано 10 сентября, 2019 · Жалоба 56 minutes ago, Vengin said: Вот tst_ip_packager.xpr.zip Во-первых это не проект, во-вторых это не тот проект (пример со скриншотов). Но я взял один ваш файл и сделал с него компонент. Всё работает и никаких глюков. p.s. Создайте проект просто запустив build.tcl с папки в среде Вивадо sv_prj_wb_intercon.zip Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Vengin 0 12 сентября, 2019 Опубликовано 12 сентября, 2019 · Жалоба В 09.09.2019 в 16:40, RobFPGA сказал: Приветствую! Если хотите чтобы в V/SV правильно парсило функции для parameter не забывайте добавлять тип параметра module tst_xpath2 #( parameter integer ADDR_WH = 32 , parameter integer DATA_WH = $clog2(ADDR_WH), parameter string NAME = "some_name" ... А иначе пакер автоматом тип string лепит Удачи! Rob. Действительно, после того как добавил тип параметра integer, warning-и исчезли и компонент лепистся нормально. Эх, жаль что всё уже на VHDL написано... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
cbiker 0 19 августа Опубликовано 19 августа · Жалоба хотел назадавать здесь много вопросов по интегратору и system verilog interface Но каждый раз чуть-чуть изменяя код, поведения интегратора очень сильно изменялось. Так что совет почаще переоткрывать проект компонента - визарды иногда заедает и например параметры и порты не распознавались. В итоге я нашёл ответ на свой вопрос. Может быть у кого-то есть опыт и более правильный вариант. Задача как делать IP component интегратором на SV интерфейсах главная проблема в том что интегратор генерирует исходник по IP компоненту и в назначениях портов SV интерфейса пишет не объявленные имена а имена из внутреннего интерфейса vivadы то есть для axis интерфейса внутреннего интерфейса vivadы - это например TVALID большими буквами Несмотря на то что SV интерфейс объявлен с маленькими буквами. для ip-интегратора - это одна и та же сущность что имя порта в SV интерфейсе что имя порта в системном интерфейсе vivado. Хотя например для обыкновенного verilog порта имя может быть любым Главное чтобы на конце был _tvalid любого регистра что большой что маленький портамии варианты решения тут два 1 Первое - это использовать заглавные буквы для локально объявленного SV интерфейса но неудобно тогда писать свой модуль постоянно используя заглавные буквы и вообще Это плохой стиль заглавные буквы используются для параметров или локальных параметров 2 или поковырявшись в xml описании вручную изменив имена axis интерфейса на нижний регистр( <spirit:busInterface> <spirit:name>rx_0</spirit:name> <spirit:busType spirit:vendor="xilinx.com" spirit:library="interface" spirit:name="axis" spirit:version="1.0"/> <spirit:abstractionType spirit:vendor="xilinx.com" spirit:library="interface" spirit:name="axis_rtl" spirit:version="1.0"/> <spirit:slave/> <spirit:portMaps> <spirit:portMap> <spirit:logicalPort> <spirit:name>p_tvalid</spirit:name> </spirit:logicalPort> <spirit:physicalPort> <spirit:name>rx_0_p_tvalid</spirit:name> </spirit:physicalPort> </spirit:portMap> <spirit:portMap> <spirit:logicalPort> <spirit:name>p_tready</spirit:name> </spirit:logicalPort> <spirit:physicalPort> <spirit:name>rx_0_p_tready</spirit:name> </spirit:physicalPort> </spirit:portMap> <spirit:portMap> <spirit:logicalPort> <spirit:name>p_tlast</spirit:name> </spirit:logicalPort> <spirit:physicalPort> <spirit:name>rx_0_p_tlast</spirit:name> </spirit:physicalPort> </spirit:portMap> <spirit:portMap> <spirit:logicalPort> <spirit:name>p_tdata</spirit:name> </spirit:logicalPort> <spirit:physicalPort> <spirit:name>rx_0_p_tdata</spirit:name> </spirit:physicalPort> </spirit:portMap> <spirit:portMap> <spirit:logicalPort> <spirit:name>p_tkeep</spirit:name> </spirit:logicalPort> <spirit:physicalPort> <spirit:name>rx_0_p_tkeep</spirit:name> </spirit:physicalPort> </spirit:portMap> </spirit:portMaps> <spirit:parameters> <spirit:parameter> <spirit:name>SV_INTERFACE</spirit:name> <spirit:value spirit:format="bool" spirit:id="BUSIFPARAM_VALUE.RX_0.SV_INTERFACE">true</spirit:value> </spirit:parameter> <spirit:parameter> <spirit:name>SV_INTERFACE_PARAMETERS</spirit:name> <spirit:value spirit:id="BUSIFPARAM_VALUE.RX_0.SV_INTERFACE_PARAMETERS">C_RX_0_DATA_BYTES</spirit:value> </spirit:parameter> </spirit:parameters> <spirit:vendorExtensions> <xilinx:busInterfaceInfo> <xilinx:enablement> <xilinx:isEnabled xilinx:resolve="dependent" xilinx:id="BUSIF_ENABLEMENT.rx_0">true</xilinx:isEnabled> </xilinx:enablement> </xilinx:busInterfaceInfo> </spirit:vendorExtensions> </spirit:busInterface> ) можно добиться того что компонент будет вставляться и собираться модуль правильно Единственный минус отсутствие всяких проверок на параметры шины Фчшы Ивановской шины и когда и при валидации блок дизайна будет цфктштп о том что ширина шины нулевая но при этом ширина порта дата правильная и при сборке ошибок нет И Все таки пару вопросов осталась 1. кто нибудь знает как просто сделать чтоб ширина шины пробрасывалась от мастера к слейву( если мы слейв)? осмотрел как у стандартных компонентов это реализовано - черт ногу сломит в их tcl файлах. 2.Как правильно сделать порт отключаемым для sv интерфейса - а то интегратор в bd что шину что порты не показывает, но генерирует исходник в котором есть назначения на этот sv interface но назначает несуществующий wire(когда порт включен это вход или выход). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
cbiker 0 19 августа Опубликовано 19 августа (изменено) · Жалоба Vivado v2021.2.1 (64-bit) SW Build: 3414424 on Sun Dec 19 10:57:14 MST 2021 IP Build: 3405791 on Sun Dec 19 15:54:35 MST 2021 нашел еще одно решение если обьявление интерфейса вивады изменить /Xilinx/Vivado/2021.2/data/ip/interfaces/axis_v1_0/axis_rtl.xml на lower case. то как раз таки и получается на выходе из ip packager xml компонента с нижним регистром и генерируется исходник для проекта с sv интерфейсами в нижнем регистре (* X_INTERFACE_INFO = "xilinx.com:interface:axis:1.0 tx_7 tvalid" *) output wire tx_7_tvalid; (* X_INTERFACE_INFO = "xilinx.com:interface:axis:1.0 tx_7 tready" *) input wire tx_7_tready; (* X_INTERFACE_INFO = "xilinx.com:interface:axis:1.0 tx_7 tlast" *) output wire tx_7_tlast; (* X_INTERFACE_INFO = "xilinx.com:interface:axis:1.0 tx_7 tdata" *) output wire [127 : 0] tx_7_tdata; (* X_INTERFACE_PARAMETER = "XIL_INTERFACENAME tx_7, SV_INTERFACE true, SV_INTERFACE_PARAMETERS C_TX_7_DATA_BYTES, TDATA_NUM_BYTES 16, TDEST_WIDTH 0, TID_WIDTH 0, TUSER_WIDTH 0, HAS_TREADY 1, HAS_TSTRB 0, HAS_TKEEP 1, HAS_TLAST 1, FREQ_HZ 100000000, PHASE 0.0, CLK_DOMAIN design_1_clk_0, LAYERED_METADATA undef, INSERT_VIP 0" *) (* X_INTERFACE_INFO = "xilinx.com:interface:axis:1.0 tx_7 tkeep" *) output wire [15 : 0] tx_7_tkeep; axis #(16) rx_0(); assign rx_0.tvalid = rx_0_tvalid; assign rx_0_tready = rx_0.tready; assign rx_0.tlast = rx_0_tlast; assign rx_0.tdata = rx_0_tdata; assign rx_0.tkeep = rx_0_tkeep; и все это собирается и не мешает стандарным компонентам, у них на выходе получается (* X_INTERFACE_INFO = "xilinx.com:interface:axis:1.0 S_AXIS TLAST" *) input wire s_axis_tlast; (* X_INTERFACE_INFO = "xilinx.com:interface:axis:1.0 M_AXIS TVALID" *) output wire m_axis_tvalid; (* X_INTERFACE_INFO = "xilinx.com:interface:axis:1.0 M_AXIS TREADY" *) input wire m_axis_tready; (* X_INTERFACE_INFO = "xilinx.com:interface:axis:1.0 M_AXIS TDATA" *) output wire [127 : 0] m_axis_tdata; (* X_INTERFACE_INFO = "xilinx.com:interface:axis:1.0 M_AXIS TKEEP" *) output wire [15 : 0] m_axis_tkeep; (* X_INTERFACE_PARAMETER = "XIL_INTERFACENAME M_AXIS, TDATA_NUM_BYTES 16, TDEST_WIDTH 0, TID_WIDTH 0, TUSER_WIDTH 0, HAS_TREADY 1, HAS_TSTRB 0, HAS_TKEEP 1, HAS_TLAST 1, FREQ_HZ 100000000, PHASE 0.0, CLK_DOMAIN design_1_clk_0, LAYERED_METADATA undef, INSERT_VIP 0" *) (* X_INTERFACE_INFO = "xilinx.com:interface:axis:1.0 M_AXIS TLAST" *) output wire m_axis_tlast; axis_data_fifo_v2_0_7_top #( Изменено 19 августа пользователем cbiker Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться