Вынес в отдельную тему скрипт для выравнивания дифференциальных пар.
Скрипт предназначен для помощи в выравнивании дифференциальных пар с учетом задержек в IC.



Коротко по интерфейсу.

D2D skew tolerance - погрешность выравнивания в между дифф парами группе;
P2N skew tolerance - погрешность выравнивания внутри пары между P и N цепями;
Delay - задержка распространения сигнала в материале, пс/мм;

Lic - длина (время) вносимая IC;
Lb - длина разведенная;
Leb - требуемая длина для обеспечения параметра D2D skew tolerance;
Lsum - суммарная длина;
D2D - результат обеспечения параметра D2D skew tolerance;
P2N - результат обеспечения параметра P2N skew tolerance.

Алгоритм работы такой.
Оператор запускает скрипт и выбирает класс дифф пар. Если необходимо учитывать задержку FPGA, то выбирает микросхему и загружает файл.
Забив необходимые значения в поля skew tolerance, выполняет трассировку пар. Скрипт производит вычисления и обновляет данные в окне.
Все введенные оператором данные, а также последний выбранный класс сохраняются в папке с проектом, те после перезапуска скрипта можно возобновить работу.
При работе скрипта не создается никаких PcbObject-ов. По сути данный скрипт дополняет/заменяет окно PCB.

Из нереализованного:
1 - Учет задержек нескольких IC;
2 - Вывод репорта в файл или на экран;
3 - Фильтр пары на PCB, выбранной в рабочем окне скрипта;
4 - …

Формат CSV файла с задержками в IC (без фигурных скобок): {PIN};{задержка, пс}

Замеченные баги:
1 - Вылет из Альтиума при активации PCB фильтра, если скрипт зарегистрирован в настройках. Замечен на нескольких машинах. Видно, как на короткое время происходит запуск рабочего окна скрипта после чего и происходит вылет. На моей рабочей машине этот баг не наблюдается.
2 – Невозможно выполнить PCB фильтр при активном скрипте. Ограничение Альтиума на количество выполняемых одновременно скриптов.
О неточностях работы и найденных багах можно отписываться здесь или в трекере на github.

Ссылка на github: СКРИПТ

Я создавал правило на один НЭТ, допустим 60 мм.
Затем рулесы экспортировал и открывал их Exelем. Там я Рулес для одного нэта копипастил столько раз, сколько нэтов надо выравнять. Заменял имена. Получалось, что каждый нэт выравнивался по 60 мм. Затем, копипастил из файла PDF числа с дистанциями внутри корпуса микрухи и в экселе отнимал от предустоновленных 60мм. Дальше, обратно импортируем рулесы в Альтиум и ВСЁ.

Здорово, а я открыл скрипт и выравниваю пары.
Но как идею для проверки DRC средствами альтиума, можно рассмотреть.

А длина переходного отверстия как учитывается?

Что то у меня нестыковка получается.
Нашел специально проект к которому csv Файл подходит. Тогда применялся lengthTuner с гугло-аддонов. С ним вроде все ОК
Здесь же показывает разбежку до 16ps между парами.. Подозрение, что с длинной переходных какая то засада.

Я попозже глубже копну, пока нет времени..

Что касается интерфеса, некоторые моменты:
- уберите выскакивающие окна. У меня три раза выскочило, что надо файл выбрать, хотя кнопка выбора файла третья в очереди: сперва галочка, затем выбор микросхемы, только после "open file". Либо кнопку "Open File" поставьте первой в очереди
- в передыдущей программе я подкрутил, чтобы в окне выбора были только элементы, начинающиеся на "D", ускоряет поиск нужного
- колонкам можно изменять ширину, но само окно расширить нельзя.
- заголовки столбцов допускают кликанье, но ничего не происходит, я думал произойдет сортировка

А можно ли использовать не diff pair class, а просто net classes? ну это так. не требование. просто у меня диффпар классы не исользуются и не назначены вовсе. все из-за того, что их назначение в альтиуме делается через одно место, у меня все на нетклассах завязано.

