Добрый день.

Имеется дизайн с одним клоком и несколькими сгенерированными клоками(generated clock).
При выполнении CCOPT в Innovus получается большой skew между регистром источника generated clock и примыкающими к нему регистрами.
Поясняющая картинка:

У Вас Caps залип?
CCOPT по всей видимости посчитал, что путь между регистрами больше требуемого периода, отсюда и skew. Це не баг, а фича. Если не нравится, запретите вообще скьюить клок setOptMode -usefulSkewCCOpt none

Спасибо за ответ. Так в этом и суть... Возникает отрицательный slack между регистрами, т.к. путь к приемнику меньше чем к источнику(одна из причин). UsfulSkew должен исправлять эту проблему. Я даже проверил, с помощью EcoAddRepeater, вставить буфер в дерево приемника и WNS уменьшился... Перепробовал кучу опций ничего не помогает! Без UsefulSkew тоже печально все.

Если "путь к приемнику меньше чем к источнику" значит в этом пути холд нарушен. Сделайте репорт по холду и по сетапу. Если по сетапу есть запас, то холд лечится. Если запаса нет, то холд лечится только в ущерб сетапу.

p.s. немного базовых вещей про сетап и холд
https://habrahabr.ru/post/302806/

Дело не в ходде. Я специально задаю запас по WNS на холд и синтезирую с CU = 0 и в режиме setAnalysisMode -analysisType single. И по отчетам видно что это не проблемное место для холдов.
Проблема именно с регистрами соседними к источнику, CCOPT создает отдельную skew_group с rank 1 в которой: регистр генератора(РГ) и самый ближайший к нему регистр(БР). В результате эта группа сбалансирована а между БР и другим регистром(картинка) слэк.
PS: дизайн очень критичный по быстродействию

Так а в чем проблема, если тайминг нормальный?
Все группы и деревья, которые создает CCOPT, можно редактировать/удалять/создавать новые. Не доверяете машине - делайте свои спецификации. Или на крайняк в инновусе до сих пор остается поддержка CKsynthesis

Почему Вы так решили?) WNS по сетапу -0,4. Период 1нс. Понимаете, все, что Вы предлагаете я уже перепробовал(и вручную редактировал файл)... С CKsyn WNS = -0,6. Во всех вариантах результат плавает от -0,4 до -0,9 и всегда одно и тоже место возле gen clock.
Самое для меня странное, что EcoAddRepeater помогает сбросить около 0,2 без нарушений по холд. Думаю можно и до нуля сбросить, но это долго и нудно. У меня Иновус 15. Спасибо)

Посмотрите тайминг до передающего триггера и после принимающего, есть ли там запас по сетапу. Тул ведь сводит всю микросхему/блок, а не один выделенный путь. Если где то совсем плохо с таймингом, тулл попытается вытащить эти места за счет хороших путей. А если все же надо вытащить именно один путь или группу путей на фоне проблем в остальной части дизайна - выделите это в отдельную группу (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). В общем беда!

Т.е. это путь reg2cgate? Я замечал, что CCOPT плохо правит reg2cgate, если есть нарушения сетап/холд в путях, которые находятся в дереве с выхода этого клок-гейта. Как только исправляете тайминг в дереве (к примеру, ослаблением констрейнтов, если нарушения в in2reg или reg2out), только тогда тул начинает сам править reg2cgate. На мой взгляд, это баг. Тулы кэденса вообще дико забагованы, как известно.

Сам слэк по пути reg2latch, но как я уже сказал если в качестве соурса для gen clock использовать обычный флип-флоп(вместо гейта) - тот же результат, с тем же constraint=0.
Хорошо, попробую еще ослабить sdc, хотя там уже кроме частоты все выключено...

Есть еще один путь. Можно задать констрейнт set_clock_latency на тот клоковый пин (скажем, триггера), который вы хотите подвинуть в дереве вверх или вниз. CCOPT учитывает это.