TimeQuest, разные задержеки тактового сигнала Опции

[Jackov]

Здравствуйте.
Решил запустить анализ проекта. Кое-что насторожило. Собрал тестовый проект:


Констрейны выглядят так:

Код

set_time_format -unit ns -decimal_places 3
create_clock -name {C} -period 100.000 -waveform { 0.000 50.000 } [get_ports {C}]
derive_clock_uncertainty

Смотрим диаграммы проверки по Setup, сначала путь от inst0 до inst1:


теперь от inst1 до inst0:


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

Тоже самое и при проверке по Hold:




Quartus 9.1sp2, Cyclone4

Сообщение отредактировал Jackov - Jul 2 2017, 21:18

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

Ну в принципе, картина вполне реальная. Начнём с того, что все LCELL оптимизатор мог почикать (хорошо бы глянуть результат P&R). Таким образом задержка распространения клока набегает лишь в проводах... Ну а в каких там логических блоках маппер расположил триггеры, это из Ваших картинок не ясно...

[Jackov]

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

LCELL не почикал, проверял.

Таким образом задержка распространения клока набегает лишь в проводах...

Так вопрос в том что: почему для одного и того же триггера при анализе разных путей задержка разная?

[bogaev_roman]

Так вопрос в том что: почему для одного и того же триггера при анализе разных путей задержка разная?

По сути вопроса - что мешает посмотреть подробную задержку clock delay? В таймквесте копируете название конечного триггера, вызываете report patch, в вкладке To копируете название, увеличиваете кол-во путей и находите в списке путь тактовой.
По описанию - Ваш алгоритм, скажем так - не совсем типичен для архитектуры ПЛИС. Я так понимаю требуется задержать тактовую на определенное время, если так, то это время будет плавать - Таймквест выдал задержки для конкретной временной модели (по умолчанию медленной), выбрав другую, задержка существенно поменяется. Кроме этого, если Ваша логика не имеет физической привязки к координатам (или не прописаны определенные временные ограничения) результат будет меняться, т.к. ячейки могут располагаться на кристалле где угодно (от этого, кстати, задержка у Вас и разная).
И еще не очень хорошо - с такой реализацией тактовая частота сначала поползет по сигнальной дорожке клокового дерева , потом перескочет через буфер на обычную, потом опять на клоковую (отсюда такая большая общая задержка, задумка изначально такая была?).

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

Никогда эти картинки у альтеры не понимал... Если Вы уверены, что правильно интерпретируете картинку, то не иначе как мистика...
P.S. TimeQest умеет выводить отчёт о том, где и какая задержка появилась для выбранного пути. Попробуйте там глянуть.

Сообщение отредактировал Грендайзер - Jul 4 2017, 07:56

[bogaev_roman]

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

Сделаю предположение, что в анализе величины clock setup/hold uncertainty для клоков разные (по факту, если lcell действительно остались, то клоки разные и идут разными путями - один по обычной дорожке - у него неопределенность другая выше ), для нормального анализа нужен полный отчет.

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

Сделаю предположение, что в анализе величины clock setup/hold uncertainty для клоков разные...

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

[Jackov]

По сути вопроса - что мешает посмотреть подробную задержку clock delay? В таймквесте копируете название конечного триггера, вызываете report patch, в вкладке To копируете название, увеличиваете кол-во путей и находите в списке путь тактовой.

P.S. TimeQest умеет выводить отчёт о том, где и какая задержка появилась для выбранного пути. Попробуйте там глянуть.

Проект на работе, сейчас показать не могу.

Я так понимаю требуется задержать тактовую на определенное время

Нет-нет, LCELL-буферы на тактовом сигнале исключительно для наглядности, чтобы значения задержек друг от друга отличались, иначе Квартус триггеры располагает так, что задержки получаются одинаковыми.

Сделаю предположение, что в анализе величины clock setup/hold uncertainty для клоков разные (по факту, если lcell действительно остались, то клоки разные и идут разными путями - один по обычной дорожке - у него неопределенность другая выше ), для нормального анализа нужен полный отчет.

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

Я не про разницу между setup и hold. Посмотрите картинки в 3-тем посте. Делаем проверку только по setup. Для пути inst0->inst1 задержка для триггера inst0 составляет 5,474, а для пути inst1->inst0 для этого же самого триггера inst0 уже 5,26. Обе картинки - проверка по setup, а задержка для одного и того же триггера разная. Она же не может меняться в зависимости от того какой путь сейчас анализирует TQ, она зависит от размещения этого триггера на кристалле и только.

