нет совсем там всё так. человек немного упрощает то, что творится в
плисине. вот раздел Resource Sharing, и вижу что там сильное упрощение. во всех модулях этого раздела на входе - трёхвходовый сигнал i_data, и максимум двухвходовый сигнал i_sel. выход однопроводной, и асинхронный. соотвественно, выход это тупо логическое выражение от пяти однобитовых переменных - и всё это банально превращается в один шестивходовый LUT6 у спартана-6. всё, все эти растекания мыслью по древу про сумматоры и мультиплексоры и прочие задержки в данном конкретном случае идут нафик. ресурс шаринг про жирные сигналы и про те случаи, когда редкий ресурс (цепи переноса) используется повторно, но зато втыкается больше мультиплексоров. то есть размен скорости на объём.
в разделе про retiming "забывают", что на входе данные тоже не сразу с триггеров могут идти, а с комбинаторной логики, и в таком случае ретайминг может сделать ещё и хуже.
ну и да, все эти проблемы возникают по большей части при большой заполненности кристалла.
я пока что по своим проектам вижу, что у меня триггеров используется меньше чем логики рядом с ними, поэтому я просто не стесняюсь втыкать новые триггерные прослойки, там где это необходимо.
если проект компактный, а выбор чипа определяется количеством выводов - то просто пиши синхронный дизайн, да не плоди много комбинаторной логики вместе, и будет тебе счастие.
Mahagam (13.11.2021 20:56, просмотров: 476) ответил Evgeny_CD на Хабр. Супер статья. Стратегии оптимизации HDL-кода и синтезатора
нетлиста для FPGA