Перейти к содержанию
    

Vivado кастомизация параметров в IP Packager с помощью XPATH

1 hour ago, Vengin said:

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

Абсолютно нет! Я говорю что эту расчитанную константу не нужно запихивать в Генерик/Параметр. Используйте константу напрямую везде где она необходима. Не нужно лишнего переприсвоения. Параметризация будет сама разбросана.

1 hour ago, Vengin said:

1) Можно или нельзя напрямую из HDL кода подтягивать параметры, если в рассчётах параметров используются только стандарные библиотечные мат функции типа log2?

Да можно. Вопрос как вы это сделаете. Криво через 4 вложения или напрямую используете константу

1 hour ago, Vengin said:

А в какой Vivado это? Я пытаюсь на 2017.4. Может в версиях постарше постепенно решают проблемы..

В самой свежей. 17-тая может и не тянет. В 19 всё ок

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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 код уже не скомпилишь для симуляции/синтеза. В чём тогда смысл?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

1 minute ago, Vengin said:

Да и не совсем понятно, что этот подход (использование XPATH функций) даёт? Допустим IP Packager не ругается на модифицированный HDL (с использованием XPATH функции вместо стандартный). Но ведь при этом сам HDL код уже не скомпилишь для симуляции/синтеза. В чём тогда смысл?

Смысл в стандартизации (надо же прогресс как то двигать) - типа пишем HDL единообразно и не паримся с паковкой в различных IP пакерах.  Ну а для того чтобы скомпилировалось в симуляции/синтезе напишем еще одну стандартную библиотеку или package. Ни кто ведь вам не мешает сделать XPATH врапперы над обычными функциями ieee math.

Но одно ясно - без мозолистых рук вам не обойтись :gamer2::gamer3:   

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я наверное сам виноват, что не показал на примере, но вот написано то же самое:

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 )))); и пользоваться ею...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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]:

image.thumb.png.3608a22bb3b24b7e864519e87fe069bf.png

 

Наверное чем иметь такой ненужный геморрой с этим IP Packager лучше в Block Design выпихнуть наружу порты, которые нужно подключать к корке и склеивать это всё уже в HDL. Бррр...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

37 minutes ago, Vengin said:

В итоге получается модуль, у когорого шина addr1[0:0], addr2[4:0]:

А скиньте ещё скрины "Customization Parameters" и "Ports and Intefaces" из приведённого примера, пожалуйста.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

41 minutes ago, Vengin said:

Не нравится именно parameter AW = $clog2(DW).

В итоге получается модуль, у когорого шина addr1[0:0], addr2[4:0]:

Ну все предсказуемо :unknw: 

Гы,  немного поэкспериментировал - на строке 

...
input  [log(2, DATA_WH)-1:0] addr2,
...

пакер в 19.1 уходит бесконечную медитацию бросив перед этим в лог ворчливое 

WARNING: [IP_Flow 19-5150] The Range '(log(2DATA_WH) - 1):0' is present  ...

Прикольно  парсер работает :shok: не уж то региональные настройки (. ,) могут влиять на это?

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

А скиньте ещё скрины "Customization Parameters" и "Ports and Intefaces" из приведённого примера, пожалуйста.

image.thumb.png.1c8f3d9d1c2c7ec7c2609821fa7061bb.png

image.thumb.png.0464cfa57119e031768fabe4572cab83.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Если хотите чтобы в 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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

34 minutes ago, Vengin said:

image.thumb.png.1c8f3d9d1c2c7ec7c2609821fa7061bb.png

image.thumb.png.0464cfa57119e031768fabe4572cab83.png

Я даже ради спортивного интереса у себя сделал проект - всё работает. Скиньте свой, будем поглядеть.

P.S. Всмысле свой проект-пример. Не основной

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

16 часов назад, Nick_K сказал:

Я даже ради спортивного интереса у себя сделал проект - всё работает. Скиньте свой, будем поглядеть.

P.S. Всмысле свой проект-пример. Не основной

Вот

tst_ip_packager.xpr.zip

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

56 minutes ago, Vengin said:

Во-первых это не проект, во-вторых это не тот проект (пример со скриншотов). Но я взял один ваш файл и сделал с него компонент. Всё работает и никаких глюков.

p.s. Создайте проект просто запустив build.tcl с папки в среде Вивадо

sv_prj_wb_intercon.zip

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 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 написано...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

хотел назадавать здесь много вопросов  по интегратору и 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(когда порт включен это вход или выход).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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 #(

 

Изменено пользователем cbiker

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...