Перейти к содержанию

    

Как уменьшить время распространения сигнала (route)?

Доброго времени суток.

Есть дизайн c LDPC DVBS2 (около 25-30 % процентов ПЛИС), с тактовой частотой 200 МГц.

В проекте много однотипных юнитов.

После P/R с помощью PlanAhead вижу следующую таблицу.

Из неё видно, что значительная часть времянок уходит на route.

Как это время можно уменьшить, не используя loc, rloc, area_group и т. п. ручные механизмы?

А если это не уменьшить, то как грамотно использовать ручные механизмы?

Всем откликнувшимся - спасибо! :)

post-15243-1516619701_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Может организовать дополнительные регистры на входах и выходах модулей...

 

ISE из-за этого будет модули компактнее делать?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Доброго времени суток.

Есть дизайн c LDPC DVBS2 (около 25-30 % процентов ПЛИС), с тактовой частотой 200 МГц.

В проекте много однотипных юнитов.

После P/R с помощью PlanAhead вижу следующую таблицу.

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

Поделиться сообщением


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

 

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

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

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

Поделиться сообщением


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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Если не поможет - фиксировать модули по определенным местам в кристалле через AREA_GROUP.
Сейчас нахожусь на этой стадии.

 

Ну и для начала попробовать ответить на вопрос - какую задачу решает плэйсер распихивая соседние элементы по разным углам...
Тут все зависит от первоначального размещения базовых элементов (?), расположение которых зависит практически от погоды на марсе и магической константы cosе table , если я правильно понял. А остальную мелочь он размещает после размещения базовых элементов.

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

Надо какой-то системный подход, а какой я по понять не могу....:(

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Как с этим бороться в уже готовом описании я даже не представляю.

В любом случае, советую уделить этой особенности работы маппера особое внимание.

Поделиться сообщением


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

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

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

Как с этим бороться в уже готовом описании я даже не представляю.

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

Поделиться сообщением


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

Управляющие сигнала древовидно разветвляются в две стадии, образуя относительно небольшой fanout.

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

 

 

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

 

fan-out = 2.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
fan-out = 2.

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

Поделиться сообщением


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

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

Поделиться сообщением


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

Да.

Длина - длинная :)

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

 

 

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

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

LOC, Rloc, AREA_GROUP?

Или еще какие-нибудь?

 

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

post-15243-1516627937_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А по-какому принципу ее приколачивать?

Как вариант:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Как вариант:

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

 

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

 

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация