SSDソフトウェアの開発とシステム・バリデーションをシフト・レフト

最近はNetflixで映画やテレビドラマをストリーミング再生したり、YouTubeに動画をアップロードしたりすることが当たり前となるなど、日常生活で消費または生産するデータの量が指数関数的に増大を続けています。それに加え、自動運転車の実用化に向けたADASの大きな進歩や監視カメラの普及など、リアルタイムにやりとりされるデータの量も急増しています。

こうしたデータ量の増大に比例して、データ・ストレージに対する需要も高まっています。今や、ストレージ容量16 GBのスマートフォンではゲーム、音楽、動画の保存もままなりません。スマートフォン以外にも、多くのスマート機器が何らかのデータ・ストレージを必要としています。現在の自動車は、地図データ、音楽、更にはドライブレコーダーの録画情報を記録するためのストレージを内蔵しています。しかし、今挙げたのは身近なコンシューマ機器の例に過ぎません。消費者にサービスを提供する側のエンタープライズ・サーバーに目を向けると、そのストレージ需要は更に大きく、ペタバイト（1024 TB）単位の膨大な容量が必要とされています。

データ・ストレージには容量だけでなく、アクセス速度も要求されます。ストレージ・デバイスの用途によって、機器の起動時間や読み出しレイテンシなど求められるものは異なりますが、いずれにしてもデータ・アクセス速度が重要な指標となります。そのため、ほぼ瞬時の起動が可能で、ランダム・アクセスも非常に高速なSSD（Solid State Drive）への移行が着実に進んでいます。SSDの長所はそれだけではありません。ディスクを回転させてデータを読み出すハードディスク・ドライブ（HDD）とは異なり、SSDには可動部品がないため、静音性にも優れています。

このようにSSDには多くの利点がある一方、ハードウェアは複雑で、デバイスの動作に必要なソフトウェアはもっと複雑になります。特にSSDの場合、フラッシュ・メモリーの劣化と破損への対処がファームウェアを複雑にする要因となっています。

ウェア・レベリングは、「SSDで使用するフラッシュ・メモリーなど、消去可能なコンピュータ・ストレージ・メディアの耐用年数を延ばす手法の1つ」とWikipedia（英語版）に定義されています。フラッシュ・メモリー・ベースのストレージ・システムにウェア・レベリングを実装していないと、データの書き込みによって短期間で製品寿命が尽きてしまいます。これは、フラッシュ・コントローラがオペレーティング・システム（OS）からの論理アドレスをフラッシュ・メモリーの特定の物理アドレスに永続的に割り当ててしまうためです。つまり、一度書き込んだブロックに再度書き込みを実行する場合、同じ物理位置に対してRead-Erase-Modify-Write動作が発生します。これは時間がかかるだけでなく、アクセスが一部のブロックに集中し、そこだけが早く劣化するという問題を起こします。一部のブロックが書き換え限度回数に達すると、それだけでデバイス全体が使用できなくなります。

もう1つの問題は、フラッシュの破損です。フラッシュ・メモリーに対する書き込み/消去ルーチンを実行するようなシステムの場合、CPUがV_DD、温度、またはシステム・クロック周波数の定格外で動作中に、これらのルーチンが実行されるリスクが常に存在します。このため、フラッシュ書き込み/消去を最小に抑える（フラッシュの書き込みと消去はそれぞれコード内の1箇所にのみとどめる）こと、そしてCPUの動作を常に定格内に維持することにより、こうしたリスクを最小に抑える必要があります。

フラッシュ・メモリーの劣化と破損への対処に加え、SSDソフトウェアにはPCIe、NVMe、SAS、SATAなど幅広い種類のホスト・インターフェイスへの対応も求められます。そしてハードウェアとソフトウェアを含むSSD SoC全体を、さまざまなアプリケーション分野のベンチマークを使用してバリデーションする必要があります。

大容量化、高性能化、低コスト化が求められるストレージ向けSoCの新規開発スケジュールは厳しさを増すばかりで、ストレージ半導体企業は次世代SSD設計サイクルのなるべく早い段階でファームウェア開発を開始する必要に迫られています。

