Search the Community

Москва, Очаковское шоссе, 34 зп от 120 до 150 тыс.руб. Связаться: 8-968-526-19-31 (Наталья), 8-965-336-65-96 (Николай Николаевич), orlova@form.ru Обязанности: Разработка проектов ПЛИС ALTERA/XILINX в составе сложных систем Тестирование и отладка проектов ПЛИС Разработка документации на проекты ПЛИС Требования: Высшее техническое образование в области радиотехники/радиоэлектроники Отличные навыки разработки, отладки и верификации проектов на ПЛИС ALTERA и/или XILINX Устойчивые навыки работы со средствами симуляции и средствами отладки проектов, лабораторными приборами и аппаратурой Уверенные знания языков Verilog/VHDL, высокоскоростных интерфейсов DDR, PCI Express, 1G/10G Ethernet и т.п. Иностранный язык: Английский чтение – перевод технических документов по специальности Будет преимуществом: Навыки разработки ЧТЗ и ПМИ на разрабатываемый проект, исходя из анализа ЧТЗ на модуль и ТЗ на изделие Навыки системного мышления, опыт декомпозиции задач по разработке проектов ПЛИС и предварительной оценки трудоемкости Условия: Работа в коллективе профессиональных разработчиков, нацеленных на результат. ФОРМ более 20 лет обеспечивает внутренний рынок электроники своей инновационной высокотехнологичной продукцией и представляет свои результаты на зарубежном рынке Предоставляются возможности для профессионального и карьерного роста в направлениях: Схемотехника, Системотехника, Программирование, управление продуктами и проектами НИОКР Оформление и работа - в полном соответствии с ТК РФ Вы будете обеспечены всеми необходимыми техническими средствами и современным рабочим местом для эффективной работы Конкурентная белая заработная плата, Размер заработной платы обсуждается с успешным кандидатом по результатам собеседования Работа на территории группы ФОРМ в БЦ West Park c доставкой до и от метро на корпоративном автобусе Скользящий рабочий график - начало рабочего дня с 7:30 до 10:00 Задачи, которые предстоит решать, настолько амбициозны, насколько они должны быть для конкуренции на зарубежном рынке средств измерений для электроники

Искал домой подходящий роутер под Linux, как вариант, рассматривал тонкие клиенты. Наткнулся на Авито на нечто, называемое DZ22-2 и DZ19-2 (производства Fujitsu). Это мониторы, со встроенным тонким клиентом. Тонкий клиент собран на Spartan-6. Это чудо стоит 1500 руб. Ссылку не привожу - по модели легко найти. Не могу оценить, насколько это перспективное приобретение, так как сам занимаюсь Альтерой. Тем не менее, вдруг кому пригодится.

