Управление силовыми сетями - вторая попытка

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

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

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

Первый тип проблем - элементарный.

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

Затем возникают проблемы более сложного характера.

Бюджет каждой сети питания должен быть точно управляем, чтобы обеспечить адекватное распределение подаваемой мощности (для нормальной работы различных частей) и в конечном итоге её сбор во всех возможных рабочих условиях. Важным является количество тока, предоставляемое при каком напряжении (со стороны источника), и как он собирается и возвращается.

Наконец, есть более сложные вопросы.

В конечном итоге, печатная плата должна быть спроектирована таким образом, чтобы физически удовлетворять требованиям к питанию используемых компонентов. Чтобы избежать повторной работы и ошибок, эти ограничения дизайна должны быть автоматически рассчитаны из схематической информации. Затем, для проверки адекватности результата, конечный дизайн печатной платы должен быть симулирован. Это касается таких областей, как дизайн силовых и разделительных плоскостей, управление трассировкой, управление теплом, напряжение компонентов и так далее.

Простая проверка соединений питания

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

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

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

Важный вопрос: каков практический способ реализации этого?

Для начала давайте рассмотрим способ «построения» электросети. Электросеть — это просто набор цепей, задействованных в обеспечении питания необходимых частей.

Я считаю, что частично прозрачные детали — хороший механизм для достижения цели определения этого.

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

Их ключевая цель — сообщить, что для определенной цели (здесь, определение электросети) две цепи должны рассматриваться как соединенные. В случае управления питанием они действуют просто как провода и, следовательно, должны быть размещены на частях, которые не влияют на напряжение существенным образом.

Это должно отражаться их поведением и графическим представлением. На экране они должны быть видны только явным образом - например, когда курсор мыши наводится на задействованный контакт, и/или в соответствии с некоторыми предпочтениями или настройками. Точный вид их (когда и если они вообще видимы), я пока не определил. Определенно должна быть возможность исключить их из печатных материалов и выводов. Также они позволят создавать отношения "один ко многим". Их можно будет разместить либо в библиотеке, либо в контексте дизайна.

Теперь давайте посмотрим, что потребуется для определения основных электрических характеристик в сети питания. Я понимаю, что замена типа контакта «Питание» на два типа «Источник питания» и «Потребитель питания», в то время как встраивание электрических характеристик в параметры контактов, является популярной идеей. Однако это вызывает у меня дискомфорт по ряду причин.

Во-первых, это поднимает вопрос обновления данных как в контексте библиотеки, так и в контексте проектирования. Учитывая "старый" контакт питания, при переходе на новое программное обеспечение придется сделать обдуманный выбор (был ли он предназначен для подачи или потребления энергии?). Исходя из сегодняшней реальной ситуации, кажется, что простых ответов нет. Та же проблема существует и для обратной совместимости, а также для данных, которые передаются туда-сюда между различными версиями программного обеспечения.

Во-вторых, мнения, кажется, расходятся относительно наименования и концепций, лежащих в основе этих типов (источник питания/потребитель, источник тока/потребитель, положительная/отрицательная ссылка...). Также может возникнуть путаница в отношении отрицательных источников питания.

Существует также проблема характеристик компонентов, которые меняются в зависимости от способа их использования в различных проектах. Это варьируется от регулируемых регуляторов до мощности, подаваемой общими разъемами. Изменение самих контактов компонентов в проекте всегда возможно, но это подход, связанный с опасностью, когда речь идет о строгом управлении данными (например, при использовании функции Обновление из библиотек или Менеджера элементов проекта).

Я думаю, что здесь, чтобы двигаться вперед, требуется более гибкая система, которая позволяет объявлять характеристики соединительных контактов простым способом.

В этой перспективе мне нравится идея "Маркировки", предложенная Иэном. "Мощностная метка" - это просто описание соединения. Она определяется типом (Производитель или Потребитель), мощностью, диапазоном напряжений и свободным текстовым описанием. Когда она размещается на контакте, она объявляет электрические характеристики контакта. Ее можно разместить как в контексте библиотеки, так и в контексте проектирования.

