Петров Максим «Эремекс»
Основой инструмента SimPCB является расчетный модуль, разработанный нашей командой. Естественно, любые вычисления требуют проверки и оценки точности, поэтому солвер мы подвергли глубокому тестированию. Для сравнения результатов выбрали несколько САПР, которые заслуживают доверия у инженеров, а именно, Ansys и Si9000 от Polar, ну и конечно, провели замеры на реальной печатной плате [1].
Оказалось, что достаточно изнурительно тестировать наш солвер SimPCB для расчёта линий передачи (ЛП) обычными действиями. В Ansys под каждую структуру мы вручную изменяли и двигали по координатам каждый примитив: ширину трека, зазоры, маску, толщины слоёв ー и делали это снова и снова. Параллельно проверяли в программе Polar, которая была, как указано выше, ещё одной обязательной точкой сверки результатов, но это уже совсем другая история без счастливого финала ー самый популярный инструмент оказался не самым лучшим [2], да и автоматизировать его не удалось. Я решил, что «хватит щёлкать» и сделал готовый конвейер, чтобы просто взять и работать: анализировать поведение параметров L (индуктивность), R (сопротивление) и G (проводимость) структуры ЛП при любом изменении её параметров ー для каждой структуры, без долгой ручной рутинной работы, экономя сотни человеко-часов и десятки тысяч рублей на психологов по профессиональному выгоранию.
Задача
Задача состояла в следующем: нужно было вычислить для ЛП L, R , С и G в зависимости от ее геометрических и электрофизических параметров. И сделать это было нужно для всех типовых структур, которых у нас целых 64 штуки!!! Мы проверяли влияние следующих параметров:
H - высота диэлектрика. Если их несколько в структуре, то проверяли влияние каждого из них отдельно.
Er - диэлектрическая проницаемость материала. Аналогично, несколько материалов ー несколько разных проверок.
W1 - ширина проводника.
T1 - толщина меди.
D1 - расстояние до опорного слоя для копланарных структур.
S1 - расстояние между проводниками в дифф. паре.
C1 - толщина паяльной маски.
CEr - диэлектрическая проницаемость паяльной маски.
tg - тангенс угла диэлектрических потерь.
TC - проводимость меди.
Программа Si9000 оставалась обязательной точкой сверки: результаты туда заносились другим тестировщиком вручную, чтобы быстро увидеть расхождения на базовом уровне. Когда несоответствия проявлялись (а они всплывали достаточно часто), то мы уже подключали Ansys как тяжёлую артиллерию, чтобы подтвердить или опровергнуть проблему уже в полноценном анализе, без упрощений и багов в Si9000.
Сами сравнения строились вокруг параметрических серий: мы перебирали один параметр за раз, когда все прочие параметры были фиксированы. Например, изменяли H1 (высоту первого диэлектрика) на 0.05 / 0.15 / 0.25 мм и смотрели, как при этом рассчитывается L, R, G. Точно так же проходили по другим применимым параметрам ЛП. Вдогонку для каждой серии мы прогоняли несколько частотных точек - 100, 500 и 1000 МГц, чтобы видеть не только статический сдвиг, но и частотную зависимость. На типовой странице отчёта для каждой подобной проверки это оформлено как таблица «SimPCB vs Polar + Погрешность (%)», а чуть ниже блок с результатами Ansys для проблемных расчётов и проверкой погрешности.
Критерий: если MATLAB и Polar не сходятся ー идём в Ansys и смотрим глубже. Такой двухступенчатый разбор позволяет быстро отделять ошибки формул/единиц/материалов от реальной чувствительности геометрии и искать, какой инструмент, где соответствует расчетам. За счёт серий по одному параметру видно именно влияние этого параметра без шума от остальных. В итоге мы получаем что-то типа карты: какой параметр линии передачи реально и правильно влияет на L, R, G, а где расхождения ー следствие ошибок, настроек или багов в одном из инструментов.
Почему автоматизация была нужна
Ранее модели для ЛП в Ansys проектировали вручную. Иногда доделывали старые проекты и это для меня оказалось ещё хуже: без понимания «как они собраны» в них легко утонуть и поломать всю структуру с концами. В старых моделях каждый примитив имел жёстко забитые координаты X/Y без каких-либо зависимостей. Меняешь высоту одного диэлектрика ー соседний остаётся «висеть в воздухе», потому что его координаты ни к чему не привязаны.
Вследствии этого переписал модели на переменные с зависимостями: H1-H4 задают стек и считаются друг относительно друга, маска учитывает зазор между проводниками, а не живёт своей жизнью. Даже подтрав проводника можно было учесть и у треков появлялись скошенные края на нужную величину! Если бы он ещё и пригодился… Плюс навёл порядок в оформлении: цвета слоёв и материалов, читаемые имена, единый набор параметров. На скрине виден сам принцип: единое окно параметров и аккуратная геометрия, которая обновляется и подстраивается под любое изменение, просто ручками поменяй нужный параметр ー и у тебя готовая модель.
Это сильно упростило жизнь, но тоже быстро стало рутиной: параметров и структур много, руками перебирать всё равно долго. Дальше ー автоматизация.
Требования к автоматизации
Время ー главная метрика. Всё должно быть заточено под минимальное число кликов и секунд до результата.
Golden-модель для одиночной и дифференциальной линии передачи со всеми возможными примитивами. Нужные параметры и частотные диапазоны заранее настроены в шаблоне отчёта модели. Скрипт не трогает частоты и отчёты, он меняет только параметры и состав модели.
Модели должны быть чисты и корректны. Всё ненужное от исходной golden-модели удаляем, а не прячем.
Никакого ручного изменения примитивов. Любые правки через параметры, руками ничего не трогаем! Все возможные значения для каждого изменяемого параметра согласованы и жёстко зафиксированы.
Все вариации одной структуры живут в одном проекте AEDT, поэтому можно запустить последовательный расчёт, и Ansys посчитает их по очереди.
Выгрузка RLG в таблицу на нужных частотах в простом .txt/.csv, готовом для Excel/Google Spreadsheets.
Работа над концептом и сама автоматизация
Сначала я собрал Golden-модель. В ней лежит всё, что вообще может встретиться в наших линиях: полный стек диэлектриков, маски, земли, варианты проводников. Все размеры завёл как параметры с зависимостями: двигаешь H1 ー вся модель перестраивается целиком; меняешь W1 или S1 ー маска подтягивается как положено. В этой же исходной модели заранее настроены отчёты и частотные диапазоны по результатам, поскольку их скрипты не трогают. Теоретически можно было и зацепить их создание, но зачем, если мы всё равно берём копию Golden-модели, куда уже можно положить всё настроенное? Дальше принцип простой: от всей огромной модели удаляем лишнее (например, диэлектрики и опорный слой сверху) и получаем конкретную структуру.
Дальше начались первые шаги к автоматизации. В Ansys можно записывать скрипты нативно в рабочей области в форматах VB Script, JavaScript и Python. Включил запись действий, сделал руками нужное изменение и выгрузил набор маленьких скриптов буквально по одному действию. Разобрал, что к чему, и склеил из этого что-то типа «справочника»: действие > какие параметры/объекты оно трогает. С Python и JavaScript у меня воспроизведение стабильно сыпалось по разным причинам, а вот VBS внезапно взлетел без танцев с бубном. Отлично ー идем от .vbs, вообще не принципиально.
Проверяем гипотезу ー размножаем действия и собираем из них проект только с нужными модификаторами. Например, на типовом кейсе: сделать пару копий golden-модели внутри проекта, в одной поменять диэлектрик, во второй удалить копланарный полигон, в третьей увеличить толщину маски, а в четвертой заменить её материал. Скрипт применился, модели перестроились ー значит, можно двигаться дальше.
Вскрылась следующая боль ー нужна фильтрация, чтобы выбирать только нужные модификаторы для создания копий. На каждый прогон меняются только выбранные вещи, остальное трогать категорически нельзя, иначе это сломает модель и вся точность результатов будет некорректной. Вдогонку переименовал сам проект под имя структуры (логично же), чтобы в любой момент была возможность найти нужную структуру, и в командах скрипта это имя тоже фигурирует ー в начальном копировании, переименовании и активации нужного проекта.
Самое простое решение по автоматизации оказалось на 100% рабочим: я вынес весь «словарь действий» со всеми возможными параметрами в Excel, добавил скрытую метку «за что отвечает строка» в колонку напротив каждой строки и просто включал фильтр по нужным модификаторам. Не забыл и про переименование проекта ー сделал жирную надпись вверху таблички «не забудь переименовать проект» и просто через «Найти/Заменить» изменял маску с именем под нужный мне код структуры. Как итог, получилось отфильтровать список команд с нужными именами проекта, который удобно скопировать в пустой .vbs файл. Этот .vbs запускается в Ansys и ー О, ЧУДО, ー модели собираются как надо.
Через пару дней такого «копипаста» меня этот процесс слегка утомил, и я накатал промты в Deepseek и ChatGPT, чтобы они собрали мне макрос для Excel. Deepseek в перерывах между изображением бурной деятельности и падающими серверами как-то старался выдавать мне код макроса, но с ним был один нюанс:
ОН. ИЗ РАЗА В РАЗ. НЕ. РАБОТАЛ !
Итерация за итерацией, но получить рабочий код не удавалось, несмотря на довольно простой, но детальный промт. С ним попытка вайб-кодинга полностью провалилась.
В итоге решил закинуть тот же промт в ChatGPT и ー о, чудо ー за пару итераций с фиксами багов и ~15 минут времени у меня появился простенький макрос с UI. Простенькое окошко с полем ввода имени проекта (и автоматической заменой), выбором нужных модификаторов (наконец-то, включаешь то, что тебе нужно, а не отключаешь ненужное), и кнопкой для генерации готового .vbs скрипта уже в нужном формате.
Дальше уже идёт сам импорт скрипта в Ansys, и нужные модели собираются со всеми модификаторами буквально за пару секунд. Все варианты живут внутри одного проекта, так что «Analyze All» запускает расчёт сразу для всех ー Ansys считает их по очереди, и это очень хорошо подходит для наших целей.
В финале задачи ー выгрузка отчётов для посчитанных результатов и сведений. Отдельный скрипт выгружает результаты в .csv из каждого отчёта Ansys (по три штуки для каждой модели), второй раскладывает значения по Excel-таблице сравнения рядом с MATLAB и Polar. Тут ничего интересного ー плюс-минус тот же синтаксис в Ansys и макрос с навигацией и «копипастом» по ячейкам. Всё, что можно было сэкономить по кликам и минутам, мы сэкономили ー в этом была именно конечная цель.
Результаты
По времени получилось очень наглядно ー ручная сборка одной модели занимала примерно от одной до двух минут времени кликов и изменения переменных. На структуру могло приходиться от пяти до десяти моделей, а иногда и двадцать-тридцать. В первом (наилучшем) сценарии это от пяти до двадцати минут времени на полное ручное заполнение структуры со всеми модификаторами. Во втором сценарии размножение моделей занимает уже от двадцати до шестидесяти минут нудных ручных кликов. Добавим к этому человеческий фактор с обычными промахами и опечатками при ручном вводе и получим ещё 10-20% к времени сверху в наилучшем случае, если ошибка находилась сразу. Про плохие расклады и говорить не хочется, если проблема находилась уже после перерасчета и более глубокого разбора модели. В результате имеем время создания полной структуры ~5 минут в сценарии «если повезло», и ~70 минут рутинных кликов «если не повезло».
Теперь умножим это на весь парк из шестидесяти четырёх структур. Итого получается ~320 минут (~6 часов времени) в самом лёгком сценарии. Но говоря честно и объективно, таких простых структур было меньшинство. В тяжёлом сценарии выходит около ~4500 минут (~75 часов) чистого времени на клики и ввод. В усредненном сценарии это около недели чистых, но сосредоточенных кликов и ввода без каких-либо перерывов и без учёта времени расчёта моделей и переноса данных, просто настройка структуры. Любой «миссклик» или ошибка в введенных данных ー и ты тратишь ещё больше времени на разборки. Тяжело, правда?
Автоматизация ведёт себя совсем иначе. Генерация скрипта со всеми нужными модификаторами занимает около 30 секунд. Само применение ещё около 10-20 секунд, в зависимости от числа модификаторов. На структуру выходит меньше минуты подготовки. Весь набор из шестидесяти четырёх структур укладывается примерно в один час подготовки. Всё остальное время можно потратить на другие задачи, пока скрипт делает всё за тебя. Дальше уже сам расчёт, Ansys считает варианты по очереди и нас это устраивает, потому что ключевая метрика здесь время подготовки ТОЧНЫХ моделей, а не параллельность ради параллельности. Ускорение по подготовительным действиям получается от примерно 8 раз при лёгком сценарии с малым числом нужных моделей и примерно до 75 раз, если нужно много моделей. Даже если взять не совсем честное для данного случая среднее значение, то экономия времени - 40 раз!
Что стало понятно про солвер SimPCB, когда мы перестали нажимать мышью впустую и начали смотреть на саму физику расчёта? Наша планка допуска была согласована максимум на 10% погрешности с Ansys. Polar всё равно служил обязательной точкой сверки и именно он давал старт спору, но дальше Ansys показывал, где расхождение вызвано нашими упрощениями, или же багами в Polar. По L и G наш матлабовский солвер в ощутимом большинстве попадал в окно допуска с Ansys. Самые заметные расхождения начались, когда мы начали проверять R линии передачи в копланарных структурах. В нашем движке мы сознательно упростили меш ради скорости расчёта (мало кому захочется в быстром режиме ждать несколько минут, пока построится сетка) и на некоторых сочетаниях зазора и толщины получили заметный сдвиг по R. Автоматизация быстро подсветила эти неточности. Стало понятно, где стоит подтянуть настройки сетки для того же попадания в допуск, и вместо настроек моделей в Ansys мы предпочли решать реальные задачи с нашим солвером.
Итог простой ー время перестало утекать в рутинные шаги. Мы получили воспроизводимые серии для каждой структуры, увидели чистую чувствительность R, L, G к высоте, ширине, зазору и прочим параметрам структуры и перестали зря использовать чуждый нам интерфейс. Теперь спорим только с цифрами и с нашим солвером. И это уже довольно приятный спор.
Список используемой литературы
Сравнение результатов расчетов волнового сопротивления линий передач на печатных платах. В.С. Кухарук, В.А. Ухин, Д.С. Коломенский, О.В. Смирнова. Хабр 25.06.2024.
Особенности расчета импеданса линий передач в Polar SI9000. Ухин В. Хабр 30.08.2024