Xilinx, Spartan6, Synplify, ISE. Я использую библиотечный модуль ICAP, который нужен для управления прошивками в конф флешке. Его инстанцирование выглядит так: ICAP_SPARTAN6 ICAP_SPARTAN6 ( .CLK ( CLK ), // <- .CE ( icap_c ), // <- .WRITE ( icap_c ), // <- .BUSY ( ), // -> .I ( icap_i ), // <- [15:0] .O ( ));// -> [15:0] Оптимизатор в Synplify удаляет нахрен этот ICAP, потому что в инстансе не используются выходы. В реальности этот ICAP присоединен к загрузочной флешке и еще к каким то кишкам внутри контроллера загрузки fpga, и очень нужен. Но синтезатор это не видит, дурак он.. Мне приходится использовать выход BUSY, тянуть его по проекту и подключать куда то, где он почти не будет мешать и не сможет оптимизироваться в никуда. Должно же быть более изящное решение! Я знаю, есть директивы /* synthesis syn_keep = 1 syn_preserve = 1*/. Я уже делал так, не помогло: ICAP_SPARTAN6/* synthesis syn_keep = 1 syn_preserve = 1*/ ICAP_SPARTAN6/* synthesis syn_keep = 1 syn_preserve = 1*/ ( .CLK ( CLK ), // <- .CE ( icap_c ), // <- .WRITE ( icap_c ), // <- .BUSY ( ), // -> .I ( icap_i ), // <- [15:0] .O ( ));// -> [15:0] Что делать? Спасите.

Всем привет. Мы проводим стримы по FPGA/ПЛИС тематике на твиче по адресу twitch.tv/fpgasystems Обычно, это среда и суббота в 20:00. Записи прошедших стримов лежат на youtube: youtube.com/c/fpgasystems Ждём Вас на стриме. Анонсы предстоящих эфиров в группе в телеграм @fpgasystems (https://t.me/fpgasystems) и VK и FB

На вебинаре вы познакомитесь с новой средой разработки Vitis, в которой реализована парадигма высокоуровневого проектирования, и с двумя новыми аппаратными платформами от Xilinx – Versal и Alveo, для которых разработка в среде Vitis наиболее эффективна. Вебинар предназначен как для разработчиков для ПЛИС и СнК, желающих повысить свою продуктивность с помощью средств высокоуровневого проектирования, так и для программистов, ищущих возможности повышения производительности своих компьютерных систем с помощью адаптируемых аппаратных ускорителей Xilinx Alveo. Вебинар состоится 31 марта в 14:00 (мск). Повтор вебинара 2 апреля в 10:00 (мск). Участие в вебинаре бесплатное, после предварительной регистрации. Регистрация на вебинар

Nexys 3 Spartan-6 Производитель: DIGILENT Микросхема: Xilinx Spartan-6 XC6LX16-CS324 Ссылка на подробную информацию: https://store.digilentinc.com/nexys-3-spartan-6-fpga-trainer-board-limited-time-see-nexys4-ddr/ В наличии есть 5 штук. Все платы находятся в штатных пластиковых коробках. Цена: 8000 руб ------------------------------------------------------------------------------------------- Spartan-6 FPGA SP605 Evaluation Kit Производитель: Xilinx Микросхема: Spartan-6 XC6SLX45T-FGG484-3C Ссылка на подробную информацию: https://www.xilinx.com/products/boards-and-kits/ek-s6-sp605-g.html В наличии есть 1 штука в штатной коробке. Цена: 18000 руб ------------------------------------------------------------------------------------------- Virtex-6 FPGA ML605 evaluation kit Производитель: Xilinx Микросхема: Virtex-6 XC6VLX240T-1FFG1156 Ссылка: https://www.xilinx.com/products/boards-and-kits/ek-v6-ml605-g.html В наличии есть 1 штука в штатной коробке. Цена: 22000 руб ------------------------------------------------------------------------------------------- Платы почти не использовались - лежат без дела. Пересылать почтой России их не хотелось бы, но в Москву и другие близлежащие города можно будет передать. Доп. фото:

Дооброго времени суток. Читал я тут соседние темы на форуме и вспомнилась старая задача для проекта на Zynq. А именно как можно увеличить адресное пространство (в Address Editor BD) с одного гигабайта до хотя бы двух. В спецификации указано что из 32х бит адресного пространства 3 Гб зарезервировано под внутренние нужды ARM и только 1 Гб доступен для адрессации "периферии" в PL. Один из вариантов - это сделать переключатель по какому-то адресу и свитчить выходные адреса старшим/младшим виртуальным битом. В таком случае проблема вылазит в конфигурации карты и сложность в обратоном чтении от устройств (их около 2х десятков). Второй вариант - подключить несколько устройств на одинаковые адреса, но управлять сигналом разрешения работы (нет необходимости работать паралельно). Проблема конфигурации карты остаётся ну и частичнаф сложность в реализации. Собственно какой вариант лучше/использовался юзерами. Или же есть ещё какой-то способ проще/лучше p.s. Раздумия над AXI передачей наводят на мысль, что собственно адреса "раздаёт" AXI Interconnect, при том, что вся остальная перифферия особо то ничего и не знает что и где лежит (отсюда и требование подключения одной связки master-slave). Насколько данная мысль правильная? Может есть какой-то способ "обмануть" или конверизировать адреса в Interconnect'е, тогда задача решится сама собой.

Добрый день, форумчане! Встал вопрос о внедрении системы контроля версий (Git) в процесс проектирования с использованием САПР Vivado. Немного покопавшись в этих самых интернетах, вычитал, что народ создает файловую структуру рядом с проектом, в которой хранятся исходники проекта (*.v, *.vhdl, *.xci, *.elf и прочее и прочее). Собственно, эту самую структуру и засовывают в СКВ. Далее вопрос: Как заполнить эту самую структуру перед коммитом? *Мысли в слух* Вариант 1. У меня есть отлаженный проект. И я ручками/не ручками (скриптами) из финальной версии проекта перетаскиваю в файловую структуру для СКВ все исходники. При этом в IDE исходники подключены из папки проекта. Коммитим. Когда вытаскиваем данный коммит (pull) из СКВ ручками/скриптами подсовываем в директорию проекта, затем собираем. Вариант 2. У меня есть неотлаженный проект. Я по мере допиливания проекта добавляю IP и исходники, затем ручками перетаскиваю во внешние папки и далее в IDE указываю расположение исходников во внешних папках. В финальной версии проекта перед коммитом все файлы уже на своих местах, т.е. в файловой структуре для СКВ. Коммитим. При вытаскивании из СКВ файлы исходников автоматически подменятся и останется только собрать проект. Вариант 3. Накатать скрипт, который из финальной версии проекта вытаскивает нужные исходники и генерирует скрипт, который на основании исходников создает проект с нуля (recreate). Все это добро коммитится. Вариант 4. Мыслю вообще не в том направлении.

Всем привет! Возникла проблема в конфигурации FPGA в режиме PCIE3.0 Tandem у отладочной платы KCU105. В проекте есть светодиод (led 0 на плате), который при второй стадии загрузки (по PCIE3.0) должен включатся. Порядок действий: Собираю проект design example. Констрейны для bitstream: После сборки генерирую MCS командой: Прошиваю конфигурационную память скриптом который есть в архиве program_spi.tcl Выключаю хост. Потом включаю. После загрузки вижу девайс: Читаю регисры с помощью mcap версия bitstream совпадает с ожидаемой. Прошиваю второй стадией: Поле прошивки ядро выдает сообщеие: После этого светодиод не горит, а mcap говорит: А если прошить FPGA по JTAG первой стадией, затем сделать reboot и прошить mcap воторой стадией, то светодиод горит и сообщения в ядре по irq нет. Данное IRQ принадлежит: Память конфигурационная память прошивается, через JTAG бластер по разъему J3. Версии: Vivado v2019.1 (64-bit) Хост в котором карточка Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux Утилиты MCAP взята отсюда https://www.xilinx.com/support/answers/64761.html Ревизия KCU105 C Версия pci-utils pciutils-3.3.1 пробовал и с 3.6.3 одинаковый результат. В чем может быть проблема? pcie3_ultrascale_0_ex.zip

Итак новая платформа с новыми возможностями и отсутствием вменяемых гайдов. Всё как обычно, но работать то нужно, отсюда возникает задача создать проект и залить его на Гит. Для одного компа всё вроде бы работает, но создаётся впечатление, что в объективных файлах проекта (bare metal) прописывается абсолютный путь ибо на других машинах уже ничего не рабоатет. Возможно кто-то использовал Vitis с Git'ом или знает как это делать. Буду благодарен за любую информацию от ссылок где кто-то как-то делал гайды или конкретную документацию (ug1400 не помог никапли). Создаётся впечатление, что как в Vivado придётся создавать tcl скрипты с организацией проекта и последующей генерацией структуры, а этого очень не хочется.

Всем привет! 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

Всем привет, подскажите пожалуйста, как правильно подключить ddr к microScale? Задача для многих простая, но боюсь что я подвис. Дело в том что проц удержеваеться в ресете при дэбаге в SDK. Использую отладку, но при создание проекта абстрагировался от нее и выбрал просто плисину. Vivado 2018.3 Artix 7 Constraint file: set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design] set_property BITSTREAM.CONFIG.UNUSEDPIN Pullup [current_design] set_property CFGBVS VCCO [current_design] set_property CONFIG_VOLTAGE 3.3 [current_design] set_property PACKAGE_PIN P6 [get_ports {reset}] set_property IOSTANDARD SSTL15 [get_ports {reset}] set_property PACKAGE_PIN U19 [get_ports {tx}] set_property IOSTANDARD LVCMOS18 [get_ports {tx}] set_property PACKAGE_PIN T19 [get_ports {rx}] set_property IOSTANDARD LVCMOS18 [get_ports {rx}]

Всем привет! Возможно, вопрос обсуждался, но мне найти не удалось. Суть в следующем. Есть проект, успешно собирается и даже работает. Но при синтезе возникают тонны предупреждений такого рода: WARNING: [Synth 8-3331] design <...> has unconnected port <...>. Выглядит угрожающе, но на деле по нетлисту (схематику) видно, что сигналы-то на месте, всё подключено. Анализ показывает, что почти все они относятся к сигналам интерфейсов. И похоже, что синтезатор ругается на сигналы модпортов интерфейса, которые не используется в том или ином модуле. Т.е. насколько понимаю, картина такая: есть интерфейс, у него есть модпорты m0, m1, s0, модпорт m0 подключается к модулю master0, модпорт m1 - к модулю master1, а модпорт s0 - к модулю slave0. Получается, что интерфейс прокинут во все модули, но часть сигналов, которые относятся к другим модпортам, естественно в данном конкретном модуле не подключена - например, в модуле master0 не подключены сигналы модпоротов m1 и s0. Получается, что ругань как бы не по делу. Собственно вопрос: как с этим бороться, т.к. подобные предупреждения выглядят неприятно?

Проходим туториалы по Zynq-7000 с платкой Minized. Есть как теоретическая часть, так и практическая. Лекции и простенькие лабораторные работы -- то что нужно для начала освоения системы-на-кристалле от Xilinx. Ссылка на плейлист: https://www.youtube.com/playlist?list=PLWMg96mLREOekNVh8-3U5JZv2NTCLMbP5

Всем привет! Прошу помощи. Кто-нибудь знает, как правильно пользоваться сигналами fc_* из ядра PCIe? Вообще суть проблемы такая. Имеется плата с Spartan 6 45T. Firmware предоставляет регистры для записи-чтения по инициативе процессора (как memory), через них задаётся, что делать. Потом firmware делает запросы к памяти (DMA). Я реализовал flow control по четвёртому методу DATA_FC из UG672. Значения Total_CplH и Total_CplD брал, как рекомендовано, из таблицы E-1 (для моего случая 32 и 256 соответственно), хотя там дальше говорится: In the case where infinite credits have been advertised to the Link Partner for a specific Credit pool, such as Completion Credits for Endpoints, the user application should use this value along with the methods described in Appendix E, Managing Receive-Buffer Space for Inbound Completions to avoid completion buffer overflow. И до поры, до времени всё работало замечательно, но вот я нарвался на то, что передача данных затыкается при работе с процессорным модулем ComExpress - запросы из FPGA MEMORY_READ ушли, а ответов на них не пришло. Подозреваю, что у этого модуля более суровые ограничения на число запросов в очереди. Решил посмотреть на то, какие значения выставляются на fc_ph, fc_pd, fc_nph, fc_npd, fc_cplh и fc_cpld для разных значений fc_sel в разные моменты времени. Должен сообщить, что значения эти выглядят странными и непонятными, причём, я не нашёл какого-то внятного user guide, чтобы там объяснялось, как этими сигналами правильно пользоваться для целей flow control. Например, для fc_sel=000 (Receive Credits Available Space) значения такие: fc_ph = 32, fc_pd = 211, fc_nph = 8, fc_npd = 8, fc_cplh = 40, fc_cpld = 211 (Крайне смущают очень маленькие значения для fc_nph и fc_npd.) для fc_sel=100 (Transmit Credits Available Space) значения такие: fc_ph = 12, fc_pd = 80, fc_nph = 12, fc_npd = 1, fc_cplh = 0x7F, fc_cpld = 0x7FF (в соответствии с таблицей 5-17 из UG672 значения 0x7F и 0x7FF обозначают Infinite credits available). Я правильно понимаю, что мне надо взять fc_nph = 8, fc_npd = 8 вместо 32 и 256 для Total_CplH и Total_CplD?

Сборка софт процессора MicroBlaze от Xilinx на русском в пошаговом режиме с огромным количеством картинок в нескольких частях: Разработка процессорной системы на базе софт-процессора MicroBlaze в среде Xilinx Vivado IDE/HLx. Часть 1. Разработка процессорной системы на базе софт-процессора MicroBlaze в среде Xilinx Vivado IDE/HLx. Часть 2. Программирование загрузочной FLASH для запуска MicroBlaze Подключение подсистемы памяти к MicroBlaze (MIG 7 Series)

Доброго времени суток, уважаемые форумчане. Балуюсь с ядром ПФ в 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

Продам отладочный комплект Artix-7 (AES-A7EV-7A50T-G). Новый, коробка не открывалась. Описание по ссылке: https://www.xilinx.com/products/boards-and-kits/1-4pilqh.html Цена: 20 000 руб. Территориально - Москва. Отправка почтой не проблема.

Взял за основу пример UDP обмена на плате Spartan 6. Используюя накопленный опыт, решил использовать струтуру в которой не нужно выравнивания (надеюсь ;-)) // структура короткого запроса typedef struct{ int cmd; // код команды/запроса int addr; // адрес обращения int data; // данные для записи/чтения unsigned int crc; }SHORT_CMD; Обрабатываю пакеты под отладчиком в плате. 1) Копирую нужную часть memcpy(&short_cmd, udp_packet, sizeof(SHORT_CMD)); 2) Подсчитываю контрольную суссу, она сходиться 3) По коду запроса вызываю функцию обработки В отладчике видно что поле data имеет значение 0xAA 4)Захожу в функцию Параметр data передается в функцию с перестановкой байт. addr, наверное тоже, но не видно так как он равен нулю. Настройки процессора следующие: Допустим можно попутать big/little endian. Почему компилятор корректно извлекает из структуры число, а передает его в функцию некорректно?

