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

Немного не корректно. В случае использования 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.
А потом посмотрите быстродействие для обоих вариантов.