[kaps 0]

Добрый день всем!

 

Вот столкнулся с проблемой - как бы оптимизировать компилятор, чтоб скорость поднять....

Объем не интересует - именно скорость.

Знаю, что можно выставить в Design Goals & Strategies условие Timing Performance. Однако, нет ли более глубоких методов? :)

Вот к примеру у меня при синтезе некоторые элементы были применены как Вlock RAM, а знаю, что применить их в LUT наверное, будет быстрее....

Или вот глобальные цепи внутри ПЛИС бы использовать для некоторых внутренних сигналов...

Ну и т.п.

Вот как бы все эти знания обобщить в этом форуме?!

Кстати, можно отдельно обговорить и оптимизацию по объему. К слову, мое мнение, что если проект оптимизирован логически (пользователем) по объему, то, наверняка, это приведет и к оптимизации по скорости.... Ну да это я отвлекся.

Помогите!!!!

[makc 192]

Если Вы под скоростью понимаете рабочую частоту проекта, то далеко не всегда высокая частота соответствует высокой скорости работы (производительности). Это легко показать на примере: максимальная рабочая частота проекта определяется максимальной величиной задержки в комбинаторных цепях между двумя триггерами, тактируемыми одним синхросигналом. Если в в эту комбинаторную цепь вставите промежуточные триггеры, то максимальная задержка, естественно, уменьшится, т.е. вырастет максимальная частота, но тактов для выполнения той же задачи потребуется больше. Если нет обратной связи и есть возможность реализовать конвейеризацию процесса обработки данных, то это может быть неплохим решением. Однако если есть обратные связи, то полноценный конвейер может не получиться и добавление триггеров вместе с ростом тактовой частоты может дать даже обратный эффект в виде снижения производительности.

 

Что же касается именно средств Xilinx-XST, то советую для начала изучить Static Timing Report для того, чтобы уяснить какие именно задержки у Вас преобладают - задержки в логических элементах, либо задержки в цепях трассировки. В первом случае можно пробовать изменять положение регистров в проекте для балансировки длин комбинаторных цепей. В последнем придется думать о снижении разветвления отдельных цепей по выходу и привязке размещения элементов проекта к топологии ПЛИС.

[xvr 12]

На соседнем форуме пробегала ссылка на книгу http://www.freebookspot.com/Books-Advanced...ptimization.htm - советую посмотреть, все эти вопросы там отражены довольно подробно

[yes 5]

Вот столкнулся с проблемой - как бы оптимизировать компилятор, чтоб скорость поднять....

Объем не интересует - именно скорость.

 

проблема не в компиляторе (если так назван синтез, а в P&R)

 

для "поднятия скорости" помогает размещение руками блоков

в оригинальном ISE для этого есть кошмарный тул (чипедитор или как-то так) - он годится для очень маленьких проектов

чтобы это исправить они выпустили planahead - некий тул для управления проектом на уровне AREA_GROUP

его правильное использование существенно поднимает скорость

 

приблизительно такой же механизм есть в Synplify (Design Plan), но симплифай и само по себе без ручного дизайн плана умеет расставлять области (Premier)

 

вобщем - универсального решения нет - если б оно было, то ксайлинс его бы наверно сделал

 

upd : из "домашних" хитростей - можно пережимать констрейны и ставить более сильные опции PAR-у (результат не уложится в констрейны, но будет лучше)

[makc 192]

проблема не в компиляторе (если так назван синтез, а в P&R)

 

Тем не менее register balancing делается не на этапе P&R, а на этапе синтеза.

 

вобщем - универсального решения нет - если б оно было, то ксайлинс его бы наверно сделал

 

Решение есть - проектирование с учётом особенностей синтезатора/P&R/архитектуры ПЛИС. Вот только не всегда получается у разработчика все это учесть...

 

upd : из "домашних" хитростей - можно пережимать констрейны и ставить более сильные опции PAR-у (результат не уложится в констрейны, но будет лучше)

 

