Krys

Возможно лишнее, рудименты от более полного проекта, недокастрировано ) А возможно этот модуль используется в симуляционных моделях корок для корректной отработки поведения по старту, и без него никак. Не уверен.

ftp://ftp.electronix-portal.org/upload/__TRASH__/lib_xil_compiled.zip некоторые сложности с доступом к фтп на работе

Да, что-то сломалось. В выходные вообще был недоступен сайт. А сейчас доступен, но пакет не найден, хотя обещали 30 дней хранить. Залил библиотеки заново: https://dropmefiles.net/en/xXDQWUvTh Я думаю подойдут. Я же их скомпилил уже в нужных версиях софта, а подцепить их можно из софта любой версии, чтобы воспроизвести ошибку. Но это не главное. Главное - подсказать, как эту ошибку обойти, не прибегая к либам из других версий, а то костыль какой-то лютый. Не понял, о чём вы, подскажите пожалуйста конкретнее. Ну нормально. И на таких должно воспроизвестись.

Спасибо! Это под Квартус. А под Виваду всё так же или что-то надо поменять?

отредактировал сообщение выше, ссылку на файлообменник дал. С фтп местным у меня не всё просто из-за прокси на работе. Другие версии вивады устраивают, просто изначально мой проект, который мне достался, был сделан на этой версии, и я решил именно на этой продолжить, без миграции, чтобы не привносить новые глюки, связанные с новой версией, т.к. заведомо известно, что на старой точно работает. А моделсим такой версии взял только потому, что в документе из первого сообщения именно эта версия фигурирует. Решил сделать максимально как рекомендовано.

выложил. Архив с библиотеками тоже прикладываю: https://dropmefiles.net/en/BVy6WZ. Но в принципе его и самому получить можно путём компиляции. Только надо взять вивадо 2016.4 и моделсим 10.5С (или квесту этой же версии, но в местных закромах я её не нашёл) tb_error_cmpy_xil_lib.zip

Я именно через это и пробовал, по-другому не пробовал компилить.

Я постараюсь, как буду на работе

Здравствуйте. Используется Vivado 2016.4. Согласно этому документу, с.9, ему подходит симулятор Modelsim 10.5C. Скачал из местных закромов. Скомпилировал библиотеки штатно, ни одной ошибки при компиляции не было. Однако при запуске симуляции появляется такая ошибка: # ** Error: ./../../cores/cmul14x16/sim/cmul14x16.vhd(56): (vcom-1136) Unknown identifier "cmpy_v6_0_12". В 56й строке записано так: USE cmpy_v6_0_12.cmpy_v6_0_12; Дело точно в либах. На пробу взял подменил (вместе с подменой пришлось поправить версии ядер типа как в строчке выше use cmpy_v6...) всю папку скомпиленных библиотек другой версии (были под рукой скомпиленные когда-то давным давно в другом месте из Vivado 2019.1 под Modelsim 10.7С), и всё запускается без ошибок, всё симулится как должно работать в реальности. Вообще я хотел бы с этим проектом работать на квесте 2021.1, я попробовал, но у меня не получилось, поэтому опустился до версии 10.5С, т.к. именно она рекомендована. А не получилось почему описывал здесь. Короче если подсунуть либы другой версии, то всё работает. Не хочется пользоваться таким костыльным вариантом как либы найденные где-то на помойке. Может кто знает ЧЯДНТ?

Вот тут я описал свои попытки скомпилить под виваду без -novopt, но не всё получилось гладко. Пока не знаю что дальше делать.

Здравствуйте. Есть ли инфа, как сделать то же самое для Vivado? Я пробовал сделать как подсказывают в этом документе на стр. 168 через config_compile_simlib. Отредактировал опции для всех библиотек, чтобы не было фразы -novopt, получилось вот так: config_compile_simlib -cfgopt {questasim.verilog.axi_bfm:-quiet} config_compile_simlib -cfgopt {questasim.verilog.ieee:-quiet} config_compile_simlib -cfgopt {questasim.verilog.simprim:-source +define+XIL_TIMING} config_compile_simlib -cfgopt {questasim.verilog.std:-quiet} config_compile_simlib -cfgopt {questasim.verilog.synopsys:-quiet} config_compile_simlib -cfgopt {questasim.verilog.unisim:-source} config_compile_simlib -cfgopt {questasim.verilog.vl:-quiet} config_compile_simlib -cfgopt {questasim.vhdl.axi_bfm:-93 -quiet} config_compile_simlib -cfgopt {questasim.vhdl.ieee:-93 -quiet} config_compile_simlib -cfgopt {questasim.vhdl.simprim:-source -93} config_compile_simlib -cfgopt {questasim.vhdl.std:-93 -quiet} config_compile_simlib -cfgopt {questasim.vhdl.synopsys:-93 -quiet} config_compile_simlib -cfgopt {questasim.vhdl.unisim:-source -93} config_compile_simlib -cfgopt {questasim.vhdl.vl:-93 -quiet} Вроде всё нормально, но проблема в том, среди этого множества нет библиотеки secureip. Попробовал выполнить строчку config_compile_simlib -cfgopt {questasim.verilog.secureip:-source -64 -work secureip -f} Но вивада ругнулась, что такого параметра у неё нет. В итоге эта либа компилится с ошибкой. Вивада 2016.4.

Сам себе отвечу: перешёл на версию 2021b update 1, там это заработало matlab.desktop.editor.getActive

Здравствуйте. Пришла пора повторить вопрос, только для файлов *.mlx (live script, live editor). Версия матлаба 2016b. Не могу найти решение. Гуглил, вот очень близкая проблема:

Спасибо, конечно, "Кэп" ))) Конечно ничего не мешает. Вопрос чисто теоретический. Хотелось бы полноценно пользоваться инструментом. Либо точно знать, что эта фича у хилинха не допилена. У нас есть такие плотно забитые кристаллы, в которых пересинтез (с тем самым сервисным счётчиком) занимает час, а последующая повторная трассировка - несколько часов (бывает до суток). Вот и не всегда получается по-быстрому что-то добавить, чтобы что-то глянуть. И тогда вспоминаешь: а в чипскопе же есть замечательный счётчик, давайте-ка его и используем. А начинаешь смотреть - совсем не то. Вот и вопрос: то ли лыжи не едут, то ли готовить надо уметь

На всякий случай решение похожей проблемы с одновременной работой в сдк и чипскопе

Может кому ещё полезно будет, добавлю на всякий случай. Выкопал где-то когда-то данный документ, не помню где, возможно, на форумах хилинх. Launch SDK and Chipscope.docx

Здравствуйте. Имеется задача для увеличения длительности захвата продецимировать захватываемые в чипскопе данные, захватывать не каждое событие триггера, а скажем каждое второе... или каждое десятое, например. Но столкнулись с проблемой. Вот тут находил похожую проблему, но решения нет. Что имеется у нас: есть сигнал, у которого 80 событий триггера ненулевые значения на шине данных, затем ещё 320 - нулевые. Storage qualification поставили по этому самому событию триггера. Настроили этот match unit counter для проверки на единичку - условие occurring in exactly n clock cycles. Видим в захваченном сигнале 80 ненулевых отсчётов, т.е. всё как надо. Затем ставим двоечку, троечку, четвёрочку. И результат отличается от ожидаемого. Например для двоечки ожидаем увидеть 40 ненулевых (может и 39 с учётом, что начало блока ненулевых отсчётов не совпадёт с периодом обнуления счётчика). Видим разброс аж на 10 значений, как в плюс, так и в минус. Для четвёрочки хотим увидеть 20 (ну может 16), но видим опять же гигантский разброс. И так далее. В результате логика работы непонятна, не можем данному инструменту довериться, что он нам достоверные результаты эксперимента покажет... Может уже кто-то сталкивался с проблемой и знает решение? ПЛИС - Спартан 6. Набор софта ISE 14.7

toshas, спасибо, похожее, но проблема в том, что там дока про виваду, а в ней спартан6 не поддерживается. Но может как-то по аналогии получится И Вам спасибо. Правда второй флешки нет, ибо это так же избыточно (формально), как и изыскивать по крупицам блочную память под загрузчик в забитом кристалле при наличии вагона мегабайтов DDR памяти. Тоже хороший вариант, но ресурсов съест ещё больше, чем просто задействование BRAM под загрузчик

Здравствуйте. Попробую заняться некропостингом. У нас есть проблема с запуском микроблейза из флешки сразу в DDR память. Т.е. есть ПЛИС спартан6, есть флешка (w25q128bw), есть DDR память к плисине. Раньше всё работало так, что загрузчик был в BRAM, загружал весь код из флешки в DDR и стартовал. Но потом мы забили кристалл подзавязку, и возник вопрос: зачем нам подключать к микроблейзу блочную память, если у нас завались внешней DDR? Сказано - сделано, развели такую прошивку, без BRAM. Всё отлично работает, если стартовать из SDK. Но как теперь сделать, чтобы загрузчик сразу грузился из флешки, а не из BRAM? Вообще не знаем, с какого боку подойти. Нигде не нашли, чтобы такой вариант описывался. Заранее спасибо за подсказки.

Спасибо, действительно, я заблуждался. wait on run есть и в планахеде. Так что моя задача действительно реализуема

Raven, спасибо за подсказки. Надо будет попробовать. Только небольшая поправочка: у меня не вивадо, а планахед. Это несколько более печально )) И ещё вопросик: когда я запущу несколько команд в скрипте в разных линиях launch impl_1 launch impl_4 launch impl_6 launch impl_2 то по-моему, он будет дожидаться выполнения каждой, а затем переходить к следующей. Не так ли? Или как-то можно сделать, чтобы он выполнил запуск и, не дожидаясь завершения, перешёл к следующей команде? (извиняюсь, в tcl не силён).

Спасибо, тоже думал над таким же решением. Если я Вас правильно понял, то Вы предлагаете сделать примерно так: 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 предыдущие будут закончены. А у них время выполнения у каждого разное, поэтому некоторое время процессор будет недонагружен, когда некоторые из задач уже закончились, но не все.

Здравствуйте. Вопрос такой. Есть у нас в 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 из них. Так вот проблема в том, что очерёдность выполнения какая-то произвольная. Есть ли способ жёстко указать, какая очерёдность? Дело в том, что мне хотелось бы некоторые запуски выполнить вперёд, а некоторые после, если уж не будет результата у первых.

Golikov A., alexadmin, спасибо. Попробую. А нет ли возможности сделать что-то автоматически, чтобы такая ошибка не вылазила? Дело в том, что у меня на ночь ставятся куча стратегий разводиться, и если такая ошибка - то плохо, уже утром будут не все результаты. К стати, где-то читал, что 32-битная версия чем-то уступает 64-битной по производительности. Кто-то по-моему из местных форумчан проводил сравнение и сделал выводы.

Коллеги, подскажите, пожалуйста: planahead в окошке design runs показывает в столбце статус ngdbuild error. Но когда я открываю лог, то там ничего про ошибку нет (см. приложенный скрин). И как мне с такой несуществующей ошибкой бороться? )