Проблема передачи данных от одной FPGA к другой, Constraints для двух FPGA на плате Опции

[Rok]

Всем добрый день.

Ситуация следующая. Есть плата на ней стоит два чипа Virtex-II.
Делаю проект, разбиваю его на 2 части. Т.е. одна часть для первой микрухи, вторая часть - для второй.
Программирую PROM.
Начинаю проверку. Вижу, что данные от второй микрухи не приходят.
Делаю для второй микрухи проект в Identify. Там все прекрасно видно, что данные на выходе 2-го чипа есть.
А на входе первой, в том-же Identify, одни нули. Ладно думаю ...

Сделал новый проект все блоки объединил на один чип. Все прекрасно работает.
Но чип забит под завязку, что не очень хорошо для меня.
Ну и потом, раньше с таким не сталкивался. Нужно бы разобраться
Т.е. нужно как-то применить timing constraints к обоим чипам, но сразу,наверное, как-то измерить задержку надо бы...
В общем одни мысли ...
Ну и вот счас нарыл в доках OFFSET (constraint) и TRACE (утилита для timing analysis) - читаю...

Прошу совета, люди добрые ...

[3.14]

Итак, предположим Ваш автомат: регистр(ы) - комбинаторная логика - регистр(ы). Теперь Вы решили разнести комбинаторку по двум кристаллам. До перетосовки содержимого Вам было достаточно указать только констрейн PERIOD (OFFSET конечно то же надо, но ...), чтоб знать будет устройство работать или нет. Теперь Вы имеете регистр - комбинаторка - пин - линия - пин - комбинаторка - регистр. Если частота работы не большая (зависит конечно от "ширины" комбинаторки), то можно ничего и не затягивать констрейнами и все будет нормально функционировать, но вот с ростом частоты (так же и с ростом заполнения кристалла, если запас по задержкам был не большой) возникнут проблемы. Т.е. теперь жизненно необходимо законстрейнить пути от/до пинов до/от регистров (читаем про OFFSET и MAXDELAY). Предположим Вы успешно указали требуемые констрейны, но вот сюрприз, PAR думает с полчаса а потом говорит что не может их выполнить. Тогда остается одно - вставлять дополнительные регистры которые сократят до минимума пути от/до пинов, например: регистр - комбинаторка - регистр - пин - линия - пин - регистр - комбинаторка - регистр. Получается, теперь данные на выходе задержаны на 2 такта которые и надо учесть в своей архитектуре. Далее, увеличиваем частоту, опять не выполняется путь от/до пина, разбираемся, оказывается выходные/входные регистры раскиданы по кристаллу чем и вызваны длинные пути, теперь нужно использовать IOB=TRUE, так же задержка на выходном буфере зависит от настройки его макс. тока и скорости переключения (сразу включать максимум не стоит по соображениям согласованности в линиях). Так же важно как входит тактовый во второй кристалл (надеюсь в кристалле для него используете глобальную линию), идеальный вариант заводить его через DLL/DCM т.к. это позволит компенсировать задержку пин - глобальная линия, в противном случае надо прибавлять эту задержку к задержке на распространении.

[Rok]

Итак, предположим Ваш автомат: регистр(ы) - комбинаторная логика - регистр(ы). Теперь Вы решили разнести комбинаторку по двум кристаллам. До перетосовки содержимого Вам было достаточно указать только констрейн PERIOD (OFFSET конечно то же надо, но ...), чтоб знать будет устройство работать или нет. Теперь Вы имеете регистр - комбинаторка - пин - линия - пин - комбинаторка - регистр. Если частота работы не большая (зависит конечно от "ширины" комбинаторки), то можно ничего и не затягивать констрейнами и все будет нормально функционировать

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

но вот с ростом частоты (так же и с ростом заполнения кристалла, если запас по задержкам был не большой) возникнут проблемы. Т.е. теперь жизненно необходимо законстрейнить пути от/до пинов до/от регистров (читаем про OFFSET и MAXDELAY).

Пока читаем мат. часть

Предположим Вы успешно указали требуемые констрейны, но вот сюрприз, PAR думает с полчаса а потом говорит что не может их выполнить. Тогда остается одно - вставлять дополнительные регистры которые сократят до минимума пути от/до пинов, например: регистр - комбинаторка - регистр - пин - линия - пин - регистр - комбинаторка - регистр. Получается, теперь данные на выходе задержаны на 2 такта которые и надо учесть в своей архитектуре.

А обязательно ли вставлять их (регистры) только в RTL, или можно их вставить на этапе после ситеза? Может FPGA Editor поможет?
Чего то я тут сморозил, надо же не только их вставить, но учесть эти 2 клока, не так ли ?

Далее, увеличиваем частоту, опять не выполняется путь от/до пина, разбираемся, оказывается выходные/входные регистры раскиданы по кристаллу чем и вызваны длинные пути, теперь нужно использовать IOB=TRUE, так же задержка на выходном буфере зависит от настройки его макс. тока и скорости переключения (сразу включать максимум не стоит по соображениям согласованности в линиях).

Ну я проверил в FPGA Editor - регистры входных цепей частично внутри IOB, но также есть некоторые вне IOB. Регистры выходых цепей, причем все, располагаются вне IOB.
Так почему только xilinx это по умолчанию не делает ? Тут же логически понятно, что это экономит ресурсы кристалла и задержка соответственно уменьшается.

Так же важно как входит тактовый во второй кристалл (надеюсь в кристалле для него используете глобальную линию)

да, линии для всех клоков глобальные

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

У меня клок заведен следующим образом:
external clok to 1st FPGA -> DCM -> global pin (1st FPGA) -> линия -> global pin (2nd FPGA) -> register
т.е. вы предлагаете поставить DCM между global clock и регистрами во 2-й FPGA ?