長年にわたり、私は多数のマイクロコントローラー ベースのプロジェクトに取り組んできました。主に Microchip の PIC を使用しています。私はさまざまなマイクロコントローラー シミュレーターを使用してきました。実際には、マイクロコントローラーが単独で存在することはなく、ファームウェアの動作は環境に依存します。ただし、私が使用した sim はどれも、マイクロコントローラー以外のものに対してまともなサポートを提供していません。
最初に考えたのは、ボード全体を Verilog でモデル化することでした。しかし、CPU モデル全体を作成したくはありません。また、私が使用しているチップの既存のモデルを見つけることができませんでした。とにかく、その詳細レベルで proc をシミュレートする必要はありませんし、したくもありません。また、通常のプロセッサ sim が提供するデバッグ機能を保持したいと考えています。
理想的なソリューションは、従来のプロセッサ シミュレータと Verilog モデルを接続するハイブリッド シミュレータであると思われます。
そのようなものは存在しますか？
FPGA に組み込まれた Altera Nios II プロセッサを使用しました。アルテラは、シミュレーターでカスタム ロジックと共に CPU を (そのソフトウェアと共に) シミュレートするためのツールチェーンを提供します。CPUのVHDL / Verilogコアをダウンロードすることで、同様のセットアップを実現できると思います（オープンコアを試しましたか？そこにはたくさんのものがあります）。
ただし、気が遠くなるほど遅くなるので、この方法で複雑なプロセス全体をシミュレートすることを期待しないでください。期待できる最善の方法は、問題をデバッグするための細かいソフトウェアとハードウェアの相互作用ポイントをシミュレートすることです。より詳細なシミュレーションが必要な場合は、組み込みの監視コードを使用して FPGA で実行することを検討してください。
「ボード全体をシミュレートする」アプローチの場合、Free Model Foundryには多数のモデルがあり、一部はVHDLで、その他はVerilogで利用できます。ただし、新しいモデルを作成するには料金が必要です。これらは、ボードが正しく構築されていることを確認するのに非常に役立ちます。
しかし、PICをデバッグするときのより一般的なアプローチは、ボードを作成してからファームウェアで作業することだと思います。チップの世界（ファームウェアがまだ製造されていないチップ内のマイクロプロセッサで実行されている場合）では、設計の一部をエミュレータにコンパイルできる非常に高価なシステム（またはシステムで時間を借りる）に頼ることがよくあります。残りの設計は通常のシミュレータ環境で実行されます。チップ用の高価なマスクセットの障壁がなければ、回路基板のコストは正当化できません。FPGAを使用したSimulink（Mathworks）のクリエイティブなアプリケーションについて聞いたことがありますが、私の記憶では、コンピューターでシステムを実行するか、デバイスをプログラムして同じことをリアルタイムで実行しました。
ケイデンス（Palladiumについて尋ねる）とメンター・グラフィックスの両方が、それに費やすお金があれば、その統合されたソリューションを持っていると思います。
私が最近行ったことは、シミュレーション環境とホスト システム間のインターフェイスを作成することです。異なる hdl シミュレーターには異なるインターフェイスがあり、シミュレーターを従来のシミュレーション モデルであるバッチ モードではなく、実際の設計のように永久に実行することが問題の半分です。
次に、C (または何でも) を使用してホストから抽象化を作成できます。これにより、どのターゲットに対してもアプリケーション ソフトウェアを作成できる場合とできない場合があります (使用している言語とコンパイラの機能によって異なります)。たとえば、一般的な poke と peek 関数を作成し、最終的なターゲットに実際に poke と peek メモリまたは I/O を持たせることができますが、抽象化によるシミュレーションでは、同じメモリ サイクルをシミュレートするシミュレーションでテストベンチと対話します。
さらに一歩進んで、ホストとテスト ベンチの間に (Berkeley) ソケットを使用して、ホスト アプリケーションが停止および開始している間もシミュレーションを実行し続けることができるようにしました。アプリケーションを起動し、それらを最後まで実行し、別のアプリケーションを起動する OS を備えた実際のプロセッサを持っているのと同じです。少なくともテスト アプリケーションの場合、配信用のアプリはおそらく 1 つだけです。
これらの抽象化レイヤーを作成することで、ビルド時にターゲットで使用される実際のアプリケーションを作成できます。最初にロジックのソフトウェア シミュレーションを使用する方法に沿って、抽象化インターフェイス (ロジックを捨てる) を使用して fpga を構築したい場合は、uart などを言います。アプリケーション抽象化レイヤーとシミュレーターの間のシムを uart インターフェイスなどに置き換えます。次に、プロセッサとロジックを同じチップまたは同じボードに結合するときは、抽象化レイヤーを、対話しているにもかかわらず常に持っているインターフェイスへの直接呼び出しに再度置き換えます。何かが壊れて抽象化レイヤーを保持している場合は、アプリケーションをシミュレーション モデルに戻して、すべてのロジック内部にアクセスできます。
具体的には、今回は sourceforge にある hdl 言語の循環 cdl を使用しています。ドキュメントには多少の助けが必要ですが、例を参照するとうまくいくかもしれません。また、合成可能な Verilog が生成されるため、さらに有利になります。私は、C シミュレーション モデルを接続して開始するために最低限必要なスクリプト以外のすべてのスクリプト バッチを破棄しました。したがって、私のテスト ベンチは C (技術的には C++) であり、ソケット レイヤーはそこで行われました。出力は、gtkwave が使用する .vcd ファイルにすることができます。基本的に、オープン ソース ソフトウェアを使用して HDL 設計の大部分をライセンスなしで行うことができます。CDL シミュレーション部分に 1 行または 2 行のコードを追加することで、無限ループとして実行することができました。これは機能していると言えます。まあ、メモリリークなどはないようです。
modelsim と cadence の両方が、ホスト C プログラムをシミュレーションの世界に接続する方法を標準化しており、そこから IPC を使用して、抽象化レイヤー API と通信するホスト アプリケーションにアクセスできます。
これはおそらく写真のやり過ぎです。とにかく、より高速でCフレンドリーなアームベースのマイクロのために、しばらく前に写真をあきらめました。ここでやろうとしていることではありませんが、シミュレーションに簡単に組み込むことができるオープンコアの写真があります/ありました。
通常、RTL レベルで CPU をモデル化する必要はありません。少しずつ何をするかはあまり気にしないので。通常、レジスタ値、メモリ、バスアクセスなど、それが何をするかを気にします。
最も単純なのは、Bus Functional Model での呼び出しです。これは、多くの場合、テキスト ファイルに基づいて、CPU が行う読み取りと書き込みを生成するだけです。これらは、一部の CPU と多くの一般的なバス (PCI、PCIe など) で利用できます。これらは超高速でシミュレートします。
次のステップは、機能的なサイクルアキュレート モデルです。それらは高速にシミュレートします。多くの場合、暗号化されています。
最後は完全な RTL モデルです。これらは通常、CPU ベンダーと密接に協力している場合 (たとえば、ASIC でコアを使用している場合) にのみ利用できます。あなたが大企業でない限り、通常、これらは暗号化されています。
メモリ モデルは通常、サイクル精度です (Micron など)。
私が見たものではありません。最善の策は、uC と FPGA 間のインターフェイスと動作を適切に定義してから、自動テスターを使用して適用できる一連のテスト波形を定義することです。FPGAまたはuC（波形の適用、割り込みの監視、ブレークポイントなど）から自動テスター（またはおそらくロジックアナライザーにそのような機能があるかもしれません）を作成する必要があります。本当に必要な場合は、Opencores.org が VHDL として定義された PIC および AVR のような 8 ビット uC コアを持っていることを知っているので、プロジェクト全体を FPGA に実装し、それをデバッグするだけです。
ハードウェア部門の同僚は、FPGA シミュレーション ソフトウェアを頻繁に使用して、タイミングのバグを見つけたり、奇妙な動作を追跡したりしています。
1 ～ 2 ミリ秒のシミュレーションには数時間かかる場合があるため、非常に小さなこと以外にシミュレーターを使用することはできません。
ただし、SystemC を見たいと思うかもしれません。http://en.wikipedia.org/wiki/SystemC