[blackfin 16]

On 2/7/2023 at 4:30 PM, Koluchiy said:

Есть ли директива, глобально отменяющая mark_debug ?

А с чего вы решили, что у вас в проекте есть атрибут mark_debug?

Если у вас в проекте:

On 2/7/2023 at 2:11 PM, Koluchiy said:

Имеем проект, в котором основную часть занимает ядро с закрытыми исходниками.

 

[RobFPGA 27]

4 hours ago, Koluchiy said:

1) В настройках Vivado в каждом процессе есть окошко "more options". Где можно посмотреть список этих самых more options для каждого процесса?

2) Есть ли в Vivado аналог директивы Seed - (Из Квартуса: Specifies the starting value the Fitter uses when randomly determining the initial placement for the current design )

Т.е. идея такая, запускать имплементацию в Vivado с разными начальными условиями, пока времянки не сойдутся.

3) Можно ли в Vivado увеличить время поиска, или количество итераций? Т.е. чтобы в рамках каждой стратегии больше перебирал вариантов. Т.е. нет проблемы поставить на ночку, или там запустить на мощном сервере, чтобы считал, пока не найдет нормальный вариант.

4) Зависит ли как-то качество разводки от количества ядер, выделяемого для каждого процесса имплементации? Ну т.е. если для процесса выделить не 4 ядра, а 8 - обработает ли оно в рамках своей стратегии больше вариантов?

 

1.  Посмотреть можно в tcl  консоли  набирая  имя процесса с  опцией -h     
2. Нет.
3. Нет  - Алгоритм P&R в Vivado  базируется на других принципах чем классический основанный на начальном рандом. Перебирать можно комбинации опций.  А так же итеративное повторение отдельных шагов P&R с частичной пере-размещением/разводкой проблемных цепей, но это уже своими скриптами.
4. Не помню точно, где то в доке было упоминание о повторяемости результатов P&R при разных OS,  и числе процов.  

[Koluchiy 0]

2 hours ago, blackfin said:

А с чего вы решили, что у вас в проекте есть атрибут mark_debug?

Если у вас в проекте:

Вы моей цитатой сами себе ответили.

Основная часть - это не 100%.

[Koluchiy 0]

27 minutes ago, RobFPGA said:

1.  Посмотреть можно в tcl  консоли  набирая  имя процесса с  опцией -h    

Спасибо! Небогато там.

[Alex77 4]

может и не богато, однако с десяток вариантов синтеза и 30-40 имплементрации. плюс в "опциях" есть числовые параметры (которые тоже можно менять). так что от 500 вариантов сборки проекта. - на месяц работы (кругло суточной) компа хватит.

а по хорошему стоит посмотреть rtl/synt/imp "methodology". и сделать соответствующие выводы.

[RobFPGA 27]

4 hours ago, Koluchiy said:

Спасибо! Небогато там.

Для  больших и напряжённых  дизайнов  нет универсальной кнопки "сделай мне хорошо".  Для получения гарантированных и повторяемых результатов всегда  надо прикладывать усилия для: анализа проблем,   разбиения дизайна на патриции,  фиксации оных на кристалле,  вдумчивого констрейнинга,  разработки своих  итеративных  сценариев P&R  позволяющих  гарантированно собрать  дизайн в  разумное время.   

[Koluchiy 0]

On 2/7/2023 at 2:26 PM, des00 said:

а какой конкретно путь не сходится? сколько слоев логики, распределение задержки: логика/роутинг и т.д. может быть это и есть предел. Может у вас требования 450МГц, а там 8 слоев логики.

Спрашивали - отвечаем.

Частота 240

4 уровня логики

фанаут 24

logic/net 1.4/2.5

 

Это путь с самым большим слаком (в текущем варианте - 0.408 нс). Но путей со слаками в этом варианте компиляции - много.

[TRILLER 0]

В 07.02.2023 в 14:11, Koluchiy сказал:

Имеем проект, в котором основную часть занимает ядро с закрытыми исходниками.

В этом случае я бы Вам рекомендовал сгруппировать BRAM в компактные Pblocks руководствуясь простейшей логикой и здравым смыслом - ведь наверняка есть базовое понимание устройства ядра - и применил EarlyBlockPlacement стратегию. Плэйсер без хотя бы базовых инструкций часто бессмысленно дробит дизайн.

[blackfin 16]

On 2/7/2023 at 2:11 PM, Koluchiy said:

Имеем проект, в котором основную часть занимает ядро с закрытыми исходниками.

При компиляции, в этом ядре не сходятся времянки.

