Всем привет,

есть незадачка - мой системверилог проект очень долго компилится (2-5 часов) и не всегда его fmax бывает приемлим.

Сам проект - всего-то около 600 строк без ниоса и наворотов, используется только мегафункции памяти (M9K, M144), altpll и altmult_add.

В самом проекте есть два параметра, назову из K и M, где K - это объем кольцевого буффера памяти, M - число использующихся умножителей.

Если K примерно 70% от всей доступной памяти, M - 10% от всех доступных умножителей, fmax на основной клок получается хороший (490МГц). Компилится все около часу на хорошем i5.

Если
1) K примерно 10-20% от всей доступной памяти, M - любое, или
2) K и M примерно по 30%,
fmax получается еще приемлимый, окло 400МГц (мне не меньше надо) но компилится уже около 2-5 часов.

Если я пытаюсь задействовать почти все умножители и хотя бы 70% памяти, то обычно квартус через 1-2 часа падает со своей какой-то внутренней ошибкой или через 5-7 часов все-таки заканчивает работу, но fmax получается очень маленьким - около 300МГц.

Алгоритмически все упирается в одну простую конструкцию:


Как я понимаю, основная загвоздка у Квартуса возникает тогда, когда я пытаюсь поместить сотни дублей моего MultOne модуля (в мой кристал влазит 384) мне очень хочется вычислять при N=42, то есть когда задействовано 378 умножителей.

Теперь мой вопрос... Могу ли я как-то помочь квартусу, чтобы он стал быстрее компилировать, например, можно ли скомпилить сколько-то этих модулей и физически куда-то в кристалле разместить? Шаманил вокруг LogicLock Regions and Design Partitions Window, но, кажется так запутался, что ничего не могу поделать сам, поэтому прошу помощи у Вас!

Пожалуйста, посоветуйте, что мне сделать, чтобы увеличить fmax и не ждать по 5 часов на компиляцию этих нескольких строк кода!

ЗЫ: при компиляции в квартусе стоят все опции, которые ускоряют fmaxна основе адвизора! Если их отключать, компиляция конечно за пол часа заканчивается но и fmax даже до 200МГц не дотягивает!

Спасибо

И

Ключевое слово верное - logic lock.

С квартусом лет 6 подробно не работал, но когда-то надо было отдельно синтезировать netlist,
потом один экземпляр разместить и развести, сохранить файлы и потом в основном дизайне все экземпляры расставить указывая либо все три файла, либо netlist и placement, либо только netlist.
Могут быть трудности с copy-paste-ом, так как микросхема не однородна и может понадобиться не один "штамп".
Во-первых, это позволяет зафиксировать fmax.
Во-вторых, радикально уменьшает время разработки, даже с учетом нескольких дней на чтение документации и игры с logic lock и virtual pins, так как не только ускоряет разводку, но и уменьшает количество ненужных итераций.

помочь можно только в том случае, если будет видно модуль умножения сложения. И надо понимать что на таких проекта трассы перевешивают все, поэтому регистры, регистры и еще раз регистры. На входе умножителя регистр, внутри умножителя все регистры, на выходе регистр, тоже самое с памятью и т.д.

С Вашим советом я полностью согласен, но, и модуль два умножения плюс сложение - это системная процедура altmult_add, и на входе по два регистра, и на выходе по два... Проверял - больше двух - уже не помогает. Это я уже прошел. Иначе 490МГц я бы не получал!!!

И даже если у меня только умножительный модуль, но забитый под 70-80%, то я тоже получаю необходимые мне 400МГц, и ОТДЕЛЬНО, модуль с памятью, тоже нормально работает. Кстати, у меня память работает только на 1/6 от основного клока, то есть мне достаточно клока в 66МГц на запись, а на чтение и того меньше - всего-то 15МГц.

Основная проблема возникает только при объединении двух модулей - такое чувство, что квартус не в сосотянии решить такую сложную задачу по размещению - фиттер висит по 5 часов а иногда падает с системной ошибкой.

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

Спасибо

И


Спасибо Вам большое, разбираюсь в этом направлении, надеюсь поможет!

Можно попробовать Design Space Explorer, или как он сейчас называется в Altera.
В Xilinx ISE нарвался на аналогичную проблему: на одних настройках (таблицах) MAP проект в итоге трассируется, на других - нет.
Причём при минимальных правках нужно искать новую "счастливую таблицу" из 100*5 возможных.
Проблема появилась при большом количестве плотных макросов с размещением (RPM) и большом количестве блоков ОЗУ.

Для получения fmax пришлось навтыкать "ненужные" регистры с запасом, хотя при малом тираже макросов доп. регистры не требовались.

