Очень неприятная ситуация: HDL симулятор выдает адекватные задаче результаты, но постразводочная симуляция дает результат несколько иной (он же потом перебирается и в железо). Пробовал и на втором, и на третьем Спартанах. На что следует обратить внимание и в чем может заключаться ошибка??? Заранее спасибо.

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

Один сотрудник долго возился с проектом с такими же симптомами. Выяснилось, что входные сигналы при симуляции он ставил относительно clock'ов (делал векторный файл, в котором входые воздействия ставил во фронты clk)

1. Посмотреть, что в описании VHDL везде стоит правильный список чувствительности.
2. А поподробнее место где поведенческое моделирование отличается от синтезированного? Может это фифо? По-моему, Xilinx не обещает моделирование с точностью до такта всяких коровых фифо.

На мой взгляд это дело обычное. Раз вы сделали Post-P&R симуляцию - так по ней и ищите. Трудно это, но результативно. Полезно бывает для этого пересинтезировать с сохранением иерархии, чтобы все сигналы исходные сохранились, а также при симуляции включать в лог все сигналы проекта. Мы обычно так делаем, моделируем до появления ошибки на выходе, а потом этот выход в Dataflow и анализировать.

Если Post-P&R симуляция проводилась с учетом полученых при раскладке времянок, то стоит обратить внимание на следующее:
1. Правильно ли заданы ограничения для цепей;
2. Смог ли раскладчик выполнить заданные ограничения.

Спасибо за ответы, но пока дело с места не сдвинулось.
Опишу более подробно проект. Входной сигнал поступает на ФВЧ (получен в fdatool в Matlab), результат домножается на гармонику (переносится на промежуточную частоту), что в свою очередь фильтруется ФНЧ (опять же matlab'овском) с предварительной децимацией (в 8 раз).
То есть, fifo не используется, но clk'ов в проекте два - один на входе, другой в 8 раз прореженный на выходе.
Последовательное прохождение по коду показало, что расхождение начинается после ФНЧ.

Хотелось бы узнать и как исправить ошибки, и что их вызвало...проект по существу стоит на месте и жутко мучает совесть(

Разъяснение дано, но понятнее от него не стало. Как часто говорится, телепаты в отпуске!!!
Если жалко (по каким-то причинам нельзя) привести проблемную часть кода хотя бы наваяйте что-то похожее.

Как вариант - если второй клок получен из первого делением на степень двойки (8), его можно вообще не использовать, а пользоваться сигналом разрешения триггеров и памяти, используя прежний клок. Сэкономите глобальный буфер, увидите что про все это скажет Timing Analyser (если явно не указана связь между клоками в ограничениях или в самом проекте, то переход между клоковыми доменами игнорируется при анализе). А Вы констрейны на проект вообще какие-нибудь кроме залочивания ног назначали?

Файлики выложить нисколько не жалко:


...в ucf'е только распиновка.

К сожалению исходники на верилоге мне читать сложно, так как пишу в основном на VHDL.

А вот это зря. При моделировании и в железе частота, которую посчитал ISE не превышается? Моделируете с задержками? Попробуйте помоделировать, не цепляя SDF. Если ошибка пропадет, то проблема в слишком высокой частоте.

Вторая частота похоже не используется вовсе, ведь нет ни одного синхронного элемента, на который она бы подавалась, только на выход.

Возможно (но маловероятно, хотя в моей практике такое было - код (не мой), который не понимал синтезатор, правда, был ужасно кривым), это ошибка синтезатора, встречались с таким, попробуйте помоделировать Post-Map модель. Если повторится история с Post-Route моделью, то попробуйте проанализировать что мог "не понять" синтезатор в той части, где возникает ошибка.