kaktus 0 27 марта, 2019 Опубликовано 27 марта, 2019 (изменено) · Жалоба При довольно низком уровне загрузки кристалла проект перестал укладываться по времянкам. Львиная доля проекта работает от 2-х тактовых 155.52 и на ней же удвоенной 311.04, кое где данные пересаживаются с одной на другую. Из приведенных ниже картинок видно, что тактовые буферы практически не использованы, собственно в основном работают упомянутые 2 из них, при этом проблема вылезает из-за Clock Path Skew. У меня есть подозрение, что это можно вылечить используя хваленые "UltraScale Architecture Clocking Resources", распихав BUFG во все углы. Раньше проект разводился при заполнении около 60%, но после небольшого увеличения нагрузки на частоту 155 перестал: возникают связи между (SLR) двумя кристаллами из которых состоит ПЛИС с задержками по 15 нс, но это, видимо, проблема из другой оперы! При уменьшении количества каналов и соответственно загрузки до 15% разводится, на 20% начинает сыпаться с более высокой частоты, что в данный момент и представлено вашему вниманию. Отсюда вопросы: 1. Верно ли мое предположение про BUFG? 2. Если верно, то как это грамотно сделать, желательно не залезая в код. 3. Если не верно, то..... стратегии синтеза и разводки?... Изменено 27 марта, 2019 пользователем kaktus Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alexadmin 0 27 марта, 2019 Опубликовано 27 марта, 2019 · Жалоба Говорят, что вивада сама старается строить оптимальное клоковое дерево в US, как явно заставить расставить дополнительные bufg не подскажу. А вы не хотите пойти другим путем и выделить каналы в разные pblock'и и расставить их так, чтобы не пересекались clock region? Судя по всему, при увеличении нагрузки у вас все размазывается по кристаллу и логически связанные элементы располагаются слишком далеко друг от друга (RAMB36*Y23 это в районе SLICE*Y110, как я понимаю). Как самый первый вариант, можно попробовать включить оптимизации placement, если еще не пробовали. PS получается, что у вас клок тянется даже не в следующий clock region, а через один, если я не обсчитался. Хорошо бы столбец Loocation чуть раздвинуть, там видно будет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Bad0512 2 27 марта, 2019 Опубликовано 27 марта, 2019 · Жалоба Строчка "fo=50129" вас не настораживает? Я бы уменьшил fanout директивами синтезатора типа syn_max_fan и тому подобных. В принципе это можно сделать и не влезая в исходники. Лишь правя кострейны. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MegaVolt 25 27 марта, 2019 Опубликовано 27 марта, 2019 · Жалоба 23 минуты назад, kaktus сказал: 1. Верно ли мое предположение про BUFG? Если честно то никогда с этой точки зрения не смотрел. Т.е. skew клока считал некой физической данностью которую не изменить. Возможно в новых кристаллах что-то поменяли и есть документ с описание skew каждого буфера. Если эта информация есть и она устраивает то да перенос клоков на более короткие клоковые регионы должно несколько помочь. Но если этой инфы нет то пробовать методом проб и ошибок :( Цитата 3. Если не верно, то..... стратегии синтеза и разводки?... То увеличивать длину конвейеров. Т.е. после любой маломальской логики должен стоять триггер. На мой взгляд 300 с хвостиков для всего кристалла это много. Как вариант распараллеливание данных с уменьшением скорости обработки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alexadmin 0 27 марта, 2019 Опубликовано 27 марта, 2019 · Жалоба 9 minutes ago, Bad0512 said: Строчка "fo=50129" вас не настораживает? Я бы уменьшил fanout директивами синтезатора типа syn_max_fan и тому подобных. В принципе это можно сделать и не влезая в исходники. Лишь правя кострейны. Это ж клок, а max_fanout вроде на логику действует только. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 27 марта, 2019 Опубликовано 27 марта, 2019 · Жалоба Приветствую! В UltraScale изменилась структура построения тактового дерева - она стала более распределенная и строится из сегментов. IMHO отсюда и увеличение Clock Path Skew иногда до неприличных значений. Радикальный способ борьбы с этим - локализация критически связанной логики в пределах одного или нескольких соседних Clock Region (CR). Вручную распараллелить клок по углам навряд ли получится. Так как использоваться будут все те же clock routing линии на которых в основном и получается slack. Можно попробовать привязать источник (MMCM с BUFG) ближе к центру кристалла для уменьшения разницы длинны путей распределения клока. Но это надо пробовать. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kaktus 0 27 марта, 2019 Опубликовано 27 марта, 2019 (изменено) · Жалоба Столбец Loocation раздвинул на картинке в начале темы, но думаю следующие "веселые картинки" больше прояснят ситуацию. На картинках Тактовая, и Цепь в кристалле и схеме,на которой при задержке 2.103 и периоде 3.2 из-за разных путей тактовой Slack -0.3 И на этой тактовой должно висеть в 3 раза больше чем сейчас. Также оговорюсь, что триггеров по схеме вставлено довольно много. Изменено 27 марта, 2019 пользователем kaktus Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MegaVolt 25 27 марта, 2019 Опубликовано 27 марта, 2019 · Жалоба 43 минуты назад, kaktus сказал: Также оговорюсь, что триггеров по схеме вставлено довольно много. Раз схему менять уже дальше некуда то остаётся не так много вариантов. 1. Работать на вдвое низкой частоте вдвое большим количеством блоков или узлов если позволяет архитектура. 2. Играться с расположением на кристалле кусков схемы. Задавая тип буфера явно в схеме. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Doka 1 29 марта, 2019 Опубликовано 29 марта, 2019 · Жалоба On 3/27/2019 at 10:52 AM, kaktus said: Раньше проект разводился при заполнении около 60%, но после небольшого увеличения нагрузки на частоту 155 перестал: возникают связи между (SLR) двумя кристаллами из которых состоит ПЛИС с задержками по 15 нс, но это, видимо, проблема из другой оперы! То, что выписано в Data Path на скрине: X49Y184 и X4Y23 - они находятся в одном SLR или в разных? Если в разных, то наверное стоит разрезать дизайн вручную между SLR, ибо вендор рекомендует при частотах от 250МГц для перехода между SLR использовать триггеры внутри лагун, а сам переход должен состоять минимум из 3х триггеров (а если утилизация плотная - то лучше и большее число) два из которых должны лечь в laguna_tx & laguna_rx (USER_SLL_REG="true") Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kaktus 0 29 марта, 2019 Опубликовано 29 марта, 2019 · Жалоба 6 hours ago, Doka said: То, что выписано в Data Path на скрине: X49Y184 и X4Y23 - они находятся в одном SLR или в разных? Если в разных, то наверное стоит разрезать дизайн вручную между SLR, ибо вендор рекомендует при частотах от 250МГц для перехода между SLR использовать триггеры внутри лагун, а сам переход должен состоять минимум из 3х триггеров (а если утилизация плотная - то лучше и большее число) два из которых должны лечь в laguna_tx & laguna_rx (USER_SLL_REG="true") Все это безобразие пока еще в одном SLR происходит, но от пересечений мне не уйти после возвращения полной набивки. Вас не затруднит указать мне путь к тайному знанию про лагуны и все что с ними связано? Пока нашел что-то об этом только в ug574, ug949. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Doka 1 29 марта, 2019 Опубликовано 29 марта, 2019 · Жалоба 11 minutes ago, kaktus said: Пока нашел что-то об этом только в ug574, ug949. например UG912: USER_CROSSING_SLR USER_SLR_ASSIGNMENT USER_SLL_REG Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kaktus 0 13 апреля, 2019 Опубликовано 13 апреля, 2019 · Жалоба В итоге удалось утоптать проект в кристалл. В логику работы не вносилось никаких изменений. В процессе, еще работая над неполным проектом переползли на 2018.3. Просто открытый тройкой проект собрался раза в 2 быстрее. Если будет время попробую прогнать ради любопытства полный проект снова на 2018.2 с обретенными достижениями: Помог ситуации Multicycle Path на достаточно большой группе цепей. В какой-то момент свинью подкладывала BRAM power optimization. Выглядит на схематике это забавно: триггер, которому задан fanout 4 честно раздает сигнал 4-м друзьям, но к цепи подключается 5 дополнительная нагрузка, которая прорываясь дальше сквозь иерархию превращается в раскидистое дерево на ветвях которого времянка потом и не сходится. Отключение этой оптимизации глобально с помощью директивы в настройках implementation сразу дало результат: времянки на высокой частоте больше не рассыпались не смотря на дальнейшее добавление числа каналов с 50% до 100%. (https://www.xilinx.com/support/answers/56747.html) После чего проблема в основном переместилась в точки перехода с одной частоты на другую. Тут наибольшее положительное влияние оказал констрейн CLOCK_DELAY_GROUP, когда речь шла о пересадке данных с одной частоты на другую (кратную ей). Без него дело доходило до абсурда, когда из-за разных путей тактового сигнала от буферов, стоящих в соседних позициях не сходилась времянка для триггеров, стоящих в 2нс друг от друга при периоде в 3.2 нс. По мере добавления каналов Vivado, пока мог, запихивал все в один SLR, потом переместил существенную часть во второй. Кусок, который работает на высокой частоте, полностью лежит в нижнем. Переходы между SLR на частоте 155. Никаких лагун я не прописывал, ничего сам не флурпланил. LUT - 60%; FF - 25% Хорошо себя показала стратегия синтеза AlternateRoutability. С ней разводка прошла побыстрее и не понадобилось отключать BRAM power оптимизацию. Вопросы: 1. Сейчас обе частоты идут с одной MMCM с соседних буферов, выравниваются по фазе благодаря констрейну CLOCK_DELAY_GROUP. Что если раздавать по проекту высокую частоту, а уже по месту делить ее на BUFGCE_DIV? 2. Возможно ли остановить процесс route не дожидаясь его окончания или точнее посмотреть промежуточные результаты? Он после каждой очередной итерации пишет WNS, а ждать когда он бросит эти попытки чтобы получить список проблемных цепей приходится иногда очень долго. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
negiin 0 14 апреля, 2019 Опубликовано 14 апреля, 2019 · Жалоба 11 hours ago, kaktus said: Тут наибольшее положительное влияние оказал констрейн CLOCK_DELAY_GROUP, когда речь шла о пересадке данных с одной частоты на другую (кратную ей). Без него дело доходило до абсурда, когда из-за разных путей тактового сигнала от буферов, стоящих в соседних позициях не сходилась времянка для триггеров, стоящих в 2нс друг от друга при периоде в 3.2 нс. Intel рекомендует передавать данные между кратными частотами как между асинхронными, даже если они синхронны. Может у xilinx есть подобная рекомендация? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kaktus 0 15 апреля, 2019 Опубликовано 15 апреля, 2019 · Жалоба Вот иллюстрация прикола с оптимизацией питания для BRAM. Появляются цепи с характерными названиями pwropt*, *cooolgate* , на ограничения по fanout забивает, времянки в итоге не сходятся. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться