Applistar

2. 3 アーキテクチャ設計

TOP > 2 オブジェクト指向要求分析と設計工程 > 2. 3 アーキテクチャ設計
  2. 3 アーキテクチャ設計  

アーキテクチャ設計方法としては

  • プラットフォーム設計
  • トップダウン設計
の2つの方法があります。

2. 3. 1 部品を組立てて作るプラットフォーム設計

SoC を設計する時の一つの方法として、プラットフォーム設計方式 (Platform based system level design) があります。 これはある程度、定形的な SoC を想定して作る方法とも言えます。 これは、あらかじめある程度のアーキテクチャ

  • CPU
  • BUS形式

などを 決めておいて、その上に、 ハードウェアIPやアプリケーションソフトウェアを 追加・変更などをして設計する方法です。

なにもアーキテクチャ上の制約を設けず、 自由にトップダウンに決める方法をトップダウン設計と呼ぶとすると、 この方法はボトムアップ設計ということも出来ます。

プラットフォーム設計の 利点としては

  • ツールやIPまでも準備しておけるので、効率がいい
  • ソフトウェアやIPの再利用がし易い

ことです。 全く何もないところからシステムを作り上げるのに 比べて、現実的な設計方法とも考えられます。 高速協調検証システムでは、この方式の設計にも対応 しています。 本ガイドラインでは、既存のIP(RTL記述)をTLMで高速に シミュレーションするための抽象化方法を説明しています。

2. 3. 2  性能最適化設計

アーキテクチャ設計においては、SW部品の処理スピード が、要求条件にあっているか、など性能 の検証を行う必要があります。

そこで、SystemCで単純に並列プロセスのシミュレーション を行っていただけでは、性能の検証を行う ことはできません。 ここで重要な用件として、

  • SW部品は、選定したCPU上で何サイクルで処理が可能か検証可能
  • SW部品が遅い場合、HW部品に変更が簡単にできる
  • RTOSや、デバイスドライバなどの連携が検証できる
  • BUSの性能設計が可能
    • バスの占有率の検証が可能
  • キャッシュの効果が測定可能
  • 割込の機能を検証可能

などが挙げられます。

従来、ハードウェアとソフトウェアの検証は インストラクション・セット・シミュレータ (ISS: Instruction Set Simulator) と RTL で記述された周辺HW部品の 協調シミュレーション環境が提案され、利用されていました。

しかし、このISS + RTLの検証環境は以下のような問題点がありました。

  • ソフトウェアのデバッグに利用するには耐えがたいほど遅い
  • HW部品をRTLで記述するには大きな工数を必要とする
  • そのためハードウェア・ソフトウェアのトレードオフ設計を実行可能なモデルで検証することは困難

高速協調検証システムでは、上記の問題点を解決する 手段として、SystemCの機能を用いて、SW部品の命令実行サイクル数 を加味したシミュレーションを実現しています。

  2. 3 アーキテクチャ設計  
TOP > 2 オブジェクト指向要求分析と設計工程 > 2. 3 アーキテクチャ設計