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

    

Aleх

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

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

  • Посещение

Весь контент Aleх


  1. set_data_check работает только с сигналами, приходящими на входы одного селла. По сути, это такое же выравнивание, как если бы один сигнал считался клоком, а второй данными (тип проверки - сетап и холд). Для выравнивания задержек этот констрейнт подходит плохо, особенно если выравнивать приходится сигналы в разных путях reg2reg (по сути - в шине). Лучше вообще избегать таких схеме; классика жанра - одиночные сигналы синхронизовать через 2(3) флопа, а массив данных - через двупортовую память, в которой индекс передается в коде грея. Пробрасывать же целую шину в асинхронный домен -моветон. Но если очень надо, то начинать надо с деревьев: все передающие флопы должны иметь одинаковое летенси (одна скью группа домена А), так же и принимающие флопы - одна скью группа домена В. Обязательное условие - отсутствие любой логики (логика в CDC переходе - моветон в квадрате, могу обьяснить почему). Таким образом, останется только выровнять задержки, что можно сделать просто разбив приграничные флопы на пары (флоп доменаА + флоп домена В), и ставя флопы каждой пары физически рядом (или попытать set_max_delay, уповая что тул сам все расставит правильно). В результате, неровность задержек будет только за счет перекоса деревьев - незначительно гулять по температуре и питанию. Как сделать лучше, я не знаю. Но, повторюсь, лучше вообще избегать подобных CDC решений.
  2. Чем меньше паразитная емкость между стадиями сдвигового регистра-пересинхронизатора, тем ниже вероятность получить метастабильное состояние. Поэтому желание поставить такие флопы рядом понятно, и тем более понятно, почему делают специальные селлы для пересинхронизации. Если же спец. селлов нет, и малтибит селлов нет, то проще всего сдвигать эти флопы в кучу сразу после плейса, и назначать им статус fixed. Или же сдвигать их после каждой оптимизации. Двигать можно руками, но проще заскриптовать через ECO команды. Еще, можно сделать свой селл-синхронизатор в том же инновусе, выписать либу или ILM-модель, а потом использовать в дизайне как иерархический блок. Либо, попробовать объединять флопы в SDP структуры. Но я так никогда не заморачивался.
  3. Так а в чем вопрос то? Если действительно имеет место быть малтисайкл, то все хорошо: сетап уже выполняется, как видно из репорта, а по холду буфера будут стоять перед вилкой на регистр flag. Если же в логике схемы нет малтисайкла, то слэк совсем небольшой - его исправит дерево. К слову, дерево ведь можно сэмулировать в синтезе, через констрейнт set_clock_latency: если наложить его на тактовые входы регистра data, то отрицательный слэк можно убрать, а мощности элементов расслабить. Позже этот констрейнт будет учтен во время CTS. Проблем нет, вроде, все хорошо
  4. Судя по описанию, был такой девайс Xilinx download, который и поддерживался джэм-плейером. Скорее всего это что то очень старое под LPT или RS232
  5. А где здесь генерейтед клок? На схеме все три флопа работают на одном клоке. В тайминг репорте показан путь от регистра до регистра. Генерейтед клока нигде не наблюдаю, все на одном клоке
  6. Синтезатор все верно сделал, если использован констрейнт multicycle 4. Этот констрейнт накладывает лимит по сетапу 4 такта, а по холду 3 такта. Вот у Вас синтезатор и вытянул (попытался) эти 3 такта по холду, напихав лишних задержек в виде дополнительной логики. Подумайте, нужен ли Вам здесь малтисайкл. Констрейнты не обязаны повторять особенности интерфейса, они предназначены для временных ограничений, задавать которые можно разными способами. Если логики по входу мало, то лучше малтисайкл не использовать. Малтисайкл вообще лучше не использовать, т.к. он привязывает дизайн к фиксированой частоте. Т.е. дизайн без малтисайкла будет работать на частоте от 0 до Fmax, а с малтисайклом только в небольшом окне частот вблизи Fmax. Зависит от задачи, конечно. В некоторых случаях без малтисайкла никак. Но недостатки такого решения надо знать.
  7. Ну что же, Вам попался очень сложный вариант. Сложнее бывает только, когда цвета добавляются У Вас второй металл случайно не горизонтальный? Если так, то обычно рекомендуют дублировать фоллоупин во втором металле - об этом должны писать в доке черным по белому. В этом случае страйпы присоединяются ко второму металлу - без конфликтов, а соединения фоллоупинов между М1 и М2 производится регулярным массивом виа. Лучше об этом читать в доке. Если доки нет, лучше спросить саппорт, как это сделать. Если же второй металл вертикальный .. тогда единственный вариант - заставить роутер автоматически кромсать малтикат виа в местах конфликтов. Т.е., к примеру, на Вашем скрине 4х малтикат виа должна быть разбита на 1х и 2х виа, с пропуском в том месте, где возникает конфликт. Т.е. в месте, где удалена виа, конфликта уже нет. Но, и я об этом уже писал, в таком случае обязателен анализ айэр-дроп в конце, чтобы убедиться, что роутер не выкрошил слишком много переходных. Бывает, что выносятся целые области, где из-за отсутствия соединений сетки возникает большая просадка напряжения.
  8. Виа, это обьект в трех слоях: два металла, и переходное между ними. Соответственно, сочетания нескольких размеров и формы переходных отверстий + нескольких вариантов полигонов металлов - дают огромное число вариантов виа (не считая малтикат). В частности, для сетки питания часто используют ортогональные виа, у которых ширина обоих металлов равна ширине переходного, а переходное - квадратного сечения, а не прямоугольник. Если на Вашем скрине поставить такую виа, то расстояние до пина селла станет намного больше, а ошибка уйдет скорее всего. Подобные рекомендации (тип виа) должны содержаться в мануалах на библиотеку селлов, как уже писал. Если их нет .. значит подбирайте сами, чтобы не было конфликтов. Либо действительно не ставьте селлы под страйпами. Но это дорогое решение, на мой взгляд - площадь пропадает. p.s. если же вернуться к изначальному вопросу топика, то поскольку расстановку страйпов я всегда скриптую, и в скрипт включаю формулы расчета шага, оффсета и ширины, то я бы в тот же скрипт заложил и create placement blockage по форме страйпов.
  9. Привет! Проблема известная - чем меньше нанометры, тем сложнее делать сетку питания. С 28нм не работал, но почти наверняка Вы используете неправильные виа. Должны быть более узкие, чтобы не было конфликтов с пинами селлов. Советую внимательно почитать гайд производителя селлов (если это не tsmc), раздел сетки питания - там должны подробно описать, какими виа надо подсоединять сетку к первому металлу, с каким шагом их ставить, каким отступом и т.д. Есть небольшая вероятность, что виа все же правильные. В этом случае роутер (при определенных настройках, которые я так не вспомню) может кромсать малтикат виа сетки питания в местах конфликтов. Т.е. в результате , после роута, сетка получится рваная, и надо будет обязательно делать пауер анализ (ай-эр дроп). На финфетах рваная сетка - вообще обычное дело.
  10. MickeyMouse Судя по скрину, проблема не в страйпе, поскольку страйп находится в металле 5, а пин в металле 2 - они не могут конфликтовать, поскольку в разных слоях. Кстати, а где находится ошибка? Запостите текст ошибки. Скорее всего, проблема в металле 2 между пином и объектом, которого нет на скрине. Алгоритм действий - читаете описание ошибки, особенно - в каком она металле, а потом выводите все объекты в этом металле. К примеру, для ошибки в М2 это: смежные виа (V12, V23), сам М2: пины и блокеджи селлов (включить всю группу), вся группа роутинга (земли, питания, сигналы, аналог и т.д.). Остальные металлы - выключите. Как результат - DRC маркер должен быть между двумя объектами. А у Вас на скрине маркер - не между, а сбоку. Т.е. не хватает обьектов.
  11. Я сталкивался с тем, что в теч. лефе некорректно прописаны треки. Если процесс новый, это вероятно, а если старый, то сомневаюсь - сотни кастомеров до Вас уже выявили все баги. Но если хочется, то треки можно генерить вручную, под себя. Самое главное - чтобы треки проходили через центры пинов селлов (с учетом направления металла). Т.е. к примеру, если пины селлов в М1, и М2 вертикальный, то треки М1 должны проходить четко через пин, и должно быть пересечение с треком М2, где тул будет ставить переходное при контакте с пином. Если все это соблюдается, значит треки -ок. Далее, касательно ошибки. Разберитесь, как так вышло, измерьте линейкой - действительно ли есть нарушение. Все зазоры металлов есть в доке DRM в таблицах, надите это место ParallelRunLength spacing для данного металла. Если страйп наложен с запасом - отступом от трека, то нарушения не должно быть. Исключение - если тул вдруг начал роутить не по треку. Если так, то надо разбираться с какого перепугу роутер перестал соблюдать треки - баг это или фича. Еще возможно, что тул использовал другую, не стандартную, ширину вайра. Тогда просто еще увеличьте отступ страйпа от трека. Т.е. в условиях, когда все роутится по трекам, стандартной шириной вайра, и соблюден отступ - нарушению не откуда взяться. p.s. как смотреть отступы страйпа - оставьте только один металл, включите треки, а потом посмотрите отступы от страйпа до соседних треков, причем в нескольких местах - бывает что один страйп правильный, а соседний со сдвигом, поскольку шаг страйпа был не кратен питчу. Или, с одной стороны зазор ок, а с другой с нарушением.
  12. Видимо, подстройка происходит при работе через меню, поскольку у консольного AddStripe я автоподстройки не наблюдал. В консоли сколько укажешь, так тул и сделает, с заданной точностью. Гайда не знаю, но это совершенно логично, делать привязку к трекам. Ведь треки и придуманы для роутера. И если Вы заложили дистанцию от края страйпа до ближайшего трека (за вычетом половины ширины вайра) больше чем ParallelRunLength, то виолейшн не образуется. Итого, если работаете чем через gui, то попробуйте консольные команды, там больше возможностей. Может и проблему свою вылечите.
  13. Ошибка, про которую Вы пишете, относится к расстоянию между металлами (конфликт со страйпом как я понял), поэтому к плейсу это может иметь отношение лишь косвенно. Скорее всего у Вас страйпы сделаны так, что роутинг по соседним трекам приводит к указанной ошибке, а плейс вообще не причем. Чтобы этого избежать, тщательно планируйте шаг, ширину страйпов, и оффсет. Шаг страйпа должен быть кратен размеру трека, а оффсет и ширина должны быть такие, чтобы стандартный роутинг по соседним трекам получался не ближе, чем указано в руле ParallelRunLenght Spacing. Не надо провоцировать тул делать нарушения )
  14. А вы туда веллтапы с филлерами просто наставьте скриптом. Больше веллтапов - меньше ликедж, да и все равно место не используете. А вообще, все размещают селлы под питанием, без проблем. Поднимайте сетку повыше, высчитывайте треки, чтобы разводке не мешать, и все будет гуд.
  15. Я примерно раза два в год с таким сталкиваюсь, приносят код, в котором синтезатор находит малтидрайв неты. Обычно поиск этого малтидрайва проходит очень болезненно (выглядит со стороны). И в очень редких случаях малтидрайв действительно нужен. К примеру, мультиплексор 32х1 гораздо быстрее работает на трибуфах, чем с полным дешифратором состояний на комбинационной логике. Или, иногда блоки памяти имеют тристейт выходы (тот же мультиплексор). Это очень не рядовые ситуации.
  16. Много драйверов одной цепи - не ошибка, такое делают, к примеру, в тристейт-шинах. Тулы синтеза обычно выдают ворнинг на такие цепи, а симулятор показывает то, что подсовывают модели: к примеру, логический ноль, единицу, третье состояние, или подтяжку (если есть в модели), либо - Х если один драйвер с нулем а второй с единицей. ПЛИС обычно не имеют внутри тристейт-драйверов, поэтому почти всегда выдаст ошибку синтеза. Другими словами, если Вы допустили ошибку, но имеете тесты со 100% покрытием, то в этой цепи в одном из тестов будет Х, ошибка ловится. Либо, проще, попробовать засунуть в ПЛИС.
  17. Поддерживаю, designware - отличная штука. Если подходит под задачу :-) На мой взгляд, такие вещи надо руками вписывать в код, прямо вызовы инстансов. Для их симуляции есть верилог-модельки, которые, кажется, даже синтезируемые (можно в ПЛИС запихнуть). Большой дешифратор можно разбить руками, уменьшив разрядность, вставить флопы, использовать в коде pragma вроде full_case parallel_case.
  18. Ретайминг сам не добавляет стадии в конвейер, их может добавить только инженер. Тул способен лишь перетрясти логику в стадиях. В этом плане летенси конвейера остается без изменений, как и состояния автоматов в дизайне. Поэтому я и писал - чтобы исполнить хотелку ТС номер 2, надо руками дорисовать третью стадию (флоп) в конвейер (добавить в код), и разрешить ретайминг в синтезаторе.
  19. Мне казалось что второй квартус вообще не поддерживает 10к. Емнип последняя верия - первый квартус ~9 или 7 версии. Ну и конечно максплюс. Я бы посмотрел на разьемы платы, может у вас интерфейс не с плис, а с флешкой. А в остальном да, как советовали - дебаг цепочки житаг, чтение айди кода, тест на разрыв петли, и если ничего не помогло - осциллограф. Путать 3 и 5 вольт ооочень плохо, помню что байтбластеры от такого горели толь в путь. Может и ваш уже труп. Его в первую очередь проверьте
  20. Интересное утверждение, не согласен. Как триггер может сломать логику, обьясните. Добавление стадий в конвейер должно отразиться только на лэтенси (в тактах), но никак не на функции. Если функция таки изменилась, это ошибка работы тула(вполне вероятный сценарий), которая ловится прогоном LEC, я об этом писал.LEC вообще обязательная процедура после ретайминга, если в коде присутствуют fsm, умножения через * и прочие вещи, которые синтезатор может исполнить неоднозначно.
  21. Называется ретайминг. Работает, к примеру, так - на выход комбинационной схемы ставите несколько последовательно включенных флопов, разрешаете ретайминг, зажимаете частоту и запускаете синтез. В результате, флопы переместятся по логике влево - ровно на столько, чтобы обеспечить fmax. Разумеется, число регистров изменится, поскольку ширина комбинационной схемы в разных разрезах разная. В реальных проектах это не используется, поскольку метод ну очень топорный. Грамотный инженер сам разместит флопы там где они нужны. Но для пристрелки/оценки метод вполне годится. Не забывайте запускать LEC, поскольку тул изредка сбивается во время ретайминга, и результат может отличаться от исходника.
  22. Польза подобных проверок действительно под сомнением. Но если уж хочется покодить, то очень полезно, к примеру, организовать работу со списками файлов и дефайнов: чтобы по одному списку файлов с синтезируемым кодом запускать симуляцию, и по тому же списку - синтез (компиляцию/элаборацию). Очевидно, что для симуляции нужен третий список - верилог моделей (модели нельзя мешать с синтезируемым кодом), а для синтеза - аналогичный список либерти моделей. Работа со списками позволит гарантировать, что на синтез передан тот же самый код, что был проверен в симуляции. Это позволит избежать множества ошибок.
  23. Выскажу распространенное (среди знакомых коллег) мнение: ситуация в Элвисе такова, что компетенция (нового молодого) руководства сильно ниже компетенции инженеров, поэтому любой новый профессионал рассматривается как конкурент - в первую очередь. Т.е. возьмут туда сейчас либо зеленых студентов, либо людей с нулевыми амбициями, хотя ищут профессионалов, вроде бы. Это нездоровая ситуация, но - что есть
  24. - все тулы не купишь. Спайглас хорошо, но своих денег не стоит. Любой физдизайнер выявит все проблемы на первом синтезе. - симулировать необходимо ровно те же корнеры, что являются mandatory для STA SignOff. Их бывает до двух десятков. Как уже писал, STA не заменяет, а дополняет симуляцию, это касается и корнеров. - оценка потребления на синтезе имеет точность +/-50%, по очевидным причинам. И никогда не сравнится с анализом post-CTS базы с реальным вектором из симуляции. Векторная оценка потребления - обязательна уже на 65нм.
  25. Статический (STA) и временной (timing simulation) анализ, это два близких подхода, имеющие как пересечения, так и эксклюзивные области. В чем эксклюзив временной верификации - выявляет ошибки в констрейнтах интерфейсов, и ошибки в коде - там, где есть CDC. Т.е. покрытие у тестов дожно быть в областях CDC и интерфейсов, причем один набор тестов для проверок setup, второй для Hold. Cимуляцию надо пускать сразу после CTS, с исправленным холдами - выявление багов на раннем этапе. Ну и пост-лейаут симуляция, разумеется. Так что STA отнюдь не достаточно для timing SignOFF.