Jump to content

    

Krys

Свой
  • Content Count

    2001
  • Joined

  • Last visited

Everything posted by Krys


  1. Я сравнивал с предыдущим проектом до изменений. Указанные проблемные компоненты находятся на тех же местах, так что условия полностью те же.
  2. Здравствуйте. Есть проблемка. Хочу заставить Planahead скушать результаты частичной разводки в FPGA Editor. У меня в Planahead не разводится 1 цепь, попытался её вручную развести в FGPA Editor и подсунуть планахеду. Но он всё делает так, как будто ничего не съел. Предыстория: Плисина xc6slx100tfgg484-3, используется Planahead и XPS. После добавления определённого функционала и изменения ног в *.ucf перестала разводиться одна цепь. В проекте есть такая DCM-ка: С выхода нарисованного на картинке BUFG сигнал в действительности подаётся не сразу на вход CLKFB этой DCM-ки, а проходит через буфер BUFIO2FB. Этот буфер вставляется средой автоматически (UG382, Clocking resources, стр. 55: "The ISE Design Suite automatically inserts matching BUFIO2FB and BUFIO2 buffers when the CMT feedback path is used."). Так вот если я обычным образом запускаю разводку в планахеде, то цепь от BUFG до BUFIO2FB не разводится. Говорит следующее: 1 signals are not completely routed. See the module_1_stub_routed.unroutes file for a list of all unrouted signals. WARNING:Par:100 - Design is not completely routed. There are 1 signals that are not completely routed in this design. See the "module_1_stub_routed.unroutes" file for a list of all unrouted signals. Check for other warnings in your PAR report that might indicate why these nets are unroutable. These nets can also be evaluated in FPGA Editor by selecting "Unrouted Nets" in the List Window. В указанном файле имеется следующее содержимое: 1 signals are not completely routed. WARNING:ParHelpers:360 - Design is not completely routed. module_1_i/blablabla/main_inst/clock_generator_inst/clkfb , где clkfb - это и есть тот самый сигнал обратной связи, что и на картинке выше. Я решил на ещё неразведённом проекте сделать предварительную разводку этих проблемных цепей в FPGA Editor-е, а уже затем отдать всё обратно планахеду. Для этого я в планахеде нажал на свою стратегию impl1 правой кнопкой, затем launch next step to MAP. После MAP у меня появился файл с расстановкой компонентов, но без разводки: module_1_stub.ncd. Открыл его FPGA Editor-ом, нашёл нужные мне цепи (до и после BUFIO2FB), нажал кнопку Autoroute. Они развелись. Затем нажал Attrib и установил у каждой из них Locked и Priority. Нажал сохранить. После этого у меня обновились файлы module_1_stub.ncd (где появилась разводка только 2х цепей - это я проверил открытием файла повторно в FPGA Editor-е) и module_1_stub.pcf, где добавились мои атрибуты: ... SCHEMATIC END; NET "module_1_i/blablabla/main_inst/clock_generator_inst/clkfb" LOCK; NET "module_1_i/blablabla/main_inst/clock_generator_inst/clkfb" PRIORITIZE = 100; // fpga_editor - P.20131013 - Tue Jul 19 13:34:37 2016 NET "module_1_i/blablabla/main_inst/clock_generator_inst/dcm_sp_inst_ML_NEW_O" LOCK; NET "module_1_i/blablabla/main_inst/clock_generator_inst/dcm_sp_inst_ML_NEW_O" PRIORITIZE = 99; После этого я надеялся подсунуть эти результаты планахеду. Нажал на стратегии правой кнопкой и дальше launch next step to PAR. Всё запустилось, в логах PAR написало, что вроде как подхватило все нужные файлы: *** Running par with args -intstyle pa "module_1_stub.ncd" -w "module_1_stub_routed.ncd" -ol high -mt 4 Constraints file: module_1_stub.pcf. ... Но результат тот же, что и раньше, т.е. одна неразведённая цепь, та же самая. Я ещё раз открыл module_1_stub_routed.ncd в FPGA Editor-е и увидел, что моя цепь до BUFIO2FB является неразведённой. Т.е. это значит, что Planahead либо вообще не увидел, что я ему подсунул в module_1_stub.ncd и module_1_stub.pcf, либо увидел, но проигнорировал, и в результате собственной разводки отцепил разведённое мною и переразвёл по-своему. Вот мой вопрос и состоит в том, как заставить Planahead скушать результаты частичной разводки в FPGA Editor? Либо другой вопрос: как развести и сделать рабочим мой проект возможно каким-то другим способом, не через FPGA Editor? Ведь, видимо, раз эта цепь не разводится, значит, среде что-то не нравится, только она сказать не может (как умная собака ))) ).
  3. Решил проблему генерацией корки, вызвав coregen отдельным приложением из пускового меню. Это конечно не победа, а всего лишь обходной путь, но всё же, хоть так можно работать...
  4. Intekus большое спасибо! Я попробую ) Вы могли бы подсказать, как обойти такую запись:localparam ACK_MIN_DUR_OUT = $rtoi(ACK_MIN_DUR_IN * CLK_RATIO + 0.5); Здесь CLK_RATIO может быть рациональным числом. Если я напрямую подставлю это в качестве ширины шины например, то будет ругаться, что только целые ему подавай.
  5. Здравствуйте. Кто-нибудь может поделиться: нужны самодельные функции взамен системных для Verilog типа $clog2, $rtoi и т.д., а то тут внезапно выяснилось, что под старыми ПЛИСами xst не всё поддерживает. Берём одни и те же исходники, делаем синтез под spartan 6 - всё прекрасно. Меняем тип ПЛИС в свойствах проекта на Virtex 4 - синтезатор ругается на эти системные функции.
  6. Здравствуйте. Подскажите плиз, как можно порешать: при создании корки FIFO в Coregen Planahead вылазит такая вот ошибка [Common 17-11] Failed to parse xmsgs file _xmsgs/cg.xmsgs - No element found Находил подобную же проблему: https://forums.xilinx.com/t5/Embedded-Devel...ead/td-p/318471 Но ответа там не было...
  7. Спасибо откликнувшимся. Мне это не просто для развлекухи надо было, а для математического обоснования при составлении одного документика
  8. Здравствуйте. Вопросик в качестве разминки для мозгов: Как математически доказать, что число 2^x может быть поделено нацело только числом вида 2^y, где y<=x, и никаким другим числом не может (или наоборот может и ещё есть какие-то числа)? Т.е. например число 2 в 12 степени это 4096 нацело делится двойкой в любой степени до 12 и ничем другим. Т.е. для меня важно доказать, что нет ничего другого, кроме 2^y
  9. Да, думаю, так можно. Вопрос в первую очередь касался гуя. Можно ли где-то в гуе поставить какую-то галочку, чтобы запустился битген?...
  10. Расширю вопрос. Есть несколько стратегий разводки в планахед, запущенных в параллель на разных ядрах. Хочется, чтобы в конце разводки каждой автоматически запускался битген. Как это настроить, подскажите пожалуйста.
  11. это возможно связано с той самой проблемой 4 слов датамувера, которую мы с Вами уже обсуждали. И тогда кажется Вы куда-то пропали и не отписались, что вышло. 4 слова датамувер принимает всегда, даже если ему не было команды на приём. Это те самые 16 байтов. Ваши 112 байтов + эти 16 и получается 128 байтов. Что конкретно происходит - не берусь судить, конкретно с этим ядром не работал. Но похоже у них у всех одинаковое поведение.
  12. Это возможно связано с разными способами представления периодического спектра. Одна функция показывает спектр от 0 до Fs, а вторая - от -Fs/2 до +Fs/2. Хотя вообще-то функция fft в матлабе показывает спектр вторым образом, т.е. должны быть палки и 100кГц и 900кГц. А чтобы было первым образом, в матлабе есть функция fftshift: http://www.mathworks.com/help/matlab/ref/fftshift.html
  13. а у меня его нет, он был на прошлой работе, но там запрещено что-то выкладывать )) Сейчас это на новой работе пока не требуется. Почитайте эту тему и найдите ещё поиском похожие темы, они точно были. Возможно, там уже приводили готовые скриптики. В целом, ничего сложного нет - надо потратить денёк, читануть, как пишут тикль скрипты и написать свой )
  14. Я вообще не обращаю внимание на сообщения синтезатора о тайминге в конце синтеза. Смотрю только после PAR. А по поводу утилизации: результат может быть достигнут довольно близкий (синтез к PAR), если в PAR выключить все оптимизации типа registers duplication и т.п. Но кому это надо? Лучше просто не смотреть на сообщения синтезатора )))
  15. Это всё понятно. Но мой вопрос был в том, что изначально было предположение, что PAR расходует элементы (допустим LUT) на интерконнект там, где по результатам синтеза LUTа быть не должно, а должна быть прямая связь. Вывод из предыдущих Ваших скриншотов такой, что предположение было ошибочным? Там потом ещё ув. jojo написал, что были задействованы лишь статические мультиплексоры, которые не задействованными и не могли быть. Т.е. их задействование неверно относить к аргументу в пользу предположения. Да, это тоже всё понятно, не спорю. Особенно бывают всякие схемы оптимизации типа registers duplication и т.п.
  16. Я правильно понял, что всё же причина не в этом, и ячейки под интерконнект не расходуются (по крайней мере сверх того, что предложил синтез)?
  17. В том-то и заключается моё удивление, что я такого никогда не видел в схематике после роутинга. А Вам несложно какой-то живой пример, где например вот кусок кода описывающий прямую связь между регистрами, а вот схема, где эта прямая связь - вовсе не прямая, а через допустим LUT?
  18. Чот сказки какие-то )) Подикась изначально неоптимально написано. Наверное на сверхвысоком уровне (со взгляда программиста, а не схемотехника). Потом Synplify догадывается, что программист имел в виду, а XST не догадывается. А если бы писал разработчик с мышлением схемотехника, то и XST бы догадался.
  19. Подскажите, пожалуйста, как ячейки бывают занятыми под интерконнект? Если между двумя регистрами надо прокинуть связь накоротко, а ячейка представляет собой например LUT, то PAR будет прокидывать связь через LUT, а не напрямую?