|
TimeQuest, разные задержеки тактового сигнала |
|
|
|
Jul 2 2017, 21:16
|
Местный
  
Группа: Участник
Сообщений: 282
Регистрация: 25-09-13
Из: Н.Новгород
Пользователь №: 78 485

|
Здравствуйте. Решил запустить анализ проекта. Кое-что насторожило. Собрал тестовый проект:
Констрейны выглядят так: Код 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
|
|
|
|
|
Jul 3 2017, 21:22
|
Местный
  
Группа: Участник
Сообщений: 282
Регистрация: 25-09-13
Из: Н.Новгород
Пользователь №: 78 485

|
Цитата(Грендайзер @ Jul 3 2017, 09:56)  Ну в принципе, картина вполне реальная. Начнём с того, что все LCELL оптимизатор мог почикать LCELL не почикал, проверял. Цитата(Грендайзер @ Jul 3 2017, 09:56)  Таким образом задержка распространения клока набегает лишь в проводах... Так вопрос в том что: почему для одного и того же триггера при анализе разных путей задержка разная?
|
|
|
|
|
Jul 4 2017, 07:43
|
Профессионал
    
Группа: Свой
Сообщений: 1 067
Регистрация: 20-10-09
Из: Химки
Пользователь №: 53 082

|
Цитата(Jackov @ Jul 4 2017, 00:22)  Так вопрос в том что: почему для одного и того же триггера при анализе разных путей задержка разная? По сути вопроса - что мешает посмотреть подробную задержку clock delay? В таймквесте копируете название конечного триггера, вызываете report patch, в вкладке To копируете название, увеличиваете кол-во путей и находите в списке путь тактовой. По описанию - Ваш алгоритм, скажем так - не совсем типичен для архитектуры ПЛИС. Я так понимаю требуется задержать тактовую на определенное время, если так, то это время будет плавать - Таймквест выдал задержки для конкретной временной модели (по умолчанию медленной), выбрав другую, задержка существенно поменяется. Кроме этого, если Ваша логика не имеет физической привязки к координатам (или не прописаны определенные временные ограничения) результат будет меняться, т.к. ячейки могут располагаться на кристалле где угодно (от этого, кстати, задержка у Вас и разная). И еще не очень хорошо - с такой реализацией тактовая частота сначала поползет по сигнальной дорожке клокового дерева , потом перескочет через буфер на обычную, потом опять на клоковую (отсюда такая большая общая задержка, задумка изначально такая была?).
|
|
|
|
|
Jul 4 2017, 09:17
|
Местный
  
Группа: Участник
Сообщений: 358
Регистрация: 18-04-11
Пользователь №: 64 451

|
Цитата(bogaev_roman @ Jul 4 2017, 11:18)  Сделаю предположение, что в анализе величины clock setup/hold uncertainty для клоков разные... Пожалуй, Вы правы. Вообще говоря, вроде как квартус оценивает наихудший из возможных вариантов, и, в этом случае для разных путей и впрямь uncertainty может иметь разные значения, ну а следовательно и задержка будет разная...
|
|
|
|
|
Jul 4 2017, 23:19
|
Местный
  
Группа: Участник
Сообщений: 282
Регистрация: 25-09-13
Из: Н.Новгород
Пользователь №: 78 485

|
Цитата(bogaev_roman @ Jul 4 2017, 10:43)  По сути вопроса - что мешает посмотреть подробную задержку clock delay? В таймквесте копируете название конечного триггера, вызываете report patch, в вкладке To копируете название, увеличиваете кол-во путей и находите в списке путь тактовой. Цитата(Грендайзер @ Jul 4 2017, 10:48)  P.S. TimeQest умеет выводить отчёт о том, где и какая задержка появилась для выбранного пути. Попробуйте там глянуть. Проект на работе, сейчас показать не могу. Цитата(bogaev_roman @ Jul 4 2017, 10:43)  Я так понимаю требуется задержать тактовую на определенное время Нет-нет, LCELL-буферы на тактовом сигнале исключительно для наглядности, чтобы значения задержек друг от друга отличались, иначе Квартус триггеры располагает так, что задержки получаются одинаковыми. Цитата(bogaev_roman @ Jul 4 2017, 11:18)  Сделаю предположение, что в анализе величины clock setup/hold uncertainty для клоков разные (по факту, если lcell действительно остались, то клоки разные и идут разными путями - один по обычной дорожке - у него неопределенность другая выше ), для нормального анализа нужен полный отчет. Цитата(Грендайзер @ Jul 4 2017, 12:17)  Пожалуй, Вы правы. Вообще говоря, вроде как квартус оценивает наихудший из возможных вариантов, и, в этом случае для разных путей и впрямь uncertainty может иметь разные значения, ну а следовательно и задержка будет разная... Я не про разницу между setup и hold. Посмотрите картинки в 3-тем посте. Делаем проверку только по setup. Для пути inst0->inst1 задержка для триггера inst0 составляет 5,474, а для пути inst1->inst0 для этого же самого триггера inst0 уже 5,26. Обе картинки - проверка по setup, а задержка для одного и того же триггера разная. Она же не может меняться в зависимости от того какой путь сейчас анализирует TQ, она зависит от размещения этого триггера на кристалле и только.
Сообщение отредактировал Jackov - Jul 4 2017, 23:20
|
|
|
|
|
Jul 5 2017, 07:01
|
Местный
  
