Jump to content

    

Search the Community

Showing results for tags 'vivado'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Сайт и форум
    • Новости и обсуждения сайта и форума
    • Другие известные форумы и сайты по электронике
    • В помощь начинающему
    • International Forum
    • Образование в области электроники
    • Обучающие видео-материалы и обмен опытом
  • Cистемный уровень проектирования
    • Вопросы системного уровня проектирования
    • Математика и Физика
    • Операционные системы
    • Документация
    • Системы CAD/CAM/CAE/PLM
    • Разработка цифровых, аналоговых, аналого-цифровых ИС
    • Электробезопасность и ЭМС
    • Управление проектами
    • Neural networks and machine learning (NN/ML)
  • Программируемая логика ПЛИС (FPGA,CPLD, PLD)
    • Среды разработки - обсуждаем САПРы
    • Работаем с ПЛИС, области применения, выбор
    • Языки проектирования на ПЛИС (FPGA)
    • Системы на ПЛИС - System on a Programmable Chip (SoPC)
  • Цифровая обработка сигналов - ЦОС (DSP)
    • Сигнальные процессоры и их программирование - DSP
    • Алгоритмы ЦОС (DSP)
  • Микроконтроллеры (MCs)
    • Cредства разработки для МК
    • ARM
    • AVR
    • MSP430
    • Все остальные микроконтроллеры
    • Отладочные платы
  • Печатные платы (PCB)
    • Разрабатываем ПП в САПР - PCB development
    • Работаем с трассировкой
    • Изготовление ПП - PCB manufacturing
  • Сборка РЭУ
  • Аналоговая и цифровая техника, прикладная электроника
  • Силовая Электроника - Power Electronics
  • Интерфейсы
  • Поставщики компонентов для электроники
  • Майнеры криптовалют и их разработка, BitCoin, LightCoin, Dash, Zcash, Эфир
  • Дополнительные разделы - Additional sections

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Сайт


ICQ


Yahoo


Jabber


Skype


Город


Код проверки


skype


Facebook


Vkontakte


LinkedIn


Twitter


G+


