Да, увидел.

Точно нет. Проект большой. Это надо все автоматы сбрасывать (а их больше десятка), кое-какие регистры, в общем надо долго и нудно в этом копаться.

Да, мне уже объяснили. И в связи с этим я начал кое-что переосмысливать. Если асинхронный сброс действительно распространяется по выделенным линиям и он ни как не усложняет трассировку, тогда может быть имеет смысл сбрасывать асинхронно все триггеры, и не ломать голову какие нужно сбрасывать, а какие нет?

Это не то. Не помню точно что это, но точно не то. Скорее всего там речь идёт о частоте от генератора, а у нас ПЛЛ в самом начале нестабильную частоту выдаёт, и вот это надо как-то задавить.

Да ну... как написано, сброс при потере захвата ФАПЧ, так и будет. Перезагрузка. Значит, пока ФАПЧ не установилась, состояние "загрузки" будет оставаться. Не будет же ПЛИС вечно перезагружаться при включении.

Ну, только, некоторые, обычно, надо и предустанавливать... По этой части недавно темка была, где я подробно все описал, что и как надо делать, чтобы после такого асинхронного резета все завелось без сбоев - http://electronix.ru/forum/index.php?showtopic=125343. Та тема немного о другом, но и применима к Вашему случаю - все сбрасываете асинхронно, а вот на разрешение работы триггеров, инициирующих первичные процессы в системе, в тех случаях, когда это может привести к метастабильности от неудачного отпускания резета, подаете слегка задержанный сигнал того же резета, синхронизированный с клоком. Получите минимум занятых ресурсов.

Только не догадайтесь завести этот резет на резет PLL - оно тогда само себя заклинит через Lock

как показано в сообщении №4

Я устанавливал эту галку - не помогло, на старте частота нестабильна.

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

Ну если это возможно, засинхронизировать его со всем необходимым сразу, то, конечно, проще. Но в реальности, обычно, так не бывает, поэтому оказывается проще оставить сброс асинхронным, но отодвинуть начало работы схемы на 1-2 такта от сброса, сделав сдвинутый по времени enable в одной...двух точках, отвечающих за начало работы. Хотя, для проекта, полностью работающего на одном клоке, наверное это не актуально.

Я понял, Вы про многоклоковый дизайн. Да, у меня именно такой. Спасибо за наводку.

Ну как я и предсказывал:
Кто может ответить, почему к аппаратному входу CE триггера не подключает такие вещи? (я могу предположить некоторые причины, но не уверен).

К стати, вопрос: как получить такую схему после разводки в Квартусе (коллеге надо, квартус 9.0, плисина FLEX10K), т.е. что куда нажать, чтобы вывело?



Ну этот документ и термины от Xilinx, в альтере, кажется, это называется Ripple Clock. Но предлагаю Вам этот документ всё же прочитать, буквально пару страниц, вокруг того абзаца на английском, там есть все разъяснения и примеры, что есть что. В двух словах:
Вы немного перепутали:
CLB CE - это "разрешение клока на триггере".
BUFGCE - правильно.
Gated clock - питание входов CLK триггеров от выхода логики (триггер или лут), зачастую с подключением этого выхода к глобальной линии.

Ничего удивительного. Именно для вашего примера, использование сигнала En, как сигнала разрешения ENA триггера в LE не эффективно. Причины объясняются тут Cyclone IV Device Handbook -> Logic Elements and Logic Array Blocks in Cyclone IV Devices -> Logic Array Blocks.

Логический вывод из этого думаю сможете сделать самостоятельно. Это кстати касается всех современных ПЛИС.

Вот, кстати, именно в данном случае, в проекте из одного триггера, это логике и не поддается. По разводке оба варианта одинаковы (какая разница, завести enable на LAB CE, или на LUT, все равно куда-то заводить, конкуренции между этими сигналами в данной схеме нет), а вот лишний LUT занят (кол-во LUT - вроде как один из критериев оптимизации).

И, кстати, это далеко не всех ПЛИС и сред касается:

Видимо, потому, что правильнее управлять данными, а не тактами. О чем я выше намекал.

Немного не корректно. В случае использования clkena для одного LE из LAB, у вас "убивается" весь LAB. Т.е. вы уже не можете использовать триггеры других 15 ти LE. А LUT можете использовать либо для многолютовой комбинаторики либо для нагрузки триггеров из другого LAB. И в общем случае это приведет к перерасходу ресурсов разводки и не возможности register packing. Тоже самое касается сигналов sclr и sload. А то что ква делает так, ну вот такой у него оптимизатор. Даже в проекте из одного триггера на миллионный чип. Кстати LAB в первых сыклонах был 10LE и там чудно делались сложные (с использованием сигналов clear/load/enable) 40 бит аккумуляторы. В старших, пришлось кое где уйти на 32 бита.

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

UPD. В стратиксе 5 ом, в LAB 10ALM, в каждом 4 ре триггера. И там, цена желания что бы на счетчике был именно clkena (ручная вставка dffeas примитивов) еще выше.