Приветствую! Недавно пересел с PlanAhead на Vivado и как обычно полезли проблемы. При перезапуске симуляции в окне Vivado происходит вылет всей IDE без ошибок и/или каких-либо всплывающих окон, просто терминация процесса. ПК: Windows 10 x 64 Vivado 2018.3.1 x64/ симулятор встроенный, XSIM Проект написан полностью на SystemVerilog (3 регистра) и тестбенч тоже Есть какое-то решение более-менее адекватное или стоит подождать Vivado 2019?

Добрый день, хочу поделится ссылкой на проект U-boot для платы ZedBoard Возможно будет полезно новичками которые хотят подробнее разобраться с загрузчиком или что-то подправить под себя. Проект позволяет собирать U-boot из исходников и так же запускать его из под SDK с точками останова как в режиме bare-metal. Все инструкции в репозитории + видеоинструкция. Если у кого получится повторить буду рад услышать ответ. Из особенностей для отладки пришлось закомментировать часть функций SPL, все комментарии добавленные мной начинаются с /* mollex: comment , количество небольшое. Ссылка на проет: https://github.com/mollex/workspace20154_uboot_dev

Есть готовые устройства на Xilinx Zinq 7010, надо как-то защитить прошивку от реверс инжиниринга, копируют пока ладно, пусть. без модификации плат. Желательно чтоб можно было стандартными имеющимися средствами обновить прошивку (уже есть это, линукс стоит, можно и u-boot обновить). Идеи - так как устройства IoT, на связи с нашими серверами, можно через защищенный канал что-то делать, например после обновления подгружать сгенерированную прошивку именно для этого чипа по защищенному каналу. Есть под них прошивка с U-BOOT, исходники. Прошивка должна будет загружаться как и сейчас для обновления по HTTP, а также иметь механизм возврата на старую (незащищенную) стандартную версию. Мы в Москве, возможна удалённая работа, образцы железяк дадим или организуем удалённый доступ. Сроки и бюджет обсуждаемы. может поможет https://www.xilinx.com/support/documentation/application_notes/xapp1226-protecting-info.pdf

Всем привет! Столкнулся со следующей проблемой: 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'ы - подобная ругань, что нет объектов (а они есть в результирующем нетлисте). В общем, обращаюсь к коллективному разуму и опыту.

Всем привет! Вот есть такой инструмент в 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, для каких проектов (всегда, никогда, только для больших и т.д.), на каких уровнях иерархии (только топ или какие-то внутренние куски иерархии) и вообще интересны мнения и оценки имеющих реальный опыт работы с этим.

Всем привет! При сборке проекта всплыл набор предупреждений вида (подформатировал, ибо в оригинале совсем нечитабельно): Суть недовольства САПР в следующем: инстанс корки 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, и варнинг, естественно, не уходит. Так понял, что тип сигнала сброса не влияет на реализацию отдельных логических частей, а влияет только на поведение корки в смысле внешнего ресета.