Доброго дня. Вот смотрю на отчеты TimeQuest и вижу, задержка на IC - 2.5нс, а задержка на Cell - 0.8 (это при 4х слоях логики). Выходит что межсоединения вносят бОльшую задержку чем LUT? В таком случае выходит бессмысленно задумываться о критических путях на этапе RTL описания, один фиг все зависит от фиттера. В связи с этим еще вопрос, по вашему опыту - на сколько вообще оптимально разбрасывает квартусовский фиттер? Есть ли смысл разводить врукопашную?

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

ИМХО руками уже делать ничего не надо, прошлый век...

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

Один "слой логики" - это Cell+IC, поэтому из полученного Вами результата надо делать другой вывод - чем меньше "слоев логики", тем быстрее схема. А о количестве "слоёв" задумываются, как раз, на этапе RTL описания.
Ну и что касается фиттера, то ему можно помочь меня его настройки и "лоча" конкретные блоки в конкретных регионах ПЛИС.

PS Думаю, что в Вашем эксперименте LogicLock. уменьшит задержку на IC.

Cosworth
Задумываться о критических путях лучше уже на RTL уровне. В данном случае, может конвейеризация поможет?

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

Ну собственно под "врукопашную" я имел ввиду активное использование LogicLock (что вообще мне всегда казалось не правильным). Вот мне тогда не совсем понятно, что значит оптимальный код? Мне задана частота, максимальная латентность, в ресурсах я не ограничен (ну гипотетически). Обычно я делаю так - зная структуру ячейки прикидываю количество слоев. Затем зная (ну хотя бы прикидочно для худшего случая) задержку ячеек, tsu, th регистров оцениваю сколько слоев можно использовать чтобы "вписаться" в частоту и соответственно расставляю регистры. А выходит что один фиг, захочет фиттер расположить логику по разным углам, и ничего не остается как самому влезать в разводку.

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

Не поделитесь примеров оптимизации под целевую архитектуру?
Мне казалось, либо ты пишешь оптимально (по частотке или по ресурсам - что тебе важнее), либо нет. Либо под оптимизацией под архитектуру Вы понимаете, что-то относительно низкоуровневое, а ля 6-входовый LUT у Stratix'a, а у Cyclone он 4-х входый? Либо что-то более высокоуровневое?



Если фиттер пути внутри одного модуля (либо одного какого-то логического блока) распихивает по разным углам, то скорее всего LogicLock вам может помочь. Выделяете квадратик где хотите хоть расположить этот блок - и он его туда упихает. Однако другие куски могут стать хуже.


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

Тогда может стоит подумать над изменением алгоритма работы?

А какая у Вас частота и какие ограничение по задержкам, если не секрет?

Да, в целом задержка в межсоединениях в фпга больше, чем задержка в логике. В asic ситуация в целом противоположная.
Из собственного опыта: для прототипирования "один-в-один" кристалла, сделанного по "дедовской" технологии 180 нм с предельными временными ограничениями, пришлось брать kintex-7 и пыхтеть с ucf и ручным размещением. Заполнение fpga - 25-30%

Какая бы целевая технология ни была, я бы рекомендовал стнадартные шаги для синтеза и p&r:
1. описать design constraints. Это подскажет fitter'у, какие блоки необходимо размещать рядом, а какие можно разнести.
2. сохранить иерархию до какого-то уровня вниз, а не разгруппировывать дизайн полностью. Это позволит хотя бы вчерне сделать floorplanning для крупных блоков. Естественно, чтобы это было эффективно, нужно выполнить некоторые простые требования для rtl (выходные сигналы по возможности регистровые, отсутсвие cdc внутри блоков и т.п. ), а также пункт 1.

Это уже совсем экстремальный случай, за 16 лет работы с ПЛИС мне не разу это не потребовалось, все решалось более простыми методами.

