[v_mirgorodsky 0]

Вот на счет упаковки я с Вами не соглашусь. Упаковка ВСЕГДА понижает частоту. Происходит это в следствие того, что магистральные (скоростные) связи между ячейками заменяются на локальные с несколько худшими характеристиками. Это не мое мнение и не мое заключение. Информация была получена от кого-то из Xilinx несколько месяцев назад на гуглях в comp.arch.fpga. Этим, к стати, объясняется более низкая частота плотно упакованных кристаллов.

[makc 201]

Вот на счет упаковки я с Вами не соглашусь. Упаковка ВСЕГДА понижает частоту. Происходит это в следствие того, что магистральные (скоростные) связи между ячейками заменяются на локальные с несколько худшими характеристиками. Это не мое мнение и не мое заключение. Информация была получена от кого-то из Xilinx несколько месяцев назад на гуглях в comp.arch.fpga. Этим, к стати, объясняется более низкая частота плотно упакованных кристаллов.

<{POST_SNAPBACK}>

 

Какой локальности Вы имеете в виду связи? Связи внутри Slice'a или связи внутри одного CLB?

 

Мне все-таки кажется, что все зависит от того, какая упаковка. Если рассматривать упаковку, при которой в один Slice упаковывается две логические ячеки (ЛЯ) и два триггера, при этом выходы соответствующей ЛЯ являются входами для рядом стоящего триггера, то в этом случае, как мне кажется, перенос триггеров в другой Slice отицательно скажется на быстродействии, поскольку линии связи внутри слайса быстрее, чем внешние линии. Это показывает опыт, который совсем не сложно повторить. А если говорить про плотно упакованные проекты, то тут причиной их низкого быстродействия может являться элементарная нехватка трассировочных ресурсов, когда задержки в трассах превалируют над задержками в логических элементах (я такое наблюдал). Но как раз подобную ситуацию может помочь решить ручное размещение, обеспечивающее такую упаковку, которая позволит съэкономить трассировочные ресурсы кристалла.

 

PS: А ссылочку на то, где Вы прочитали про соотношение скоростей связей Вы можете подсказать?

[v_mirgorodsky 0]

Со ссылочкой сложно :( Этот thread попался мне на глаза в то время, когда мы только начинали заниматься Xilinx, посему ссылочка не сохранилась, однако факт небольшого уменьшения рабочей частоты при упаковке отложился у меня в голове однозначно.

 

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

[makc 201]

Со ссылочкой сложно :( Этот thread попался мне на глаза в то время, когда мы только начинали заниматься Xilinx, посему ссылочка не сохранилась, однако факт небольшого уменьшения рабочей частоты при упаковке отложился у меня в голове однозначно.

<{POST_SNAPBACK}>

 

Досадно...

 

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

 

Все правильно. :) Можно еще добавить, что у того же Xilinx'a, например, в Spartan-2 есть специальные линии, позволяющие быстро связать LUT:

Internal CLB feedback paths that provide high-speed

connections to LUTs within the same CLB, chaining them together with minimal routing delay

Т.е. это помогает увеличить эффективную упаковку при реализации функций многих переменных. Против упаковки говорит наличие быстрых связей между CLB в строке, позволяющих обойтись без использования более медленных глобальных трассировочных ресурсов (GRM). А PAR занимается тем, что ищет золотую середину между всем этим. :) И иногда находит. ;)

[ilya79 0]

Может это именно та ссылка о которой упоминалось:

 

http://www.fpga-faq.org/archives/63825.html

Article: 63833

 

 

Yeah ideally you'd like to solve your problem by setting up constraints to

guide the tools, because your floorplanning work is more likely to be wasted

if your design changes significantly enough (though creating relative

placement macros for sub blocks of your design can help preserve your work).

Area constraints, as opposed to timing constraints, can be helpful in

nudging the tools to placing smarter.

 

Of course, like you said, the tools might not have enough smarts to do what

you want or it might take too long to place/route without some intervention.

 

As far as floorplanning, the main thing is is to understand the layout of

the routing resources in your target FPGA. Xilinx's Spartan-III, for

example, has direct lines (that connect adjacent CLBs), double lines (that

connect every other), hex lines (which don't connect every 6 but every 3),

and long lines (which do connect every 6). So from best to least, you want

logic in: 1) the same CLB, 2) adjecent CLB, 3) two CLBs away, 4) three CLBs

away, or 5) six CLBs away.

 

>>>Four and five CLBs away could be worse than six.>>>

 

A lot of times I find that when I floorplan I'm fixing some crazy things the

