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

Как уменьшить время распространения сигнала (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 - собственно описание памяти.

 

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

 

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

 

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

 

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


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

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...