UPD2. Посмотрел на вашу картинку внимательнее. Судя по всему верхняя половина LE не задействована. Вам повезло, "убийство" верхнего триггера вы не заметили. Вот будет у вас более плотный дизайн, тогда думаю обратите на это внимание

А причем тут "общий случай" и какие-то гипотетические триггеры и сигналы, которые могут быть нужны и которых нет? У нас случай вполне себе частный, и конкретный, от автора:


1) В части разводки конкуренции нет, больше цепей нет в принципе, следовательно, критерий отпадает (умножается на коэфф. конкуренции = 0).
2) В части нужности других CE - тоже нет, тоже критерий отпадает (умножается на коэфф. конкуренции = 0).
3) В части нужности других триггеров в LAB - опять, конкуренции нет, опять, критерий отпадает (умножается на коэфф. конкуренции = 0).
4) А вот LUT - он и ток кушает, и место (area) занимает, так что критерий имеет вес. Вот его и следует соптимизировать, заведя сигнал на CE.


Нет там таких ключей, CE тоже общий. Любой смотрите на выбор, разводится одинаково (я проверил на XO2, XO3, XP, XP2, ECP2, ECP3). Просто, там, оптимизатор делает свою работу более логично, нежели квартус.

PS
А когда количество enable-ов от одного сигнала возрастает, так, тем более, есть прямой смысл их объединять в кучу и заводить на CE, и не только на LAB/SLICE CE, но и в более глобальные ресурсы разводки.

Это все софистика при решении задачи о сферическом коне в вакууме. Вы гуру вам виднее и опыта у вас больше.

Мои результаты по утаптыванию проектов в чипы от альтер приводил на форуме кучу раз. 99.5-99.8 % занятого дспешным кодом третьего сыклона, хлопающего на частоте 192МГц (у него триггерная 250). Всё после изучения даташитов и логических выводов о работе квартуса.

А Вы вернитесь в мир реальный, к реальному элементарному исходнику из одного триггера, о котором речь в теме идет, и который неоптимально укладывается квартусом. А не о забитии 99% кристалла.

PS
Может, если ему дать больше приоритета на Area, и заведет? Я сейчас посмотрел, в моей среде по умолчанию стоит и Area, и Timing driven.

UPD:
Убрал "Area", ничего не поменялось...

Ну значит я правильно подозревал причину. В Xilinx это называется, кажется, control set.


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


Xilinx этим тоже грешит.

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


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

Про сферического коня - это правильно. Пример тривиальный. Зачем ругать синтезатор из-за ошибки на тривиальных примерах? Да, формально это ошибка, но ругать надо, когда будет неоптимально синтезить нормальные проекты.
Предлагаю засинтезить проект по защёлкиванию шины данных (размером с количество "теряемых" триггеров) по клоку, стробируемому по CE. В этом случае хотя бы синтезатору будет видно, что совершенно все триггеры имеют CE, и ничего не потеряется, если подать CE прямо на соответствующий выделенный аппаратный вход триггера.
Можно ещё дополнительно усложнить задачу, подобрав на входе триггера такую комбинационную функцию, которая бы занимала все входы LUT'а. В этом случае добавление к этой функции ещё одного сигнала приводит к необходимости ещё одного лута, а это уж точно неоптимально (просто в тривиальном примере от добавления сигнала CE к LUT'у ничего страшного не происходит, т.к. ещё есть свободные входы).


Да я пробовал и на неплотных проектах. Да вообще где ни пробовал - там это везде наблюдалось. Из чего я сделал для себя эмпирический вывод, что с этим надо смириться, CE он добавляет не на аппаратный выделенный вход триггера, а замешивает в LUT.


А если домен один - то нет преимуществ?

Ну это, смотря как этот enable делать. Я имел в виду нечто вроде DCS/BUFGCE/Gated_clock - таким образом, каждый enable создает свой домен, экономя потребление (отключается целый сегмент дерева тактовых сигналов). Но затраты на разводку увеличиваются - так как начинаются проблемы с коррекцией HOLD-ов на междоменных переходах. А подача на CE с точки зрения затратности ресурсов на разводку идентична мультиплексору данных.


Из соображений логики. Раз на тривиальном сделал неоптимально, значит и на нетривиальном где-то лажанется по этой же причине....

Вот именно что пример высосан из пальца и все вот это:

Именно софистика. ответы на 1-3 дал постом выше : "А то что ква делает так, ну вот такой у него оптимизатор". а по пункту 4 ре вы сами вчитайтесь в вашу фразу с точки зрения ПЛИСа и в котором 5к лютов и а фоне потребления этого чипа в статике этот LUT как мертвому припарка.
Понимаю что вам, как асикостроителю, все это чуждо и вызывает бурю негодования. Но, как уже писал, на настоящих реальных проектах поголовное использование сигналов разрешения в качестве clkena триггеров приведет к результату более низкого качества, чем результат полученный со взвешенным использованием того самого clkena (квартус тоже это делает).

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


Оно должно быть не поголовное, а оптимальное, на любых проектах. Зачем искать оправдания для банального глюка оптимизатора?

для вас это глюк, для меня это изученная фича, имеющая под собой логические обоснования. задали вопрос - объяснил логику такого поступка, остальные вопросы www.altera.com.

