Virtex 5 LX85, ISE10.1

Почему отдельно части проекта собираются на частотах до 375 МГц, а вместе - только 300?

Сделал конвейер с глубиной 16 и шириной 128. Частота получается в V5 градации -1 375 МГц. Размер - по 2000 LUT и FF.
Для имитации медленной части схемы приделал к конвейеру двухчастотные FIFO на вход и на выход - частота упала до 250 МГц.

Тогда нашел медленные трассы, которые оказались на выходе FIFO и в самом конвейере (?).
С конвейером делать ничего не стал, он ведь работал на 375 МГц? Между FIFO и конвейером вставил регистры. Частота поднялась до 307 МГц.

Что это за эффект? Так и должно быть? Это только в рекламе 400 - 500 МГц на счетчиках и коротких сумматорах, а увесистый проект - только 300 МГц?
Как сделать, чтобы частота не падала с ростом заполнения микросхемы?
Для нас вопрос принципиальный - ситуация требует, чтобы было 350 Мгц.

А когда части проекта собирали tsu, tco какие были? Если больше чем 2.5 нс - то вот от этого частота и падает.

Внутренняя тактовая частота 300-350 МГц тактирует изолированный от выводов ПЛИС участок схемы.
Внешняя тактовая частота обоих FIFO 50 МГц. tsu tco для внешнего интерфейса я не задавал, они получились обычные, примерно 5 и 12 нс.

А разве есть связь с tsu и tco при вычислении FMAX? По всем моим опытам, fmax само по себе, зависит от задержек в путях между регистрами.

Вот что вызывает подозрения, так это соотношение задержек в логике и проводах, 25%/75%=около 0.9нс/2.7 нс.
В какой "бубен" надо бить, чтобы сделать 50% / 50% или хотя бы 40% / 60%?

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

Ну вы же говорили о отдельных частях проекта. Пока они отдельные, то это значения tsu и tco, а когда в составе - это уже путь между двумя триггерами и соответственно влияет на Fmax.


Нормально. И ничего с этим не сделаешь.
Я где-то читал, что, дословно: "в современных ПЛИС задержки на связях составляют до 90%".

Похоже, я недостаточно разобрался с tsu и tco в Virtex. Почему-то в DS они менее 1 нс, а в реальности tsu tco портов - несколько нс.

Однако согласиться с потерей частоты из-за задержек мы не можем. 10/90 недопустимое соотношение. По моим наблюдениям, хорошее размещение дает 30-50/70..50, а если 10/90 - дело в консерватории.

Микросхемы следующих градаций выбиваются из бюджета.

Нашел забавный параметр в UCF - MAXSKEW для тактового сигнала. Повышает частоту на 20 МГц, что неплохо. Непонятно только - когда я просто задаю PERIOD - результат хуже.

Сейчас задержка в раздельных частях в лучшем случае 25...29/75...71, причем больше теряется в проводах. Понятно, что теряется, но что делать? Трассировать вручную? Читать AppNote? Какой?

Когда подключаю ФИФО - все рушится.

Размещение на ПЛИС хорошей схемы выглядит, как настоящий конвейер - длинный прямоугольник. Причем, чем выше частота - тем тольше и длиннее.

Топология медленной схемы выглядит, как равностороннее пятно вокруг блока памяти ФИФО.
Есть желание вообще отказаться от верилога и map/par , всё делать вручную. Схема-то простая, большая только.

Увеличивать конвейер. (ИМХО)

Тоже бился с похожей проблемой, правда в "3 спартане"...
Входных тактовых сигналов было 16, а свободных глобальных шин оставалось всего 6...
Я аналогично стал использовать ограничение "MAXSKEW" но совместно с "MAXDELAY"...

NET "CLKE0" MAXDELAY = 6 ns;
NET "CLKE0" MAXSKEW = 3 ns;

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

Схема простая.
Пути распространения сигналов между регистрами состоят из двух LUT, т.е. глубина логики = 2.
Удвоение количества регистров может привести к росту частоты на 10-20%, что в наших условиях невыгодно.

Выгодно крутить уши Mapper-у.

Задержка в логике около 1 нс, в проводах - около 2-2.5 нс. ISE провирается на 200 пикосекунд, частота падает до неприемлемых 300-307 МГц.

Я вот думаю сделать макрос из быстрого варианта сборки схемы. Макрос-то вставится, как есть. Единственное, его надо как-то ограничить по форме и в пространстве, а то форма несколько кривая у конвейера.

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

IMHO вы где-то обсчитались. У вас 2 LUT, то есть цепочка триггер-связь-LUT-связь-LUT-связь-триггер. Если вы удвоите количество триггеров, то будет триггер-связь-LUT-связь-триггер: вы выиграете 1 связь и 1 LUT. Если пренебречь временами установки и удержания триггеров и предположить, что времена LUT/связь у вас 30 на 70, то вы выигрываете 35%. На практике (не пренебрегая ничем) может чуть меньше. Но вам и надо-то с 307 подняться на 350, это всего 15%.
И еще PlanAhead повертите в руках, помогает иногда.

Да, надо попробовать удвоить количество регистров.

Хотя я не согласен с самой постановкой вопроса - схема-то синтезирована нормально, отдельно трассируется нормально (уже за 370 МГц) - работа вроде сделана. Картинка с задержкой прилагается. Ан нет, надо что-то еще.

Сделал глобальным сигнал разрешения работы триггера и добавил MAXSKEW- получилось за 370 МГц.

Думаю, надо хитрее поступить - отвязать входы и выходы конвейера от остальной схемы через многоцикловую схему или что-то в этом духе. А то быстрая сторона обычного ФИФО норовит приблизить к себе весь конвейер и всё портит.

Сделайте FIFO типа Independent Clock - оно гораздо быстрее (500 МНz против 350 у Synchronous). И не забудьте, в Virtex-5 есть ресурс FIFO36, только его использование заставит FIFO работать на предельной частоте.