NEWS
「複雑なアルゴリズムのハード化に高位合成は不可欠」NECのCyber活用事例
2010年10月12日、19日の2日間、NEC組込みソリューション事業部は、東京と大阪で同社の高位合成ツールのセミナー「CyberWorkBench Forum 2010」を開催した。
今回は同セミナー東京会場にて事例発表を行った、日本電気株式会社 システムIPコア研究所 主任研究員の森岡 澄夫氏に、設計事例の詳細について話を聞いた。
森岡氏は、NEC内で新たな装置やハードウェアなどの研究開発に従事する人物で、研究成果の最終的なユーザーはNECグループ内各事業部およびルネサス。ある意味セット・メーカーに近い形で先進アルゴリズムのハード実装（IP化）に取り組んでいる。大きな意味では高位合成ツール「Cyber」の部隊と同じ屋根の下で活動しているが、あくまでも「Cyber」を設計で利用する現場のエンジニアという立場で事例を発表した。
森岡氏が「CyberWorkBench Forum 2010（東京会場）」で行った講演のタイトルは、「サブシステム規模セキュリティIPの全体構造設計における動作合成の活用」。同氏が取り組んだ新しいグループ電子署名アルゴリズムのハードIP化にあたり、如何に高位合成（CyberWorkBench）を活用したかについて紹介した。
森岡氏によると、今回ハードIP化を目指したグループ電子署名アルゴリズムは、RSAをはじめとした各種アルゴリズムを70回以上組み合わせて実現するもので、C言語記述で数千行以上。高位合成の適用事例としては、元のアルゴリズはC言語で数百?千行程度というのが大半で、人手のRTLと同等の回路が得られたというケースも珍しくないが、さすがに数千?1万行に及ぶCのコードを一括合成は難しいと、森岡氏はアルゴリズムのハード化に向けて、その回路構成の検討に「CyberWorkBench」を活用する事を考えた。
※画像はNEC提供のデータ
アルゴリズムのハード化にあたり、森岡氏はその全体的な回路構造は比較的単純な構成がイメージできたが、回路の性能（速度）や規模を左右する詳細な回路構造までは設計前の机上検討で目処を付ける事が出来なかった。アルゴリズムが巨大なため、個々の演算ユニットの接続の仕方やバスの数、制御の方法などによりデータの流れ方が全く変わり、そのデータの流れが回路の性能を決定付けるからだ。そこで森岡氏は然るべきデータを用いて回路の全体構成を検討すべく、ユニット単位で高位合成を実行。「CyberWorkBench」を利用して回路構成検討用の基礎データを集めた。
次に森岡氏は、収集した基礎データ（合成したユニット単位の各回路）の入出力帯域やレイテンシから通信オーバーヘッドを推定し、各ユニットを接続するトポロジーを決定。更にグループ署名アルゴリズムの回路アーキテクチャを検討するための「専用のスケジューラ」を自ら作り、ユニットの数や種類によってどう回路全体性能が変化するか評価し、最終的な回路アーキテクチャを決定した。
※画像はNEC提供のデータ
大規模アルゴリズムを高位合成で合成する際に、個々のモジュールに分割し個別に合成し、最終的にそれらを接続するという手法は珍しくないが、森岡氏は同様の手法でまず回路のアーキテクチャを実データで検討。自前の「専用スケジューラ」でトレードオフを行い、一括合成が困難なアルゴリズムを最適な形でハード化する事に成功。出来上がったRTLは難なくバックエンドを通過し、所望のパフォーマンスを持ったチップ化を実現した。森岡氏曰く、この手法はある意味「2段階の高位合成を行うに等しい手法」、小規模単位であれば「CyberWorkBench」のRTL合成能力が信頼出来るからこそ実現出来たやり方だという。
※画像はNEC提供のデータ
尚、今回の高位合成を用いた設計事例にて、森岡氏は幾つかの課題にも直面。その中身と解決策についても解説してくれた。
課題１：複雑なアルゴリズムの理解
今回ハード化のターゲットとしたグループ署名のアルゴリズムは、ようやくソフトで実用化されたもので、その処理内容をハード設計者が理解するのは非常に困難だった。そこで、アルゴリズム開発者とハード設計者の間のギャップを埋めるために、回路の全体構成はアルゴリズム開発者と共に決定。プロトタイプが動くまでは共同作業の形を取った。これによりハード化出来ない理由をアルゴリズム開発者に明らかにすると同時に、ハード設計者による勝手な仕様解釈を防いだ。
森岡氏は、先端アルゴリズムのハード化にはその作業体制も重要と指摘。具体的な作業分担については、同社でも色々と模索しているようだ。
課題２：言語の使い分け
やはり一般的にC言語設計の課題と言われる「言語の使い分け」については、同プロジェクトでも課題となった。C/C++でアルゴリズムを書くアルゴリズム開発者と、処理の並列性や時間の概念を必要とするハード設計者の共同作業でどう言語を使い分けていくか？ 今回の例では、幸いアルゴリズムの変更においてビット精度などが絡まなかった為、基本的にアルゴリズム本体はANSI-C、一部インタフェース部の記述追加にSystemCを使うというC/SystemC併用の形を取り、CPUによる制御の検証はFPGAで実施というスタイルで切り抜ける事が出来た。しかし、回路全体構造の表記や性能評価における言語の選択は常に課題としてつきまとう為、森岡氏も頭を悩ませているという。
課題３：Cと合成したRTLの等価性検証
これも高位合成ユーザー共通の悩みの一つであるが、今回のケースでは、デザイン規模が巨大かつ個々の動作合成単位で等価性をチェックしても回路全体として元のアルゴリズムと等価かどうか判断出来ないため、等価性検証は見送りFPGAでのランダム検証とRTLでのカバレッジ計測を実施した。森岡氏はある意味セットメーカー的な立場であったため、この検証でよしとしたが、「立場が製造側では、こうは行かないかもしれない」と語った。
課題４：ECO対応
特に今回のケースでECOを実施した訳では無いが、一般的に言われるECO対策について森岡氏は、「高位合成を使う使わないに限らず、大規模アルゴリズムのバグをECOで直すのは不可能」と断言。あらかじめ手を打ち、ハード設計前にアルゴリズムの検証は済ませるべきと指摘した。
課題５：セキュリティ上の問題
今回のケースでは、グループ署名アルゴリズムのハード化という事でセキュリティ対策として、「サイドチャネル攻撃」に対する対策を施していたため、Cコード中に幾つかのダミーコードが記述されていた。これを普通に高位合成にかけてしまうと、ダミー記述を無くされてしまう可能性があるので注意が必要と森岡氏。幸い「CyberWorkBench」には詳細な合成指示機能が備わっているため、ダミーコードを除去する事無く高位合成できたという。
その他にも今回森岡氏からは、高位合成ツールの実用について様々な話を聴く事が出来たが、印象に残ったのは、「アルゴリズムの大規模化・複雑化」により回路の全体構造が机上検討し難い状況が現場で起こりつつあるという話。だからこそ「高位合成の利用」と繋がる話であるが、その為には「アルゴリズムの理解」が必須で、それを実現する「作業体制」も無視できない。まだまだ高位合成ツールの利用にあたっては様々な課題があるようだが、「既に高位合成無くして、大規模アルゴリズムはハード化出来ない」という話は事実のようだ。
｜ページの先頭へ｜