高位合成がもたらす価値を高める高位設計／高位検証（Design and Verification LANDSCAPE　2022-Vol1）

2023/01/11

はじめに

いまから30年も前の半導体の論理設計は、回路図入力が主流であり、現在で言うゲートレベル抽象度のシミュレーションに依存しており、せいぜい数万〜十数万ゲート規模の設計までが限界だった。1990年代の後半になりVHDLやVerilog HDLによる言語設計へと移行し、論理合成の技術と相まってRTL抽象度による設計とシミュレーションが実用的な時代となっていった。この技術シフトによりさまざまなメリットがもたらされたが、その１つは半導体プロセスや特定半導体ベンダのテクノロジへの依存度が極端に減り設計の再利用性が高まったこと、設計IPによる設計のエコシステムが勃興したことであろう。同時に標準的に使用されるバスとそれに接続するためのインタフェースやプロトコルが出現し、設計がしやすくなったことも挙げられる。またゲートレベルに比べてシミュレーション速度が数倍から十数倍高速となり、より大きな設計にも対応できるようになったことも大きなメリットである。

しかしその後、大きな課題となっているのがRTL抽象度における機能検証である。2020年に実施されたWilson Research Groupの市場調査によれば、機能検証はプロジェクト時間の60%近くを占めており、設計エンジニアの伸び率を上回る勢いで検証エンジニアのリソースがプロジェクトに投入されている。

一方で設計の抽象度をさらに高め、動作レベル、アルゴリズムレベルなど、より高位で設計し、そこから高位合成によってRTL記述を自動生成する技術も使われ始めている。RTL設計から高位設計にシフトしようとする際に抱く懸念の多くは、RTLハンドコーディング設計に対する面積増や性能、消費電力に関するものだが、足元でプロジェクト時間の60%を占める機能検証の労力が低減されることはあるのだろうか。設計の抽象度が高位へとシフトしても、高位合成後のRTL検証に現状と変わらない労力が費やされるなら、高位合成がもたらす価値は限定的であると言わざるをえない。本稿では高位合成そのものよりも、RTL機能検証の労力が低減され、高位合成の価値が充分にもたらされるのかに着目しながら考察する。

アルゴリズムのRTL実装

エレクトロニクス製品やシステムには何かしらのアルゴリズムが含まれており、近年使われているDSPや機械学習による実装はその際たるものである。アルゴリズム開発は通常ネイティブなC言語で行われる。アルゴリズムの正当性、妥当性の確認や評価では、データの型として浮動小数点であればfloatやdoubleが、整数であればintやlong、short、charなどが使用されている。

一方でハードウェア設計者は、仕様書と検証済みのC言語モデルを受取り、これをベースにハードウェアへと実装する。Cモデルはアルゴリズム設計者によって検証されているため、このモデルをリファレンスモデルとするように指示されることが多い。ところが、浮動小数点のままハードウェア実装するとエリア的に大きく影響を及ぼすため、多くのプロジェクトではハードウェア設計者が固定小数点化して、実装する。また整数型であっても余分なビットのトリミング作業なども行う。ここで問題となるのが固定小数点化やビットのトリミングによってリファレンスモデルに対する差異が生じることである。そしてどこまでの誤差が許容されるのか、保証はどうするのかなどは、ハードウェア設計者が扱わなくてはならないことが多い。仮にアルゴリズム設計者がそのままハードウェアを実装する場合でも、本質的には同じ問題を抱えている。それはハードウェア実装する段階で固定小数点化やビットトリミングをしているため、アルゴリズム検証に比べて数百倍もの時間を要するRTL検証によって、誤差の妥当性を検証しなくてはならないということである。さらにその妥当性検証に要する完全なテストパターンが作成できない限り、ここで品質低下のリスクが高まるという問題を抱えている。

高位でビット精度の型を使うことが鍵

このような本質的な問題を解決するために有効なのがCレベルの記述にビット精度を持たせる手法である。高位記述のまま浮動小数点から固定小数点に書き換え、それによる誤差の評価と検証を行う。AC（Algorithmic C）データタイプと呼ばれるビット精度の型定義は、Apache 2.0ライセンスによるオープンソースとして入手し、フリーで使用できる。型定義のみならず、さまざまなIPが含まれるHLS LIBSというライブラリとしてSIEMENS EDA（旧Mentor Graphics）が開発し、現在は誰でもがダウンロード可能なプロジェクトとなっている。同社が持つ高位合成ツールでは、このビット精度のCコードを読み込み、それと同じ精度のRTLを出力することができる。もちろんハードウェア依存のデータレートやスループットの検証はRTLでのみ行うことになるが、ある入力に対する演算結果が完全に一致するかどうかはCでもRTLでも検証内容としては同じである。であればRTLに対して数百倍高速で実行可能なC記述で検証、評価を行い、RTLにおける検証項目や評価項目を減らすべきである。

そしてこの戦略は、Cでアルゴリズムを記述し、そのモデルをリファレンスとしてRTLを手で記述するプロジェクトであれば、高位合成を使用するかしないかに関わらず、一定のメリットを享受することができる。その戦略の実践とは高位における設計と評価、検証を、よりハードウェアを意識した形で行うということである。そこで、次のセクションではACデータタイプについて解説し、さらにこのデータタイプを使うことによって、どのような検討が高位段階で行えるかについて解説する。

ACデータタイプの活用

ACデータタイプはHLS LIBSに含まれ、 https://hlslibs.org サイトからダウンロードすることができる。

図1. ACデータタイプがダウンロード可能なサイト

ビット精度を扱うデータタイプとしてはSCデータタイプも存在するが、特に固定小数点を用いたシミュレーション実行は、ACデータタイプが圧倒的に高速である。またSCデータタイプの場合、ビット幅によって型を変えないといけないという制限があるが、ACデータタイプでは整数はac_int、固定小数点はac_fixed、そして浮動小数点はac_floatと、それぞれ一種類の型のみがクラス定義されているため、使い方が非常にシンプルで、かつ可読性にも優れているという利点がある。

図2. ACの固定小数点の使用

図2.はac_fixedの型についての説明である。ac_fixedでは全体のビット長、小数点位置、符号を指定する。さらにはオーバーフローした際のモードとして飽和（Saturation）や丸め（Rounding）といった処理機能も内蔵している。
アルゴリズム記述をリファレンスモデルとしてRTLを記述する際、あるいは高位合成ツールによりRTLを生成する際によく問題となるのが、値の範囲を超えた時の振舞いがアルゴリズムとRTLとで異なってしまうことである。

しかしビット精度を持つデータタイプを使用することで、このような振舞いの差異は解消することができる。例えば図3.の記述では変数xをac_int<7,true>のデータタイプとして宣言している。7ビットの符号付き整数となるため、取り得る値は -64 < x <63 である。

図3. ac_int を用いたサイン関数値の
ファイル出力例

しかしOFFSETを加えていくと、やがて取り得る値の範囲を超えてしまう。OFFSETが0の時とOFFSET=14の時のプロット図を図4.に示す。

図4. OFFSETによって異なるxの値

ネイティブなCで表現すればサチュレーションを起こすところでも、VHDLやVerilog HDL、SystemVerilogなどのハードウェア言語では、7ビットの範囲を超える際にラッピング（Wrapping）と呼ばれる振舞いとなる。つまり全てのビットが”1111111”となったポイントから”0000000”へといきなり落ちる振舞いである。図4.の右側のプロットはACデータタイプを用いた際の振舞いであるが、ハードウェア言語の記述とまったく同じ振舞いとなる。ACデータタイプを使用することで、RTLとまったく同じ振舞いを数百倍高速に確認することができることになる。

次に同じサイン関数を使用し、データタイプにac_fixedを用いた例について見てみる。その記述を図5に示す。このデータタイプでは、オーバーフローした際のデフォルトのモードは、前出のラッピングモード（AC_WRAP）であるが、その代わりに飽和状態を示すサチュレーションモード（AC_SAT）を指定することが可能である。詳細については前出のHLSLIBsのドキュメントから知ることができる。

