Jump to content

    

Vengin

Свой
  • Content Count

    137
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Vengin

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

Контакты

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

Информация

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

Recent Profile Visitors

1478 profile views
  1. 1. Сделано. 2. Подключено в файле проекта *.mpf (аналог modelsim.ini). Библиотеки в симуляторе отображаются. 3. Не совсем понятно. Аналог директивы #include (для VHDL это LIBRARY ...; USE ...;)? Это и так делается в сгенеренных коркой файлах. Не припомню одинаковых библиотек с суффиксами. Обычно вроде есть только несколько разных версий (типа floating_point_v7_0_16, floating_point_v7_1_8). Строка "protected" вроде фигурирует только внутри файлов библиотек " *_vh_rfs.vhd " (header с описанием чего и как зашифровано).
  2. Здравствуйте. Решил обновить рабочий софт: работал на связке Vivado 2017.4 + Modelsim 10.5, обновил до Vivado 2019.1 + Modelsim 2019.2. Скомпилил симуляционные библиотеки. При попытке симуляции одного рабочего проекта (без оптимизации, т.е. "vsim -novopt …") изначально получаю ошибку: # ** Error (suppressible): (vsim-12110) All optimizations are disabled because the -novopt option is in effect. This will cause your simulation to run very slowly. If you are using this switch to preserve visibility for Debug or PLI features, please see the User's Manual section on Preserving Object Visibility with vopt. -novopt option is now deprecated and will be removed in future releases. Подавляю эту ошибку (добавлением флага "vsim -novopt suppress 12110 …") и симуляция отрабатывает (при этом вываливается куча warnings, предупреждающих, что при выключенной оптимизации симуляция будет медленной и т.п.). Когда же пытаюсь включить оптимизацию (“vsim -voptargs="+acc" ….”) получаю маловразумительные ошибки: # ** Error: D:\PF\Xilinx\Vivado\2019.1\data\ip\xilinx\xbip_dsp48_addsub_v3_0\hdl\xbip_dsp48_addsub_v3_0_vh_rfs.vhd(64): (vopt-1598) Library "<protected>" not found. # ** Error: D:\PF\Xilinx\Vivado\2019.1\data\ip\xilinx\xbip_dsp48_addsub_v3_0\hdl\xbip_dsp48_addsub_v3_0_vh_rfs.vhd(64): (vopt-1136) Unknown identifier "<protected>". В проекте используются ядра floating_point_v7_1_8, которым требуются xbip_dsp48_addsub_v3_0_vh_rfs.vhd, о которых по идее и говорится в ошибках. Т.к. это всё шифрованные исходники, то пытаться искать в них что-то бессмысленно. Где искать корень зла непонятно. Сделал пустой проект с простейшим float ядром add32 (на базе ядра floating_point_v7_1_8) и он симулируется корректно, как с оптимизацией, так и без неё. Может есть идеи, в чём может быть проблема при включении оптимизации? Или кто какие версии Modelsim использует с Vivado 2019.1? Xilinx для Vivado 2019.1 рекомендует Modelsim 10.7c, но его найти пока не удалось.
  3. На картинке в 1-ом посте действительно выделяется только цвет самого соединения (а при clock/reset domains выделяются ещё порты). clock/reset domains цвета раскидывается сам (может и можно настраивать - не заморачивался, и так хватало), с другим "разукрашиванием" вроде не сталкивался. Windows версия если что.
  4. ЕМНИП цвета раскидываются автоматически при показе clock domains или reset domains (в менюшке View). Не знаю точно с какой версии это появиялось (есть в 16.1)
  5. Действительно, после того как добавил тип параметра integer, warning-и исчезли и компонент лепистся нормально. Эх, жаль что всё уже на VHDL написано...
  6. Подход понятен. Но проблемы это не решает (по крайней мере в 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. Бррр...
  7. О, а я пробовал с GENERIC - не клеилось, на портах и не проверял. Как и упоминалось на форумах Xilinx какой-то очень сырой и своеобразный этот парсер IP Packager. Да и не совсем понятно, что этот подход (использование XPATH функций) даёт? Допустим IP Packager не ругается на модифицированный HDL (с использованием XPATH функции вместо стандартный). Но ведь при этом сам HDL код уже не скомпилишь для симуляции/синтеза. В чём тогда смысл?
  8. Не понимаю. Допустим есть конфигурационный файл с расчётом параметра 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. Может в версиях постарше постепенно решают проблемы..
  9. Гм. Ну я вроде считаю себя программистом. Но вооще это продиктовано ТЗ - есть набор конфигураций, которые корка должна "подхватывать". Но должна быть и возможность её настраивать вручную. И всегда легко сказать "меняйте архитектуру" (хотя я например не вижу на что менять). Как вы себе это представляете, когда проект пишется не один месяц, вдруг всё поменять. Да и не совсем понятен предлагаемый подход: заменить все параметры на рассчитанные фиксированные значения. Т.е. придётся делать N копий версий проекта (по количеству конигурационных файлов), где каждая версия имеет жёстко вбитые в коде константы рассчитанных параметров? И опять таки самое главное. Простая замена GENERIC на непосредственно формулы с мат функциями типа log2 не решает проблемы (т.е. ошибки IP Packager остаются)!!!
  10. Тем более, если даже убрать в 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)".
  11. Это простой пример для демонстрации проблемы. Как я и говорил в реальности по другому. Параметры рассчитываются в различных конфигурационных package файлах и, в зависимости от конфигурации, подставляются в ядро (в основном в GENERIC верхнего уровня, но не только есть и другие зависимости). Т.е. например на верхнем уровне есть: USE WORK.CFG_PKG01.all; .... generic( GENERIC_PARAMETER1: natural := PARAMETER1_CALCULATED_IN_CFG_PKG01; ) Значение PARAMETER1_CALCULATED_IN_CFG_PKG01 рассчитано в файле CFG_PKG01.vhd (на основе других параметров заданных в этом конфигурационном файле)
  12. Да я уже начинаю задумываться о всевозможных вариантах. Да и речь не о фантазиях, а о вроде как банальных вещах в языке VHDL, которому больше 20 лет (т.е. речь о не о VHDL-2008). Но воощбе пытаюсь понять: 1) Точно нельзя напрямую из HDL кода (если в рассчётах параметров используются только стандарные библиотечные мат функции типа log2)? 2) Возвращаясь к изначальному вопросу в 1-ом сообщении: что за механизм такой функции XPATH и куда его пихать? Потому как когда вручную модифицируется параметр, то рассчёты делаются вроде как по синтаксису TCL (например, для ADDR_WIDTH по формуле expr {log($DATA_WIDTH)/log(2)} )