[CaPpuCcino 0]

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

если используется, то в каких случаях?

спб!

[oratie 0]

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

 

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

[yes 5]

наш посредник (делают бэк-енд)

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

 

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

 

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

 

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

 

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

 

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

ну а вообще - если стоимость бага несколько лимонов баксов - почему бы не просимулировать?

[masics 0]

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

[CaPpuCcino 0]

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

[dvladim 0]

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

 

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

[CaPpuCcino 0]

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

 

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

спасибо, человеческий фактор мне как-то в голову не приходил.

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

[dvladim 0]

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

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

А сигналы в RTL ровно такие же 4-х уровневые.

[sleep 0]

Многое уже было правильно написано выше.

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

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

[vitus_strom 0]

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

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

[sleep 0]

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

Мне кажется, что в реалиях наших дизайн-центров стоимость провала/ограничения функционала чипа из-за недосмотра/недостатка опыта при STA+формальной верификации намного выше,

чем +неделя на прогон тестов на gate-level netlist. Кроме того, запуски нескольких таких тестов можно делать в параллель.

afaik минимум 2-3 дизайн-центра в Мск+Питере, делающих реальные чипы в кремнии, используют симуляцию на netlist.

[vitus_strom 0]

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

[yes 5]

под человеческим фактором я бы подразумевал не возможность допустить ошибку, а нежелание рисковать, хотя это почти одно и то же

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

 

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

 

 

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

 

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

[vitus_strom 0]

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

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