[dxp 51]

Просто мы уже подходим к финалу разработки одного из наших модулей и хотелось бы к нему в качестве последнего аккорда прилепить файл описания констрейнов, дабы заставить работать его на нужной скорости. PERIOD на него мы уже навернули, но этого ему явно не достаточно, т.к. он это требование иногда выполняет, иногда нет. Частота зависит в основном от фазы луны и плавает в диапазоне 10MHz даже если просто добавить инвертор в совершенно не связанном с ним блоке.

 

Странного, имхо, тут мало, так и должно быть, когда проект в данном чипе близок к пределу по быстродейтсвию. 10 МГц разброс на 150 МГц - это еще немного. С Зайлинксом дела почти не имел, но а альтеровских ПЛИСах картина похожая. В текущем проекте при системной тактовой в 160 МГц результат просто от разводки к разводке получается в пределах от 140 до 165 МГц (чип - Циклон 6, спидгрейд 7). Все обконстрейнено выше крыши (удовольствие еще то, скажу я вам! ну его на фиг), мультициклы введены, где скорость такая не требуется.

 

Т.е. 20 МГц при 160 МГц - 12.5%, вполне нормальный разброс в зависимости от разводки. Чтобы не иметь из-за этого головной боли, надо просто иметь запас хотя бы процентов 30 по скорости (понятно, что не всегда это удается, но лучше к этому стремиться).

 

Нахождение оптимальной разводки - задача непростая, в настоящий момент ее, похоже, можно только методом проб решить. В Квартусе для этого есть специальная тулза Design Space Explorer. В ISE, вроде, тоже есть аналогичные средства для многократного прогона разводки с целью поиска наилучшей.

 

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

<{POST_SNAPBACK}>

Синтезатор - синтезатором, только вот на разводку он напрямую не влияет. И не учитывает. А она, тем не менее, очень сильно влияет на быстродействие - процент задержек на связях между логикой по отношению с задержкам на самой логике может в ряде случаев составлять от 20 до 70% (оценивал по критичным путям в своем проекте на Циклоне - в среднем около 40%).

 

Вот этот момент - неучет разводки в реальном чипе - слабое место стороннего синтезатора. Есть дополнительные тулзы типа Amplify, но как с ними эффективно работать я, честно говоря, до конца не врубаюсь. Буду признателен, если кто-нибудь, кто с успехом использует, объяснит основные моменты и сам Design Flow в этом случае.

[3.14 0]

2 v_mirgorodsky

Итак, "боевой" проект в силу ряда причин я выложить не могу, хотел написать корку подключения внешней SRAM к MicroBlaze через шину MLB и затянуть ее как умею, дык блин не успеваю :( (в понедельник прибывают новые платы). Извиняюсь.

Посему попробую на словах.

Вы наверняка знакомы с времянкой на MLB.

Я хотел сделать: использовать одну статическую 16р RAM, тактировать SRAM от удвоенной частоты шины MLB, читать 32р слова за 3 такта шины MLB (6 тактов в самой корке)

T(MLB)=20нс => f(core)=10нс.

Чтение по тактам может выглядеть так:

1) дешифрация адреса

2) защелкиваем адрес первого полуслова, защелкиваем управляющие сигналы

3) удерживаем адрес

4) читаем данные первого полуслова, защелкиваем инкрементированный адрес

5) удерживаем адрес

6) читаем данные второго полуслова, устанавливаем сигнал Ready.

 

По ходу писанины получился такой констрайн файл:

1) NET sys_clk TNM_NET=MB_sync;
2) TIMESPEC "TS_clock_1" = PERIOD "MB_sync" 50 MHz;
3) TIMEGRP to_Core_FFS = FFS(pi_lmb_core_0/*); 
4) TIMEGRP from_Core_FFS = FFS(pi_lmb_core_0/*);
5) TIMESPEC TS_top_to_core =FROM FFS TO to_Core_FFS TS_clock_1 * 2;
6) TIMESPEC TS_core_to_top =FROM from_Core_FFS TO FFS TS_clock_1 * 2;
7) TIMEGRP SRAM_Addres = FFS(pi_lmb_core_0/SRAM_Addr*); 
8) TIMESPEC TS_to_SRAM_Addr =FROM SRAM_Addres TO PADS TS_clock_1 * 2;
9) TIMEGRP SRAM_Control = PADS(SRAM_CE) PADS(SRAM_OE) PADS(SRAM_WE); 
10) TIMESPEC TS_SRAM_Control =FROM FFS TO SRAM_Control TS_clock_1 * 2;
11) TIMEGRP SRAM_Data = PADS(SRAM_Data*); 
12) TIMESPEC TS_to_SRAM_Data_1 =FROM FFS TO SRAM_Data TS_clock_1 * 2;
13) TIMESPEC TS_to_SRAM_Data_2 =FROM SRAM_Data TO FFS TS_clock_1 * 2;

PERIOD для удвоенной частоты появится сам.

Строки 3-6 ограничивают путь Microblaze <-> корка.

Строки 7-8 ограничивают путь адреса SRAM.

Строки 9-10 ограничивают путь упраления SRAM.

Строки 11-13 ограничивают путь данных SRAM.

Можно минимизировать и описать так:

TIMESPEC TS_core_1 =FROM FFS TO FFS(pi_lmb_core_0/*)TS_clock_1 * 2;
TIMESPEC TS_core_2 =FROM FFS(pi_lmb_core_0/*) TO FFS TS_clock_1 * 2;
TIMESPEC TS_core_3 =FROM PADS TO FFS(pi_lmb_core_0/*) TS_clock_1 * 2;
TIMESPEC TS_core_4 =FROM FFS(pi_lmb_core_0/*) TO PADS TS_clock_1 * 2;

В общем, не вписывалась она :( (вписать конечно можно, но это приведет к "неповоротливости" всего проекта и времени потребует ОЧЕНЬ много).

Далее я осознал, что удваивать частоту не обязательно для чтения за 3 такта :)

В этом случает отпадают 1- 4 строки.

В общем таким макаром и затягиваю свою писанину, еще иногда, когда получаются локальные тактовые частоты, применяю MAXSKEW для нее. Величину определяю на глаз (1-2нс), встроенных средств для определения максимального MAXSKEW в ISE нет :(, благо что глобальных тактовых в последних кристаллах становытся больше.

 

Далее по тексту Вашего поста.

Мне очень понравилось как ответил dxp. Могу добавить, что у Xilinx точно такая же картина с "устойчивостью" разводки :( Средства борьбы конечно есть, но все так муторно становится :(

В общем "велком ту фпга дезигнерс".

[v_mirgorodsky 0]

Ну чтож, и на том спасибо :) Жаль, что не получилось с законченным проектом :( Основная идея была как бы поиграться в пределах фиксированного базиса, поизменять циферки в констраин-файле и понять взаимосвязь последних с пректом, потому как "свои" констрейны на данный момент просто не выполняются. Более того, я вижу где же он конкретно лажается, но подсказать ему (синтезатору) правильно не могу, а глобальный констраин PERIOD он тупо не выполняет. Будем разбираться :)

[des00 25]

Ну чтож, и на том спасибо :) Жаль, что не получилось с законченным проектом :( Основная идея была как бы поиграться в пределах фиксированного базиса, поизменять циферки в констраин-файле и понять взаимосвязь последних с пректом, потому как "свои" констрейны на данный момент просто не выполняются. Более того, я вижу где же он конкретно лажается, но подсказать ему (синтезатору)  правильно не могу, а глобальный констраин PERIOD он тупо не выполняет. Будем разбираться :)

<{POST_SNAPBACK}>

Хмм изините что вмешиваюсь а может быть этот контрейн и невозможно выполнить ?

нелзя же требовать того, что невозможно не так ли ??

Например я сделаю 16 уровней сложно логики и попрошу ИСЕ уложить это в 200 МГц. Если логика сложная то он в приницпе этого не сделает. Может быть пересмотреть/переделать "узкие" блоки, которые режут частоту ?

[3.14 0]

Когда закончу (это наверное затянется) обязательно выложу проект EDK.

 

des00 правильно говорит.

 

Мне иногда кажется, что от констрайны годятся только на то чтоб указать на то что модуль не будет работать, а не для того чтоб пытаться что то сделать с проблемными путями :(

 

Может вам попробовать например так:

1) Пытаетесь разместить в кристалле модули по отдельности.

2) Если впишутся, создать RPM мкрос или "тупо" залочить модуть.

 

Или например так (если virtex):

(Я так полагаю синтезатор - Synplify)

1) Перенесите проект в Amplify (синтез Synplify) (правда прийдется физические констрайны перенести в Amlify).

2) Попробовать покрутить через TOPS flow - после синтеза запускает PAR(ISE), если ограничения не вписываются, крутит размещение, повторяет.

 

Ну или еще можно попробовать через PALACE нетлист пргнать.

 

Сами понимаете, выше приведенное более-менее эффективно для минимизации межсоединений. Ну а если в нетлисте заковырка ...

[v_mirgorodsky 0]

Как оказалось, не все так плохо, как казалось изначально. Просто надо подсказывать синтезатору для каких блоков какие примитивы лучше использовать. Приведу пару "свежих"/"сегодняшних" примеров.

 

Были четыре 12-разрядных регистра и сигналы валидности информации в каждом из регистров. Был сигнал входной 12-разрядный. Требовалось сравнить входной сигнал с одним из регистров и выдать управляющий сигнал на FSM в случае равенства/неравенства операндов. Невалидный операнд в одном из четырехразрядных регистров считался неравенством величин. Изначально стоял 12-разрядный компаратор и его выход наворачивался битом валидности логическим И. Скорость этой части дизайна "плавала" в пределах 150-160MHz. После этого был выкушен 12-разрядный компаратор и применен 13-разрядный, 13-м разрядом регистров стал бит валидности, для входного операнда - '1'. Таким образом количество уровней логики не изменилось, но один уровень логики был заменен быстрым мультиплексором сравнивателя, что в свою очередь выкинуло данный кусок схемы из критического пути, повысив частоту именно этого куска схемы до "запредельных" 167MHz :)

 

Второй пример. Был очень "занятый" триггер со сложной системой управления Set/Reset. Этим триггером рулила машина, но при этом о его переключении надо было знать в тот же такт, как он переключался. Ассинхронные Set/Reset отпадали в следствие возможных глитчей на выходах FSM в реальной схеме. Потому Set складывался по ИЛИ с выходом триггера и дальше шел на управляющие входы других триггеров следующего слоя, т.е. уровней логики на управляющем сигнале было два - триггер и выход FSM по ИЛИ. Быстродействие схемы упало до 145MHz или что-то в этом роде. Из FSM был вынут сигнал побуждающий машину перейти в состояние, где устанавливался триггер и отправлен на Set этого триггера - т.е. машина из машины Мура стала машиной Милли по паре сигналов. В результате частота блока выросла до 163MHz. Оказывается машина Милли - это не всегда плохо :ninja:

 

Еще один результат. Если сказать синтезатору, что Set/Reset не бывают активными одновременно, то вместо D-триггера он родит RS-триггер, эффективно убрав еще один уровень логики :cranky:

 

При этом всем мы еще не поставили ни одного платформенно-зависимого элемента <_< Просто надо как-то синтезатору подсказать что тонко именно в этом месте, именно на этом ассинхронном пути, но я еще не до конца разобрался как. Synplify большая умница с точки зрения компиляции, однако иногда и он делает глупые вещи.

[des00 25]

Были четыре 12-разрядных регистра и сигналы валидности  информации в каждом из регистров. Был сигнал входной 12-разрядный. Требовалось сравнить входной сигнал с одним из регистров и выдать управляющий сигнал на FSM в случае равенства/неравенства операндов. Невалидный операнд в одном из четырехразрядных регистров считался неравенством величин. Изначально стоял 12-разрядный компаратор и его выход наворачивался битом валидности логическим И. Скорость этой части дизайна "плавала" в пределах 150-160MHz. После этого был выкушен 12-разрядный компаратор и применен 13-разрядный, 13-м разрядом регистров стал бит валидности, для входного операнда - '1'. Таким образом количество уровней логики не изменилось, но один уровень логики был заменен быстрым мультиплексором сравнивателя, что в свою очередь выкинуло данный кусок схемы из критического пути, повысив частоту именно этого куска схемы до "запредельных" 167MHz :)

Хмм не совсем понял, вы откуда взялся четырехразрядный регистр ?

 

Это как раз то про что я и говрил, лучше критически пересмотреть блоки, и переделать узкие места. :))))

 

А насчет умности синтезатора, я сам удивился тут недавно когда описав блок по другому (не меняя его принципа работы) получил вместо 156 слайсов, всего 35 :))

[v_mirgorodsky 0]

Хмм не совсем понял, вы откуда взялся четырехразрядный регистр ?

<{POST_SNAPBACK}>

 

Это регистр валидности данных в каждом из 12-разрядных регистров. На пример, в строке кеша находится строка 50 и она валидна, т.е. соответсвует информации находящейся под ней памяти. При сбросе бита валидности те же самые 50 уже не будут приниматься в расчет и функция должна будет генерировать неравенство по любому входящему операнду. Строки памяти могут принимать все значения, от нуля до 4095, потому необходим отдельный бит валидности. Похожим образом обстоят дела и с нашим устройством. Так вот введение бита валидности в сравниватель как еще одного разряда позволило повысить скорость работы блока.

 

А насчет умности синтезатора, я сам удивился тут недавно когда описав блок по другому (не меняя его принципа работы) получил вместо 156 слайсов, всего 35 )

<{POST_SNAPBACK}>

 

Такое я видел уже несколько раз, когда пытался отклониться от RTL-уровня описания схемы :) После чего принял решение больше не делать таких экспериментов. Я четко знаю на каких элементах следует собрать мою схему и не его (синтезатора) собачье дело учить меня как это сделать лучше :twak:

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