最近のブログ投稿「パワーネット管理」について、非常に興味深く、有益なコメントが多数寄せられました。多くの人が議論に参加してくれるのを見ると、私にとって心温まることです。これらの貢献は、パワーマネジメントの領域がいかに広大で複雑であるかを理解するのに役立ちました。
最近のブログ投稿「パワーネット管理」について、非常に興味深く、有益なコメントが多数寄せられました。多くの人が議論に参加してくれるのを見ると、私にとって心温まることです。これらの貢献は、パワーマネジメントの領域がいかに広大で複雑であるかを理解するのに役立ちました。皆さんにとって、どのようなタイプの設計を行っているにせよ、明らかに非常に重要な領域です。
これらのコメントの多くは素晴らしい提案やアイデアを提供しています。これらを一つにまとめ、整理し、前進するための明確で有用な方法を示すことを試みたいと思います。
この問題に取り組むにあたり、まずは対処すべき問題をより明確に定義し、分類することから始めたいと思います。そうすることで、電力管理を「エネルギー消費」(言葉遊びをお許しください)が少なくなるようにするために、各問題または問題のクラスごとに、可能な解決策のアプローチを提案しようと思います。その際、これらを実装するために必要な開発努力を見積もろうと思います。
最初のタイプの問題は基本的なものです。
各電力ネットワーク(コンポーネントに電力を供給するために関与するネットのセット)は、最終的には何らかの外部電源に接続されるべきです。また、任意の外部電源もどこかに電力を供給するべきです。特定の電力ネットワークでは、基本的な予算制約を守るべきです(生成される電力は消費される電力以上であるべきであり、共通のネットに接続するデバイスの動作電圧範囲は一致するべきです)。また、電力ネットワークが信号(プルアップやプルダウンを指します)と相互作用する場合、実際のエラーを覆い隠すような偽のエラーが生成されるべきではありません。
次に、より複雑な性質の問題があります。
各電力ネットワークの予算は、供給されたものが適切に分配され(各部品が正しく機能するため)、最終的にはあらゆる可能な運用状況下で収集されるように、正確に管理されるべきです。懸念されるのは、供給側でどの電圧の下でどれだけの電流が提供され、それがどのように収集され返されるかです。
最後に、もっと高度な問題があります。
最終的には、使用される部品の電力要件を物理的に満たす方法でPCBを設計する必要があります。繰り返しの作業やエラーを避けるために、これらの設計制約は回路図情報から自動的に計算されるべきです。そして、結果が適切であることを確認するために、最終的なPCB設計をシミュレートする必要があります。これらは、電力および分割面の設計、ルート管理、熱管理、部品のストレスなどの問題領域に関するものです。
最初の一連の基本的な問題については、電力ネットワーク、そのノードとその基本的な特性を定義する手段があれば、基本的なチェックを比較的簡単に実行し、設計者の注意を潜在的な問題に集中させることができると思います。
私が考えている基本的なチェックは次のとおりです:
重要な問題は、これを実装する実用的な方法は何かということである。
まず、電力ネットワークを「構築」する方法を考えてみましょう。電力ネットワークとは、単にそれが必要な部品に電力を提供するために関与するネットのセットに過ぎません。
私は、これを定義する目的を達成するための良いメカニズムとして、部品の透視図を見つけます。
前の投稿で提案されたグラフィカルな表現が適切でないことを理解しており、完全に指摘された点を理解しています - 以前に描かれたように、それらは混乱を招き、誤解を招き、不必要に設計スペースを clutter する可能性があります。
彼らの主な目的は、ある特定の意図(ここでは、電力ネットワークの定義)に対して、2つのネットが結合されるべきであることを伝えることです。電力管理の場合、彼らは単にワイヤーとして機能し、したがって、電圧に大きな影響を与えない部品に配置されるべきです。
これは、彼らの振る舞いとグラフィカルな表現に反映されるべきです。画面上では、例えば関連するピンの上にマウスがホバーしたとき、および/またはいくつかの設定や好みに応じて、明示的な方法でのみ可視化されるべきです。ただし、(そもそも可視化される場合に)どのように見えるかは、まだ決定していません。印刷物や出力からそれらを除外することが可能であるべきです。また、一対多の関係を許容することもできます。ライブラリまたは設計のコンテキストのいずれかに配置することが可能になります。
それでは、電力ネットワーク上で基本的な電気特性を定義するために必要なことを見てみましょう。私は、「Power」ピンタイプを「Power Supply」と「Power Sink」の2つのタイプに置き換え、ピンパラメータに電気特性を埋め込むことが一般的なアイデアであると理解しています。しかし、いくつかの理由でそれが不安に感じます。
まず、ライブラリと設計の文脈でのデータ更新の問題が提起されます。古いパワーピンを考えた場合、新しいソフトウェアに移行する際には、それが供給源か、それともシンクかを判断しなければなりません。今日の実情を考えると、簡単な答えはないようです。同じ問題が、ソフトウェアのさまざまなバージョン間でデータが行き来する際の後方互換性にも存在します。
第二に、命名とこれらのタイプ(電源供給/シンク、電流供給/シンク、正/負の参照...)に基づく概念に関して意見が分かれているようです。負の電源供給に関しても混乱が生じる可能性があります。
また、部品の特性が、それらがさまざまな設計でどのように使用されるかによって変わるという問題もあります。これは、調整可能なレギュレータから一般的なコネクタによって供給される電力に至るまで様々です。設計内で部品のピン自体を変更することは常に可能ですが、厳格なデータ管理(例えば、ライブラリからの更新やデザインアイテムマネージャーの使用時)に関しては危険が伴うアプローチです。
ここで前進するために必要だと思われるのは、接続ピンの特性を簡単に宣言できるようにする、より柔軟なシステムです。
この観点から、イアンが提案した「タギング」のアイデアが気に入りました。「パワータグ」とは、単に接続の説明です。これは、タイプ(プロデューサーまたはコンシューマー)、電力定格、電圧範囲、および自由記述テキストによって定義されます。ピンに配置されると、そのピンの電気特性を宣言します。ライブラリコンテキストまたは設計コンテキストのいずれかに配置することができます。
次に、電力ネットワークが与えられた場合、基本的なチェックを簡単に実行できます:
以下の画像は、上記で説明した全体的なアプローチを示しています。この例では、2つの電力ネットワークが定義されています:5V0と3V3。
パワージャックが5V0を全ネットワークに供給します。この状況は設計固有のものであるため、直接回路図上でパワータグが5V0レールに接続されたパワージャックピンの電力特性を記述しています。
スイッチによって電源をオンオフできます。ネット+Bと5V0は同じ電源ネットワークの一部であり、実際には同じ電圧にあるため、ピン1と3、およびピン3と2をリンクするために2つのシースルーが追加されます。スイッチは常に「透明」なので、これらのシースルーは、回路図ライブラリ内のschシンボル自体に追加されてもよかったです。
その後、レギュレーターが5V0レールを3V3に下げます。
5V0はオーディオパワーアンプに供給されます。ピンに配置されたパワータグがその特性を記述します。消費電力値は最悪のシナリオを記述します。これは、回路図ライブラリ環境または回路図自体で行うことができます。
3V3はタッチスクリーンコントローラーに供給され、そのピンの特性は適切なパワータグによって記述されます。
その後、5V0に対して簡単な電力チェックを実行できます:
5V0の生産者
ピン |
生産された電力(W) |
J19-1 |
5 |
合計 |
5 |
5V0の消費者
ピン |
消費電力(W) |
U1-1 |
1 |
U26-2 |
1.3 |
U26-10 |
1.3 |
U26-15 |
1.3 |
合計 |
4.9 |
このネットワーク上でも、すべての電圧範囲が一致しています(J19-1が5V0を提供し、U1-1が2V7〜6V0を必要とし、U26-2、10、15が4V5〜5V0を必要とします)。
3V3においても、同様の検証が行われます:
3V3の生産者
ピン |
発生電力(W) |
U1-5 |
480 x 10-3 |
合計 |
480 x 10-3 |
3V3の消費者
ピン |
消費電力(W) |
U48-10 |
80 x 10-6 |
U48-1 |
750 x 10-6 |
U48-9 |
10 x 10-9 |
合計 |
830.01 x 10-6 |
また、3V3ネット上でも、動作電圧範囲が一致しています(3.2V〜3.4V、1.2V〜3.4V、2.7V〜3.6V、2.7V〜3.6V)
この改訂されたアプローチに基づき、数ヶ月以内にこれらの基本的な問題に対処する効果的な解決策の実装に向けての明確な道筋が見え始めています。
また、要求に応じて全ての電力ネットを強調表示し、その正確性の指標を示すことも可能であるべきです。
同様に、Power Tag内でグループインデックスを使用して生産者をグループ化する簡単なメカニズムは、どの生産者が同時にアクティブになるか(従って合計されるべきか)を示すことを可能にします。例えば、冗長電力システムの場合です。システムは、チェックを実行する際にこれを考慮に入れることができます。
また、アシストされた電力予算管理のより複雑な問題にも対処したいと思います。
関与するコンポーネントの完全な電気特性とそれらがどのように接続されているかを考慮して、全ての計算を行い、宣言された制約が常に満たされているかどうかを報告できるツールが非常に有用であると理解しています。この見解に同意します。
それを何らかの満足のいく方法で実装するためには、Spiceシミュレーションエンジンを導入する必要がありますが、これは明らかに可能です。
ライブラリや設計に適切なシミュレーションモデルを追加することの重要性に加えて、すべての可能なケースを確実にカバーできるかどうかはまだ確信が持てません。多くのデバイスの消費電力は、実際の運用方法に依存します。これを実現するためには、Spiceシミュレーションエンジンがデバイスのプログラミング方法と、これらのプログラムされたデバイスが環境とどのように相互作用するかを考慮に入れる手段を備える必要があります。
これは非常にエキサイティングなプロジェクトのように聞こえますが、長期的な視点で合致するものです。私には、さらに考察し、調査し、話し合う価値があるように感じられます - おそらく将来のブログ投稿で!
最後に、自動ルール生成と最終設計シミュレーションの高度なトピックも、効果的に対処できれば同様に有用に見えます。しかし、その最終的な実装への道のりはさらに不透明です。
自動ルール生成に関しては、たとえば回路図レベルでバイナリルールを定義する能力のような、ソフトウェア内で解決すべき多くのアーキテクチャ上の問題があります。その後、自動ルール生成のガイドラインを明確に調査し、定義する必要があり、場合によっては、PCBレベルで新しいルールが導入される可能性があります。
また、最終結果のシミュレーションの世界では、まったく新しい技術を開発するか、または取得する必要があります。これらの側面を効果的に対処するためには、まずいくつかの戦略的なステップを踏む必要があります。
これはかなり長い投稿になりましたが、この主題に対する関心が高かったため、慎重な分析と同じくらい詳細で正直な回答が求められたと思います。私の目標は、数ヶ月以内に効果的に展開できる有用な解決策への道筋を明確に示すことです。
私が提案した基本的な解決策についても、いくつかの入力が非常に役立ちます。
例えば、「電力ネットワーク」という言葉を何度も使っていますが、この用語は最善とは言えないほど曖昧だと感じています。ここでは「電力線」という用語を使ってみました。皆さんの考えはどうですか?
また、部分的に透けて見えるグラフィカルな表現と、電力タグには非常に慎重な検討が必要になるでしょう。上のイラストに描かれているのは単なる草案に過ぎません。皆さんの提案をお待ちしています。
いつものように、ここで皆さんの考えやアイデアを読むことを非常に楽しみにしています。
以下のコメントセクションに投稿してください。