Сообщение отредактировал Jackov - Jul 4 2017, 23:20

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

Я не про разницу между setup и hold. Она же не может меняться в зависимости от того какой путь сейчас анализирует TQ, она зависит от размещения этого триггера на кристалле и только.

Сама задержка, как физическое явление, зависит лишь от частоты сигнала и длинны "линии задержки", тобиш провода. Но вот TQ под этим делом может подразумевать задержка в проводе + нестабильность тактовой частоты. Тогда, в зависимости от того какой триггер является "запускающим" а какой "запускаемым" и в зависимости от того, что там после них понавтыкано, худший случай расчёта времянки может меняться от того, когда и на какой триггер придёт фронт. Например, если FF1 - запускающий, а FF2-запускаемый, то очевидно, что худший случай (по setup) наступит, когда на FF1 фронт придёт быстро, а на FF2 с задержкой. Второй случай, FF2 - запускающий, FF1 - запускаемый. Картина худшего случая поменялась. Т.к. длинна провода, и частота - неизменны, значит картину можно испортить лишь добавив нестабильность частоты. Вот у Вас задержка и скачет.
P.S. Кстати, худший случай ещё и от температуры и напряжения питания может скакать, так что надо повнимательней Вам почитать для каких условий TQ пути анализирует.

Сообщение отредактировал Грендайзер - Jul 5 2017, 07:15

[bogaev_roman]

Сама задержка, как физическое явление, зависит лишь от частоты сигнала и длинны "линии задержки", тобиш провода. Но вот TQ под этим делом может подразумевать задержка в проводе + нестабильность тактовой частоты. Тогда, в зависимости от того какой триггер является "запускающим" а какой "запускаемым" и в зависимости от того, что там после них понавтыкано, худший случай расчёта времянки может меняться от того, когда и на какой триггер придёт фронт. Например, если FF1 - запускающий, а FF2-запускаемый, то очевидно, что худший случай (по setup) наступит, когда на FF1 фронт придёт быстро, а на FF2 с задержкой. Второй случай, FF2 - запускающий, FF1 - запускаемый. Картина худшего случая поменялась. Т.к. длинна провода, и частота - неизменны, значит картину можно испортить лишь добавив нестабильность частоты. Вот у Вас задержка и скачет.

Да, приблизительно так. Формулы из дока clock_setup_and_hold_slack_explained только для анализа setup:

Data Arrival Time = Launch Edge + Longest tCLK + µtCO + Longest tD
Data Required Time = Clock Arrival Time – µtSU – Clock Setup Uncertainty
Clock Arrival Time = Latch Edge + Shortest tCLK ‘
Clock Setup Slack = Data Required Time – Data Arrival Time

[Jackov]

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

Отчёты:


Сообщение отредактировал Jackov - Jul 5 2017, 22:26

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

Интересно. Для путей данных TQ честно указал все луты, а для тактового пути ограничесля скупой фразой clock network. Да и задержка до второго триггера непропорциональна мала по сравнению с той, что набегает для первого, хотя на тактовой линии столько логики понапихано. Может он на ней всё же почикал всё.

Сообщение отредактировал Грендайзер - Jul 6 2017, 07:02

[bogaev_roman]

Отчёты:

Каким образом частота на схему идет и что Вы прописываете во временных ограничениях (кроме периода в 10МГц)?

[Jackov]

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

В смысле? 5,26 и 6,16, вроде сопоставимы.

Каким образом частота на схему идет и что Вы прописываете во временных ограничениях (кроме периода в 10МГц)?

Ограничения все что в первом посте есть, не более.
То что на картинке - верхний уровень, тактовая частота с входной ноги поступает, притом ногу явно не указывал, Ква сам выбрал какую-то.

Сообщение отредактировал Jackov - Jul 6 2017, 22:42

[bogaev_roman]

В смысле? 5,26 и 6,16, вроде сопоставимы.

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

Ограничения все что в первом посте есть, не более.
То что на картинке - верхний уровень, тактовая частота с входной ноги поступает, притом ногу явно не указывал, Ква сам выбрал какую-то.

Вот здесь странность какая-то в отчете - timequest должен отобразить отсчет нулевой точки от входного пина и дальше расписать по каким ячейкам сигнал проходит до клокового входа триггера, а в отчете он как будто сразу заведен на клоковый вход с заданной начальной задержкой - первый раз такое вижу. Интересно было бы увидеть схему после синтеза и фиттера (RTL viewer/technology map viewer).