Xilinx clock definition, Интересно как он это делает Опции

[ATname]

Суть явления в следующем.

Исходный код проекта VHDL, арибуты сигналов отсутствуют как класс.
Файл *.UCF содержит только привязку к контактам (LOC and ect.)
Файла *.XCF нет в принципе.

И тем не менее XilinxISE (XST) умудряется часть сигналов определить как сигналы синхронизации, что видно в редакторе ограничений. Т.е. в соотвествтующем окне есть определенный набор сигналов. Вопрос: откуда сабж взял, что именно эти сигналы являются сигналами синхронизации?
Что характерно, один из таких сигналов даже близко не подключен к контактам глобального клока...

[alexadmin]

И тем не менее XilinxISE (XST) умудряется часть сигналов определить как сигналы синхронизации, что видно в редакторе ограничений. Т.е. в соотвествтующем окне есть определенный набор сигналов. Вопрос: откуда сабж взял, что именно эти сигналы являются сигналами синхронизации?
Что характерно, один из таких сигналов даже близко не подключен к контактам глобального клока...

Зато они подключены к тактовым входам тригеров! ;-)

[Boris_TS]

Вопрос: откуда сабж взял, что именно эти сигналы являются сигналами синхронизации?
Что характерно, один из таких сигналов даже близко не подключен к контактам глобального клока...

При корявом описании различных узлов могут возникать Latch с локальным тактированием. Сигнал, которым тактируется хотя бы один тактовый вход (Latch, FF и пр. компонентов), считается clock'ом.
На большее моей телепатии не хватает, приведите отчёт XST, тогда можно будет сказать больше и точнее.

[ATname]

При корявом описании различных узлов могут возникать Latch с локальным тактированием. Сигнал, которым тактируется хотя бы один тактовый вход (Latch, FF и пр. компонентов), считается clock'ом.
На большее моей телепатии не хватает, приведите отчёт XST, тогда можно будет сказать больше и точнее.

Тот факт, что "...Сигнал, которым тактируется хотя бы один тактовый вход, считается clock'ом..." я понимаю.
Вопрос гораааааааздо интересней. В приведенном отчете сигнал cpu_nwe как раз и является тем самым сигналом, который не подключен к контакту глобального клока, но определен XST как клоковый.
Заковыка как раз в том, что в данном отчете, в разделе "Clock Information:", нет сигнала cpu_ncs0, который, как раз в перечне клоковых редактора ограничений, стоит в полный рост. Наряду с имеющимися в отчете cpu_nwe и fpga_clk.
И что с этим делать?

Прикрепленные файлы

 Main.rar ( 18.91 килобайт ) Кол-во скачиваний: 20

 

[Boris_TS]

Вопрос гораааааааздо интересней. В приведенном отчете сигнал cpu_nwe как раз и является тем самым сигналом, который не подключен к контакту глобального клока, но определен XST как клоковый.

Тот факт, что "...Сигнал, которым тактируется хотя бы один тактовый вход, считается clock'ом..." я понимаю.

А в чём тогда проблема ??

Внимательно смотрим сюда:

Код

Clock Information:
------------------
--------------+------------------------+-------+
Clock Signal  | Clock buffer(FF name)  | Load  |
--------------+------------------------+-------+
...
cpu_nwe       | IBUF+BUFG              | 16    |
...

Видим cpu_nwe - типичный clock signal подаваемый аж на 16 входов. Если Вам кажется это странным, то смотрим дальше:

Код

=========================================================================
Timing constraint: Default OFFSET IN BEFORE for Clock 'cpu_nwe'
  Total number of paths / destination ports: 16 / 16
