Jump to content

    

Krys

Свой
  • Content Count

    2001
  • Joined

  • Last visited

Posts posted by Krys


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

    Не могу найти решение. Гуглил, вот очень близкая проблема:

     

    I'm working on my MATLAB code in a number of different locations, and it would be really helpful if I could make the code aware of its location on the computer. Till now I worked with .m-files. For .m-files I found the following solutions:

    
    %example 1    
    cd(fileparts(mfilename('fullpath')))
    

    or

    
    %example 2
    tmp = matlab.desktop.editor.getActive;
    cd(fileparts(tmp.Filename));
    

    or

    
    %example 3
    S = dbstack('-completenames');
    S(1).file
    

    or

    
    %example 4
    which(mfilename)
    

    ...

    Outputs of the examples above executed in a *.mlx-file:

    %example1: mfilename returns the path to the 'MatlabEvaluationHelper' in the 'AppData\Local\Temp'-folder

    %example2: output is an empty array

    %example3: same output as example1

    %example4: same output as example1, because mfilename returns "MatlabEvaluationHelper"

     

     

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

  3. Здравствуйте. Имеется задача для увеличения длительности захвата продецимировать захватываемые в чипскопе данные, захватывать не каждое событие триггера, а скажем каждое второе... или каждое десятое, например. Но столкнулись с проблемой.

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

    Может уже кто-то сталкивался с проблемой и знает решение?

     

    ПЛИС - Спартан 6. Набор софта ISE 14.7

  4. toshas, спасибо, похожее, но проблема в том, что там дока про виваду, а в ней спартан6 не поддерживается. Но может как-то по аналогии получится

     

    если у вас есть некая параллельная flash, подключенная непосредственно к ПЛИС, и из которой microblaze может выполнять код непосредственно - то можно использовать в качестве ПЗУ её.
    И Вам спасибо. Правда второй флешки нет, ибо это так же избыточно (формально), как и изыскивать по крупицам блочную память под загрузчик в забитом кристалле при наличии вагона мегабайтов DDR памяти.

     

    есть и другой вариант - написать конечный автомат, который при запуске прошивки
    Тоже хороший вариант, но ресурсов съест ещё больше, чем просто задействование BRAM под загрузчик

     

  5. Здравствуйте. Попробую заняться некропостингом.

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

    Заранее спасибо за подсказки.

  6. Raven, спасибо за подсказки. Надо будет попробовать. Только небольшая поправочка: у меня не вивадо, а планахед. Это несколько более печально ))

    И ещё вопросик: когда я запущу несколько команд в скрипте в разных линиях

    launch impl_1
    launch impl_4
    launch impl_6
    launch impl_2

    то по-моему, он будет дожидаться выполнения каждой, а затем переходить к следующей. Не так ли? Или как-то можно сделать, чтобы он выполнил запуск и, не дожидаясь завершения, перешёл к следующей команде? (извиняюсь, в tcl не силён).

  7. Спасибо, тоже думал над таким же решением. Если я Вас правильно понял, то Вы предлагаете сделать примерно так:

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

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

    post-13271-1505721509_thumb.png

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

    К стати, где-то читал, что 32-битная версия чем-то уступает 64-битной по производительности. Кто-то по-моему из местных форумчан проводил сравнение и сделал выводы.

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

    post-13271-1505290028_thumb.png

  11. Ещё некоторая дополнительная информация от моего коллеги, что невозможно на RTL написать соединение PCOUT -> PCIN, если эти порты находятся в разных модулях: https://forums.xilinx.com/t5/Welcome-Join/C...ros/td-p/754013

  12. А откуда следует, что умножение на синусоиду и последующую децимацию-фильтрацию можно заменить на децимацию-фильтрацию с синусом? И откуда следует, что потом ещё нужен доворот на линейно нарастающую фазу? А такой поворот на линейно нарастающую фазу не является ли синусом?

    Не пробовали в матлабе отмоделировать?

  13. Короче победил я эту штуку... не в лоб, конечно, как хотелось... Я просто переконфигурил ту DCM-ку на рисунке из первого поста, чтобы у неё не было обратной связи, т.е. убрал галочку source sycnhronous. Соответственно, нет цепи - нет и конфликта )) Конечно, такое решение не для всех проектов пригодно, вдруг кому-то надо клок на выходе, синхронный с входом.

  14. Ну прям чудеса - ничего нет а что-то мешает - толи темная материя портит всю картину мироздания - толи яй... :)

    Как минимум для PCI должен же быть клок егошный, богатырский!

    Ну вобщем Вы отчасти правы, но и я правильно ответил ))) Дело в том, что тот самый писиайный егошный клок просто подаётся внутрь корки, и внутри самой корки нет BUFG и соответственно он никак не законстрейнен. Но вообще BUFG конечно для этого клока есть, просто снаружи. И создался он, как я понимаю, автоматически, когда я подключил сигнал с тактовой ножки ПЛИС на тактовый вход всех триггеров корки. Естественно плейсер догадался, что неплохо было бы и BUFG поставить ))

     

     

    А еще старцы говорили что было для PCI пару напряжных временных констант для каких-то входных сигналов - правда было это в далекие времена когда по миру расхаживали древние монстры Virtex, VirtexE, VirtexII.
    Ну в любом случае же ни один сигнал писяй не меняется быстрее тактовой, т.е. 33МГц?

     

  15. Не, корка PCI - она же довольно тупая и примитивная, там же 33МГц )) Там нет в принципе ни одного перечисленного элемента - DCM, MMCM, BUFG, BUFIO. LOC атрибутов тоже нету, всё разводится типа на автомате - полная свобода для творчества ))

  16. Так-то возможность есть, утилизация неплотная. Просто знать бы что двигать. Как я писал сообщением ранее, проблема возникла у сигналов, никак не связанных с внедрённой PCI-коркой, просто она что-то подвинула. И уже подвинутый сигнал вызвал коллизию. А найти эту взаимосвязь довольно сложно...

  17. В том-то и дело, что ругается на сигналы, никак не связанные с PCI. Просто корка PCI расталкивает другие цепи, и взаимосвязь установить довольно сложно. Я конечно буду пытаться искать... двигаться-то по проекту надо...

  18. Пока результаты такие. Открыл FPGA Editor в двух окнах: со старым проектом, в котором всё красиво, и с проектом после изменений. Начал вести руками ту цепь, которая не хотела разводиться. Вёл тем же маршрутом, что и в старом проекте, подсматривая в соседнее окно. Благо число пересечений там небольшое, и можно за 10 минут развести. Вёл-вёл, пока не упёрся в один из многочисленных switch-box-ов, на котором стало видно, что тот выход этого свичбокса, где был мой сигнал в старом проекте, в новом проекте занят другим сигналом. При том другой сигнал не из числа вновь добавленных элементов в новом проекте. Похоже вновь добавленные элементы потеснили старый сигнал, и он занял другое место.

    Я не долго думая удалил разводку того сигнала, который залез в свичбоксе на чужое место. После этого для моей цепи дал команду autoroute. Цепь развелась полностью, тем самым маршрутом, как и в старом проекте. Теперь я дал команду autoroute для того сигнала, который залез на чужое место. И в результате выдало ошибку, мол, развёл частично, не смог подвести цепь к таким-то элементам. Эти элементы находятся как раз в том же районе, что и проблемный свичбокс, из-за которого подрались сигналы ))

     

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

  19. RobFPGA, спасибо за подсказку, но у нас обычный PCI, так что не подходит...

     

     

    Надо после place смотреть где и как рассоложено и нет ли конфликта для BUFG и BUFIO.
    Подскажите, пожалуйста, как посмотреть конфликты BUFG и BUFIO? Как я писал в предыдущем сообщении, я смотрел согласно документу UG382, Clocking resources - вроде ничего и не нарушается... Но мог что-то и упустить конечно...

     

     

  20. Попробуйте поменять в настройках Map параметр Starting Placer Cost Table. Возможно проблема как раз в том что компоненты размещены плохо.
    Большое спасибо за такой развёрнутый ответ! Пробовал этот параметр менять и даже добавил все возможные стратегии разводки ну типа вот так:

    post-13271-1469103239_thumb.png

    и попробовал все, каждая выдала одинаковую ошибку.

     

    Мне все же кажется что тут нужны не пляски с бубном и FPGAeditor-ом а понять почему штатно не разводится.
    Да, я тоже к этому бы хотел стремиться. Тем более, что проект развивается, и не будешь же при каждом изменении так каждый раз плясать с бубномFPGA Editor-ом )))

     

     

    Тем более что раньше я так понял было все ок. Значит надо проанализировать что было добавлено или изменено и как это повлияло. Вплоть до того что окатить изменения и научным методом тыка добавлять их поэтапно и смотреть на разводку
    Было добавлено ядро PCI в виде корки XPS (внутри потроха в виде ngc, и туда не залезть). Больше собственно ничего не было добавлено. И ноги в ucf перекинуты. Чую, что у PCI корки добавился один клок, который где-то не лезет по каким-то путям. Где-то не хватает трассировочных ресурсов.

    Точнее не так. Нарисованная на картинке в первом сообщении DCM-ка совершенно не связана с PCI-коркой, и была там всегда. Видимо PCI-корка заняла какие-то трассировочные ресурсы и вытеснила сигнал clkfb у DCM-ки. Как говорится была у зайца избушка лубяная, а у лисыPCI-корки ледяная )))

    Главно что согласно документу UG382, Clocking resources вроде ничего и не нарушается... Где-то ещё есть узкое местечко...