Jump to content

    

5EN5E

Участник
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

0 Обычный

Recent Profile Visitors

270 profile views
  1. Kintex 7. Подменил рукописные синхронизаторы на макрос xpm_cdc_single и действительно, подцепилась цепочка синхронизации с соответствующими констрейнами. Анализатор молчит, чем меня радует Ради любопытства залез поглядеть на констрейн: # Scoped constraints for xpm_cdc_single set src_clk [get_clocks -quiet -of [get_ports src_clk]] set dest_clk [get_clocks -quiet -of [get_ports dest_clk]] if {($src_clk != $dest_clk) || ($src_clk == "" && $dest_clk == "")} { set_false_path -to [get_cells syncstages_ff_reg[0]] } elseif {$src_clk != "" && $dest_clk != ""} { common::send_msg_id "XPM_CDC_SINGLE: TCL-1000" "WARNING" "The source and destination clocks are the same. \n Instance: [current_instance .] \n This will add unnecessary latency to the design. Please check the design for the following: \n 1) Manually instantiated XPM_CDC modules: Xilinx recommends that you remove these modules. \n 2) Xilinx IP that contains XPM_CDC modules: Verify the connections to the IP to determine whether you can safely ignore this message." } Таки set_false_path кидается на путь.
  2. На частоте clk2 у меня работает совсем другой интерфейс. Данные с clk2 я как раз и перевожу на clk1, но только в том случае, когда корка в домене clk1 поднимет свой link_up.
  3. Добрый день, господа! В проекте имеется сигнал ready, формируемый на тактовом сигнале clk1. Есть фифо, в которое я пишу по сигналу ready на частоте clk2. Соотношение частот clk1/clk2 = 1.9. По факту, ready это сигнал link_up от корки, т.е. пишем в фифо по готовности корки, которая работает в своем клоковом домене. Поскольку клоки не кратны друг другу, то рано или поздно фронты обоих клоков наползут так, что вылезет метастабильность. С ней, по классике жанра, боремся при помощи пары регистров на clk2. Однако, временной анализатор ругается, предупреждая о негативных слаках. Собсно, вопрос: достаточно ли просто задать false_path на данный путь или есть еще какие-нибудь подводные камни, из-за которых в неожиданный момент запись в буфер встанет колом?
  4. RobFPGA, vitus_strom, спасибо большое за ответы, мрака в голове стало чуть меньше
  5. В Вашем случае исходные файлы проекта лежат извне и Вы с ними оперируете, как в части Vivado, так и в части СКВ. Но если я знаю, какие файлы моего проекта для сборки необходимо коммитить, что мне мешает в .gitignore загнать весь мусор и работать из директории проекта? В чем прелесть Вашего подхода?
  6. Добрый день, форумчане! Встал вопрос о внедрении системы контроля версий (Git) в процесс проектирования с использованием САПР Vivado. Немного покопавшись в этих самых интернетах, вычитал, что народ создает файловую структуру рядом с проектом, в которой хранятся исходники проекта (*.v, *.vhdl, *.xci, *.elf и прочее и прочее). Собственно, эту самую структуру и засовывают в СКВ. Далее вопрос: Как заполнить эту самую структуру перед коммитом? *Мысли в слух* Вариант 1. У меня есть отлаженный проект. И я ручками/не ручками (скриптами) из финальной версии проекта перетаскиваю в файловую структуру для СКВ все исходники. При этом в IDE исходники подключены из папки проекта. Коммитим. Когда вытаскиваем данный коммит (pull) из СКВ ручками/скриптами подсовываем в директорию проекта, затем собираем. Вариант 2. У меня есть неотлаженный проект. Я по мере допиливания проекта добавляю IP и исходники, затем ручками перетаскиваю во внешние папки и далее в IDE указываю расположение исходников во внешних папках. В финальной версии проекта перед коммитом все файлы уже на своих местах, т.е. в файловой структуре для СКВ. Коммитим. При вытаскивании из СКВ файлы исходников автоматически подменятся и останется только собрать проект. Вариант 3. Накатать скрипт, который из финальной версии проекта вытаскивает нужные исходники и генерирует скрипт, который на основании исходников создает проект с нуля (recreate). Все это добро коммитится. Вариант 4. Мыслю вообще не в том направлении.