Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Как "разогнать" блок до нужной частоты
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
v_mirgorodsky
Здравствуй всезнающий ALL!

Столкнулся вот с такой проблемой. Был дизайн на счематике для Альтеры - медианная фильтрация изображений. Работал на частотах до 150MHz в чипе EP1K30TC144-2, т.е. второй speed-grade ACEX-1K. Все было замечательно и красиво. smile.gif

Позже возникла необходимость изваять аналогичную функциональность на VHDL под Xilinx. Перевод графики в текст проблем не вызвал. Созданный тулзой RTL-счематик практически один в один повторял графическое представление схемы, созданной ранее. Все было хорошо до анализа логов временного симулятора. По его репорту максимальная рабочая частота схемы составляет 120-134MHz. В поытке побороть глюк был установлен тайминг-констраин на клоковый вход - ISE счастливо завершился с предупреждением, что временные ограничения не выполняются cranky.gif Запуск флор-план редактора показал, что бедный медианный фильтр разметало на половину XC2VP4 кристалла, при самом размере блока фильтра менее 10% ресурсов микросхемы smile3046.gif По опыту работы с Альтерой, надо копать в сторону более плотной упаковки кристала. Пять часов различных експериментов в попытках правильно законстраинить дизайн закончились ничем. Попытки дотронуться до любых движков оптимизации в настройках приводили в основном к падению рабочей частоты smile3046.gif

По даташитам - Virtex-II Pro speed grade 6 все же несколько быстрее, чем альтеровский ACEX-1K, следовательно проблема не в тулзе и не в чипе, а в неправильном их использовании. Не подскажет ли глубоко уважаемый ALL путей выхода из этого кризиса?
Andrey Filippov
Цитата(v_mirgorodsky @ Mar 30 2005, 12:25)
Не подскажет ли глубоко уважаемый ALL путей выхода из этого кризиса?

Трудно полностью понять алгоритм оптимизации проприетарного продукта :-)

Но я бы посоветовал действовать так (хотя у меня Verilog, а не VHDL)
Сначала - отпустить немного ограничения. Мне кажется, что гогда тулы не справляются с заданием, они "паникуют" и порют лажу.
дальше - установить отдельные (или просто выкинуть - TIG) ограничения для сигналов, для которых задержки не критичны (например - двухцикловые).
Ну а потом - смотреть "где тонко" и там пытаться подправить. Например, временные параметры регистра на выходе встроенного умножителя отличаются от просто регистра, поэтому, если результат используется в дальнейших арифметических операциях, то его выход неплохо бы еще пропустить через обычный регистр - как в примере ниже - DCT (Verilog, Spartan-3):
idct
Кстати, на "раскидано" обычно можно внимание не обращать.
v_mirgorodsky
Проблема решилась заменой SRL16 встроенного сдвигового регистра на основе блока LUT на обычный на триггерах и все поперло - блок разогнался до 214+MHz без любых проблем.

Не согласен что на "раскидано" внимания можно не обращать. Путем ручной трассировки и раскладки в чип получилось убрать ошибку на бите данных, который до этого не проходил временные проверки. Таким образом заключаем что проблема не в тулах, а в умении ими пользоваться. Просто нет опыта в правильном законстраинивании проекта, а документация по констраинам чем то напоминает описание кубика Рибика => у вас есть несколько граней, которые вы можете вращать вокруг своей оси, вращая их в правильном порядке вы можете сложить кибик, затратив на это не более чем N операций вращения. Все понятно, беда только в том, что вариантов слишком много sad.gif
fake
[quote=v_mirgorodsky,Mar 30 2005, 22:25]
В поытке побороть глюк был установлен тайминг-констраин на клоковый вход - ISE счастливо завершился с предупреждением, что временные ограничения не выполняются
[/quote]

От пина до глобального буфера что ли?

[quote=v_mirgorodsky,Mar 30 2005, 22:25]
Запуск флор-план редактора показал, что бедный медианный фильтр разметало на половину XC2VP4 кристалла, при самом размере блока фильтра менее 10% ресурсов микросхемы
[/quote]

Вынеси узел в макро-фрагмент (или как он там называется), ограничь его с помощью RLOC_RANGE, либо RLOC_ORIGIN на него поставь так чтоб он поближе к входным пинам встал.

[/quote]
v_mirgorodsky
Цитата(fake @ Mar 31 2005, 13:52)
От пина до глобального буфера что ли?


Нет, ограничение на максимальную желаемую тактовую частоту.

Цитата(fake @ Mar 31 2005, 13:52)
Вынеси узел в макро-фрагмент (или как он там называется), ограничь его с помощью RLOC_RANGE, либо RLOC_ORIGIN на него поставь так чтоб он поближе к входным пинам встал.


Осталось только догадаться как это сделать. А констраин гайде я нашел очень много описаний по поводу именно этого констраина, попытался его применить к модулю верхнего уровня и получил ошибку. После прикручивания этого констраина к конкретной метке описания элементарного блока ошибка пропала, но это же не выход практически в ручную задавать расположение элементов внутри кристалла - слишком много элементов и совсем непереносимая схема cranky.gif
3.14
<... как правильно задавать констрейны?>

Хочу высказаться smile.gif
Для начала, надо описывать устройство так, чтоб потом его можно было вписать в констрейн, это я к тому, что различные выражения HDL балансирующие на грани синтезируемости пользы не добавляют.

У Xilinx "нужных" констрейнов всего два - PERIOD и OFFSET.
PERIOD - ограничивает pipeline, OFFSET, его входы/выходы.

Геморой начинается с проектами в которых несколько тактовых, тут наворячиваются мультицикловые констрейны FROM ... THRU ... TO, игнорирующие TIG.
Но мне болше всего неудобств приносит специфика OFFSET - он не может пользоваться тактовыми полученными внутри кристалла sad.gif
Тогда на помощь приходит FROM ... TO.
Например:
INST Inst_ADDRES_GENERATOR/* TNM = ADDRffs ;
NET Inst_ADDRES_GENERATOR/* MAXSKEW = 1.5 ns ;
TIMESPEC "TSADDR01" = FROM ADDRffs TO ADDRffs 50 ns;
TIMESPEC "TSADDR02" = FROM ADDRffs TO FFS 100 ns;
TIMESPEC "TSADDR02" = FROM ADDRffs TO PADS 80 ns;
TIMESPEC "TSADDR03" = FROM FFS TO ADDRffs 100 ns;

TSADDR01 - это за место PERIOD (мне так больше понравилось).

По поводу RPM можно посмотреть здесь
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.