Перейти к содержанию

    

RobFPGA

Свой
  • Публикаций

    1 300
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

1 Подписчик

Информация о RobFPGA

  • Звание
    Профессионал

Посетители профиля

9 688 просмотров профиля
  1. Приветствую! Увы - неожидаемого чуда не случилось - v2018.3 фигня Также медленно работает. Да к тому же в используемом мной PCIe XDMA так и не починили проблемы с таймингом для режима Gen3 x8. После синтеза внутри XDMA видны 11!!! уровней логики с fanout>100 (при тактовой 250 MHz) и никакой оптимизацией при P&R это не лечится :(. А заниматься патчингом нетлиста после синтеза лень. Удачи1 Rob.
  2. Приветствую! Казалось бы что может быть проще ... if {[current_run]=="synth_1"} {... Ан нет :( Ведь к моменту применения файлов констрейнов процесс синтеза УЖЕ ЗАКОНЧИЛСЯ! Поэтому [current_run] возвращает ... сюрприз ... "impl_1" Но нормальные герои как известно всегда в обход ползут. # synth_implentation_constaint_file.tcl # out current property report_property [current_design] report_property [current_project] report_property [current_run] report_property [current_fileset] common::send_msg_id "SYNTH: 00-000" "INFO" "apply user's common constraint" # common constraint create_clock -period 3.000 -name CLK_IN [get_ports clk_in] create_clock -period 5.000 -name CLK_OU [get_ports clk_ou] set_clock_groups -asynchronous -group {CLK_IN} set_clock_groups -asynchronous -group {CLK_OU} # Stone near 3 roads if {[get_property DESIGN_MODE [current_fileset]]=="RTL"} { common::send_msg_id "SYNTH: 00-000" "INFO" "apply user's synthesis constraint" # ... } elseif {[get_property DESIGN_MODE [current_fileset]]=="GateLvl"} { common::send_msg_id "SYNTH: 00-000" "INFO" "apply user's implementation constraint" # ... } else { common::send_msg_id "SYNTH: 00-000" "ERROR" "F..k! Where i'm?" exit 1 } Увы - в Vivado все еще каша в части организации внутренних процессов и упорядочивании команд. Удачи! Rob.
  3. Приветствую! Так как сейчас можно полноценно использовать tcl для констрейнов то при желании можно ваять универсальный файл выбирая через if часть для синтеза или P&R. Но у меня такое впечатление что Vivado при синтезе не учитывает данные по клоку - так как по логу видно что xdc применяется после окончания синтеза . Удачи! Rob.
  4. Приветствую! Для синтеза это "нормальное" поведение если часть BD/IP у вас синтезируется как OOC модули. В таком случае при синтезе констрэйны привязанные к net|pin внутри этих OOC не находятся. Так как модуль OOC виден при синтезе как black-box. Тут нужно либо забить на варнинги, либо все синтезировать одним куском (global), либо выносить такие констрэйны в отдельный xdc с опцией "только для P&R". Порядок применения констрэйнов в Vivado описан в доке. Если в общем случае то сначала все ip.xdc, затем user.xdc | user.tcl (в порядке включения в проекте!!!). Ну а конкретная последовательность видна в логе синтеза/P&R Удачи! Rob.
  5. Приветствую! Тестирую новинку на старом проекте. Бросилось в глаза новый таск при P&R ... Starting Netlist Obfuscation Task ... Интересно будет глянуть что они там obfuscatили ? Удачи! Rob.
  6. Приветствую! IMHO думаю что никак. Это внутренности Vivado. Да и лазить шаловливыми ручками в .xpr файл плохая затея. Лучше уж через tcl проектом управлять. Удачи! Rob.
  7. Приветствую! Вот так вот и портится - причем это ROM я туда вообще не пишу - только читаю. Но если по какой то причине будет нарушение таймингов setup/hold на шине адреса ( например тактовая вдруг стала выше чем ожидалось) то возможно что содержимое BRAM будет испорчено даже если сигнал WE в землю забит на глубину в 1 метр. Сигнал сброс|lock от PLL конечно есть - но видно он срабатывает с задержкой. Да и не спасет это если внешняя тактов не сильно меняется - захват PLL все равно остается а выходная частота PLL уже вне рабочего диапазона на которую были costraint при P&R. Удачи! Rob.
  8. Приветствую! В данной случае - желании программистов читать спеки Было же им писано - "остановить обработку, смени частоту, сделать ресет" - они это поняли как "сменю и ресет сделаю". Ну и немножко в моей лени - надо было сразу делать обработку на независимом от ADC клоке. Но вся "прелесть" такой ситуации в том что если например нет возможности на 100% контролировать качество тактовой - например клок внешний и с ним может случится что-то в любой момент - то ставить на такой клок обработку с ROM на BRAM очень рискованно Удачи! Rob.
  9. Приветствую! Ресет синхронный - проблема скорее все в другом - софт начинает менять частоту тактовой не останавливая наглухо перед этим блок обработки. Соответственно на переходных процессах и вылазит timing vialtion портящий содержимое ROM. Потом после смены тактовой и ресета все стартует корректно но табличка то в BRAM уже порченная . Удачи! Rob.
  10. Приветствую! Вот напоролся я на источник этой ругани: Проект на Virtex7. В дизайне модуль в котором 16 штук одинаковых FFT параллельно-последовательно жуют поток от 2 каналов ADC. Модуль уже работал в другом проекте так что проблем не ожидал - и вдруг выходе одного из FFT наблюдаю что то похожее на забор соседа на даче, а не одинокую палку. Все времянки после P&R ок. Прогнал пост P&R функционал и timig симуляцию для этого модуля - все ок. Что за чертовщина? Полез дебажить через ECO моде. Последовательно цепляя пробники по пути сигнала вычислил что глючить ... ROM таблица поворотов (просто BRAM) в одном из stage FFT. Причем там никакой асинхроннщины нет и в помине! Прошивка только что загружена через JTAG! Неужели Pentek подсунул мне битые FPGA? Немного остыв начал смотреть в чем разница с предыдущим проектом. А разница в том что в текущем проекте частота ADC программируется и софт сначала меняет частоту внешнего синтезатора а потом меняет настройки внутреннего PLL от которого питается FFT. И все это на лету - без остановки FFT модуля!. Потом ясное дело ресетится весь блок обработки и все. Поэтому как пить дать происходить кратковременное нарушение времянок на адресной шине ROM - а это чревато: The setup time of the block RAM address and write enable pins must not be violated. Violating the address setup time (even if write enable is Low) can corrupt the data contents of the block RAM. Теперь вот надо думать как с этим бороться. Понятно что сначала надо избить поговорить с программистами. А потом решать как уйти от этой зависимости непосредственно в железе. Удачи! Rob.
  11. Приветствую! Тогда остается самый печальный вариант - смотрите хорошим осциллографом питание на ADC (цифровую часть) и на FPGA в частности аналоговый домен питания PLL. Может там короткие провалы при нагрузке при приходе сигнала. Ну или наводки шумов на эти линии идут при одновременном переключении множества линий когда код с выхода ADC около 0. Удачи! Rob.
  12. Прикольный колокольчик на бубне :) - вроде это только ускоряет чуть чуть компиляцию исходников Полезно запустить 3-4 итерации с разными опциями - и посмотреть что и на сколько влияете Удачи! Rob.
  13. Приветствую!. 2-3 часа для плотного дизайна для Stratix V это нормально - это ведь не 10-12 часов Можно попробовать побить дизайн на партиции - те из них которые не меняются при компиляции задать как post_fiting. Также пробовать RapidRecompiling - но это работает не всегда - при относительно больших изменениях может быть даже хуже чем при нормальной компиляции. Можно пробовать лочить партиции на кристалле. Вобщем чистое шаманство :) Удачи! Rob.
  14. Естественно для всех бит - так как тут нет проверки отдельных бит в test_sig. Это эквивалентно signal_out = (test_sig[39:0]!=0) ? {40{1'b1}} : {40{1'bz}}; А TC хотел бы что типа такого // signal_out = {40{1'bz}} | test_sig[39:0]; Но увы - хоть битовая операция 1'bz | 1'b1 = 1'b1 но вот 1'bz | 1'b0 = 1'bx (а не 1'bz) - обломс :( Удачи! Rob.
  15. Приветствую! Настоящий партизан - но мы то все равно догадались что явка Штирлица не найдены библиотеки примитивов целевой FPGA или IP корок . То есть - либо не скомпилированы в скрипте либо поставлялись отдельно и не подключены. Удачи! Rob.