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

    

Aleх

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

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

  • Посещение

Репутация

0 Обычный

Информация о Aleх

  • Звание
    Участник

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

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

  1. Ошибка, про которую Вы пишете, относится к расстоянию между металлами (конфликт со страйпом как я понял), поэтому к плейсу это может иметь отношение лишь косвенно. Скорее всего у Вас страйпы сделаны так, что роутинг по соседним трекам приводит к указанной ошибке, а плейс вообще не причем. Чтобы этого избежать, тщательно планируйте шаг, ширину страйпов, и оффсет. Шаг страйпа должен быть кратен размеру трека, а оффсет и ширина должны быть такие, чтобы стандартный роутинг по соседним трекам получался не ближе, чем указано в руле ParallelRunLenght Spacing. Не надо провоцировать тул делать нарушения )
  2. А вы туда веллтапы с филлерами просто наставьте скриптом. Больше веллтапов - меньше ликедж, да и все равно место не используете. А вообще, все размещают селлы под питанием, без проблем. Поднимайте сетку повыше, высчитывайте треки, чтобы разводке не мешать, и все будет гуд.
  3. Я примерно раза два в год с таким сталкиваюсь, приносят код, в котором синтезатор находит малтидрайв неты. Обычно поиск этого малтидрайва проходит очень болезненно (выглядит со стороны). И в очень редких случаях малтидрайв действительно нужен. К примеру, мультиплексор 32х1 гораздо быстрее работает на трибуфах, чем с полным дешифратором состояний на комбинационной логике. Или, иногда блоки памяти имеют тристейт выходы (тот же мультиплексор). Это очень не рядовые ситуации.
  4. Много драйверов одной цепи - не ошибка, такое делают, к примеру, в тристейт-шинах. Тулы синтеза обычно выдают ворнинг на такие цепи, а симулятор показывает то, что подсовывают модели: к примеру, логический ноль, единицу, третье состояние, или подтяжку (если есть в модели), либо - Х если один драйвер с нулем а второй с единицей. ПЛИС обычно не имеют внутри тристейт-драйверов, поэтому почти всегда выдаст ошибку синтеза. Другими словами, если Вы допустили ошибку, но имеете тесты со 100% покрытием, то в этой цепи в одном из тестов будет Х, ошибка ловится. Либо, проще, попробовать засунуть в ПЛИС.
  5. Поддерживаю, designware - отличная штука. Если подходит под задачу :-) На мой взгляд, такие вещи надо руками вписывать в код, прямо вызовы инстансов. Для их симуляции есть верилог-модельки, которые, кажется, даже синтезируемые (можно в ПЛИС запихнуть). Большой дешифратор можно разбить руками, уменьшив разрядность, вставить флопы, использовать в коде pragma вроде full_case parallel_case.
  6. Ретайминг сам не добавляет стадии в конвейер, их может добавить только инженер. Тул способен лишь перетрясти логику в стадиях. В этом плане летенси конвейера остается без изменений, как и состояния автоматов в дизайне. Поэтому я и писал - чтобы исполнить хотелку ТС номер 2, надо руками дорисовать третью стадию (флоп) в конвейер (добавить в код), и разрешить ретайминг в синтезаторе.
  7. Мне казалось что второй квартус вообще не поддерживает 10к. Емнип последняя верия - первый квартус ~9 или 7 версии. Ну и конечно максплюс. Я бы посмотрел на разьемы платы, может у вас интерфейс не с плис, а с флешкой. А в остальном да, как советовали - дебаг цепочки житаг, чтение айди кода, тест на разрыв петли, и если ничего не помогло - осциллограф. Путать 3 и 5 вольт ооочень плохо, помню что байтбластеры от такого горели толь в путь. Может и ваш уже труп. Его в первую очередь проверьте
  8. Интересное утверждение, не согласен. Как триггер может сломать логику, обьясните. Добавление стадий в конвейер должно отразиться только на лэтенси (в тактах), но никак не на функции. Если функция таки изменилась, это ошибка работы тула(вполне вероятный сценарий), которая ловится прогоном LEC, я об этом писал.LEC вообще обязательная процедура после ретайминга, если в коде присутствуют fsm, умножения через * и прочие вещи, которые синтезатор может исполнить неоднозначно.
  9. Называется ретайминг. Работает, к примеру, так - на выход комбинационной схемы ставите несколько последовательно включенных флопов, разрешаете ретайминг, зажимаете частоту и запускаете синтез. В результате, флопы переместятся по логике влево - ровно на столько, чтобы обеспечить fmax. Разумеется, число регистров изменится, поскольку ширина комбинационной схемы в разных разрезах разная. В реальных проектах это не используется, поскольку метод ну очень топорный. Грамотный инженер сам разместит флопы там где они нужны. Но для пристрелки/оценки метод вполне годится. Не забывайте запускать LEC, поскольку тул изредка сбивается во время ретайминга, и результат может отличаться от исходника.
  10. Польза подобных проверок действительно под сомнением. Но если уж хочется покодить, то очень полезно, к примеру, организовать работу со списками файлов и дефайнов: чтобы по одному списку файлов с синтезируемым кодом запускать симуляцию, и по тому же списку - синтез (компиляцию/элаборацию). Очевидно, что для симуляции нужен третий список - верилог моделей (модели нельзя мешать с синтезируемым кодом), а для синтеза - аналогичный список либерти моделей. Работа со списками позволит гарантировать, что на синтез передан тот же самый код, что был проверен в симуляции. Это позволит избежать множества ошибок.
  11. Выскажу распространенное (среди знакомых коллег) мнение: ситуация в Элвисе такова, что компетенция (нового молодого) руководства сильно ниже компетенции инженеров, поэтому любой новый профессионал рассматривается как конкурент - в первую очередь. Т.е. возьмут туда сейчас либо зеленых студентов, либо людей с нулевыми амбициями, хотя ищут профессионалов, вроде бы. Это нездоровая ситуация, но - что есть
  12. - все тулы не купишь. Спайглас хорошо, но своих денег не стоит. Любой физдизайнер выявит все проблемы на первом синтезе. - симулировать необходимо ровно те же корнеры, что являются mandatory для STA SignOff. Их бывает до двух десятков. Как уже писал, STA не заменяет, а дополняет симуляцию, это касается и корнеров. - оценка потребления на синтезе имеет точность +/-50%, по очевидным причинам. И никогда не сравнится с анализом post-CTS базы с реальным вектором из симуляции. Векторная оценка потребления - обязательна уже на 65нм.
  13. Статический (STA) и временной (timing simulation) анализ, это два близких подхода, имеющие как пересечения, так и эксклюзивные области. В чем эксклюзив временной верификации - выявляет ошибки в констрейнтах интерфейсов, и ошибки в коде - там, где есть CDC. Т.е. покрытие у тестов дожно быть в областях CDC и интерфейсов, причем один набор тестов для проверок setup, второй для Hold. Cимуляцию надо пускать сразу после CTS, с исправленным холдами - выявление багов на раннем этапе. Ну и пост-лейаут симуляция, разумеется. Так что STA отнюдь не достаточно для timing SignOFF.
  14. Периодически наблюдаю SV в присылаемом коде. Тулы нормально сьедают. Интерфейсы SV флатуются при синтезе, поскольку нетлист - это обычный верилог, не SV. Верификаторам очень больно дебажить результат (изза флатования). Моя позиция такова: выбор SV вместо верилога - смещает риски к концу проекта. С точки зрения менеджмента, это не разумно. Поэтому, лучше писать на верилоге: меньше потом дебажить и меньше риск переноса дедлайнов.
  15. Промоделируйте арку на спайсе (можно использовать выписку спайсдека в темпусе), убедитесь что тайминг соотвествует либе. Потом запустите либерейт в режиме дебага (когда спайсдеки сохраняются на диск), промоделируйте эти спайсдеки. Сравните результат.