Подскажите, как бороть времянки в 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

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

ну вот эти можно пробывать:
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 всегда, в любых относительно сложных проектах: это заодно еще может сильно уменьшить время работы маппера.