Цитата(yes @ Sep 5 2007, 16:14)
ну то есть для описания синхронизатора, который перепривязывает данные с одного такта на другой
понятно, что никакие 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-вставку сразу из триггеров
и "не трогать" при синтезе...
Даже вариант переопределить на несуществующий триггер
и "не трогать".
Но в любом случае в этих теоретических вариантах в конце ручные правки или
немного другой результат синтеза.
снова про DC : как убрать временные проверки hold|setup при симуляции?, то есть сгенерить SDF, проаннотировав который сим. не сделает ХХ
Sep 5 2007, 12:14
