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

[Rok]

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

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

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

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

[DmitryR]

Делаю для второй микрухи проект в Identify. Там все прекрасно видно, что данные на выходе 2-го чипа есть.
А на входе первой, в том-же Identify, одни нули. Ладно думаю ...

Ну так наверное на плате косяк или стандарты ввода-вывода неправильно стоят.

[3.14]

Скорее всего у Вас путь FFS->PADS->PADS->FFS не вписывается в период. По мимо OFFSET еще есть MAXDELAY (если тактовая получена не с внешнего пина), указать еще не значит что требуемые времянки выполнятся. Чтоб сократить FFS->PADS, увеличивайте выходной ток буфера и переключите в FAST, PADS->FFS - включите NODELAY (не знаю может у виртеха еще какие настройки есть).

[Gate]

Еще у synplicity есть продукт certify - он умеет разбивать дизайн на несколько fpga (предназначен для прототипирования асиков). Есть на фтп.

[3.14]

Кстати, забыл еще, важно чтобы входные/выходные регистры находились в IOB, в противном случае задержка на разводке будет больше чем на свойствах буферов к тому же забег по шине будет минимальный (меньше 1нс). Констрейн INST XXX IOB=TRUE

[sazh]

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

[3.14]

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

Я просто в шоке (извиняюсь не сдержался), я думаю человек не мог не догадаться учесть дополнительный такт при передаче.

[Rok]

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

Я просто в шоке (извиняюсь не сдержался), я думаю человек не мог не догадаться учесть дополнительный такт при передаче.

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

[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 ?

[3.14]

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

Если в констрейны впишется.

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

По другому никак.

Так почему только xilinx это по умолчанию не делает ? Тут же логически понятно, что это экономит ресурсы кристалла и задержка соответственно уменьшается.

Тут как монетка ляжет ... Synplify обычно через PCF файл с ограничениями засовывает регистры по IOB, но надежней это сделать самому.

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

Посмотрите в FPGAeditor какой путь получается от пина до глобальной линии с учетом входного буфера. Например для Spartan2 (используя не "глобальный" пин) этот путь может достигать нескольких наносекунд и сильно зависит от заполненности кристалла.