[Jackov 1]

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

А скорее всего это не джитер, для джитера, если правильно помню, существует специальный констрейн. Наверно под Uncertainty имеется ввиду технологический разброс при производстве. Хотя если взять разницу между 5,26нс и 5,474нс получается более 200пс, как-то многовато.

 

Имеется ввиду то, что у Вас сигнал C проходит через 8 последовательных логических блоков lcell перед тактированием inst1, которые должны добавить задержку (судя по отчету задержки для данных - там их такое же кол-во) порядка 4.5нс. В данном случае разница меньше 1нс.

А разве Ква не мог выровнять время прохождения сигналов до тактовых входов?

 

Интересно было бы увидеть схему после синтеза и фиттера (RTL viewer/technology map viewer).

Ну теперь только в ПН.

[Грендайзер 0]

А скорее всего это не джитер, для джитера, если правильно помню, существует специальный констрейн.

Uncertainty если не задана, на сколько я помню, по умолчанию имеет не то 20 не то 10 пс. Но задержка сигнала в линии плавает от таких параметров как температура и напряжение питания. TQ считает плохие случаи - питание просело до минимально допустимого - плиса нагрелась (остыла). Питание скакнуло до максимально допустимого... и т.д. Кстати, эти параметры - температура и напряжения (крайние значения) можно выставить в настройках квартуса.

 

А разве Ква не мог выровнять время прохождения сигналов до тактовых входов?

Мог, но лишь за счёт задержки в проводе, а как я писал ранее этого из картинок не видно. Тут надо смотреть топологию размещения элементов на кристалле.

Изменено 8 июля, 2017 пользователем Грендайзер

[Timmy 1]

Почему при анализе пути от inst0 до inst1 у запускающего триггера inst0 значение Clock delay составляет 5,474, а при анализе пути от inst1 до inst0 у этого же самого триггера уже 5,26? С триггером inst1 такая же история.

Для launch клока берётся max delay, для latch клока берётся min delay, всё в одном corner, чтобы учитывался разброс времени прохождения клока до разных триггеров(это не джиттер, кстати).

[Jackov 1]

Тут надо смотреть топологию размещения элементов на кристалле.

Синие это LCELL-буферы в тактовой цепи. На LogicLock-регион внимания не обращайте.

Изменено 11 июля, 2017 пользователем Jackov

[Shivers 0]

Почему при анализе пути от inst0 до inst1 у запускающего триггера inst0 значение Clock delay составляет 5,474, а при анализе пути от inst1 до inst0 у этого же самого триггера уже 5,26? С триггером inst1 такая же история.

У вас там констрейнт стоит derive_clock_uncertainty. Это значит, что вычисляется джиттер (дрожание фазы) клока.

 

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

Можно посчитать этот джиттер: (5,474-5,26)/2 = +/-107 пс.

 

[Jackov 1]

Ну в целом я понял, TQ не все поправки на диаграммах рисует, чем и создаёт непонятки.

 

А вот по поводу джитера, это же характеристика генератора, откуда TQ может её знать, или он берёт некое стандартное усреднённое значение?

[Shivers 0]

Просто, надо time_report смотреть подробный, а не временные диаграммы.

 

По поводу джиттера - есть куча причин, откуда он берется, кроме джиттера генератора. Клоковое дерево ведь не в идеальных условиях находится: шумы, наводки, просадка питания - все влияет.

[Jackov 1]

Просто, надо time_report смотреть подробный, а не временные диаграммы.

А где посмотреть? Не нашёл того места где он подробно расписывает из чего формируется задержка тактового сигнала.

[bogaev_roman 0]

А где посмотреть? Не нашёл того места где он подробно расписывает из чего формируется задержка тактового сигнала.

В сообщении 4 я Вам описал, каким образом сам смотрю подробно задержки. Цифры, которые увидите, будут отличаться от тех, которые приведены при расчете setup/hold.

[Jackov 1]

В сообщении 4 я Вам описал, каким образом сам смотрю подробно задержки. Цифры, которые увидите, будут отличаться от тех, которые приведены при расчете setup/hold.

Я что-то похожее делал, в сообщении 11 результат. Это не то?

 

[bogaev_roman 0]

Я что-то похожее делал, в сообщении 11 результат. Это не то?

Вы выводили временную диаграмму от inst0 до inst1 и наоборот, там действительно есть путь и для клокового сигнала, но он нераскрыт (почему так для меня лично загадка) - только общее время. Интересен полный, подробный путь сигнала от пина до клокового входа триггера.

[Jackov 1]

В сообщении 4 я Вам описал, каким образом сам смотрю подробно задержки. Цифры, которые увидите, будут отличаться от тех, которые приведены при расчете setup/hold.

Таки да, отличаются.

Но как и из чего он получает 5,474 и 5,26, о которых говорили в начале, видимо, это непостижимая тайна.

[bogaev_roman 0]

Таки да, отличаются.

Но как и из чего он получает 5,474 и 5,26, о которых говорили в начале, видимо, это непостижимая тайна.

Ну теперь понятнее немного стало, у Вас клок идет по обычной сигнальной дорожке, отсюда при вычислении setup такой разброс Clock Setup Uncertainty получается. Попробуйте вытащить все-таки путь для расчета setup - в окне TQ запустить report setup summary (report/slack) и в выделенной частоте report timing (в окне data path путь клока clock path должен быть расписан полностью, включая clock uncertainty и clock pessimism).

ЗЫ. А вообще смысл такого подробного анализа Вам для чего требуется? Компилятор вообще говоря работает по умолчанию при мерно так - временные ограничения выполняются во всех временных моделях, значит все будет работать. А запас 0.01нс или полпериода (5 нс в данном случае) не важен.