Задержки получаются синтезатором, STA — это средство анализа.

STA специально не упоминал, в маршрут проектирования он должен входит, конечно же. Но он ближе к back-end, с ним специалисты по синтезу и физической имплементации должны обниматься, как и с инструментами анализа ограничений (constraints). Ну, на данный момент, такая моя точка зрения.

Большие блоки логики тоже покрываются тестами практически полностью, при наличии времени. В составе системы это трудно сделать, но отдельно блок можно «вытрясти». Все декомпозируется. Сложные системы тоже по частям проверяются.

Кстати, если совсем мутит от UVM, то можно посмотреть вот эту книгу для начала: Chris Spear, Greg Tumbush. SystemVerilog for Verification, там про методы неплохо написано. UVM только взял это все и обернул в библиотеку (большую такую библиотеку).

А что такое фаззинг по существу?
При функциональной верификации мы можем исказить любые сигналы. Тактовую частоту «покачать» по нестабильности фазы, частоты и пр. Это устройствам, которые с внешнего мира забирают сигналы в свой частотный домен, может помочь проверить блоки фильтрации и синхронизации.
Есть еще способы введения искажений в ОВ, т.е. можно случайным способом исказить состояние в модели и посмотреть как она «выкарабкается» из этого неловкого положения.

UVM штука хорошая, но неободимо применять обдумано. Там порой куча способов сделать одно и то же. Есть несколько ресурсов, вендров, которые приводят исходные коды, там бывают сильно разные подходы.
Беда еще в том, что сам по себе он очень криво документирован, вернее, документация есть, а вот смысл и взаимосвязи понять — это просто превращается в кошмар. По опыту могу сказать, что бывают моменты, когда в нем можно забуксовать по абсолютно ерундовой причине именно в попытках найти взаимосвязи и идею, которая закладывалась в конструкции. Т.е. разбираешься не с проблемой по существу, а сражаешься с инструментом, безумно жалко время при этом.
Но с другой стороны, если его использовать, он превращается в некоторый «язык» команды верификации. Т.е. тут надо либо внутри создавать свои библиотеки/инструменты (тут нужен опыт и ресурсы), либо использовать готовое.
У себя мы вводим его постепенно (лет 6 уже), осваивая те или иные необходимые конструкции по необходимости и полностью осознавая зачем оно нам, хотя изначально знали практически все его возможности.

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

По-хорошему, нужно всем, кто хоть как-то применяет «цифру» в проекте. Другой вопрос — какие инструменты применять. И тут уже начинаем балансировать между временем, ресурсами, затратами (стандартный набор как и везде). Цифровая схема хороша тем, что ее функционально можно проверить даже малейшие ее детали, но незначительная ошибка может привести к серьезным финансовым и временным затратам, а порой, к бессмысленности дальнейшего продолжения работ.

Я для начала хотел сделать немного вводных статей, что бы потом с опорой на них можно было бы объяснять примеры. Про рандомизацию и пр. согласен, полагаю, имеет смыс объяснить «на пальцах» некоторые принципы и дать отсылку на существующие материалы, для «расширения сознания». Правда, они все на английском.