Что-то не могу найти, как можно контролировать расстояние между диф. парами на одном слое (между внешними проводниками). Версия 15.5.
Может, это есть в новых версиях? Кто как делает?

Создайте класс, включите в него нужные цепи/пары, создайте Spacing Constraint Set с нужными зазорами, и установите его на созданный класс.

С этого и начал. Только я использую не классы, а назначаю свойства (properties), как это сказано в мануале. Но подозреваю, что это не важно.
Так вот, при таком подходе DRC проверяет расстояние между всеми проводниками с назначенными свойствами. У меня, допустим, три пары (6 проводов). Я на все назначил одно и то же свойство. Соответственно и DRC начинает считать ошибкой зазор между проводниками внутри пары, т.к. он меньше расстояния между парами. Вот в чем вопрос.
Ну не назначать же свойства отдельно на плюсовые и минусовые провода? Хочется работать именно с парой, как с отдельным объектом.

А я не просто так написал именно о классах Посмотрите в хэлпе иерархию констрейнов(Constraint Object Hierarchy) и все станет ясно. Вы назначили констрейны зазоров практически на самом верхнем уровне иерархии, для цепи(Net). И они конфликтуют с другими констрейнами заданными на том же уровне, только в другой ветке правил. А вот классы находятся всего лишь на одну ступеньку выше, чем Default, поэтому цепи в классе подчиняются правилам для класса, а цепи в паре подчиняются констрейнам пары и конфликта не происходит.
Посмотрите какие констрейны являются определяющими для этих пар (CNS Show -> Resolved).

Видимо, я уже сильно отстал от жизни, ибо ничего подобного у себя не наблюдаю. Нету никаких классов и show resolved.
Единственное упоминание о классах цепей в хелпе есть в разделе про назначения свойств. Там благодаря назначенным свойствам и образуются классы цепей, но больше этот термин нигде не используется. Соответствие между цепями со свойствами и наборами констрейнов задается с помощью табличек в окошках assignment table.
Естественно, ест иерархия объектов, но не констрейнов, а объектов дизайна. Про констрейны написано, что они наследуются согласно иерархии объектов дизайна.
Сама эта иерархия выглядит так: system - design - design instance - bus - diff pair - xnet/net - matched/relative group - pin pair.
Про классы и default ничего не сказано...

Как-то так:
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Единственное что я не смог это сделать, так это чтобы соблюдался большой зазор между дифф. парами, находящимися в том-же классе. Если ставить значение зазора, больше расстояния между проводниками в самой дифф. паре, то начинается ругань DRC.

Ух ты! Там уже и spacing, и physical есть. У меня такого нету, в констрейн менеджере только electrical.

Но все равно, как я понял, ругань начинается потому, что наборы правил применяются не к парам, а к цепям. Т.е. невозможно (у меня не получается) работать с парой, как с неделимым объектом, всегда назначаемые констрейны применяются к обоим проводникам внутри пары.
У меня есть желание раздвинуть пары одного типа (видимо, в новых версиях это принадлежность задается классом, а у меня назначаются свойства) на определенное расстояние просто для страховки, при этом моделировать crosstalk совершенно не хочется.

Я, к сожалению, не могу проверить совет Uree на практике, ибо нету у меня классов, но странно, почему этого не можете сделать Вы... По-идее, слова Uree выглядят очень правдоподобно...

Свою проблему пытался решить констрейном MAX_PARALLEL, но он работает до первого DRC и не отличает бока диф. пары друг от друга. Т.е. неудобно и неправильно это все.
Что делать, не знаю даже... Придется на глазок...

Vitan, выложите хэлп по вашей версии Аллегро в паб. Желательно полную папку /docs, или как она там называется. Просто Вы почему-то сидите на достаточно древней версии и ни этой версии, ни док по ней уже похоже ни у кого нет. Поэтому помочь тяжело.
Но в общем случае, классы цепей и констрейны(ограничения) в Аллегро есть давным давно, меняются только способы их вписывания. То, что Вам надо, можно описать, осталось только посмотреть в хэлпе как именно это сделать.
Еще могу посоветовать перейти на версию поновее Очевидный так сказать совет

Может от лицензии зависит? В простейшей L, наверное, ничего такого нет.

З.Ы: ааа, раз у вас старая версия, то мой коммент бессмыслен.

В новых версиях наоборот - физические констрейны и спэйсинги есть во всех версиях, а вот электрические - диффпары, длины, группы есть только в старших версиях. Точнее диффпары есть уже и в младших, но они единственное, что там есть. Хуже всего, что в версии "L" нет регионов и правил для них Надеюсь в новой версии Аллегро 16.5 они этот функционал "опустят" до младшей версии

Положил доки в аплоад/пцб/кейденс/спб_1551_док
Если не трудно, посмотрите, я так и не нашел ничего более подходящего, чем max_parallel.

Vitan, похожий на ваш случай показан в \doc\aleg_spec_tut\examples\spacing_set_viewlet_swf.html. Правда там набор правил добавляется на уровень цепей... Но вот вопрос - а если Вы через Properties создадите неткласс и на него навернете набор правил, все равно не получается?

ЗЫ А все-таки, перейти на версию поновее совсем не судьба или типа некогда такой ерундой заниматься? Неужели с лицензией работаете и без оплаченного maintenance?

Спасибо за участие. Посмотрел мультик, ничего нового не увидел. С этого я и начинал, однако, свойства задаются именно цепям, коих в паре две штуки. Поэтому вся эта технология работает только для одиночных цепей.
Даже если мне бы и удалось как-то создать неткласс через свойства (отдельный вопрос - как?), то мне уже очевидно, что работать это не будет именно по указанной причине.

Uree, Вы можете сделать картинки наподобие тех, что привел Ant_m, чтобы стало понятно, как у Вас получается работать с парой, как с единым объектом (в плане спейсинга)?

В принципе могу, но не сейчас. Время на это нужно... а его сейчас нет.

Похоже в старых версиях с этим сложнее, либо просто мы не всё знаем.

Вот так ваш случай выглядит в версии 16.3:

- пары определены (DPr в столбце Object type) и собраны в NetClass(NCIs), для которого назначен PCS (physical constraint set)

Нажмите для просмотра прикрепленного файла

- физические параметры трассировки пары описываются через PCS, причем вместе со спэйсингами и их допусками

Нажмите для просмотра прикрепленного файла

- в разделе спэйсингов этому нет-классу назначен свой SCS (spacing constraint set)

Нажмите для просмотра прикрепленного файла

в этом CSC я дополнительно определил зазор line_to_shape, дабы полигон земли был подальше от пары.

А теперь Ваш случай - определяем в этом же SCS зазор lin_to_line = 0.5мм

Нажмите для просмотра прикрепленного файла

Работает. Там где синим обведено пары расположены на большем расстоянии - ошибок нет. Там где зеленым - расстояние от трасс неткласса CLS_HDMI до любых других трасс меньше 0.5мм - получаем ошибки. Конкретно на скрине имеем трассы земли, питания и соседние пары. Т.е. то, что Вы и хотели - зазоры в паре и зазоры в нетклассе определены по разному и одно с другим не конфликтует, потому как правила диффпары выше в иерархии, чем правила для нет-класса:

Нажмите для просмотра прикрепленного файла

Спасибо за красивые картинки.
Похоже, что в новых версиях все-таки есть отличия в работе с диф. парами. Т.е. они нормально воспринимаются как единый объект и, самое главное, этому объекту можно назначать SCS-ы.
К сожалению, в версии 15.5 я такого не нашел.
Придется раздвигать все руками и думать про новые версии. Спасибо всем еще раз!

Я заметил, что доки переместили в паб.
Ценность там невелика, это можно смело удалять имхо...

попробуйте так:
Setup/constrains/electrical constrains/
1. electrical csets - создать класс
2. assign (назначить diff. pair в этот класс (из списка))
3. diffpair values – установить значения
4. modes – установить All differential pair checks.

Дык ну это ж все внутри пары. А мне надо между парами.

попробуйте + к вшесказанному содать spacing constrain set
с нужными (внешними) зазорами и внести туда дифф пары.

Это уже предлагалось, но в версии 15.х нереализуемо - там попросту еще нет spacing constrain set... Точнее они вроде как есть, но на уровне Nets, а нужно бы на уровне Net Class.

наверно путаница в терминологии
можно попрбовать в живой плате, если такая есть

У Вас есть Аллегро 15.х ? Если есть - попробуйте. У меня нет, но из документации я понял, что в тех версиях это так просто не реализуется. А если и можно, то я не знаю как.

Как я понял разговор о конкретной плате - значит с ней и работать надо

Да не в конкретной плате дело. Вопрос в версии софта и возможностях задания правил/ограничений от этого зависящих.

извиняюсь. значит не правипьно понял

Погодите. Естественно, вопрос возник не на пустом месте, и мне помогло бы решение именно для конкретной платы. Вот только есть ли оно (помимо апдейта)? Что имелось ввиду?

тогда выложите "конкретную плату" и "конкретные требования" которые надо решить

А какая может быть особенность конкретной платы, чтобы в ней можно или нельзя было реализовать то, что НЕ позволяет софт?
Проще говоря - если это ограничение софта, то от конкретной платы не зависит НИЧЕГО.

Дошли руки проверить (16.5-16.6).
Не получается.
Точнее, получается, но не то. Зазор между парами работает, но при этом возникает ошибка внутри пары, т.к. в PCS для gap число меньше, чем для SCS между классами.
Выглядит так: начинаю вести пару, все нормально, в процессе прокладывания пары автоматически выполняется зазор между классами (т.е. не дает проложить пару близко к соседней), но как только заканчиваешь трассировку, возникает DRC от спейсинга класса. Что делать, ума не приложу...

Я правильно все понял? Создаем класс, в него складываем пары, создаем ему PCS, в котором устанавливаем зазор внутри пары и прочее. Потом создаем отдельный SCS, в котором Line-to-line устанавливаем как надо. Потом назначаем этот SCS классу. И внутри класса должен выполняться только он?

В некотором роде ошибки ведь логичны. Что мы задали в line-to-line внутри SCS для класса? Непонятно. Т.е. где те самые line (в случае дифпары), для которых будет выполняться проверка? Это что, мнимая середина пары? Где это описано?

Uree, как Вам удалось получить предпоследний скриншот? Вы делали принудительное обновление DRC после создания скриншота?

Ну Вы спросили... когда это было. Уже и не помню.
Проверил. SCS выглядит так:

Нажмите для просмотра прикрепленного файла

т.е. дополнительный зазор только для объектов Line.

В итоге при трассировке не дает вести пары ближе, чем задано, DRC ошибок не показывает ни online, ни после batch-проверки.
Выключил bubble, сдвинул трассы ближе допустимого, сразу получил три ошибки:

Нажмите для просмотра прикрепленного файла

Как и должно быть - один сегмент кофликтует с тремя сегментами трассы другой пары.

Почему у Вас так не получается - понятия не имею...

А насчет логичности ошибки не согласен. Посмотрите иерархию правил Аллегро - правила для диффпар на два уровня выше правил для класса.

Интересно, откуда их там три? За счет изгибов?


А какая у Вас версия?


Ну и что? Допустим, в SCS для класса описывается некое правило line-to-line. Допустим, в класс входят некие объекты, в т.ч. и дифпары. Где написано, по каким законам будет проверяться SCS класса применительно к этим дифпарам? Что такое "line" применительно к дифпаре, вот в чем вопрос!

Да, три сегмента нарушают зазор с сегментом другой пары:

Нажмите для просмотра прикрепленного файла

Версия у меня 16.5S030.

А с иерархией все-таки поразбирайтесь. Вас же не удивляет, что правило для класса выше чем дефолтовое правило для дизайна и в итоге именно оно является определяющим при проверке? Нормально? Да.
А почему тогда непонятно, что правило "Primary Gap" для диффпары выше в иерархии чем "Line-to-Line Clearance" для класса?
Можно пойти еще выше по иерархии и на уровне цепи указать зазор меньший, чем Primary Gap пары - вот тогда получим ошибку, потому что правила для Net выше уровнем, чем правила для Differential Pair.