Почему "D", мне бы "U"
Не надо ничего трогать

ну можно сделать D и U. или можно сделать, чтобы попадали компоненты с числом выводов не менее 100, например.
вариантов масса.

эти огромные списки надо сокращать

Просто в компонент ввести параметр PinDelay=FileName
И выводить только те, у которых есть такой параметр, а имя файла брать из значения этого параметра ==> это еще меньше кликов. Да и задумываться не надо
Как раз для таких лентяев, как я

ну скрипты и предназначены для лентяев я и себе стараюсь по максимуму облегчить однотипные операции

Если вводить параметр (хотя и подсчет контактов тоже) заставит проверять все компоненты... Будет вызывать задержку. На несколько секунд поди

Вы имеете ввиду, чтобы параметр содержал сразу путь до файла .pkg?
Неплохой вариант. Но надо тогда чтобы при новом выборе файла .pkg параметр обновлялся в компоненте.

В первом приближении работает. По точности проверять надо
Без учета Xsignal. Хотя похоже тут будет без проблем работать
1 Желательно скрипт распространить не только на дифпары
2 При большом числе сигналов не хватает итоговой оценки--- все окей, или не все окей (сори тут оказывается все есть. Просто у меня она всегда красная)
3 желателно не только писать Fail И Pass но подсветить цветом Зеленый Pass, красный синий-- больше меньше нормы
4. Сортировка по столбцам отсутствует, а не мешало бы
5. флаг Stay on Top --- для чего?

Версия Алитиума 15. Длина берется из параметра RoutedLength объекта IPCB_Net/IPCB_DiffernetialPair, те она не считается. Предполагаю, что длина переходных учитывается. Проверю точнее. Если длина переходных не учитывается, будем определять версию альта для совместимости со старыми версиями и добавлять в случае чего длину виасов.


Тоже напрягает. Сделаю более эргономичнее.


Думал над этим вопросом. Но после приспособился не мотать ползунком, а набирать на клаве. Только нужно быстро )). Нужно подумать, как сделать фильтрацию.


Да окно делалось фиксированное. Это неправильно. Согласен, что необходимо сделать таблицу адаптивную под размер основного окна.


Это в планах.


В планах и стоит задача сделать не только на дифы, а на все сигналы.


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


Это думаю то не проблема, вот только если компонент обновят в схематике.




1 - см выше.
2 - Да, это сделано в виде изменяющегося цвета P2N/D2D skew tolerance.
3 - Это сделано сознательно по следующей причине - мне не заставить было альтиум выполнять процедуру прорисовки cell -а, где и мог меняться цвет/шрифт ячейки.
Поработаю над этим вопросом еще, но не думаю, что получится.
4 - в планах.
5 - Окно поверх всех окон.

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

Что по поводу вылета Альтиума, когда скрипт зарегистрирован в системе. Проявился у кого?

5. Да поверх не только окон алтиума, но всего поверх

Это актуально, когда все на FTP лежит
Нет ни разу не вылетел. Вот скрипт ушел в отладку, когда дважды запуск хотел и когда PKG открыт другим приложением.

Вылетов не было вроде. Все ок.

Ну окно поверх, есть окно поверх

Да с доступом к файлу есть такой нюанс.


Проверил щас как Альт считает длину виасов. Если сказать, что я удивлен, то это ничего не сказать.

так уж год как точно считает, а может и 2

Так в том и дело, что точно, но не точно. Или я чего не догоняю на своей дрезине.
Дело в том, что при добавлении просто виасов на трек без переходов на другой слой, Альтиум просто добавляет длину этих виасов к суммарной длине трека.
Допустим у меня есть трек длиной 20мм. Задача довести до 40. Нет ничего проще в расчетах Альтиума - просто добавь 10 виасов на трек и получишь 40 мм при толщине платы ~2 мм.
Если же произвести переход, то вот здесь он считает правильно.