Если вы прописали все временные ограничения вашего проекта и софт их принял, то синтезатор сделает поправки на синтез (если есть опция Timing-Driven Synthesis), маппер и роутер обязательно их учтут и будут искать решение задачи. В среднем, в современных плис соотношение задержек логики и разводки в плотных проектах от 50/50 до 20/80.




Оптимальное описание должно учитывать архитектурные возможности целевой ПЛИС. Например :
Под альтеру :
1. приоритет сигналов установки и сброса триггеров и разрешения тактовой
2. Приоритет сигналов синхронной загрузки триггеров (у альтер этот мультиплексор стоит за лютом)
3. Какие именно сигналы LE идут на арифметические блоки
4. Размерность LUT
Под xilinx :
1. Количество и возможности реализации сигналов управления триггером
2. Размерность и количество выходов LUT из связь с выходным триггером(ами), возможности использования их ресурсов LUT (RAMS/RAMD, SRL, LUT, dual LUT)
3. Возможности использования MUXF7, MUXF8 (у них они стоят после LUT)
4. Возможности использования MUCXY, XORCY (тоже стоят после LUT)

Под Lattice и Actel : не в курсе, не работал, это лучше узнать у SM и yes

Во всех семействах нужно учитывать структуру CLB/LB т.к. внутри нее связи быстрее чем со внешним миром, размер CLB/LB (например у сыклонов 1 он был не 16, а 10 бит) и т.д.

На моих проектах, сокращение занимаемых ресурсов достигало ~2 раза, рост времянки в ~1,5 раза. Все это на уровне поведенческого описания. Хотя в некоторых, особо тяжелых случаях, приходилось руками вставлять примитивы и собирать CLB/LB примитивами (макросы рулят и за их отсутствие мне очень не нравиться VHDL). Но это уже редкость.

Да там и алгоритма то нету. Задача - предобработка видео, по которому в дальнейшем замыкают некий контур. Задержка в 1 кадр - уже не катит. Впринципе 30 fps - достаточно медленно, но со всеми преобразованиями выходит длинный конвейер. На самом деле по времянке вписываюсь пока, просто хочу иметь побольше запаса по критическим путям чтобы в случае чего можно было расширять проект (утилизация плис всего 50%). А насчет констрейнов - выходит их правильнее задавать еще ДО RTL описания? А, вот еще, имеет ли смысл играться с количеством фан-аутов логики, или квартус при синтезе сам может дублировать сильно загруженные ячейки для уменьшения задержек?

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

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

по второму вопросу: с max_fanout не надо активно играть, но этот параметр при синтезе принято ограничивать. Также, насколько я помню, в fpga-синтезаторах широко используется опция дублирования регистров как раз по причине больших задержек в трассировке. Это может дать значительный выигрыш во временных ограничениях при размещении и рассировке полностью разгруппированного дизайна.

Еще раз повторю: успех для сложного и меняющегося проекта там, где вы в большей степени контролируете синтез, размещение и разводку. Говорить о чем-то серьезном в базисе: открыл gui - нажал run - подвинул ползунок "speed/area" - еще рез нажал run - и т.д., я бы не стал.

Хотя тут рассказывают про действительно интересные методики разработки: много sv для синтезируемого rtl, автоматическая генерация синтезируемого rtl из чего-то более высокоуровневого, взять fpga побольше/побыстрее.

Спасибо!
Пункты 1 и 2 знал и использовал, пункт 4 знал, но никогда под размер LUT'a не оптимизировал, вроде.
Третий пункт не очень понял. Не могли бы Вы прояснить?

Я-бы так сказал:
В техгологиях меньше 0.35мкм, задержки в межсоединениях (хоть ASIC хоть FPGA) становяться больше чем в гейтах.
Оптимизировать RTL таки надо, ибо чем сложнее комбинаторика, тем и соединений больше.

Проверьте, пожалуйста, корректность моих расчетов:

1. Открываю "TSMC 90nm CLN90G Process SAGE-XTM v3.0 Standard Cell Library Databook"
2. Нахожу NAND2X4
3. Delays at 25C, 1.0V, Typical Process, Intrinsic Delay (ns). Беру среднее для 4х: 0.0135ns
4. 3.0e+8 м/с * (0.0135 * 1.0e-9) с = 0.004 м. 4 мм. Это огромная эквивалентная длина проводника, на мой взгляд.

Даже пусть половина этого - в счет емкости проводника и нагрузки, а вторая половина - эквивалентная длина. 2 мм. все равно очень много.

Чем сложнее комбинаторика, тем больше слоев логики для asic. И тем больше соединений для FPGA. Оптимизировать надо в любом случае.

3.0e+8 м/с * - это типа скорость света?
А если учесть что сигнал не по вакуму а по распределённой RC линии задержки бежит?
Да и задержка гейта это при какой RC нагрузки?

Внутри Lattice [почти]== Xilinx, ну очень близко. Так что практически все, что касается упаковки в xilinx, применимо и к латису.


Основные задержки в ASIC - не длина проводов, даже учитывая их емкость, а сама емкость затворов входных каскадов ячеек и соответствующая им "жирность" выходных буферов. А так как это все учтено именно в моделях ячеек, а не разводки - поэтому так оно и получается, что почти вся задержка на ячейках.
wireload модели, кстати, тоже в результате дают значение эквивалентной RC-цепочки, которая, собственно, и задерживает сигнал в проводе. Потом уже экстракция паразитов их же генерирует, уже точные. Так что длиной провода просто пренебрегается.

UPD:
вот кусочек из wireload модели от 0.35:

