Tpeck 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба Доброго времени суток. Есть дизайн c LDPC DVBS2 (около 25-30 % процентов ПЛИС), с тактовой частотой 200 МГц. В проекте много однотипных юнитов. После P/R с помощью PlanAhead вижу следующую таблицу. Из неё видно, что значительная часть времянок уходит на route. Как это время можно уменьшить, не используя loc, rloc, area_group и т. п. ручные механизмы? А если это не уменьшить, то как грамотно использовать ручные механизмы? Всем откликнувшимся - спасибо! :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
svedach 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба Может организовать дополнительные регистры на входах и выходах модулей... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tpeck 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба Может организовать дополнительные регистры на входах и выходах модулей... ISE из-за этого будет модули компактнее делать? Здесь route внутри модуля огромный, из-за "хаотичного" расположения компонента по кристаллу :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bogaev_roman 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба Доброго времени суток. Есть дизайн c LDPC DVBS2 (около 25-30 % процентов ПЛИС), с тактовой частотой 200 МГц. В проекте много однотипных юнитов. После P/R с помощью PlanAhead вижу следующую таблицу. У Вас временные ограничения не выполняются (они вообще заданы?)? Или Вам просто не нравится процентное соотношение задержек? Что за пути - может там по одному регистру на входе/выходе и сигнал тянется через весь кристалл? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tpeck 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба У Вас временные ограничения не выполняются? Или Вам просто не нравится процентное соотношение задержек? Что за пути - может там по одному регистру на входе/выходе и сигнал тянется через весь кристалл? Не выполняются. Не нравится. Тянется примерно через четверть кристалла. По Триггер->lut->триггер ->lut, fanout 1..4, иногда 2 триггера. Я бы хоть как-то понял если бы они не выполнялись в такой связке, но даже не пути триггер-триггер не выполняется. 4 строчка в репорте. Увеличение количества триггеров приведет к резкому увеличению используемых ресурсов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alexadmin 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба Не выполняются. Не нравится. Тянется примерно через четверть кристалла. По Триггер->lut->триггер ->lut, fanout 1..4, иногда 2 триггера. Я бы хоть как-то понял если бы они не выполнялись в такой связке, но даже не пути триггер-триггер не выполняется. 4 строчка в репорте. Увеличение количества триггеров приведет к резкому увеличению используемых ресурсов. Я бы для начала попробовал поиграть с настройками плэйсера (ну и рутера заодно). Если не поможет - фиксировать модули по определенным местам в кристалле через AREA_GROUP. Ну и для начала попробовать ответить на вопрос - какую задачу решает плэйсер распихивая соседние элементы по разным углам... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tpeck 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба Если не поможет - фиксировать модули по определенным местам в кристалле через AREA_GROUP. Сейчас нахожусь на этой стадии. Ну и для начала попробовать ответить на вопрос - какую задачу решает плэйсер распихивая соседние элементы по разным углам... Тут все зависит от первоначального размещения базовых элементов (?), расположение которых зависит практически от погоды на марсе и магической константы cosе table , если я правильно понял. А остальную мелочь он размещает после размещения базовых элементов. В проекте много памяти и он раскидал её равномерно по всей окружности. Остальное начинает плясать от этого. Где-то адрес не дотягивается с fanout 8 ибо память к которой адрес идет по половине кристалла раскидана, хотя можно было рядом положить. Где-то данные. Пробовал память группировать с помощью rloc стало только хуже. Пробовал наложить AREA_GROUP, стало только хуже. Надо какой-то системный подход, а какой я по понять не могу....:( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
TRILLER 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба Основная проблема раскладки проекта в ISE, на мой взгляд, это шины. Т.е. если у Вас сигналы образуют шину, то они будут распиханы по 4 штуки(по умолчанию) в SLICE. Ещё хуже то обстоятельство, что однобитные сигналы одинаковых модулей("empty" для фифо, например), описанных через генерейт(т.е. копи) будут объединены в шину. В итоге у вас большие массивы BRAM в разных углах кристалла будут стоять, а управляющие сигналы к ним будут в одном "месте" Как с этим бороться в уже готовом описании я даже не представляю. В любом случае, советую уделить этой особенности работы маппера особое внимание. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bogaev_roman 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба Я бы хоть как-то понял если бы они не выполнялись в такой связке, но даже не пути триггер-триггер не выполняется. 4 строчка в репорте. Для начала - возьмите один длинный путь от триггера до триггера и проанализируйте кол-во fan-out на выходном триггере этого пути, а также наиболее длинный путь до входного триггера, возможно у Вас дикое кол-во fan-out. В итоге у вас большие массивы BRAM в разных углах кристалла будут стоять, а управляющие сигналы к ним будут в одном "месте" biggrin.gif Как с этим бороться в уже готовом описании я даже не представляю. Дублировать логику, можно для этих сигналов ограничить fan-out - тогда компилятор сам все продублирует. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tpeck 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба Основная проблема раскладки проекта в ISE, на мой взгляд, это шины. Т.е. если у Вас сигналы образуют шину, то они будут распиханы по 4 штуки(по умолчанию) в SLICE. Ещё хуже то обстоятельство, что однобитные сигналы одинаковых модулей("empty" для фифо, например), описанных через генерейт(т.е. копи) будут объединены в шину. В итоге у вас большие массивы BRAM в разных углах кристалла будут стоять, а управляющие сигналы к ним будут в одном "месте" Управляющие сигнала древовидно разветвляются в две стадии, образуя относительно небольшой fanout. Вопрос в другом, почему ISE, при исользовании четверти памяти, ставит их в разные углы плисины? Для начала - возьмите один длинный путь от триггера до триггера и проанализируйте кол-во fan-out на выходном триггере этого пути, а также наиболее длинный путь до входного триггера, возможно у Вас дикое кол-во fan-out. fan-out = 2. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bogaev_roman 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба fan-out = 2. Это для выхода? Проанализируйте длину этих путей. Думаю, что тут без скриншота не обойтись. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
TRILLER 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба Вопрос в другом, почему ISE, при исользовании четверти памяти, ставит их в разные углы плисины? Лично я считаю хорошим тоном приколотить ВСЮ блочную память гвоздями. Несколько сотен штук - не так и много. Зато экономит кучу времени в дальнейшем. И САПРине сильно легчает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tpeck 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба Это для выхода? Проанализируйте длину этих путей. Думаю, что тут без скриншота не обойтись. Да. Длина - длинная :) Тут системная проблема и длинный путь - это следствие. Лично я считаю хорошим тоном приколотить ВСЮ блочную память гвоздями. Несколько сотен штук - не так и много. Зато экономит кучу времени в дальнейшем. И САПРине сильно легчает. А по-какому принципу ее приколачивать? LOC, Rloc, AREA_GROUP? Или еще какие-нибудь? И главное, как её расположить так, чтобы хуже не стало? :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
TRILLER 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба А по-какому принципу ее приколачивать? Как вариант: 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 - собственно описание памяти. П.С.: хотя я всё равно считаю, что проблема в шинах.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tpeck 0 22 января, 2018 Опубликовано 22 января, 2018 · Жалоба Как вариант: 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 - собственно описание памяти. Значит каждый юнит отдельно... П.С.: хотя я всё равно считаю, что проблема в шинах.. В шинах управления? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться