Stratix II. Задание Assignments Опции

[Ethereal]

Добрый день.
В данный момент пишу модуль под ПЛИС Altera в среде Quartus 7.2. Все инструменты родные (то есть не используется возможность подключения внешних синтезаторов, фиттеров и прочего).
У меня такой вопрос. Я создал проект. Создал файлы с описанием функциональных единиц. Задал требуемую fmax. Поставил тип оптимизации "Speed". Поставил все советуемые Ассистентом настройки компилятора и фиттера.
Проект компилируется, прогоняется через Classic Timing Analizer. Анализатор сообщает, что получившаяся прошивка удовлетворяет временным требованиям.
Но часто еще на этапе симуляции симулятор выдает сообщения о превышении th (оптимизация th вдоль всех путей включена). При прошивке в ПЛИС в качестве выходного результата получается бред (не всегда, но зависит от компиляции - то все хорошо, то все не очень хорошо).
Входной клок идет на ФАПЧ с коэфициентом 1:1. Все блоки дезайна сделаны синхронными и тактируются с выхода ФАПЧ.
Существует клок входных данных, совпадающий по частоте с входным. Входные данные через память переводятся в клоковую область выхода ФАПЧ.
Все клоки (кроме PLL) описаны как клоки в Assignments manager.
Загрузка ПЛИС - 10%.

Основной вопрос: что я делаю не так?
Подпункт 1: Почему при проверке анализатором все хорошо, но при симуляции и в реальной работе все плохо?
Подпункт 2: Возможно стоит задавать еще какие-то требования?

[dvladim]

Подпункт 1: Почему при проверке анализатором все хорошо, но при симуляции и в реальной работе все плохо?
Подпункт 2: Возможно стоит задавать еще какие-то требования?

1. Вы сами ответили на этот вопрос - нарушаются th.
2. В качестве констрейнов задайте не только максимальную частоту, а еще ограничения на входные и выходные пины: tsu, th, tco(вроде).

Можно еще попробовать разместить граничные триггера в IO эелементах.

[murmel1]

Можно еще попробовать разместить граничные триггера в IO эелементах.

Это вторично. Это влияет на tsu/th/tco, но в первую очередь необходимо задать требования на tsu/th/tco. С равной вероятностью может улучшить, но может и стать еще хуже.

[sazh]

В данный момент пишу модуль под ПЛИС Altera в среде Quartus 7.2. Все инструменты родные (то есть не используется возможность подключения внешних синтезаторов, фиттеров и прочего).
Но часто еще на этапе симуляции симулятор выдает сообщения о превышении th (оптимизация th вдоль всех путей включена). При прошивке в ПЛИС в качестве выходного результата получается бред (не всегда, но зависит от компиляции - то все хорошо, то все не очень хорошо).
Входной клок идет на ФАПЧ с коэфициентом 1:1. Все блоки дезайна сделаны синхронными и тактируются с выхода ФАПЧ.
Подпункт 1: Почему при проверке анализатором все хорошо, но при симуляции и в реальной работе все плохо?
Подпункт 2: Возможно стоит задавать еще какие-то требования?

1. Если говорит хорошо, значит хорошо.
Проблема в родных инструментах. Очень трудно в ручную графически во временном моделировании создать входные воздействия с соблюдением th
да еще для памяти. Пропуститте входные данные через регистр на клоке с pll. (Это поможет справиться с рисованием входных воздействий в симуляторе квартуса. Кстати - поставьте 8.1. Он при несоблюдении временных граничений будет выдавать вам неопределеености при моделировании. Чтобы не казалось, что все хорошо).
Дело скорее всего в проекте. При переносе данных из одного клокового домена в системный.

[Ethereal]

Извиняюсь, неточно сформулировал.
Ошибка в th происходит в клоковом домене PLL. То есть данные записались в память, считались, прошли определенную обработку, и где-то в середине конвеера th вылезает за пределы допустимого. А не на входном каскаде.

Задание tco, tsu, th, tpd влияет же только на распространение сигнала от пинов до регистров и от регистров (комбинаторики) до пинов?