SpecC

1.2

関連活動（その3）

1.2.3　公開団体(コンソーシアム)<その2>

　1998年に設立されたVirtual Component Exchange(VCX)はIP取り引き事業と法律面を合理化した．この機構ではWebベースのツールを構築中で，ちょうど株取り引きがオンラインでできるのと同じように，IPのオンライン取り引きを可能にして，VCX会員会社にはこの取り引き上生じる保護，支援，持続可能な事業モデルが与えられるように配慮している．

　現状の業界で標準的なIP開発とその商品は，レジスタ・トランスファ・レベル(ソフトIP)あるいは物理レベル(ハードIP)であり，多くのベンダーが体験しているように，これらはシステム仕様設計者や実装設計者にとって取引上きわめて低い抽象度レベルに留まっている．システム仕様設計者の大半が使っている言語は，Cあるいはその派生言語であって，例えばITUが発表している通信標準の設計を見てもそれがわかる．英文で書いたコンポーネントやシステムの仕様記述は原理の理解には助けとなるが，一般的に「Cによる仕様」は詳細を知りたい実装設計者にはこれがもっとも良い参考書となる．したがって，実用的な理由でC/C++をシステム仕様設計者と実装設計者の間で取り交わすゴールデン・モデルとすることが望ましい．

　不幸なことに，Cはアルゴリズムを記述する仕様記述言語としては良いものだが，レジスタ・トランスファ・レベルのIPをモデル化する言語としては適切なものとは言えない．これを解決するためたくさんの研究が行われ，たまたま類似の技術的，事業的方策が生み出されている．CynAppsは最近Cynlibを発表し，C++クラス・ライブラリを使いC++でモデル・ハードウェアを記述できるようにした．Open SystemC InitiativeはSystemCと称する類似のライブラリを発表した．もしどちらかの言語が標準になったとすると，IP利用者は完全に自由にIPをC++で取り引きできるようになる．ちょうどこれはVSIAがソフトIPで成し遂げた目標と同じであるが，しかしながらソフトIPの場合には，安く，あるいは無料でC/C++コンパイラが使え，直ちにシミュレートできる状態にあるのにくらべ，上記の言語の場合はそうとはならない．CynlibとSystemCは効率よくC/C++をハードウェア記述言語に変換するから，仕様設計者と実装設計者は同じ言語で話しているように見えるが，しかしセマンティクスにギャップが残っている．つまり，システムの機能を仕様に移し替えるときは，各種の計算モデルから導かれることが多いが，システム・アーキテクチャは実装設計者が探索するものと考えられているから，これは容易な仕事ではない．IP供給者が所有しているIPコンポーネントのアルゴリズム表現をIPインテグレータ向けのRTL記述に変える作業は高位合成ツールに期待されているが，これはまだ満足のいくものが開発されていない．CynAppsとSystemCがPtolemyプロジェクトの方法をほとんど活用してシステム仕様を記述できるよう拡張することも可能だが，問題は人間がやる場合とかシミュレーション・エンジンだけだった時にくらべて，そこで記述された仕様が容易にシステム・アーキテクチャ探索ツールや動作合成ツールに理解できるものになるだろうかという疑問である．

　SpecC Technology Open Consortium(STOC)は日本の大手電子・半導体会社の支援で1999年に設立され，本書で解説しているSpecCをシステム・レベル設計の仕様記述言語として採用することを促進している．システム・レベル設計をRTLからC/C++へ移行したいという同じ意向をもっているが，SpecCはCynlibやSystemCのようにライブラリ・ベースの方式は採っていない．SpecC言語は当初SOC設計の要件を把握する目的で開発され，その後注意深く工夫されて十分に規定されたセマンティクスを携えて現状の構成に至った．

　SpecCの構成は既存のANSI-Cの拡張版に当たる．SpecCで記述した仕様がシミュレートされると，構成中の拡張部がシミュレーションAPI呼び出しに展開される．この展開はSystemCとCynlibの公開ソース・ライブラリで規定されたAPIとほぼ同一のものである．SpecCの場合はユーザが対話的に組み立てを行え，ライブラリをユーザが見える点が異なっている．仕様設計者側に許されている強力な抽象化と表現力の他に，さらにSpecC方式には次のような優位性がある．つまり，合成ツールの仕様を解析し理解するタスクがライブラリ・ベースの場合とくらべてたいへん容易になっている．ライブラリ・ベースの場合には仕様に使われるコードとシミュレーションに使われるコードの区別が付きにくいからである．

1.3　SpecCの目標

　いくつかの理由でSpecCは過去数年にわたって進化してきた．

(a)　SOCを作り上げる設計プロセスを定めるため，設計プロセスの各段階で，システムの仕様記述とモデリングを行える言語が必要となった．この目的でSpecC言語が作られ，SOC設計を行うときの実行可能な仕様を記述できる言語に成長させ，これを用いてシステムのサイクルを正しく記述した適切なSpecCモデルを作った．後の章で仕様から実装に進めていくリファイン・ルールについて説明している．

(b)　SpecCはモデルとツールで学習が行え，実験が行える，設計財産とIPを含んだSOCに対しての明快な方法論が確立できるSLDL(システム・レベル記述言語)として作られた．

(d)　SpecCはモデル製品を揃えて各種の応用領域に使えるようにし，その領域に特有な特徴を把握したり，検証と合成のための技術やツールに対する要件が何かを学べるようにした．

1.4　まとめ

　本章ではSOC設計上で考えられる課題と三つの方式を述べた．どの方式の場合も，システムの目的とする機能を記述できる仕様記述言語が必要となり，これを用いて中間段階の実装を記述する．

　本書ではこの目的で作られた言語SpecCを説明し，さらにSpecCを用いたシステム設計の方式論を展開する．第2章ではシステム・レベル設計に必要なモデル，アーキテクチャ，言語，方式論を論じる．第3章ではSpecC言語のシンタックスとセマンティクスを示す．第4章ではSpecC言語とモデルを用いたSOC設計，仕様に対する規則と手引き，修正，探索についての方式論を記述する．第5章では業界でも先端的なSOCの設計ケース・スタディでこの方式論の実演を行う．最後に，第6章でまとめを行い，将来の開発の展望を行う．

Copyright　2000　
著者　Daniel　D．Gajski　　Jianwen　Zhu　　Rainer　Doemer
Andreas　Gerstlauer　　Shuqing　Zhao
訳者 木下　常雄　　冨山　宏之

目次のページに戻る

新刊案内ページに戻る

新刊のご案内