[dxp 65]

Всем привет!

 

С Xilinx ранее работать серьёзно не приходилось, всё больше была Altera, поэтому нахожусь в процессе набора опыта и познания особенностей FPGA Xilinx и её САПР Vivado.

 

Текущий проект: Artix-7 xc7a200t, Vivado 2018.2. По результатам очередной сборки развалились времянки: тактовый домен 4 нс (250 МГц), слак по сетапу порядка 0.8 нс. Смотрю, на чём просело, вижу, задержку пути на логике 1.269 нс, на трассировке 3.229. Логики там реально немного, поэтому и странно, что не уложилось. Открываю Device, и вижу, что вивада утащила часть логики модуля в другой Clock Region, отсюда и такая конская задержка (плоховато, но видно беленьким показан путь).

 

 

Никакими изменениями стратегий ситуацию исправить не удалось. Вообще, ситуация представляется достаточно простой - кристалл почти пустой, и места для логики в левом Clock Region и под ним полно. Зачем же плейсер рассовал логику так, что трассировщик потом уже ничего не может исправить?

 

Ну, делать нечего, пришлось применить ручное назначение потрохов модуля в pblock.

 

 

После этого всё получилось, времянки сошлись и на дивайсе всё выглядит компактно, логично и красиво.

 

Собственно вопрос: это правильный подход и нормальная практика для Xilinx/Vivado или это костыльно и правильно всё же как-то вызвать интеллект САПР из сумрака, чтобы она сама соображала, как размещать, чтобы проект разводился без фейлов? Просто на Altera/Quartus не помню случая, чтобы приходилось фиксить работут фиттера - он всегда сам справлялся лучше (а попытки лезть к нему напрямую только мешали).

 

P.S. Вдогонку штрих: без констрейна на pblock длительность сборки:

 

синтез: 0:33
P&R: 2:19

 

и в итоге времянка не сходится.

 

с pblock'ом:

 

синтез: 0:33
P&R: 1:38

 

и времянка в норме.

[RobFPGA 35]

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

Увы алгоритм P&R в Xilinx этим грешит  размазывая логику по кристаллу что манку по тарелке. IMHO  скорее всего это связанно с другой структурой FPGA (более однородной) по сравнению с Altera.  Поэтому применение pblock это необходимое условие для повторяемости результатов и ускорения P&R. особенно для скоростных и загруженных дизайнов.

Удачи! Rob.

 

[ViKo 1]

Я вижу причину такого поведения как попытку распределить выделяемую тепловую энергию равномерно по кристаллу. Может, есть установка не распределять? 

[dxp 65]

Стремление похвальное. Но не в ущерб же таймингам? Кому нужно хорошее распределение тепла по кристаллу при не рабочем проекте?

[ViKo 1]

Ксайлинксу? Может, иначе они не работают от перегрева?

[Koluchiy 0]

Есть два пути самурая, и каждый выбирает свой.

Самый лучший инструмент - не тот, который самый лучший, а тот, которым лучше всего владеешь.

 

Что касается холивара Альтера/Ксайлинкс, то лично у меня поведение одинаковое и там и там. Всё зависит от скоростной нагруженности проекта. Если он нагружен хорошо - компилятор без помощи разработчика будет лажать.

[RobFPGA 35]

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

45 minutes ago, ViKo said:

Я вижу причину такого поведения как попытку распределить выделяемую тепловую энергию равномерно по кристаллу. Может, есть установка не распределять? 

Думаю что нет.  Тут скорее дело в  алгоритме минимизации  целевой функции тайминга/роутинга при P&R. 

Например для структуры связей A <-> B <-> C <-> ... N  и N <->A. Когда суммарный вес множества коротких связей между близкими блоками превышает  вес одной длинной. Ощущения что при размещении  блоки ставятся один за другим.  При этом направление размещения для следующего не имеет существенно роли так как связи короткие (можно даже предположить что преимущество будет в сторону пустого пространства). В какой то момент  функция попадает в локальный минимум и выбраться от туда уже не может.

В ISE было еще печальнее - там  P&R мог запросто  модуль вытянуть колбасой по диагонали через весь кристалл. В Vivado это заметно  поправили. Во всяком случае для Kintex|Virtex,  (для Artix не скажу почти не работал с ними).

Удачи! Rob.

[dxp 65]

12 минут назад, Koluchiy сказал:

Что касается холивара Альтера/Ксайлинкс

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

[Koluchiy 0]

А констрейны на i/o как-то задавались?

[yes 8]

всегда так делаю :)

кстати, такими же проблемами (неумением правильно размещать элементы) страдают и размещатели для АЗИКов

 

[Dvil 0]

Мне кажется, он просто их от того , так разводит, что у вас ножки уже заданы , вот он и стремиться регистры к ним рассположить

[dxp 65]

В 07.12.2018 в 21:17, Koluchiy сказал:

А констрейны на i/o как-то задавались?

А это тут причём? Эта логика очень далеко от I/O пинов - за несколькими слоями регистров и за парой аппаратных блоков. И даже если бы там пины тянули, то это не оправдание такого горбатого размещения.

В 08.12.2018 в 05:42, Nik. сказал:

Мне кажется, он просто их от того , так разводит, что у вас ножки уже заданы , вот он и стремиться регистры к ним рассположить

Нет, этого и близко нет. Там данные приходят через аппаратные GT трансиверы, проходят через аппаратный же PCEe блок и только после этого попадают на логику. Эти аппаратные блоки расположены в левом верхнем Clock Region, и по идее там же нужно размещать сопутствующую логику. В целом плейсер так и делает за некоторым исключением. Логика такого поведения не понятна.

[Koluchiy 0]

On 12/9/2018 at 12:17 PM, dxp said:

А это тут причём? Эта логика очень далеко от I/O пинов - за несколькими слоями регистров и за парой аппаратных блоков. И даже если бы там пины тянули, то это не оправдание такого горбатого размещения.

Окей, буду прокачивать исусство телепатии.