Jump to content

    

Vengin

Свой
  • Content Count

    135
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Vengin

  • Rank
    Частый гость

Контакты

  • Сайт
    http://
  • ICQ
    438549118

Информация

  • Город
    Беларусь, г. Минск

Recent Profile Visitors

1378 profile views
  1. На картинке в 1-ом посте действительно выделяется только цвет самого соединения (а при clock/reset domains выделяются ещё порты). clock/reset domains цвета раскидывается сам (может и можно настраивать - не заморачивался, и так хватало), с другим "разукрашиванием" вроде не сталкивался. Windows версия если что.
  2. ЕМНИП цвета раскидываются автоматически при показе clock domains или reset domains (в менюшке View). Не знаю точно с какой версии это появиялось (есть в 16.1)
  3. Действительно, после того как добавил тип параметра integer, warning-и исчезли и компонент лепистся нормально. Эх, жаль что всё уже на VHDL написано...
  4. Подход понятен. Но проблемы это не решает (по крайней мере в 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. Бррр...
  5. О, а я пробовал с GENERIC - не клеилось, на портах и не проверял. Как и упоминалось на форумах Xilinx какой-то очень сырой и своеобразный этот парсер IP Packager. Да и не совсем понятно, что этот подход (использование XPATH функций) даёт? Допустим IP Packager не ругается на модифицированный HDL (с использованием XPATH функции вместо стандартный). Но ведь при этом сам HDL код уже не скомпилишь для симуляции/синтеза. В чём тогда смысл?
  6. Не понимаю. Допустим есть конфигурационный файл с расчётом параметра PAR1: constant PAR1_0: natural := 32; constant PAR1_1: natural := 8; constant PAR1: natural := natural(ceil(log2( PAR1_0/PAR1_1 ))); Я так понимаю, предлагается вместо формулы вставить константу, равную рассчитанному значению: constant PAR1_0: natural := 32; constant PAR1_1: natural := 8; --constant PAR1: natural := natural(ceil(log2( PAR1_0/PAR1_1 ))); constant PAR1: natural := 2; Так что ли? Тогда при любом изменении значений входящих в формулу (PAR1_0, PAR1_0) нужно вручную перерасчитывать PAR1 (и отслеживать это). Это бессмысленная и ненужная работа. Вроде сама идея программирования сводится к автоматизации ручного труда, а не к обратному. Честно говоря, не хочу превращать тему во флуд. Просто пытаюсь решить простую казалось бы проблему. А для этого пытаюсь получить ответ на два простых вопроса: 1) Можно или нельзя напрямую из HDL кода подтягивать параметры, если в рассчётах параметров используются только стандарные библиотечные мат функции типа log2? 2) Возвращаясь к изначальному вопросу в 1-ом сообщении: что за механизм такой функции XPATH и куда его пихать? Потому как когда вручную модифицируется параметр, то рассчёты делаются вроде как по синтаксису TCL (например, для ADDR_WIDTH по формуле expr {log($DATA_WIDTH)/log(2)} ) ----------------------- А в какой Vivado это? Я пытаюсь на 2017.4. Может в версиях постарше постепенно решают проблемы..
  7. Гм. Ну я вроде считаю себя программистом. Но вооще это продиктовано ТЗ - есть набор конфигураций, которые корка должна "подхватывать". Но должна быть и возможность её настраивать вручную. И всегда легко сказать "меняйте архитектуру" (хотя я например не вижу на что менять). Как вы себе это представляете, когда проект пишется не один месяц, вдруг всё поменять. Да и не совсем понятен предлагаемый подход: заменить все параметры на рассчитанные фиксированные значения. Т.е. придётся делать N копий версий проекта (по количеству конигурационных файлов), где каждая версия имеет жёстко вбитые в коде константы рассчитанных параметров? И опять таки самое главное. Простая замена GENERIC на непосредственно формулы с мат функциями типа log2 не решает проблемы (т.е. ошибки IP Packager остаются)!!!
  8. Тем более, если даже убрать в 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)".
  9. Это простой пример для демонстрации проблемы. Как я и говорил в реальности по другому. Параметры рассчитываются в различных конфигурационных package файлах и, в зависимости от конфигурации, подставляются в ядро (в основном в GENERIC верхнего уровня, но не только есть и другие зависимости). Т.е. например на верхнем уровне есть: USE WORK.CFG_PKG01.all; .... generic( GENERIC_PARAMETER1: natural := PARAMETER1_CALCULATED_IN_CFG_PKG01; ) Значение PARAMETER1_CALCULATED_IN_CFG_PKG01 рассчитано в файле CFG_PKG01.vhd (на основе других параметров заданных в этом конфигурационном файле)
  10. Да я уже начинаю задумываться о всевозможных вариантах. Да и речь не о фантазиях, а о вроде как банальных вещах в языке VHDL, которому больше 20 лет (т.е. речь о не о VHDL-2008). Но воощбе пытаюсь понять: 1) Точно нельзя напрямую из HDL кода (если в рассчётах параметров используются только стандарные библиотечные мат функции типа log2)? 2) Возвращаясь к изначальному вопросу в 1-ом сообщении: что за механизм такой функции XPATH и куда его пихать? Потому как когда вручную модифицируется параметр, то рассчёты делаются вроде как по синтаксису TCL (например, для ADDR_WIDTH по формуле expr {log($DATA_WIDTH)/log(2)} )
  11. Вот простейшая VHDL болванка, с которой экспериментировал: LIBRARY IEEE; USE IEEE.STD_LOGIC_1164.ALL; USE IEEE.STD_LOGIC_UNSIGNED.ALL; USE IEEE.MATH_REAL.ALL; entity top is generic ( DATA_WIDTH : natural := 32; ADDR_WIDTH : natural := natural(ceil(log2(real( DATA_WIDTH )))) ); port( clk : in std_logic; addr : in std_logic_vector(ADDR_WIDTH-1 downto 0); di : in std_logic_vector(DATA_WIDTH-1 downto 0); do : out std_logic_vector(DATA_WIDTH-1 downto 0) ); end top; architecture beh of top is begin D_P: process(clk) begin if rising_edge(clk) then do <= di; end if; end process; end beh; При попытке упаковать это IP Packager выдаёт ошибки в "Customization Parameters": [IP_Flow 19-343] User Parameter 'ADDR_WIDTH (Addr Width)': Default value "natural(ceil(log2(real(DATA_WIDTH))))" does not match format "long" [IP_Flow 19-343] HDL Parameter 'ADDR_WIDTH (Addr Width)': Default value "natural(ceil(log2(real(DATA_WIDTH))))" does not match format "long" Пробовал заменить библиотечную функцию math_real.log2 на самописную, но с тем же результатом. Из вариантов пробовал вручную настраивать параметр ADDR_WIDTH: Т.е. делал ему Dependency=YES, по формуле expr {log($DATA_WIDTH)/log(2)}. Но это не совсем решает проблему, т.к. например параметр Deаfault Value всё равно нужно выставлять вручную. Но вообще проблема в то, что надо вручную набивать формулы. А надо бы, чтобы формулы подхватывались из HDL кода. Дело в том, что есть параметризируемое ядро, с большим количеством настроек. Наборы настроек задаются конфигурационными файлами, которые представляют vhdl package файлы (их десятки разных), в которых эти настройки рассчитываются. В зависимости от конфигурации ядра просто подключается нужный конфигурационный файл, из которого подставляются значения для ядра (в основном через GENERIC параметры). Вот и пытаюсь понять, как это всё впихнуть в IP Packager.
  12. Да я никак не могу понять, где их можно использовать, чтобы собственно добиться кастомизации параметоров. Судя по синтаксису это что-то Tcl-образное. Но куда это впихивать - не понятно. В HDL это не лезет. Пробовал вручную модифицировать файл component.xml, генерируемый при создании IP Core, но сходу не получилось.