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истемный уровень проектирования
    • Вопросы системного уровня проектирования
    • Математика и Физика
    • Операционные системы
    • Документация
    • Разработка цифровых, аналоговых, аналого-цифровых ИС
    • Электробезопасность и ЭМС
    • Управление проектами
  • Программируемая логика ПЛИС (FPGA,CPLD, PLD)
    • Среды разработки - обсуждаем САПРы
    • Работаем с ПЛИС, области применения, выбор
    • Языки проектирования на ПЛИС (FPGA)
    • Системы на ПЛИС - System on a Programmable Chip (SoPC)
  • Цифровая обработка сигналов - ЦОС (DSP)
    • Сигнальные процессоры и их программирование - DSP
    • Алгоритмы ЦОС (DSP)
  • Микроконтроллеры (MCs)
    • Cредства разработки для МК
    • ARM
    • AVR
    • MSP430
    • Все остальные микроконтроллеры
    • Отладочные платы
  • Печатные платы (PCB)
    • Разрабатываем ПП в САПР - PCB development
    • Работаем с трассировкой
    • Изготовление ПП - PCB manufacturing
  • Сборка РЭУ
    • Пайка, монтаж, отладка, ремонт
    • Корпуса
    • Вопросы надежности и испытаний
  • Аналоговая и цифровая техника, прикладная электроника
    • Вопросы аналоговой техники
    • Цифровые схемы, высокоскоростные ЦС
    • Rf & Microwave Design
    • Метрология, датчики, измерительная техника
    • АВТО электроника
    • Умный дом
    • 3D печать
    • Робототехника
  • Силовая Электроника - Power Electronics
    • Силовая Преобразовательная Техника
    • Обратная Связь, Стабилизация, Регулирование, Компенсация
    • Первичные и Вторичные Химические Источники Питания
    • Высоковольтные Устройства - High-Voltage
    • Электрические машины, Электропривод и Управление
    • Индукционный Нагрев - Induction Heating
    • Системы Охлаждения, Тепловой Расчет – Cooling Systems
    • Моделирование и Анализ Силовых Устройств – Power Supply Simulation
    • Компоненты Силовой Электроники - Parts for Power Supply Design
  • Интерфейсы
    • Форумы по интерфейсам
  • Поставщики компонентов для электроники
    • Поставщики всего остального
    • Компоненты
  • Майнеры криптовалют и их разработка, BitCoin, LightCoin, Dash, Zcash, Эфир
    • Обсуждение Майнеров, их поставки и производства
  • Дополнительные разделы - Additional sections
    • Встречи и поздравления
    • Ищу работу
    • Предлагаю работу
    • Kуплю
    • Продам
    • Объявления пользователей
    • Общение заказчиков и потребителей электронных разработок

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+


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

