Перейти к содержанию

    

Aleх

Участник
  • Публикаций

    7
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Посетители профиля

Блок последних пользователей отключён и не показывается другим пользователям.

  1. Польза подобных проверок действительно под сомнением. Но если уж хочется покодить, то очень полезно, к примеру, организовать работу со списками файлов и дефайнов: чтобы по одному списку файлов с синтезируемым кодом запускать симуляцию, и по тому же списку - синтез (компиляцию/элаборацию). Очевидно, что для симуляции нужен третий список - верилог моделей (модели нельзя мешать с синтезируемым кодом), а для синтеза - аналогичный список либерти моделей. Работа со списками позволит гарантировать, что на синтез передан тот же самый код, что был проверен в симуляции. Это позволит избежать множества ошибок.
  2. Выскажу распространенное (среди знакомых коллег) мнение: ситуация в Элвисе такова, что компетенция (нового молодого) руководства сильно ниже компетенции инженеров, поэтому любой новый профессионал рассматривается как конкурент - в первую очередь. Т.е. возьмут туда сейчас либо зеленых студентов, либо людей с нулевыми амбициями, хотя ищут профессионалов, вроде бы. Это нездоровая ситуация, но - что есть
  3. - все тулы не купишь. Спайглас хорошо, но своих денег не стоит. Любой физдизайнер выявит все проблемы на первом синтезе. - симулировать необходимо ровно те же корнеры, что являются mandatory для STA SignOff. Их бывает до двух десятков. Как уже писал, STA не заменяет, а дополняет симуляцию, это касается и корнеров. - оценка потребления на синтезе имеет точность +/-50%, по очевидным причинам. И никогда не сравнится с анализом post-CTS базы с реальным вектором из симуляции. Векторная оценка потребления - обязательна уже на 65нм.
  4. Статический (STA) и временной (timing simulation) анализ, это два близких подхода, имеющие как пересечения, так и эксклюзивные области. В чем эксклюзив временной верификации - выявляет ошибки в констрейнтах интерфейсов, и ошибки в коде - там, где есть CDC. Т.е. покрытие у тестов дожно быть в областях CDC и интерфейсов, причем один набор тестов для проверок setup, второй для Hold. Cимуляцию надо пускать сразу после CTS, с исправленным холдами - выявление багов на раннем этапе. Ну и пост-лейаут симуляция, разумеется. Так что STA отнюдь не достаточно для timing SignOFF.
  5. Периодически наблюдаю SV в присылаемом коде. Тулы нормально сьедают. Интерфейсы SV флатуются при синтезе, поскольку нетлист - это обычный верилог, не SV. Верификаторам очень больно дебажить результат (изза флатования). Моя позиция такова: выбор SV вместо верилога - смещает риски к концу проекта. С точки зрения менеджмента, это не разумно. Поэтому, лучше писать на верилоге: меньше потом дебажить и меньше риск переноса дедлайнов.
  6. Промоделируйте арку на спайсе (можно использовать выписку спайсдека в темпусе), убедитесь что тайминг соотвествует либе. Потом запустите либерейт в режиме дебага (когда спайсдеки сохраняются на диск), промоделируйте эти спайсдеки. Сравните результат.
  7. И все же, плисоводы должны знать о DFT, поскольку: для DFT необходим отдельный интерфейс микросхемы, который надо учитывать еще на этапе разработки RTL и печатных плат-прототипов. В модели необходимо предусмотреть дополнительные пады, или добавить интерфейс скана к имеющимся падам (как вторая функция). Кроме того, отдельной частью DFT является boundary scan вместе с JTAG - это можно имплементировать и отлаживать в FPGA. Можно соорудить свой MBIST и отладить в FPGA. На самом деле, идея конверсии FPGA->ASIC крайне ущербна, поскольку такие вещи как домены питания, режимы тестирования и исправления ошибок в памяти, использование отдельных макроблоков, таких как PHY интерфейсов, и т.д. - на FPGA не отладишь. А значит, подобная конверсия имеет смысл только для старых процессов 180нм и выше. На более тонких процессах имеет смысл просто заказывать бэкэнд, поскольку у результата, вероятнее всего, будут сильно другие характеристики, чем были в FPGA. Хотя бы просто потому, что дерево клока в FPGA зафиксировано, а в эсике его можно реализовать как угодно.