Исходные данные:
- ПЛИС Xilinx Virtex4, среда ISE 12.2
- мини проект состоит из 8-ми больших FIR - фильтров и небольшой программы на vhdl по обработке выходных данных фильтров. Фильтры занимают процентов так 70 ресурсов ПЛИС.
- работоспособность этого мини проекта полностью проверена в моделсиме
- непосредственно при загрузке в ПЛИС этот проект не заработал. При помощи логического анализатора и многократного переписывания кода (код изначально без ошибок - просто разными способами одно и тоже делается) удалось добиться стабильной правильной работы мини проекта.

Суть проблемы:
- при установке моего проекта в более крупный проект - он опять перестает работать
- более того - часть сигналов выведены на контрольные контакты платы и при удалении любого из этих сигналов из проекта с последующей перекомпиляцией - проект снова перестает работать.
- при отладке есть ощущение что ходишь по кругу - исправишь что-то в одном куске коде, перестает правильно работать другой кусок - и так до бесконечности

Подозреваю что все это результат неких "гонок" сигналов, каких-то проблем синхронизации и пр. в результате значительного заполнения ресурсов ПЛИС. Код полностью работоспособен, ибо при уменьшении количества фильтров проект начинает стабильно работать.

Вопросы к форумчанам:
1. Из-за чего возможно такое поведение проекта
2. Возможно ли победить данную проблему путем настроек компилятора
3. Возможно ли сохранить конфигурацию аппаратных средств ПЛИС после единственной работоспособной компиляции проекта и вставить ее уже в более крупный проект.

1. Такое вполне возможно, если не выполняются временные ограничения. Проект полнстью синхронный?
2. Победить с помощью компилятора только если попробуете изменить стратегию проекта.
3. Сохранить возможно - нужно найти нетлист после place&route.

Сообщение отредактировал AlphaMil - May 19 2011, 14:01

код совсем не работоспособен


1. асинхра/не ложиться в констрейны
2. только если причина в констрейнах
3. да, но вам это не поможет

1. Проверьте проект на наличие временных ошибок
2. Можно, но не всегда. Для фильтров лучше применить конвейер, т.е. разделить времненной путь от регистра к регистру
3. Можно создать и закрепить нетлист отдельных частей и использовать его со всеми характеристиками в топовом модуле
PS Все вопросы обсуждались на форуме много раз, воспользуйтесь поиском...

Удалите пожалуйста мой пост, а то три раза уже одно и тоже примерно написали, сам удалить не смог...

Сообщение отредактировал bogaev_roman - May 19 2011, 14:06

UCF файл - в студию!

Наверное в этом проблема? Вы "программу" писали?

У Вас есть какой-то автоматизированный отчет (отчет синтезатора) о количестве тактовых сигналов в мини-проекте? Сколько их?

Благодарю и прошу прощения за задержку с ответом.
Свой мини проект я победил. Достаточно было убрать ibuf с одной из цепей и все заработало стабильно.
Временных ошибок не было - это проверил в первую очередь.
Клоков в проекте действительно несколько, но весь проект синхронный. В UCF файле на каждую клоковую цепь стояла запись вида NET xxx PERIOD=19.56ns HIGH 50%. Обычно этого хватало. А здесь видимо сказывалось соотношение фаз клоков.

Крупный проект с моим куском тоже работает, но правда на 20-30 раз включения питания работает не стабильно. В самом проекте разных клоков еще больше и влияние рассогласования их фаз сильнее. Поэтому сижу читаю мануал Xilinx Timing
Constraints User Guide. Надо хорошенько разобраться.

либо нарушена синхронизация между различными клоками или есть асинхронщина
в любом случае нужно править/смотреть само описание

Важные ключевые слова crossclock и metastability.

На самом деле, кроме множества клоков и возможной метастабильности регистров при пересечении данными их границ, есть не менее популярный момент - reset.
Если он асинхронный, то его обычно не учитывает timing analyzer, предполагается, что первый фронт клока случается через достаточное время после снятия сброса. Аргументированно доказать, что это всегда так способен не каждый разработчик, даже если его явно об этом попросить.
Проблема может проясниться даже на одноклоковой схеме, если исходный сигнал reset пропустить через регистр, а уже потом раздать всем (через глобальную сеть и через что попало будет по разному интересно).
В целом этот регистр не обязателен, но без него нужно не забыть описать reset в констрейнах.

Это была ассоциация на "20-30 раз включения питания". Удачи.

Раз так много клоков, значит наверное есть и переходы между "доменами". Предпринимаются ли специальные меры для перехода из домена в домен?
Например - везде связь идет через FIFO, и флаги empty/full дополнительно тактируются в соответствующем домене.