[rrlagic 0]

Здравствуйте!

У меня проект на Spartan-3. Пользуюсь ISE 11.5.

Для работы мне требуется два клока. Поэтому входной клок 122.88 МГц я завожу на DCM и уже с него в дизайн поступают все тот же 122.88 МГц и деленный на 4, то есть 30.72 МГц. Для входного клока я описываю его период. Для derivative констрейнты вычисляются автоматически. Меня смущает цифра максимальной частоты, которая получается для Post Place&Route Timing. Вот фрагмент отчета:

Derived Constraint Report
Derived Constraints for TS_clk_in
+-------------------------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------+
|                               |   Period    |       Actual Period       |      Timing Errors        |      Paths Analyzed       |
|           Constraint          | Requirement |-------------+-------------|-------------+-------------|-------------+-------------|
|                               |             |   Direct    | Derivative  |   Direct    | Derivative  |   Direct    | Derivative  |
+-------------------------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------+
|TS_clk_in                      |      8.138ns|      5.987ns|      8.124ns|            0|            0|            0|      1217843|
| TS_iLTE_CLK_CLK0_BUF          |      8.138ns|      2.376ns|          N/A|            0|            0|            0|            0|
| TS_iLTE_CLK_CLKDV_BUF         |     24.414ns|      2.376ns|          N/A|            0|            0|            0|            0|
| TS_iLTE_CLK_CLK0_BUF_0        |      8.138ns|      2.376ns|          N/A|            0|            0|            0|            0|
| TS_iLTE_CLK_CLKDV_BUF_0       |     32.552ns|      2.376ns|          N/A|            0|            0|            0|            0|
| TS_iLTE_CLK_CLK0_BUF_1        |      8.138ns|      8.124ns|          N/A|            0|            0|      1198352|            0|
| TS_iLTE_CLK_CLKDV_BUF_1       |     32.552ns|     32.108ns|          N/A|            0|            0|        19491|            0|
+-------------------------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------+

All constraints were met.


Timing summary:
---------------

Timing errors: 0  Score: 0  (Setup/Max: 0, Hold: 0)

Constraints cover 1218397 paths, 0 nets, and 132950 connections

Design statistics:
   Minimum period:  32.108ns{1}   (Maximum frequency:  31.145MHz)
   Minimum input required time before clock:   2.787ns

Судя по "All constraints were met" все у меня получилось. Но цифра "Maximum frequency: 31.145MHz" мне непонятна. Я проверил, 31.145MHz - это 1/32.108ns, который есть достижимый период для деленного клока. А я бы хотел получить максимальную цифру для входного клока... Научите, плз, как правильно это делать.

 

Спасибо.

[DmitryR 0]

У вас эта цифра есть в таблице, 8.124.

[rrlagic 0]

У вас эта цифра есть в таблице, 8.124.

Спасибо!

Я так понял, что на цифру "Maximum frequency" и не нужно смотреть, а правильнее будет анализировать таблицу достигнутых периодов и самому пересчитывать в частоты?

[Beby 4]

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

В окне Process выбираем Implementation ->Place&Route->Generate Post-Place&Route Static Timing - тыкаем правой кнопкой и выбираем Properties.... Тут ставил галочку Perform Advanced Analysis - Потом смотрим временной отчёт (и при необходимости читаем в документации, что это за такой Advanced Timing Analysis).

 

Но даже эта процедура не даст вам ответ о максимально возможной частоте, на которую возможно развести Ваш проект: Вы задали constraint - как только P&R его выполнил, то улучшения разводки оканчиваются. Весьма вероятно, что можно достичь и большей частоты, но если все требования уже выполнены, то "зачем же тогда тратить время на улучшение проекта ??". Поэтому остаётся только потихоньку ужесточать constraint и поглядывать - когда же время на разводку начинает резко увеличиваться...

[rrlagic 0]

Но даже эта процедура не даст вам ответ о максимально возможной частоте, на которую возможно развести Ваш проект: Вы задали constraint - как только P&R его выполнил, то улучшения разводки оканчиваются.

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

 

По-видимому, не стоит обращать внимания на помянутую цифру, а обложить констрейнами все важные пути и убедиться в их удовлетворении.

[bogaev_roman 0]

С этой позиции неверно спрашивать о максимальной возможной частоте для проекта.

 

По-видимому, не стоит обращать внимания на помянутую цифру, а обложить констрейнами все важные пути и убедиться в их удовлетворении.

 

Смотрите на максимальную частоту после синтеза, выше нее не прыгнуть, но приблизиться можно :)

Изменено 17 июля, 2010 пользователем bogaev_roman

[_sda 0]

Смотрите на максимальную частоту после синтеза, выше нее не прыгнуть, но приблизиться можно :)

 

Да ну?

Boris_TS правильно говорит : как только P&R его выполнил, то улучшения разводки оканчиваются

Так что максимальная частота зависит от указанных констрейнов.

[Beby 4]

Смотрите на максимальную частоту после синтеза, выше нее не прыгнуть, но приблизиться можно :)

Гы-Гы. А когда припекало, то я заметно (более 10%) превышал частоту, указанную XST апосля синтеза, т.к. XST для оценки задержки берёт типовую задержку линии связи. А если самое тяжёлое место (с точки зрения XST) является хорошо оптимизированным RPM'ом (собственно говоря: для этого они и нужны), то задержки оказываются меньше типовых, а частота - выше.

