[Doka 1]

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

Появилась необходимость работы с US+ с несколькими кристаллами (3...4 SLRs)

Для уменьшения рантайма P&R да и в целом, чтобы помочь вивадо повысить QoR хочу вручную назначить по SLR где какой блок должен лежать (ранее не доводилось работать с SLR), в связи с чем появились несколько вопросов, но перед этим пару слов о самом дизайне:

дизайн представляет собой соединение в единый datapath (выход одного модуля подаётся на вход другого моделя и так далее по цепочке) достаточно крупных модулей (~200k LUT), причем в некоторых модулях (назовём его модуль_с_bigDSP) может быть высокое использование независимых примитивов (например ~80% всех имеющихся на кристалле DSP48). частоты > 400 МГц. Дизайн использует один тактовый домен, используется одно направление передачи данных по цепочке модулей (datapath без какого-либо handshake).

 

Вопросы:

-----------------------------------------

1. PBlock: поскольку разные PBlock'и не могут содержать одни и теже SLICE (и другие ресурсы), то непонятно как сделать следующий финт ушами:

Вариант А:

Допустим для первого приближения было бы достаточно просто указывать на каком SLR располагаться какому модулю (без нарезки конкретных регионов внутри SLR), а там бы вивадо сам бы расплейсил как ему удобно. притом модуль_с_bigDSP мы никакак не ограничиваем прявязками, чтобы он рассредоточился по всему кристаллу

Вариант Б:

Мы жёстко привязываем модули к конкретным PBlock внутри SLR, притом модуль_с_bigDSP вручную разрезаем на равные числу SLR части для использования всех имеющихся ресурсов DSP48, делаем новым частям модуль_с_bigDSP также PBlock с распределением по всей площади конкретных SLR

Вариант В:

