Временная верификация и статический анализ, частота и причины использования первой Опции

[CaPpuCcino]

скажите, плз, используется ли не практике вообще и для синхронного дизайна в частности gate-level симуляция для временного анализа, или STA полностью вытеснил DTA?
если используется, то в каких случаях?
спб!

[oratie]

У нас в конторе, начиная с 0.35мкм уже не используем gate-level для тайминга. Только STA.

А gate-level + SDF используется (иногда) для функциональной верификации: бывает находятся ошибки невыявляемые при RTL моделировании (обычно в схемах где есть передачи между разными клоковскими доменами).

[yes]

наш посредник (делают бэк-енд)
настаивает на прохождении как можно большего объема тестов по различным "углам", то есть sdf-ов полно

технологии модные - 90нм, 40нм

--------------------

ну и вообще предполагается, что это необходимый этап - синопсисы при продвижении своего VCS-а напирают на его шустрости при симуляции gate-level

--------------------

в принципе я могу найти логические объяснения для нашего конкретного флоу,
ну а вообще - если стоимость бага несколько лимонов баксов - почему бы не просимулировать?

[masics]

Мы тоже гоняем симуляции (65nm). Слишком дорого баги исправлять, а прогнать симуляции - неделя или чуть больше.

[CaPpuCcino]

ребята, указывайте, пожалуйста ещё и причину, по которой отдаётся предпочтение динамической верификации. мне просто показалось по публикациям, что методы STA стали довольно продвинутыми. какие причины? финансовые, функциональные, внедренческие...

[dvladim]

Одно другого не отменяет. Даже если STA прошел, то это не значит что при написании констрейнов не ошиблись. Я думаю основная причина - человеческие ошибки.

У меня, например, был случай: в функциональном описании все работало, а в gate-level нет. Причиной было отсутствие сброса одного из регистров и в функциональном моделировании if давал false и все работало дальше, а в gate-level все разваливалось в X.

[CaPpuCcino]

Одно другого не отменяет. Даже если STA прошел, то это не значит что при написании констрейнов не ошиблись. Я думаю основная причина - человеческие ошибки.

У меня, например, был случай: в функциональном описании все работало, а в gate-level нет. Причиной было отсутствие сброса одного из регистров и в функциональном моделировании if давал false и все работало дальше, а в gate-level все разваливалось в X.

спасибо, человеческий фактор мне как-то в голову не приходил.
а с примером вы наверное немого ошиблись, всё-таки функциональное моделирование к STA относится также, как двухуровневый сигнал в вашем RTL описании, проинициализированный в начале симуляции 0, относится к 4-уровневому после синтеза, инициализированному симулятором в Х. не так ли?

[dvladim]

а с примером вы наверное немого ошиблись

Ну как сказать, вопрос был о том зачем использовать gate-level, если STA прошел. Вот такая ошибка и была бы пропущена.
А сигналы в RTL ровно такие же 4-х уровневые.

[sleep]

Многое уже было правильно написано выше.
Для собственного спокойствия и удовлетворения начальства : ) рекомендуется проводить симуляцию 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.

[CaPpuCcino]

гранд мерси! очень красиво всё сформулировано.

[vitus_strom]

Как и сказали выше формальная верификация + СТА заменяют гейт левел симуляцию (по слухам NXP так делает)
Походу гейтлевел пользуют в случае если не удалось косяк поймать предыдущими методами - очень затратно по времени ИМХО

[sleep]

Походу гейтлевел пользуют в случае если не удалось косяк поймать предыдущими методами - очень затратно по времени ИМХО

Мне кажется, что в реалиях наших дизайн-центров стоимость провала/ограничения функционала чипа из-за недосмотра/недостатка опыта при STA+формальной верификации намного выше,
чем +неделя на прогон тестов на gate-level netlist. Кроме того, запуски нескольких таких тестов можно делать в параллель.
afaik минимум 2-3 дизайн-центра в Мск+Питере, делающих реальные чипы в кремнии, используют симуляцию на netlist.

[vitus_strom]

У нас тоже нетлисты гоняют - но я говорил про nxp не знаю какой у вас объем микросхем - у нас на достаточно малые проекты, примено тоже неделя выходит - хуже когда несколько доменов питания.... сами понимаете что будет если начать гонять нетлист дизайна >1млн вентилей через разные корнеры напряжения и температуры и процесса - неделей никак не обойдешься

[yes]

под человеческим фактором я бы подразумевал не возможность допустить ошибку, а нежелание рисковать, хотя это почти одно и то же
то есть менеджер проекта говорит : мы сделали N успешных тэйпаутов и всегда пользовались симуляцией нетлиста, что теперь, когда подготовко к производству стоит еще дороже мы будем рисковать уйти на респин????? это диверсия

также для качественного STA и FV нужно иметь достаточно дорогие PT и formality (ну или аналоги), а симулятор по любому покупать

через разные корнеры напряжения и температуры и процесса - неделей никак не обойдешься

но тут осуществима мечта производителей процессоров и тулзов - процесс паралелится : при количестве лицензий == количеству корнеров все замечательно , но стоит денег...

[vitus_strom]

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