SDF для верификации, сколько штук?, RC, OCV, PVT, corners и т.п. Опции

[yes]

делаем первый 90нм проект

и в отличие от более "толстых" технологий предлагается симулировать для сайн-оффа не 3 варианта (для библиотек worst, typical, best), а гораздо больше
----цитата---------
Actually we have 36 SDF
files in total for your simulation. Along with 3 library corners you
mentioned, we have 3 RC corners and 4 I/O voltage combinations.

ну если с IO комбинациями вроде бы понятно: маленькое VCCIO - задержки большие

то остается 18 вариантов (2 I/O voltage).

проблема в том, что прогон для 3 SDF занимает у нас неделю.
6 недель (а если брать 36 SDF - то вообще 12) - неприемлемо большой срок

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

впринципе, конечно, есть представления, где будет вероятность на setup-ы нарваться, а где на hold-ы - то есть в этой табличке (RC/corners) 3x3 можно найти "реально" worst и best
но страшно

ес-сно STA и формальная верификация выполнены, но без симуляции как-то стремно...

==============

btw: для дип-субмикрона и библиотек не 3 corners, а 5 (+2 низкотемпературные - там какой-то inversion phenomena имеет место быть) но я особо не разбирался, так как нам эти режимы не нужны

[id_gene]

проблема в том, что прогон для 3 SDF занимает у нас неделю.

Кстати, а не слишком ли долго?
Симулятор какой? Проблема в тестах или в рабочих станциях?
Или в размере кристалла?
нетлист 60+ к триггеров, 1ns/100fs
На десктопе под win-хр НЦ у меня моделируется ~0.5 мс/час (что на атлоне 64Х2dual, что на core2duo 6400 на 2х гигах памяти).
2 процесса одновременно моделируются без проблем. На рабочих станциях быстрее.

[yes]

быстрее не получается

станции по 2 core2duo-шных (2 или 4 ядра) xeon-a (они раза в два быстрее AMD64x2 по-моим измерениям) по 32Гб на каждой (симуляционный снапшот 5-8Гб)
станции под линухом (что-то под редхатом/федорой, что-то под дебианом)
сильно считаю, что для нераспределенных задач это самое быстрое железо (причем на удивление дешевое)

тесты написаны не очень оптимально - оптимизировать их по покрытию (togglecount) не стали для уменьшения времени разработки, представляют собой куски реально работающего фирмваря (десятки ms)
правильно это или нет - отдельный вопрос

размер проекта весьма большой - почти квадратный сантиметр при 90нм

[Escorial]

быстрее не получается

станции по 2 core2duo-шных (2 или 4 ядра) xeon-a (они раза в два быстрее AMD64x2 по-моим измерениям) по 32Гб на каждой (симуляционный снапшот 5-8Гб)
станции под линухом (что-то под редхатом/федорой, что-то под дебианом)
сильно считаю, что для нераспределенных задач это самое быстрое железо (причем на удивление дешевое)

тесты написаны не очень оптимально - оптимизировать их по покрытию (togglecount) не стали для уменьшения времени разработки, представляют собой куски реально работающего фирмваря (десятки ms)
правильно это или нет - отдельный вопрос

размер проекта весьма большой - почти квадратный сантиметр при 90нм

Я согласен с grigorik - для уверенности проведите моделирование для 4х сочетаний BestTiming-BestRC, BestTiming-WorstRC, WorstTiming-BestRC, WorstTiming-WorstRC. Для всех остальных корнеров пользуйтесь STA. Должно хватить. Эти дополнительные корнеры просто позволяют убедиться в высоком выходе годных, т.е. даже если у вас будут нарушения в каком то сочетании - это еще не означает, что у вас не будет рабочих схем, просто выход годных будет меньше.

Если боитесь перезапуска то еще раз внимательно поглядите на все виды coverage RTL модели и постарайтесь добить его ближе к 100 процентам. Может быть, добавьте функциональный coverage в важные блоки, например полезно проверить производилась ли запись и чтение из всех регистров и т.д.

[grigorik]

Если боитесь перезапуска то еще раз внимательно поглядите на все виды coverage RTL модели и постарайтесь добить его ближе к 100 процентам. Может быть, добавьте функциональный coverage в важные блоки, например полезно проверить производилась ли запись и чтение из всех регистров и т.д.

Просто была упомянута coverage RTL есть ли у кого-то документация про это или знает где скочать заранее спасибо?

[Escorial]

Просто была упомянута coverage RTL есть ли у кого-то документация про это или знает где скочать заранее спасибо?

Начните с книжки WritingTestbenches for SystemVerilog. А дальше либо начинайте копать в сторону Functional Verification либо смотрите доки на САПРы. В Cadence это немного нетривиально устроено, т.к. симулятор и средство анализа покрытия разбиты на 2 продукта. В Mentor'e попроще, т.к. все интегрировано.

[grigorik]

Начните с книжки WritingTestbenches for SystemVerilog. А дальше либо начинайте копать в сторону Functional Verification либо смотрите доки на САПРы. В Cadence это немного нетривиально устроено, т.к. симулятор и средство анализа покрытия разбиты на 2 продукта. В Mentor'e попроще, т.к. все интегрировано.

спасибо

Сообщение отредактировал grigorik - Jan 23 2008, 10:46