[VladimirB 1]

Гы-Гы. А когда припекало, то я заметно (более 10%) превышал частоту, указанную XST апосля синтеза, т.к. XST для оценки задержки берёт типовую задержку линии связи. А если самое тяжёлое место (с точки зрения XST) является хорошо оптимизированным RPM'ом (собственно говоря: для этого они и нужны), то задержки оказываются меньше типовых, а частота - выше.

+500

для XST аналогично.

Но может человек Симплифаем пользуется? Как интересно у него с оценкой скорости проекта после синтеза?

[bogaev_roman 0]

Гы-Гы. А когда припекало, то я заметно (более 10%) превышал частоту, указанную XST апосля синтеза, т.к. XST для оценки задержки берёт типовую задержку линии связи. А если самое тяжёлое место (с точки зрения XST) является хорошо оптимизированным RPM'ом (собственно говоря: для этого они и нужны), то задержки оказываются меньше типовых, а частота - выше.

Честно говоря, никогда не видел, чтоб максимальная тактовая частота после разводки была выше нежели после синтеза (ну может от проекта зависит). Синтез же вообще не учитывает констрейны. Суммарная задержка после синтеза дейсвительно складывается из задержек на элементах (они вообще фиксированные) и типовых задержек на соединениях. Я так понимаю, Вы просто сигнал пускали по скоростным линиям. Ну а тогда вопрос: сколько разярдов (ну или сколько сигналов) можно по ним пустить в пределах одного домена?

Но может человек Симплифаем пользуется? Как интересно у него с оценкой скорости проекта после синтеза?

XST пользовался.

To _Anatoliy

как только P&R его выполнил, то улучшения разводки оканчиваются

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

Если я не прав, поправьте.

Изменено 19 июля, 2010 пользователем bogaev_roman

[Beby 4]

Я так понимаю, Вы просто сигнал пускали по скоростным линиям. Ну а тогда вопрос: сколько разярдов (ну или сколько сигналов) можно по ним пустить в пределах одного домена?

XST ошибался при оценке задержек в линиях в следующем случае: между элементами (особым образом подобранными) сигнал передаётся через Pin Wires (см. FPGA Editor), а XST для этой связи берёт задержку от Local Lines. Соответственно, ни про какую разрядность Pin Wires говорить невозможно, можно только говорить что: для конкретной FPGA можно сделать вот такое техническое ухищрение.

[bogaev_roman 0]

XST ошибался при оценке задержек в линиях в следующем случае: между элементами (особым образом подобранными) сигнал передаётся через Pin Wires (см. FPGA Editor), а XST для этой связи берёт задержку от Local Lines. Соответственно, ни про какую разрядность Pin Wires говорить невозможно, можно только говорить что: для конкретной FPGA можно сделать вот такое техническое ухищрение.

Я правильно понимаю, что Вы сейчас говорите о максимальной задержке от пина до регистра или другого пина ну или наоборот, а не о задерже регитр-логика-регистр?

Какое техническое ухищрение Вы можете предложить, если в схеме стоит, например, БИХ фильтр с обратной связью и разрядностью 20 бит (при этом суммарная задержка всех сигналов приблизительно одинаковая)?

Изменено 19 июля, 2010 пользователем bogaev_roman

[Beby 4]

Я правильно понимаю, что Вы сейчас говорите о максимальной задержке от пина до регистра или другого пина ну или наоборот, а не о задерже регитр-логика-регистр?

Нет, не правильно - я же русским языком написал:

...между элементами (особым образом подобранными) сигнал передаётся через Pin Wires (см. FPGA Editor)...

Ключевая фраза: см. FPGA Editor - а Вы поленились...

 

Ну, тогда прийдётся ткнуть Вас в FPGA Editor: если его всё-таки запустить, и как следует рассмотреть соединения между различными элементами, то можно обнаружить, что их аж 3 вида:

Pin Wires - зелёненкие такие,

Local Lines - серые (основной разводочный ресурс),

Long Lines - розовые (длинные и специфические).

 

Какое техническое ухищрение Вы можете предложить, если в схеме стоит, например, БИХ фильтр с обратной связью и разрядностью 20 бит (при этом суммарная задержка всех сигналов приблизительно одинаковая)?

Опять-таки, запускаем FPGA Editor и рассматриваем проблемные связи,.. ищем: а нет ли этих самых былёненьких линий соединяющих соседние Slice/CLB ?, да еще так, чтобы их можно было использовать для проблемных связей - далее плотненько думаем и используем RLOC и, если очень сильно прижало, то и DIRECTED_ROUTING. А иногда необходимо использовать Long Lines для проблемных связей - а у них свои заморочки...

[bogaev_roman 0]

Ну, тогда прийдётся ткнуть Вас в FPGA Editor: если его всё-таки запустить, и как следует рассмотреть соединения между различными элементами, то можно обнаружить, что их аж 3 вида:

Pin Wires - зелёненкие такие,

Local Lines - серые (основной разводочный ресурс),

Long Lines - розовые (длинные и специфические).

 

Теперь понял, спасибо :smile3046: .