SystemCはRTL設計も行えますが、それよりも上流のTLM(トランザクションレベルモデリング)での設計が行えることが特徴です(前ページ図1参照)。TLMでは、レジスタ間の細かいタイミングを考えずに設計できるため、アーキテクチャの設計を行うのに適しています。
抽象度の高いトランザクションレベルで設計&検証が行えることには、多くのメリットがあります。RTLに比べてコード量が少なくて済むため、コーディング時間など開発効率が向上します。また、検証(シミュレーション)も高速に行えます。時間概念のない「PV(Programmers View)」と時間概念が入った「PVT(Programmers View plus Timing)」の2つのレベルを記述することが可能になります。そして、SystemCではTLM設計におけるバスモデルとしてTLMライブラリがサポートされており、これもまた無償で提供されています。
以前のTLMライブラリ(TLM 1.0)は、ハードウェアのアーキテクチャを設計するには不十分な点などもあり、TLM 1.0を独自に拡張していたユーザーもいたようです。2006年12月にリリースされた最新版(TLM 2.0ドラフト版)ではさまざまな改良が施され、独自拡張せずそのまま使用できるレベルになりました。
以下に、TLM 2.0ドラフト版のTLMを使用したバスモデルの構造(マスタ側とスレーブ側)のアクセス方法を記します。
アーキテクチャ設計にSystemCを使用するメリットは、高速に設計&検証が行えることです。そしてさらに、そのアーキテクチャ設計からRTLを自動合成することも可能になりました。それを実現するのが「動作合成ツール」と呼ばれるものです。その取り組みは一昔前までは夢のようなことでしたが、現在は現実になりつつあります。
もっとも、初期の動作合成ツールは必ずしも評判が良かったわけではありません。というのも、動作合成ツールの登場当時は「SystemCのコードから、人間がコーディングしたRTL回路よりもスピード、面積などに優れたコードが生成される」「SystemCで開発を行えば、もうRTLの設計は必要ない」など、非常に期待されていたのです。こうした期待と現実とのギャップの大きさが、実際よりも印象を悪くしたといえるでしょう。
現在は動作合成ツールも進化し、ある程度合成を考慮して設計を行えば、人間が記述したRTLコードと同等のコードを生成するレベルまで来ました。ツールはまだ非常に高価ですが、開発者が何カ月もかけていた作業を数分で行えることを考えると、ツールによる自動合成には大きなメリットがあります。
今後も動作合成ツールは進化していきます。動作速度など、合成結果も向上しています。多くの人が使用するようになれば需要が増え、価格も安くなるでしょう。すると、どこかのタイミングで一気に普及することが考えられます。
「まったくRTLのコードを意識しなくてよい」ということにはならないにしても、将来的にはSystemCによりアーキテクチャ部分だけ設計し、ハードウェアのタイミングは自動合成するという形式での開発が当たり前になるかもしれません。
ハードウェアのモデルのみでSoCの検証は行えません。ソフトウェアとハードウェアの両方が必要になります。以前は協調検証の実施には非常に多くの時間が必要であったため、イテレーションを行うことは困難でした。しかし、STARC(半導体理工学研究センター)が開発した「バジェット追加技術」により、高速に協調検証が行えるようになりました。
バジェット追加技術は、ターゲットCPUでのソフトウェア実行をPCのネイティブコードで模擬することにより、ISS(Instruction Set Simulator)に比べて100〜1000倍高速なシミュレーションを実現する技術です。仕組みを簡単に説明すると、C言語で書かれたソースコードをターゲットCPUのクロスコンパイラでアセンブリコードにします。そのアセンブリコードを使ってブロック単位の実行サイクル数を解析し、C言語のソースコードにSystemCの時間関数(wait)を埋め込みます。こうして作ったモデルをSystemCシミュレータに掛けることで、高速・高精度なソフト/ハード協調検証を行います。
このように、SystemCを使用した新しい技術が出てきたこともSystemCの魅力の1つといえるでしょう。
関連リンク: | |
---|---|
⇒ | STARC(半導体理工学研究センター) |
⇒ | FastVeri(バジェット追加技術を利用した検証ツール) |
Copyright © ITmedia, Inc. All Rights Reserved.