один в один как у меня было, пока я в проект памяти не напихал, а сейчас и это не помогает.

Logic lock не такой уж и сложный механизм!
Попробуйте на небольшой кошке.

Да, и частоту в констрейнах можно уменьшить, чтобы понапрасну не ждать.

После трассировки для неправильно размещаемых элементов можно задавать (уточнять) области, где им положено быть. Это если элементы в макрос не входят.

Благодарю Вас за ответы и советы!


и так по минимуму



Будьте любезны, разъясните, пожалуйста, как это делается. Вот получил я, например, fmax=330MHz вместо ожидаемых 400МГц. И как я это исправлю, куда смотреть?

Спасибо

Нужно сопоставлять отчёт анализатора задержек (Timequest др.) и вид проблемного пути на кристалле (FloorPlan Editor и т.п.).

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

Ресурсы ПЛИС расположены немонотонно, например, узкими колонками, простым констрейном размещения дело может не обойтись. В этом случае добавляем в конвейер пустые регистры, которые по алгоритму вроде не нужны, но задержку сокращают.

Покажите, если можете, аналогичную картинку своего проекта с подсвечиванием сбойных путей.

Уважаемый jojo,

очень Вам благодарен за классные советы и разъяснения.

Я, к сожалению, новичек в квартусе (только один год опыта) и, некоторые вещи пока еще не знаю.



вот как это сделать, не понимаю. Допустим у меня есть собранный проект.
; Logic utilization ; 50 % ;
; Combinational ALUTs ; 23,937 / 113,600 ( 21 % ) ;
; Memory ALUTs ; 84 / 56,800 ( < 1 % ) ;
; Dedicated logic registers ; 60,800 / 113,600 ( 54 % ) ;
; Total registers ; 60800 ;
; Total block memory bits ; 4,131,624 / 5,630,976 ( 73 % ) ;
; DSP block 18-bit elements ; 210 / 384 ( 55 % ) ;

Это последний из максимальных, который у меня собирается, но его fmax=398MHz (85С) и 420МГц (0С), то есть чуть-чуть меньше, чем надо. Я кстати заметил, что хоть кристалл и до 60С разогревается во время работы, но данные бывают битые, если fmax меньше 420МГц, хотя у меня клок системы через плл из плиски задается и составляет ровно 400МГц. Возможно где-то нестабильность имеется, ну да ладно, главное я знаю на какую частоту мне все затачивать.

По спидгрейдам кристалла, умножители могут работать до 490МГц, все остальное - совсем простое - суммы примерно 40 битных чисел, работающие на полуклоке, то есть на 200МГц от основного клока.

Вот получил я Technology Map Viewver на 615 страницах или Resource Property Editor с огромным числом информации, большая часть которой мне не понятна, или получил картинку от Chip Planner, красивая конечно, но что мне с ней делать, можно по разному ее покрасить, но путей там не видно... Если FanIn кнопку нажимаю, получается сначала какое-то мессиво, а потом квартус зависает с полной загрузкой компьютера. Это здесь именно я должен был увидеть картинку сбойных путей, подскажите, мне, если Вас не затруднит, пожалуйтса!

ЗЫ: вроде и компьютер не совсем тормознутый, 2*2.2ГГц с 8 ГБ оперативки.

Спасибо

И

Возможно, из-за дрожания тактового сигнала данные сбиваются.

Я сейчас больше с Xilinx работаю. По памяти, вроде надо в Timequest провести анализ путей на Fmax, потом построить список путей в отчёте, потом нажать на сбойный путь и сделать Locate in Chip Planner. Там подсветятся ресурсы сбойного пути. Наверное, можно прямее сделать это же.

В том же отчёте TimeQuest можно увидеть, из чего складывается задержка. Нажмите на сбойный путь и Locate in Technology Map Viewer.

Что-то в документации должно быть на эту тему.

Надо либо законстрейнить положение, либо добавить регистры, либо перестроить сбойный путь.

Что именно мешает посмотреть все критические пути на timequest анализатор? Там все расписано подробно - посмотрите примерно в каких пропорциях задержки критичекого пути распределены - если большие задержки на IC (т.е. от элемента до элемента) то советую идти по пути partition и logic lock, то что Shtirlits советовал. Если основные задержки на самих элементах - то только переделка самого алгоритма.

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

Да, кстати, вот это очень интересное место. Еще не понятно как раскидал фиттер эту сумму. Ну и как у Вас чатоты в проекте соотносятся или Вы работаете на основной частоте, а 200МГц получаете используя разрешающий сигнал на триггер?