yes 5 5 сентября, 2007 Опубликовано 5 сентября, 2007 · Жалоба ну то есть для описания синхронизатора, который перепривязывает данные с одного такта на другой понятно, что никакие 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 ) нет есть другие способы? может я облажался в другом - как можно найти триггера, которым на вход поступает сигнал из другого тактового домена (возможно, что через комбинаторные целы)??? если есть и не жалко - покажите пример скрипта... вобщем-то по функциональности устройства наверно проще, но есть свои трудности... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
soshnev 0 5 сентября, 2007 Опубликовано 5 сентября, 2007 · Жалоба ну то есть для описания синхронизатора, который перепривязывает данные с одного такта на другой понятно, что никакие 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-вставку сразу из триггеров и "не трогать" при синтезе... Даже вариант переопределить на несуществующий триггер и "не трогать". Но в любом случае в этих теоретических вариантах в конце ручные правки или немного другой результат синтеза. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 5 6 сентября, 2007 Опубликовано 6 сентября, 2007 · Жалоба "перепривязка к другому тактовому домену" означает, что на вход данных триггеру приходит сигнал не привязаный к его тактовому сигналу поэтому какие-бы ни были сетап и холд - они влияют только на вероятность попадания нестабильных данных в запрещенный интервал это лечится логически - например установкой последовательных триггеров (ну это все, что крутится вокруг "метастабильности") то есть временное нарушение компенсируется логикой функционирования устройства. но симулятор попав в $setup или $hold разрушает эту функциональность - то есть нужно выключить эти проверки сильно хочется сделать это DC, а не сторонним скриптом или какими-то ухищрениями при симуляции. скрипт - не хочется по идеологическим причинам - нетлист я подправлю а ddc нет, поэтому настаиваю :) на DC ----------- про поиск триггера по известному имени - нет вопроса ни в скрипте, ни в DC но интересно получить скрипт, который находит связанные триггера в разных доменах : то есть задаю скрипту clkA и clkB и он мне находит триггера, тактируемые clkB, на данных которых сигнал привязанный к clkA Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
soshnev 0 7 сентября, 2007 Опубликовано 7 сентября, 2007 · Жалоба "перепривязка к другому тактовому домену" означает, что на вход данных триггеру приходит сигнал не привязаный к его тактовому сигналу поэтому какие-бы ни были сетап и холд - они влияют только на вероятность попадания нестабильных данных в запрещенный интервал это лечится логически - например установкой последовательных триггеров (ну это все, что крутится вокруг "метастабильности") то есть временное нарушение компенсируется логикой функционирования устройства. но симулятор попав в $setup или $hold разрушает эту функциональность - то есть нужно выключить эти проверки сильно хочется сделать это DC, а не сторонним скриптом или какими-то ухищрениями при симуляции. скрипт - не хочется по идеологическим причинам - нетлист я подправлю а ddc нет, поэтому настаиваю :) на DC ----------- про поиск триггера по известному имени - нет вопроса ни в скрипте, ни в DC но интересно получить скрипт, который находит связанные триггера в разных доменах : то есть задаю скрипту clkA и clkB и он мне находит триггера, тактируемые clkB, на данных которых сигнал привязанный к clkA 1. А вопрос со стороны - "нестабильных данных в запрещенный интервал" - может заблокировать этот триггер в этот момент в аппаратуре? В смысле пусть сетапит иксом, а икс никуда больше не пройдёт. 2. Если есть в данной версии DC tcl скриптовая поддержка - наверное что-то можно сделать... (Скрипт с использованием for, find и т.п.). Опять же как он их будет находить и в какой момент. Например, может получиться производный сигнал от clkA - в смысле имя изменилось. Не уверен - что найдёт в раскрытой схеме. Если всё искать в одном модуле - наверное получится. Надо искать примеры script-ов, если есть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 5 7 сентября, 2007 Опубликовано 7 сентября, 2007 · Жалоба 1. А вопрос со стороны - "нестабильных данных в запрещенный интервал" - может заблокировать этот триггер в этот момент в аппаратуре? В смысле пусть сетапит иксом, а икс никуда больше не пройдёт. ну большинство сигналов (типа шина адреса/данных и т.п.) блокируется синхронизатором, но сам синхронизатор не заблокируешь - собственно там идет вероятностная борьба путем соединения триггеров последовательно (логически - запрос/подтверждение + все то же метастабилити и борьба с ним) а если в синхронизатор попал Х то вся логика блокирования рассыпается.... вобщем свой частный вопрос я решил поименным поиском синхронизирующих триггеров и их блокировкой (set_annotated_check) а вопросы общего решения :) оставил на потом Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
