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

Может организовать дополнительные регистры на входах и выходах модулей...

ISE из-за этого будет модули компактнее делать?
Здесь route внутри модуля огромный, из-за "хаотичного" расположения компонента по кристаллу

У Вас временные ограничения не выполняются (они вообще заданы?)? Или Вам просто не нравится процентное соотношение задержек? Что за пути - может там по одному регистру на входе/выходе и сигнал тянется через весь кристалл?

Не выполняются. Не нравится. Тянется примерно через четверть кристалла. По Триггер->lut->триггер ->lut, fanout 1..4, иногда 2 триггера.
Я бы хоть как-то понял если бы они не выполнялись в такой связке, но даже не пути триггер-триггер не выполняется. 4 строчка в репорте.
Увеличение количества триггеров приведет к резкому увеличению используемых ресурсов.

Я бы для начала попробовал поиграть с настройками плэйсера (ну и рутера заодно). Если не поможет - фиксировать модули по определенным местам в кристалле через AREA_GROUP. Ну и для начала попробовать ответить на вопрос - какую задачу решает плэйсер распихивая соседние элементы по разным углам...

Сейчас нахожусь на этой стадии.

Тут все зависит от первоначального размещения базовых элементов (?), расположение которых зависит практически от погоды на марсе и магической константы cosе table , если я правильно понял. А остальную мелочь он размещает после размещения базовых элементов.
В проекте много памяти и он раскидал её равномерно по всей окружности. Остальное начинает плясать от этого. Где-то адрес не дотягивается с fanout 8 ибо память к которой адрес идет по половине кристалла раскидана, хотя можно было рядом положить. Где-то данные. Пробовал память группировать с помощью rloc стало только хуже. Пробовал наложить AREA_GROUP, стало только хуже.
Надо какой-то системный подход, а какой я по понять не могу....

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

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

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

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




fan-out = 2.

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

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

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



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

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

Как вариант:
INST "*/u_layer_a/u_layer_b/gen_layer_c.0.u_layer_c/u_fifo/u_bram" AREA_GROUP = "pb_0_bram_0";
AREA_GROUP "pb_0_bram_0" RANGE=RAMB36_X7Y60:RAMB36_X7Y61;
INST "*/u_layer_a/u_layer_b/gen_layer_c.1.u_layer_c/u_fifo/u_bram" AREA_GROUP = "pb_0_bram_1";
AREA_GROUP "pb_0_bram_1" RANGE=RAMB36_X7Y62:RAMB36_X7Y63;

u_bram - собственно описание памяти.
П.С.: хотя я всё равно считаю, что проблема в шинах..

Значит каждый юнит отдельно...



В шинах управления?