[kaktus 0]

При довольно низком уровне загрузки кристалла проект перестал укладываться по времянкам.

Львиная доля проекта работает от 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]

Говорят, что вивада сама старается строить оптимальное клоковое дерево в US, как явно заставить расставить дополнительные bufg не подскажу. А вы не хотите пойти другим путем и выделить каналы в разные pblock'и и расставить их так, чтобы не пересекались clock region? Судя по всему, при увеличении нагрузки у вас все размазывается по кристаллу и логически связанные элементы располагаются слишком далеко друг от друга (RAMB36*Y23 это в районе SLICE*Y110, как я понимаю). Как самый первый вариант, можно попробовать включить оптимизации placement, если еще не пробовали.

PS получается, что у вас клок тянется даже не в следующий clock region, а через один, если я не обсчитался. Хорошо бы столбец Loocation чуть раздвинуть, там видно будет.

[Bad0512 2]

Строчка "fo=50129" вас не настораживает? Я бы уменьшил fanout директивами синтезатора типа syn_max_fan и тому подобных. В принципе это можно сделать и не влезая в исходники. Лишь правя кострейны.

[MegaVolt 25]

23 минуты назад, kaktus сказал:

1. Верно ли мое предположение про BUFG?

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

Цитата

3. Если не верно, то..... стратегии синтеза и разводки?...

То увеличивать длину конвейеров. Т.е. после любой маломальской логики должен стоять триггер. На мой взгляд 300 с хвостиков для всего кристалла это много. Как вариант распараллеливание данных с уменьшением скорости обработки.

[alexadmin 0]

9 minutes ago, Bad0512 said:

Строчка "fo=50129" вас не настораживает? Я бы уменьшил fanout директивами синтезатора типа syn_max_fan и тому подобных. В принципе это можно сделать и не влезая в исходники. Лишь правя кострейны.

Это ж клок, а max_fanout вроде на логику действует только.

[RobFPGA 27]

Приветствую!

В UltraScale  изменилась структура построения тактового  дерева  - она стала более распределенная и строится из сегментов. IMHO отсюда и увеличение Clock Path Skew иногда до неприличных значений.  Радикальный способ борьбы с этим - локализация  критически связанной логики в пределах одного или нескольких соседних  Clock Region (CR).  Вручную  распараллелить  клок по углам навряд ли получится. Так как использоваться будут все те же clock routing линии на которых в основном и получается slack.  Можно попробовать привязать источник (MMCM с BUFG) ближе к центру кристалла для уменьшения разницы длинны путей распределения клока. Но это надо пробовать. 

Удачи! Rob.

[kaktus 0]

Столбец Loocation раздвинул на картинке в начале темы, но думаю следующие "веселые картинки" больше прояснят ситуацию.

На картинках Тактовая, и Цепь в кристалле и схеме,на которой при задержке 2.103 и периоде 3.2 из-за разных путей тактовой Slack -0.3

И на этой тактовой должно висеть в 3 раза больше чем сейчас. Также оговорюсь, что триггеров по схеме вставлено довольно много. 

Изменено 27 марта, 2019 пользователем kaktus

[MegaVolt 25]

43 минуты назад, kaktus сказал:

Также оговорюсь, что триггеров по схеме вставлено довольно много. 

Раз схему менять уже дальше некуда то остаётся не так много вариантов.
1. Работать на вдвое низкой частоте вдвое большим количеством блоков или узлов если позволяет архитектура.
2. Играться с расположением на кристалле кусков схемы. Задавая тип буфера явно в схеме.

[Doka 1]

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]

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]

11 minutes ago, kaktus said:

Пока нашел что-то об этом только в ug574, ug949.

например UG912:

• USER_CROSSING_SLR
• USER_SLR_ASSIGNMENT
• USER_SLL_REG

 

[kaktus 0]

В итоге удалось утоптать проект в кристалл. В логику работы не вносилось никаких изменений. В процессе, еще работая над неполным проектом переползли на 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]

11 hours ago, kaktus said:

Тут наибольшее положительное влияние оказал констрейн CLOCK_DELAY_GROUP, когда речь шла о пересадке данных с одной частоты на другую (кратную ей). Без него дело доходило до абсурда, когда из-за разных путей тактового сигнала от буферов, стоящих в соседних позициях не сходилась времянка для триггеров, стоящих в 2нс друг от друга при периоде в 3.2 нс.

Intel рекомендует передавать данные между кратными частотами как между асинхронными, даже если они синхронны. Может у xilinx есть подобная рекомендация? 

[kaktus 0]

Вот иллюстрация прикола с оптимизацией питания для BRAM. Появляются цепи с характерными названиями pwropt*, *cooolgate* , на ограничения по fanout забивает, времянки в итоге не сходятся.