Жёстко привязываем модули к конкретным PBlock внутри SLR, притом модуль_с_bigDSP  не привязан ни к одному PBlock и будет заплейсен автоматом поверх уже имеющихся  PBlock (критерий для плейсмента - наличие достаточного числа необходимых ресурсов DSP48. В этом варианте упор делается на то, что плейсер вивадо сам знает "как лучше" ( в 1ю очередь с т.з. времянок) и создавать ему искусственные ограничения, разрезая руками модуль_с_bigDSP  не совсем правильно.

 

PS: знаю что есть возможность создавать PBlockи из независимых примитивов вроде DSP48, но рядом с DSP48 нужна логика, иначе тайминги будет свести нереально из-за длины цепей

-----------------------------------------

2. Продолжение пп.1: осуществимо ли вышеописанное, если всю имплементацию разбить на 2 прохода:

         1й: синтез модулей out-of-context  с нужной  привязкой по PBlock

         2й: синтез/P&R топа с (частично) перекрывающимися PBlock

?

-----------------------------------------

3. Laguna: гайд для частот свыше 250МГц требует вставки между разными SLR трех стадий регистров: один на передающей стороне, второй - как часть передатчика (внутри лагуны) и третий уже на другом SLR для приёма сигнала через SSI: мне было бы удобнее реализовать все эти три стадии внутри модуля (на выходе), но если модуль будет обконстрейнен на конкретный PBlock - сможет ли вивадо "вытащить" за границы этого PBlock регистры для лагуны и для следующего SLR либо вивадо не поймёт зачем я их запихал в модуль и будет жестко выполнять гайд по плейсменту внутри указанного PBlock?

 

 

[RobFPGA 27]

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

 

Сразу оговорюсь что с большими (несколько SLR) чипами опыта мало.  Но общее правило с PBlock - чем более детально он описан (что и где располагается) тем быстрее и повторяемые результаты P&R.  Конечно если ваши ограничения реализуемые и не вводят Vivado в ступор. В этом свете вариант Б мне кажется предпочтительнее. 

 

Что касается регистров связи то если они вами назначены в PBlock то вытащить их за границы размещения PBlock Vivado не вправе. Так что обязательно нужно исключать эти регистры из назначения в PBlock. 

 

1 hour ago, Doka said:

2. Продолжение пп.1: ...

При синтезе PBblock не используется - так как эти constraint только для P&R  - тут лучше смотреть в сторону методики Partition/PartialRecofiguration. В этом случае можно независимо делать P&R для отдельных PBlock/SLR. 

 

Удачи! Rob.

 

[myq 0]

Привет!

Не совсем понял разницу между п.2 и п.3.

Я делал так:
Большой модуль, который занимает несколько SLR - не привязан ни к чему.
В нём заведены некие партишены, которые я точно знаю, в какой SLR их положить. Для этих партишенов заведены pblock'и размером с SLR.
В большом модуле между партишенами используются SLR Crossing Register Slices для AXIS-интерфейсов, и самописные модули slr_cross для forward-only интерфейсов.
На сегодняшний день оптимальный переход между SLR'ами - это 4 триггера: обычный -> Laguna_TX -> Laguna_RX-> обычный.

[Doka 1]

RobFPGA

myq

спасибо!

 

пока что временно остановился на вот таком интересном "заменителе" pblock-approach: USER_SLR_ASSIGNMENT

 

Quote

The USER_SLR_ASSIGNMENT property lets you specify the placement of cells into a defined super logic region (SLR), or grouped together into the same SLR without defining a specific SLR.

 

ну и плюс по лагунам буду юзать рецепт  4хFF + SLR Crossing Register Slices

[Doka 1]

появился еще один вопрос, напрямую связанный с SLR-дизайнами,

на рисунке изображены ядра (притом довольно крупные), которые используются в дизайне, притом тактовый сигнал на весь дизайн один, передача от ядра к ядру, как упоминалось выше, идёт в одном направлении, без всяких хендшейков и проч.

 

Вопрос:

1. как для такого дизайна вивадо строит распространение клока - понимает ли он, что клок Core1 может быть расфазирован с Core8 (хоть это формально один и тот же клок). Для ASIC тут бы вообще в идеале сопровождать клок вместе с данными при переходе от ядра к ядру, а уже внутри ядра строить свой локальный clock_root конкретно под каждое ядро

 

2. какие существуют методы написания констрейн-гайдлайнов  клоков для SLR? Цель - уменьшить рантайм + улучшить QoR, дав прямое указание вивадо, что от него хотят (ну, например, чтобы он не стал делать бесполезную работу по выравниванию фаз клока Core1 и Core8)

 

PS: судя по тайминг-репорт клоки на разных SLR вивадо таки-считает за разные клоки, наверное вопрос появился из-за того, что не очень хорошо представляю какие возможности/стратегии по роутингу клоков закладывались в кристаллы с несколькими SLR (увы, UG572 по фразе SLR ничего не находит).

 

[RobFPGA 27]

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

1 hour ago, Doka said:

(увы, UG572 по фразе SLR ничего не находит).

Посмотрите еще UltraFast Design Methodology Guide for the Vivado Design Suite UG949  раздел о Clocking Guidelines.

Удачи! Rob.

[Doka 1]

RobFPGA

UG949 посмотрел, действительно наиболее полно описывает тему SLR

спасибо за наводку!

 

 

--------------------------------

 

Есть еще такой кейс по плейсменту в vivado:

Допустим, в дизайне 2 pblock'а, занимающих полностью два SLR (по одному каждый). Все модули (cell'ы) раскиданы по этим двум pblock'ам, кроме модулей, описывающих кросс-переходы между SLR (в  их просто цепочка из 4-х триггеров, 2 из которых это laguna_tx и laguna_rx).

 

 

Как это всё правильно расплейсить? Сначала вызвать place_pblocks, а потом place_design, чтобы вставились модули с переходами между SLR?
В таком случае будут ли доступны плейсеру ресурсы, зарезервированные под pblock'и?
Если нет, значит ли, что единственный путь разрезать модуль с переходами между SLR на два и привязывать их к двум отдельны pblock'ам?