Я бы не стал особо рассчитывать на этот метод. К тому же на больших проектах время работы PAR может стать совсем неприличным...

[yes 5]

нормальное решение - это типичный "дивайд энд конквер" с помощью того же planahead-а разбивать на маленькие модули, а с ними P&R более-менее справляется

 

у ксайлинса на сайте есть картинки (видео), где они хвалятся планэхедом - но лучше попробовать

 

для кристала типа V4LX100 - весьма оправдано получается

[makc 192]

нормальное решение - это типичный "дивайд энд конквер" с помощью того же planahead-а разбивать на маленькие модули, а с ними P&R более-менее справляется

у ксайлинса на сайте есть картинки (видео), где они хвалятся планэхедом - но лучше попробовать

для кристала типа V4LX100 - весьма оправдано получается

 

Да, если так оптимизировать небольшие части проекта, на уровне модулей, то результат будет неплохим. Я же говорил про затягивание констрейнов для всего проекта и без учёта использования PlanAhead.

[kaps 0]

А кто нить может подсказать - где искать ссылку по теме "Как создать файл констрейтов и каков у него синтаксис"? В официальном хелпе копался минут 40 - не нашел.... Может здесь поможете, я имею в виду - в этой теме?

 

PS: извините - в Xilinx-XST (ISE 10.1 SP2)

 

И еще вопрос - может не в тему - а что такое SLICE? Я новичок, так что бейте, но не сильно! :)

 

И что такое - Forward и Backward Balancing?

[YuP 0]

А кто нить может подсказать - где искать ссылку по теме "Как создать файл констрейтов и каков у него синтаксис"? В официальном хелпе копался минут 40 - не нашел.... Может здесь поможете, я имею в виду - в этой теме?

 

help\Software Manuals\Constraints Guide.pdf

[yes 5]

Да, если так оптимизировать небольшие части проекта, на уровне модулей, то результат будет неплохим. Я же говорил про затягивание констрейнов для всего проекта и без учёта использования PlanAhead.

 

затягивание констрейнов - решение халявное, а не нормальное :)

но иногда проходит

[SFx 0]

можно память поменять с дистрибутивной на блочную, это позволит несколько MHz получить, еще рекомендую добавить EDN файлы Coregen'a в файл проекта для Synplify. Также хорошо помагает "map -ol high -xe n -timing -cm speed" и " par -ol high -xe с ".

[kaps 0]

Спасибо, попробую....

 

А "map -ol high -xe n -timing -cm speed" и " par -ol high -xe с " в TCL консоли запускать?

[leevv 0]

затягивание констрейнов - решение халявное, а не нормальное :)

но иногда проходит

 

"перетягивание" констрайнов часто даёт обратный результат. P&R использует все свои "ресурсы" на проблемные констрейны, которые вы "перетянули". Наоборот помогает ослабить другие констрейны, которые можно ослабить.

[SFx 0]

А "map -ol high -xe n -timing -cm speed" и " par -ol high -xe с " в TCL консоли запускать?

 

Я пользовался CMD файлом (аля BATник).

 

Там последовательно были команды на старт Synplify, Translate (ngbbuild), Map (map), Place & Route (par), Timing Analizer (trce) и Binary Generator (bitgen).

 

в TCL консоли я не работал, тк сама ISE жрет много ресурсов и тормазит процесс компиляции. Для XC3S5000 забитого на 78% становится недопустимо ожидать билд в течении 3 часов... При работе с Window'ой консолью стало уходить гдето на 20-30 минут меньше, плюс ичезли глюки ISE, которые иногда приводили нарушением констрейнов (приходилось постоянно перегенирить сам проект и производить чистку Project файлов).

 

помошь по TCL находится здесь: Xilinx92i\doc\usenglish\de\dev\tcl.pdf

в этом же каталоге информация о Map, PAR и др.

[kaps 0]

Спрасибки! Надо бы тикл осваивать - говорят гибкий язычок скриптовый! :)