Группа: Участник
Сообщений: 358
Регистрация: 18-04-11
Пользователь №: 64 451

|
Цитата(Jackov @ Jul 5 2017, 02:19)  Я не про разницу между setup и hold. Она же не может меняться в зависимости от того какой путь сейчас анализирует TQ, она зависит от размещения этого триггера на кристалле и только. Сама задержка, как физическое явление, зависит лишь от частоты сигнала и длинны "линии задержки", тобиш провода. Но вот TQ под этим делом может подразумевать задержка в проводе + нестабильность тактовой частоты. Тогда, в зависимости от того какой триггер является "запускающим" а какой "запускаемым" и в зависимости от того, что там после них понавтыкано, худший случай расчёта времянки может меняться от того, когда и на какой триггер придёт фронт. Например, если FF1 - запускающий, а FF2-запускаемый, то очевидно, что худший случай (по setup) наступит, когда на FF1 фронт придёт быстро, а на FF2 с задержкой. Второй случай, FF2 - запускающий, FF1 - запускаемый. Картина худшего случая поменялась. Т.к. длинна провода, и частота - неизменны, значит картину можно испортить лишь добавив нестабильность частоты. Вот у Вас задержка и скачет. P.S. Кстати, худший случай ещё и от температуры и напряжения питания может скакать, так что надо повнимательней Вам почитать для каких условий TQ пути анализирует.
Сообщение отредактировал Грендайзер - Jul 5 2017, 07:15
|
|
|
|
|
Jul 5 2017, 07:57
|
Профессионал
    
Группа: Свой
Сообщений: 1 067
Регистрация: 20-10-09
Из: Химки
Пользователь №: 53 082

|
Цитата(Грендайзер @ Jul 5 2017, 10:01)  Сама задержка, как физическое явление, зависит лишь от частоты сигнала и длинны "линии задержки", тобиш провода. Но вот 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
|
|
|
|
|
Jul 6 2017, 22:40
|
Местный
  
Группа: Участник
Сообщений: 282
Регистрация: 25-09-13
Из: Н.Новгород
Пользователь №: 78 485

|
Цитата(Грендайзер @ Jul 6 2017, 09:59)  Да и задержка до второго триггера непропорциональна мала по сравнению с той, что набегает для первого, хотя на тактовой линии столько логики понапихано. В смысле? 5,26 и 6,16, вроде сопоставимы. Цитата(bogaev_roman @ Jul 6 2017, 10:33)  Каким образом частота на схему идет и что Вы прописываете во временных ограничениях (кроме периода в 10МГц)? Ограничения все что в первом посте есть, не более. То что на картинке - верхний уровень, тактовая частота с входной ноги поступает, притом ногу явно не указывал, Ква сам выбрал какую-то.
Сообщение отредактировал Jackov - Jul 6 2017, 22:42
|
|
|
|
|
Jul 7 2017, 07:42
|
Профессионал
    
Группа: Свой
Сообщений: 1 067
Регистрация: 20-10-09
Из: Химки
Пользователь №: 53 082

|
Цитата(Jackov @ Jul 7 2017, 01:40)  В смысле? 5,26 и 6,16, вроде сопоставимы. Имеется ввиду то, что у Вас сигнал C проходит через 8 последовательных логических блоков lcell перед тактированием inst1, которые должны добавить задержку (судя по отчету задержки для данных - там их такое же кол-во) порядка 4.5нс. В данном случае разница меньше 1нс. Цитата Ограничения все что в первом посте есть, не более. То что на картинке - верхний уровень, тактовая частота с входной ноги поступает, притом ногу явно не указывал, Ква сам выбрал какую-то. Вот здесь странность какая-то в отчете - timequest должен отобразить отсчет нулевой точки от входного пина и дальше расписать по каким ячейкам сигнал проходит до клокового входа триггера, а в отчете он как будто сразу заведен на клоковый вход с заданной начальной задержкой - первый раз такое вижу. Интересно было бы увидеть схему после синтеза и фиттера (RTL viewer/technology map viewer).
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|