図5. ac_fixed を用いたサイン関数値の
ファイル出力例

ac_fixed指定しているAC_SATによるサチュレーションモードの振舞いを、ラッピングの振舞いと比べてみると図6のようになる。

図6. AC_SATモードとAC_WRAPモードの違い

従来のアルゴリズム記述ではサチュレーションを表現するために、オーバーフローのポイントで条件文を用意し、オーバーフローする限りは取り得る最大値を出力し続けるという振舞いを記述する必要があったが、このようにオーバーフロー時のモードでAC_SATを指定するだけで済むため、アルゴリズム記述の煩雑さも抑えることができる。アルゴリズム設計者はアルゴリズムの記述により注力することができる。

ここで示される振舞いは、その後に高位合成をしても、あるいは高位合成を使用せずにアルゴリズムをリファレンスモデルとしてRTLをマニュアル記述したとしても、ハードウェア実装における振舞いとまったく同じ振舞いがCレベルで再現されるという事実が重要である。

このほか、ハードウェア実装した際のエリア増が高くつくことを承知の上で、あえて浮動小数点を使用したい場合や、または浮動小数点と固定小数点との誤差を評価する目的でac_floatを使用することもできる。また複素数を使用する場合にはac_complexも用意されており、実数や虚数を扱うことができる。

HLS LIBSの活用

HLS LIBSに含まれているのはAlgorithmic Cのデータタイプだけではない。このライブラリにはアルゴリズム開発を支援するためのさまざまな関数やライブラリも提供されており、すべてオープンソースかつフリーで活用することができる。

その１つはAC MATHと呼ばれる数値演算の関数ライブラリである。三角関数や対数関数、正規化関数、平方根などさまざまな関数群がライブラリ化されており、このライブラリを使用することでアルゴリズムを容易に実装することができる。ac_mathではac_int、ac_fixedなどのデータタイプが使われており、つまりビット精度を持った高位検証や評価、そして高位合成が可能である。よく使用する関数に対するRTL実装があれば、高位合成を持っていなくてもRTLに置換えることでメリットを享受することもできる。

また少し大きな単位でIPとして使えるものとしてAC DSPと呼ばれるクラスライブラリもある。FFTなど実装アーキテクチャは複数あるが、それぞれのハードウェアのアーキテクチャに対応したサンプルのコードが入っている。さらにAC MLというマシンラーニングのライブラリもあり、主に畳み込み演算を中心としたサンプルコードが含まれている。当然のことながら、ビット精度を持つACデータタイプによって記述されており、ビット精度を保った評価、検証、そして高位合成が可能である。

ビット精度モデルの検証

ACデータタイプはC++のクラスとして記述されている。つまり実行やデバッグといった作業は通常のC開発の環境で行うことができる。コンパイラはgccやVC++を使用し、LinuxやWindowsが使用可能である。参考までにACデータタイプそのものの開発はgccとLinuxの組合せで行われている。そして機能検証に必要なライブラリやコードをそのまま使用し、Cソースデバッグに慣れ親しんだ環境で検証することができる。もちろんRTLに比べて数百倍の実行速度で行える。

Cのビット精度モデルの検証は極めて重要であり、品質を担保するものでなくてはならない。高位合成を行うにせよ、RTLコーディングを行うにせよ、次に続く工程においてリファレンスモデルとして使われるからである。ここで検証の抜け漏れがありバグが混入していると、それを忠実に再現するRTL設計ができることになる。運が良くても長時間を要するRTL検証の段階でバグが見つかり、そこからCのアルゴリズム検証へと手戻りが発生することになる。運が悪ければ、バグはそのまま市場に流出してしまう。

C言語の世界でもコードカバレッジを測定することにより、そのモデルがいかにテストされたかを示すことができる。ソフトウェア記述であればgcovといったツールがカバレッジ計測や分析を目的として広く使われている。しかし、gcovなどはあくまでもソフトウェアのカバレッジ測定を目的としたものであり、ハードウェア実装を目的としたC言語モデルを作成する場合には、ソフトウェアとは異なる測定が必要となることを認識しなくてはならない。その例を具体的に示す。図7.は与えられた整数値に対して、その絶対値を返すmy_absというユーザ定義のファンクションとその呼出しの記述である。

図7. 絶対値を返すファンクションと
その呼出し

ここでmy_absは絶対値を返すファンクションとして定義されている。例えばaが-20、bが20の場合、Line13とLine14でmy_absが呼出され、Line5とLine7の両方が実行され、ソフトウェアのコードであればコードカバレッジは100%になる。しかし高位合成ではLine13とLine14はインライン展開され、それぞれ別のハードウェア・インスタンスとなる。つまりハードウェアのコードカバレッジとしては50%にしかならない。

続いてアルゴリズムの記述に多く用いられるループ分についても見てみる。

図8. forループを含むコード例

図8はハードウェアを目的として記述されたCコードで、ACデータタイプを使用している。この記述を高位合成ツールが読み込み、そこで設定する制約条件によってまったく異なるハードウェア実装が得られる。特にLine16からの加算を含むforループを実現するハードウェアは、このループをどのように展開するのか、または他のリソースと共有させるかといった制約に大きく依存する。図9には、このループを維持（ロール）した場合のハードウェア構成と、完全に展開（アンロール）した場合のハードウェア構成を示す。左側はアンロールされた状態で加算器が多く使われており面積は大きくなるもののタイミング的には高速で処理できる。それに対して右側はロールされたままでレジスタに演算結果が記憶され、次の加算に使われるため、加算器は少なくて済むものの処理には時間がかかる実装となっている。

図9. 図8のアルゴリズム記述の
ハードウェア実装例

このように高位合成の制約によってハードウェア実装が大きく異なるため、その制約を利用してロール／アンロールの状態に応じたコードカバレッジの測定が必要となる。ソフトウェア用の従来のカバレッジツールでは、常にロール状態にある記述が対象となるが、実際に求められるカバレッジはループ文の各イタレーションに対するカバレッジである。ハードウェア実装を意識したカバレッジ測定手法が確立されていれば、アルゴリズムのビット精度モデルに対するカバレッジ結果をUCDBにダンプし、それに続くRTL検証において活用することができる。そしてカバレッジもコードカバレッジのみならず、機能カバレッジやクロスカバレッジ、アサーションなどもビット精度を持つアルゴリズム記述で指定できることが望ましい。ACデータタイプを開発した前出のSIEMENS EDAからは、アルゴリズムのビット精度モデルに対して高位合成の制約情報を読み込み、ハードウェア実装を考慮したカバレッジが高位で測定できるツールも提供されている。

まとめ

論理合成ツールが登場した時、それまでの回路図ベースの設計からRTL記述による設計手法へと技術シフトが起きた。しかし現在、論理合成の技術は当たり前のものとなり、多くのプロジェクトはRTLレベルの機能検証の課題に直面している。高位合成技術を導入したり、より高位へと設計をシフトしたりするプロジェクトでは、その技術シフトによって現在の最大の課題である機能検証の負荷を減らすことを目的の１つとして設定するべきである。高位検証において、いかにハードウェア実装を意識した検証が行えるのかも重要な視点である。高位におけるビット精度の検証や評価を可能にするACデータタイプは、この領域において大きな役割を果たす。そして高位合成によって得られるハードウェア実装を考慮したカバレッジ測定の環境も重要である。

論理合成の技術がコモディティ化したように、将来的には高位合成の技術そのものもコモディティ化の波にさらされる。その際には、いかに高位で設計と検証を行うかがより重要になる。しかもそれに続くRTL実装に対してコミットできる高位の設計と検証が行われなくてはならない。高位合成を導入しようとするプロジェクトでは、高位設計と検証における要件とメリットについても併せて検討する事が求められる。

一方で、本稿で示したHLS LIBSのACデータタイプは、高位合成を使用する、しないに関わらず、アルゴリズムの段階からハードウェア実装を意識した評価検討、検証が可能である。これは今日時点でも新たな価値をリスク無しで得られるため、業界で広く使われることが期待される。