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

Krys

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

    2 002
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Гуру

Контакты

  • Сайт
    http://

Информация

  • Город
    Томск, Россия
  1. toshas, спасибо, похожее, но проблема в том, что там дока про виваду, а в ней спартан6 не поддерживается. Но может как-то по аналогии получится Цитата(krux @ Dec 13 2017, 16:37) если у вас есть некая параллельная flash, подключенная непосредственно к ПЛИС, и из которой microblaze может выполнять код непосредственно - то можно использовать в качестве ПЗУ её.И Вам спасибо. Правда второй флешки нет, ибо это так же избыточно (формально), как и изыскивать по крупицам блочную память под загрузчик в забитом кристалле при наличии вагона мегабайтов DDR памяти. Цитата(krux @ Dec 13 2017, 16:37) есть и другой вариант - написать конечный автомат, который при запуске прошивкиТоже хороший вариант, но ресурсов съест ещё больше, чем просто задействование BRAM под загрузчик
  2. Здравствуйте. Попробую заняться некропостингом. У нас есть проблема с запуском микроблейза из флешки сразу в DDR память. Т.е. есть ПЛИС спартан6, есть флешка (w25q128bw), есть DDR память к плисине. Раньше всё работало так, что загрузчик был в BRAM, загружал весь код из флешки в DDR и стартовал. Но потом мы забили кристалл подзавязку, и возник вопрос: зачем нам подключать к микроблейзу блочную память, если у нас завались внешней DDR? Сказано - сделано, развели такую прошивку, без BRAM. Всё отлично работает, если стартовать из SDK. Но как теперь сделать, чтобы загрузчик сразу грузился из флешки, а не из BRAM? Вообще не знаем, с какого боку подойти. Нигде не нашли, чтобы такой вариант описывался. Заранее спасибо за подсказки.
  3. Спасибо, действительно, я заблуждался. wait on run есть и в планахеде. Так что моя задача действительно реализуема
  4. Raven, спасибо за подсказки. Надо будет попробовать. Только небольшая поправочка: у меня не вивадо, а планахед. Это несколько более печально )) И ещё вопросик: когда я запущу несколько команд в скрипте в разных линиях Кодlaunch impl_1 launch impl_4 launch impl_6 launch impl_2то по-моему, он будет дожидаться выполнения каждой, а затем переходить к следующей. Не так ли? Или как-то можно сделать, чтобы он выполнил запуск и, не дожидаясь завершения, перешёл к следующей команде? (извиняюсь, в tcl не силён).
  5. Спасибо, тоже думал над таким же решением. Если я Вас правильно понял, то Вы предлагаете сделать примерно так: Код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 предыдущие будут закончены. А у них время выполнения у каждого разное, поэтому некоторое время процессор будет недонагружен, когда некоторые из задач уже закончились, но не все.
  6. Здравствуйте. Вопрос такой. Есть у нас в 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 из них. Так вот проблема в том, что очерёдность выполнения какая-то произвольная. Есть ли способ жёстко указать, какая очерёдность? Дело в том, что мне хотелось бы некоторые запуски выполнить вперёд, а некоторые после, если уж не будет результата у первых.
  7. Golikov A., alexadmin, спасибо. Попробую. А нет ли возможности сделать что-то автоматически, чтобы такая ошибка не вылазила? Дело в том, что у меня на ночь ставятся куча стратегий разводиться, и если такая ошибка - то плохо, уже утром будут не все результаты. К стати, где-то читал, что 32-битная версия чем-то уступает 64-битной по производительности. Кто-то по-моему из местных форумчан проводил сравнение и сделал выводы.
  8. Коллеги, подскажите, пожалуйста: planahead в окошке design runs показывает в столбце статус ngdbuild error. Но когда я открываю лог, то там ничего про ошибку нет (см. приложенный скрин). И как мне с такой несуществующей ошибкой бороться? )
  9. Ещё некоторая дополнительная информация от моего коллеги, что невозможно на RTL написать соединение PCOUT -> PCIN, если эти порты находятся в разных модулях: https://forums.xilinx.com/t5/Welcome-Join/C...ros/td-p/754013
  10. Делал комплексный умножитель на 36 битов из вещественного умножителя на 36 битов (описан в доке на DSP48) , там оказалось, что выгоднее по числу DSP-блоков реализовать комплексное умножение в лоб по определению.
  11. А откуда следует, что умножение на синусоиду и последующую децимацию-фильтрацию можно заменить на децимацию-фильтрацию с синусом? И откуда следует, что потом ещё нужен доворот на линейно нарастающую фазу? А такой поворот на линейно нарастающую фазу не является ли синусом? Не пробовали в матлабе отмоделировать?
  12. Короче победил я эту штуку... не в лоб, конечно, как хотелось... Я просто переконфигурил ту DCM-ку на рисунке из первого поста, чтобы у неё не было обратной связи, т.е. убрал галочку source sycnhronous. Соответственно, нет цепи - нет и конфликта )) Конечно, такое решение не для всех проектов пригодно, вдруг кому-то надо клок на выходе, синхронный с входом.
  13. Цитата(RobFPGA @ Jul 27 2016, 13:22) Ну прям чудеса - ничего нет а что-то мешает - толи темная материя портит всю картину мироздания - толи яй... :) Как минимум для PCI должен же быть клок егошный, богатырский!Ну вобщем Вы отчасти правы, но и я правильно ответил ))) Дело в том, что тот самый писиайный егошный клок просто подаётся внутрь корки, и внутри самой корки нет BUFG и соответственно он никак не законстрейнен. Но вообще BUFG конечно для этого клока есть, просто снаружи. И создался он, как я понимаю, автоматически, когда я подключил сигнал с тактовой ножки ПЛИС на тактовый вход всех триггеров корки. Естественно плейсер догадался, что неплохо было бы и BUFG поставить )) Цитата(RobFPGA @ Jul 27 2016, 13:22) А еще старцы говорили что было для PCI пару напряжных временных констант для каких-то входных сигналов - правда было это в далекие времена когда по миру расхаживали древние монстры Virtex, VirtexE, VirtexII.Ну в любом случае же ни один сигнал писяй не меняется быстрее тактовой, т.е. 33МГц?
  14. Не, корка PCI - она же довольно тупая и примитивная, там же 33МГц )) Там нет в принципе ни одного перечисленного элемента - DCM, MMCM, BUFG, BUFIO. LOC атрибутов тоже нету, всё разводится типа на автомате - полная свобода для творчества ))
  15. Так-то возможность есть, утилизация неплотная. Просто знать бы что двигать. Как я писал сообщением ранее, проблема возникла у сигналов, никак не связанных с внедрённой PCI-коркой, просто она что-то подвинула. И уже подвинутый сигнал вызвал коллизию. А найти эту взаимосвязь довольно сложно...