現在、多くのストレージ半導体企業が、バーチャル・プロトタイピング、エミュレーション、FPGAベース・プロトタイピングを活用したエンド・ツー・エンドのプリシリコン（実機完成前）ソフトウェア・ブリングアップおよびコントローラSoCバリデーション・メソドロジを導入しています。SoCのテスト・チップが完成してからソフトウェア開発を始めるのではなく、SystemCモデリング、初期RTLのエミュレーションへのマッピング、FPGAプロトタイピング・プラットフォームを使用することで、ソフトウェア開発の前倒し（シフト・レフト）が可能になります。これらの手法は個別に使用することもできますが、モデル、インターフェイス、解析ツールを各手法で共有するメソドロジの方が、効果を最大化できます。それでは、下図に示すエンド・ツー・エンドのソフトウェア開発およびシステム・バリデーション・フローについて詳しく見ていきましょう。

バーチャル・プロトタイピングは、実行可能モデルを最も早い段階で使用してファームウェア開発を開始する手法です。バーチャル・プロトタイプはSystemCモデルをベースにしており、RTLが完成しているかどうかは問わないため、設計中のSoCのRTL検証完了を待つ必要がありません。しかも仮想環境は動作が高速で、デバッグの可視性と可制御性も高く、故障注入をサポートした完全に確定的な実行が可能です。このように、ファームウェア開発においてバーチャル・プロトタイピングは、ソフトウェアの開発とテストを始めるのに理想的な環境となります。

エンド・ツー・エンドの開発およびバリデーション・プロセスの次のステージでは、初期バージョンのSSD RTLをエミュレータにロードします。バーチャル・プロトタイプをエミュレータに接続するハイブリッド・エミュレーションでは、デザインの既存のモデル（制御用プロセッサのモデルなど）を利用し、まずエミュレータ上でカスタムIPやSoCの一部の検証とバリデーションに専念します。バーチャル・プロトタイピングからエミュレーションへのメソドロジが真価を発揮するためには、エミュレータで仮想インターフェイスを扱えるようにすることが重要です。これによりブリングアップが容易となる他、性能および可制御性、可視性が向上し、バーチャル・プロトタイプからエミュレータへの移行が容易になります。ハードウェアおよびソフトウェア・デバッガと統合されたスマート・トランザクタ・テクノロジを利用すると、メモリー・プロファイリングによるシステム性能の検討と最適化を短時間で完了できます。SSD開発を容易にするには、組込みソフトウェアの関数スタック、レジスタ・プログラミング、ONFIバス・パフォーマンス統計データを可視化し、これらの相関を容易に理解できるようにすることが重要です。

最後に、実インターフェイスを使用した環境でSSDハードウェアおよびソフトウェア全体のバリデーションを実行します。ここでは、まずエミュレーション・トランザクタをターゲット・プロトコルのスピード・アダプタで置き換えます。これらのスピード・アダプタをFPGAベース・プロトタイプで再利用することで、プリシリコン・システム・バリデーションの最後の重要なステップへの移行がスムーズになります。これらのスピード・アダプタを使用してプロトタイプが動作するようになったら、プロトタイプの性能を最適化し、実インターフェイスの専用ドーターボードを使用してリアルタイム実行を開始します。これにより、SSDハードウェアおよびソフトウェアの完全なバリデーションが可能となり、実際の運用環境と同等の条件下でストレス・テストを実施することができます。

SSDはコンシューマ機器からエンタープライズ環境まで幅広く導入が進み、私たちに大きなメリットをもたらしてくれる一方、その開発には大きな困難が伴います。バーチャル・プロトタイピング、エミュレーション、FPGAベース・プロトタイピングを最適な形で組み合わせ、実機完成前からのフローをエンド・ツー・エンドでサポートしたメソドロジを導入することで、ソフトウェアの開発、検証、バリデーションが容易になります。

本稿でご紹介したメソドロジの一部については、SNUG Silicon Valley 2019でSK Hynix社のChunHok Ho氏から詳しいプレゼンテーションがありました。この講演では、最先端のSSDデザインで求められるプロトタイピングの主な条件、そして実インターフェイスを使用したソフトウェア・テストをサポートし、強力なデバッグ機能によってハードウェアとソフトウェアの問題を解決できる高性能マルチFPGAソリューションを導入した同社のファームウェア開発について説明がありました。

イベントの詳細は、こちらをご参照ください。