ハードウェア記述言語
ハードウェア記述言語(ハードウェアきじゅつげんご、英: hardware description language、HDL)は、デジタル回路を設計するためのコンピュータ言語ないしドメイン固有言語(DSL)である。回路の設計、構成を記述する。処理を検証するための試験(テストベンチ)記述ができ、シミュレーションできる開発環境もある。
プログラミング言語との類似性が見られる機能がある言語もあることから、プログラミング言語の一種などとする誤解が非常に多いが、間違いである。また、プログラマブルロジックコントローラの記述に用いられるラダー言語は別のものと扱われている。
概要
[編集]ハードウェア記述言語は、ハードウェアの動作仕様を記述するのに使う、文字で記述するコンピュータ言語で、電子回路の経時的振舞いと空間的構造を表現する。プログラミング言語と比較すると、ハードウェア記述言語の構文(シンタックス)や意味(セマンティックス)は、ハードウェアの基本的属性である時間や並行性を記述するものであり、全く異なるものである。回路の接続関係(コンポーネントと等電位点の列挙)を記述する言語として、ネットリストがある。
ハードウェア記述言語の処理系には、記述にもとづきネットリストやプログラマブルロジックデバイスのコンフィグレーションを生成する合成系と、記述に直接もとづきシミュレーションを行うシミュレータがある。シミュレータによってハードウェア設計者は実装前にハードウェアの動作を確認できる。シミュレータには、シミュレーションのレベルとして、ディジタルな事象としてのみ扱うものと、アナログな事象まで詳細に扱うものがある。アナログまで扱うように最初から設計された言語もあれば、拡張として追加された言語もある。
C++のようなプログラミング言語に実装した内部DSL(internal/embedded DSL)として実装されているSystemCのようなハードウェア記述言語もある。
プログラミング言語と同様に様々な言語がある。現在は米国防総省が開発に携わったAdaの流れを汲むVHDL、ゲートウェイ・デザイン・オートメーション社(Gateway Design Automation)[注 1]が開発したVerilog HDLの標準化がまずIEEEで進み、その後IECの国際規格にもなり、広く普及している。
歴史
[編集]最初のハードウェア記述言語は、カーネギーメロン大学の「ISP」[注 2][1]、カイザースラウテルン大学の「KARL」である。この二つの言語は1977年にほぼ同時に開発された。ISP はよりプログラミング言語的で、設計上の入力と出力の関係を記述する方式であった。ISP は設計のシミュレーションには使えるが、回路を生成することはできなかった。KARL は大規模集積回路の回路配置が記述可能な機能も持っていた。回路配置の記述機能は関連する対話型グラフィカル言語 ABL にもあった。1980年代初期にABLを使ったVLSI設計エディタをトリノの通信研究センター CSELT で開発している。1980年代中ごろ、欧州連合の委員会が出資した国際コンソーシアムが KARL と ABL を中心としたVLSI設計フレームワークを実装した[2]。1983年、Data-I/O が ABEL を発表した。これはプログラム可能な論理回路を対象としたもので、主に有限状態機械の設計に使った。他に、日本で開発されたSFLがある。
最初の現代的意味でのハードウェア記述言語である Verilog は、1985年、ゲートウェイ・デザイン・オートメーション社が開発した。ケイデンス・デザイン・システムズがその権利を取得して Verilog-XL というシミュレータを開発し、これがその後約10年間で事実上の標準となった。1987年、アメリカ国防総省の要求で Ada 言語の流れを汲む VHDL を開発した。これらハードウェア記述言語とシミュレータによって、技術者はより抽象化されたレベルで設計が可能となり、回路規模も数百トランジスタから数千トランジスタへと拡大していった。
ハードウェア記述言語で記述されたプログラムから論理合成できるシステムが登場し、ハードウェア記述言語はデジタル設計の表舞台に立つようになった。合成ツールはハードウェア記述言語でRTLを記述したソースファイルをコンパイルし、製造可能な論理ゲートやトランジスタのネットリスト記述を生成する。当初のシステムでは、合成可能なRTLファイルを書くには熟練を要した。RTLで合成したネットリストは、従来の設計に比べるとサイズが大きく、性能も悪いことが多かった。熟練技術者による回路図による設計は、論理合成した同等の回路設計よりも常に優れていたが、論理合成の生産性の良さから、RTL合成が不得手としていた高速低電力な回路や非同期回路でもハードウェア記述言語が採用されていった。論理合成は、単にハードウェア記述言語をデジタル設計の中心に押し出しただけでなく、それ自体がデジタル回路設計のための画期的技術であった。回路図による設計とRTLによる設計は、プログラミング言語におけるアセンブリ言語による設計とC言語による設計の関係に似ている。
IEEEが VHDL と Verilog HDL を標準化したこともあり、VHDL と Verilog HDL は電子産業では事実上の標準となり、それら以外のハードウェア記述言語はあまり使われなくなっていった。しかし、VHDL と Verilog HDL には共通の弱点がある。どちらもアナログ回路やアナログとデジタルの混在した回路のシミュレーションが苦手であり、再帰的な論理構造を記述できない。そのような VHDL と Verilog HDL の弱点を克服するハードウェア記述言語もいくつか登場したが、VHDL や Verilog HDL を置換するには至っていない。
ハードウェア記述言語の改善は長年に渡っている。Verilog HDL から派生した SystemVerilog では、様々な新機能がある。VHDL の最新版でも SystemVerilog の拡張と同等の機能を持たせるよう開発が進んでいる。今後も VHDL と Verilog HDL の改良は続くという予測がある。
ハードウェア記述言語を使った設計
[編集]デジタル回路設計は、ハードウェア記述言語による記述か回路図入力によって行っている。回路図入力では、大規模な記述の確認が困難であるため、ハードウェア記述言語の記述が増えている。
設計の最初期は、紙と鉛筆で要求仕様や高水準な構造(アーキテクチャ)図を描くことから始まる。この構造が妥当であるかどうか重要である。構造の妥当性を確認する上で、ハードウェア記述言語で記述する場合もある。ハードウェア記述言語による記述を行う工程は、設計者の熟練度や回路の性質に強く依存している。次の段階として MATLAB や C++ の数学的モデル記述のような、高水準のアルゴリズムを記述することもある。制御と判断構造は、流れ図(フローチャート)描画ソフトウェアや状態遷移図編集ソフト(エディタ)で試作(プロトタイピング)することも多い。この後、ハードウェア記述言語の記述に変換を行う。
ハードウェア記述言語では、「RTL」と呼ぶ抽象度でハードウェアを記述する。この抽象度では演算器やレジスタとその間の信号伝達を用いてハードウェアを記述する。また、多くのハードウェア記述言語では入れ子構造的に、ある回路の部分回路に分けて設計する。あるいは既にある回路記述を部分回路として利用することもできる。再利用によって設計の効率化が行える。
RTL は論理回路の表現としては抽象的であるため、このままではハードウェアにする事はできない。その代わり、この抽象度に適合したシミュレータを用いて、回路の論理的な動作を確認することができる。機能としては電気的特性などの再現は限られる。シミュレータを用いて、回路の妥当性検証や性能見積もりを行う。
この後ゲート水準と呼ぶ、論理回路を記述する抽象度の記述に展開することで、集積回路を実現する。この操作を論理合成と呼ぶ。論理合成を実行するための道具を論理合成ツール と呼ぶ。
ハードウェア記述言語の記述の抽象度(水準)
- 構造(アーキテクチャ)- システムの構造、基本機能(アルゴリズム)を記述
- 動作(BL[注 3]) - 回路の動作を機能面から記述
- レジスタ転送(RTL[注 4]) - レジスタと演算器とその間の配線(接続)を記述
- ゲート(GL[注 5]) - フリップフロップや論理素子:ゲート(not, and, or, xor)で回路図を表現
設計工程が次の段階に進むたびに、ハードウェア記述言語コードは常にコードレビューを行う。論理合成の前に、ハードウェア記述言語記述は一連の自動化された検査を受ける。この検査工程で、後の合成工程で解釈を間違う可能性のある曖昧な構文を検出したり、一般的なコーディング上の問題を検出する。
ここでよく用いるのが、STARC が作成した Verilog HDL スタイルガイド、VHDL スタイルガイドである。このコーディング規則に従うと、電子回路の知識がないプログラマが作成したコードの論理的な欠陥を少なくすることができる。スタイルガイドに適合しているかを検査するソフトウェアも存在している。
ハードウェア記述言語による設計は、論理合成工程で終了すると考える。合成ツールがハードウェア記述言語の記述をゲートのネットリストに変換すると、ネットリストが下工程に引き渡される。物理的なテクノロジ(FPGA、ASICゲートアレイ、ASIC標準セル)によっては、ハードウェア記述言語が下工程でも重要な役割を演じることもある。一般に工程が進んで設計が詳細化していくと、設計データベースには技術固有の情報が格納されるようになっていく。技術固有のデータが増えると汎用的なハードウェア記述言語による記述では格納しきれなくなる。
反復的な回路構造をハードウェア記述言語で記述するときに、Perlのようなスクリプト言語を使って自動生成することもある。Emacsなどのテキストエディタは、ハードウェア記述言語のソースコードについて自動字下げ(インデント)、キーワードの強調表示、各種宣言のマクロ拡張などの機能を提供しているものがある。
ハードウェア記述言語コードのシミュレーションとデバッグ
[編集]ハードウェア記述言語による設計の本質は、ハードウェア記述言語プログラムをシミュレーション可能な点にある。シミュレーションすることで、設計のハードウェア記述言語プログラム(モデル)が設計検証に合格するようにできる。設計検証は、コード実装(ハードウェア記述言語プログラム)がその設計が意図した機能(仕様)に対して妥当かを検証する重要なマイルストーンである。シミュレーションによって構造(アーキテクチャ)的な吟味もする。技術者は基本設計に対して複数の設計を実験的に書き、シミュレーションでそれらの動きを比較することができる。以上のようなことから、ハードウェア記述言語による設計ではシミュレーションが重要である。
ハードウェア記述言語で書かれたモデルをシミュレーションするには、テストベンチと呼ぶシミュレーション環境をまず記述する。テストベンチには少なくとも、モデルを実体(インスタンス)化した試験対象装置(Device Under Test、DUT)、そのモデルの入出力のためのピンと信号の宣言、クロック波形が必要である。テストベンチのコードはイベント駆動型である。テストベンチが生成するリセット信号の実装、インタフェース・トランザクション(ホストバスの読み書きなど)のモデリング、そしてDUTの出力モニタのための記述が必要となる。テストベンチを実行するソフトウェアをシミュレータと呼ぶ。シミュレータはテストベンチ内の全イベントの参照元となるシミュレータ・クロックを発生させる。イベントはテストベンチのプログラムが指示したときだけ発生するもの(テストベンチ内のコードでリセット信号を発生させるなど)と、およびそのようなイベントへの反応としてモデルが発生するものがある。最近のシミュレータはGUI化されており、デバッグツール一式も備えている。利用者は任意の時点でシミュレーションを中断/再開でき、ブレークポイントを設定でき、モデルの階層を監視/変更できる。さらにプログラム実行環境に利用者がコンパイルしたライブラリをPLI/VHPIインタフェースを通してリンクできるシミュレータもある。リンクは環境依存であり、シミュレータと利用者ライブラリのコンパイルとリンクは、HDL環境の外部で行う。
設計検証は、ソフトウェア開発工程で言えばソフトウェア試験(ソフトウェアテスト)とデバッグの工程である。設計工程の中でも最も時間がかかる可能性がある。試験結果によっては大きな設計変更もありうるため、シミュレータ環境で最初に行う。ただし、厳密に定義したコーディング規約に基づいているかどうかの検査を先に行うことにより、試験作業を大幅に短縮することもできる。プログラムをハードウェアで検証する目的でPLD(プログラマブルロジックデバイス)、FPGAを使うこともある。ハードウェアを使ったプロトタイピングはシミュレーションよりも費用がかかるが、シミュレーションではわからない設計上の問題点が明らかになることもある。他のハードウェアとのインタフェースの確認はハードウェアによるプロトタイピングが最善の方法である。FPGAは、シミュレータより高速に動作するだけでなく、実際に並行実行するための時間的な問題について検出可能である。
ハードウェア記述言語での設計検証
[編集]歴史的に、設計検証は労力を要する工程であり、テストケースを書いてはシミュレーション実行するということをDUTに対して繰り返す。チップが大規模かつ複雑になるにつれて、設計検証も開発期間の大部分を占めるようになってきた。設計の生産性を向上させるべく、特性仕様言語が開発された。
形式的検証において、「プロパティ」とは、オブジェクトの期待される振る舞いや推定される振る舞いに関する事実を記した文である。理想的には、ハードウェア記述言語プログラムが与えられたとき、プロパティは形式的数学的手法で真偽を証明可能である。実際には、多くのプロパティは無限の解空間を占めるため、真偽を証明できない。しかし、前提や制約が与えられると解空間が狭められ、プロパティチェッカ・ツールで真偽を証明できるプロパティが増える。
表明は回路の動作をモデルとしたものではなく、むしろ設計者の意図を捉え、ハードウェア記述言語コード内に込めるものと言える。シミュレーション環境では、シミュレータは全ての指定された表明を評価し、表明に違反した箇所と違反の程度を報告する。合成環境では、表明違反があれば、合成が中断されることもある。表明に基づく検証はまだ始まったばかりの手法だが、ハードウェア記述言語による設計の必須な部分となると予測されている。
ハードウェア記述言語とプログラミング言語
[編集]ハードウェア記述言語はプログラミング言語と似ているが、異なるものである。(近年の並列・並行プログラミング言語を例外として)プログラミング言語は基本的には手続き的で、並行・並列性に対応する構文・意味は限定的であるものがほとんどである。一方ハードウェア記述言語は、複数の並列処理するコンポーネント(フリップフロップ、加算器など)をモデル化でき、各コンポーネントは自動的に互いに独立に実行する。入力を変化させると、変化をトリガとして自動的にシミュレータのプロセススタックを更新する。
プログラミング言語ではコンパイラにより機械語を生成し、ハードウェア記述言語ではシンセサイザ(合成系)でネットリストを生成する。後者もコンパイルと呼ぶものもあるが、目的と対象が異なる。プログラミング言語のコンパイラはソースコードをプロセッサ固有の機械語に変換し、そのプロセッサ上で実行可能な形式にする。ハードウェア記述言語のシンセサイザは、ソースコードから物理的に実装可能なゲートのネットリストを生成する。ネットリストには様々な形態があり、ゲート遅延情報を持つシミュレーション・ネットリスト、下工程用のハンドオフ・ネットリスト、汎用の標準ネットリストであるEDIFなどがある。なお、プログラミング言語におけるインタプリタは、ハードウェア記述言語ではシミュレータに相当する(性能上の理由などのために、シミュレーションを実行する実行可能プログラムを生成するタイプのシミュレータもある)。
ハードウェア記述言語には、プログラミング言語用のプリプロセッサを流用しているものもある。
ハードウェア記述言語の意味論には、厳密でないものもあり、記述がまずいとシミュレーションと合成結果のふるまいが異なることがある、というものもある。
以上で述べたように、基本的にはハードウェア記述言語はプログラミング言語と異なるものであるが、より高水準からの記述を求めたハードウェア記述言語があり、一方で並列・並行の記述を言語機能に持つプログラミング言語もあるため、共通する要素を持つものもそれぞれあらわれている。
電子システムがますます複雑化するにつれ、再構成処理(再構成可能コンピューティング)が増えていることと、どちらも設計できる技術者の必要性から、ハードウェア記述言語としてもプログラミング言語としても使える言語への要求が高まりつつある。
一例として SystemC があり、組み込みシステムのハードウェアを詳細の不明なアーキテクチャ上のブロック(入出力信号がモデル化されたブラックボックス)としてモデル化できる。SystemC の高度に抽象化したモデル記述は、初期のアーキテクチャ選定に適している。
周辺技術動向
[編集]システムレベル設計
[編集]当初、ハードウェア記述言語は大規模集積回路のシミュレーションを目的に開発されたが、論理合成技術の開発によってハードウェア記述言語での記述からの論理回路生成の自動化ができるようになった。現在、RTLでの設計より更に高い抽象度でのハードウェア設計を可能とする高位合成技術の開発が進んでおり、メンター・グラフィックス社が提供する Catapult C Synthesis やシノプシス社のSynphony C Compiler などに例を挙げられるような、いくつかのツールが市販されている。RTLの上位に位置するのは、振舞い(ビヘイビア・レベル)と呼び、ハードウェアの動作やアルゴリズムを記述する。特にこの振舞いの記述を対象とした高位合成を動作合成と呼ぶ。
この振舞い記述では、ハードウェアをプログラミング言語によるソフトウェアの記述と殆ど同様の考えで記述することになる。ここから、ハードウェアとソフトウェアを同時に、区別なく設計・合成する技術の研究開発も進んでいる。ハードウェア・ソフトウェア協調設計(コデザイン、co-design)は、ソフトウェア技術者がハードウェア記述言語プログラムを理解し、ハードウェア技術者がソフトウェアプログラムを理解することによって、加速していく可能性がある。
こうした高位合成技術、協調設計技術を総合してシステムレベル設計またはシステム設計技術と呼ぶ。これらの技術を用いて、ハードウェアとソフトウェアとを区別なく、ソフトウェアの記述と同等の抽象度で論理(デジタル)システム全体を記述することをシステムレベル設計と呼ぶこともある。
このようなシステムレベル設計に用いる言語として、C言語を拡張した SpecC、C++のテンプレートライブラリとして実現したSystemC、Verilog HDLを拡張したSystemVerilogなどがある。特に SpecC や SystemC など、C/C++をベースにした言語による設計をC言語設計と呼び、日本ではシステムレベル設計といえばC言語設計を指すこともある。
アナログ回路設計への拡張
[編集]ハードウェア記述言語はデジタル回路を対象としているが、これを拡張してアナログ回路を記述できるようにする動きもある。主たる目的はアナログ回路、もしくはアナログ - デジタル混載回路のシミュレーションである。
これに該当する言語としてVerilog-AMSやVHDL AMSがある。
言語
[編集]主に次の二つのハードウェア記述言語が業界で主流として使われている。
- VHDL
- Verilog HDL、SystemVerilog (Verilog HDL の上位言語)
他に以下のようなハードウェア記述言語がある。
- Advanced Boolean Expression Language[3](ABEL)
- AHDL(アルテラ社のハードウェア記述言語)
- Atom[4](Haskellベース)
- Bluespec(Haskellベース。型システムを独自拡張するなどしており内部DSLではない。A History of Haskell: being lazy with class§12.4.2)
- BSV[5](Bluespec SystemVerilog。現在 Bluespec と呼ばれているのはこちら。Bluespec の機能を Verilog ライクな構文にしたもの)
- Chisel[6] Scala内部DSL
- HDCaml[7](Objective Camlベース)
- Hardware Join Java[8]
- HHDL[9][10] Haskell 内部DSL
- HML[11]
- Hydra[12](Haskellベース)
- JHDL[13](Javaベース)
- Lava(Haskell 内部DSL)(Chalmers Lava[14]、Xilinx Lava[15]、Kansas Lava[16]、York Lava[17])
- Lola(教育用の素朴な言語)
- MyHDL[18](Python 内部DSL)
- NSL SFLを拡張および一部モディファイ
- PALASM[19](プログラマブル・アレイ・ロジック向け)
- Ruby[20] -(※こちらはオブジェクト指向スクリプト言語Rubyとは無関係)
- RHDL[21] -(※こちらはオブジェクト指向スクリプト言語Rubyベース)
- SFL
- SystemC - C++ 内部DSL
- ImpulseC - C言語のハードウェア記述言語
関連項目
[編集]脚注
[編集]注釈
[編集]出典
[編集]- ^ Barbacci, M. 「The ISPL Language」カーネギー大学 計算機科学科、1977.
- ^ J. Mermet 編、「Fundamentals and Standards in Hardware Description Languages」(シュプリンガー・フェアラーク、1993年)
- ^ http://www.seas.upenn.edu/~ese201/abel/abel_primer.html
- ^ http://funhdl.org/wiki/doku.php/atom Atom
- ^ http://www.bluespec.com/highlevelsynthesis/highlevelsynthesis.html
- ^ http://chisel.eecs.berkeley.edu/
- ^ http://funhdl.org/wiki/doku.php?id=hdcaml
- ^ http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/8456/26638/01188707.pdf
- ^ http://hackage.haskell.org/package/HHDL
- ^ http://www.haskell.org/pipermail/haskell-cafe/2011-December/097449.html
- ^ http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=820756
- ^ http://www.dcs.gla.ac.uk/~jtod/Hydra/
- ^ http://www.jhdl.org/
- ^ http://www.cse.chalmers.se/edu/course/TDA956/Tools/lava/ http://hackage.haskell.org/package/chalmers-lava2000
- ^ http://www.raintown.org/lava/ http://hackage.haskell.org/package/xilinx-lava
- ^ http://ittc.ku.edu/csdl/fpg/Tools/KansasLava http://hackage.haskell.org/package/kansas-lava
- ^ http://www.cs.york.ac.uk/fp/reduceron/ http://hackage.haskell.org/package/york-lava
- ^ http://www.myhdl.org/doku.php MyHDL
- ^ http://www.brouhaha.com/~eric/retrocomputing/mmi/palasm/
- ^ http://web.comlab.ox.ac.uk/oucl/work/geraint.jones/ruby/
- ^ http://rhdl.rubyforge.org