wire_load("8000") {
capacitance : 0.000123 ;
resistance : 0.078E-3;
area : 0.01;
slope : 189.0 ;
fanout_length(1,28.84);
fanout_length(2,57.4);

так что для fanout=2 получится R=57.4*0.078E-3 кОм и C=57.4*0.000123 пФ - вот такая средняя по больнице задержка в разводке для разветвления на две нагрузки, если разводимый блок укладывается в area <= 8000 um^2

Простой пример : в атаче LE третьего сыклона в арифметическом режиме. Видно что использовать register feedback невозможно, т.е. банальный счетчик будет задействовать разводку общего назначения. Вот такие мелочи можно учитывать для оптимальной разводки.

Если кому интересно....
---------------------------------------------------------------

Для 035

wire_load_table ("0_5k_4m") {
fanout_capacitance (5, 0.0130) ;
fanout_resistance (5, 0.0299) ;
fanout_area (5, 11.07) ;
fanout_length (5, 124.17) ;

Берём фаноут гейта 5 (типично) .
Имеем для вайров С=0.0130pf \ R=0.0299кОм

Ёмкость входов нагрузки для 5 гейтов:
cell (BULHDX2) {
pin (A) {
direction : input;
capacitance : 0.0040;

С=5*0.0040=0.02pf

Общая ёмкость линии Сw=0.0130pf+0.02pf=0.033pf

Таким образом, задержка в межсоединениях:
Тw=3*RCw=3*0.033pf*0.0299кОм=0.0029нс

Задержка в межсоединениях 035 определяется её собственной ёмкостью и резистивным сопротивлением, а также ёмкостю входов гейтов нагрузки.


Смотрим задержеку гейта при input_net_transition=1.2:

lu_table_template (BU1_timing_2D) {
variable_1 : input_net_transition;
variable_2 : total_output_net_capacitance;
index_1("0.06 0.6 1.2 2.4 4.8");
index_2("0.0020 0.0349 0.0698 0.1396 0.2791");
}
cell_rise (BU1_timing_2D) {
values("0.1690, 0.4209, 0.6805, 1.1994, 2.2363",\
"0.2290, 0.4812, 0.7404, 1.2591, 2.2959",\
"0.2503, 0.5040, 0.7633, 1.2812, 2.3176",\
"0.2490, 0.5125, 0.7731, 1.2909, 2.3263",\
"0.1817, 0.4632, 0.7327, 1.2618, 2.2988");
}

Тbuf1 (при Сw=0.033pf) = 0.5040нс
-
В 035 мы имеем соотношения задержек в межсоединении к задержке в гейте 0.0029нс\0.5040нс или 1\173.
Вся задержка сосредоточена в гейте.

При этом, ёмкость типичного межсоединения (фаноут 5) в данной технологии увеличивает задержку гейта с 0.2503 до 0.5040 т.е в 2 раза (см. 3-ю строку BU1_timing_2D)!

---------------------------------------------------------------

для 018

wire_load_table (5k) {
fanout_area (5, 2.65);
fanout_capacitance (5, 0.0018);
fanout_length (5, 99.97);
fanout_resistance (5, 0.041);

Имеем для вайров С=0.0018pf \ R=0.041кОм

Ёмкость входов нагрузки для 5 гейтов:
cell (BU1) {
pin (A) {
direction : input;
capacitance : 0.003201;

С=5*0.003201=0.016pf

Общая ёмкость линии Сw=0.0018pf+0.016pf=0.0178pf

Таким образом, задержка в межсоединениях:
Тw=3*RCw=3*0.0178pf*0.041кОм=0.0022нс

Задержка в линии 018 технологии определяется только ёмкостью входов гейтов нагрузки и её резистивным сопротивлением.


lu_table_template (TIMING_TEMP_1_2D) {
variable_1 : input_net_transition;
variable_2 : total_output_net_capacitance;
index_1 ("0.0108, 0.1284, 0.2454, 0.480, 0.9492, 1.8876, 3.7644");
index_2 ("0.00100, 0.0186, 0.0312, 0.0519, 0.0864, 0.144, 0.240");
}

cell_rise (TIMING_TEMP_1_2D) {
values ("0.078796, 0.139521, 0.180945, 0.248608, 0.361001, 0.548422, 0.860681", \
"0.111564, 0.172588, 0.214054, 0.281758, 0.394213, 0.581647, 0.893816", \
"0.130034, 0.191773, 0.233171, 0.300882, 0.413318, 0.600755, 0.912829", \
"0.149527, 0.214052, 0.25529, 0.322875, 0.435329, 0.62261, 0.934493", \
"0.162109, 0.232954, 0.274269, 0.341518, 0.453854, 0.641113, 0.953011", \
"0.151271, 0.234228, 0.27716, 0.344678, 0.456789, 0.643955, 0.955758", \
"0.080574, 0.181599, 0.230327, 0.300692, 0.414288, 0.603211, 0.916342");
}

Тbuf1 (при Сw=0.0178pf) = 0.214052нс
-
В 018 мы имеем 0.0022нс\0.214052нс или 1\97

Ёмкость типичного межсоединения (фаноут 5) в данной технологии увеличивает задержку гейта с 0.149527 до 0.214052 т.е в 1.5 раза (см. 4-ю строку TIMING_TEMP_1_2D)!

-----------------
1) Задержка сигнала на линиях межсоединений определяется входной ёмкостью гейтов нагрузки и резистивным сопротивлением самой линии.
2) Ёмкость типичной нагрузки (5 входов) увеличивает задержку на выходе гейта примерно в 2 раза
3) С уменьшением технологических норм, задержка линии приближается к задержке гейта (035 - 1\173, а в 018 - 1\97, т.е. в почти в 2 раза)
Можно предположить, что при норме в 40нм это соотношение будет примерно 1\20, т.е. уже не пренебрежимо мало (мож у кого есть дезайн кит на 40нм или ниже?)....

Для 035 и 018 можно сказать что задержка в межсоединениях пренебрежимо мала и что входная ёмкость нагрузки вносит наибольший вклад в задержку выхода самого гейта.
При этом, чем меньше технологические нормы, тем ближе величины задержки в межсоединениях (R линии + Cвходов) к выходным задержкам гейтов-драйверов.