| |
|
  |
 Maximum frequency или научите читать Post P&R timing report |
|
|
|
|
  Jul 16 2010, 05:50
|
Группа: Участник
Сообщений: 5
Регистрация: 16-07-10
Пользователь №: 58 469
|
Здравствуйте! У меня проект на 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, который есть достижимый период для деленного клока. А я бы хотел получить максимальную цифру для входного клока... Научите, плз, как правильно это делать. Спасибо.
|
|
|
|
|
|
|
|
Jul 16 2010, 08:09
|
Группа: Участник
Сообщений: 5
Регистрация: 16-07-10
Пользователь №: 58 469
|
Цитата(DmitryR @ Jul 16 2010, 17:05)  У вас эта цифра есть в таблице, 8.124. Спасибо! Я так понял, что на цифру "Maximum frequency" и не нужно смотреть, а правильнее будет анализировать таблицу достигнутых периодов и самому пересчитывать в частоты?
|
|
|
|
|
|
|
|
Jul 17 2010, 08:13
|
Злополезный
Группа: Свой
Сообщений: 608
Регистрация: 19-06-06
Из: Russia Taganrog
Пользователь №: 18 188
|
Цитата(rrlagic @ Jul 16 2010, 09:50) А я бы хотел получить максимальную цифру для входного клока... Научите, плз, как правильно это делать. В окне Process выбираем Implementation ->Place&Route->Generate Post-Place&Route Static Timing - тыкаем правой кнопкой и выбираем Properties.... Тут ставил галочку Perform Advanced Analysis - Потом смотрим временной отчёт (и при необходимости читаем в документации, что это за такой Advanced Timing Analysis). Но даже эта процедура не даст вам ответ о максимально возможной частоте, на которую возможно развести Ваш проект: Вы задали constraint - как только P&R его выполнил, то улучшения разводки оканчиваются. Весьма вероятно, что можно достичь и большей частоты, но если все требования уже выполнены, то "зачем же тогда тратить время на улучшение проекта ??". Поэтому остаётся только потихоньку ужесточать constraint и поглядывать - когда же время на разводку начинает резко увеличиваться...
|
|
|
|
|
|
|
|
Jul 17 2010, 09:16
|
Группа: Участник
Сообщений: 5
Регистрация: 16-07-10
Пользователь №: 58 469
|
Цитата(Boris_TS @ Jul 17 2010, 17:13) Но даже эта процедура не даст вам ответ о максимально возможной частоте, на которую возможно развести Ваш проект: Вы задали constraint - как только P&R его выполнил, то улучшения разводки оканчиваются. Спасибо, очень здравая мысль. С этой позиции неверно спрашивать о максимальной возможной частоте для проекта. По-видимому, не стоит обращать внимания на помянутую цифру, а обложить констрейнами все важные пути и убедиться в их удовлетворении.
|
|
|
|
|
|
|
|
Jul 17 2010, 16:46
|
Злополезный
Группа: Свой
Сообщений: 608
Регистрация: 19-06-06
Из: Russia Taganrog
Пользователь №: 18 188
|
Цитата(bogaev_roman @ Jul 17 2010, 17:28) Смотрите на максимальную частоту после синтеза, выше нее не прыгнуть, но приблизиться можно  Гы-Гы. А когда припекало, то я заметно (более 10%) превышал частоту, указанную XST апосля синтеза, т.к. XST для оценки задержки берёт типовую задержку линии связи. А если самое тяжёлое место (с точки зрения XST) является хорошо оптимизированным RPM'ом (собственно говоря: для этого они и нужны), то задержки оказываются меньше типовых, а частота - выше.
|
|
|
|
|
|
|
|
Jul 17 2010, 17:47
|
Знающий
Группа: Свой
Сообщений: 614
Регистрация: 12-06-09
Из: рядом с Москвой
Пользователь №: 50 219
|
Цитата(Boris_TS @ Jul 17 2010, 20:46) Гы-Гы. А когда припекало, то я заметно (более 10%) превышал частоту, указанную XST апосля синтеза, т.к. XST для оценки задержки берёт типовую задержку линии связи. А если самое тяжёлое место (с точки зрения XST) является хорошо оптимизированным RPM'ом (собственно говоря: для этого они и нужны), то задержки оказываются меньше типовых, а частота - выше. +500 для XST аналогично. Но может человек Симплифаем пользуется? Как интересно у него с оценкой скорости проекта после синтеза?
|
|
|
|
|
|
|
|
Jul 19 2010, 08:37
|
Профессионал
Группа: Свой
Сообщений: 1 088
Регистрация: 20-10-09
Из: Химки
Пользователь №: 53 082
|
Цитата(Boris_TS @ Jul 17 2010, 20:46) Гы-Гы. А когда припекало, то я заметно (более 10%) превышал частоту, указанную XST апосля синтеза, т.к. XST для оценки задержки берёт типовую задержку линии связи. А если самое тяжёлое место (с точки зрения XST) является хорошо оптимизированным RPM'ом (собственно говоря: для этого они и нужны), то задержки оказываются меньше типовых, а частота - выше. Честно говоря, никогда не видел, чтоб максимальная тактовая частота после разводки была выше нежели после синтеза (ну может от проекта зависит). Синтез же вообще не учитывает констрейны. Суммарная задержка после синтеза дейсвительно складывается из задержек на элементах (они вообще фиксированные) и типовых задержек на соединениях. Я так понимаю, Вы просто сигнал пускали по скоростным линиям. Ну а тогда вопрос: сколько разярдов (ну или сколько сигналов) можно по ним пустить в пределах одного домена? Цитата Но может человек Симплифаем пользуется? Как интересно у него с оценкой скорости проекта после синтеза? XST пользовался. To _Anatoliy Цитата как только P&R его выполнил, то улучшения разводки оканчиваются Я говорил о том, что после синтеза выдается некая задержка (пусть и при типовых задержках на линиях), PaR пытается только к ней приблизиться, уже учитывая размещение элементов на плисине. Ну и при обычных условиях задержка на PaR больше или равна задержке после синтеза. Если я не прав, поправьте.
Сообщение отредактировал bogaev_roman - Jul 19 2010, 08:40
|
|
|
|
|
|
|
|
Jul 19 2010, 10:07
|
Злополезный
Группа: Свой
Сообщений: 608
Регистрация: 19-06-06
Из: Russia Taganrog
Пользователь №: 18 188
|
Цитата(bogaev_roman @ Jul 19 2010, 12:37) Я так понимаю, Вы просто сигнал пускали по скоростным линиям. Ну а тогда вопрос: сколько разярдов (ну или сколько сигналов) можно по ним пустить в пределах одного домена? XST ошибался при оценке задержек в линиях в следующем случае: между элементами (особым образом подобранными) сигнал передаётся через Pin Wires (см. FPGA Editor), а XST для этой связи берёт задержку от Local Lines. Соответственно, ни про какую разрядность Pin Wires говорить невозможно, можно только говорить что: для конкретной FPGA можно сделать вот такое техническое ухищрение.
|
|
|
|
|
|
|
|
Jul 19 2010, 10:34
|
Профессионал
Группа: Свой
Сообщений: 1 088
Регистрация: 20-10-09
Из: Химки
Пользователь №: 53 082
|
Цитата(Boris_TS @ Jul 19 2010, 14:07) XST ошибался при оценке задержек в линиях в следующем случае: между элементами (особым образом подобранными) сигнал передаётся через Pin Wires (см. FPGA Editor), а XST для этой связи берёт задержку от Local Lines. Соответственно, ни про какую разрядность Pin Wires говорить невозможно, можно только говорить что: для конкретной FPGA можно сделать вот такое техническое ухищрение. Я правильно понимаю, что Вы сейчас говорите о максимальной задержке от пина до регистра или другого пина ну или наоборот, а не о задерже регитр-логика-регистр? Какое техническое ухищрение Вы можете предложить, если в схеме стоит, например, БИХ фильтр с обратной связью и разрядностью 20 бит (при этом суммарная задержка всех сигналов приблизительно одинаковая)?
Сообщение отредактировал bogaev_roman - Jul 19 2010, 11:17
|
|
|
|
|
|
|
|
Jul 19 2010, 15:58
|
Злополезный
Группа: Свой
Сообщений: 608
Регистрация: 19-06-06
Из: Russia Taganrog
Пользователь №: 18 188
|
Цитата(bogaev_roman @ Jul 19 2010, 14:34) Я правильно понимаю, что Вы сейчас говорите о максимальной задержке от пина до регистра или другого пина ну или наоборот, а не о задерже регитр-логика-регистр? Нет, не правильно - я же русским языком написал: Цитата(Boris_TS @ Jul 19 2010, 14:07) ...между элементами (особым образом подобранными) сигнал передаётся через Pin Wires (см. FPGA Editor)... Ключевая фраза: см. FPGA Editor - а Вы поленились... Ну, тогда прийдётся ткнуть Вас в FPGA Editor: если его всё-таки запустить, и как следует рассмотреть соединения между различными элементами, то можно обнаружить, что их аж 3 вида: Pin Wires - зелёненкие такие, Local Lines - серые (основной разводочный ресурс), Long Lines - розовые (длинные и специфические). Цитата(bogaev_roman @ Jul 19 2010, 14:34) Какое техническое ухищрение Вы можете предложить, если в схеме стоит, например, БИХ фильтр с обратной связью и разрядностью 20 бит (при этом суммарная задержка всех сигналов приблизительно одинаковая)? Опять-таки, запускаем FPGA Editor и рассматриваем проблемные связи,.. ищем: а нет ли этих самых былёненьких линий соединяющих соседние Slice/CLB ?, да еще так, чтобы их можно было использовать для проблемных связей - далее плотненько думаем и используем RLOC и, если очень сильно прижало, то и DIRECTED_ROUTING. А иногда необходимо использовать Long Lines для проблемных связей - а у них свои заморочки...
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
.