Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: setup time и post-route simulation
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Костян
Итак есть тестовая схема (см. аттач ).

На вход din подается сигнал, который изменяет свое значение через 2ns после фронта clk.
На скриншоте 1a.jpg представлен post-map simulation . Триггер temp защелкивается значение строго по фронту clk.
На скриншоте 1b.jpg представлен post-route simulation . Триггер temp защелкивается по фронту clk значение din, изменяемое после 2ns. А как же setup time ??

Почему результат post-map и post-route так рознятся ??


з.ы в аттаче также hdl файлы
DmitryR
Для начала убедитесь, что входной триггер располагается в пэде.
Костян
Цитата(DmitryR @ Feb 2 2010, 16:04) *
Для начала убедитесь, что входной триггер располагается в пэде.

Развел эту схемку для Virtex4. У него я не вижу триггеров в паде. Развел в пады выходные , задержка пропала , тригерр работает строго по фронту.

Правильно ли я понимаю, что существует задержка в распространении сигнала DIN (либо точнее говоря CLK), которая не компенсируется автоматически на этапе route ?


p/s страсти накаляются..... развел это дело под Spartan3, значение в триггер защелкивается строго по фронту , при чем не имеет значение , где располагается триггер в паде или в слайсах. В чем различие между триггерами и архитектурой Spartan и Virtex ?
DmitryR
В чем различие архитектуры - это долгий разговор, почитайте лучше доки.

Что же касается вашей проблемы: если вы ставите входной триггер в лапу - он почти всегда будет работать, так как задержки будут невелики. Если же все в логике - то работоспособность будет зависеть от задержки линии данных. Если триггер окажется недалеко от края - будет работать, если в середине кристалла - то нет. Это частично объясняет разницу поведения Spartan и Virtex: Spartan маленький (обычно), и в нем шанс, что путь до произвольно расположенного в логике триггера будет не очень длинный выше, чем у Virtex.
Костян
пасиб за идеи...

Цитата
Если же все в логике - то работоспособность будет зависеть от задержки линии данных.

а не линии тактового сигнала ? (хотя и то другое в общем случае равнозначно)
dvladim
Цитата(Костян @ Feb 3 2010, 11:09) *
Правильно ли я понимаю, что существует задержка в распространении сигнала DIN (либо точнее говоря CLK), которая не компенсируется автоматически на этапе route ?

Вы вообще не в ту сторону смотрите. Задайте констрейны на сетап/холд по входным данным и посмотрите в отчете как они выполняются. Именно такой должен быть подход.

Цитата(Костян @ Feb 3 2010, 15:54) *
а не линии тактового сигнала ? (хотя и то другое в общем случае равнозначно)

Я бы сказал противоположно. Задержка по данным будет приводить к отрицательным холдам, по клоку - к положительным.
DmitryR
Так как тактовый сигнал разводится по специальным линиям его задержку в самом первом приближении, которое сейчас рассматривается можно принять константной. Поэтому пока обсуждаем задержку данных.

Что же касается констрейнов на входной оффсет - это имеет смысл лишь тогда, когда между входом и первым триггером есть логика (иногда это необходимо, например при извлечении тактового сигнала в стандарте SpaceWire), в остальных же случаях триггеры проще поставить в лапы и иметь фиксированный, известный из даташита OFFSET IN.
dvladim
Цитата(DmitryR @ Feb 4 2010, 09:52) *
Что же касается констрейнов на входной оффсет - это имеет смысл лишь тогда, когда между входом и первым триггером есть логика (иногда это необходимо, например при извлечении тактового сигнала в стандарте SpaceWire), в остальных же случаях триггеры проще поставить в лапы и иметь фиксированный, известный из даташита OFFSET IN.

Это имеет смысл делать всегда! Контролировать работоспособность проекта проще.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.