アジャイルSoC設計:実用的なワークフローを実現する方法

2022年3月11日

「他の人に対してあなたが持つことができる唯一の持続可能な優位点は機敏性(アジリティ)、それだけです。」 (ジェフ・ベゾス)

最良のワークフローは、機能しなくなるまで唯一の存在です。次の設計のテープアウトまで、SoCチームは設計の制約とプロジェクトのマイルストーンを満たすために、実績のあるワークフローに依存しています。よくあることですが、ワークフローのさまざまなフェーズで設計上の制約やプロジェクトのマイルストーンが変化します。つまり、新しいテクノロジーノードの新たな課題によって以前のワークフローが適応できないことがあります。そのため多くのSoCチームは、とらえどころのないテープアウトのマイルストーンと制約を満たすために、ワークフローを絶えず調整する必要がありました。
アジャイル(機敏)は、変化、生産性、予測可能性、および品質に対応するソフトウェア開発チームの能力を向上させるために、90年代に最初に導入されました。そうです、それは長い間存在していました。それ以来25年間のデータは、アジャイルがウォーターフォールよりもほぼ2倍以上の可能性があることを示しています。さらにアジャイルはウォーターフォールに取って代わり、ソフトウェア開発に最適なプロジェクト管理として70%以上の企業が使用しています。 (Djurovic, 2020) 世界中の72,000人を超えるメンバーで構成される、非営利組織であるアジャイル・アライアンスなどの強力なサポートコミュニティが構築されています。
残念ながら、ハードウェアでのアジャイルの成功は、ソフトウェアよりもはるかに少数です。 Paul CunninghamがEETimesの記事 “Agile Verification for SOC Design” で示唆したように、ハードウェアでのアジャイル化は、ソフトウェアのように明示的なラベル付けがなされていないため、制限されている可能性があります。もう1つの考えられる理由は、アジャイルがソフトウェア開発の概念として始ったので、スクラム、かんばん、エクストリームプログラミング、FDD、アジャイルマニフェストなどの多数の専門用語が、プロジェクトをできるだけ早くテープアウトしたいSoCチームに二の足を踏ませていると言う事実です。 一見アカデミックなソフトウェア開発の概念を採用しない方がよいでしょう。
一般的なSoCワークフローは、プロジェクトのタイムラインに比べてサイクルが短い複数の個別のタスクで構成されています。完璧でタイムリーな引き継ぎを期待する社内顧客にサービスを提供する、さまざまなチームによって開発されたIPを使用する、テープアウトするために複数のECOフローが必要、さまざまな地域のチームとコラボレーションが必要、多くの計画変更に対応することが期待される・・・にも関わらず、アジャイルはハードウェア開発には適していないということをよく耳にします
批評家はアジャイルの潜在的なメリット、変化に対応しやすい、プロジェクト成功率の向上、より良い協調性、そして高い品質の成果物に焦点を当てるのではなく、ソフトウェアプロジェクトとハードウェアプロジェクトの違いが、アジャイルを採用するオールオアナッシングの提案のように攻撃する傾向があります。議論の真実は、アジャイルの採用がパッチを当てることができなくなった現在のプロセスを改善する、などの実際的な小さなニーズに駆り立てられたものだと言う事です。
ソフトウェア開発で確立された実績から段階的で実用的なステップを経て、ハードウェア開発のためのアジャイルの類似点と利点に焦点を当てることは、良い考えのように思われます。ですが幸いなことに、SoC設計のウォーターフォールワークフローが非常に連続的に見えても、アジャイルの原則を採用することで改善の機会が存在するのです。次の図は、世界中のSoC開発チームの典型的な高レベルのワークフローを示しています。
(1)のフロントエンド設計チームは米国西部にあり、(3)の米国中部地域のチームによって開発されたソフトIPを使用しています。(2)のバックエンド設計チームはインドにあり、(4)のヨーロッパのチームによって開発されたハードIPを使用しています。各チームのコンピューティングリソースは、全てが社内、全てがクラウド上、または社内とクラウドのハイブリッド構成を使用しています(5)。
フロントエンド設計チームのワークフローは、設計仕様やHDLでのモデリングなどの様々なフェーズを経由します。その後、機能シミュレーションとフォーマル検証が実行される検証フェーズが続き、論理合成とテスト容易性が続きます。この設計フェーズは通常、数千のジョブを、同じくらい多くの比較的小さいファイルを使って並行に実行し、各フェーズを繰り返して割り当てられた時間がなくなった後、最終的にバックエンドチームに引き渡されます。
バックエンドチームはバイナリファイル、ハードIP、マクロ、メモリなど、はるかに大きなファイルサイズを常に処理する必要がありますが、とはいえ、別のフェーズでは反復的な処理も行う必要があります。フロアプラン、配置と配線、ECOなどの物理的な設計作業は反復的な作業です。同様に、寄生抽出、DRC / LVS、タイミングECO、電力およびシグナルインテグリティ解析も通常、サインオフの前に複数回実行する必要があります。
念頭に置くべき事は、各IPチームにも独自の反復ワークフローがあるでしょうし、各チームは異なる場所にいる可能性があると言う事です。反復と変更を安全かつ簡単にするための機能を備えた、共通の設計および協調プラットフォームを想像するのは難しいことではありません。スケーラブルなクラウドコンピューティングを利用して、生産性ツールとの統合でチームを融合させることは、実用的なアジャイルSoCワークフローの基盤として非常に有益です。
ここで HCM(ハードウェア構成管理)プラットフォームが登場します。 HCMは以前から存在し、多くのSoC設計チームがすでに設計に使用しています。しかしながら、チームの機敏性を向上させるためにその潜在能力を活用するのではなく、部品表(BoM)の作成やリビジョン管理などの限定されたタスクにしか、HCMが使用されていない事があります。これは非常に残念な事で何故なら、主要なHCMプラットフォームは最新のテクノロジーのニーズに応えて進歩し続け、新しいリリースごとにSoCワークフローでアジャイルを採用するのにますます適した機能が提供されているからです。次の図を考察してください。
この図はアジャイル対応のHCMプラットフォームを示しています。(1)レビュー協調ツールである、Review Boardとの統合を通じて、コード、ドキュメント、およびグラフィックスのレビュー機能を提供しています。 (2)Jenkinsなどのオープンソース自動化ツールとの統合により、プラットフォームから反復タスクを簡単に実行できます。 (3)Git、Perforce、SubversionなどのSCMツールに接続して、SCMツールのリポジトリで作成されたIPの使用と管理を可能にします。(4)クラウドコンピューティングを活用し、水平展開への無制限なスケーラビリティを実現するために、柔軟性を備えた最高のクラウド・プロバイダーによってサポートされています。(5)プラットフォームは JIRA, Bigzilla Redmine, TARC などのイシュー・トラッキング、プロジェクト管理にも接続しているため、設計工程と問題の記録、追跡が可能です。
ソフトウェアの場合も同様ですが、アジャイルを採用するにはツールを導入するだけではできません。
しかしながら、ツールがすべてのチームメンバーに、自動化の進行を説明するので、頻繁な変更とワークフローの改善に役立ち、コラボレーションを促進します。これは、採用を成功させる事に大いに役立ちます。
適切なツール無しにアジャイルを採用することは、未舗装の道路でレースカーを運転しているようなものなので、そのうちドライバーは車に不満を言うようになるでしょう。
Cliosoft SOSなどのアジャイル対応のHCMプラットフォームは、実用的なアジャイルSoCワークフローへの理想的な第一歩として、前向きな導入体験を確実にするでしょう。Cliosoft SOSの主な特徴は次のとおりです。
1) ハードウェア設計者のためにゼロから設計されており、ソフトウェア開発目的で設計されたSCMの上に追加構築したものではありません。ハードウェア設計者を念頭に置いて構築されたネイティブなHCMプラットフォームは、次のようなハードウェア設計手法に適した主要な機能を備えています。

