Mobile menu
製造
ホーム 製造

製造

リソースライブラリでは、PCB設計とプリント基板製造の詳細を紹介しています。

How Design Decisions Affect PCB Fabrication

Live Webinars

See what upcoming live webinars we have scheduled and join us for one!

Live Webinars

Articles

View More Articles
SRAMユーザーのためのPCB設計のヒント：データ損失を防ぐ方法 SRAMとは何か？PCB設計のヒントとデータ損失の防止方法 1 min Thought Leadership SRAMは電源が切れるとデータを失います。 編集ソフトウェアの最高の発明の一つは、最悪のタイミングでマーフィーの法則が発動するのを防ぐオートセーブ機能です。数十年前、オートセーブ機能が存在しないことが、「保存」ボタンを押すことを渋っていた私にとって悪化し、重要な大学の課題の数ページが文字通り消去されたとき、私はほとんど泣きました。 電子機器では、SRAMを設計する際の課題を認識していないと、静的ランダムアクセスメモリ（SRAM）に格納されているデータ全体を失うリスクがあります。これは、SRAMが重要な変数を格納している場合、特にハードウェアの予測不可能な動作を引き起こす可能性があります。 SRAMとは何か、そしてどのように機能するのか？ SRAMは、組み込みシステム設計で一般的に使用される不揮発性メモリです。ロジカルビットで情報を格納し、動作電圧が供給されている限りその値を保持します。電源が切断されると、SRAM全体がデフォルト値、通常はロジック1に相当する値にリセットされます。 SRAMの内部は、複数のセルによって構成されています。これらのセルには、いくつかのトランジスタによって制御されるバイステーブルフリップフロップが含まれています。特定のアドレスに情報が格納されると、いくつかのフリップフロップがデータのデジタル値を表すように適切にラッチされます。 SRAMは電源が切れると情報を保持できないにもかかわらず、追加の作業用メモリが必要な設計で定期的に使用されます。FlashやEEPROMなどの他の揮発性メモリコンポーネントと比較して、SRAMは無視できる読み取りアクセス時間を持ち、データはランダムなメモリアドレスに書き込むことができます。 他の電子部品と同様に、SRAMは年々改良されてきました。SRAMが40ピン以上の大型コンポーネントであり、並列アドレスバスがまだ一般的なインターフェースだった時代は過ぎ去りました。今日のメモリメーカーは、 SPIやI2Cのようなシリアルインターフェースを備えたSRAMを生産し、フォームファクターを8ピンまで大幅に削減しています。 SRAMを設計する際の主要な考慮事項 SRAMの設計にさらなる考慮を払うことで、大きな違いが生まれるかもしれません。 SRAMを使った設計は簡単な作業のように思えるかもしれません。結局のところ、ピン数が少ないメモリチップを使った設計が何が難しいのでしょうか？しかし、経験上、実際には多くの問題が発生する可能性があることを学びました。部品選択から製造後の問題に至るまで、多くの問題に遭遇する可能性があります。ここでは、初心者レベルのPCB設計者に役立ついくつかのヒントを紹介します： メモリ容量 最大容量のSRAMを選ぶべきでしょうか？それともプロジェクトの要件に合ったものを選ぶべきでしょうか？これは、ファームウェア開発者を悩ませる質問であり、ハードウェア設計者にとってはそうではありません。メモリメーカーは通常、同じ物理パッケージで異なる容量のSRAMを導入します。これは、メモリ容量の選択が変わっても設計を変更する必要がないことを意味します。 インターフェースタイプ SRAMでよく使用されるインターフェースにはSPIとI2Cがあります。SPIはデータの書き込みと読み出しに4つの物理ピンを必要としますが、I2Cは2つの物理データ接続のみを必要とします。一般に、SPIはより高速なアクセスを提供しますが、SPIバス上の各ICに個別の制御信号が必要です。I2Cは、複数のメモリチップがマイクロコントローラに接続されている場合に理想的で、データ信号とクロック信号のみが必要です。 デカップリングコンデンサ 革新的な不揮発性メモリー、フラッシュや FRAMのようなものが登場している今、バッテリーバックアップSRAMを設計することはほとんどないでしょう。これにより確かにSRAMの設計は容易になりますが、安定した電源供給の重要性を見落としてはいけません。SRAMのVccピンにできるだけ近い場所にデカップリングキャパシタを配置することを常に確認してください。電源の不安定さによるデータの破損は、絶対に避けたい最後の事態です。 デカップリングキャパシタは、グラウンドバウンスの問題を防ぐのにも役立ちます。 記事を読む
Altium 365がPCBアセンブリプロセスをサポートする方法 Altium 365がPCBアセンブリ（PCBA）プロセスをどのようにサポートできるか 1 min Engineering News プロダクションマネージャー プロダクションマネージャー プロダクションマネージャー エンジニアはもはや、ボード組み立てを行う際に紙のプリントアウトをめくったり、CADソフトウェアを操作したりする必要はありません。 記事を読む
持続可能性のための設計とプリントエレクトロニクス 持続可能性のための設計とプリントエレクトロニクス 1 min Blog 電気技術者 PCB設計者 エンジニアリング/テクノロジー幹部 +1 電気技術者 電気技術者 PCB設計者 PCB設計者 エンジニアリング/テクノロジー幹部 エンジニアリング/テクノロジー幹部 製造技術者 製造技術者 印刷エレクトロニクスが廃棄物、エネルギー使用量、有害物質をどのように削減するかを探求しましょう。エレクトロニクス製品のライフサイクル全体で持続可能な設計を推進します。 記事を読む
電子開発のための要件管理ツール エレクトロニクス開発に最適な要件管理ツールの選び方 1 min Blog システムエンジニア/アーキテクト 電気技術者 システムエンジニア/アーキテクト システムエンジニア/アーキテクト 電気技術者 電気技術者 スプレッドシート、メール、Word文書は、多くの電子開発チームにとって依然として要件管理ツールの主流です。それらは使い慣れており、柔軟で、使いやすいです。しかし、プロジェクトがより複雑になるにつれて、その場しのぎの要件管理はリスクとなります。 断片化した文書はメールやSlackのスレッドに閉じ込められ、チームメンバーやその他の関係者間での誤解を招きます。要件は進化しますが、下流のエンジニアが常に追いついているわけではありません。変更が発生したとき、その影響を追跡したり、完全に検証されたかどうかを把握する簡単な方法はありません。 その結果、プロジェクトの遅延、ボードの再設計、コンプライアンスの問題が発生します。 再作業の最大50%が要件の失敗に起因しており、失敗するプロジェクトの70%が要件の不備によって引き起こされます。解決策は単により良い文書ではなく、ハードウェア要件を扱うためのより良いシステムとツールです。 この記事では、電子開発のための要件管理ツールを評価する方法、避けるべき落とし穴、そして現代の協力的な電子設計チームにとって最も重要な機能について説明します。 なぜほとんどの要件管理プロセスが不十分なのか 表面上は、スプレッドシートやカンバンボードは要件管理に適した方法のように思えます。これらは情報を論理的で整理された方法で収集・表示するために設計されています。データはカテゴリ分けされ、フィルタリングされ、構造化されます。これらのツールは汎用性があり、異なるプロジェクトのニーズに合わせて形を変えることができるほど柔軟です。 しかし、非専門的なツールの一般的で高水準な性質が問題の一部です。これらは現代の電子機器開発の複雑さを扱うために設計されておらず、エンジニアやシステムアーキテクトが設計の反復とともに進化する数百または数千の要件を追跡するために必要な機能が欠けています。 最大の課題は可視性です。要件がタスク管理ツール、共有ドライブ、内部ウィキ、チャットスレッドに散らばっている場合、それらが最新の変更を反映しているか、またはテストケースが変更された要件をまだカバーしているかどうかを知る方法がありません。エンジニアは時間を無駄に二重チェックや相互参照に費やします。または、何も変わっていないと仮定することが、それよりも悪いです。 第二の問題はトレーサビリティです。専門の要件管理ツールがなければ、要件を設計要素や検証ステップにリンクすることは困難です。プロジェクトが終盤に近づくか監査の時になると、チームはなぜ、どこで決定が行われたのか、それがテストされたか、そしてそのテストが現在の設計の状態に対してまだ関連があるのかを再構築するために慌てます。 最終的に、これらの方法はスケールしません。チームが成長し、同時に複数のプロジェクトを手がけるにつれて、オーバーヘッドは指数関数的に増加します。スケールで切断された要件を管理する結果は、より多くの作業、より多くのやり直し、そしてより多くの無駄なお金です。 選んではいけないもの：要件管理ツールの一般的な落とし穴 要件管理用に市販されているすべてのツールがハードウェア開発に適しているわけではありません。多くは細かい点で失敗しますが、それでも電子設計のワークフローにとっては重大な影響を及ぼします。特に、チームがどんな構造化されたシステムでもアドホックな要件管理より良いと仮定する場合はなおさらです。 チームにとっての解決策を選ぶ際に避けるべき「機能」をいくつか探ってみましょう。 要件トレーサビリティ機能がない 一部のツールは、要件を静的なチェックリストのように扱います。それらは、要件を互いや回路図、テストケース、設計成果物にリンクする能力に欠けています。要件の収集には役立つかもしれませんが、それが終わると、本当に重要なコンテキストを欠いた構造化されたデータを持つことになります。 汎用タスクマネージャー ソフトウェア向けに構築されたプロジェクト管理プラットフォームは、自らをRMソリューションとして宣伝することがよくあります。しかし、要件をチケットとして割り当てることは、検証計画、ライフサイクル管理、またはECAD統合を効果的にサポートしません。要件データは収集され、レビューのために利用可能になりますが、プロセスの規律をツールの外で強制しなければなりません。 過剰設計されたレガシーRMプラットフォーム 一部のエンタープライズRMツールは、膨大な数の機能を備えていますが、現代の電子開発プロジェクトが求める使いやすさ、柔軟性、速度に欠けています。適切な手に渡れば、これらは優れたツールですが、専用の管理者、カスタムスクリプト、そしてチームを速く立ち上げるための数ヶ月のオンボーディングがしばしば必要です。これらは、迅速に動こうとするエンジニアリングチームには不向きです。 記事を読む