Jump to content

    

Vengin

Свой
  • Content Count

    135
  • Joined

  • Last visited

Everything posted by Vengin


  1. На картинке в 1-ом посте действительно выделяется только цвет самого соединения (а при clock/reset domains выделяются ещё порты). clock/reset domains цвета раскидывается сам (может и можно настраивать - не заморачивался, и так хватало), с другим "разукрашиванием" вроде не сталкивался. Windows версия если что.
  2. ЕМНИП цвета раскидываются автоматически при показе clock domains или reset domains (в менюшке View). Не знаю точно с какой версии это появиялось (есть в 16.1)
  3. Здравствуйте. Нужно создать в Vivado IP Core, чтобы интегрировать его в Block Design и подключать к Zynq. Был неприятно удивлён тем, что не поддерживаются пользовательские функции (к примеру log2 для задания параметра ширины шины). На форуме Xilinx нашёл пару похожих тем (например, ), только вот решения так и не увидел. В основном описываются проблемы "парсера" IP Packager. Но вроде как в том же ug1118 Creating and Packaging Custom IP говорится о поддержке более сложных математических выражений при помощи XPATH функций: Вот только как и где использовать эти функции XPATH? Как ни пытался ничего не получилось. Даже в описываемом примере, как можно в Verilog коде "output [ceil_log2(max_count)-1:0] count;" заменить пользовательскую функцию ceil_log2 на некую XPATH функцию ceiling(log(2, $max_count)), у которой параметр $max_count описывается как в языке Tcl. Как понять фразы: Может знает кто, как собственно можно использовать эти самые XPATH функции? Или вообще, как кто боролся с кастомизацией параметров для ядер в IP Packager?
  4. Действительно, после того как добавил тип параметра integer, warning-и исчезли и компонент лепистся нормально. Эх, жаль что всё уже на VHDL написано...
  5. Подход понятен. Но проблемы это не решает (по крайней мере в 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. Бррр...
  6. О, а я пробовал с GENERIC - не клеилось, на портах и не проверял. Как и упоминалось на форумах Xilinx какой-то очень сырой и своеобразный этот парсер IP Packager. Да и не совсем понятно, что этот подход (использование XPATH функций) даёт? Допустим IP Packager не ругается на модифицированный HDL (с использованием XPATH функции вместо стандартный). Но ведь при этом сам HDL код уже не скомпилишь для симуляции/синтеза. В чём тогда смысл?
  7. Не понимаю. Допустим есть конфигурационный файл с расчётом параметра 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. Может в версиях постарше постепенно решают проблемы..
  8. Гм. Ну я вроде считаю себя программистом. Но вооще это продиктовано ТЗ - есть набор конфигураций, которые корка должна "подхватывать". Но должна быть и возможность её настраивать вручную. И всегда легко сказать "меняйте архитектуру" (хотя я например не вижу на что менять). Как вы себе это представляете, когда проект пишется не один месяц, вдруг всё поменять. Да и не совсем понятен предлагаемый подход: заменить все параметры на рассчитанные фиксированные значения. Т.е. придётся делать N копий версий проекта (по количеству конигурационных файлов), где каждая версия имеет жёстко вбитые в коде константы рассчитанных параметров? И опять таки самое главное. Простая замена GENERIC на непосредственно формулы с мат функциями типа log2 не решает проблемы (т.е. ошибки IP Packager остаются)!!!
  9. Тем более, если даже убрать в 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)".
  10. Это простой пример для демонстрации проблемы. Как я и говорил в реальности по другому. Параметры рассчитываются в различных конфигурационных package файлах и, в зависимости от конфигурации, подставляются в ядро (в основном в GENERIC верхнего уровня, но не только есть и другие зависимости). Т.е. например на верхнем уровне есть: USE WORK.CFG_PKG01.all; .... generic( GENERIC_PARAMETER1: natural := PARAMETER1_CALCULATED_IN_CFG_PKG01; ) Значение PARAMETER1_CALCULATED_IN_CFG_PKG01 рассчитано в файле CFG_PKG01.vhd (на основе других параметров заданных в этом конфигурационном файле)
  11. Да я уже начинаю задумываться о всевозможных вариантах. Да и речь не о фантазиях, а о вроде как банальных вещах в языке VHDL, которому больше 20 лет (т.е. речь о не о VHDL-2008). Но воощбе пытаюсь понять: 1) Точно нельзя напрямую из HDL кода (если в рассчётах параметров используются только стандарные библиотечные мат функции типа log2)? 2) Возвращаясь к изначальному вопросу в 1-ом сообщении: что за механизм такой функции XPATH и куда его пихать? Потому как когда вручную модифицируется параметр, то рассчёты делаются вроде как по синтаксису TCL (например, для ADDR_WIDTH по формуле expr {log($DATA_WIDTH)/log(2)} )
  12. Вот простейшая 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.
  13. Да я никак не могу понять, где их можно использовать, чтобы собственно добиться кастомизации параметоров. Судя по синтаксису это что-то Tcl-образное. Но куда это впихивать - не понятно. В HDL это не лезет. Пробовал вручную модифицировать файл component.xml, генерируемый при создании IP Core, но сходу не получилось.
  14. Ну, если изделие планируется пускать в серию, и официально продаваться в тех же штатах, то вопросов не избежать. Мне как инженеру гораздо проще просто использовать "честно стыренное", но обычно у буржуинов всё сложнее. И критерием "честности" будет являться собственно покупка лицензии у дистрибьютера. А этот переговорный процесс не так-то прост. Вдогонку про честность, на форуме xilinx: " if you clone the Digilent EEPROM (which lets the FT2232 identify as a Digilent product, and is necessary to make it talk to the Xilinx tools) and the USB PID/VID then you're almost certainly committing copyright infringement - with all the usual penalties. "
  15. Спасибо! Надо понимать, что содержимое зашиваемое в EEPROM это "пиратчина". Но если нужно сделать всё официально нужно искать лицензиею? Может кому приходилось идти официальным путём - насколько это сложно/дорого/геморно?
  16. Здравствуйте. Пытаюсь решить такую же пробему как и у TC (т.е. на кастомную плату поставить FT2232H, чтобы сделать мост USB-JTAG для программирования Zynq-7000. Почитав эту и другие темы, так и не понял, каково же решение. Может кто подсказать, какого набора достаточно/необходимо, чтобы можно было из Vivado/ISE программировать/дебажить FPGA через FTDI. Мои предположения: 1) Только FTDI FT*32H (у которой JTAG подсоединен к FPGA). Никаких драйверов, доп софта, всё подхватывается Vivado/ISE? 2) FTDI FT*32 и какие-то стандартные/самодельные драйвера, доп софт, танцы с бубном? 3) FTDI FT*32 к которой подсоединена какая-то EEPROM с "Xilinx JTAG license". Если этот вариант, то не совсем понимаю, как конфигурировать EEPROM? Она ставится на плату уже с готовой предпрошитой лицензией, или подразумевается, что разработчик сам должен её прошить каким-то лицензионным файлом? Где все эти лицензии искать (у Xilinx, или Digilent, или FTDI, или...)? P.S. к сожалению предложенные ссылки не работают (видно слетели после обновления сайта?)
  17. Здравствуйте. Есть кастомная плата с xc7z030fbg676-1. Из-за ограниченного количества PS MIO на пины MIO40-45 на схематике заведено 2 интерфеса (SDIO и SPI) через внешний mux/demux: Вопрос, можно ли обоими интерфейсами пользоваться "статически" или "динамически"? "Статически" - это на одну прошивку один интерфейс. "Динамически" - это в рамках одной прошивки менять тип PS MIO интерфейса на лету. Насколько я понимаю конфигурация PS MIO выполняется за счёт настройки SLCR Registers (как в генерируемом файле ps_init.tcl). А можно ли эти регистры менять прямо из программы процессора? Смотрел ug585-Zynq-7000-TRM, но явного подвтерждения/опровержения пока найти не удалось.
  18. Там однако десятки-сотни программ - копать не перекопать. В примерах виденных ранее вроде не встречалось.
  19. Интересно. Но это всё применимо только для linux kernel. А для bare-metal тогда как? Кажется, что должна быть более низкоуровневая и универсальная возможность. Но в целом это всё предполагает, что переключение в принципе возможно. А вот как узнать наверняка ...
  20. C тонкостями FSBL практически не знаком и предполагал, что он больше отвечает за нюансы загрузки. Бегло просмотрел сейчас раздел "Boot and Configuration" в ug585-Zynq-7000-TRM - как-то не особо помогло. В исходникак FSBL тоже не совсем понятно, что смотреть. Да, есть вызов функции ps7_init(). Есть ещё кстати макросы SlcrLock()/SlcrUnlock(). Но даже в какую сторону копать не совсем понятно. Допустим, в FSBL (в post_config?) переключили интерфейс, а что дальше? В моём понимании FSBL ведь выполняется 1 раз? Как это поможет "динамически" и многократно переключать интерфейсы PS_MIO? Продублировал вопрос на форуме Xilinx, глядишь там помогут. Просто сейчас стоит задача понять, возможно ли это в принципе (динамически переключать PS_MIO интерфейсы), или нужно переделывать плату. Да, кстати, там в плане схематики ещё есть нюанс. Дело в том, что этот shared MIO[40-45] интерфейс выводится через коннектор на другую плату. Если прводить оба интерфейса по отдельности, может не хватить места в коннектере.
  21. А при чём тут FSBL, и исходники чего смотреть?
  22. Ну, если это можно делать программно, то это естественно проще чем переразводить плату. Да и вообще мне и самому интересено, насколько в этом плане гибока подсистема PS цинка.