Jump to content

    

Krys

Свой
  • Content Count

    2000
  • Joined

  • Last visited

Everything posted by Krys


  1. Спасибо, конечно, "Кэп" ))) Конечно ничего не мешает. Вопрос чисто теоретический. Хотелось бы полноценно пользоваться инструментом. Либо точно знать, что эта фича у хилинха не допилена. У нас есть такие плотно забитые кристаллы, в которых пересинтез (с тем самым сервисным счётчиком) занимает час, а последующая повторная трассировка - несколько часов (бывает до суток). Вот и не всегда получается по-быстрому что-то добавить, чтобы что-то глянуть. И тогда вспоминаешь: а в чипскопе же есть замечательный счётчик, давайте-ка его и используем. А начинаешь смотреть - совсем не то. Вот и вопрос: то ли лыжи не едут, то ли готовить надо уметь
  2. На всякий случай решение похожей проблемы с одновременной работой в сдк и чипскопе
  3. Может кому ещё полезно будет, добавлю на всякий случай. Выкопал где-то когда-то данный документ, не помню где, возможно, на форумах хилинх. Launch SDK and Chipscope.docx
  4. Здравствуйте. Имеется задача для увеличения длительности захвата продецимировать захватываемые в чипскопе данные, захватывать не каждое событие триггера, а скажем каждое второе... или каждое десятое, например. Но столкнулись с проблемой. Вот тут находил похожую проблему, но решения нет. Что имеется у нас: есть сигнал, у которого 80 событий триггера ненулевые значения на шине данных, затем ещё 320 - нулевые. Storage qualification поставили по этому самому событию триггера. Настроили этот match unit counter для проверки на единичку - условие occurring in exactly n clock cycles. Видим в захваченном сигнале 80 ненулевых отсчётов, т.е. всё как надо. Затем ставим двоечку, троечку, четвёрочку. И результат отличается от ожидаемого. Например для двоечки ожидаем увидеть 40 ненулевых (может и 39 с учётом, что начало блока ненулевых отсчётов не совпадёт с периодом обнуления счётчика). Видим разброс аж на 10 значений, как в плюс, так и в минус. Для четвёрочки хотим увидеть 20 (ну может 16), но видим опять же гигантский разброс. И так далее. В результате логика работы непонятна, не можем данному инструменту довериться, что он нам достоверные результаты эксперимента покажет... Может уже кто-то сталкивался с проблемой и знает решение? ПЛИС - Спартан 6. Набор софта ISE 14.7
  5. toshas, спасибо, похожее, но проблема в том, что там дока про виваду, а в ней спартан6 не поддерживается. Но может как-то по аналогии получится И Вам спасибо. Правда второй флешки нет, ибо это так же избыточно (формально), как и изыскивать по крупицам блочную память под загрузчик в забитом кристалле при наличии вагона мегабайтов DDR памяти. Тоже хороший вариант, но ресурсов съест ещё больше, чем просто задействование BRAM под загрузчик
  6. Здравствуйте. Попробую заняться некропостингом. У нас есть проблема с запуском микроблейза из флешки сразу в DDR память. Т.е. есть ПЛИС спартан6, есть флешка (w25q128bw), есть DDR память к плисине. Раньше всё работало так, что загрузчик был в BRAM, загружал весь код из флешки в DDR и стартовал. Но потом мы забили кристалл подзавязку, и возник вопрос: зачем нам подключать к микроблейзу блочную память, если у нас завались внешней DDR? Сказано - сделано, развели такую прошивку, без BRAM. Всё отлично работает, если стартовать из SDK. Но как теперь сделать, чтобы загрузчик сразу грузился из флешки, а не из BRAM? Вообще не знаем, с какого боку подойти. Нигде не нашли, чтобы такой вариант описывался. Заранее спасибо за подсказки.
  7. Спасибо, действительно, я заблуждался. wait on run есть и в планахеде. Так что моя задача действительно реализуема
  8. Raven, спасибо за подсказки. Надо будет попробовать. Только небольшая поправочка: у меня не вивадо, а планахед. Это несколько более печально )) И ещё вопросик: когда я запущу несколько команд в скрипте в разных линиях launch impl_1 launch impl_4 launch impl_6 launch impl_2 то по-моему, он будет дожидаться выполнения каждой, а затем переходить к следующей. Не так ли? Или как-то можно сделать, чтобы он выполнил запуск и, не дожидаясь завершения, перешёл к следующей команде? (извиняюсь, в tcl не силён).
  9. Спасибо, тоже думал над таким же решением. Если я Вас правильно понял, то Вы предлагаете сделать примерно так: launch_runs impl_1 impl_2 impl_3 -jobs 3 launch_runs impl_4 impl_5 impl_6 -jobs 3 launch_runs impl_7 impl_8 impl_9 -jobs 3 и т.д. Ну там условия ещё наворотить о завершении задач... Но мне кажется такое решение не совсем подходит: при запуске согласно строчке из первого сообщения происходит автоматический запуск следующей стратегии, когда предыдущая закончилась. А согласно строчкам выше следующие 3 запуска будут произведены, когда все 3 предыдущие будут закончены. А у них время выполнения у каждого разное, поэтому некоторое время процессор будет недонагружен, когда некоторые из задач уже закончились, но не все.
  10. Здравствуйте. Вопрос такой. Есть у нас в Planahead несколько запусков имплементации (design runs), как на приложенной картинке. Если их запускать из гуя выбрав все запуски, нажав правой кнопкой и выбрав launch runs, то выполняется такой скрипт: launch_runs impl_1 impl_2 impl_3 impl_4 impl_5 impl_6 impl_7 impl_8 impl_9 impl_10 impl_11 impl_12 impl_13 impl_14 impl_15 impl_16 impl_17 impl_18 impl_19 -jobs 3 Вроде как тут эти запуски перечислены последовательно и говорится, что одновременно запускается 3 из них. Так вот проблема в том, что очерёдность выполнения какая-то произвольная. Есть ли способ жёстко указать, какая очерёдность? Дело в том, что мне хотелось бы некоторые запуски выполнить вперёд, а некоторые после, если уж не будет результата у первых.
  11. Golikov A., alexadmin, спасибо. Попробую. А нет ли возможности сделать что-то автоматически, чтобы такая ошибка не вылазила? Дело в том, что у меня на ночь ставятся куча стратегий разводиться, и если такая ошибка - то плохо, уже утром будут не все результаты. К стати, где-то читал, что 32-битная версия чем-то уступает 64-битной по производительности. Кто-то по-моему из местных форумчан проводил сравнение и сделал выводы.
  12. Коллеги, подскажите, пожалуйста: planahead в окошке design runs показывает в столбце статус ngdbuild error. Но когда я открываю лог, то там ничего про ошибку нет (см. приложенный скрин). И как мне с такой несуществующей ошибкой бороться? )
  13. Ещё некоторая дополнительная информация от моего коллеги, что невозможно на RTL написать соединение PCOUT -> PCIN, если эти порты находятся в разных модулях: https://forums.xilinx.com/t5/Welcome-Join/C...ros/td-p/754013
  14. Делал комплексный умножитель на 36 битов из вещественного умножителя на 36 битов (описан в доке на DSP48) , там оказалось, что выгоднее по числу DSP-блоков реализовать комплексное умножение в лоб по определению.
  15. А откуда следует, что умножение на синусоиду и последующую децимацию-фильтрацию можно заменить на децимацию-фильтрацию с синусом? И откуда следует, что потом ещё нужен доворот на линейно нарастающую фазу? А такой поворот на линейно нарастающую фазу не является ли синусом? Не пробовали в матлабе отмоделировать?
  16. Короче победил я эту штуку... не в лоб, конечно, как хотелось... Я просто переконфигурил ту DCM-ку на рисунке из первого поста, чтобы у неё не было обратной связи, т.е. убрал галочку source sycnhronous. Соответственно, нет цепи - нет и конфликта )) Конечно, такое решение не для всех проектов пригодно, вдруг кому-то надо клок на выходе, синхронный с входом.
  17. Ну вобщем Вы отчасти правы, но и я правильно ответил ))) Дело в том, что тот самый писиайный егошный клок просто подаётся внутрь корки, и внутри самой корки нет BUFG и соответственно он никак не законстрейнен. Но вообще BUFG конечно для этого клока есть, просто снаружи. И создался он, как я понимаю, автоматически, когда я подключил сигнал с тактовой ножки ПЛИС на тактовый вход всех триггеров корки. Естественно плейсер догадался, что неплохо было бы и BUFG поставить )) Ну в любом случае же ни один сигнал писяй не меняется быстрее тактовой, т.е. 33МГц?
  18. Не, корка PCI - она же довольно тупая и примитивная, там же 33МГц )) Там нет в принципе ни одного перечисленного элемента - DCM, MMCM, BUFG, BUFIO. LOC атрибутов тоже нету, всё разводится типа на автомате - полная свобода для творчества ))
  19. Так-то возможность есть, утилизация неплотная. Просто знать бы что двигать. Как я писал сообщением ранее, проблема возникла у сигналов, никак не связанных с внедрённой PCI-коркой, просто она что-то подвинула. И уже подвинутый сигнал вызвал коллизию. А найти эту взаимосвязь довольно сложно...
  20. В том-то и дело, что ругается на сигналы, никак не связанные с PCI. Просто корка PCI расталкивает другие цепи, и взаимосвязь установить довольно сложно. Я конечно буду пытаться искать... двигаться-то по проекту надо...
  21. Пока результаты такие. Открыл FPGA Editor в двух окнах: со старым проектом, в котором всё красиво, и с проектом после изменений. Начал вести руками ту цепь, которая не хотела разводиться. Вёл тем же маршрутом, что и в старом проекте, подсматривая в соседнее окно. Благо число пересечений там небольшое, и можно за 10 минут развести. Вёл-вёл, пока не упёрся в один из многочисленных switch-box-ов, на котором стало видно, что тот выход этого свичбокса, где был мой сигнал в старом проекте, в новом проекте занят другим сигналом. При том другой сигнал не из числа вновь добавленных элементов в новом проекте. Похоже вновь добавленные элементы потеснили старый сигнал, и он занял другое место. Я не долго думая удалил разводку того сигнала, который залез в свичбоксе на чужое место. После этого для моей цепи дал команду autoroute. Цепь развелась полностью, тем самым маршрутом, как и в старом проекте. Теперь я дал команду autoroute для того сигнала, который залез на чужое место. И в результате выдало ошибку, мол, развёл частично, не смог подвести цепь к таким-то элементам. Эти элементы находятся как раз в том же районе, что и проблемный свичбокс, из-за которого подрались сигналы )) Вот теперь сижу чешу репу, как эти сигналы подружить. Видно, что на свичбоксе много пустых выходов, но почему-то по ним эта цепь, которая залезла на чужое место, идти не хочет, видимо дальше линии идут не в те места. Передвинуть в другой регион элементы, до которых не дотянулся этот сигнал, не могу, т.к. они идут на рядом находящиеся ноги плис.
  22. RobFPGA, спасибо за подсказку, но у нас обычный PCI, так что не подходит... Подскажите, пожалуйста, как посмотреть конфликты BUFG и BUFIO? Как я писал в предыдущем сообщении, я смотрел согласно документу UG382, Clocking resources - вроде ничего и не нарушается... Но мог что-то и упустить конечно...
  23. Большое спасибо за такой развёрнутый ответ! Пробовал этот параметр менять и даже добавил все возможные стратегии разводки ну типа вот так: и попробовал все, каждая выдала одинаковую ошибку. Да, я тоже к этому бы хотел стремиться. Тем более, что проект развивается, и не будешь же при каждом изменении так каждый раз плясать с бубномFPGA Editor-ом ))) Было добавлено ядро PCI в виде корки XPS (внутри потроха в виде ngc, и туда не залезть). Больше собственно ничего не было добавлено. И ноги в ucf перекинуты. Чую, что у PCI корки добавился один клок, который где-то не лезет по каким-то путям. Где-то не хватает трассировочных ресурсов. Точнее не так. Нарисованная на картинке в первом сообщении DCM-ка совершенно не связана с PCI-коркой, и была там всегда. Видимо PCI-корка заняла какие-то трассировочные ресурсы и вытеснила сигнал clkfb у DCM-ки. Как говорится была у зайца избушка лубяная, а у лисыPCI-корки ледяная ))) Главно что согласно документу UG382, Clocking resources вроде ничего и не нарушается... Где-то ещё есть узкое местечко...
  24. Подскажите, пожалуйста, поподробнее, как это сделать. Или в каком датащите весь этот алгоритм прописан?
  25. Я сравнивал с предыдущим проектом до изменений. Указанные проблемные компоненты находятся на тех же местах, так что условия полностью те же.