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

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

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

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


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

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


Ссылка на сообщение
Поделиться на другие сайты
Цитата(svedach @ Jan 22 2018, 14:56) <{POST_SNAPBACK}>
Может организовать дополнительные регистры на входах и выходах модулей...


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

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


Ссылка на сообщение
Поделиться на другие сайты
Цитата(Tpeck @ Jan 22 2018, 14:26) <{POST_SNAPBACK}>
Доброго времени суток.
Есть дизайн c LDPC DVBS2 (около 25-30 % процентов ПЛИС), с тактовой частотой 200 МГц.
В проекте много однотипных юнитов.
После P/R с помощью PlanAhead вижу следующую таблицу.

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

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


Ссылка на сообщение
Поделиться на другие сайты
Цитата(bogaev_roman @ Jan 22 2018, 15:28) <{POST_SNAPBACK}>
У Вас временные ограничения не выполняются? Или Вам просто не нравится процентное соотношение задержек? Что за пути - может там по одному регистру на входе/выходе и сигнал тянется через весь кристалл?


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

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


Ссылка на сообщение
Поделиться на другие сайты
Цитата(Tpeck @ Jan 22 2018, 15:37) <{POST_SNAPBACK}>
Не выполняются. Не нравится. Тянется примерно через четверть кристалла. По Триггер->lut->триггер ->lut, fanout 1..4, иногда 2 триггера.
Я бы хоть как-то понял если бы они не выполнялись в такой связке, но даже не пути триггер-триггер не выполняется. 4 строчка в репорте.
Увеличение количества триггеров приведет к резкому увеличению используемых ресурсов.


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

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


Ссылка на сообщение
Поделиться на другие сайты
Цитата(alexadmin @ Jan 22 2018, 15:55) <{POST_SNAPBACK}>
Если не поможет - фиксировать модули по определенным местам в кристалле через AREA_GROUP.
Сейчас нахожусь на этой стадии.

Цитата(alexadmin @ Jan 22 2018, 15:55) <{POST_SNAPBACK}>
Ну и для начала попробовать ответить на вопрос - какую задачу решает плэйсер распихивая соседние элементы по разным углам...
Тут все зависит от первоначального размещения базовых элементов (?), расположение которых зависит практически от погоды на марсе и магической константы cosе table , если я правильно понял. А остальную мелочь он размещает после размещения базовых элементов.
В проекте много памяти и он раскидал её равномерно по всей окружности. Остальное начинает плясать от этого. Где-то адрес не дотягивается с fanout 8 ибо память к которой адрес идет по половине кристалла раскидана, хотя можно было рядом положить. Где-то данные. Пробовал память группировать с помощью rloc стало только хуже. Пробовал наложить AREA_GROUP, стало только хуже.
Надо какой-то системный подход, а какой я по понять не могу....sad.gif

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


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

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


Ссылка на сообщение
Поделиться на другие сайты
Цитата(Tpeck @ Jan 22 2018, 15:37) <{POST_SNAPBACK}>
Я бы хоть как-то понял если бы они не выполнялись в такой связке, но даже не пути триггер-триггер не выполняется. 4 строчка в репорте.

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

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

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


Ссылка на сообщение
Поделиться на другие сайты
Цитата(TRILLER @ Jan 22 2018, 16:14) <{POST_SNAPBACK}>
Основная проблема раскладки проекта в ISE, на мой взгляд, это шины. Т.е. если у Вас сигналы образуют шину, то они будут распиханы по 4 штуки(по умолчанию) в SLICE. Ещё хуже то обстоятельство, что однобитные сигналы одинаковых модулей("empty" для фифо, например), описанных через генерейт(т.е. копи) будут объединены в шину. В итоге у вас большие массивы BRAM в разных углах кристалла будут стоять, а управляющие сигналы к ним будут в одном "месте" biggrin.gif

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


Цитата(bogaev_roman @ Jan 22 2018, 16:20) <{POST_SNAPBACK}>
Для начала - возьмите один длинный путь от триггера до триггера и проанализируйте кол-во fan-out на выходном триггере этого пути, а также наиболее длинный путь до входного триггера, возможно у Вас дикое кол-во fan-out.


fan-out = 2.

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


Ссылка на сообщение
Поделиться на другие сайты
Цитата(Tpeck @ Jan 22 2018, 16:22) <{POST_SNAPBACK}>
fan-out = 2.

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

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


Ссылка на сообщение
Поделиться на другие сайты
Цитата(Tpeck @ Jan 22 2018, 16:22) <{POST_SNAPBACK}>
Вопрос в другом, почему ISE, при исользовании четверти памяти, ставит их в разные углы плисины?

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

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


Ссылка на сообщение
Поделиться на другие сайты
Цитата(bogaev_roman @ Jan 22 2018, 16:27) <{POST_SNAPBACK}>
Это для выхода? Проанализируйте длину этих путей. Думаю, что тут без скриншота не обойтись.

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


Цитата(TRILLER @ Jan 22 2018, 16:29) <{POST_SNAPBACK}>
Лично я считаю хорошим тоном приколотить ВСЮ блочную память гвоздями. Несколько сотен штук - не так и много. Зато экономит кучу времени в дальнейшем. И САПРине сильно легчает.

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

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

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


Ссылка на сообщение
Поделиться на другие сайты
Цитата(Tpeck @ Jan 22 2018, 16:36) <{POST_SNAPBACK}>
А по-какому принципу ее приколачивать?

Как вариант:
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 - собственно описание памяти.
П.С.: хотя я всё равно считаю, что проблема в шинах..

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


Ссылка на сообщение
Поделиться на другие сайты
Цитата(TRILLER @ Jan 22 2018, 16:41) <{POST_SNAPBACK}>
Как вариант:
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 - собственно описание памяти.


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

Цитата(TRILLER @ Jan 22 2018, 16:41) <{POST_SNAPBACK}>
П.С.: хотя я всё равно считаю, что проблема в шинах..


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

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


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

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

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

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

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

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

Войти

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

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