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

Получилось что после синтеза и роутинга всего автомата 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.
В результате получаем логическую диаграмму с временными параметрами, которую анализируем.