|
Многое уже было правильно написано выше.
Для собственного спокойствия и удовлетворения начальства : ) рекомендуется проводить симуляцию gate-level netlist-ов.
Позволяет
* адекватно оценить на желаемых тестах качественность latency, skew клоковых деревьев и деревьев сброса;
* убедиться, что все триггеры, нуждающиеся в сете/ресете, его действительно имеют - посмотреть на отсечение X-ов через мультиплексоры в схеме после синтеза;
* убедиться в максимальной частоте не только на этапе STA в топологии (например, неправильно описаны propagated clock, multicycle_path, false_path, ...). Если существуют специальным образом выравниваемые тракты данных - позволяет удостовериться, что в backend поняли и сделали всё правильно;
* убедиться в качественности/полноте требуемых у backend ограничений;
* позволяет оценить, что для всех углов процесс/температура/питание требования по setup, hold выполняются. Чем глубже технология, тем больше таких углов->вариантов задержек для схемы;
* вроде при проектировании с low-power методологией есть необходимость моделирования некоторых моментов;
* способствует общению моделировщиков с бэкэндерами, что всегда полезно и синергетично;
* для нормального анализа мощности и просадок питания (IR-drop) схемы очень неплохо предоставить backend-у данные по переключениям конкретной имплементации (VCD).
Вообще говоря, качественный STA + формальная верификация RTL против топологического нетлиста дает достаточно уверенности, что всё сделано правильно.
Слышал, что китайцы в погоне за сроками выхода очередной кальки не могут себе позволить роскоши моделировать нетлисты с задержками, ограничиваются STA + FV.
|
Временная верификация и статический анализ, частота и причины использования первой
May 28 2010, 02:45
