動作合成とは，設計対象の回路で処理したいアルゴリズムから，その回路のRTL（register transfer level）コードを生成することをいう。動作合成を実行するEDAツールが，動作合成ツールである。現在の動作合成ツールは，演算器とレジスタの使用効率が高く，かつ論理合成可能なRTLコードを生成できる。
信号処理系のハード設計で真価
動作合成は，主に，画像処理やオーディオ処理，フィードバック制御，暗号処理，誤り訂正符号などの信号処理系のハードウェア設計で，その効果を発揮する。一般に信号処理系の設計は次のような手順で進める（図1）。
【図1 LSIの上流設計フローと動作合成】出典はJEITA。 （画像のクリックで拡大）
まず，チップの要求仕様に基づいてアルゴリズムを設計する。この時，演算量やメモリー量を少なくして，最高の効果（性能）を出すように設計する。アルゴリズム設計の次には，アーキテクチャ設計を行う。すなわち，モジュール分割や階層，インタフェースの詳細を決定する。
その次には，各モジュールをプロセサ・コアで稼働するソフトウェアとして実現するか，専用回路としてハードウェア化するかを決める。このうちハードウェア化する部分は，RTL，ゲート・レベルへと詳細化を進める。アーキテクチャ設計結果をRTLに詳細化する工程で，動作合成が使える。
基本機能は三つ
動作合成ツールは，次のような機能を備えている。すなわち，（1）構文解析，（2）スケジューリング，（3）リソース・シェアリング，（4）パイプライン合成，（5）インタフェース合成，（6）データパスとステート・マシンの生成，である。以下，それぞれを説明する。
（1）の構文解析は，設計者が記述したコードをツールが「理解する」機能である。市場に早くからあった，Verilog-HDL入力の動作合成ツールでは，ピン・レベルの入出力とアルゴリズムのモジュールを記述して入力としていた。その後，SystemCが動作合成ツールの入力言語として使えるようになってからは，C++のオブジェクト構文を入力記述に利用できるようになった。例えば，設計の効率や再利用性を高めるためにインタフェースをクラス化したり，用意されていないデータ型を新しいクラスとして定義できる。
（2）のスケジューリングは，「アルゴリズム中の演算」や「データの保持」を行うクロック・サイクルを決めることをいう。スケジューリングの仕方によって，演算器やレジスタなどの資源（リソース）を共用（シェアリング）することが可能になる。これが（3）のリソース・スケジューリングの機能である。例えば，
y = a*x 1+ b*x2 + c*x3 という演算の場合，処理が速い回路にするには，乗算器3個と加算器2個を使う。これなら，1クロック・サイクルで処理が済む。
一方，処理が遅くてもよければ，
（i）y = a*x1
（ii）y= y + b*x2
（iii）y= y + c*x3
という3段階の処理に分割すれば，乗算器と加算器は1個ずつで済む。ただし，処理時間は，3クロック・サイクルに延びる。
動作合成ツールではパラメータを変更するだけで，同じ演算を，演算器数やクロック・サイクル数が異なる回路（RTL）に実現することができる。
上述した（1）～（3）が動作合成ツールの基本的な機能だが，（4）のパイプライン処理の自動生成，（5）のインタフェース合成，（6）のデータパスとステート・マシンの生成の各機能を備える場合も多い。
このうち，（5）のインタフェース合成は技術的に動作合成とは別の処理になる。ただしLSI設計の一般的な手順を考えると，動作合成と同時にインタフェース合成が一つのツールで実行できることが望ましい。
また，（6）のデータパスとステート・マシンは，動作合成ツールの出力形式とも言える。ステート・マシンの状態を表すコードは，「バイナリ」，「グレー」，「ワン・ホット」などから選ぶことができる。
動作合成の入力
動作合成ツールへの入力言語は，主に次の3種類に分類できる。すなわち，（a）Verilog HDLやVHDLなどのハードウェア記述言語（HDL：hardware description language），（b）C言語やJavaなどのプログラミング言語，（c）SystemCなどのシステム・レベル記述言語である。なお厳密には，SystemCは，独立した一つの言語ではない。C++言語のライブラリとして用意した，C++言語上の記述法という方が正確である。
（a）のHDLを用いれば，ハードウェア設計者に理解しやすく，（b）のプログラミング言語を用いれば，アルゴリズム設計者に理解しやすくなる傾向がある。ただし，HDLはオブジェクト指向などのプログラミング手法が使えない，プログラミング言語にはモジュールの階層や並列動作を表現できないなどの問題がある。これらの弱みを補うために，（c）のシステム・レベル記述言語が登場した。
いずれの言語を用いる場合でも，「シミュレーション可能な構文をすべて動作合成できるわけではない」ことには注意が要る。動作合成用に規定された構文とコーディング・スタイルを使った場合のみ，動作合成が可能な記述となる。なおSystemCに関しては，その支援機関のOpen SystemC Initiativeが「SystemC Synthesizable Subset」1)が，動作合成可能なサブセットを規定している。また，JEITA SystemC WGは，「SystemC推奨設計メソドロジ 合成編」2)の中で，動作合成を使用する設計手法について提案した。
記述量が1/5～1/10に
【図２ 動作合成におけるトレードオフ】出典はJEITA。 （画像のクリックで拡大）
次に動作合成の利点と注意点について説明する。動作合成の利点としては，第1に「入力コードの記述量が小さい」こと，第2に「処理クロック数と回路規模のトレードオフの検討が容易にできる」こと，第3に「入力コードの再利用性が高い」ことを挙げられる。
一般に，動作合成の入力コードは，アルゴリズムを複数のモジュールに分割し，入出力の定義を加えたものになっている。論理合成の入力コードである，RTL記述のように処理の詳細を書く必要がないため，動作合成の入力コード量は，論理合成のそれに比べて，1/5～1/10程度になる。コード量が小さいと，仕様であるアルゴリズムとの対比が容易であり，検証がしやすい。
また，処理のパラメータを変更することによって，トレードオフ関係にある，処理クロック数と回路規模の最適値を求めることができる（図2）。なお処理パラメータは入力コードに含ませるか，別途外部から与える。
動作合成の入力コードは，処理クロック数と回路規模を最適化する前の状態にあるため，再利用性が高い。さらに，演算型などをパラメータにすれば，各種の処理アルゴリズムのライブラリを容易に整備できる。
ツールに合った入力コードを用意
一方，現在の技術レベルの動作合成ツールを使うには，以下のような3点に留意する必要がある。（A）「目的に沿った動作合成ツールを選ぶ」，（B）「大きい設計は分割する」，（C）「使うツールに合わせた入力コードを用意する」である。
まず，（A）の目的に沿った動作合成ツールを説明する。例えば，あるプログラミング言語で記述したプログラムの一部をコプロセサにしたい場合は，そのプログラミング言語で入力できる動作合成ツールが使いやすい。
一方，システム（チップ）の大半を動作合成したい場合には，アーキテクチャを表現できるシステム・レベル記述言語で入力する動作合成ツールを用いるのが良い。また，最適化できる内容もツールにより異なるので，使用前に十分確認したい。
次に（B）の大きなアルゴリズムを見る。現在の動作合成ツールに入力できるアルゴリズムの大きさには限界がある。一定量を超えると，最適化処理の時間が非常に長くなり実用的でない。そのため，大きなアルゴリズムは複数のモジュールに分割する。なおメモリーの使用方法やモジュールの分割などは，動作合成ツールが最適化できないため，事前にユーザーが十分に検討する。
その次に，（C)の入力コードのスタイルについて説明する。各動作合成ツールには，そのツールに固有のコーディング・スタイルが決められているのが一般的である。これに沿っていないアルゴリズム（プログラム）でも，処理不可能ではないが，最適な結果を得ることは難しい。
実際，期待した動作合成結果が得られない場合には，入力のコーディング・スタイルを見直すと，改善する場合が多い。今後，ツールの進化につれて，コーディング・スタイルの制約は少なくなるだろう。ただし，最適な結果を得るために，コーディング・スタイルを修正することは，今後もなくならないだろう。
高位合成との違い
動作合成より広い概念に，「高位合成（high-level synthesis）」がある。高位合成は入力言語がUML（Unified Modeling Language）やC言語など，ソフトウェアのプログラミング言語の場合が多い。一方，動作合成はVerilog HDLやSystemCなど，ハードウェアを意識した言語を入力記述に使うのが一般的である。
また高位合成はハードウェア化する際に最適化処理の有無にはあまりこだわらないことが多い。一方で，動作合成には，ハードウェアの最適化機能として，「スケジューリング」と「リソース・シェアリング」の二つが備わっているのが一般的である。
参考文献
1) Synthesis Working Group of Open SystemC Initiative， SystemC Synthesizable Subset Draft 1.1.18， December, 2004.
2)JEITA EDA技術委員会 標準化小委員会 SystemCワーキンググループ, 『SystemC推奨設計メソドロジ 合成編』，2008年4月.
