プレシリコンソフトウェア開発の最適化

今日の急速に変化するテクノロジーの時代において、市場のニーズを処理するための最も一般的なアプローチは、システムオンチップ（SoC）です。 SoCは基本的に、機能アクセラレータとそれがサポートする関連周辺機器用の多くのI / Oに囲まれたプロセッサです。 2002年のモバイルデータ革命以来、スマートフォンを定義する主要な機能を促進するためにSoCを使用することが前提条件になっています。同様に、SoCはそれ以来、テレビ、自動車、拡大を続けるモノのインターネット（IoT）市場などの「スマート」な消費者向け製品を作成するための頼りになるデバイスになりました。

SoCに対する需要の高まりは、非常に競争の激しい市場を生み出しました。このため、SoCはより複雑になり、SoCの周辺機器は継続的に進化し、市場投入までの時間は短縮されています。 SoC開発の複雑さに対応するための重要なコンポーネントは、ソフトウェアの可用性です。間違いの余地はほとんどなく、ソフトウェアはできるだけ早く準備する必要があります。この課題に対処するには、SoCパーツが利用可能になる前にソフトウェア開発を開始する必要があります。

SoCソフトウェア開発

従来、ソフトウェア開発は、最初のシリコンサンプルが製造から到着した後に開始されていました。 SoCサンプルが到着すると、ソフトウェアチームと検証チームが開発活動を開始し、SoCの大規模な立ち上げ作業が開始されます。 SoCに取り組んでいるチームは、SoCの立ち上げをサポートするために、限られた時間だけ1つの屋根の下に集まるように世界中から集まっていました。

ソフトウェア開発は通常、最初のサンプルが到着してから生産の準備が整うまでに数か月かかりました。その間に、シリコンの検証が完了し、関連製品の大量生産を開始するための信頼性が制限されます。

ただし、SoC設計の複雑さが増すため、通常はソフトウェア開発に数か月かかるものが、ソフトウェアの生産準備が整うまでに数年に及ぶ可能性があります。サポートされる周辺機器の数の増加とそれらの周辺機器の進化も、対象分野の専門知識にギャップを生み出しました。ソフトウェアチームは、これらのドメイン（オーディオ、ビデオ、USB、イーサネットなど）の専門知識を持つ新しい開発者を調達することにより、これらの特定のギャップを埋める必要があります。

プロジェクトの早い段階で本番環境に対応したソフトウェアを提供できるようにするために、ソフトウェア開発はシリコンの最初のサンプルが利用可能になるまで待つことができません。ソフトウェア開発をできるだけ早く開始し、さらに良いことに、SoCハードウェアの設計を開始すると同時に左シフトアプローチを採用する必要があります。プレシリコンソフトウェア開発は、SoC実装のバグを特定し、金属修正またはフルマスクテープアウトのコストを削減する可能性もあります。これらの要件を満たすために、いくつかの方法論が検討されています。

プレシリコン開発アプローチ

SoCテープアウトの前にソフトウェア開発を開始するには、開発者はソフトウェアプロトタイピング、RTLテストベンチ、FPGAボード、ハードウェアエミュレーターなど、いくつかのアプローチを使用できます。これらのアプローチは通常、個々のモジュールに焦点を当てているため、これらのアプローチにはそれぞれ、目的から独自の課題があります。個々のモジュールではなく、SOC全体を起動するためのソフトウェアを開発することです。問題をより小さなモジュールに分割する場合、ドライバー開発を開始する前に最初に必要なことは、開発中の各プロセッサー、アクセラレーター、または周辺機器の知識です。

システムCモデル

C動作モデルはSoCのIPごとに構築でき、スタンドアロンソフトウェアドライバーはこれらの動作モデルでテストできます。しかし、このアプローチにはいくつかの問題があります。まず、膨大なソフトウェア作業が必要です。つまり、モデル自体の実装をサポートするには、大規模なソフトウェアチームまたは専用のモデルチームが必要です。したがって、モデルの開発は費用効果が高くありません。第二に、行動モデルの精度は開発者の解釈に依存します。 IP設計の所有者とモデル開発者の間の通信ギャップは、不正確な動作を引き起こす可能性があります。これにより、設計の誤解に関連する問題を修正するために多くの無駄な労力が発生します。

RTLテストベンチ

この不正確な問題に対処するために、Verilogテストベンチを使用することもできます。テストベンチは通常、検証のためにSoC設計チームによって開発および保守されます。 Verilogテストベンチは、SoCのレジスタ転送言語（RTL）仕様に基づいており、一部のIPブロックだけでなく、完全なSoCを表します。したがって、サイクルごとに正確です。 RTLが開発されると、テストベンチはそれとロックステップで移動します。これにより、開発中のSoCの最新かつ正確な表現が保証されます。ソフトウェア開発の目的で、Verilogテストベンチを使用してソフトウェアドライバーを開発することもできます。

この方法を使用して開発されたソフトウェアは正確であり、製造プロセス後にSoCサンプルが到着したときのソフトウェアの起動時間を短縮するのに役立ちます。しかし、このアプローチには問題があります。 Verilogテストベンチはサイクル精度が高いため、非常に低速です。このような環境でソフトウェアを開発することは可能ですが、開発とデバッグには非常に時間がかかります。この方法でドライバーを開発するには、数か月かかる場合があります。 Verilogテストベンチは、はるかに早く開始することで使用できる場合があります。ソリューションの速度が遅いことを考慮して、プレシリコンで必要な時間を本質的に増やします（ただし、テストベンチの可用性によって異なります）。別のアプローチでは、別のソフトウェアチームがこの方法論を使用できます（シリコン前の開発にのみ取り組んでいます）。基本的に必要なリソースの数を増やすため、C動作モデル法の問題と同様にこの問題を取り除くことはできません。

実際には、不正確または長い開発サイクルを受け入れることはできません。また、通常の設計サイクルのタイムラインを維持するためにリソースの数を複製または増やすために必要な追加コストを受け入れることもできません。したがって、プレシリコンソフトウェア開発への別のアプローチを検討する必要があります。このアプローチには、フィールドプログラマブルゲートアレイ（FPGA）での各SoCIPブロックのエミュレーションが含まれます。

FPGAプロトタイプ

最新のFPGAはかなり高速であり、FPGAはRTLから構築されているため、サイクルごとに正確です。設計の複雑さが増すにつれて、IPブロックには数年前よりもはるかに多くのゲートがあります。数年前、FPGAはASICゲートの数によって制限されていました。つまり、より大きなロジックブロックを単一のFPGAに収めることはできませんでした。これで、ブロックごとにFPGAを構築し、それらに高速で正確なドライバーを開発することができます。

この方法論はより高速であり、ソフトウェアチームが早期に時間を費やす必要はありません。統合されたSoC設計全体ではなく、個別のIPブロックごとに機能するため、このアプローチでは、ソフトウェアが完全なSoCレベルの開発を行うことが制限されます。さまざまなIPブロックがどのように連携して機能するかについての統合の詳細は省略されています。したがって、この方法では立ち上げの労力は軽減されますが、関連するSoC統合の詳細が欠落しているため、ギャップが存在します。この方法は、変更の数が限られているが、SoCソフトウェア開発に必要な完全なカバレッジを必要としない派生SoCにとっては許容できるアプローチである可能性があります。

クリックすると拡大画像が表示されます

図。プレシリコンソフトウェア開発ソリューションの概要。 （出典：Nitin Garg）

SoCエミュレーター

精度、速度、およびカバレッジの問題に対処するために、SoCエミュレーターを使用するより堅牢なアプローチを採用することができます。非常に大規模で複雑なSoCをエミュレートできる市販のSoCエミュレーターがたくさんあります。 SoCエミュレーターはRTLに基づいているため、正確であり、Verilogテストベンチよりも100倍高速であるため、ソフトウェア開発に非常に適しています。それらはかなり高速であるため、完全なOS移植とドライバー開発を妥当な時間で実行できます。 SoCエミュレーターはSoC全体を拡張できるため、ソフトウェア開発は最終的な実稼働SoCにより適しています。

プレシリコンソフトウェアの開発と設計にSoCエミュレーターを使用すると、全体的な開発ギャップを排除または削減できるため、ソフトウェアの立ち上げ時間と労力が削減されます。ソフトウェアは、SoCエミュレーターの標準JTAGツールを使用してデバッグすることもできます。エミュレーターは、R​​OMの開発と検証、ファームウェアとOSの開発、IPまたはSoCレベルの検証などの複数のタスクに使用できます。 SoCエミュレーターのもう1つの興味深い機能は、開発ボードに搭載されているような実際のコンポーネントにSoCを接続できることです。たとえば、エミュレータで実数または仮想のNANDデバイスをSoCに接続し、ROMやOSドライバなどを開発することができます。