..., в одной из стратегий не сходится на 0.01 нс.

Простейший план такой:

 

1. Открываем синтезированный дизайн: Open Synthesized Design
2. В окне "Netlist" находим зашифрованный модуль
3. Правой кнопкой мыши: Floorplanning->Draw Pblock
4. Рисуем "Pblock" подходящего размера
5. В окне "Pblock Properties" на вкадке "Statistics" проверяем статистику: %Util ~= 90% ... 95%
6. В окне "Pblock Properties" на вкадке "Properties" убираем флаг: "IS_SOFT", ставим флаг: "EXCLUDE_PLACEMENT"
7. Нажимаем кнопку "Сохранить"
8. Запускаем имплементацию

 

Этот план может сработать, если все критические пути находятся внутри зашифрованного модуля.
 

[des00 25]

16 hours ago, Koluchiy said:

Частота 240

4 уровня логики

фанаут 24

logic/net 1.4/2.5

4 уровня да, где то на 250МГц можно рассчитывать, фанаут 24 тоже ни о чем, а вот то что задержка разводки в ~2 раза выше чем логики беда. Либо у вас упаковка в SLICE не очень и если есть возможность, то я бы переписал эту часть логики, либо у вас проект плохо влезает в чип и он сильно заполнен. В этом случае, может помочь.....смена стратегии с производительности на ресурс, чтобы проект был более компактным. Ну и все что с этим связано: константы времени исполнения в мультициклы или ложные пути и т.д

1 hour ago, blackfin said:

4. Рисуем "Pblock" подходящего размера

ага, а если там логика, дсп и память, да все не раскладывается в линейку/квадратик, вот там будет потом космос, с попыткой разложить его туда, куда он не лезет

[blackfin 16]

On 2/9/2023 at 9:58 AM, des00 said:

ага, а если там логика, дсп и память, да все не раскладывается в линейку/квадратик, вот там будет потом космос, с попыткой разложить его туда, куда он не лезет

И что, для вас это проблема? :)

UG909, page 34:

[des00 25]

17 minutes ago, blackfin said:

И что, для вас это проблема? 🙂

Проблема не мышку тыкнуть, проблема адекватно оценить требуемые ресурсы модуля, с учетом того что они различаются для разных стратегий сборки, под разную производительность. Затем DSP/RAMB блоки стоят в колонках по чипу, со сложным роутингом, переносами, выходами на обычную логику и т.д. Тот же например DSP фильтр на основе цепи делается только в вертикальной линейке, но не делается в горизонтальной. Это я все к тому, что нарезав от балды Pблоки, можно ухудшить ситуацию, вместо ее улучшения.

 

[blackfin 16]

On 2/9/2023 at 10:44 AM, des00 said:

Это я все к тому, что нарезав от балды Pблоки, можно ухудшить ситуацию, вместо ее улучшения.

А есть другие варианты, если времянки не сходятся в зашифрованном модуле?

On 2/9/2023 at 9:58 AM, des00 said:

я бы переписал эту часть логики, либо у вас проект плохо влезает в чип и он сильно заполнен.
Ну и все что с этим связано: константы времени исполнения в мультициклы или ложные пути и т.д

Что там можно переписывать, если доступ есть только к нетлисту?

On 2/9/2023 at 10:44 AM, des00 said:

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

Это как раз не проблема. После синтеза на вкладке "Статистика" Vivado указывает все требуемые для модуля ресурсы.

[des00 25]

3 minutes ago, blackfin said:

А есть другие варианты, если времянки не сходятся в зашифрованном модуле?

А кто сказал что она не сходится именно в зашифрованном модуле? ТС нигде не писал об этом, просто указал что не сходится в проекте, в котором есть и своя логика тоже и она там тоже не сходится)

ЗЫ. Есть еще особенность такого прибивания, ЕМНП, если вы это сделаете, вы лишаете софт возможно повторно использовать свободную логику в слайсах если она есть (триггер, мультиплексор, байпас), этим вы снижаете утилизацию SLICE, а с учетом отчета там и так проблемы с этим (довольно часто бывает что использование SLICE 100%, а LUT/REG 70/80%), а тут мы еще можем больше усугубить сие)

[blackfin 16]

On 2/9/2023 at 10:51 AM, des00 said:

А кто сказал что она не сходится именно в зашифрованном модуле? ТС нигде не писал об этом, ...

Читайте внимательно:

On 2/7/2023 at 2:11 PM, Koluchiy said:

Имеем проект, в котором основную часть занимает ядро с закрытыми исходниками.

При компиляции, в этом ядре не сходятся времянки.