Как уменьшить время распространения сигнала (route)?, Virtex6, xc6vlx240, Ise14.7, LDPC DVBS2 Опции

[Tpeck]

Доброго времени суток.
Есть дизайн c LDPC DVBS2 (около 25-30 % процентов ПЛИС), с тактовой частотой 200 МГц.
В проекте много однотипных юнитов.
После P/R с помощью PlanAhead вижу следующую таблицу.
Из неё видно, что значительная часть времянок уходит на route.
Как это время можно уменьшить, не используя loc, rloc, area_group и т. п. ручные механизмы?
А если это не уменьшить, то как грамотно использовать ручные механизмы?
Всем откликнувшимся - спасибо!

Эскизы прикрепленных изображений

 

[TRILLER]

Основная проблема раскладки проекта в ISE, на мой взгляд, это шины. Т.е. если у Вас сигналы образуют шину, то они будут распиханы по 4 штуки(по умолчанию) в SLICE. Ещё хуже то обстоятельство, что однобитные сигналы одинаковых модулей("empty" для фифо, например), описанных через генерейт(т.е. копи) будут объединены в шину. В итоге у вас большие массивы BRAM в разных углах кристалла будут стоять, а управляющие сигналы к ним будут в одном "месте"
Как с этим бороться в уже готовом описании я даже не представляю.
В любом случае, советую уделить этой особенности работы маппера особое внимание.

[Tpeck]

Основная проблема раскладки проекта в ISE, на мой взгляд, это шины. Т.е. если у Вас сигналы образуют шину, то они будут распиханы по 4 штуки(по умолчанию) в SLICE. Ещё хуже то обстоятельство, что однобитные сигналы одинаковых модулей("empty" для фифо, например), описанных через генерейт(т.е. копи) будут объединены в шину. В итоге у вас большие массивы BRAM в разных углах кристалла будут стоять, а управляющие сигналы к ним будут в одном "месте"

Управляющие сигнала древовидно разветвляются в две стадии, образуя относительно небольшой fanout.
Вопрос в другом, почему ISE, при исользовании четверти памяти, ставит их в разные углы плисины?

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

fan-out = 2.

[bogaev_roman]

fan-out = 2.

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

[Tpeck]

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

Да.
Длина - длинная
Тут системная проблема и длинный путь - это следствие.

Лично я считаю хорошим тоном приколотить ВСЮ блочную память гвоздями. Несколько сотен штук - не так и много. Зато экономит кучу времени в дальнейшем. И САПРине сильно легчает.

А по-какому принципу ее приколачивать?
LOC, Rloc, AREA_GROUP?
Или еще какие-нибудь?

И главное, как её расположить так, чтобы хуже не стало?

Эскизы прикрепленных изображений

 

[bogaev_roman]

Тут системная проблема и длинный путь - это следствие.

Судя по описанию, это проблема не кривой разводки и решается она до парсера, на уровне описания алгоритма путем изменения логики и, как было выше описано, добавлением регистров. Вы можете попробовать все банки прибить гвоздями, но без четкого понимания того, каким образом Ваш алгоритм должен лечь на ПЛИС (архитектурно) это приведет только к ухудшения времянки и дополнительному времени разводки.

Лично я считаю хорошим тоном приколотить ВСЮ блочную память гвоздями. Несколько сотен штук - не так и много. Зато экономит кучу времени в дальнейшем. И САПРине сильно легчает.

А что если вся эта память управляется из одного места и имеет стыки с интерфейсами типа ethernet или DDR3,которые уже жестко сидят - куда ее прибивать? Нам ТС ничего не поведал об алгоритме.

[Tpeck]

Судя по описанию, это проблема не кривой разводки и решается она до парсера, на уровне описания алгоритма путем изменения логики и, как было выше описано, добавлением регистров. Вы можете попробовать все банки прибить гвоздями, но без четкого понимания того, каким образом Ваш алгоритм должен лечь на ПЛИС (архитектурно) это приведет только к ухудшения времянки и дополнительному времени разводки.

А что если вся эта память управляется из одного места и имеет стыки с интерфейсами типа ethernet или DDR3,которые уже жестко сидят - куда ее прибивать? Нам ТС ничего не поведал об алгоритме.

Топикстартер ничего не понимает в том о чем он пишет
Информация принята.
Алгоритм приведен в описание темы.

[bogaev_roman]

Топикстартер ничего не понимает в том о чем он пишет
Информация принята.
Алгоритм приведен в описание темы.

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

Есть дизайн c LDPC DVBS2

с точки зрения реализации в итоговой RTL схеме может варьироваться. Обычная линия задержки может иметь несколько вариантов реализации, не зная реализацию, сложно чем-то помочь.

[Tpeck]

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

Тут не в куске проблема. С проблемным куском я и сам бы разобрался
C fan-out глобальных проблем нет.
Структурная схема - Память, сдвигатель, обработчик.
Проблема в том, как вежливо объяснить мапперу, что не надо память равномерно по всему кристаллу раскидывать.
Память размести компактней, сдвигатель поставь после неё, а обработчик поставь после сдвигателя и перед памятью.
А так память раскидал по всему кристаллу и между кристаллами начинает распихивать, сдвигатель, обработчик.
Там становится тесно и бах 90 % времни тратиться на распространение сигнала с fanout 2 .....
PS Белый цвет - это блоки памяти.

Эскизы прикрепленных изображений

 

[iosifk]

Тут не в куске проблема. С проблемным куском я и сам бы разобрался
C fan-out глобальных проблем нет.
Структурная схема - Память, сдвигатель, обработчик.
Проблема в том, как вежливо объяснить мапперу, что не надо память равномерно по всему кристаллу раскидывать.
Память размести компактней, сдвигатель поставь после неё, а обработчик поставь после сдвигателя и перед памятью.

А если память взять как инстанс из библиотеки - RAMB32 и т.д. А сдвигатель как SRL32...
И память составлять из кусков не по "адресам", а по "данным"... Тогда не понадобится мультиплексор шины данных от разных кусков памяти....