Может кто сталкивался с такой проблемой?
Есть проект, который успешно транслируется (без временных ошибок) на кристалл Virtex4lx80.
При трансляции этого же проекта (без изменения логики и частоты) на Virtex6lx240 появляется куча временных ошибок.
Работаю в ISE 14.1.

Xilinx предупреждал, что что-то подобное может возникнуть.
Основной причиной называлось иное строение Slice'а (Virtex-5/6), которое требует иного подхода к созданию проекта. Раньше CE, Reset, PreSet распространялся на 2 триггера, теперь на 4/8,.. а в Virtex-6 PreSet вообще пропал. Поэтому Xilinx настоятельно рекомендовал пересмотреть весь проект и переделать его под Virtex-5/6 с учётом всех особенностей новых FPGA. Ну и RLOC может всякие гадости подкинуть...

А еще, ноавя ПЛИС, значительно больше, и маленький проект внутри неё может быть жеското натянут между крайними I/O ножками.

У меня проект сделан на VHDLе. И когда создавал его под Virtex4 особо не задумывался по поводу особенностей FPGA. Поэтому пересматривать проект в рамках новой архитектуры ПЛИС Virtex6 не вижу смысла.
А что значит RLOC может всякие гадости подкинуть...?

А напрасно. Ибо Xilinx излогал эту мысль как раз в материалах по языковому описанию проектов. В оных материалах несколько раз подчёркивалось, что стили кодирования S3/V2/V4 и V5/V6 существенно отличаются. В материалах по V6 также подчёркивалось, что оные отличия в V6 еще более существенны, чем в V5. Хотя тут уже всё зависит от извращенности синтезатора, который Вы используете. Xilinx, что и естественно, описывал особенности XST.

Факт описания на языке еще ничего не значит. Да, обычно языковое описание облегчает переход... Но порой тоже бывает необходимо перелопатить проект целиком при миграции между версиями ISE (XST). У меня уже есть такой печальный опыт V5 (ISE 10.1SP3) -> V6 (ISE 13.x/14.1): всё описание RAM пришлось переделать !


Ну, в V4 slice - только 2 триггера, а в V6 4(8), поэтому constraint'ы RLOC необходимо все перепроверить и, при необходимости, скорректировать под новую архитектуру.

Например, могли быть RLOC'и, которые раскладывали 4 триггерп по 2 смежным Slice (например, чтобы с как-то хитро взаимодействовать с логикой быстрого переноса)... а в архитектуре V6 от этого будет только вред, т.к. все 4 триггера надо будет собрать в один slice. Ну и тому подобные гадости - всего не тут заочно не напишешь (фантазии не хватит).

Не совсем так. Если раньше было доступно два асинхронных входа одновременно: Preset и Clear, то в V6 остался только один на выбор. Поэтому, если в старом коде используются два асинхронных сигнала (и сброс и установка), это порождает комбинаторную петлю, с не всегда предсказуемым результатом. Как в плане корректности ковременных констрэйнов, так и в логике работы реальной схемы. Маппер и синтезатор об этом предупреждают.

От себя могу сказать, как действовал бы сам:
0. Внимательно прочитал все сообщения синтеза, трансляции и рутера для старого проекта. Вспомнил где были проблемы, если подставляли костыли, то где и какие.
1. Прочитал свежие: Constraints Guide, XST User Guide for Virtex-6, Spartan-6, and 7 Series Devices, Synthesis and Simulation Design Guide, Virtex-6 Libraries Guide for HDL Designs.
2. Внимательно прочитал все сообщения синтеза, трансляции и рутера для нового проекта.
3. Если для синтеза используется Synplify, проверил, не остались ли включены по умолчанию опции "Autoconstraint" и "Write Vendor Constraint File".
4. Обратил внимание на IP и примитивы, используемые в схеме, особенно: память, тактовые буферы и генераторы (DCM, PLL), регистры (на предмет вышеуказанных особенностей), IODELAY, заменил на подходящие именно для V6.
5. Просмотрел временные констрэйны: всё ли задано, включая multipass, не перегружены ли sdc/ucf дублирующими констрэйнами и всякими натяжками (старыми костылями) - это может здорово замедлять и ухудшать трассировку. Для рутеров современных кристаллов сейчас достаточно указывать лишь входную частоту с пина, все последующие частоты на буферах и выходах PLL они определяют и вычисляют сами.
6. Открыл имеющуюся ucf через "Create Timing Constraints", удивился куче сообщений о некорректных назначениях, исправил их.
7. Как уже отметил Boris_TS, очень внимательно посмотрел на RLOC'и, если они есть - действительно ли они необходимы, грохнул всё необязательное.
8. Снова внимательно просмотрел репортажи, особенно рутера: все ли констрэйны прошли, всё ли правильно задано, ничего не забыто.
9. Дальше уже можно открывать Timing Analyzer и разбираться с временными ошибками.
Как-то так.

Спасибо все за советы, буду смотреть, пробовать, читать и т.д.