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

    

RobFPGA

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

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

  • Посещение

Репутация

0 Обычный

1 Подписчик

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

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

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

9 673 просмотра профиля
  1. Приветствую! Тестирую новинку на старом проекте. Бросилось в глаза новый таск при P&R ... Starting Netlist Obfuscation Task ... Интересно будет глянуть что они там obfuscatили ? Удачи! Rob.
  2. Приветствую! IMHO думаю что никак. Это внутренности Vivado. Да и лазить шаловливыми ручками в .xpr файл плохая затея. Лучше уж через tcl проектом управлять. Удачи! Rob.
  3. Приветствую! Вот так вот и портится - причем это ROM я туда вообще не пишу - только читаю. Но если по какой то причине будет нарушение таймингов setup/hold на шине адреса ( например тактовая вдруг стала выше чем ожидалось) то возможно что содержимое BRAM будет испорчено даже если сигнал WE в землю забит на глубину в 1 метр. Сигнал сброс|lock от PLL конечно есть - но видно он срабатывает с задержкой. Да и не спасет это если внешняя тактов не сильно меняется - захват PLL все равно остается а выходная частота PLL уже вне рабочего диапазона на которую были costraint при P&R. Удачи! Rob.
  4. Приветствую! В данной случае - желании программистов читать спеки Было же им писано - "остановить обработку, смени частоту, сделать ресет" - они это поняли как "сменю и ресет сделаю". Ну и немножко в моей лени - надо было сразу делать обработку на независимом от ADC клоке. Но вся "прелесть" такой ситуации в том что если например нет возможности на 100% контролировать качество тактовой - например клок внешний и с ним может случится что-то в любой момент - то ставить на такой клок обработку с ROM на BRAM очень рискованно Удачи! Rob.
  5. Приветствую! Ресет синхронный - проблема скорее все в другом - софт начинает менять частоту тактовой не останавливая наглухо перед этим блок обработки. Соответственно на переходных процессах и вылазит timing vialtion портящий содержимое ROM. Потом после смены тактовой и ресета все стартует корректно но табличка то в BRAM уже порченная . Удачи! Rob.
  6. Приветствую! Вот напоролся я на источник этой ругани: Проект на 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.
  7. Приветствую! Тогда остается самый печальный вариант - смотрите хорошим осциллографом питание на ADC (цифровую часть) и на FPGA в частности аналоговый домен питания PLL. Может там короткие провалы при нагрузке при приходе сигнала. Ну или наводки шумов на эти линии идут при одновременном переключении множества линий когда код с выхода ADC около 0. Удачи! Rob.
  8. Прикольный колокольчик на бубне :) - вроде это только ускоряет чуть чуть компиляцию исходников Полезно запустить 3-4 итерации с разными опциями - и посмотреть что и на сколько влияете Удачи! Rob.
  9. Приветствую!. 2-3 часа для плотного дизайна для Stratix V это нормально - это ведь не 10-12 часов Можно попробовать побить дизайн на партиции - те из них которые не меняются при компиляции задать как post_fiting. Также пробовать RapidRecompiling - но это работает не всегда - при относительно больших изменениях может быть даже хуже чем при нормальной компиляции. Можно пробовать лочить партиции на кристалле. Вобщем чистое шаманство :) Удачи! Rob.
  10. Естественно для всех бит - так как тут нет проверки отдельных бит в 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.
  11. Приветствую! Настоящий партизан - но мы то все равно догадались что явка Штирлица не найдены библиотеки примитивов целевой FPGA или IP корок . То есть - либо не скомпилированы в скрипте либо поставлялись отдельно и не подключены. Удачи! Rob.
  12. Приветствую! Да так же как вы для для бита написали (только с инверсией условия) - Ну а биты перебирать в цикле. А цикл соответственно спрятать в яйце в ларце функции или на дереве genrate блока. Удачи! Rob.
  13. Приветствую! Еще N! вариантов и вы найдете (может быть) удачную комбинацию. Даже не анализируя "какие то ошибки". Удачи! Rob.
  14. Приветствую! Думаю что нет. Тут скорее дело в алгоритме минимизации целевой функции тайминга/роутинга при P&R. Например для структуры связей A <-> B <-> C <-> ... N и N <->A. Когда суммарный вес множества коротких связей между близкими блоками превышает вес одной длинной. Ощущения что при размещении блоки ставятся один за другим. При этом направление размещения для следующего не имеет существенно роли так как связи короткие (можно даже предположить что преимущество будет в сторону пустого пространства). В какой то момент функция попадает в локальный минимум и выбраться от туда уже не может. В ISE было еще печальнее - там P&R мог запросто модуль вытянуть колбасой по диагонали через весь кристалл. В Vivado это заметно поправили. Во всяком случае для Kintex|Virtex, (для Artix не скажу почти не работал с ними). Удачи! Rob.
  15. Приветствую! Увы алгоритм P&R в Xilinx этим грешит размазывая логику по кристаллу что манку по тарелке. IMHO скорее всего это связанно с другой структурой FPGA (более однородной) по сравнению с Altera. Поэтому применение pblock это необходимое условие для повторяемости результатов и ускорения P&R. особенно для скоростных и загруженных дизайнов. Удачи! Rob.