Jackov 1 7 июля, 2017 Опубликовано 7 июля, 2017 · Жалоба Хотите сказать, что TQ, в зависимости от того приёмный это триггер, или передающий, добавляет значение джитера, которое не показывает на диаграммах. Ну ок, надо подумать.А скорее всего это не джитер, для джитера, если правильно помню, существует специальный констрейн. Наверно под Uncertainty имеется ввиду технологический разброс при производстве. Хотя если взять разницу между 5,26нс и 5,474нс получается более 200пс, как-то многовато. Имеется ввиду то, что у Вас сигнал C проходит через 8 последовательных логических блоков lcell перед тактированием inst1, которые должны добавить задержку (судя по отчету задержки для данных - там их такое же кол-во) порядка 4.5нс. В данном случае разница меньше 1нс.А разве Ква не мог выровнять время прохождения сигналов до тактовых входов? Интересно было бы увидеть схему после синтеза и фиттера (RTL viewer/technology map viewer).Ну теперь только в ПН. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Грендайзер 0 8 июля, 2017 Опубликовано 8 июля, 2017 (изменено) · Жалоба А скорее всего это не джитер, для джитера, если правильно помню, существует специальный констрейн. Uncertainty если не задана, на сколько я помню, по умолчанию имеет не то 20 не то 10 пс. Но задержка сигнала в линии плавает от таких параметров как температура и напряжение питания. TQ считает плохие случаи - питание просело до минимально допустимого - плиса нагрелась (остыла). Питание скакнуло до максимально допустимого... и т.д. Кстати, эти параметры - температура и напряжения (крайние значения) можно выставить в настройках квартуса. А разве Ква не мог выровнять время прохождения сигналов до тактовых входов? Мог, но лишь за счёт задержки в проводе, а как я писал ранее этого из картинок не видно. Тут надо смотреть топологию размещения элементов на кристалле. Изменено 8 июля, 2017 пользователем Грендайзер Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Timmy 1 8 июля, 2017 Опубликовано 8 июля, 2017 · Жалоба Почему при анализе пути от inst0 до inst1 у запускающего триггера inst0 значение Clock delay составляет 5,474, а при анализе пути от inst1 до inst0 у этого же самого триггера уже 5,26? С триггером inst1 такая же история. Для launch клока берётся max delay, для latch клока берётся min delay, всё в одном corner, чтобы учитывался разброс времени прохождения клока до разных триггеров(это не джиттер, кстати). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jackov 1 11 июля, 2017 Опубликовано 11 июля, 2017 (изменено) · Жалоба Тут надо смотреть топологию размещения элементов на кристалле.Синие это LCELL-буферы в тактовой цепи. На LogicLock-регион внимания не обращайте. Изменено 11 июля, 2017 пользователем Jackov Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 12 июля, 2017 Опубликовано 12 июля, 2017 · Жалоба Почему при анализе пути от 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 13 июля, 2017 Опубликовано 13 июля, 2017 · Жалоба Ну в целом я понял, TQ не все поправки на диаграммах рисует, чем и создаёт непонятки. А вот по поводу джитера, это же характеристика генератора, откуда TQ может её знать, или он берёт некое стандартное усреднённое значение? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 13 июля, 2017 Опубликовано 13 июля, 2017 · Жалоба Просто, надо time_report смотреть подробный, а не временные диаграммы. По поводу джиттера - есть куча причин, откуда он берется, кроме джиттера генератора. Клоковое дерево ведь не в идеальных условиях находится: шумы, наводки, просадка питания - все влияет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jackov 1 20 июля, 2017 Опубликовано 20 июля, 2017 · Жалоба Просто, надо time_report смотреть подробный, а не временные диаграммы. А где посмотреть? Не нашёл того места где он подробно расписывает из чего формируется задержка тактового сигнала. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bogaev_roman 0 20 июля, 2017 Опубликовано 20 июля, 2017 · Жалоба А где посмотреть? Не нашёл того места где он подробно расписывает из чего формируется задержка тактового сигнала. В сообщении 4 я Вам описал, каким образом сам смотрю подробно задержки. Цифры, которые увидите, будут отличаться от тех, которые приведены при расчете setup/hold. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jackov 1 20 июля, 2017 Опубликовано 20 июля, 2017 · Жалоба В сообщении 4 я Вам описал, каким образом сам смотрю подробно задержки. Цифры, которые увидите, будут отличаться от тех, которые приведены при расчете setup/hold. Я что-то похожее делал, в сообщении 11 результат. Это не то? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bogaev_roman 0 24 июля, 2017 Опубликовано 24 июля, 2017 · Жалоба Я что-то похожее делал, в сообщении 11 результат. Это не то? Вы выводили временную диаграмму от inst0 до inst1 и наоборот, там действительно есть путь и для клокового сигнала, но он нераскрыт (почему так для меня лично загадка) - только общее время. Интересен полный, подробный путь сигнала от пина до клокового входа триггера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jackov 1 26 июля, 2017 Опубликовано 26 июля, 2017 · Жалоба В сообщении 4 я Вам описал, каким образом сам смотрю подробно задержки. Цифры, которые увидите, будут отличаться от тех, которые приведены при расчете setup/hold. Таки да, отличаются. Но как и из чего он получает 5,474 и 5,26, о которых говорили в начале, видимо, это непостижимая тайна. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bogaev_roman 0 27 июля, 2017 Опубликовано 27 июля, 2017 · Жалоба Таки да, отличаются. Но как и из чего он получает 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 нс в данном случае) не важен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться