Перейти к содержанию
    

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

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

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

post-78485-1499029326_thumb.png

 

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

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:

post-78485-1499029546_thumb.png

 

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

post-78485-1499029581_thumb.png

 

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

 

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

post-78485-1499029918_thumb.png

post-78485-1499029927_thumb.png

 

Quartus 9.1sp2, Cyclone4

Изменено пользователем Jackov

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

post-78485-1499116816_thumb.png

post-78485-1499116829_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Изменено пользователем Грендайзер

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По сути вопроса - что мешает посмотреть подробную задержку 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

P.S. Кстати, худший случай ещё и от температуры и напряжения питания может скакать, так что надо повнимательней Вам почитать для каких условий TQ пути анализирует.

Изменено пользователем Грендайзер

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Сама задержка, как физическое явление, зависит лишь от частоты сигнала и длинны "линии задержки", тобиш провода. Но вот 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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Отчёты:

post-78485-1499293537_thumb.pngpost-78485-1499293550_thumb.png

Изменено пользователем Jackov

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Изменено пользователем Грендайзер

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Отчёты:

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

Изменено пользователем Jackov

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Ограничения все что в первом посте есть, не более.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...