Jackov 1 2 июля, 2017 Опубликовано 2 июля, 2017 (изменено) · Жалоба Здравствуйте. Решил запустить анализ проекта. Кое-что насторожило. Собрал тестовый проект: Констрейны выглядят так: 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 Изменено 2 июля, 2017 пользователем Jackov Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Грендайзер 0 3 июля, 2017 Опубликовано 3 июля, 2017 · Жалоба Ну в принципе, картина вполне реальная. Начнём с того, что все LCELL оптимизатор мог почикать (хорошо бы глянуть результат P&R). Таким образом задержка распространения клока набегает лишь в проводах... Ну а в каких там логических блоках маппер расположил триггеры, это из Ваших картинок не ясно... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jackov 1 3 июля, 2017 Опубликовано 3 июля, 2017 · Жалоба Ну в принципе, картина вполне реальная. Начнём с того, что все LCELL оптимизатор мог почикать LCELL не почикал, проверял. Таким образом задержка распространения клока набегает лишь в проводах... Так вопрос в том что: почему для одного и того же триггера при анализе разных путей задержка разная? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bogaev_roman 0 4 июля, 2017 Опубликовано 4 июля, 2017 · Жалоба Так вопрос в том что: почему для одного и того же триггера при анализе разных путей задержка разная? По сути вопроса - что мешает посмотреть подробную задержку clock delay? В таймквесте копируете название конечного триггера, вызываете report patch, в вкладке To копируете название, увеличиваете кол-во путей и находите в списке путь тактовой. По описанию - Ваш алгоритм, скажем так - не совсем типичен для архитектуры ПЛИС. Я так понимаю требуется задержать тактовую на определенное время, если так, то это время будет плавать - Таймквест выдал задержки для конкретной временной модели (по умолчанию медленной), выбрав другую, задержка существенно поменяется. Кроме этого, если Ваша логика не имеет физической привязки к координатам (или не прописаны определенные временные ограничения) результат будет меняться, т.к. ячейки могут располагаться на кристалле где угодно (от этого, кстати, задержка у Вас и разная). И еще не очень хорошо - с такой реализацией тактовая частота сначала поползет по сигнальной дорожке клокового дерева , потом перескочет через буфер на обычную, потом опять на клоковую (отсюда такая большая общая задержка, задумка изначально такая была?). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Грендайзер 0 4 июля, 2017 Опубликовано 4 июля, 2017 (изменено) · Жалоба Никогда эти картинки у альтеры не понимал... Если Вы уверены, что правильно интерпретируете картинку, то не иначе как мистика... P.S. TimeQest умеет выводить отчёт о том, где и какая задержка появилась для выбранного пути. Попробуйте там глянуть. Изменено 4 июля, 2017 пользователем Грендайзер Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bogaev_roman 0 4 июля, 2017 Опубликовано 4 июля, 2017 · Жалоба Никогда эти картинки у альтеры не понимал... Если Вы уверены, что правильно интерпретируете картинку, то не иначе как мистика... Сделаю предположение, что в анализе величины clock setup/hold uncertainty для клоков разные (по факту, если lcell действительно остались, то клоки разные и идут разными путями - один по обычной дорожке - у него неопределенность другая выше ), для нормального анализа нужен полный отчет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Грендайзер 0 4 июля, 2017 Опубликовано 4 июля, 2017 · Жалоба Сделаю предположение, что в анализе величины clock setup/hold uncertainty для клоков разные... Пожалуй, Вы правы. Вообще говоря, вроде как квартус оценивает наихудший из возможных вариантов, и, в этом случае для разных путей и впрямь uncertainty может иметь разные значения, ну а следовательно и задержка будет разная... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jackov 1 4 июля, 2017 Опубликовано 4 июля, 2017 (изменено) · Жалоба По сути вопроса - что мешает посмотреть подробную задержку 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, она зависит от размещения этого триггера на кристалле и только. Изменено 4 июля, 2017 пользователем Jackov Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Грендайзер 0 5 июля, 2017 Опубликовано 5 июля, 2017 (изменено) · Жалоба Я не про разницу между setup и hold. Она же не может меняться в зависимости от того какой путь сейчас анализирует TQ, она зависит от размещения этого триггера на кристалле и только. Сама задержка, как физическое явление, зависит лишь от частоты сигнала и длинны "линии задержки", тобиш провода. Но вот TQ под этим делом может подразумевать задержка в проводе + нестабильность тактовой частоты. Тогда, в зависимости от того какой триггер является "запускающим" а какой "запускаемым" и в зависимости от того, что там после них понавтыкано, худший случай расчёта времянки может меняться от того, когда и на какой триггер придёт фронт. Например, если FF1 - запускающий, а FF2-запускаемый, то очевидно, что худший случай (по setup) наступит, когда на FF1 фронт придёт быстро, а на FF2 с задержкой. Второй случай, FF2 - запускающий, FF1 - запускаемый. Картина худшего случая поменялась. Т.к. длинна провода, и частота - неизменны, значит картину можно испортить лишь добавив нестабильность частоты. Вот у Вас задержка и скачет. P.S. Кстати, худший случай ещё и от температуры и напряжения питания может скакать, так что надо повнимательней Вам почитать для каких условий TQ пути анализирует. Изменено 5 июля, 2017 пользователем Грендайзер Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bogaev_roman 0 5 июля, 2017 Опубликовано 5 июля, 2017 · Жалоба Сама задержка, как физическое явление, зависит лишь от частоты сигнала и длинны "линии задержки", тобиш провода. Но вот 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 1 5 июля, 2017 Опубликовано 5 июля, 2017 (изменено) · Жалоба Хотите сказать, что TQ, в зависимости от того приёмный это триггер, или передающий, добавляет значение джитера, которое не показывает на диаграммах. Ну ок, надо подумать. Отчёты: Изменено 5 июля, 2017 пользователем Jackov Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Грендайзер 0 6 июля, 2017 Опубликовано 6 июля, 2017 (изменено) · Жалоба Интересно. Для путей данных TQ честно указал все луты, а для тактового пути ограничесля скупой фразой clock network. Да и задержка до второго триггера непропорциональна мала по сравнению с той, что набегает для первого, хотя на тактовой линии столько логики понапихано. Может он на ней всё же почикал всё. Изменено 6 июля, 2017 пользователем Грендайзер Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bogaev_roman 0 6 июля, 2017 Опубликовано 6 июля, 2017 · Жалоба Отчёты: Каким образом частота на схему идет и что Вы прописываете во временных ограничениях (кроме периода в 10МГц)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jackov 1 6 июля, 2017 Опубликовано 6 июля, 2017 (изменено) · Жалоба Да и задержка до второго триггера непропорциональна мала по сравнению с той, что набегает для первого, хотя на тактовой линии столько логики понапихано.В смысле? 5,26 и 6,16, вроде сопоставимы. Каким образом частота на схему идет и что Вы прописываете во временных ограничениях (кроме периода в 10МГц)?Ограничения все что в первом посте есть, не более. То что на картинке - верхний уровень, тактовая частота с входной ноги поступает, притом ногу явно не указывал, Ква сам выбрал какую-то. Изменено 6 июля, 2017 пользователем Jackov Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bogaev_roman 0 7 июля, 2017 Опубликовано 7 июля, 2017 · Жалоба В смысле? 5,26 и 6,16, вроде сопоставимы. Имеется ввиду то, что у Вас сигнал C проходит через 8 последовательных логических блоков lcell перед тактированием inst1, которые должны добавить задержку (судя по отчету задержки для данных - там их такое же кол-во) порядка 4.5нс. В данном случае разница меньше 1нс. Ограничения все что в первом посте есть, не более. То что на картинке - верхний уровень, тактовая частота с входной ноги поступает, притом ногу явно не указывал, Ква сам выбрал какую-то. Вот здесь странность какая-то в отчете - timequest должен отобразить отсчет нулевой точки от входного пина и дальше расписать по каким ячейкам сигнал проходит до клокового входа триггера, а в отчете он как будто сразу заведен на клоковый вход с заданной начальной задержкой - первый раз такое вижу. Интересно было бы увидеть схему после синтеза и фиттера (RTL viewer/technology map viewer). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться