NEWS
【#SCJ2010】高位合成の話題が多数、SystemCを設計で如何に使いこなすか
2010年7月2日、新横浜のホテルで、ESL言語「SystemC」にフォーカスした技術セミナー「SystemC Japan 2010」が開催された。
5回目の開催となる今年は、SystemC標準化団体のOSCIがセミナーの主催者に。ESLの広がりが追い風となったのか、エントリー数は過去最高を記録し、300名以上の参加者で会場は熱気に包まれた。
事前に実施したアンケートによると、セミナー参加者の担当業務は「管理職・プロジェクト管理」、「LSI（HW）設計」、「LSI（HW）検証」が多数派で6割以上。「アーキテクチャ/アルゴリズム設計」、「EDA評価/環境構築」がこれに続き、「SW設計」は少数派で1割未満だった。
SystemCの使用状況については、昨年よりも使用経験者が増加し、「使用中」または「使用経験有り」が全回答の4割以上。昨年までは「言語に触れた事が無い」という人が最多数だったが、今年は「言語を習得中」という人がそれを上回った。
また、SystemCの用途については、昨年まで最多数だった「機能検証」を上回り「動作合成」が最上位に。SystemCの普及効果からか、SystemC関連ツールの使用経験者の数も大きく増えた。
OSCIの委員でIEEE P1666のチェアを務めるCadenceのStan Krolikoski氏は、OSCI代表としてSystemCのアップデートの予定を紹介。
Stan氏によると、IEEEでは現在「フルスイング状態」でP1666-2005標準のアップデート作業を進めており、年内には新たなP1666-2011標準の策定が完了する予定。P1666-2011標準には、急速に採用が進んでいるOSCI TLM 2.0を取り込む予定で、2011年上半期でのIEEE承認を目指しているという事だった。
P1666-2011標準の先のアップデート計画について会場から質問が出ると、Stan氏は、未だ分からないが、ソフトウェアとのインタフェースが更に良くなる事を願っていると答えていた。
■株式会社リコー 塚本泰隆氏の講演
塚本氏は、ESL設計関連分野で豊富な講演実績を持つ有名人。過去にもSystemC Japanで講演した事があり、2度目の講演となる今回は、「動作合成とバーチャル・プラットフォームの統合に向けて」と題し、SystemCモデルの重複開発を解消する一つの提案を紹介した。
塚本氏によると、リコーでは2003年からESL手法による設計を取り入れはじめ、既に高位合成を用いたハードウェア設計やバーチャル・プラットフォームによるソフトウェア先行開発、システムレベルでの性能見積りを行っているが、用途に応じてSystemCモデルを個別にモデリングしなければならず、その「重複開発」を問題視していた。
今回塚本氏が提案したのは、動作合成用のモデルを修正すること無くバーチャル・プラットフォームに接続するためのOSCI TLM 2.0をベースとしたモデリング手法で、動作合成の対象ブロックとバスとのインタフェースに着目したもの。
同社の利用する高位合成「Cynthsizer」のForte社からヒントを得たというそのモデリング手法は、TLM 2.0の通信関数とレジスタI/F回路をターゲットポート（ソケット）に埋め込むというもので、これにより動作合成用とバーチャル・プラットフォーム用のモデルの共通化を実現。同じモデルをC++の「テンプレート部分特殊化」によって、TLMモデルとピンレベル・モデルに切り替えて利用する。同手法であれば、バスを変更する場合はソケット名を変更するだけで対応でき、バスI/F回路を隠蔽できるというメリットも得られる。
※下の画像は塚本氏の講演データ（リコー提供）
塚本氏によると、同モデリング手法で作成したモデルは、OSCIの「Simple Bus」、Synopsysの「Platform Architect」、Imperasの「OVP」、Forteの「Cynthesizer」で既に接続を確認済み。「テンプレートの部分特殊化」が使えるTLM 2.0ベースのESL環境であれば、モデルを利用できるという見通しのようで、「テンプレートの部分特殊化は絶対オススメ。是非使ってみて下さい！」と力説していた。
また塚本氏は、セミナー後のパーティーで締めの挨拶で再び登場。「動作合成ユーザーが増えた事に驚いた」とした上で、「もっと若いエンジニアに積極的にセミナーに参加してもらい、現場からのESL推進に一役買って欲しい」と語っていた。
■ルネサス エレクトロニクス株式会社 野中義弘氏の講演
野中氏は、「ルネサスエレクトロニクスにおける高位設計適用事例」と題して、高位合成前後の等価性検証手法を中心に講演を行った。
同社ではツールの選択肢の広さから高位設計用の言語としてSystemCを選択。その中心となる高位合成ツールはCadenceの「C to Silicon Compiler」を採用している。高位設計フローにおける検証の手順としては、可能な限り高位合成前にSystemCベースの検証を行うという方針で、機能検証、カバレッジ検証、I/Fのタイミング検証（サイクルベース）を実施。高位合成後は、検証済みのSystemCとRTLの等価性をCalypto社の「SLEC」を使って検証している。
等価性検証は、回路の複雑度に応じて処理時間が増加するため、ルネサスエレクトロニクスでは、それを抑える手段として、対応する変数とレジスタを指定する事を検討。しかし、人手でレジスタマップを指定するのは困難なため、Cadence、Calyptoに依頼し「C to Silicon Compiler」からレジスタマップを自動出力する機能を開発した。
その結果、「C to Silicon Compiler」の出力するレジスタマップを用いて「SLEC」で等価性検証を行うというフローを確立し、等価性検証の工数を大幅に削減。どうしても検証が収束しない場合は、人手でレジスタマップを追加していするという形をとる事にした。また、レジスタマップの指定と合わせて、入力パターン制約を設定することで等価性検証の工数削減を図っているという。
野中氏によると、ルネサスエレクトロニクスでは、既に複数の画像IPを「C to Silicon Compiler」と「SLEC」の組み合わせで設計完了しており、設計生産性の向上を確認済み。次なる課題は、デザイン全体の一括検証の実現という事で、既にCadence、Calyptoと両社のツール間I/Fの改善に取り組んでいるという。
■富士通アドバンストテクノロジ株式会社 中山典保氏の講演
中山氏は、「ASIC適用に向けた高位設計技術への取り組み」と題し、同社が試みた高位合成技術の適用評価結果を紹介した。
高位合成ツールの適用に際しては、その要件として「人手設計同等の回路規模」と良く言われるが、富士通アドバンストテクノロジでは、ECO対応、人手設計同等の低消費電力化、合成前後の等価検証もその要件とし、それら能力を実際に評価した。
同社が導入している高位設計用ツールは、ルネサスエレクトロニクス同様、「C to Silicon Compiler」と「SLEC」という組み合わせ。中山氏によると評価の結果、「C to Silicon Compiler」のインクリメンタル合成機能で所望のECO対応を実現できる事を確認。合わせて低消費電力化についても、入力となるSystemCを適切に記述すれば「C to Silicon Compiler」が最適なRTLを合成可能な事を確認した。等価性検証については、「SLEC」の利用によってその要求をカバー出来ているという。
※下の画像は野中氏の講演データ（富士通アドバンストテクノロジ提供）
また、中山氏は高位合成、等価性検証と合わせてSystemCの検証環境についても言及。SystemCのデバッグ環境としては「gcc」とCadenceの「Incisive」を利用。SystemCカバレッジについては、GNUのテストカバレッジツール「gcov」を利用しているが、フリーツールとして機能不足を感じているため、商用ツールでSystemCカバレッジをサポートして欲しいと訴えていた。
■株式会社プライムゲート 梅田芳直氏の講演
梅田氏は、「経産省委託研究「画像・動画処理用C 言語のLSI 化の支援システム開発」事例」と題して、同社の研究プロジェクトの内容と合わせて、C言語設計のあるべき姿を講演。設計会社の経営者という立場ならではの、経営視点の設計論を語った。
梅田氏の講演内容は、「C言語設計でムーアの法則に対処する」という考えをベースにしたもので、主に設計現場のマネージャー層に訴えるもの。経営資源の有効利用から、具体的なプロジェクト管理テクニックまで内容は幅広いものであったが、ポイントは大きく３つ。
まず、C言語設計を進めるにあたっては、これまで工数として定義されていなかった要素もふまえ、生産性を正しく定義し、プロジェクト全体の工数を一元管理することが重要という話。同社では、その実現に向けてJavaベースの設計フレームワークを開発し、可能な限り設計の効率化を追及し生産性を向上しているという。
次に、C言語設計は、C/C++とSystemCの併用が最適という話。梅田氏は、それぞれの言語の長所と短所を活かし、様々なデザインおよび検証に対し柔軟に対応する事で生産性を向上できるとし、その例として同社では3種類の高位合成を用途に応じて使い分けているという話を紹介した。ちなみに、使用している高位合成ツールは、Mentorの「Catapult」とNECの「Cyber」、そしてテクノレポ社の「Design Prototyper」。梅田氏は、ツールも設計者も適材適所が大事であると語っていた。
また梅田氏は、Cベース設計とSystemVerilogによる検証の組み合わせ手法も紹介。SystemVerilogはCベース設計との親和性が高く、アサーションやプロパティチェックなどを容易に適用可能とし、DPIを使えばC言語で記述した機能モデルとSystemVerilogの接続も簡単とその有効利用をすすめた。
そして梅田氏が講演を通じて繰り返し語っていたのが「設計IPの有効活用」。この話には2つの側面があり、一つは、設計する過程で出来るだけ会社の資産としてIPを残そう。そしてそれを別の設計で有効活用していこうという話。もう一つは、HDLの設計IPではあまり設計の効率化は望めない。より設計の効率化を図るためには、設計の上流工程におけるソフトIPの活用が必須という話だった。この話には、人的リソースを労働集約型から資本集約型へ変えていこうという、経営者梅田氏ならではのメッセージが込められていた。
■ソニー株式会社 蛯原均氏、旦木秀和氏の講演
蛯原氏と旦木氏は、「ソニーで成功しているSystemC設計フロー」と題して、1つの講演枠を2名で講演。蛯原氏は、ソニーで活用しているRTL実装前の「SystemCリファレンス」について、旦木氏は主に高位合成を用いた同社の設計フローについて紹介した。
「講演の入り方がカッコイイ」と某所でもつぶやかれていた蛯原氏の出だしは、日本の半導体が世界で勝てないのは、過剰な品質基準＝高コスト体質が大きな要因という話で、機能追加を繰り返す事でマージンが過剰になる日本の「積み上げ型」の設計スタイルと、限られたコスト内で要求機能を実現する海外の「バランス型」の設計スタイルの違いを指摘。高コストな設計を打破するカギは「SystemC」とした上で、同社で実践しているSystemCを用いたシステム設計の最適化手法を紹介した。
※下の画像は蛯原氏の講演データ（ソニー提供）
蛯原氏によると、ソニーではビット精度やデータの内部構造も表現できるSystemCを用いて、デザインのプロトタイプ（SystemCリファレンス）を設計の初期段階で要求仕様から作成。SystemCリファレンスを用いてシステムレベルの最適化を行い、システムの整合性を確認した上でそれをゴールデンとしてRTL実装を進めている。従来手法で言う仕様検討をSystemCリファレンスに、RTL実装を高位合成に、RTL検証をSystemCリファレンスとRTLの一致検証に、という形で3つの「置き換え」によって仕様を最適化できる設計フォローを実現している。
尚、蛯原氏によるとソニーでは、SystemCリファレンスと高位合成用SystemCの作成は、全く別のレイヤで作業をしており、同じSystemCでも分けて考えているとの事。それは、システムの最適化とハードウェア(実装）の最適化を区別しているからで、これにより後段の一致検証の精度が高まるという効果もあるという。
※下の画像は蛯原氏の講演データ（ソニー提供）
続いて蛯原氏は講演の途中で実際に作成したSystemCリファレンスのデモを披露。SystemCにWindowsのGUIの皮を被せたというフレームワークを用いて、カメラ画像処理LSI用に作ったSystemCリファレンスを実際に動かして見せた。同環境を利用すれば、Verilogでいうハードウェア・レジスタ同等のものが同じビット精度で見え、実機と同じ精度で画像を確認可能。安価な環境で、画質の調整に必要なパラメータのチューニング（合わせ込み）などを効率よく実現できるという事で、ソニーのカメラ画像処理LSIの開発の殆どで、SystemCリファレンスを用いた設計手法が導入されているという。
※下の画像は蛯原氏の講演データ（ソニー提供）
また、同フレームワークには、システム上の各ブロックを部分実行できる仕掛けがあり、SystemCリファレンスを用いたブロック単位のランダム検証が可能。SystemC,SystemVerilog,eなどを用いてRTL一致検証ベンチを作成し、SystemCリファレンスとRTLとの結果一致を見る事ができる。同検証手法ではカバレッジが100％になるようランダムを制御する事がポイントという事だった。
更にSystemCリファレンスを使えばファームウェアの基礎的な動かし方を見る事も可能。OSの構造や割込みハンドラなどを見るにはTLM2.0のバスやISSが必要となるが、SystemCリファレンスは、ファームウェアの先行開発にも役立てる事が可能であると蛯原氏は説明した。
続いて旦木氏の講演。
旦木氏は同社における高位合成の利用状況にフォーカスし、ここ3年間の実績とフローの変化について語った。
旦木氏によると、ソニーでは「高位合成はRTLの実装を効率化するものではあるが、全自動では無い。」という認識の下、これまでは高位合成の得意なところにフォーカスして設計で活用してきた。その例として旦木氏は、パイプライン機能の活用やリソース共有機能の活用を上げたが、そこに至るまでは数年に及ぶ試行錯誤があり、約3年前の時点でデータパス回路には高位合成が使えるという判断に至っていた。
その後、その有効性から、出来ればもっと高位合成の適用範囲を広げたいと考えていたところ、使用しているツールが「モジュラ・インタフェース」という技術で複雑なインタフェースを扱う事が可能となり、その用途が一気に拡大。2009年の実績で年間14件の設計に高位合成ツールを利用するまでになった。
※下の画像は旦木氏の講演データ（ソニー提供）
旦木氏によると、現在では、バス、CPUなど以外であればほぼ高位合成が適用可能という認識で、より短期間で設計を終わらせたいかどうかで、高位合成の適用を判断しているという話。ソニーでは、高位合成＝TAT短縮の手段という形で定着しているようだった。
（※利用しているツール名は未公表。SystemC入力でモジュラ・インタフェースが使える高位合成ツール。）
具体的に示された設計事例によると、RTL設計で3ヶ月を要するブロックを1ヶ月で完了。この1ヶ月の中には実機デモが可能なFPGAプロトタイプの工数も含まれており、そこからASICへの移行は僅か1日。動作合成をかけ直すだけで済んだという。旦木氏曰く、「大事なのは導入フロー。ちゃんとしたフローを作れば高位合成による短期間実装は確実。」そういった事例は社内で多数あり、直近では400万ゲートの回路を高位合成を用いて3ヶ月間で完了したケースもあるという話であった。
※下の画像は旦木氏の講演データ（ソニー提供）
尚、しばし人手設計よりも大きくなると言われる回路面積について旦木氏は、合成の過程で最適化は必要とする一方で、設計の早い段階で正確な回路面積見積もりを行う事も重要とし、回路面積の話は必ずしも高位合成ツールだけの問題では無いとした。
最後に旦木氏は高位合成利用における今後の課題を列挙。記述スタイルや合成制約の標準化、合成ツールの機能改善と合わせて、ツールを使う設計者の育成や教育環境の整備も課題に挙げていた。
｜ページの先頭へ｜