[Serega Doc 0]

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

 

Получилось что после синтеза и роутинга всего автомата max F=171 MHz

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

 

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

 

Пользую Sinplyfi 8.0 -> Quartus 4.2 SP1 Время оценено в Quartus

Кристал Cyclon -8 speed

 

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

[makc 197]

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

 

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

[Serega Doc 0]

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

 

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

 

 

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

 

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

[makc 197]

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

 

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

 

 

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

 

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

<{POST_SNAPBACK}>

 

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

[Serega Doc 0]

Ну по квартусу в одних и тех же цепях есть различия во времени

А синплифай не может точно определить время так как в проекте используются ЛПМ блоки.

A->B

T1=5.739 - весь блок

T2=6.212 - часть блока (одна команда)

 

T2-T1=0,473 ns

 

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

 

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

 

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

[makc 197]

Ну по квартусу в одних и тех же цепях есть различия во времени

А синплифай не может точно определить время так как в проекте используются ЛПМ блоки.

A->B

T1=5.739        - весь блок

T2=6.212        - часть блока (одна команда)

 

T2-T1=0,473 ns

 

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

 

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

<{POST_SNAPBACK}>

 

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

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

 

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

 

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

 

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

[Serega Doc 0]

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

 

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

[makc 197]

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

 

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

<{POST_SNAPBACK}>

 

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

[vetal 0]

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

[v_mirgorodsky 0]

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

 

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

[Serega Doc 0]

Хорошо теперь мне стало в общем понятно почему упала частота.

Но проблема то осталась. Мне необходимо найти самые медленные цепи в моем блоке.

Хотелось бы увидеть самую медленную цепь для каждой команды а не для блока в целом.

Подскажите как лучше всего проводить данный анализ.

 

 

2 makc

 

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

[kas 0]

Хорошо теперь мне стало в общем понятно почему упала частота.

Но проблема то осталась. Мне необходимо найти самые медленные цепи в моем блоке.

Хотелось бы увидеть самую медленную цепь для каждой команды а не для блока в целом.

Подскажите как лучше всего проводить данный анализ.

 

 

2 makc

 

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

<{POST_SNAPBACK}>

 

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

[makc 197]

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

<{POST_SNAPBACK}>

 

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

[Serega Doc 0]

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

[vetal 0]

Synplify:

1.Tech. View

2.Timing Analist.

3. from "all" to "all".

4.Выбираем Все порты в дереве и на диаграмме говорим expand path.

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