A、SoC設計に存在するすべてのデータ型とサイズ、数百万の小さなサイズからGBからまでのテキストとバイナリのファイル、例えばレイアウトブロック、コンポジットなど、を効率的に処理可能です。

B、設計フェーズをプロジェクトビューに構成する機能、必要に応じてプロジェクトやファイルのブランチやマージを簡単にサポートできる柔軟性。

C、データにラベル付けして設計の状態を伝達し、コミュニケーションを容易にします。また、様々なSoCワークフロー、設計、検証、テストなどのフェーズ内で、反復を促進します。

D、オブジェクトを混合したグループにして、階層的なデータ管理を可能にします。

E、ACL(アクセス・コントロール・リスト)で制御される、安全でかつ柔軟なチェックアウトベースの作業領域をサポートします。

2) シンプルで直感的なGUIと包括的なCLI(Command Line Interface)が、SoC設計のすべてのフェーズで、設計業務を加速します。

3) 主要なEDAツールとの統合がユーザーの立ち上げ時間を最小限にします。

4) シミュレーションやテストなどのタスクを調整するJenkinsや、コードとドキュメントのレビュー・ツールであるReview Boardなどの自動化ツールとの統合
 
5) Bugzilla、Jira、Redmine、TRACなどの一般的な問題追跡ツールとの統合により、設計管理プラットフォームから記録が可能。
 
6) Git、Perforce、Subversionなどの他のSCMツールに接続して、さまざまなリポジトリの設計データを使い、設計全体を管理できます。
 
7) 少人数で同じ場所でも、数百人が世界中に分散する組織でも、プロジェクトの共同作業を統率することができます。
 
8) クラウド・コンピューティングに依る水平スケーラビリティが、効率を向上させます。主要なクラウド・コンピューティング・プロバイダーとのハイブリッドな、又はフルクラウドの展開をサポート。
 
9) “sparsely populating”ワークエリアなどの継続的な機能改善により、ユーザーはワークエリアに素早くポピュレートし、ディスクとiノードの使用量を大幅に削減できます。プロジェクトをプログラム的に構成する能力が、プロセスの自動化に役立ちます。
これらの特徴はワークフローに実用的な利点を提供するので、SoCチームメンバーがアジャイルの採用を容易にする事を助けます。言い換えれば、アジャイルSoCワークフローをどのように展開するかは重要ですが、それぞれがプロジェクトに実用的なメリットをもたらすでしょう。
アマゾンのジェフ・ベゾスはかつて、「今日のように変化の早い時代には、再発明する以外に方法はありません。他の人に対してあなたが持つことができる唯一の持続可能な優位点は機敏性(アジリティ)、それだけです。」と言いました。この考え方は、20年以上にわたって会社を導いてきた、機敏であること、と言うAmazonの1日目の原則をもたらしました。 2015年にAnnapurna Labsを買収してから、Amazonがクラウド上で完全なSoC開発するまでに3年以上かかりました。Amazonはクラウドインフラストラクチャを所有していますが、この変革は一夜には実現しませんでした。
 
SoC設計にアジャイルを採用するのは気が遠くなる事のように思えるかもしれません。ただし、他のすべての場合と同様に、最初の一歩を踏み出すことが重要です。実用的なアジャイルSoCワークフローは、Cliosoft SOSなどの主要なHCMプラットフォームを使用して実現できます。SOSの関連する機能を展開し、定期的に最新リリースにアップグレードして機能を強化する事で、改善の恩恵を受けることができます。なぜ待っているのですか?