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

    

Aleх

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

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

  • Посещение

Репутация

0 Обычный

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

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

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

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

  1. Бандари скан в основном нужен для теста паек на PCB, ну и для отладки. В микросхемах эту штуку очень часто делают, годов с 80х.
  2. Возможно, это зависит от вендора тула. У меня опыт синопсиса и кеденса. Синопсис требует пады, и делает проверку того, что вставил (может отругаться, к примеру, что на tdo стоит тип пада просто выход, а не тристейт, может на отсутствие пуллапа отругаться). У кеденса как обычно все либеральней, практически без проверки и с кучей багов, но и там спецификация требует наличия падов. А вот с ментором не работал. Впрочем, допускаю, что и без падов можно както баундари скан вставить, но не представляю как. Никогда так не делал.
  3. DFT в части баундари скан очень даже зависит от наличия падов. Тул из либы вычисляет функции портов пада, и окружает их соотв. тестовыми структурами. Конечно, можно и в слепую написать баундари спецификацию, но лучше все же иметь тайминг либы на пады, и генерить баундари структуры на автомате. На внутренний скан пады конечно же никак не влияют.
  4. Первое что приходит в голову - отдельно констрейните-синтезируете этот модуль, получаете нетлист, потом подгружаете его в большой проект, накладываете на этот модуль атрибут preserve=true, и пускаете синтез. Альтернатива - можно дополнительно этот модуль довести до конца в инновусе, отдельно от проекта, выписать либу и использовать ее в синтезе большого проекта. А в P&R использовать ILM модель + LEF модуля.
  5. С падами, конечно. Логика здесь следующая. Есть ТЗ, в нем указана спецификация интерфейса - тайминги, нагрузки, наклоны фронта. Все это аккуратно перекладывается в sdc (set-input-delay, set-load, set-transition и т.д.). Разумеется, эти констрейнты должны накладываться на выводы микросхемы, а не коре. А значит, пады должны быть обязательно. Уберете пады - не сможете правильно обконстрейнить интерфейс - не попадете в ТЗ. К тому же, систему моделирования у верификаторов тоже надо сразу делать в расчете на топ уровень с падами. Добавлять потом уровень иерархии бывает сложно, лучше сразу все делать правильно. Для верификации вместо падов используют либо модели из библиотеки, либо самодельные поведенческие модели. Но для синтеза лучше иметь инстансами вызовы реальных библиотечных падов, которые выбираются исходя из ТЗ. Вписывают их ртльщики. Хотя для SoC часто все сложнее - бьют дизайн на блоки, делают их отдельно, но в конечном счете все равно синтезируют топ-уровень с падами.
  6. Бондпады, к слову, не всегда клеят. Бывает, что их целый набор под разную разварку - медь, люминий, разная толщина проволоки. А пады идут отдельно. Что до клампов, то их тоже не всегда с питанием ставят. Правило - кламп не далее чего то, и по току - не более чего то. А если правило соблюдено, то кламп хоть между айошками ставь. Хотя, может гдето и рядом ставить надо, не встречал. Отвечая прямо на вопрос - нет, не знаю такой команды. Сам расстановку падов всегда скриптую. На входе таблица в экселе, где пады, филлеры, клампы, рингкаты, корнеры и т.д. - все расположено по порядку расстановки, против часовой стрелки, скажем. В каждой строке инстанс (для айо), название селла и сторона кристалла, можно еще ширину добавить. Потом таблица экспортируется в ascii, затем обрабатывается тиклевским парсером, который на каждую строчку высчитывает координату, ориентацию, и делает placeIO чтото там. Поскольку все координаты известны, можно заодно и бондпады приклеивать, если они отдельно. Этим же алгоритмом можно в несколько рядов пады ставить, если надо, или - сразу координаты центров пятаков в файл сбрасывать - для последующего айрдропа и лвс. Работает так - накатил скрипт, посмотрел результат, не понравилось - все грохнул, подправил эксель и снова накатил. В минуту одна итерация - легко. Скрипт легко переносится на другую технологию. Дизайн аутомейшн наше все, рекомендую :-)
  7. Если честно, не уверен, что понял задачу. Понял так: Есть макро, с него выходит шина асинхронных сигналов, и есть приемный клоковый домен для этих сигналов. Нужно обеспечить равные задержки. Что получается. Разряды в шине расползаются на +/- 1 такт в любом случае (поскольку сигналы асинхронные), и Ваша задача их потом выровнять с помощью фифо. Возникает вопрос - а на сколько выравнивать фазы? Полагаю, что допустимый разброс не должен превышать одного такта за вычетом сетапа и холда флопа, а так же разброса по температуре и питанию - в этом случае будет ошибка не более +/- 1 такт, а не, скажем, +/-2 такта. В зависимости от частоты это может быть и большой разброс и маленький, частоту Вы не указали. На мой взгляд, здесь надо все плейсить руками, включая клоковые буферы. Вероятно, эту часть схемы лучше выделить в отдельный уровень иерархии, и построить для нее Н-дерево или фишбон, а может еще и развести клок руками. Другой вариант - не заморачиваться с плейсом, но организовать выравнивание +/-2 клока с помощью фифо :-) Что касается сдвигания флопов, я это делаю скриптами. Для выходного пина первого флопа узнаете его координаты (через атрибуты). Далее , через placeinstance (или как то так - нет мануала под рукой) плейсите в эту координату второй флоп, а потом выполняете refineplace. Получаете два флопа рядом. Но это медленно работает, особенно на больших обьемах. Если же нужно аккуратно расставить целый массив (фифо, к примеру) из флопов, то очень рекомендую почитать про SDP - техника специально для расстановки структурированых массивов селлов.
  8. set_data_check работает только с сигналами, приходящими на входы одного селла. По сути, это такое же выравнивание, как если бы один сигнал считался клоком, а второй данными (тип проверки - сетап и холд). Для выравнивания задержек этот констрейнт подходит плохо, особенно если выравнивать приходится сигналы в разных путях reg2reg (по сути - в шине). Лучше вообще избегать таких схеме; классика жанра - одиночные сигналы синхронизовать через 2(3) флопа, а массив данных - через двупортовую память, в которой индекс передается в коде грея. Пробрасывать же целую шину в асинхронный домен -моветон. Но если очень надо, то начинать надо с деревьев: все передающие флопы должны иметь одинаковое летенси (одна скью группа домена А), так же и принимающие флопы - одна скью группа домена В. Обязательное условие - отсутствие любой логики (логика в CDC переходе - моветон в квадрате, могу обьяснить почему). Таким образом, останется только выровнять задержки, что можно сделать просто разбив приграничные флопы на пары (флоп доменаА + флоп домена В), и ставя флопы каждой пары физически рядом (или попытать set_max_delay, уповая что тул сам все расставит правильно). В результате, неровность задержек будет только за счет перекоса деревьев - незначительно гулять по температуре и питанию. Как сделать лучше, я не знаю. Но, повторюсь, лучше вообще избегать подобных CDC решений.
  9. Чем меньше паразитная емкость между стадиями сдвигового регистра-пересинхронизатора, тем ниже вероятность получить метастабильное состояние. Поэтому желание поставить такие флопы рядом понятно, и тем более понятно, почему делают специальные селлы для пересинхронизации. Если же спец. селлов нет, и малтибит селлов нет, то проще всего сдвигать эти флопы в кучу сразу после плейса, и назначать им статус fixed. Или же сдвигать их после каждой оптимизации. Двигать можно руками, но проще заскриптовать через ECO команды. Еще, можно сделать свой селл-синхронизатор в том же инновусе, выписать либу или ILM-модель, а потом использовать в дизайне как иерархический блок. Либо, попробовать объединять флопы в SDP структуры. Но я так никогда не заморачивался.
  10. Так а в чем вопрос то? Если действительно имеет место быть малтисайкл, то все хорошо: сетап уже выполняется, как видно из репорта, а по холду буфера будут стоять перед вилкой на регистр flag. Если же в логике схемы нет малтисайкла, то слэк совсем небольшой - его исправит дерево. К слову, дерево ведь можно сэмулировать в синтезе, через констрейнт set_clock_latency: если наложить его на тактовые входы регистра data, то отрицательный слэк можно убрать, а мощности элементов расслабить. Позже этот констрейнт будет учтен во время CTS. Проблем нет, вроде, все хорошо
  11. Судя по описанию, был такой девайс Xilinx download, который и поддерживался джэм-плейером. Скорее всего это что то очень старое под LPT или RS232
  12. А где здесь генерейтед клок? На схеме все три флопа работают на одном клоке. В тайминг репорте показан путь от регистра до регистра. Генерейтед клока нигде не наблюдаю, все на одном клоке
  13. Синтезатор все верно сделал, если использован констрейнт multicycle 4. Этот констрейнт накладывает лимит по сетапу 4 такта, а по холду 3 такта. Вот у Вас синтезатор и вытянул (попытался) эти 3 такта по холду, напихав лишних задержек в виде дополнительной логики. Подумайте, нужен ли Вам здесь малтисайкл. Констрейнты не обязаны повторять особенности интерфейса, они предназначены для временных ограничений, задавать которые можно разными способами. Если логики по входу мало, то лучше малтисайкл не использовать. Малтисайкл вообще лучше не использовать, т.к. он привязывает дизайн к фиксированой частоте. Т.е. дизайн без малтисайкла будет работать на частоте от 0 до Fmax, а с малтисайклом только в небольшом окне частот вблизи Fmax. Зависит от задачи, конечно. В некоторых случаях без малтисайкла никак. Но недостатки такого решения надо знать.
  14. Ну что же, Вам попался очень сложный вариант. Сложнее бывает только, когда цвета добавляются У Вас второй металл случайно не горизонтальный? Если так, то обычно рекомендуют дублировать фоллоупин во втором металле - об этом должны писать в доке черным по белому. В этом случае страйпы присоединяются ко второму металлу - без конфликтов, а соединения фоллоупинов между М1 и М2 производится регулярным массивом виа. Лучше об этом читать в доке. Если доки нет, лучше спросить саппорт, как это сделать. Если же второй металл вертикальный .. тогда единственный вариант - заставить роутер автоматически кромсать малтикат виа в местах конфликтов. Т.е., к примеру, на Вашем скрине 4х малтикат виа должна быть разбита на 1х и 2х виа, с пропуском в том месте, где возникает конфликт. Т.е. в месте, где удалена виа, конфликта уже нет. Но, и я об этом уже писал, в таком случае обязателен анализ айэр-дроп в конце, чтобы убедиться, что роутер не выкрошил слишком много переходных. Бывает, что выносятся целые области, где из-за отсутствия соединений сетки возникает большая просадка напряжения.
  15. Виа, это обьект в трех слоях: два металла, и переходное между ними. Соответственно, сочетания нескольких размеров и формы переходных отверстий + нескольких вариантов полигонов металлов - дают огромное число вариантов виа (не считая малтикат). В частности, для сетки питания часто используют ортогональные виа, у которых ширина обоих металлов равна ширине переходного, а переходное - квадратного сечения, а не прямоугольник. Если на Вашем скрине поставить такую виа, то расстояние до пина селла станет намного больше, а ошибка уйдет скорее всего. Подобные рекомендации (тип виа) должны содержаться в мануалах на библиотеку селлов, как уже писал. Если их нет .. значит подбирайте сами, чтобы не было конфликтов. Либо действительно не ставьте селлы под страйпами. Но это дорогое решение, на мой взгляд - площадь пропадает. p.s. если же вернуться к изначальному вопросу топика, то поскольку расстановку страйпов я всегда скриптую, и в скрипт включаю формулы расчета шага, оффсета и ширины, то я бы в тот же скрипт заложил и create placement blockage по форме страйпов.