ну то есть для описания синхронизатора, который перепривязывает данные с одного такта на другой
понятно, что никакие setup/hold-ы для такого триггера не имеют смысла, а вред - X в симуляции

вроде рекомендовали метод - на этот триггер ставить
set_annotated_check -setup 0.0 (и -hold 0.0) -from clock_pin -to data_pin

вроде как это помогает (когда два независимых идеальных тактовых сигнала), но почему-то в случае с TCK ( http://electronix.ru/forum/index.php?showtopic=36181 ) нет

есть другие способы?

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

1.
Не очень понятны фразы "перепривязывает" и "другого тактового домена" .
А цифры setup/hold в SDF?
Если это так - есть вариант найти их по иерархическому имени компонента и обнулить
(закоментировать // или /* */) ручками в SDF-е.

В принципе и script коррекции можно написать (если как-то поименовать исходные переменные
чтобы они перенеслись на имена компонентов).
(Есть вендоры - они пишут script чуть ли не на pearl, кстати действительно всё вокруг SDF-a).

2.
Весьма теоретические варианты :
Есть вариант их как-то выделить в описании и попробовать обложить констраинтами чтобы
setup-ы/hold-ы не появились(но тогда и результат синтеза изменится).

Есть другие варианты - опять же если их можно выделить в описании.
Типа заменить их в описании на netlist-вставку сразу из триггеров
и "не трогать" при синтезе...
Даже вариант переопределить на несуществующий триггер
и "не трогать".

Но в любом случае в этих теоретических вариантах в конце ручные правки или
немного другой результат синтеза.

"перепривязка к другому тактовому домену" означает, что на вход данных триггеру приходит сигнал не привязаный к его тактовому сигналу

поэтому какие-бы ни были сетап и холд - они влияют только на вероятность попадания нестабильных данных в запрещенный интервал

это лечится логически - например установкой последовательных триггеров (ну это все, что крутится вокруг "метастабильности")

то есть временное нарушение компенсируется логикой функционирования устройства.
но симулятор попав в $setup или $hold разрушает эту функциональность - то есть нужно выключить эти проверки

сильно хочется сделать это DC, а не сторонним скриптом или какими-то ухищрениями при симуляции.
скрипт - не хочется по идеологическим причинам - нетлист я подправлю а ddc нет, поэтому настаиваю на DC

-----------

про поиск триггера по известному имени - нет вопроса ни в скрипте, ни в DC

но интересно получить скрипт, который находит связанные триггера в разных доменах : то есть задаю скрипту clkA и clkB и он мне находит триггера, тактируемые clkB, на данных которых сигнал привязанный к clkA

1. А вопрос со стороны - "нестабильных данных в запрещенный интервал" - может
заблокировать этот триггер в этот момент в аппаратуре?
В смысле пусть сетапит иксом, а икс никуда больше не пройдёт.

2. Если есть в данной версии DC tcl скриптовая поддержка - наверное что-то можно сделать...
(Скрипт с использованием for, find и т.п.). Опять же как он их будет находить и в какой
момент. Например, может получиться производный сигнал от clkA - в смысле имя изменилось.
Не уверен - что найдёт в раскрытой схеме.
Если всё искать в одном модуле - наверное получится.
Надо искать примеры script-ов, если есть.

ну большинство сигналов (типа шина адреса/данных и т.п.) блокируется синхронизатором, но сам синхронизатор не заблокируешь - собственно там идет вероятностная борьба путем соединения триггеров последовательно (логически - запрос/подтверждение + все то же метастабилити и борьба с ним)

а если в синхронизатор попал Х то вся логика блокирования рассыпается....

вобщем свой частный вопрос я решил поименным поиском синхронизирующих триггеров и их блокировкой (set_annotated_check)

а вопросы общего решения оставил на потом