Никто не работал с characterize для design compiler. Есть желание поиграться со bottom-up стратегией для синтеза при помощи characterize блоков нижнего уровня. А именно:
*** первоначальный синтез -> характеризация -> пост синтез с новыми констрейнами.
- для первоначального синтеза sub-blocks какие констрейны выбрать, наиболее ближние (что логично) или что-то еще;
- каким образом проходит характеризация, если мы просто собираем нетлист саб-блоков и код топ уровня (включая констрейны топа), то у топ уровня еще нет таймингов, только базовые ячейки;
- как лучше вывести и повторно использовать значения после characterize, поскольку на выходе много каши из виртуальных клоков и входные/выходные задержки выше чем тактовый сигнал (что-то где-то не так).

Мануала на это катастрофически мало, точнее его там просто нет, только простейшее описание. Создавать топик у синопсиса пока нет желания, поскольку думаю есть недопонимание на базовом уровне.

Да все эту функцию используют, любой мало-мальский SoC удобнее синтезировать bottom-up, особенно когда еще меняется RTL. Другое дело, что в некоторых случаях проще констрейнты на блок руками написать, чем использовать characterize.

А маршрут очень простой: загружаете RTL всего проекта, накладываете констрейнты, потом characterize, а потом write_sdc. И еще полезно слегка поджать то, что выпишется в sdc. Затем синтезируете каждый блок отдельно (можно даже сделать layout) и потом выписываете .lib/.db И, наконец, грузите RTL верхнего уровня + .db на блоки и пускаете синтез. Для отладки скриптов рекомендую потренироваться на кошечках: взять, к примеру, процессор из DC/DV-туториала, и синтезнуть его поблочно.

Руками проще, но когда портов много затруднительно по всем писать, тем более если порты многобитовые (не все биты имеют одинаковый констрейн).

т.е. characterize на загруженный код + elaborate -> вывод sdf.
Насколько я читал, там используется уже готовый нетлист блков нижнего уровня, потом их ресинтез и далее синтез топа.

Не sdf, а sdc
Нетлист блоков получать не обязательно, достаточно просто RTL загрузить.
И, как уже писал, очень желательно потом руками пожать в выписанных констрейнтах запас по интерфейсам. Удобно это делать скриптом, к примеру на perl - ужимать все на 10-15%, скажем.

Попробуйте
set_top_implementation_options -block_references ...
Или
create_block_abstraction
Особенно хорошо, если используете топо режим.

Cинтез только до pre-netlist. Далее уже другие работают.

Каким образом DC определяет констрейны если это только начальная стадия. Причем для части блоков нижнего уровня необходимо еще и перейти на микс из RVT/LVT, а по таймингам они значительно отличаются.

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

В блоки обычно выделяются модули иерархии с унифицированными интерфейсами - APB/AHB/AXI и т.д. Подразумевается, что нагрузка на эти интерфейсы небольшая, и для них можно писать констрейнты с некоторым запасом. Запас потом съедается при сборке верхнего уровня.
Если же в блок выделен модуль, у которого интерфейс и так перегружен (о чем косвенно свидетельствуют большие input/output delay после характеризации), то ничего хорошего Вы не получите, тайминг будет только хуже. Т.е. самая критичная по таймингу часть должна оставаться внутри блоков, наружу ее выносить - себе дороже.