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

Получилось что после синтеза и роутинга всего автомата max F=171 MHz
а ести синтезировать отдельную команду (самую сложную) то F=158 MHz

Кто нибудь встречался с такими ситуациями?

Пользую Sinplyfi 8.0 -> Quartus 4.2 SP1 Время оценено в Quartus
Кристал Cyclon -8 speed

Заранее спасибо!

Нужно попробовать проанализировать критический путь (путь с наибольшей задержкой). Вполне возможно, что при реализации самой сложной команды отдельно длина этого пути возрастает -> частота падает.

PS: Или можно сравнить результаты синтеза в RTL для обоих вариантов.

Произведено сравнение критических путей в Synplify.

Для обоих блоков это один и тот же счетчик. Различия только в одной логической цепочке, но по количеству последовательно включенных лутов это то же количество.


Вообще ничего не понимаю.

Один и тот же счетчик а разницав скорости более 10 MHz

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

Ну по квартусу в одних и тех же цепях есть различия во времени
А синплифай не может точно определить время так как в проекте используются ЛПМ блоки.
A->B
T1=5.739 - весь блок
T2=6.212 - часть блока (одна команда)

T2-T1=0,473 ns

И таких различий много

Т. е. можно сделать вывод что падение частоты обусловлено другим размещением в кристале?

Если применить LPM счетчик то скорость изменяся не должна?

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



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

PS: На время, определяемое Synplify, особенно ориентироваться не стоит, т.к. это "идеальное" время, в то время как реальное размещение на кристалле вносит в полученное Synplify значение существенные коррективы.

Временные ограничения есть только на CLK сигнал.

И в какой програме надо задавать constrain файл в Synplify или в Quartus?

Какие временные ограничения Вы задали для CLK? А задавать их, я считаю, нужно в Quartus'e. Ведь интересен результат после PAR.

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

Во время синтеза самой сложной команды отдельно, Synplify рассматривает этот блок как единое целое и не уделяет его оптимизации достаточно внимания, если блок вписывается в констраины клока с большим запасом или заведомо не вписывается в них, тоже с большим запасом. Если же синтезировать все устройство целиком, то остальная часть устройства как более быстрая вынуждает синтезатор "подтягивать" скорость более медленного блока к стандартам более быстрой части, положительно влияя на результирующую частоту. Такое у меня возникло впечатление во время работы с этим синтезатором.

Теперь откуда берется более высокая скорость. Просто используются более быстрые роутинговые ресурсы в микросхеме. Сумматор, входящий в состав счетчика можно скомпоновать/развести по разному. Квартус всегда использует самые быстрые переносы для синтеза, Synplify, обычно, пытается с начала экономить и использует высокоскоростную реализацию только если это совершенно необходимо. Потому при синтезе Synplify в нетлисте больших перекосов по скорости обычно нет, тогда как Квартусом обычно получается самый быстрый проект, страдающий некоторой неравномерностью быстродействия блоков и ассинхронных путей.

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


2 makc

Временные ограничения автоматически передаются из Synplify Pro 8.0 в Quartus II 4.2 SP1. Я задавал 500 MHz. В Quartus II 4.2 SP1 я проверял этот параметр.

Может смотреть по результатам моделирования?

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

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

Synplify:
1.Tech. View
2.Timing Analist.
3. from "all" to "all".
4.Выбираем Все порты в дереве и на диаграмме говорим expand path.
В результате получаем логическую диаграмму с временными параметрами, которую анализируем.

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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