Одноклассники

  1. Здравствуйте, подскажите, как в проекте сделать так, чтобы тестбенч для верхнего уровня читал данные из файла в модуль нижнего уровня. Не делая выводы в модeле top? Либо можно как-то пометить выводы верхнего уровня, чтоб при имплементации не выдавало ошибок об отсутствии пинов для данных выводов?
  2. Всем привет. Мы проводим стримы по FPGA/ПЛИС тематике на твиче по адресу twitch.tv/fpgasystems Обычно, это среда и суббота в 20:00. Записи прошедших стримов лежат на youtube: youtube.com/c/fpgasystems Ждём Вас на стриме. Анонсы предстоящих эфиров в группе в телеграм @fpgasystems (https://t.me/fpgasystems) и VK и FB
  3. На вебинаре вы познакомитесь с новой средой разработки Vitis, в которой реализована парадигма высокоуровневого проектирования, и с двумя новыми аппаратными платформами от Xilinx – Versal и Alveo, для которых разработка в среде Vitis наиболее эффективна. Вебинар предназначен как для разработчиков для ПЛИС и СнК, желающих повысить свою продуктивность с помощью средств высокоуровневого проектирования, так и для программистов, ищущих возможности повышения производительности своих компьютерных систем с помощью адаптируемых аппаратных ускорителей Xilinx Alveo. Вебинар состоится 31 марта в 14:00 (мск). Повтор вебинара 2 апреля в 10:00 (мск). Участие в вебинаре бесплатное, после предварительной регистрации. Регистрация на вебинар
  4. Добрый день, форумчане! Встал вопрос о внедрении системы контроля версий (Git) в процесс проектирования с использованием САПР Vivado. Немного покопавшись в этих самых интернетах, вычитал, что народ создает файловую структуру рядом с проектом, в которой хранятся исходники проекта (*.v, *.vhdl, *.xci, *.elf и прочее и прочее). Собственно, эту самую структуру и засовывают в СКВ. Далее вопрос: Как заполнить эту самую структуру перед коммитом? *Мысли в слух* Вариант 1. У меня есть отлаженный проект. И я ручками/не ручками (скриптами) из финальной версии проекта перетаскиваю в файловую структуру для СКВ все исходники. При этом в IDE исходники подключены из папки проекта. Коммитим. Когда вытаскиваем данный коммит (pull) из СКВ ручками/скриптами подсовываем в директорию проекта, затем собираем. Вариант 2. У меня есть неотлаженный проект. Я по мере допиливания проекта добавляю IP и исходники, затем ручками перетаскиваю во внешние папки и далее в IDE указываю расположение исходников во внешних папках. В финальной версии проекта перед коммитом все файлы уже на своих местах, т.е. в файловой структуре для СКВ. Коммитим. При вытаскивании из СКВ файлы исходников автоматически подменятся и останется только собрать проект. Вариант 3. Накатать скрипт, который из финальной версии проекта вытаскивает нужные исходники и генерирует скрипт, который на основании исходников создает проект с нуля (recreate). Все это добро коммитится. Вариант 4. Мыслю вообще не в том направлении.
  5. Всем привет! vivado 2018.3 artyx7 ac701 development kit. Столкнулся с проблемой в назначение ножек. В идеи когда при создание проекта выбирается борда вместо отделенного ПЛИСа, то Vivado в настройках ip позволяет сделать привязку к определённым в отладочной плате выводам. Как я и сделал в моём случае. Дело в том что среде ругается на отсутствие назначений ножек для axi_ethernetlite. На схеме к отладке ножек этих нет. Что делаю не так?) phy_col, phy_crs, phy_rst_n ... phy_tx_data[3:0] при этом phy_mdc, phy_mdio_i,phy_mdio_o,phy_mdio_t среда назначила нормально. Схему block design прикрепил в атач. Заранее спасибо за помощь) ethernet_lite.pdf
  6. Пытаюсь использовать в своём проекте готовый IP блок от Xilinx, а именно Fir Compiler 7.2 Пытаюсь реализовать несколько симметричных КИХ фильтров. Частота работы фильтра в 24 раза больше частоты дискретизации. Пока коэффициентов было мало - логика имплеминтации была понятна: 48 коэффициентов - 1 DSP блок 96 коэффициентов - 2 DSP блока Захотел использовать фильтр на 20 DSP блоков - 960 коэффициентов не лезет, только 912 сейчас изменил значения этих 912 коэффициентов - требует 41 DSP. Я бы хотел иметь возможность задавать разные АЧХ одному фильтру, но не понятно для чего ему дополнительные DSP.
  7. Всем привет! Возможно, вопрос обсуждался, но мне найти не удалось. Суть в следующем. Есть проект, успешно собирается и даже работает. Но при синтезе возникают тонны предупреждений такого рода: WARNING: [Synth 8-3331] design <...> has unconnected port <...>. Выглядит угрожающе, но на деле по нетлисту (схематику) видно, что сигналы-то на месте, всё подключено. Анализ показывает, что почти все они относятся к сигналам интерфейсов. И похоже, что синтезатор ругается на сигналы модпортов интерфейса, которые не используется в том или ином модуле. Т.е. насколько понимаю, картина такая: есть интерфейс, у него есть модпорты m0, m1, s0, модпорт m0 подключается к модулю master0, модпорт m1 - к модулю master1, а модпорт s0 - к модулю slave0. Получается, что интерфейс прокинут во все модули, но часть сигналов, которые относятся к другим модпортам, естественно в данном конкретном модуле не подключена - например, в модуле master0 не подключены сигналы модпоротов m1 и s0. Получается, что ругань как бы не по делу. Собственно вопрос: как с этим бороться, т.к. подобные предупреждения выглядят неприятно?
  8. Доброго времени суток. Итак за пол года изучения Vivado/SystemVerilog добрался вуршины ещё одного холма. В проекте стоит задача передать параметр конфигурации из Block Design в tcl скрипт, который формирует placement констрейны. Ниже скидываю пример тестового проекта. В данном примере для корректной работы нужно прокинуть в папку ip_repo/CSA_1.0 ссылку на sources из корня с именем src иначе ip ядро может не собираться и дико глючить (на линукс машинах уже всё готово). Собственно проблема в том, что я конфигурирую в BD параметр Integer_Resolution компонента CSA (carry save adder), который формирует разное количество триггеров. Дялее мне нужно разложить эти триггеры по плате в конкретной последовательности, для чего в констрейнах прописан скрипт floorplanning.tcl. Вся проблема заключается в автоматической передаче значения Integer_Resolution в переменную component_num в скрипте. Сейчас приходится всё прописывать руками. Возможно ли это сделать в автоматическом режиме? p.s. Любые замечания по проекту также приветствуются, которые позволят оптимизировать/улучшить компоненты или в целом. test_proj.tar
  9. Здравсвуйте. Пытаюсь скомпилировать библиотеки для квэсты. Возникает ошибка с библиотекой common_cpp_v1_0 (не видел ее раньше в предыдущих версиях). Компиляция прекращается. вивада успевает скомпилить совсем мало... нету либ для ip ядер... Linux. Vivado 2019.1. Questasim_10.7c Подскажите, пожалуйста, как побороть это? Или как заставить виваду продолжать компилировать дальше (исключить конкретно эту либу)? -спасибо
  10. Доброго времени суток! Для облегчения жизни при сборке модулей в готовую систему решил сделать свой модуль как отдельное IP ядро с всеми необходимыми настройками параметров, включая размножение внутренних компонентов обработки, которые состоят из входного сигнала, логики+БРАМ, и выходной порт AXI. Всё написано на SystemVerilog и "выходной" порт AXI запихнут в отдельный интерфейс. Правдами и неправдами сумел собрать IP и договорится с bd что это и вправду компонент с AXI шинами (пришлось перегенерировать кучу портов и создать массу ненужных параметров, те которые с ID и USER). Для удобства создал параметр, который говорит сколько внутри размножено модулей и соответственно сколько входных сигналов и выодных AXIшин должно быть прокинуто. С помощью настройки Interface presence указал когда должны появляться порты (коих 32 штуки) по условию ($P_COMPONENT_NUM >N) для входных сигналов и AXI. Входные порты конфигурируются нормально без каких бы то ни было вопросов, все неиспользующиеся подвешиваются на 0. Но вот AXI начинает творить чудеса. BDувидел, что это AXI и что у него сконфигурированы все порты в соответствии с проприетарным интерфейсом "aximm", да вот только он пытается подключить все 32 AXI порта к несуществующим сигналам. В коде интерфейс сгенерированного топ файла IPядра выглядит где-то так: Тут ничего неординароного, а вот дальше генератор пытается создать и подключить все AXI порты: aximm S_AXI_0(); // Порт 0 присутствует assign S_AXI_0.WLAST = s_axi_0_s_axi_wlast; assign S_AXI_0.BREADY = s_axi_0_s_axi_bready; assign S_AXI_0.AWLEN = s_axi_0_s_axi_awlen; ... aximm S_AXI_1(); // Порт 1 присутствует assign S_AXI_1.WLAST = s_axi_1_s_axi_wlast; assign S_AXI_1.BREADY = s_axi_1_s_axi_bready; assign S_AXI_1.AWLEN = s_axi_1_s_axi_awlen; ... aximm S_AXI_2(); // Порт 2 отсутствует (не сконфигурирован) assign S_AXI_2.WLAST = s_axi_2_s_axi_wlast; assign S_AXI_2.BREADY = s_axi_2_s_axi_bready; assign S_AXI_2.AWLEN = s_axi_2_s_axi_awlen; ... aximm S_AXI_3(); // Порт 3 отсутствует (не сконфигурирован) assign S_AXI_3.WLAST = s_axi_3_s_axi_wlast; assign S_AXI_3.BREADY = s_axi_3_s_axi_bready; assign S_AXI_3.AWLEN = s_axi_3_s_axi_awlen; ... // И так все 32 порта из которых реально входит только 2 первых Ну и дальше идёт подключение к моему сгенерированному IP ядру. top_component inst ( .i_clk(i_clk), .s_axi_aclk(s_axi_aclk), .s_axi_aresetn(s_axi_aresetn), .s00_axi_0_s00_axi_araddr(s00_axi_0_s00_axi_araddr), .s00_axi_0_s00_axi_arprot(s00_axi_0_s00_axi_arprot), .s00_axi_0_s00_axi_arready(s00_axi_0_s00_axi_arready), ... // Конфигурация AXI Lite. Здесь всё нормально .S_AXI_0(S_AXI_0), // Подключён существующий порт .S_AXI_1(S_AXI_1), // Подключён существующий порт .S_AXI_2(S_AXI_2), // Подключён несуществующий порт. Который просто объявлен в топе .S_AXI_3(S_AXI_3), // Подключён несуществующий порт. Который просто объявлен в топе ... // И так далее до 31-го порта .i_signal_0(i_signal_0),// Подключён существующий вход .i_signal_1(i_signal_0),// Подключён существующий вход .i_signal_2(1'B0), // Подключён несуществующий вход. Который просто объявлен в топе .i_signal_3(1'B0), // Подключён несуществующий вход. Который просто объявлен в топе ... // И так далее до 31-го порта ); Как избежать такой ситуации? Нужно дополнительно указать какие-то параметры или вручную создать порты AXI? Этот файл генерируется автоматические и Xilinxпредупреждает: // DO NOT MODIFY THIS FILE.
  11. Здравствуйте. Нужно создать в 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?
  12. Есть необходимость создания проекта под Artix в Vivado: АЦП -> ФНЧ -> ЦАП Цель - на простом проекте отработать навыки работы с констрейнами в Vivado. Вводные: АЦП - выходы LVDS, тактовая данных (64МГц) - тактируют плис ФНЧ - КИХ на частоте 384 МГц ЦАП - КМОП 32 МГц Пока пытаюсь сделать упрощённый вариант - генерировать синус на ЦАП по 16 точкам. Вопрос 1 У меня есть ноги CLK64_P и CLK64_N, из них я создаю клок CLK64 методом: Удивлён, что констрейн на клок приходится задавать для CLK64_P а не для CLK64, это правильно? #create_clock -add -name sys_clk_pin -period 15.625 -waveform {0 7.8125} [get_ports { CLK64_P }]; сколько цифр после точки можно вводить? Vivado понимает 7.8125 или округлит до 7.81? Вопрос 2 Мне нужны частоты 384МГц и 32МГц, 384МГц получаю так: Мне надо прописывать констрейн на клок CLK384 или Vivado сам поймёт что он и всё что от него тактируется работает на частоте 384МГц? Вопрос 3 Как лучше получить частоту 32 МГц - своим счётчиком или с PLL? Вопрос 4 Счётчики в Vivado оптимизируются? В ISE я брал 32 разрядный регистр, делел на нём 3 разрядный счётчик и при синтезе у меня старшие разряды отбрасывались и получался 3 разрядный счётчик в Vivado я что-то этого не замечаю, он что пытается развести 32 разряда? Вопрос 5 Как передавать данные между блоками работающими на частотах 64, 384, 32 МГц - напрямую или ставить регистры типа FIFO для надёжности? Вопрос 6 Хочется сделать выходные и входные триггеры и разместить их рядом с ножками - как это описать в констрейнах и как задать время запаздывания/распространения? Вопрос 7 Файл .xdc - один на проект или можно создать некую иерархию из .xdc файлов? констрейны только в .xdc? В верилоге сразу указать нельзя?
  13. Сборка софт процессора MicroBlaze от Xilinx на русском в пошаговом режиме с огромным количеством картинок в нескольких частях: Разработка процессорной системы на базе софт-процессора MicroBlaze в среде Xilinx Vivado IDE/HLx. Часть 1. Разработка процессорной системы на базе софт-процессора MicroBlaze в среде Xilinx Vivado IDE/HLx. Часть 2. Программирование загрузочной FLASH для запуска MicroBlaze Подключение подсистемы памяти к MicroBlaze (MIG 7 Series)
  14. Доброго времени суток, уважаемые форумчане. Балуюсь с ядром ПФ в Vivado. Ядро сконфигурировано следующим образом: - размер - 8192 точки. - Тактовая - 100 МГц. - Сэмплинг - 100 Msps. - Без масштабирования (Unscaled). - convergent rounding. - натуральный порядок вывода. В качестве тестового сигнала использую сумму двух комплексных экспонент, однак на выходе модуля получаю паразитные гармоники (см. рис.). Причем, мнимая часть более ли менее похожа на правда, а шум появляется именно в реальной части. Чем это может быть вызвано и как с таким бороться? На сколько правильно вообще у меня сконфигурировано ядро? Заранее благодарен за ответы. Код модуля: module tb_xfft(); reg CLK = 0; always #5 CLK = ~CLK; wire [31:0] signal1, signal2, signal; wire signal1_valid, signal2_valid, signal_valid; assign signal_valid = signal1_valid & signal2_valid; dds_out16 inst_dds_out16( .aclk(CLK), .m_axis_data_tdata(signal1), .m_axis_data_tvalid(signal1_valid) ); dds_out16_3M inst_dds_out16_3M( .aclk(CLK), .m_axis_data_tdata(signal2), .m_axis_data_tvalid(signal2_valid) ); wire signed [15:0] sin1, cos1, sin2, cos2, sin, cos; wire signed [16:0] ssin, scos; assign sin1 = signal1[31:16]; assign cos1 = signal1[15:0]; assign sin2 = signal2[31:16]; assign cos2 = signal2[15:0]; assign ssin = sin1 + sin2; assign scos = cos1 + cos2; assign sin = ssin[16:1]; assign cos = scos[16:1]; assign signal = {sin, cos}; wire fft_valid; wire [31:0] fft; wire new_fft; wire config_valid; reg [7:0] config_data = {7'b0, 1'b1}; xfft inst_xfft( .aclk(CLK),//aclk : IN STD_LOGIC; .s_axis_config_tdata(config_data),//s_axis_config_tdata : IN STD_LOGIC_VECTOR(31 DOWNTO 0); .s_axis_config_tvalid(config_valid),//s_axis_config_tvalid : IN STD_LOGIC; .s_axis_config_tready(config_valid),//s_axis_config_tready : OUT STD_LOGIC; .s_axis_data_tdata(signal),//s_axis_data_tdata : IN STD_LOGIC_VECTOR(31 DOWNTO 0); .s_axis_data_tvalid(signal_valid),//s_axis_data_tvalid : IN STD_LOGIC; //.s_axis_data_tready(),//s_axis_data_tready : OUT STD_LOGIC; //.s_axis_data_tlast(),//s_axis_data_tlast : IN STD_LOGIC; .m_axis_data_tdata(fft),//m_axis_data_tdata : OUT STD_LOGIC_VECTOR(31 DOWNTO 0); .m_axis_data_tvalid(fft_valid),//m_axis_data_tvalid : OUT STD_LOGIC; .m_axis_data_tready(1),//m_axis_data_tready : IN STD_LOGIC; //m_axis_data_tlast : OUT STD_LOGIC; .event_frame_started(new_fft) ); wire [15:0] fft_re, fft_im; assign fft_re = fft[15:0]; assign fft_im = fft[31:16]; wire [31:0] Re, Im; mult_16x16 inst_mult_re( .CLK(CLK), .A(fft_re), .B(fft_re), .P(Re) ); mult_16x16 inst_mult_im( .CLK(CLK), .A(fft_im), .B(fft_im), .P(Im) ); reg [32:0] Abs = 0; always @(posedge CLK) begin if (fft_valid) begin Abs <= Re + Im; end else begin Abs <= 0; end end endmodule
  15. Имеются две практически идентичные реализации одного и того же проекта. Ниже приведены две таблицы с характеристиками Destination Clock Path (для обоих вариантов). Видно, что различие имеется только для параметра Setup_fdre_C_D: в одном случае он равен 0.076 ns, а в другом 0.033 ns. Отличия в реализации по сути только в одном: в первом случае триггер размещен в SLICEM, во втором в SLICEL. На данный момент мне неясны следующие моменты: что означает параметр Setup_fdre_C_D – это “настоящий” Tsetup для триггера или это какая-то “приведенная” величина (используемая в Xilinx Timimg Analysis) почему при практически идентичной структуре эти параметры имеют различные значения – это отличие обусловлено тем, что используются SLICEM/SLICEL или чем-то другим?
  16. Вводная: Vivado, VU13P У всего проекта интерфейсный клок и клок вычислителя.Клок вычислителя (clk_core) в несколько раз выше интерфейсного (clk_ctrl). Сам проект содержит под сотню вычислителей,с которыми общаются на интерфейсном клоке, а сами вычислители молотят на клоке вычислителя. Для улучшения QoR закрепил каждый вычислитель на конретные pBlock (до этого результаты WNS по конфигу 1 и конфигу 2 или 3 существенно различались). Собственно все эксперименты по синтезу & PnR провожу в трёх конфигах: конфиг 1 флоу с одним вычислителем конфиг 2 флоу с одном SLR, полностью забитым вычислителями конфиг 3 кристалл полностью забит вычислителями Так вот - несмотря на то, что по факту ничего не поменялось (все вычислители зафикшены на pBlock) результаты в кейсе 2 и 3 деградируют по WNS. Появилось подозрение, что в этих кейсах вивадо пытается построить CLOCK ROOT от SLR/всего кристалла, что не является для меня необходимым. Все вычислительные клоки каждого вычислителя не обязаны быть синхронными между собой, а коммуницируют вычислители с центром управления на медленном интерфейсном клоке, хочется дать вивадо информацию о том, чтобы позволить строить клоковое дерево независимо внутри каждого вычислителя и соответствующим образом выбирать локалько CLOCK ROOT. Вопрос Поскольку рантайм адовый - не хочется тратить время на эксперименты, а описать послабления наверняка: 1. Правильно ли понимаю, что для начала надо поименовать все клоки разных вычислителей? Можно ли применить create_generated_clock к порту модуля? 2. Правильно ли будет потом применить между этими клоками set_clock_groups -asynchronous ? Как перенесёт вивадо эту команду с числом аргументов свыше сотни? 3. Либо надо писать set_clock_groups для пар каждого с каждым? Вот вроде как чутка похожий кейс: https://forums.xilinx.com/t5/Timing-Analysis/Asynchronous-inter-clock-paths-failed-to-meet-timing/td-p/761677
  17. Прошу помощи с GT Transceiver Wizard. Vivado 2018.3.1, проект на XC7K160TFFG676-2. Хочу добавить GTX transceivers для JESD204 ADC. Вроде бы делаю все как положено по UG476 и PG168, gtwizard_0.xci появляется, но с "паучком", указывающим на несовместимость, в списке модулей он тоже появляется как несовместимый. Что я упустил? Upd: Попробовал в проекте с ZynqMP US+ сгенерить трансиверы - та же фигня...
  18. Приветствую! Недавно пересел с PlanAhead на Vivado и как обычно полезли проблемы. При перезапуске симуляции в окне Vivado происходит вылет всей IDE без ошибок и/или каких-либо всплывающих окон, просто терминация процесса. ПК: Windows 10 x 64 Vivado 2018.3.1 x64/ симулятор встроенный, XSIM Проект написан полностью на SystemVerilog (3 регистра) и тестбенч тоже Есть какое-то решение более-менее адекватное или стоит подождать Vivado 2019?
  19. Приветствую! Хотелось бы собрать в одном месте информацию по техникам борьбы с неразводимостью проекта в Vivado, Есть конкретный кейс, большой проект на VU13P специфика которого в том, что ядра, которые реализованы пересекаются друг с другом (например одно ядро использует 90% из всех DSP на конкретном SLR, а другое - 80% RAM SLR, а третье - половину всех LUT SLR). Репорт о роутинге: степень утилизации: Собственно репорт рекомендует попробовать: report_design_analysis -congestion report_design_analysis -complexity и штудировать UG906 report_design_analysis -complexity: report_design_analysis -congestion: Какие выводы из этого всего напрашиваются: 1. Отключение LUT combining (если допустимо) 2. Использование ограничений по -max_fanout 3. opt_design -directive ExploreArea 4. place_design -directive AltSpreadLogic_medium или place_design -directive AltSpreadLogic_high 5. route_design -directive AlternateCLBRouting 6. phys_opt_design -directive AggressiveExplore (под вопросом) 7. Понижение частоты дизайна (если возможно) Итого, с помощью некоторых из приведенных способов удалось число пересечений свести от восьми к двум, поэтому интересно дополнить этот список, чтобы продолжить эксперименты. что еще можно попробовать? ------------------------ upd: 8. Синтезировать с оверконстрейном по частоте и ретаймингом (но поскольку это не ASIC, то работает только в определенном диапазоне частот), а разводить на фактической частоте.
  20. Здравствуйте. Пришло время запускать разные стратегии. В ISE было просто. Вызвал из GUI, нажал run и готово. А как дело обстоит в Vivado? Если я правильно понял в процессе поиска, то в ней такой приятной фичи нету. Неужели, для каждой стратегии в implement необходимо создавать свой отдельный проект? Или я ошибаюсь. Спасибо.
  21. Приветствую!.. По теме были изучены следующие материалы: https://www.xilinx.com/content/dam/xilinx/support/documentation/sw_manuals/xilinx2018_3/ug907-vivado-power-analysis-optimization.pdf https://www.xilinx.com/content/dam/xilinx/support/documentation/sw_manuals/xilinx2018_3/ug997-vivado-power-analysis-optimization-tutorial.pdf На основании которых создан tcl-скрипт из следующей последовательности: read_edif link_design read_saif set_operating_conditions ... report_power На этом этапе выяснил, что саиф у меня неправильный и правильный саиф - это тот, который пишется по нетлисту (ок, как появится новый - перезапущу, ибо новый саиф по нетлисту с обеда пишется всё не запишется). На что обратил внимание особенности работы report_power в старом SAIF: были аннотированы только клок, входы и выходы, дале он пытался сделать Activity Propagation, но по иерархическому репорту по потреблению, видно было что по какой-то причине этого не получилось, лишь финальный модуль конвейера (с которого собственно снимается выход) показал какое-то аномально-высокое потребление. Ok, пока новый SAIF пишется решил поиграться с set_switching_activity, чтобы хоть какие-то начальные результаты были, т.е. вместо read_saif делаю магические последовательности из set_switching_activity. Соответственно, report_power бодро рапортует о том, что честно делает Running Vector-less Activity Propagation... Сначала я подошёл творчески, описал все входы максимально приближенно к реальной картине мира, но затем заметил, что чтобы я не менял - получаю абсолютно одинаковую цифру потребления, в итоге это было протестировано двумя краевыми случаями (шина din[] - единственный вход 512бит, ресета нету): worst_case: set_switching_activity -default_static_probability 0.5 -default_toggle_rate 0 set_switching_activity -static_probability 0.5 -toggle_rate 100 [get_ports din[*]] best_case: set_switching_activity -default_static_probability 0.5 -default_toggle_rate 0 set_switching_activity -static_probability 0.5 -toggle_rate 0 [get_ports din[*]] Вопросы: Почему в случае с аннотированными входами-выходами report_power безобразно пропагирует активность? ЧЯДН? Почему цифры потребления неизменны для абсолютно разных set_switching_activity? ЧЯДН? Протестировано на Вивадо 2018.1 и 2018.3
  22. Приветствую! Появилась необходимость работы с US+ с несколькими кристаллами (3...4 SLRs) Для уменьшения рантайма P&R да и в целом, чтобы помочь вивадо повысить QoR хочу вручную назначить по SLR где какой блок должен лежать (ранее не доводилось работать с SLR), в связи с чем появились несколько вопросов, но перед этим пару слов о самом дизайне: дизайн представляет собой соединение в единый datapath (выход одного модуля подаётся на вход другого моделя и так далее по цепочке) достаточно крупных модулей (~200k LUT), причем в некоторых модулях (назовём его модуль_с_bigDSP) может быть высокое использование независимых примитивов (например ~80% всех имеющихся на кристалле DSP48). частоты > 400 МГц. Дизайн использует один тактовый домен, используется одно направление передачи данных по цепочке модулей (datapath без какого-либо handshake). Вопросы: ----------------------------------------- 1. PBlock: поскольку разные PBlock'и не могут содержать одни и теже SLICE (и другие ресурсы), то непонятно как сделать следующий финт ушами: Вариант А: Допустим для первого приближения было бы достаточно просто указывать на каком SLR располагаться какому модулю (без нарезки конкретных регионов внутри SLR), а там бы вивадо сам бы расплейсил как ему удобно. притом модуль_с_bigDSP мы никакак не ограничиваем прявязками, чтобы он рассредоточился по всему кристаллу Вариант Б: Мы жёстко привязываем модули к конкретным PBlock внутри SLR, притом модуль_с_bigDSP вручную разрезаем на равные числу SLR части для использования всех имеющихся ресурсов DSP48, делаем новым частям модуль_с_bigDSP также PBlock с распределением по всей площади конкретных SLR Вариант В: Жёстко привязываем модули к конкретным PBlock внутри SLR, притом модуль_с_bigDSP не привязан ни к одному PBlock и будет заплейсен автоматом поверх уже имеющихся PBlock (критерий для плейсмента - наличие достаточного числа необходимых ресурсов DSP48. В этом варианте упор делается на то, что плейсер вивадо сам знает "как лучше" ( в 1ю очередь с т.з. времянок) и создавать ему искусственные ограничения, разрезая руками модуль_с_bigDSP не совсем правильно. PS: знаю что есть возможность создавать PBlockи из независимых примитивов вроде DSP48, но рядом с DSP48 нужна логика, иначе тайминги будет свести нереально из-за длины цепей ----------------------------------------- 2. Продолжение пп.1: осуществимо ли вышеописанное, если всю имплементацию разбить на 2 прохода: 1й: синтез модулей out-of-context с нужной привязкой по PBlock 2й: синтез/P&R топа с (частично) перекрывающимися PBlock ? ----------------------------------------- 3. Laguna: гайд для частот свыше 250МГц требует вставки между разными SLR трех стадий регистров: один на передающей стороне, второй - как часть передатчика (внутри лагуны) и третий уже на другом SLR для приёма сигнала через SSI: мне было бы удобнее реализовать все эти три стадии внутри модуля (на выходе), но если модуль будет обконстрейнен на конкретный PBlock - сможет ли вивадо "вытащить" за границы этого PBlock регистры для лагуны и для следующего SLR либо вивадо не поймёт зачем я их запихал в модуль и будет жестко выполнять гайд по плейсменту внутри указанного PBlock?
  23. Всем доброго времени суток. Есть такая проблема с расположением файлов для проекта Vivado. В моих проектах каталог src отделён от каталога где лежит проект Vivado. Это позволяет его легко подключить под систему контроля версий. Но при таком подходе есть проблема с IP Core. Файлы xci лежат каждый в своём каталоге, они подключены под систему контроля версий, но Vivado при своей работе начинает в этих каталогах работать. И там получается очень много файлов, что неудобно. Собственно вопрос - существует ли возможность указать Vivado что бы она использовала другой рабочий каталог для IP Core ?
  24. Vivado после синтеза/имплемента показывает окошко с опциями типа: Открыть синтезированный/имлементированный дизайн Показать репорты Что-то ещё (точно не помню)… И checkbox: «Запомнить выбранную опцию и больше не показывать это окно» Допустим выбрали опцию «Показать репорты» и запомнили этот выбор (галочку в checkbox). Больше окошко напоминание не показывается. Потом, появилась необходимость изменить на другую опцию (скажем «Открыть синтезированный дизайн»). Т.к. окно больше не показывается, то в нём этого сделать не можем. А где ещё эту настройку поменять? Перерыл GUI менюшки самого Vivado – вроде не нашлось таких опций. Может знает кто, в каких недрах (конфигурационный файл, реестр или ещё где) эти настройки хранятся, чтобы хи можно было бы изменить? Или может есть какие Tcl команды для чтения/изменения этих настроек.
  25. Всем привет! Столкнулся со следующей проблемой: Vivado выдаёт предупреждения о том, что не может найти pins, cells, nets, прописанные в констрейнах, хотя оные объекты вроде на месте - это легко проверяется хоть через просмотр нетлиста, хоть через схематик, хоть через Tcl консоль, выдавая туда команды get_pins/get_cells/get_nets - ровно те, которые прописаны в констрейнах. Всё находится, всё на месте. Но при запуске, например, Synthesis, в окне Messages вижу: Интриги добавляет ещё то обстоятельство, что аналогичный констрейн на другой объект не вызывает такого поведения - там всё хорошо. Вот оба констрейна: create_generated_clock -name pcie_user_clk [get_pins pcie_port/pipe_clock_i/mmcm_i/CLKOUT2] create_generated_clock -name dpc_clk [get_pins dpc_clk_gen/inst/plle2_adv_inst/CLKOUT0] Это два простых констрейна для переименования клоков. Разница между ними в том, что первый относится к MMCM, находящейся внутри корки, а второй - к инстансу в проекте. Сам объект на месте (как уже выше указал), более того, по результату вижу, что клок-то таки переименовался (имеет указанное в констрейне имя). Вот оно на схеме (пин помечен маркером): В общем, заподозревал, что что-то тут, возможно, с порядком обработки данных - такое впечатление, что констрейн прикладывается в момент, когда ещё нетлист не готов и поэтому не находит объект (а в случае первого констрейна находит потому, что там в проект подтаскивается корка, синтезированная OOC, т.е. уже с нетлистом). Но если так, то как это разрулить? Никаких средств не нашёл, гугление тоже не помогло. Из-за этой же фигни не удаётся использовать waiver'ы - подобная ругань, что нет объектов (а они есть в результирующем нетлисте). В общем, обращаюсь к коллективному разуму и опыту.