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

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

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

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

Если не поможет - фиксировать модули по определенным местам в кристалле через AREA_GROUP.

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

Я бы хоть как-то понял если бы они не выполнялись в такой связке, но даже не пути триггер-триггер не выполняется. 4 строчка в репорте.

В итоге у вас большие массивы BRAM в разных углах кристалла будут стоять, а управляющие сигналы к ним будут в одном "месте" biggrin.gif
Как с этим бороться в уже готовом описании я даже не представляю.

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

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

fan-out = 2.

Вопрос в другом, почему ISE, при исользовании четверти памяти, ставит их в разные углы плисины?

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

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

А по-какому принципу ее приколачивать?

Как вариант:
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 - собственно описание памяти.

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

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

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

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

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

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

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

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

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

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

Используется циклический сдвигатель. Известный как barrel shifter.
Как его сделать на SRL32 не знаю и даже не уверен, что можно.

Control Signals
• Use control signals only as necessary.
• Avoid using a routed global reset signal and minimize use of local resets to maximize opportunity to use FPGA resources.
• Use active-High control signals.
• Avoid having both set and reset on the same flip-flop.
• Avoid control signals on small shift registers and storage arrays in order to use LUTs instead of flip-flops, to maximize utilization and minimize power.

А сигнал сброса в этом сдвигателе используется?

нет
А нужно?

Не нужно..

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

Xilinx, ug474_7Series_CLB, page 45:
То есть, если у регистра сдвига явно прописан сигнал сброса, то синтезатор не сможет имплементировать этот регистр в примитиве "SLICEM SRL Shift Register" и сделает все на FFs. /См. UG474, page 50/

Использовать Pblocks?

Это-то понятно, но только как с помощью SRL реализовать циклический сдвиг 360-ти 8-битных слов? Да еще и с произвольным шагом. Может быть укажите где на это можно посмотреть?

Define sets of design elements with U Set (U_SET) or HU Set (HU_SET) constraints.
• Each element of the set is placed in relation to the other elements of the set by Relative Location (RLOC) constraints.
• Logic elements with RLOC constraints and common set names are associated in an RPM.
U_SET, HU_SET, and RLOC constraints:
• Must be defined as properties in the HDL design files.
• Are not supported in Xilinx® Design Constraints format (XDC).

RLOC
Relative Location (RLOC) constraints define the relative placement of logic elements assigned to a set, such as an H_SET, HU_SET, or U_SET.
When RLOC is present in the RTL source files, the H_SET, HU_SET, or U_SET properties get translated into a read-only RPM property on cells in the synthesized netlist. The RLOC property is preserved, but becomes a read-only property after synthesis. For more information on using these properties, and defining RPMs, refer to the Vivado Design Suite
User Guide: Using Constraints (UG903) [Ref 19].

You can define the placement of any element within the set relative to other elements in the set, regardless of the eventual placement of the entire group onto the target device. For example, if RLOC constraints are applied to a group of eight flip-flops organized in a column, the mapper maintains the column and moves the entire group of flip-flops as a single unit.

The following Verilog module defines RLOC and HU_SET properties for the shift register Flops in the module.

About Relatively Placed Macros
A Relatively Placed Macro (RPM) is a list of basic logic elements (BELs) grouped into a set.
Examples of logic elements include:
• FF
• LUT
• DSP
• RAM
RPMs are primarily used to place small groups of logic close together in order to improve resource efficiency and enable faster interconnections.

Увеличение количества триггеров приведет к резкому увеличению используемых ресурсов.

В ASIC - да, а в ПЛИСе они и так есть, поэтому какой смысл их экономить? Если LUT уже задействован, то триггер под другие сигналы особо уже не используешь, поэтому отказываться от них из экономии в большинстве случаев неразумно. На выходах памяти, предполагающей длинные линии, я обычно ставлю регистры, как раз чтобы потом херней с ее приколачиванием не страдать.Если частоты уж совсем большие, тогда, конечно, только флорпленить остается.

Упс.. Только сейчас заметил, что вся тема про ISE.. Пардон..

Обычно за 2-3 итерации P&R находится стабильная конфигурация.
Заодно такой дизайн "гвоздями" обычно сокращает (и значительно) время сборки для больших проектов.

...
А насколько сокращает?
Был час стало полчаса.
Или было три часа, стал час?