-------------------------------------------------------------------------
Offset:              9.889ns (Levels of Logic = 6)
  Source:            cpu_ncs0 (PAD)
  Destination:       Inst_audio_cntr/AudioChannel1/bitLoop (LATCH)
  Destination Clock: cpu_nwe rising

  Data Path: cpu_ncs0 to Inst_audio_cntr/AudioChannel1/bitLoop
                                Gate     Net
    Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
    ----------------------------------------  ------------
     IBUF:I->O             6   1.218   0.704  cpu_ncs0_IBUF (cpu_ncs0_IBUF)
     LUT3:I2->O            1   0.704   0.424  cs_audio_SW0 (N723)
     LUT4:I3->O           12   0.704   0.996  cs_audio (cs_audio)
     LUT3:I2->O           10   0.704   0.917  Inst_audio_cntr/csChan1_and000011 (N597)
     LUT3:I2->O           11   0.704   1.108  Inst_audio_cntr/csChan2_and00001 (Inst_audio_cntr/csChan2)
     LUT3:I0->O            2   0.704   0.447  Inst_audio_cntr/AudioChannel2/bitPause_and00001 (Inst_audio_cntr/AudioChannel2/bitPause_and0000)
     LDCE:GE                   0.555          Inst_audio_cntr/AudioChannel2/bitLoop
    ----------------------------------------
    Total                      9.889ns (5.293ns logic, 4.596ns route)
                                       (53.5% logic, 46.5% route)
=========================================================================
...

Тут даже глаз разувать не надо: всё уже написано:
Destination: Inst_audio_cntr/AudioChannel1/bitLoop (LATCH)
Destination Clock: cpu_nwe rising

И что с этим делать?

Правильно описывать на языке различные конструкции, и внимательно читать отчёт синтезатора (!) - от опечаток никто не застрахован, поэтому WARNING:Xst:737 от XST об обнаружении Latch стоит искать и анализировать с особой тщательностью.

P.S. Откройте секрет, что такое "контакт глобального клока" ? И почему Clock не может браться от других источников ?

P.P.S. А Вы вообще читали названия Ваших clock'овых сигналов, которые обнаружил XST ? Вам от этих названий страшно не стало (?): Inst_sdram_access/regAddrHi_and00001_1 - это же смахивает на натуральный Gated clock ! И в отчёте их достаточно много.

[ATname]

Вы пропустили самое главное, вот это: "Заковыка как раз в том, что в данном отчете, в разделе "Clock Information:", нет сигнала cpu_ncs0...".
То, что Вы так старательно описали, понятно и без столь пространных объяснений.

Тут интересно другое: почему сигнал подключенный к контакту глобального клока (cpu_ncs0, а также и cpu_ncs1, не упомянутый XST вовсе) и имеющий (согласно кода) практически такой же путь прохождения как и cpu_nwe, клоковым не является (по мнению XST). Заметьте, что именно XST определяет кому быть клоковым сигналом, а кому нет. Ну и за каким тогда вообще нужно выделять клоковые контакты и специальные трассировочные ресурсы глобального клока, если работающий по непонятным критериям XST выделяет клоковый сигнал согласно своим алгоритмам оптимизации?

Тут более глобальный вопрос: как заставить ISE тарссировать нужные мне сигналы именно по клоковым ресурсам, без "сюрпризов" со стороны ISE в стиле мелкогософта: типа нам лучше знать, что для вас лучше.

[andrew_b]

Не надо гнать на xst, это нормальный синтезатор. Если хотите, чтобы он работал предсказуемо, почитайте манул, там есть примеры того, как та или иная конструкция кода отображается в ресурсы FPGA.

[Boris_TS]

Вы пропустили самое главное, вот это: "Заковыка как раз в том, что в данном отчете, в разделе "Clock Information:", нет сигнала cpu_ncs0...".
То, что Вы так старательно описали, понятно и без столь пространных объяснений.

Я ответил на ту половину Вашего вопроса, на которую возможно было ответить по имеющимся материалам: то, что сделал синтезатор - было отражено в отчёте (соответственно, я проанализировал имеющуюся информацию и отписался о наличии ошибок описания схемы); а то, чего синтезатор не сделал - соответственно и не отражено в отчёте. Если Вы хотите узнать на форуме, почему синтезатор не воспринял Ваше описание, так, как Вы хотели, то Вам необходимо выложить исходники Вашего проекта (или фрагменты исходников, которые вызывают вопросы).

Тут интересно другое: почему сигнал подключенный к контакту глобального клока (cpu_ncs0, а также и cpu_ncs1, не упомянутый XST вовсе) и имеющий (согласно кода) практически такой же путь прохождения как и cpu_nwe, клоковым не является (по мнению XST). Заметьте, что именно XST определяет кому быть клоковым сигналом, а кому нет.

