Mikhail241 0 16 ноября, 2017 Опубликовано 16 ноября, 2017 · Жалоба Добрый день. Имеется дизайн с одним клоком и несколькими сгенерированными клоками(generated clock). При выполнении CCOPT в Innovus получается большой skew между регистром источника generated clock и примыкающими к нему регистрами. Поясняющая картинка: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 16 ноября, 2017 Опубликовано 16 ноября, 2017 · Жалоба У Вас Caps залип? CCOPT по всей видимости посчитал, что путь между регистрами больше требуемого периода, отсюда и skew. Це не баг, а фича. Если не нравится, запретите вообще скьюить клок setOptMode -usefulSkewCCOpt none Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Mikhail241 0 16 ноября, 2017 Опубликовано 16 ноября, 2017 · Жалоба CCOPT по всей видимости посчитал, что путь между регистрами больше требуемого периода, отсюда и skew. Це не баг, а фича. Если не нравится, запретите вообще скьюить клок setOptMode -usefulSkewCCOpt none Спасибо за ответ. Так в этом и суть... Возникает отрицательный slack между регистрами, т.к. путь к приемнику меньше чем к источнику(одна из причин). UsfulSkew должен исправлять эту проблему. Я даже проверил, с помощью EcoAddRepeater, вставить буфер в дерево приемника и WNS уменьшился... Перепробовал кучу опций ничего не помогает! Без UsefulSkew тоже печально все. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 16 ноября, 2017 Опубликовано 16 ноября, 2017 · Жалоба Если "путь к приемнику меньше чем к источнику" значит в этом пути холд нарушен. Сделайте репорт по холду и по сетапу. Если по сетапу есть запас, то холд лечится. Если запаса нет, то холд лечится только в ущерб сетапу. p.s. немного базовых вещей про сетап и холд https://habrahabr.ru/post/302806/ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Mikhail241 0 16 ноября, 2017 Опубликовано 16 ноября, 2017 · Жалоба Если "путь к приемнику меньше чем к источнику" значит в этом пути холд нарушен. Сделайте репорт по холду и по сетапу. Если по сетапу есть запас, то холд лечится. Если запаса нет, то холд лечится только в ущерб сетапу. p.s. немного базовых вещей про сетап и холд https://habrahabr.ru/post/302806/ Дело не в ходде. Я специально задаю запас по WNS на холд и синтезирую с CU = 0 и в режиме setAnalysisMode -analysisType single. И по отчетам видно что это не проблемное место для холдов. Проблема именно с регистрами соседними к источнику, CCOPT создает отдельную skew_group с rank 1 в которой: регистр генератора(РГ) и самый ближайший к нему регистр(БР). В результате эта группа сбалансирована а между БР и другим регистром(картинка) слэк. PS: дизайн очень критичный по быстродействию Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 16 ноября, 2017 Опубликовано 16 ноября, 2017 · Жалоба Так а в чем проблема, если тайминг нормальный? Все группы и деревья, которые создает CCOPT, можно редактировать/удалять/создавать новые. Не доверяете машине - делайте свои спецификации. Или на крайняк в инновусе до сих пор остается поддержка CKsynthesis Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Mikhail241 0 17 ноября, 2017 Опубликовано 17 ноября, 2017 · Жалоба Так а в чем проблема, если тайминг нормальный? Все группы и деревья, которые создает CCOPT, можно редактировать/удалять/создавать новые. Не доверяете машине - делайте свои спецификации. Или на крайняк в инновусе до сих пор остается поддержка CKsynthesis Почему Вы так решили?) WNS по сетапу -0,4. Период 1нс. Понимаете, все, что Вы предлагаете я уже перепробовал(и вручную редактировал файл)... С CKsyn WNS = -0,6. Во всех вариантах результат плавает от -0,4 до -0,9 и всегда одно и тоже место возле gen clock. Самое для меня странное, что EcoAddRepeater помогает сбросить около 0,2 без нарушений по холд. Думаю можно и до нуля сбросить, но это долго и нудно. У меня Иновус 15. Спасибо) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 17 ноября, 2017 Опубликовано 17 ноября, 2017 · Жалоба Посмотрите тайминг до передающего триггера и после принимающего, есть ли там запас по сетапу. Тул ведь сводит всю микросхему/блок, а не один выделенный путь. Если где то совсем плохо с таймингом, тулл попытается вытащить эти места за счет хороших путей. А если все же надо вытащить именно один путь или группу путей на фоне проблем в остальной части дизайна - выделите это в отдельную группу (group_path), и повысьте на ней приоритет (setPathGroupOptions). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Mikhail241 0 17 ноября, 2017 Опубликовано 17 ноября, 2017 · Жалоба Посмотрите тайминг до передающего триггера и после принимающего, есть ли там запас по сетапу. Тул ведь сводит всю микросхему/блок, а не один выделенный путь. Если где то совсем плохо с таймингом, тулл попытается вытащить эти места за счет хороших путей. А если все же надо вытащить именно один путь или группу путей на фоне проблем в остальной части дизайна - выделите это в отдельную группу (group_path), и повысьте на ней приоритет (setPathGroupOptions). Я смотрел worst chain в отчетах ccopt и там все сводится к тому, что нет временного окна для usful skew(constaraint = 0!) Т.е. он не может добавить задержку в регистр gen clock(в данном случае это латч) --> choosen = 0. Тут используется gating clock для генерации, но в классической ситуации где gen clock описывается сразу с выхода делителя аналогичные проблемы. В UG ничего не нашел по этому поводу, кроме увеличения auto_limit_insertion_delay_factor. Т.е. проблема в том, что изначально ccopt задает временное окно равное нулю. Хотя добавление задержки не вызовет ухудшения WNS(EcoAddRepeater). В общем беда! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 17 ноября, 2017 Опубликовано 17 ноября, 2017 · Жалоба Т.е. это путь reg2cgate? Я замечал, что CCOPT плохо правит reg2cgate, если есть нарушения сетап/холд в путях, которые находятся в дереве с выхода этого клок-гейта. Как только исправляете тайминг в дереве (к примеру, ослаблением констрейнтов, если нарушения в in2reg или reg2out), только тогда тул начинает сам править reg2cgate. На мой взгляд, это баг. Тулы кэденса вообще дико забагованы, как известно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Mikhail241 0 17 ноября, 2017 Опубликовано 17 ноября, 2017 · Жалоба Т.е. это путь reg2cgate? Я замечал, что CCOPT плохо правит reg2cgate, если есть нарушения сетап/холд в путях, которые находятся в дереве с выхода этого клок-гейта. Как только исправляете тайминг в дереве (к примеру, ослаблением констрейнтов, если нарушения в in2reg или reg2out), только тогда тул начинает сам править reg2cgate. На мой взгляд, это баг. Тулы кэденса вообще дико забагованы, как известно. Сам слэк по пути reg2latch, но как я уже сказал если в качестве соурса для gen clock использовать обычный флип-флоп(вместо гейта) - тот же результат, с тем же constraint=0. Хорошо, попробую еще ослабить sdc, хотя там уже кроме частоты все выключено... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 17 ноября, 2017 Опубликовано 17 ноября, 2017 · Жалоба Есть еще один путь. Можно задать констрейнт set_clock_latency на тот клоковый пин (скажем, триггера), который вы хотите подвинуть в дереве вверх или вниз. CCOPT учитывает это. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться