Скорость блока больше скорости команды, Как получилось? Опции

[vitus_strom]

отлаживать какой то отдельный кусочек в FPGA ИМХО нет никакого смысла потому как даже задав размещение раутер моежет разводить его каждый раз по разному, конечно можно поизвращатьсть с так называемыми хард макросами, но есть ли смысл вот в чем вопрос, по моему мнению если не нужно из FPGA выжимать край, то можно воспользоваться временными ограничениями

[kas]

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

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

А каким образом тут может помочь моделирование, которое основывается на тех данных о задержках, которые ему передал PAR?

Смотреть по сигналам внутри блоков. На какие команды быстрее/медленее реагируют.

[Serega Doc]

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

[vetal]

Оптимизировать надо в первую очередь схему.
Как я заметил, synplify, не всегда корректно воспринимает шаблоны.
К примеру триггер с установкой, без асинхронного сброса делать на отрез отказывается. В разных версиях по разному интерпритирует типовые конструкции.
Следовательно работу по оптимизации необходимо начинать с проверки корректности преобразования rtl->netlist и принимать соответствующие меры.

По поводу времени в синтезаторе и post place/route, да они отличаются, но это лишь косвенный показатель, данные времена связаны переменным масштабирующим коэффициентом.Улучшение временных характеристик в синтезаторе приведет к улучшению характеристик после разводки.

Основное, к чему необходимо стремиться - не давать синтезатору повода для внесения излишних оптимизаций. Эксперименты с настройками тактовой частоты, позволяют найти "резонансную" частоту схемы, при которой будет происходить наиболее эффективный синтез.

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

[Serega Doc]

Подскажите как всетаки проверить отдельные составляющие одного сложного блока.
Насколько я понял если коментить все остальное и проверять только то что нужно то получим не самую быструю реализацию.

[vitus_strom]

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

[Serega Doc]

Я говорю об оптимизации именно логики.
Потому что сложные конечные автоматы могут синтезироватся не так как по теории.

Вот скажем я пытался найти наиболее оптимальную схему сравнения - вышло что лучше использовать LPM блок
А суматор лучше написать как "+"

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

[vitus_strom]

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

[Serega Doc]

Что вы называете уровни логики?