[Koluchiy 0]

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

 

Собираю проект под 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.

 

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

 

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

Изменено 22 декабря, 2010 пользователем Koluchiy

[Shtirlits 0]

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 0]

ИМХО. Судя по всему, слоев логики очень много, перекос в сторону route большой. Игрой с настройками синтезатора\маппера\парсера ничего, кроме потери времени и изучения этих самых настроек, не достигните. Схему надо менять. Конвеер, мультицикловые констрейны и т.д.

С увеличением загрузки кристалла ситуация будет только ухудшаться.

Полезный документ wp381 (правда он про виртекс). Был какой то еще документ полезный про хай-перфоманс, завтра на работе найду.

А сколько не влезает то? В процентах. В ксалинксовых апноутах пишется, что настройками синтеза\маппера можно играть если процентов 10 не хватает. Если больше, то схему нужно корректировать.

[Shtirlits 0]

Случаи бывают разные. Плохим размещением можно и с 200 MHz до 20 MHz уронить.

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

Переделывать схему конечно прекрасно, но как бы не попасть на последующую отладку и верификацию. Кто гарантирует, что переделанная схема будет такая же по функциональности?

Я за подробное изучение проблем в схеме и последующие подсказки placer-у без переделки самой схемы.

 

[Leka 0]

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

[RobFPGA 27]

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

 

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

затем попытка уменьшит длину связей заданием ограничений на размещение

как говорил товарищ Shtirlits -AreaGroup, фиксация блоков памяти, и.т.д.

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

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

Соответственно если их не поставить в "игнор" то PR всеми своими немощными попытками будет пытается их реализовать теряя при этом в действительно нужных местах. Ну и естественно если по дизайну цепь необходимо размазать по всему кристаллу - тут только изменение логики может помочь.

 

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

 

Удачи! Rob.

 

[Koluchiy 0]

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

Включено.

 

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

Включено.

 

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

На этом проекте (да и вообще на моих проектах) Синплифай дает ощутимый выигрыш.

Кроме того, в XST скорее всего надо будет менять текст, т.к. он не всё поддерживает, чего написано.

 

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

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

 

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

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

Проблема во времянках.

Если судить по отчетам P&R, проблемных цепей всего ничего - для разных настроек от 15 до 100.

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

 

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

А он ощутимо медленнее...

[disel 0]

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

Проблема во времянках.

 

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

[Koluchiy 0]

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

 

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

Изменено 23 декабря, 2010 пользователем Koluchiy

[disel 0]

wp331. Он правда достаточно древний, и не все применимо, но больших изменений нет.

Регистры сами размножаться могут - включить Register Duplication.

Ключевое слово для поиска - Timing Closure.

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

 

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

 

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

 

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

 

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

[Koluchiy 0]

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

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

Поэтому хочется откомпилить "as is".

Да и вообще интересно выжать из ПО максимум, чего оно может дать.

 

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

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

 

3/12,5 = 24 %.

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

Изменено 23 декабря, 2010 пользователем Koluchiy

[disel 0]

ну вот эти можно пробывать:

Perform Timing-Driven Packing and Placemen

Map Effort Level - в хай

Extra Effort - в хай

Trim Unconnected Signals - включить

Optimization Strategy - Speed

LUT Combining отключить

 

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

 

Может поможет.

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

 

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

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

 

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

[DmitryR 0]

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

[Koluchiy 0]

Оно, конечно, мало(хотя есть цепи с fanout за 80).

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

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

[DmitryR 0]

Оно, конечно, мало(хотя есть цепи с fanout за 80).

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

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

 

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

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