SoCエミュレーターは、他のソフトウェア開発アプローチよりもはるかに多くの可能性を提供します。エミュレーターは、SoCをUART、I2C、さまざまなディスプレイ、ストレージデバイス、PCIeデバイス、イーサネットやWi-Fiなどの接続デバイスに同時に接続し、カメラやセンサーなどのデバイスをキャプチャできます。言い換えれば、SoCエミュレーターは実際の開発ボードを表すことができるため、Androidのような完全なフレームワークを立ち上げ、SoCをテープアウトする前に完全なユースケースを実行できます。たとえば、Androidを起動してSOCエミュレーターで数フレームのビデオをデコードするには数時間かかる場合がありますが、SOCパフォーマンスの分析には非常に役立ちます。

SoCでの周辺機器の可用性が高まっているため、SoCエミュレーションは、テープアウト前の設計の弱点を浮き彫りにするパフォーマンスベンチマークにも非常に役立ちます。この機能により、SoCの未確認のパフォーマンスの欠点に関連するリスクまたはその後のテープアウトを減らすことができます。 SoCエミュレーターを使用すると、サードパーティのIPに必要な場合は、SoCをサードパーティのFPGAまたはソフトモデルに接続することもできます。

SoCサンプルの到着後に問題をデバッグすることは、実際のハードウェアと同じOS、ドライバー、およびフレームワークを実行するという事実を考えると、エミュレーターでも役立ちます。多くの場合、信号レベルで調査できるように、シリコンで観察された問題をエミュレーターに複製する必要があります。エミュレータとシリコンの間で同じソフトウェアを使用すると、問題をより速く、より正確に再現でき、チップ内の詳細に完全にアクセスできます。

さまざまなSoCソフトウェア開発アプローチを比較すると、シリコン前の開発とシリコン後のデバッグの観点から、SoCエミュレーターを使用する方が適切です。ソフトウェアチームがSoCエミュレーターを実行するためのコストは高額に思えるかもしれません。しかし、本番ソフトウェアをより早く利用可能にし、リスクとコストを削減することによってSoCエミュレーターが提供する貢献は、市場目標までの時間への影響を考慮すると非常に貴重であることがわかります。他のソフトウェア開発アプローチは同じカバレッジを持たないため、リスクが高く、より大規模なソフトウェアチームのリソースが必要になる場合があります。考慮されるすべての要因は、SoCエミュレーター以外のソフトウェア開発アプローチを使用すると、比較してはるかにコストがかかることが判明する可能性があります。

図2.各ソリューションの実行速度の比較。 （出典：Nitin Garg）

ムーアの法則によれば、集積回路（IC）の機能が向上するため、トランジスタ数は2年ごとに2倍になります。今日のARMベースの64ビットSoCのほとんどには、1億から3億の論理ゲートがあります。現在のSoCソフトウェア開発アプローチのうち、SoCエミュレーターは、今日の競争の激しい市場でのSoCの複雑化に伴う課題に直面しているソフトウェア開発チームのニーズを拡張し、サポートすることが証明されています。

参考資料

1. Triimberger、StephenM。「FPGAの3つの時代」。 IEEE XploreフルテキストPDF： 2015年、ieeexplore.ieee.org / stamp / stamp.jsp？arnumber =7086413。
2. BRUNET、JEAN-MARIE。 「現代のSoC設計がエミュレーションを採用する理由。」 組み込みコンピューティング設計 、2018年9月5日、embedded-computing.com / Embedded-computing-design / why-modern-soc-designs-embrace-emulation。
3. 「Socエミュレーション」。 Socエミュレーション 、2019、www.aldec.com / en / solution / hardware_emulation_solutions / co-emulation–soc-emulation。
4. 「より多くのコンポーネントを集積回路に詰め込む。」 http://www.cs.utexas.edu/ 、2006、cs.utexas.edu / 〜fussell / courses / cs352h / papers /moore.pdf。