Можно еще посмотреть какие правила для нужных объектов являются результирующими:

Нажмите для просмотра прикрепленного файла

Нажмите для просмотра прикрепленного файла

Я вижу, что Аллегро трассы внутри пары проверяет только по правилам для диффпары. С другими объектами, не входящими в состав пары, начинают работать остальные правила. Поэтому внутри пары line - это член пары, и по отношению ко второй line будет действовать Primary Gap, а по отношению к остальным line правила дизайна/класса/цепи и т.д.

ЗЫ Хотя мне никак не удалось получить ошибку зазоров внутри пары, даже прописыванием зазора прямо в редакторе на уровне Properties.

А потому что gap - это домен physical, а clearance - spacing.
В этом месте они (домены) пересекаются. И я не могу от этого избавиться. И не понимаю, как Вам удалось.


Это я все понимаю, но это не спасает. Ошибка возникает из-за того, что в домене spacing проводится проверка на предмет близости проводников, для которых правило определено в другом домене. Иерархия тут ни при чем, на всех картинках в хелпе показано, что все домены, якобы, независимы. Но это оказывается не так.


Удивительно! Может, у Вас выключен какой-то режим? Давайте обменяемся нашими проектами! Ну или хотя бы кусочками. Вот, я специально сделал тестовый проект в 16.5. DRC горит!
Нажмите для просмотра прикрепленного файла

Нда... а мне удивительно как Вы сумели создать такую пару Neck параметры больше чем Primary, разброс зазора почти равен самому зазору - это как???
Отредактировал параметры пары - никаких DRC не осталось. Смотрите.

Нажмите для просмотра прикрепленного файла

Я в шоке!
Какая ему разница-то???? Вы можете объяснить?

Параметры пары, сами видите?

Конечно, вижу. Но не понимаю. Какая разница, какой там neck и прочее? Как это связано с DRC line to line?
Какой-то баг, похоже.
Щас буду исследовать, при каких условиях это проявляется. Иначе я как-то побаиваюсь работать с таким неадекватным софтом...

UPD.
Разобрался.
Не был задан min line spacing для дифпары. Точнее, там был ноль.
В доке сказано, что если min line spacing не задано (именно так: if you do not enter), то берется значение из line to line spacing для назначенного паре набора. В нашем случае набор резолвится до netclass-а (что есть правильно), а в нем стоит число, большее, чем gap, что и вызывает DRC.
Tol +\- ни при чем.

Мда... Ни за что бы не догадался, что ноль в их понимании - то же самое, что "do not enter"...
Если хоть на сколько-нибудь увеличить этот параметр (например, записать 0.0001), то DRC тут же пропадают.
Жестко.
Спасибо, Uree, свежая голова - всегда хорошо.

Да не за что, но так определять пару - это жестко Кстати вопрос - а зачем Вы определяете параметры для слоев, где этой пары не будет по определению? На плэйн слоях земли например. И зачем там вообще разрешена ее трассировка?

Да я их так не определял. Я просто задал необходимый минимум, а min spacing и остальное уже и не помню откуда взялись. А на плэйнах получилось потому что я вначале задал на всех слоях, а потом задал на паре внутренних некие абстрактные значения просто с целью, чтобы они различались. И трассировка на них не разрешена, там у меня layer sets (или удалилось?). Это просто самое начало проекта, никаких реальных параметров еще не задано. Вот теперь я понял, как можно это сделать (кстати, на весь DDR пока что удается обойтись одним PCS и одним SCS) и теперь задаю реальные параметры.
Теперь по теме остается один маленький вопрос: как увидеть DRC, если случайно зазор в паре увеличился?

Такая ситуация даст DRC когда длина несвязанных сегментов станет больше заданной: раздел Electrical, закладка Differential Pair, параметр Uncoupled Length.

Точно. Ну, теперь, можно и тему закрывать.