Затем, учитывая сеть питания, базовые проверки могут быть легко выполнены:

• Типы соединений позволяют проверить отсутствие производителя или потребителя.
• Мощность всех производителей [произведенная] может быть сложена, и мощность всех потребителей [потребленная] может быть сложена. Затем эти два значения могут быть сравнены для проверки наличия дисбаланса в сети питания.
• Наконец, диапазоны напряжений каждого подключенного контакта мощностной метки могут быть сравнены для проверки на соответствие.

Следующие изображения иллюстрируют общий подход, описанный выше. В этом примере определены две сети питания: 5V0 и 3V3.

Разъем питания обеспечивает 5V0 для всей сети. Непосредственно в схеме (поскольку эта ситуация специфична для проекта) мощностная метка описывает характеристики питания контакта разъема питания, который подключен к шине 5V0.

Переключатель позволяет включать и выключать питание. Поскольку сети +B и 5V0 являются частью одной и той же сети питания и фактически находятся под одним и тем же напряжением, добавляются два прозрачных соединения для связывания контактов 1 и 3, а также контактов 3 и 2. Переключатель всегда «прозрачен», поэтому эти прозрачные соединения могли быть добавлены непосредственно к символу схемы в библиотеке схем.

Затем регулятор снижает напряжение с 5V0 до 3V3.

5V0 подается на аудиоусилитель мощности. Метки питания, размещенные на контактах, описывают их характеристики. Значение потребляемой мощности описывает худший случай. Это может быть сделано как в среде библиотеки схем, так и непосредственно в схеме.

3V3 подается на контроллер сенсорного экрана, характеристики контактов которого описаны соответствующими метками питания.

Затем можно выполнить простые проверки питания на 5V0:

Производители на 5V0

Потребители на 5V0

Также в этой сети все диапазоны напряжений совпадают (J19-1 обеспечивает 5V0, в то время как U1-1 требуется 2V7~6V0, а U26-2, 10 и 15 требуется 4V5~5V0).

На 3V3 можно выполнить те же проверки:

Производители на 3V3

Потребители на 3V3

Также на сети 3V3 диапазоны рабочих напряжений совпадают (3.2V~3.4V, 1.2V~ 3.4V, 2.7V~3.6V, 2.7V~3.6V)

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

Также должна быть возможность по требованию выделять целые сети питания с некоторым указанием их корректности.

Также, простой механизм группировки производителей вместе, используя групповой индекс в метке питания, позволит нам указывать, какие производители будут активны одновременно (и, следовательно, должны быть суммированы), например, для избыточных систем питания. Система может учитывать это при проведении проверок.

Продвинутое управление питанием и анализ

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

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

Для того чтобы реализовать это каким-либо удовлетворительным образом, необходимо было бы привлечь движок симуляции Spice, что, очевидно, возможно.

Помимо веса добавления адекватных моделей симуляции в библиотеки и проекты, я пока не уверен, можно ли надежно охватить все возможные случаи. Потребление энергии многих устройств зависит от того, как они фактически работают на местах. Чтобы учесть это, движок симуляции Spice должен быть оснащен средствами учета способа программирования устройств и взаимодействия этих программированных устройств с их окружением.

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

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

Что касается автоматического создания правил, то в программном обеспечении пришлось бы решить ряд архитектурных проблем, например, возможность определения бинарного правила на уровне схемы. Затем необходимо было бы четко исследовать и определить руководящие принципы для автоматического создания правил, возможно, введя новые правила на уровне печатной платы.

Кроме того, в мире моделирования конечного результата потребуется разработать или приобрести совершенно новую технологию. Для эффективного решения этих аспектов сначала придется предпринять ряд стратегических шагов.

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

Даже для элементарного решения, которое я предложил, было бы очень полезно получить какой-то ввод.

Например, я продолжаю говорить о «Сети питания», но нахожу этот термин в лучшем случае двусмысленным. Здесь мы использовали термин «Линия питания». Каковы ваши мысли?

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

Как всегда, мне очень хотелось бы прочитать ваши мысли и идеи здесь.

Пожалуйста, оставляйте их в разделе комментариев ниже.