[Cosworth 0]

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

[Golikov 0]

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

 

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

[des00 25]

все зависит от фиттера.....Есть ли смысл разводить врукопашную?

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

 

[DuHast 0]

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

 

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

Ну и что касается фиттера, то ему можно помочь меня его настройки и "лоча" конкретные блоки в конкретных регионах ПЛИС.

 

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

[ASN 0]

Cosworth

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

 

[DuHast 0]

Cosworth

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

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

[Cosworth 0]

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

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

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

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

 

[johan 0]

а вот писать оптимальный код под целевую архитектуру можно и нужно.

Не поделитесь примеров оптимизации под целевую архитектуру?

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

 

 

Ну собственно под "врукопашную" я имел ввиду активное использование LogicLock (что вообще мне всегда казалось не правильным).

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

 

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

Может Вам и одного регистра хватит?

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

Изменено 18 сентября, 2014 пользователем johan

[Maverick_ 15]

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

 

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

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

[Des333 0]

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

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

[FatRobot 0]

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

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

 

Какая бы целевая технология ни была, я бы рекомендовал стнадартные шаги для синтеза и p&r:

1. описать design constraints. Это подскажет fitter'у, какие блоки необходимо размещать рядом, а какие можно разнести.

2. сохранить иерархию до какого-то уровня вниз, а не разгруппировывать дизайн полностью. Это позволит хотя бы вчерне сделать floorplanning для крупных блоков. Естественно, чтобы это было эффективно, нужно выполнить некоторые простые требования для rtl (выходные сигналы по возможности регистровые, отсутсвие cdc внутри блоков и т.п. ), а также пункт 1.

 

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

 

[des00 25]

Ну собственно под "врукопашную" я имел ввиду активное использование LogicLock (что вообще мне всегда казалось не правильным).

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

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

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

 

Вот мне тогда не совсем понятно, что значит оптимальный код?

 

Не поделитесь примеров оптимизации под целевую архитектуру?

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

Оптимальное описание должно учитывать архитектурные возможности целевой ПЛИС. Например :

Под альтеру :

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). Но это уже редкость.

[Cosworth 0]

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

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

[Bad0512 2]

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

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

[FatRobot 0]

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

 

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

 

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

 

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

 

 

 

А насчет констрейнов - выходит их правильнее задавать еще ДО RTL описания? А, вот еще, имеет ли смысл играться с количеством фан-аутов логики, или квартус при синтезе сам может дублировать сильно загруженные ячейки для уменьшения задержек?