Замечу, что не столько от XST, сколько от HDL описания зависит, что и как будет синтезировано. Если Вы сознательно допускаете описание, которое может неоднозначно трактоваться, то не удивляйтесь за последствия: что написали, то и получили.

Ну и за каким тогда вообще нужно выделять клоковые контакты и специальные трассировочные ресурсы глобального клока, если работающий по непонятным критериям XST выделяет клоковый сигнал согласно своим алгоритмам оптимизации?

Вы же так и не ответили: "что же это такое "клоковые контакты" ?", а еще хотите чтобы мы толковали этого термин. Пока Вы не поясните, что Вы имеете в виду - мы не сможем Вам ответить (для уменьшения кривизны переводов - оперируйте англоязычными терминами).
Вообще-то ответы на эти вопросы находятся в Spartan-3 Generation FPGA User Guide в главе Using Global Clock Resources.

Тут более глобальный вопрос: как заставить ISE тарссировать нужные мне сигналы именно по клоковым ресурсам, без "сюрпризов" со стороны ISE в стиле мелкогософта: типа нам лучше знать, что для вас лучше.

1. В составе ISE 13.4 есть документы "XST User Guide for Virtex-4, Virtex-5, Spartan-3, and Newer CPLD Devices" (xst.pdf) и "XST User Guide for Virtex-6, Spartan-6, and 7 Series Devices" (xst_v6s6.pdf). Если Вы что-то хотите от XST, то Вам необходимо внимательно прочитать хотя бы один из этих документов. Главное чётко уразуметь, что синтезатор может реализовать в железе далеко не все возможные языковые выпендрясы, поэтому в описании на синтезаторы обычно подробно рассказывается как описывать те или иные конструкции, а также приводятся примеры того, что необходимо втыкать примитивами, из-за невозможности описания оного на языке (например DCM и XADC нельзя описать синтезируемой конструкцией).

Кстати, открою большую тайну: XST ничего не трассирует - этим занимается Place&Route, а XST только синтезирует.

2. Если Вы хотите, чтобы сюрпризов совсем не было, то вы должны:
a) досконально изучить ПЛИС с которой Вы собираетесь работать и все её узлы, которые Вы собираетесь задействовать (в своё время мне очень сильно помог FPGA Editor - этой уникальной программой можно посмотреть что и как легло в кристалл, а также какие в кристалле есть блоки/их настройки/связи и пр.);
b) изучить Libraries Guides на Вами применяемые ПЛИС;
c) изучить подходящий XST User Guide;
d) изучить Constraints Guide.
После этого мы сможем поговорить на более или менее одном языке.

Общий совет: для уменьшения кривизна проекта, отключите опцию синтезатора Add I/O Buffers, и вручную повтыкайте те IO буфера, которые нужны и туда, куда нужно. Также, для особо тяжёлых случаев, очень хорошо помогает ручная установка BUFG, BUFR, BUFH и подобных. Чем больше Вы сделаете сами - тем меньше надо будет догадываться синтезатору о Ваших потяёных желаниях (не описали что-то - значит утаили это от синтезатора), и тем более качественный результат Вы получите.

[ATname]

Многоуважаемый сэр!
Упомянутые Вами документы мне известны. Как и используемый в проекте тип FPGA.

А вынесенный на рассмотрение вопрос возник из процесса переноса ранее (успешно) реализованного проекта в иную (более старшую) версию ISE. И из всей этой "бадяги" можно сделать одно заключение. В обход ограничений проекта XST по своему разумению, в силу своих алгоритмов оптимизации процесса синтеза, может создавать специфические сигналы (в данном случае сигнал синхронизации) который ему не задавали.
В данном случае XST подсунул в проект, то чего в нем раньше (в более младшей версии ISE) НЕ БЫЛО! И перегрузил ресурсы глобального клока, вчистую развалив работающий (в более младшей версии ISE) проект.

Из Ваших содержательных ответов видно, что как бороться с этим явлением Вам неизвестно.

