Design Rules and Verification

Ensure your designs meet technical specifications with automated design rule checks and verification processes for higher accuracy and quality.

Altium's Design Rules and Verification Solutions Constraints Documentation

Filter

見つかりました

Sort by

統合環境における制約駆動設計とルール駆動設計 1 min Thought Leadership 競合他社のツールをご利用のユーザー

競合他社のツールをご利用のユーザーもし、人生のルールが自動的にチェックされたらどんなに素晴らしいだろうか。私はイタリア料理を作るのが好きだが、料理本とトマトソースの鍋の間を行き来するのは疲れる。キッチンでの唯一の自動ルールチェック機構はオーブンタイマーだ。幸いにも、PCBデザイナーにとっては、制約とルールのチェック機能を含む高品質のソフトウェアパッケージがあり、レイアウトと回路図を自動的にチェックできる。ルーティング、スペーシング、伝搬遅延、ファンイン/ファンアウト、ビアに関する設計ルールをPCBに設定する能力は、PCB設計ソフトウェアの必須機能となっている。しかし、すべてのPCB設計ソフトウェアが同じように作られているわけではない。異なるプログラムでは設計ルールの定義が異なる方法で表示され、設計ルールは異なるインターフェースで定義され、いくつかの表示は他より直感的である。 PCB設計ソフトウェアは、設計ルールと制約を設定するだけでなく、これらのルールが回路図とレイアウトにどのように表示されるか、特定のアプリケーションに対してルーティング制約と指示をカスタマイズする柔軟性を提供すべきである。統合設計環境で作業するとき、設計ルールはプログラムの一部で定義され、レイアウト全体に適用される。制約駆動型対ルール駆動型設計制約ベースの設計とルール駆動型設計は、基本的な原則の下で動作します。定義された設計ルールに対してレイアウトをチェックし、設計者に違反を表示します。しかし、表面を掘り下げると、これらの方法論の間の主な違いは設計環境に関係しています。制約駆動型設計を使用する一部のPCB設計ソフトウェア会社は、複数のプログラム間で制約定義を受け渡します。これが統合設計環境と呼ばれているにもかかわらず、設計はユーザーインターフェースの下で真に統合されていません。真に統一された設計環境はこれを克服します。すべての制約定義とチェックが単一の統一インターフェースで行われます。回路図キャプチャプログラムからレイアウトプログラムに制約を送信する代わりに、回路図とレイアウトを一つの屋根の下で真に統合するソフトウェアを使用するのはどうでしょうか？言われているように、ルールは破るためにあるものです。すべての設計ルールがすべての状況に適用されるわけではなく、設計ソフトウェアの仕事は、ルールを破ったときに通知することです。デザイナーやエンジニアとして、そのルールがデバイスが適切に機能するために本当に重要かどうかを決定するのはあなた次第です。レイアウト内のルール違反を明確で視覚的な方法で示すグラフィックをカスタマイズできるべきです。誰もルール違反のリストをスクロールして、モデル内の違反要素を手動で探したいとは思いません。一部の設計ルールは他のルールよりも優先される必要があります。これを念頭に置いて、設計ソフトウェアはどの設計ルールをプロセスで優先するかを定義できるようにするべきです。これにより、優先順位の順にルールが順次チェックされます。このタイプのルールチェックは不必要なルールの衝突を防ぎ、統合設計モデルを使用するソフトウェアパッケージ内でのみ機能します。 Altium Designerのルールエディタ制約と設計ルール：不足した場合はどうなるのか？多層ボード、 HDIアプリケーション、高速設計、および高周波設計において、ビアのパラメータと隣接する機能とのクリアランスを定義することは非常に重要です。これらの重要な構造に対する設計ルールを定義する際には、設計プロセスの各ステップでルールが設計にどのように影響するかを正確に表示するグラフィカルインターフェースを含めるべきです。ビアとルーティングパラメータのグラフィカル表現を含まないソフトウェアは、設計者が抽象的な識別子に基づいてすべての設計ルールの意味を記憶することを強いるため、重要なルールを無視したり、誤って他のルールを適用したりする可能性があります。これはまた、新しい設計者が設計ソフトウェアに慣れるまでの時間を増加させます。 PCB設計ソフトウェアが、トレースクリアランスやビア設計のようなものにのみ設計ルールが適用されるという視点を取る場合、重要な機能に関する設計ルールを定義する機会を失います。信号整合性、高速設計、ルーティング指示、およびその他の仕様に関するルールは同様に重要であり、回路基板に同様の容量で影響を与えます。あなたのソフトウェアにこれらの設計ルールが含まれていない場合、これらの重要な要件を満たしていることを確認する唯一の方法は、シミュレーションを含めるようにプロセスを調整することです。これらの領域の問題を修正することは時間がかかり、設計とシミュレーションの間を行き来する必要があります。設計とシミュレーションのソフトウェアが統合された設計環境に組み込まれていない場合、状況はさらに悪化します。設計ルールはルーティングだけに関するものではありません複雑なデバイスに取り組むとき、設計ルールは不可欠です。おそらく、制約エディタ、設計ルールチェック、

デザインルールによるコンポーネントの電力定格の最適化 1 min Thought Leadership 私は、自分が最初に設計した回路が認定に失敗したことを今でも覚えています。それは証明済みの設計で、既に以前の認定に合格していたものなので、テストが失敗したことをマネージャーから聞かされたときには非常に驚きました。「火がついた」と噂が広まりました。電子回路が実際に発火することは稀です。ほとんどの場合は、多少煙が出るだけです。どちらにしても、PCB上の焼け焦げが事実を物語っていました。トランジスタが過熱し、暴走して発煙したのです。しかし、なぜそのような結果になったのでしょうか? それは証明済みの設計でした。何が変わったのでしょうか? 簡単な調査の結果、回路は同じであることが証明されました。同じコンポーネントで、同じ入出力で、ロットや製造業者さえも同じでした。1つだけ変化したのはレイアウトでした。私がこの基板をレイアウトしたとき、機械的アセンブリの部品の周囲に収まるよう、フォームファクターを調整する必要がありました。パワートランジスタの周囲の銅箔は、元々は約1平方インチでした。この設計では、その1/3に切り詰められました。面積の制約のため、電力を生成する他のコンポーネントは、PCB上で理想よりも近くに配置されました。この両方の要因から、狭い面積の銅箔では放散できない大量の熱が発生し、トランジスタが早期に破壊されることになりました。重要なコンポーネントを定量化するデザインルールのリストを維持知識の移行はほとんどの場合、現場において最大のボトルネックで、多くの時間を必要とします。理想的には、全ての設計者が元の設計を構築するときにきちんとノートを作成し、思考プロセスを保存するべきです。しかし、a) 面倒である、b) ノートが消失することから、実際にはほとんどの場合これは行われません。問題なのは、机上では実証済みの設計を再利用するのが効率的ですが、ノートが十分に作成されなかった、または知識の移行が不完全であったために、重要な設計パラメーターの多くが忘れ去られている場合、設計パラメーターを推量してチェックするために時間を浪費するということです。いくつかのデザインルールを組み込むと、小さな変更により設計が不良になることを回避し、チームの設計時間を節約できます。これを最初からうまく行うには、次のような方法を使用します。デザインルールを作成して組み込み、恒久的に引き継がれるようにする私は、意味のあるルールを好みます。このため、管理を行うデザインルールを割り当てる前に、消費電力についての制約を定義することが重要です。このための最良の方法は、データシートを作成することです。適切に作成されたデータシートには一般に、電力定格についてベストからワーストまで、最低でも3つの区分の条件が含まれます。最初の定格は、コンポーネントのみが、自由な空間で消費する電力です。これは、ワーストケースの消費電力と考えられます。 2番目の定格は、コンポーネントが「一般的な」形式でFR-4銅箔のPCBに半田付けされたときの消費電力です。この「一般的」とは主観的な用語です。この電力の値は平均値と考えられますが、可能なら経験的に検証する必要があります。 3番目の定格は、ベストケースの消費電力です。これは、コンポーネントが 1平方インチ、2オンスの銅箔上に完璧に取り付けられた場合に達成されます。この値は、実際に達成することは困難な理論値と考えるべきです。計算に使用する消費電力の値は、一般的な値とベストケースとの間での主観的な判定となります。どれだけの電力を消費する必要があるかが判明したら、ルールを作成します。これによって、その設計を誰かが使用するとき、元のデータシートをチェックする必要もなくなります。ただしこれは、注意を払う必要がなく、データシートの文書化がいい加減でもいいという意味ではなく、バックアップや、設計をさらに明確化するために使用するということです。今日の設計ソフトウェアにはコンポーネントライブラリが付属し、コンポーネント評価の時間を節約できると同時に、ユーザーが特定のコンポーネントにルールを添付できます。レイアウトに十分なヒートシンクが使用されていない場合、まだ仮想の設計であるうちに「デバッグ」する方が、実際に火を吹いてからやり直すよりもはるかに楽です。