tools have done. Like for some reason the tools will take a 32-bit register

and instead of keeping it in order, it'll mix it up in a seemingly random

fashion.

 

They seemed to have architected their FPGAs for data to flow horizontally,

so keep that in mind. I'm not sure if it matters, but I always go

left-to-right because it feels natural.

 

Heh sorry I don't have too many pointers. I try not to floorplan (unless I

want to veg out. I find Xilinx's Floorplanner relaxing, it uses pretty

colors) and it feels more like an intuitive art than a science. One thing

you can try is to compile your design with only the difficult logic and the

other logic removed. This will help speed up the floorplan-route-results

cycle which sometimes can be more productive than trying to plan everything

up front, especially when we don't have a good knowledge of the routing or

we have the wrong ideas.

 

Best of luck,

Vinh

[makc 201]

Может это именно та ссылка о которой упоминалось:

 

http://www.fpga-faq.org/archives/63825.html

Article: 63833

 

 

Yeah ideally you'd like to solve your problem by setting up constraints to

 

[skipped]

 

Best of luck,

Vinh

<{POST_SNAPBACK}>

 

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

[ilya79 0]

v_mirgorodsky>>Происходит это в следствие того, что магистральные (скоростные) связи между ячейками заменяются на локальные с несколько худшими характеристиками.

 

>>>Four and five CLBs away could be worse than six.>>>

 

Упоминалась именно эта ситуация.

Хотя я не настаиваю :) Мне просто не очень нравиться утверждение "Упаковка ВСЕГДА понижает частоту". Боюсь что v_mirgorodsky

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

[makc 201]

v_mirgorodsky>>Происходит это в следствие того, что магистральные (скоростные) связи между ячейками заменяются на локальные с несколько худшими характеристиками.

 

>>>Four and five CLBs away could be worse than six.>>>

 

Упоминалась именно эта ситуация.

Хотя я не настаиваю :)  Мне просто не  очень нравиться утверждение "Упаковка ВСЕГДА понижает частоту".  Боюсь что v_mirgorodsky

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

<{POST_SNAPBACK}>

 

С этим согласен. :)

Кстати, а может быть Вам попадалась статья или обзор, в котором бы рассматривались вопросы эффективности(по скорости и размеру) реализации различных типовых узлов на ПЛИС с различной архитектурой (основных производителей вроде Actel, Altera и Xilinx)?

[druzhin 4]

Почаму после Синплифи проект занимает больше места, чем после ИСЕ-синтезёра:

 

1. У всех синтезёров на белом свете при настройках "speed" жрётся больше "array", чем при настройках "array". Это типа закон природы, сообщающиеся сосуды, длинный и тонкий - короткий и толстый, итд.

2. В ИСЕ по умолчанию опции синтеза (и всего остального тоже) выставлены на экономию ресурсов.

3. При скоростных настройках сравниваемых синтезёров Синплифи даёт всегда лучший результат по времянке и почти всегда по обьёму.

4. Если у Синплифи до хрена накрутить "Frequency" или врубить "Auto constrain", то вместе со скоростью нехило растёт "array".

 

И вообче: По моему опыту Синплифи по сравнению с ИСЕ офигительно оптимизирует перекос фаз - глюкавый и хреновый проект с кучей неглобальных счётчиков и триггеров, готорый глючил после ИСЕ, нормально работал, будучи просинтезированным в Синплифи. (Проект делал не я).

[3.14 0]

2 v_mirgorodsky

Есть такая просьба. Можете ли Вы кинуть в качестве примера какой нибудь свой нетривиальный исходник с прикрученными к нему констрейнами?

Сейчас не смогу, а чем ранее приводимые не устраивают? Там я старался подробно расписать что и почему. Недавно появились еще соображения на эту тему, надо будет "прожевать".

 

Теперь по поводу размещения.

Есть такой констрейн RLOC (как то с makc-ом обсуждали методы создания) на основе которого стоят RPM макросы, которые заставляют логику ложится относительно друг друга по определенному правилу. Так вот, Synplify, как правило, отыскивает в вашем проекте примитивы (счетчики, мультиплексоры и т.п.) и прикручивает к ним RPM макрос (кстати, эти макросы во floorplanner подсвечиваются), который соответьсвенно и может приводить к "расползанию" проекта. Другой причины вызывающей "расползание" мне не известно.

По поводу площадь/быстродействие, у меня то же сложилось субъективное правлио - если слайс уже занят, забудь(защити от дальнейшего заполнения) про него, если не хочеш понижения производительности :(

[v_mirgorodsky 0]

Ну по поводу исходника - так тут все прото. Хотелось бы увидеть нечто не совсем тривиальное, с тройкой-четверкой слоев регистров и с ассинхронной логикой между ними.

 

Пользуясь предыдущим объяснением я попытался написать констраин для модуля. Он представлял собой два слоя регистров между которыми крутилась нетривиальная FSM. Периодически Synplify раскладывает эту схему на 172MHz при требуемых 166MHz, а остальное время говорит, что буду работать на 157MHz. Я накрапал UCF файл для ISE и странслировал его для Synplify утилиткой edf2srs. Короче говоря, ничего не получилось :( Кроме того, не вполне понятен принцип написания констрейнов. Т.к. во время своего опыта я просто замахался распределять все цепи по группам :( Мне почему-то кажется, что должно быть это как-то проще. На днях видел файл констраинов к Gigabit Ethernet MAC - так там всего пара строчек. Вот совсем и не понятно откуда они там взялись и как всего парой строчек зажали блок более 1000 слайсов размером :cranky:

[3.14 0]

2 v_mirgorodsky

 

Пример на следующей неделе постараюсь выложить (все таки причесать надо чтоб прочесть смогли ;) ), терпит?

 

 

<Пользуясь предыдущим объяснением я попытался написать констраин для модуля. Он представлял собой два слоя регистров между которыми крутилась нетривиальная FSM. >

Если так, то у вас три пути которые надо граничить:

1) PADS -> FFS

2) FFS -> FFS

3) FFS -> PADS

Я думаю, Вы их и ограничили наиболее подходящим способом.

 

<Периодически Synplify раскладывает эту схему на 172MHz при требуемых 166MHz, а остальное время говорит, что буду работать на 157MHz.>

Например, я вообще не смотрю, что мне синтезатор говорит. Смотрю только на RTL (чтоб синтезатор "нарисовал" нужную схему) и потом на количество слоев логики в отчете PAR ну и соответственно на получившиеся задержки.

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

Еще, мне кажется, Вы преувеличиваете роль синтезатора. Например, опишем синхронное устройство, у которого между регистрами получается два (макс.) слоя логики, пусть на слое логики "падает" по 2нс. Отсюда, знай синтезатор о том, что ему надо запустить эту схему на 400МГц, или нет, он все ровно ничего не изменит (в лучшую сторону) ...

 

<Я накрапал UCF файл для ISE и странслировал его для Synplify утилиткой edf2srs. Короче говоря, ничего не получилось>

А вчем был смысл такой манипуляции?

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

Можно рожать UCF чере Synplify, но у меня такой способ не прижился. Года полтора назад я пытался приучиться именно так "описывать" констрейны, но так и не смог получить "понятный"/"нужный" констрейн.

 

< Кроме того, не вполне понятен принцип написания констрейнов. >

Можно конкретней?

 

<На днях видел файл констраинов к Gigabit Ethernet MAC - так там всего пара строчек.>

Ну это они то же "загибают".

У него должно быть (если он синхронный):

1) FFS -> FFS(module)

2) FFS(module) -> FFS(module)

3) FFS(module) -> PADS

4) PADS -> FFS(module)

1 - отбрасывают, т.к. думают что тактовая одинаковая ;)

2 - PERIOD

3 - Объявление в группу, затем OFFSET OUT

3 - Объявление в группу, затем OFFSET IN

Ну а то что слайсов тьма, дык 99% попадают под действие PERIOD.

У EMAClite (EDK) так и есть.

 

< Т.к. во время своего опыта я просто замахался распределять все цепи по группам Мне почему-то кажется, что должно быть это как-то проще.>

Я про это и писал "Недавно появились еще соображения на эту тему, надо будет "прожевать"." В общем, констрейны TNM и TNM_NET, должны облегчить эту задачу :).

[v_mirgorodsky 0]

2 3.14:

 

До следующей недели терпит :)

 

<Пользуясь предыдущим объяснением я попытался написать констраин для модуля. Он представлял собой два слоя регистров между которыми крутилась нетривиальная FSM. >

Если так, то у вас три пути которые надо граничить:

1) PADS -> FFS

2) FFS -> FFS

3) FFS -> PADS

Я думаю, Вы их и ограничили наиболее подходящим способом.

Ага, так и делал

NET Clk PERIOD = 7.0 ns;

ISE после PAR'а сказал, что костраин не выполнен. Я посмотрел где он не выполнен и попытался прикрутить MAXDELAY констраин на тонкие места. Ну было у меня такое впечатление, что если на управляющий сигнал, который идет на машину сказать MAXDELAY, то PAR сможет более оптимально их разводить и уменьшит задержки на сам роутинг, т.к. задержки на логику уменьшить все равно не получится. Тексту было просто море а результат никакой - все равно Fmax сильно не изменилась. Вот потому и хочется посмотреть на правильно законстраиненый проект, поиграться с ним, поменять циферки и увидеть как это влияет на результирующую частоту.

 

<Я накрапал UCF файл для ISE и странслировал его для Synplify утилиткой edf2srs. Короче говоря, ничего не получилось>

А вчем был смысл такой манипуляции? Как ни прискорбно, один и тот же HDL, после разных синтезаторов, будет иметь как минимум разные имена внутренних регистров и цепей, соответственно прийдется делать разные UCF. Можно рожать UCF чере Synplify, но у меня такой способ не прижился. Года полтора назад я пытался приучиться именно так "описывать" констрейны, но так и не смог получить "понятный"/"нужный" констрейн.

 

С синтезатором я дружу. Сказывается рисовальческое прошлое. Я хоть и пользуюсь VHDL но реально думаю триггерами, счетчиками, мультиплексорами и т.п. Потому если я говорю, что там есть триггер, то она обычно со мной соглашается. Потому чтобы найти элемент в схеме обычно достаточно написать его имя и поставить * в конце :)

 

edf2srs - попытка иметь один констраин для ISE и Synplify. Вроде бы что-то получилось, но говорить о чем-то доведенном до уровня технологии еще рано.

[3.14 0]

<ISE после PAR'а сказал, что костраин не выполнен. Я посмотрел где он не выполнен и попытался прикрутить MAXDELAY констраин на тонкие места. Ну было у меня такое впечатление, что если на управляющий сигнал, который идет на машину сказать MAXDELAY, то PAR сможет более оптимально их разводить и уменьшит задержки на сам роутинг...>

Если имеется возможность, то лучше пользоваться PERIOD, он должен еще учитывать задержки на синхросигналах, а так же setup и hold.

[v_mirgorodsky 0]

2 3.14:

 

А Вы как-то в этой нити обещали запостить какой-нибудь свой не самый тривиальный проект с прикрученными к нему констраинами. Что-то не получается или просто нет времени?

 

Просто мы уже подходим к финалу разработки одного из наших модулей и хотелось бы к нему в качестве последнего аккорда прилепить файл описания констрейнов, дабы заставить работать его на нужной скорости. PERIOD на него мы уже навернули, но этого ему явно не достаточно, т.к. он это требование иногда выполняет, иногда нет. Частота зависит в основном от фазы луны и плавает в диапазоне 10MHz даже если просто добавить инвертор в совершенно не связанном с ним блоке. Был даже курьез. С блока на блок через два сигнала/проводочка шла связь - понятно, что один можно было выбросить, выбросили и частота упала с 160 до 153MHz. Понятно, что наличие одной связи между блоками позволило синтезатору каким-то образом слить похожую логику двух блоков, что в результате привело к падению производительности. И это при том, что в обоих случаях констраин PERIOD не менялся, блок по входам и выходам имеет триггера, раскладывается в единственном экземпляре в FPGA и занимает всего 10% ее ресурсов :cranky:

 

Еще заметил странное поведение. То что хорошо для Виртекса второго, совсем плохо для Спартана третьего и наоборот. Одна и та же схема, написанная на RTL-уровне работает в Спартане на 99MHz, в Виртексе - на 160. Меняю в схеме логику с триггерами местами, т.е. общий путь остается одинаковым и получаю результат с точностью до наоборот. Правда Виртекс работает всеж на 130MHz, зато Спартан разганяется до 140. При этом оба чипа показывают РАЗНЫЕ критические пути во всех четырех случаях.

 

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

 

Еще заметили странность. Синтезируем схему в Synplify, видим длинный ассинхронный путь с одного триггера на другой. Два раза щелкаем на элементах этого пути и оказывается, что Synplify подсвечивает логику, совершенно даже не относящуюся к этому блоку, а лежащую от него за двумя слоями триггеров :maniac: Понятно, что это есть некоторый глюк синтезатора, но по началу мы пару раз перепахали схему в поисках ошибки :)

 

Теперь я четко понимаю, что при необходимости выжать последние мегагерцы из дизайна его надо оптимизировать под конкретное семейство и даже, в некоторых случаях, под конкретный синтезатор :angry2: