Подскажите, как бороть времянки в Xilinx?, Задержки в цепях гораздо больше, чем в логике Опции

[Koluchiy]

Здравствуйте, уважаемые гуры.

Собираю проект под Spartan-6, а точнее XC6SLX150T.
Микросхема большая, текущая версия проекта занимает ее примерно наполовину (в будущем хотелось бы заполнить под завязку).
При компиляции (синтез Synplify, остальное ISE 12.3) проект не проходит по времянкам.

В отчете по ошибкам времянок классическая картина следующая:

Код

     -------------------------------------------------  -------------------
SLICE_X52Y115.CQ     Tcko                  0.447
                                                
SLICE_X48Y99.A3      net (fanout=8)        1.571
SLICE_X48Y99.CMUX    Topac                 0.537
                                                                                                    
                                                                                                    
SLICE_X51Y97.C5      net (fanout=2)        0.573
SLICE_X51Y97.C       Tilo                  0.259
                                                                                                    
SLICE_X85Y58.B4      net (fanout=12)       3.898
SLICE_X85Y58.B       Tilo                  0.259
                                                                                                    
SLICE_X113Y49.C4     net (fanout=68)       2.203
SLICE_X113Y49.C      Tilo                  0.259
                                                                                                    
SLICE_X116Y49.C4     net (fanout=16)       0.727
SLICE_X116Y49.C      Tilo                  0.204
                                                                                                    
SLICE_X105Y54.A3     net (fanout=1)        1.158
SLICE_X105Y54.A      Tilo                  0.259
                                                                                                    
SLICE_X105Y54.B6     net (fanout=1)        0.118
SLICE_X105Y54.B      Tilo                  0.259
                                                                                                    
SLICE_X85Y54.D6      net (fanout=1)        1.236
SLICE_X85Y54.CLK     Tas                   0.322

     -------------------------------------------------  ---------------------------
     Total                                     14.289ns (2.805ns logic, 11.484ns route)
                                                        (19.6% logic, 80.4% route)

Можно видеть, что:
1) потери на "путь" гораздо больше, чем потери на логику.
2) fanout части цепей достигает больших значений (68 например), что по моему мнению не может не сказываться на задержках в этой цепи. Кстати, в настройках Synplify ставлю Max fanout = 30, что не мешает появляться цифрам типа вышеуказанного 68.

Собственно, вопросов 2:

1) Прав ли я в том, что большой fanout цепей увеличивает их задержки. Если да - то как его уменьшить.
2) Если синтез производится силами Synplify, какие оптимизации Map в ISE нужно включать, а какие - лучше не надо? Например, в настройках и того, и того есть возможность включить Retiming.

Ну или пошлите, где на эту тему почитать.

Заранее спасибо.

Сообщение отредактировал Koluchiy - Dec 22 2010, 15:50

[Shtirlits]

1) да. разрешить Map Properties -> register duplication -> On, поиграть со стратегиями P&R
2) там нечего крутить практически, только effort и strategy. Balanced и Area в некоторых редких случаях может дать лучше времянки (для CRC, DES и т.п.). В общем случае Allow Logic Optimization Across Hierarchy нужно включать, но не все схемы это допускают. Может быть я путаю сейчас с опцией синтеза xst "Keep Hierarchy", после которой может потребоваться вносить изменения в .UCF

Попробуйте синтезировать XST, несколько лет назад я перестал даже пытаться синтезировать синплифаем, не умею его готовить.
Если вы контролируете исходные тексты, можете проверить корректность после изменений и представляете где и что, то может иметь смысл руками дублировать регистры с большим fanout.
В случае, когда дизайн большой, сделан из огромного чужого кода или готовых ядер, то однозначно нужно играть настройками, выкручивать все на максимум (Reentrant Route, High, High, Continue on Impossible), но можно сначала заглянуть в PlanAhead и помочь с размещением руками. Наделать AreaGroup и расставить все аккуратно.

[disel]

ИМХО. Судя по всему, слоев логики очень много, перекос в сторону route большой. Игрой с настройками синтезатора\маппера\парсера ничего, кроме потери времени и изучения этих самых настроек, не достигните. Схему надо менять. Конвеер, мультицикловые констрейны и т.д.
С увеличением загрузки кристалла ситуация будет только ухудшаться.
Полезный документ wp381 (правда он про виртекс). Был какой то еще документ полезный про хай-перфоманс, завтра на работе найду.
А сколько не влезает то? В процентах. В ксалинксовых апноутах пишется, что настройками синтеза\маппера можно играть если процентов 10 не хватает. Если больше, то схему нужно корректировать.

[Shtirlits]

Случаи бывают разные. Плохим размещением можно и с 200 MHz до 20 MHz уронить.
Некоторые схемы вообще могут работать, только при правильных констрейнах размещения.
Переделывать схему конечно прекрасно, но как бы не попасть на последующую отладку и верификацию. Кто гарантирует, что переделанная схема будет такая же по функциональности?
Я за подробное изучение проблем в схеме и последующие подсказки placer-у без переделки самой схемы.

[Leka]

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

[RobFPGA]

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

В такой ситуации в первую очередь анализ путей где именно возникают проблемы,
затем попытка уменьшит длину связей заданием ограничений на размещение
как говорил товарищ Shtirlits -AreaGroup, фиксация блоков памяти, и.т.д.
Полезно также посмотреть нет ли "лишних" констрейн. Поскольку очень часто при излишней "зажатости" PR не может автоматом оптимально разместить проект. Например если есть несколько clk которые формируются из одного источника то при этом
автоматом появляются констрейны на связи между clk доменами которые могут быть очень "жесткими" хоть и реально не нужными в проекте.
Соответственно если их не поставить в "игнор" то PR всеми своими немощными попытками будет пытается их реализовать теряя при этом в действительно нужных местах. Ну и естественно если по дизайну цепь необходимо размазать по всему кристаллу - тут только изменение логики может помочь.

Так что ищите хороший бубен! :-)

Удачи! Rob.

[Koluchiy]

1) да. разрешить Map Properties -> register duplication -> On

Включено.

В общем случае Allow Logic Optimization Across Hierarchy нужно включать

Включено.

Попробуйте синтезировать XST

На этом проекте (да и вообще на моих проектах) Синплифай дает ощутимый выигрыш.
Кроме того, в XST скорее всего надо будет менять текст, т.к. он не всё поддерживает, чего написано.

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

А почему оно само не может автоматом размножать? Это недоделки ихних программистов, или есть какие-то проблемы с размножением (учитывая, что свободная логика есть).

А сколько не влезает то? В процентах.

Логика влезает вся (заполнение микросхемы порядка 44%).
Проблема во времянках.
Если судить по отчетам P&R, проблемных цепей всего ничего - для разных настроек от 15 до 100.
Но при правке этих цепей и перекомпиляции он успешно находит другие "не успевающие" цепи.

Собственно, основная фишка работы в том, что проект изначально создавался и отлаживался под Virtex-5, а теперь вот начальство издало гениальное решение переделывать практически готовый проект под Spartan-6...
А он ощутимо медленнее...

[disel]

Логика влезает вся (заполнение микросхемы порядка 44%).
Проблема во времянках.

Я про то сколько по времени не влезает.

[Koluchiy]

Порядка 2-3 наносекунд на проблемную цепь.

Период порядка 12.5 нс.

Сообщение отредактировал Koluchiy - Dec 23 2010, 05:11

[disel]

wp331. Он правда достаточно древний, и не все применимо, но больших изменений нет.
Регистры сами размножаться могут - включить Register Duplication.
Ключевое слово для поиска - Timing Closure.
Если у вас с 44% заполнения уже проблемы, то при полном заполнении проблемы будут еще больше. Я бы схему начал переделывать сразу. Мучений меньше.

Порядка 2-3 наносекунд на проблемную цепь.

Период порядка 12.5 нс.

3/12,5 = 24 %. Настройками маппера\парсера вы этого не выберете. Если выберете сейчас, по при заполнении кристалла, опять вернетесь к этой проблеме.

Мультициклы в констрейнах, статичные цепи в игнор весьма помогают.

[Koluchiy]

Если у вас с 44% заполнения уже проблемы, то при полном заполнении проблемы будут еще больше. Я бы схему начал переделывать сразу. Мучений меньше.

Теоретически это понятно, а практически эти 44% - задача минимум, до выполнения которой, казалось бы, всего ничего. До того момента, когда будет необходимо выполнять задачу максимум (80%), может чего-то "по опыту эксплуатации" поменяться, что вызовет необходимость что-то дополнительно корректировать (возможно, существенно).
Поэтому хочется откомпилить "as is".
Да и вообще интересно выжать из ПО максимум, чего оно может дать.

Мультициклы в констрейнах, статичные цепи в игнор весьма помогают.

Буду пытаться...

3/12,5 = 24 %.

Тем не менее, если посмотреть на табличку в первом посте и представить, что в цепи с fanout 68 сделать, чтобы fanout был = 34 и при этом задержка станет вместо 2.2 нс -> 1.1 нс, то это уже 1 нс. Если с остальных столько же наскрести, то вот уже те самые 2-3 нс.

Сообщение отредактировал Koluchiy - Dec 23 2010, 05:24

[disel]

ну вот эти можно пробывать:
Perform Timing-Driven Packing and Placemen
Map Effort Level - в хай
Extra Effort - в хай
Trim Unconnected Signals - включить
Optimization Strategy - Speed
LUT Combining отключить

Global Optimization весьма помогает.

Может поможет.
Можно планахед запустить. там уже предопределенные стратегии есть.

Но вот это ваше сообщение выглядит грустно:

Но при правке этих цепей и перекомпиляции он успешно находит другие "не успевающие" цепи.

В wp331 первый рисунок очень полезен, посмотрите. Там вообще весь алгоритм очень наглядно показан.

[DmitryR]

Fanout 68 - это на самом деле довольно мало, не вижу смысла пытаться его уменьшить. Надо сначала сделать размещение в PlanAhead, а настройки маппера выкрутить как раз на минимум. Ибо если вы сейчас будете выезжать на маппере - при загрузке микросхемы в 80% вы не влезете никуда наверняка. Начинайте с PlanAhead всегда, в любых относительно сложных проектах: это заодно еще может сильно уменьшить время работы маппера.

[Koluchiy]

Оно, конечно, мало(хотя есть цепи с fanout за 80).
Но если посмотреть на то, что задержки цепей от задержки всего пути составляют порядка 80%, уже кажется, что много...
Ну и есть некоторое чисто академическое непонимание вопроса - почему в Synplify стоит ограничение 30, а на практике получается гораздо больше?

[DmitryR]

Оно, конечно, мало(хотя есть цепи с fanout за 80).
Но если посмотреть на то, что задержки цепей от задержки всего пути составляют порядка 80%, уже кажется, что много...

Это получается не от фанаута, а от неоптимального размещения, когда соединяемые модули оказываются физически далеко друг от друга.

Ну и есть некоторое чисто академическое непонимание вопроса - почему в Synplify стоит ограничение 30, а на практике получается гораздо больше?

Потому что маппер еще есть, и он много чего умеет.

[Koluchiy]

Это получается не от фанаута, а от неоптимального размещения, когда соединяемые модули оказываются физически далеко друг от друга.

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

Потому что маппер еще есть, и он много чего умеет.

Можно как-то ограничить его стремление к повышению фанаута? Чего включить/выключить надо.

[DmitryR]

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

Это для ASIC. Для FPGA считайте грубо, что задержка сильно коррелирует с длиной (почти линейно) линии и слабо коррелирует с фанаутом (растет линейно при экспоненциальном росте фанаута).

Можно как-то ограничить его стремление к повышению фанаута? Чего включить/выключить надо.

Не заморачивайтесь, только время потеряете.

[dmitry-tomsk]

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


Можно как-то ограничить его стремление к повышению фанаута? Чего включить/выключить надо.

p&r в ise настолько тупой, что самое тривиальное размещение модулей по кристаллу в planahead даёт отличные результаты по частоте и времени имплементации.

[Shtirlits]

От разработчиков placer-ов почему-то годами скрывают существование регулярных структур и требуют размещения по принципу минимального расхода проволоки и близости к вымышленному пупу чипа.

[disel]

Хаппи энд случился?

[Мур]

Прокоментируйте, народ, такой парадокс.
Если я добился в Post-Route и самом медленном Speed grade-2 устойчивой работы проекта в Model Sim, но при смене Speed grade-3 (шустрее!) вижу как валится проект на ровном месте(не должно быть такого в моём понимании).
Казалось бы, стоило расслабиться! Я в лёгкой прострации...

[disel]

Схема поди не синхронная или констрейны заданы не верно (или не заданы). Других вариантов нет.
А зачем Post-Route в моделсим засовывать?

[Мур]

Схема поди не синхронная или констрейны заданы не верно (или не заданы). Других вариантов нет.

Схема синхронная под единую 100Мгц. Собственно, в констрейнах только это и было прописано...

А зачем Post-Route в моделсим засовывать?

Там же большее приближение к истинным задержкам! Глюки в нём как раз и просматриваются...

[disel]

Там же большее приближение к истинным задержкам! Глюки в нём как раз и просматриваются...

А зачем вам истинные задержки? Именно вам? Пускай временной анализатор этим мучается.

Вообще в данной теме это офтоп и нехорошо. Создайте новую тему, если нужно.

[Koluchiy]

Хаппи энд случился?

Почти, но не совсем.
Т.е. при заполнении 44% всё вполне себе.
Но при заполнении микросхемы 86% при выполнении MAP в компьютере заканчивается память .

Сообщение отредактировал Koluchiy - Jan 19 2011, 08:00

[disel]

Почти, но не совсем.
Т.е. при заполнении 44% всё вполне себе.
Но при заполнении микросхемы 86% при выполнении MAP в компьютере заканчивается память .

Ну вы поделитесь как победили.

Странно по поводу памяти. В спартане6 вроде ничего страшного нет: http://www.xilinx.com/ise/products/memory.htm.

[Мур]

А зачем вам истинные задержки? Именно вам? Пускай временной анализатор этим мучается.

Поведенчески проект совершенен(ModelSim)
До заливки в железо провериться всегда полезно с приближенными к реальности задержками...

Вообще в данной теме это офтоп и нехорошо. Создайте новую тему, если нужно.

Извините! Тема спала...
Я посчитал, что времянки здесь тоже цепляют такой вариант.
...Я просто воспользовался поиском и не стал новый топик из такого пустяка создавать.
Как решат модераторы?

[Koluchiy]

Ну, во-1х, пока не победил, ибо 86% пока откомпилить не удалось.

А в остальном - собственно, все рецепты здесь перечислили.
1) Включение всех оптимизаций по скорости (в Synplify - тоже).
2) Ручная расстановка отдельных блоков. Я расставлял блоки памятей, причем делал это в общем "по наитию", но эффект это дало очень заметный.
3) Развязка отдельных блоков между собой при помощи промежуточных триггеров (можно это назвать конвейеризацией). Т.е. если нет разницы, через сколько тактов придет такой-то сигнал из блока А в блок Б, то между А и Б ставятся триггера, которые делят путь на участки.

Странно по поводу памяти. В спартане6 вроде ничего страшного нет

Ну вот там вот написано, что для S6 150LXT в пике 2300 МБайт.
А у меня их 2 гига...
Собственно, память закончилась тогда, когда я на 86% заполнения включил Global Optimization.

[disel]

Т.е. ручная расстановка + переделка схемы. Понятно.
По пункту 3 можно было в таком случае и мультицикловыми констрейнами обойтись.

На расстановку еще влияет cost table. Можно запустить на ночь смарт эхплорер, пускай перебирает пока не найдет подходящий вариант. А потом фиксить.

[DmitryR]

Global optimiztion в моей практике может помочь дотянуть чуть-чуть, но не может помочь кардинально, а ресурсов (в основном времени) жрет много. Поэтому я бы его не включал. Если у вас компилируется без него - расскажите, что получается.

А памяти не жалейте, она же дешевая. Если написано пик 2300 - значит надо иметь минимум 4 гига: эти пики оказываются, как сами видите, вполне достижимыми. Да, придется поставить шестидесятичетырехразрадную операционку, но двенадцатый ISE в ней уже вроде полностью живет.

[Koluchiy]

По пункту 3 можно было в таком случае и мультицикловыми констрейнами обойтись.

Насколько я понимаю суть мультицикловых констрейнов, нельзя.

Поскольку данные передаются каждый такт, и поэтому должны фиксироваться в триггере перед следующим тактом.
Но могут приходить с задержкой на несколько тактов, поэтому промежуточные триггеры решают задачу.

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

Как-то так...

Global optimiztion в моей практике может помочь дотянуть чуть-чуть, но не может помочь кардинально, а ресурсов (в основном времени) жрет много. Поэтому я бы его не включал.

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

Собственно, сейчас, поскольку конфигурация-минимум откомпилировалась, эта задача отошла на задний план.

А памяти не жалейте, она же дешевая...Да, придется поставить шестидесятичетырехразрадную операционку

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

[disel]

Ну тогда да.

[jojo]

Рецепт для 95-100% слайсов и максимальных частот.
Действуя так, можно добиться впечатляющих 110-120 % использования LUT с учётом комбинирования LUT2 и LUT3 в LUT6:

Этап 1. Подготовка IP
Ограничить пути распространения ~2...4 LUT или ~32 бита при суммировании с переносом.
Экспортировать крупные или многочисленные блоки IP в Planahead (сделав для них отдельный проект).

Этап 2. Сборка основного проекта
Привязать вручную импортированные крупные блоки констрейнами.
Для всей остальной логики основного проекта назначить области в Planahead.

На всех этапах, по необходимости:
Перебрать таблицы Cost в поисках "счастливого номера" при сбалансированной стратегии.
Увеличить усилия и включить продвинутые галки Mapper-у.
Вручную переставить несколько совсем неудачно расположенных LUT.


Все эти действия имеют свою трудоёмкость и последствия, поэтому выжимать максимум из Xilinx - занятие не из приятных.

[Koluchiy]

Граждане, кто-нибудь пробовал компилировать проекты для больших Spartan-6 (LX100, LX150) при заполнении 80% и больше?
Если да, насколько успешно и сколько времени занимает Place & Route.

Чего-то у меня оно затыкается на Route.Phase 4... Думает-думает-думает, и не может придумать, как это всё дело развести.
Заполнение по LUT'ам 78%, по триггерам чуть меньше, по блокам памяти порядка половины.
Временные ограничения отключил, но это не очень помогло.

[Kuzmi4]

2 Koluchiy
из тяжеловесных имею XC3S1600E: на AMD Phenom II 945 собирает минут 10 (Синтез Synplify Pro). Сильно зависит от того как написан код. Исходный код писали какие то индусы (за воду наверное) и синтез в XST - ситезирует 4 часа. После моих апдейтов (апдейтил и редизайнил правда ОЧЕНЬ долго) и синтеза в Synplify Pro имею 10 минут.. Так что тут неоднозначность - всё зависит от того как написать архитектуру и где синтезировать.

Так а что именно пишет роутер ?

[Koluchiy]

Spartan-3 мне не очень интересно, у меня есть проект под XC3S5000 :-))) с заполнением те же 80.
Интересно про Spartan-6...

Так а что именно пишет роутер ?

А ничего не пишет. Несколько часов считает молча, периодически выдавая строки типа
Intermediate status: 9421 unrouted; REAL time: 2 hrs 15 mins 7 secs,
причем цифра неразведенных колеблется вокруг 9000.
Неужели закончились цепи межсоединений?

[Kuzmi4]

2 Koluchiy
ну тут выше 45ки дело не имел
правда заполнение 99%, но выше приведённых сообщений не получал...

[DmitryR]

Неужели закончились цепи межсоединений?

Это вряд ли. Вообще LX150 - кристалл большой, если у вас процессор не очень мощный - может уйти несколько часов легко. А если не хватает ОЗУ (используется своп) - то может и на сутки растянуться, думаю. Особенно если Global Optimization включено. Посмотрите соотношение имеющейся и используемой памяти, напишите что за процессор. Поиграйтесь опциями ISE.

[disel]

У меня правда не спартан, а виртекс6. Но в целом проблема была такая же. 75% по лютам и 250 мгц тактовой. И та же хрень. Помог запуск смартэксплорера с опцией Use built-in SmartXplorer strategies for Congestion Reduction. все развелось, а до этого процессор сутки колбасился и никак не мог развести. Советую почитать wp381, там правда про виртекс, но думаю это не принципиально.

[Koluchiy]

2 Kuzmi4

2 Koluchiy
ну тут выше 45ки дело не имел
правда заполнение 99%, но выше приведённых сообщений не получал...

Если не секрет, какие частоты?

[Kuzmi4]

2 Koluchiy
не секрет там несколько частот: внешнаяя на 2.048МГц/1.554МГц, внешнаяя на 75МГц. И внутренняя, системная, на 200МГц.

[Victor®]

2 Koluchiy
не секрет там несколько частот: внешнаяя на 2.048МГц/1.554МГц, внешнаяя на 75МГц. И внутренняя, системная, на 200МГц.

Хм... TDMoIP? Рискну предположить :-)

[Kuzmi4]

2 Victor®
возле того