Читаю Recommended HDL Coding Styles по ссылке http://www.altera.com/literature/hb/qts/qts_qii51007.pdf. Написано там примерно следующее (раздел multiplexers): если имеем длинное дерево if - else if - else if - else if, то рекомендуется попробовать перекодировать условия так, чтоб получить мультиплексоры 4-1 - это существенно может сэкономить ресурсы fpga. Даже пример приведен, показывающий уменьшение задействованных ресурсов на 20% (стр. 6-68). Вот у меня вопрос возник: для небольшого примера все примерно понятно, а как обстоит дело при разработке реальных проектов? Насколько критична такая оптимизация? Понятно, что дерево условий стараются разработать минимальной длинны (так ведь?), но занимаются ли разработчики перекодированием? В ручную-то делать - не самое быстрое и веселое занятие. Может, есть какой-то софт для подобных вещей? Вообщем, интересует мнение опытных людей по данному вопросу.

софт есть: называется он - синтезатор..
ИМХО, для того чтобы он бы эффективным, необходимо стараться:
а) стараться по возможности уходить от вентильного описания к поведенческому где это возможно (дабы дать синтезатору свободу для творчества - возможность оптимальной имплементации схемы в заданный элементный базис)
б) не забывать про прагмы, например для того же case есть всяческие full_case, parallel_case для того чтобы донести синтезатору информацию о том, чего же мы таки хотим от него (в SV помоему еще больше - и распрастраняется и на if|else) - пользоваться ими где это уместно/необходимо.

Либо я не очень понимаю, что есть поведенческое описание, либо мой вопрос как раз к нему и относится. Приведу пример:

Тогда мы имеем такую картинку (направо true, налево false, цифры в скобках понадобятся дальше):

т.е. имеем проверку 4 условий.
Альтера предлагает сделать так:

и утверждает, что в этом случае будет существенная экономия ресурсов. Вот мне и интересно - кодирует ли кто-нить вот так x и y? Или оно того не стоит/синтезатор справляется?

PS: Перечитал мануал. Там в начале раздела есть ссылка, что квартус и сам справляется с задачей, но для лучшего понимания... и далее идет рассказ о перекодировании условий. Но все равно, зато чему-то новому научился.

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

Когда корпуса были большими, а объемы логики в них маленькими :-) я пробовал заниматься рационализацией логики на уровне элементарных функций. Для MAX7128S максимальный выйгрыш был 1-2 ячейки при полной загрузке, а то и вовсе было незаметно.
По собственному опыту могу сказать, что гораздо важнее последовательность "срабатывания" функций, на которые заведены быстрые сигналы, реализуемые по некой временной диаграмме.
Простейший пример:
IF not(CS) then -- если есть выбор кристалла
IF ADR[]==devADR[] then -- если совпадает адрес
IF not(RD) then outEN=VCC -- если команда чтения, то...
и запись
outEN=not(CS) & (ADR[]==devADR[]) & not(RD);
должны выполняться с разной скоростью, причём первый вариант вроде как быстрее. Однако, на практике они часто один в один совпадают :-)

ага вот это действительно может быть значимо (правда в СВ это уже не прагмы а ключевые слова - unique и priority): в некоторых ситуациях последнее действительно может давать более сложную логику