Не-не-не ))) Объяснения "ну вот такой вот синтезатор, хоть убейте" не годятся )))

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


Я бы всё же называл это стандартным термином "known bugs and issues" )) Всё же надо признать, что формально для тривиального проекта это бага. Пусть и ни на что не влияющая.


А если на тривиальном не сделал неоптимально, то всё равно может лажануться на крупном ))) Не застрахуешься. Это как к людям, "отбывшим в местах не столь отдалённых", относятся с недоверием, скажем, при приёме на работу: один раз оступился, значит обязательно ещё раз оступится.

Это не "для меня" глюк. Ничего личного. Это просто глюк, и все тут. Суть его я объяснил - если ресурс (свободные триггеры, LUT CE, и т.п.) не занят, то и нечего его "зажимать" непонятно для чего. Я даже предполагаю, для чего он это делает - вероятно, для упрощения себе жизни при инкрементальных размещении и разводке, так как он (глюк) появился как раз примерно в одно время с этими инкрементальными фичами... С инкрементальной точки зрения, конечно, зажопить 7 триггеров про запас выгоднее, чем освободить 1 LUT. Но это никак не оптимально с точки зрения размещения конкретного проекта. Совсем старые версии более эффективно задействовали CE в простых проектах. Да и вообще за квартусом замечено, чем новее версия, тем менее эффективно использование ресурсов ПЛИС (может, чтобы более толстые кристаллы покупали... а может из-за ленивости программистов...). У меня даже был конкретный случай, когда я активно пользовался альтерой, где-то в районе 8-9-х версий квартуса, что после очередного обновления перестал влезать проект, отлично влезавший и работавший ранее и с квартусом, и даже с Max+plus... А уж увеличение area на ровном месте с увеличением версии квартуса, так это вообще, норма жизни.

Для проверки забейте 4 входных сигнала вместо 1. Например, по И объедините. LUT весь используется, и Quartus будет вынужден использовать CE.
А потом посмотрите быстродействие для обоих вариантов.

Ничего он не будет вынужден. Он еще может это на 2-х лутах собрать. К сожалению, проверить не могу, нет сейчас квартуса. А быстродействие все равно уложится в заданные констрейны, разница в 1 лут это примерно сотня-две пикосекунд, мелочь, если он и в тривиальном случае не задействует быстрый прямой CE. Но это догадки.

То, что уложится, понятно. Но максимальную тактовую частоту покажет. На двух LUT - это уже слишком неоптимально, не такой он глупый, Quartus.
Jackov проверит, надеюсь.

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

Задать оптимизацию по скорости, а не по площади. Еще есть третий вариант - баланс между первый и вторым. Не знаю, как там по умолчанию задано.

Для оптимизации по скорости надо, кроме режима самой оптимизации, еще и скорость задать. Ни одна среда не занимается оптимизацией до тех пор, пока что-то оптимизируется. Все среды оптимизируют до тех пор, пока все пути не уложится в констрейны. Пути, не описанные в констрейнах, оптимизации по скорости не подлежат изначально.

Не уверен, но помню, что галки SPEED, AREA еще со времен MAXPlus+II были, когда даже слова такого "constraint" никто (я) не знал.
Ок, зададим 1000 МГц, пусть попыхтит.

Они меняют стоимости тех или иных критериев. А констрейны задают, к каким путям эти критерии применять.

Тогда уж более очевидный тестовый проект, как я предлагал:

И посмотреть сразу в виде схемы после PAR, так будет надёжнее, чем по косвенным признакам оценивать, как же это легло.

Набросал код. 16 триггеров, у каждого 4-х входовое И.

РТЛ:
Нажмите для просмотра прикрепленного файла

Компиляция:
Нажмите для просмотра прикрепленного файла
Как видим, теперь вход EN используется.

Однако, Ква триггеры разметал по всему кристаллу:
Нажмите для просмотра прикрепленного файла
Такие пироги.

Пользуясь случаем, хочу спросить. Почему синтезатор не даёт использовать generate внутри always-а?
Если generate разворачивается в набор строчек, то какая ему разница где их разворачивать?

И ещё, пытался этот код написать без generate-а, вот так:
Ругается вот на это &D[i*4+3:i*4], говорит, что i - не константа. Собака такой.

generate можно за always вынести, смысл такой же останется.

Через цикл так надо писать:

Он у меня и так вынесен. Почему его туда занести нельзя - вот в чём вопрос.

Стандарт языка не позволяет. Се ля ви.

Вы мне так и не подсказали, как получить такую схему после разводки в Квартусе (коллеге надо, квартус 9.0, плисина FLEX10K), т.е. что куда нажать, чтобы вывело? Заранее спасибо.

По теме: ну и что, что "Ква триггеры разметал по всему кристаллу"? ))) Главное CE задействовал же.

Сначала жмете Chip Planner, потом на нужном логическом элементе шлепаете два раза мышкой, включится Resource Property Editor. Только для FLEX, ACEX такого нет, помнится.
Разметал по кристаллу - чтобы кристал нагревался равномерно.

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