Не сомневаюсь, что Вы истинный виртуоз в программирования на HDL, чего нам, за ...дцать лет работы в отрасли, достичь не довелось.

P.S. Если Вас посылают... читать документацию, то главное в этом процессе это то, что Вас послали. А куда и зачем, значения не имеет.

[Bad0512]

Многоуважаемый сэр!
Упомянутые Вами документы мне известны. Как и используемый в проекте тип FPGA.

А вынесенный на рассмотрение вопрос возник из процесса переноса ранее (успешно) реализованного проекта в иную (более старшую) версию ISE. И из всей этой "бадяги" можно сделать одно заключение. В обход ограничений проекта XST по своему разумению, в силу своих алгоритмов оптимизации процесса синтеза, может создавать специфические сигналы (в данном случае сигнал синхронизации) который ему не задавали.
В данном случае XST подсунул в проект, то чего в нем раньше (в более младшей версии ISE) НЕ БЫЛО! И перегрузил ресурсы глобального клока, вчистую развалив работающий (в более младшей версии ISE) проект.

Из Ваших содержательных ответов видно, что как бороться с этим явлением Вам неизвестно.

Не сомневаюсь, что Вы истинный виртуоз в программирования на HDL, чего нам, за ...дцать лет работы в отрасли, достичь не довелось.

P.S. Если Вас посылают... читать документацию, то главное в этом процессе это то, что Вас послали. А куда и зачем, значения не имеет.

Вы совершенно напрасно обижаетесь, вас справедливо отсылают к мануалам именно потому, что ошибки-то у вас ДЕТСКИЕ. Именно в следствии этих детских ошибок (latches, gated clocks) у вас и "пропал" нужный вам клок. Вы наплодили (видимо из-за неряшливого стиля кодинга) тучу gated clocks с маленьким fanout, поэтому у синтезатора скорее всего тупо не хватило клоковых ресурсов для вашего "нужного" клока. Ну а обстоятельство, что раньше XST этот ваш кривоватый код как-то умудрялся пережёвывать - вас совсем не оправдывает.Пишите аккуратно - не будет сюрпризов.

[Boris_TS]

Многоуважаемый сэр!

Вообще-то, я скромный советский товарищ.

Упомянутые Вами документы мне известны. Как и используемый в проекте тип FPGA.

Хорошо. Ну а тогда зачем же Вы вопрошаете про "клоковые контакты" ? - в FPGA Editor'е сразу же видно - что у соответствующих IOB есть дополнительная связь (с хорошими временными параметрами) для выхода на dedicated clock resource; более, существенных отличий в кристалле между GCLK/RHCLK/LHCLK и "обычными" IOB'ами - нет.

А вынесенный на рассмотрение вопрос возник из процесса переноса ранее (успешно) реализованного проекта в иную (более старшую) версию ISE. И из всей этой "бадяги" можно сделать одно заключение. В обход ограничений проекта XST по своему разумению, в силу своих алгоритмов оптимизации процесса синтеза, может создавать специфические сигналы (в данном случае сигнал синхронизации) который ему не задавали.
В данном случае XST подсунул в проект, то чего в нем раньше (в более младшей версии ISE) НЕ БЫЛО! И перегрузил ресурсы глобального клока, вчистую развалив работающий (в более младшей версии ISE) проект.

Ну вот мы и добрались до сути дела. Вероятность наличия ошибки в XST я не отрицаю, но всё-таки она не велика. Как я писал ранее, заочно предполагаю неоднозначность Вашего описания, для более точного диагноза нужен код (или фрамент кода) - без него ловить нечего. К сожалению, в настоящее время, я пишу только на VHDL, но, думаю, если вы работаете на Verilog'е, то найдутся другие специалисты, которые заинтересуются и смогут разобрать Ваш код: пояснить неоднозначности или, быть может, констатировать наличие еще одной ошибки в XST.

Из Ваших содержательных ответов видно, что как бороться с этим явлением Вам неизвестно.

Я боролся и с ошибками в XST (13.1), коие были признаны Xilinx (в процессе WebCase переписок) и исправлены не в 13.3 (как первоначально заявлялось), а аж в 13.4 - настолько они много за собой потянули. Опыт, хе-хе, есть. Кстати нарвались тоже при переходе (от 11.5 к 13.1) - работающий проект "вдруг" стал жестоко глючить (Virtex-6), а при функциональном моделировании синхронного проекта все замечательно !