Found 17 results

  1. Сборка софт процессора MicroBlaze от Xilinx на русском в пошаговом режиме с огромным количеством картинок в нескольких частях: Разработка процессорной системы на базе софт-процессора MicroBlaze в среде Xilinx Vivado IDE/HLx. Часть 1. Разработка процессорной системы на базе софт-процессора MicroBlaze в среде Xilinx Vivado IDE/HLx. Часть 2. Программирование загрузочной FLASH для запуска MicroBlaze Подключение подсистемы памяти к MicroBlaze (MIG 7 Series)
  2. Доброго времени суток, уважаемые форумчане. Балуюсь с ядром ПФ в 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
  3. Имеются две практически идентичные реализации одного и того же проекта. Ниже приведены две таблицы с характеристиками 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 или чем-то другим?
  4. Вводная: 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
  5. Прошу помощи с GT Transceiver Wizard. Vivado 2018.3.1, проект на XC7K160TFFG676-2. Хочу добавить GTX transceivers для JESD204 ADC. Вроде бы делаю все как положено по UG476 и PG168, gtwizard_0.xci появляется, но с "паучком", указывающим на несовместимость, в списке модулей он тоже появляется как несовместимый. Что я упустил? Upd: Попробовал в проекте с ZynqMP US+ сгенерить трансиверы - та же фигня...
  6. Приветствую! Недавно пересел с PlanAhead на Vivado и как обычно полезли проблемы. При перезапуске симуляции в окне Vivado происходит вылет всей IDE без ошибок и/или каких-либо всплывающих окон, просто терминация процесса. ПК: Windows 10 x 64 Vivado 2018.3.1 x64/ симулятор встроенный, XSIM Проект написан полностью на SystemVerilog (3 регистра) и тестбенч тоже Есть какое-то решение более-менее адекватное или стоит подождать Vivado 2019?
  7. Приветствую! Хотелось бы собрать в одном месте информацию по техникам борьбы с неразводимостью проекта в 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, то работает только в определенном диапазоне частот), а разводить на фактической частоте.
  8. Здравствуйте. Пришло время запускать разные стратегии. В ISE было просто. Вызвал из GUI, нажал run и готово. А как дело обстоит в Vivado? Если я правильно понял в процессе поиска, то в ней такой приятной фичи нету. Неужели, для каждой стратегии в implement необходимо создавать свой отдельный проект? Или я ошибаюсь. Спасибо.
  9. Приветствую!.. По теме были изучены следующие материалы: 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
  10. Приветствую! Появилась необходимость работы с 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?
  11. Всем доброго времени суток. Есть такая проблема с расположением файлов для проекта Vivado. В моих проектах каталог src отделён от каталога где лежит проект Vivado. Это позволяет его легко подключить под систему контроля версий. Но при таком подходе есть проблема с IP Core. Файлы xci лежат каждый в своём каталоге, они подключены под систему контроля версий, но Vivado при своей работе начинает в этих каталогах работать. И там получается очень много файлов, что неудобно. Собственно вопрос - существует ли возможность указать Vivado что бы она использовала другой рабочий каталог для IP Core ?
  12. Vivado после синтеза/имплемента показывает окошко с опциями типа: Открыть синтезированный/имлементированный дизайн Показать репорты Что-то ещё (точно не помню)… И checkbox: «Запомнить выбранную опцию и больше не показывать это окно» Допустим выбрали опцию «Показать репорты» и запомнили этот выбор (галочку в checkbox). Больше окошко напоминание не показывается. Потом, появилась необходимость изменить на другую опцию (скажем «Открыть синтезированный дизайн»). Т.к. окно больше не показывается, то в нём этого сделать не можем. А где ещё эту настройку поменять? Перерыл GUI менюшки самого Vivado – вроде не нашлось таких опций. Может знает кто, в каких недрах (конфигурационный файл, реестр или ещё где) эти настройки хранятся, чтобы хи можно было бы изменить? Или может есть какие Tcl команды для чтения/изменения этих настроек.
  13. Всем привет! Столкнулся со следующей проблемой: 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'ы - подобная ругань, что нет объектов (а они есть в результирующем нетлисте). В общем, обращаюсь к коллективному разуму и опыту.
  14. Всем привет! Вот есть такой инструмент в Vivado как Block Diagram Editor, что делает в целом понятно - позволяет организовывать межсоединения между блоками/модулями/ядрами в наглядной графической форме. Мне как-то до сих пор подобные инструменты не очень пригождались - помнится, ещё на Active-HDL пробовал топ делать с помощью такой вот схемы (блок диаграммы), поначалу понравилось, но потом энтузиазм поугас - как-то многовато телодвижений лишних (чуть что поправить - эн мелких правок в разных местах), а главное, когда диаграмма становится большой, то уже линии соединений скорее мешают, чем помогают, и проще их (соединения) не таскать шинами/проводниками, а оформлять метками, что уже в значительной степени нивелирует красоту и эффективность схемного представления... А потом я просто научился инстансы модулей оформлять так, что читабельность практически не уступает вот такому схемному с метками. Но вот вижу, что Xilinx в своих примерах и design flow активно использует именно BD. Более того, обнаружил, что некоторые корки просто недоступны в виде отдельного ядра - например, AXI Interconnect инстанцируется только в BD, и отдельным ядром OOC его сделать нельзя, хотя его составные компоненты - Crossbar, Clock Converter, Data Width Converter и прочие, - вполне можно получить виде отдельных ядер и подключить их к проекту как обычно. Кроме того, насколько знаю, тяжёлые ядра типа Microblaze или Zynq подключаются к проекту тоже только через BD. И вот возникает вопрос: насколько это нужный и полезный инструмент в повседневной работе? Попытаюсь изложить в меру своего понимания темы плюсы и минусы BD'шного подхода. Плюсы: Наглядность межсоединений. Хотя при росте схемы она резко падает. Может немного спасти ведение иерархии - чтобы на каждом уровне было вменяемое количество "кубиков" и их связей, но и тут есть засада - при большом проекте возрастает количество уровней иерархии, что затрудняет навигацию и вообще мысленный охват проекта. Возможность лёгкого манипулирования большим количеством портов, группируя их в шины - как, например, сигналы AXI шины. Средства автоматизации - редактор BD автоматически отслеживает неподключенные порты и устанавливает на них значения по умолчанию. Минусы: Некоторое усложнение проекта - ещё один уровень выше HDL. Не все типы файлов поддерживаются - например, .sv исходники не поддерживаются, только .v, .vhd, т.е. если у меня код на SystemVerilog, то для того, чтобы из модуля родить "кубик" для BD, мне нужно сделать специальный файл-обёртку вокруг исходного модуля. Хуже переносимость. Если HDL сорцы можно напрямую передавать в другой проект на синтез и симуляцию, то с файлом диаграммы уже не так просто - сам этот файл вне среды САПР Vivado никому не нужен, а если сгенерить по нему исходник, то он получается в не очень читабельном и сопровождабельном руками виде. Для меня в первую очередь значимым является способность легко и просто работать с портами. И вот если бы редактор BD умел извлекать из SV интерфейсов сигналы (а лучше бы просто использовал их как есть), то это было бы очень круто! Но идея с файлом-обёрткой на Verilog как-то не очень греет. Для сугубо вериложных файлов BD, наверное, и даёт заметный профит - автоматом подхватывает все сигналы модуля и всё хорошо, но в SV есть замечательная штука - интерфейсы, которые позволяют свести количество портов модуля к минимуму, сделать использование сигналов портов простым и безопасным, а кроме этого ещё и местами нетривиальную логику завернуть внутри интерфейса. И вот тут-то пожалуй главный профит BD нивелируется и превращается балласт (необходимость городить врапперы вокруг модуля и руками мапить сигналы интерфейсов на порты модуля-обёртки). Вопросы внешнего вида (наглядности, лёгкости восприятия и удобства модификации) на HDL вполне решаются стилем форматирования экземпляров модулей, а поддержка интерфейсов позволяет легко получить компактные описания. В общем, пока не понял хорошенько, в чём профит BD, какие у него есть киллер-фичи. Но ведь широко используют, и это, наверное, неспроста. Прошу высказываться по теме - что сказано верно, а что нет, что-то упущено, а что-то наоборот "в точку". Кто пользуется BD, для каких проектов (всегда, никогда, только для больших и т.д.), на каких уровнях иерархии (только топ или какие-то внутренние куски иерархии) и вообще интересны мнения и оценки имеющих реальный опыт работы с этим.
  15. Симулирую FIFO корку Vivado и что-то никак не удаётся получить ожидаемого поведения. Не совпадают результаты симуляции с тем, что описано в даташите (в частости latency выходных сигналов), и с тем, что ожидаешь увидеть. Когда много лет назад приходилось работать с FIFO ядром в ISE, не припомню таких трудностей. Совсем запутался, надеюсь коллективный разум поможет. Итак вводные: Vivado v2017.4 (64-bit), корка fifo_generator_v13_2_1. Генерим простейшее FIFO: Native (без AXI), Common Clock Block-RAM, 8x16, Standard Read Mode (т.е. не First Word Fall Through), без выходных регистров: Как видим, ожидаемая задержка чтения (данных) должна быть 1 такт. А задержка остальных выходных сигналов указывается в даташите (“Ch. 3: Designing with the Core” -> Latency -> Non-Built-in FIFOs: Common Clock and Standard Read Mode Implementations) : Т.е. вроде все остальные выходные сигналы в домене чтения (кроме prog_empty) должны иметь задержу 0 тактов. Хотя лично для меня это звучит странно, т.к. в моём понимании это сигналы «синхронные» (т.е. выходят с неких внутренних регистров ядра), и должны быть задержаны хотя бы на 1 такт. И эти догадки подтверждаются синтезом корки (на схематике выходные «статусные» выходят с регистров. В моём понимании это задержка минимум в 1 такт (или больше, в зависимости от общего количества регистров в каскаде). Уже это вызывает вопросы. Xilinx в даташите на FIFO описывает, как определяется Latency: Тут стоит сказать, что ИМХО такое изображение диаграмм (т.е. не как в function simulation, («синхронное, такт-в-такт»), а как в timing simulation (более «реалистичное» с учётом таких задержек, как setup/hold)) не только не помогает понять логику работы для функциональной симуляции, но скорее больше мешает, ухудшает восприятие и приводит к потенциальным ошибкам. По мне так эта диаграмма больше похожа на latency=1, а не 0. Так вот генерим в Vivado тестбенч для нашего простенького FIFO (правым кликом на IP-Core –> “Open IP Example Design…”). В сгенеренном Vivado тестбенче «имитируются» вышеупомянутые timing задержки, т.е на VHDL используются конструкции вида “… after XX ns”. Таким способом «задержаны» синхронный сброс (srst), входные сигналы записи/чтения (wr_en/rd_en) и входные данные записи (din). В данном случае период клока симуляции 200ns, задержки after = 50ns. И что же мы имеем в симуляции. Вот так выглядит запись в FIFO: А так чтение из FIFO: Сначала я долго не мог понять, что за 0.1ns на выходных сигналах (диаграмма чтения, 3-ий курсор, сигналы empty/data_count обновляются при T=16300.1ns). Покопавшись в даташите и инете, вроде пришёл к выводу, что так явно «имитируются» delta delay симуляции (и/или задержки синхронных сигналов в железе). В даташите (Ch. 4: Design Flow Steps -> Simulation -> Behavioral Model): И на форуме Xilinx: тыц (100 ps delay for Block Memory Generator 6.3) и тыц (BRAM output delay). Т.е. вроде эти 100ps должны быть «более наглядными» (если сравнивать с delta delay, которая в симуляции стремится к нулю), показывая, что «in hardware, it should never assume that synchronous data is available instantaneously with the active clock edge». Переварив всё это, я прихожу к выводу, что: На диаграмме записи задержка сигналов статуса чтения (empty, data_count) по отношению к wr_en вроде как 0 тактов (соответствует значениям в таблице 3-14). Хотя (как уже писалось раньше), эти сигналы вроде как выходят с регистров, и должны иметь задержку минимум 1 такт. На диаграмме чтения задержка сигнала данных (dout) по отношению к сигналу rd_en мне непонятна (получается ещё меньше, чем 0 тактов, т.к. нет 100ps, а исходя из вышеупомянутых параметров FIFO latency=1). При этом если сконфигурировать FIFO с выходным регистром (Embedded или Fabric в поле Output Register), то ожидаемая задержка latency=2 такта, а на диаграмме выход dout «свдигается» на всё те же 100ps (т.е. выравнивается со «статусными» выходными сигналами, что вроде как по описанию Xilinx соответствует задержке 0 тактов, а не 2). Но больше всего мне непонятно, как такие выходные сигналы (с задержкой на 100ps) «стыковать» с остальной частью логики, которая описана естественно без такого рода задержек, как просто «функциональная» схема или «синхронный» дизайн на логическом уровне. Т.е. елсли в проекте стыковать это FIFO ядро, на уровне функциональной симуляции, его входные управляющие сигналы (wr_en, wr_data) не будут иметь «имитируемую» задержку 'after XX ns'. Т.е к примеру диаграмма записи будет выглядеть так: Получается, что с точки зрения остальной «функциональной логики», выходные статусные сигналы empty и data_count будут иметь latency=2. Т.е. любой синхронный процесс «защёлкнет» значение empty/data_count после двух клоков от сигнала wr_en (в момент T=16500ns), т.к. после одного клока (T=16300ns) сигнал ещё не обновился из-за этих 100ps. В то же время у асинхронных процессов эти 100ps будут вызывать glitch-и, и тоже приводить к ошибкам. В конечном итоге, основые вопросы такие. Как работать в «функциональной» симуляции с таким ядром? И почему выходные задержки latency не соответствуют значениям указанным в datasheet? Понимаю, что решение должно быть, но мне оно пока не ясно. Извиняюсь, что так много букв получилось, но не знаю как всё это описать покороче. И это лишь простейший вариант конфигурации FIFO. А что уж будет, если надо использовать скажем разные клоковые домены, в режиме First-Word-Fall-Through, разные Aspect Ratios и т.п.
  16. Всем привет! При сборке проекта всплыл набор предупреждений вида (подформатировал, ибо в оригинале совсем нечитабельно): Суть недовольства САПР в следующем: инстанс корки PCIe содержит внутри блочную память, на входы блоков которой приходит сигнал из недр другой корки - сигнал empty прокинут (через логику) из FIFO, при этом флоп, с которого выходит этот empty, имеет тип FDPE, что в переводе на русский означает, что этот флоп типа "D Flip-Flop with Clock Enable and Asynchronous Preset", и это сильно не нравится синтезатору, о чём он сообщает. Формально он прав - нехорошо, когда асинхронный сброс (пресет) используется - вдруг глитч на сигнале сброса... со всеми вытекающими. Но смотрю, откуда приходит сигнал сброса (пресета), а он приходит с другого флопа, который имеет тип FDRE (D Flip-Flop with Clock Enable and Synchronous Reset), т.е. никаких глитчей быть не может - флоп строго синхронен общему клоку данного домена. Вопрос: а чего он тогда ругается-то? Или у него просто не хватает глубины анализа? И второй вопрос: как быть? Оставить, как есть? Вроде оно безопасно, но неприятный варнинг портит настроение. Или всё же есть способ забороть корректно? P.S. Корка FIFO по умолчанию имеет настройку параметра Reset Type как Asynchronous. Попытался изменить на синхронный тип, появились два раздельных входа ресета (для обоих тактовых доменов - FIFO сконфигурировано с независимыми клоками), но картина не поменялась. Внутри корки флоп сигнала empty по-прежнему имеет тип FDPE, и варнинг, естественно, не уходит. Так понял, что тип сигнала сброса не влияет на реализацию отдельных логических частей, а влияет только на поведение корки в смысле внешнего ресета.
  17. Добрый день! Необходимо сконфигурировать с помощью zynq ацп и цап, имеющий только 3 - х проводный spi. Axi-quad SPI работает только в 4-х проводном. Может кто сталкивался, как это можно сделать? Спасибо.