P.S. Если Вас посылают... читать документацию, то главное в этом процессе это то, что Вас послали. А куда и зачем, значения не имеет.

Вы ошибаетесь, как раз имеет. Коли Вы задаёте странные, на мой взгляд, вопросы (про "клоковые контакты" и пр.), то я и указал Вам документы для приведения Вашей терминологии в соответствие с терминологией Xilinx, чтобы мы могли лучше понимать друг друга: я - о чём именно Вы спрашиваете, а Вы - то, что я пытаюсь ответить.

Да, я тут совсем упустил из виду, что у Вас Spartan-3e в котором весьма мало BUFG - и они могут так быстро кончиться (у меня в Virtex-5/6 этих BUFG на много больше + еще BUFR и BUFH водятся пачками, поэтому глаз уже замылился: не разглядел, что для Spartan-3e у Вас что-то многова-то clock'ов).
А бороться с этим просто:

Общий совет: для уменьшения кривизна проекта, отключите опцию синтезатора Add I/O Buffers, и вручную повтыкайте те IO буфера, которые нужны и туда, куда нужно. Также, для особо тяжёлых случаев, очень хорошо помогает ручная установка BUFG, BUFR, BUFH и подобных. Чем больше Вы сделаете сами - тем меньше надо будет догадываться синтезатору о Ваших потяёных желаниях (не описали что-то - значит утаили это от синтезатора), и тем более качественный результат Вы получите.

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

[ATname]

Вы совершенно напрасно обижаетесь, вас справедливо отсылают к мануалам именно потому, что ошибки-то у вас ДЕТСКИЕ. Именно в следствии этих детских ошибок (latches, gated clocks) у вас и "пропал" нужный вам клок. Вы наплодили (видимо из-за неряшливого стиля кодинга) тучу gated clocks с маленьким fanout, поэтому у синтезатора скорее всего тупо не хватило клоковых ресурсов для вашего "нужного" клока. Ну а обстоятельство, что раньше XST этот ваш кривоватый код как-то умудрялся пережёвывать - вас совсем не оправдывает.Пишите аккуратно - не будет сюрпризов.

Во-первых, код не мой.
Во-вторых, "детские ошибки" всего лишь иллюстрация "простой истины": наличие в кристаллах Xilinx специализированных ресурсов для сигналов синхронизации (клоковых ресурсов) НИЧЕГО НЕ ГАРАНТИРУЕТ! НЕТ НИКАКИХ способов ЖЕСТКО гарантировать трассировку сигналов клока по клоковым ресурсам в кристалле. Есть только надежда на то, что если удастся угадать (не больше, ни меньше) по каким критериям и как именно ту или иную языковую конструкцию синтезатор интерпретирует, то есть надежда, что сигнал будет тарссироваться по клоковым ресурсам. Вот этим самым: см. ug331.pdf стр.47 рис 2-2, если кто не понимает, о чем идет речь.
Контролировать этот процесс явно (вплоть до выдачи синтезатором предупреждений или ошибок) такого инструмента (прямого действия) у разработчика нет. И в этом аспекте, подключать клоковые сигналы на контакты, специально выделенные для этих целей производителем кристалла - только лишняя головная боль.
От которой, тем не менее, никуда не деться.

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

P.S. Если бы Вы соизволили внимательно прочитать прикрепленный отчет сиснтезатора, то вопросов о "перегрузке" клоковых ресурсов в Вашем посте не последовало. Ресурсов этих там более чем.

[Boris_TS]

Ну вот мы и добрались до сути дела. Вероятность наличия ошибки в XST я не отрицаю, но всё-таки она не велика.

Как оказалось, эта вероятность значительно больше, чем хотелось бы.
Сегодня, при перетаскивании моего проекта обнаружилось, что ISE 13.4 Virtex-6 XST по сравнению с ISE 11.5 Virtex-5 XST в ряде случаев разучился адекватно воспринимать следующие конструкции:

Код

process(C) begin
    if rising_edge(C) and CE = '1' then
        Q <= D;
    end if;
end process;

Q <= D when rising_edge(C) and CE = '1';

Т.к. эти конструкции мне очень сильно нравятся, из-за того, что они повышают компактность (наглядность) кода, то в настоящее время я локализую причины сбоев XST для открытия очередного WebCase.
Ранее мы не смогли обнаружить оные глюки, т.к. в проектах моих коллег таких конструкций не встречалось.

Замечу, что и в XST User Guide этих конструкций нет.
Если у Вас (ATname) в коде присутствуют подобные конструкции, то Вы напрасно проигнорировали рекомендации перечитать XST User Guide. Возможно, именно эти конструкции приводят к неадекватному поведению XST в новой версии ISE. В любом случае, Вы так и не выложили код или его фрагменты для анализа. Без кода говорить по существу больше невозможно.

[Bad0512]

Во-первых, код не мой.
Во-вторых, "детские ошибки" всего лишь иллюстрация "простой истины": наличие в кристаллах Xilinx специализированных ресурсов для сигналов синхронизации (клоковых ресурсов) НИЧЕГО НЕ ГАРАНТИРУЕТ! НЕТ НИКАКИХ способов ЖЕСТКО гарантировать трассировку сигналов клока по клоковым ресурсам в кристалле. Есть только надежда на то, что если удастся угадать (не больше, ни меньше) по каким критериям и как именно ту или иную языковую конструкцию синтезатор интерпретирует, то есть надежда, что сигнал будет тарссироваться по клоковым ресурсам. Вот этим самым: см. ug331.pdf стр.47 рис 2-2, если кто не понимает, о чем идет речь.
Контролировать этот процесс явно (вплоть до выдачи синтезатором предупреждений или ошибок) такого инструмента (прямого действия) у разработчика нет. И в этом аспекте, подключать клоковые сигналы на контакты, специально выделенные для этих целей производителем кристалла - только лишняя головная боль.
От которой, тем не менее, никуда не деться.

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

P.S. Если бы Вы соизволили внимательно прочитать прикрепленный отчет сиснтезатора, то вопросов о "перегрузке" клоковых ресурсов в Вашем посте не последовало. Ресурсов этих там более чем.

Я и не утверждаю, что код ваш. Я лишь утверждаю что он написан криво, поэтому глупо ждать от синтезатора,маппера и роутера адекватного поведения в ситуации когда вы ставите ему непосильную задачу. В приведённом репорте указано, что из 24-х клоковых буферов используется только 9, однако это не означает что можно попользовать все 24 - у спартана хитрая схема тактирования, не все клоковые буфера могут тактировать весь кристалл - см. мануалы. При этом в репорте есть предупреждение о 33-х !!! gated clocks с мелким fanout-ом. Соответственно ресурсов кристалла в любом случае не хватит для того, что все эти gated clocks использовали клоковые ресурсы. Как поступит в этой ситуации technology mapper? Я не знаю, и боюсь что сами разработчики софта ISE тоже не знают. А вы утверждаете что "наличие ресурсов ничего не гарантирует". Это примерно то же самое, что резать японской бензопилой лом, а потом предъявлять претензии производителю бензопилы.
Кроме того, у вас похоже имеется некоторая путаница в понимании того, что такое "клоковые ресурсы". У Xilinx есть понятие clock capable pin. Это такая спец. нога, задержка распространения сигнала по которой до определённого клокового буфера будет минимальной и всегда одинаковой. Однако сигнал на клоковый буфер можно завести и с любой другой ноги, при этом задержка будет больше, она будет меняться от разводки к разводке и маппер выдаст соответствующий ваининг. Однако это не есть ошибка, это всего лишь "нежелательная ситуация". Чтобы пользовать колоквые линии существуют специальные примитивы под назвнием GBUF - если бы вы использовали эти примитивы, то тогда уже можно "кое-что гарантировать", как вам уже и советовали выше. Однако вы упрямо продолжаете кормить бензопилу ломом да ещё и потом кричать что "никто ничего не гарантирует".
Что ж, удачи вам в этом нелёгком деле - продолжайте в том же духе...