VHDL速習講座 No.1

■ はじめに

設計標準化言語としてのVHDLは、次第に定着してきていますが、やはりその習得には多くの時間を要しているようです。VHDL関連書籍も多数出版されていますが、言語体系が大きくかつ複雑だという声もよく聞かれます。やはりこの言語は、分かりにくい部類に入るといえるでしょう。
またハードウェア記述言語のわりには、ハードウェアの記述性に対する問題点もあり、回路を記述できなかったり、記述した回路が合成できなかったりすこともあり、これがまた実用化の負荷にもなっています。
はたまた、VHDLのコードを自動生成するツールなどでは、現実的ではないソースコードをはきだすものまであり、これから合成された回路が誤動作でトラブる事態も発生しています。
ここでは、言語の性格を概観し、一般に習得には数ヶ月かかるといわれるVHDLを３日で理解、１週間で実戦的に使用することができないものだろうかということを考えて、短期間で合理的にこの言語をモノにする方法について述べていきたいと思います。

■ 速習の作戦

ここでは、実践的に短期習得を目指すためにユニークな手法をとっていきますので、通常のVHDL 解説とはかなり勝手が違うかもしれません。そのために、位置づけと方針をはっきりしておきます。まず最終目的を、実際に動作するハードウア設計に置きます。(純粋な言語の世界と違って、ハードウェア設計の世界は結構泥臭い部分もあります。)そしてこの目的を達成するための手段として、 VHDLを道具として駆使するという立場にたちます。ですから言語全体のほんの一部しか使用しないことがあるかも知れませんし、わざわざ遠回りのように見える詳細な記述をすることもあるかも知れません。一見便利なCADのツールもあえて使用しないことや自動生成されたソースを手直しすることもあります。つまりは、言語の世界に陶酔することなしに、”モノを作ってなんぼの世界”からVHDLを道具として割り切って見立てようということになります。

■ HDLからの二方面への応用

さてこのシミュレーションのほうは、絵にかいたモチの世界ですから、上手い下手とか旨そう不味そうとかいろいろ談義すればそれでいいわけですが、右側の設計自動化のほうは、本当にモノをつくる世界、すなわち絵にかいたモチではなく本物のモチを作ることになるわけです。
よって、シミュレーションは一般的に容易ですが、合成工程を含む設計自動化は、かなりめんどうな話になってまいります。

実際には、HDLでの記述と実回路とのギャップにより、回路の記述性問題と合成可能問題について十分考慮する必要があります。
何故ならばHDL言語系では現実に使用されている回路の記述が困難であったり、言語的に記述可能であっても、この記述からの回路合成が困難な場合があるからです。

VHDLは、もともとVLSIの仕様を記述する目的の言語として、開発されたもので、この記述からの実回路の合成は考慮されていません。 そのため大規模なLSIやハードウェアのアルゴリズム記述とそのシミュレーションに関しては、威力を発揮しますが、このような抽象度の高い記述からの実際の回路の合成や設計の自動化は困難になります。

たとえば、アーキテクチャ設計で、ある回路ブロックにNビット乗算器を使用する場合、AとBの乗算結果をY に出力する記述が、Y <= A*B;と一行で書けますが、このままの記述で合成系に処理させると、8ビットくらいでは屁のかっぱですが、16,32,64,128ビットなーんて無制限に増やしていくと、ついには合成系の処置に400年かかったり、でき上がったシリコンがタタミ三枚分なーんてことになるかもしれません。（まあこうなる前にシステムがオーバーフローするでしょうが）

アメリカの大学では、ハードウェア方式設計のコースがあり、VHDLで設計してこれを履修単位にするところが結構ありますが、新式の64ビットマイクロプロセッサのアーキテクチャを、VHDLの2,000ステップ記述で完成し、シミュレーションもパスして、おおっ設計終了。うんこれはすごいアイデアだ。私は天才じゃー。と思って半導体メーカーやCADのメーカーに持ち込んでも、あのーこんなおおざっぱな書き方じゃあ石がでけへんのやー。ということになります。

まあそんな訳で、回路の合成を目的にする場合や、詳細なハードウェア機能を記述する場合には、RTL(Registor Transfer Level)というかなり具体的な表現法をとる必要があります。

HDL記述性と合成可能問題に関しては、結局緑色の部分を使って記述すれば安全ということになります。この部分が記述可能かつ合成可能領域となります。
しかし青色の実際に存在するハードウェアのリソースを記述するHDL文法がないエリアでは、HDLはお手上げ状態にもなります。
でもこれにはCADの運用によって解決できるのです。

■ 言語のなりタチ

よく知られた言語を性格的に分類してみると、VHDLは標準化と仕様記述を目的に作られたものであり、Verilogは、もともとシミュレーション用の言語であり、ABELはPLDやFPGAのハードウェア回路を合成目的で記述するために開発されたものということになります。
一般的に仕様記述目的のものは、チェーンソーやマサカリでバッサバッサと木を伐採し、森や林道の大規模建設を効率よくおこなうことに適しており、合成を目的にするものは、のこぎりや彫刻刀のようにより繊細な作業で確実に目的のハードウェアを記述することに適します。
シミュレーション目的の言語の場合にはこ れらの中間的なところに位置づけられると考えてよいでしょう。

ここで注意しなければならないのは、よくCADのメーカーが製品の宣伝をするときに、ハイレベル言語、高水準言語によるトップダウン設計という台詞を使いますが、これは、言い換えると"おおざっぱな記述”によるCADまかせの"設計ともいえるわけで、しこしこ回路図を使用した詳細設計が時代おくれだというイメージをあたえがちですが、設計の現場からみると、HDLを使おうが、回路図を使おうが設計には二通りしかなく、その二つというのは不安定動作のダメ回路と高信頼の優れた設計で、HDLか回路図かの手法を論ずる以前の問題です。
詳細設計に未熟達のエンジニアが、後の工程をCADまかせにして、おおざっぱな記述をして設計をしたつもりになるのは、マニュアル操縦ができずに、オートパイロットのみにたよって飛行機を操縦するようなものです。（でも下手なマニュアルよりは、オートのほうがいいって？）

この法則は、80:20の法則とも呼ばれ、よく知られています。例えば、レストランのメニューの上位20%の品目から全売上の80%が達成されているというものです。この法則をVHDL文法にあてはめるてみると、全体の２割の文法で、８割の回路記述はできるということにもなります。私なりにVHDL文法をながめてみると、全体の１割以下の文法でほとんどすべての現実のハードウェア設計が可能ではないかと思います。たとえば、IEEE1164では、13データの型が定められていますが、私はこのうちの3つの型 、すなわちstd_logic,std_logic_vector,integerがあればほとんどこと足りると考えています。さらに合成不能な記述や使用頻度のきわめて少ないものをはぶいていけば、必要な記述は全文法の1割以下になってしまうと思います。このような"でる単"方式の考え方は邪道といわれりゃそれまでですが、最重要な部分からさっさとおぼえていって、それを使ってどんどん仕事をこなし、あとで必要に応じて残りの文法部分をおぼえていけばいいんじゃないでしょうか？

■ 設計手法と回路タイプから文法を吟味する

設計では、モノを作ってナンボの世界ですから、まずシステム設計工程と工程内で不可欠なモジュール単位での回路タイプを列記してみます。そうすると、以下の5項目になります。つまりこれをガイドラインにして、必要な文法系を再構築すればよいのです。

A.システム設計工程で必要なもの

B.階層設計

C.各モジュールの設計

D.制御文

E.シミュレーション用のテストベンチ

■ 習得と使用上のポイント

A.データの型について

VHDLは、高偏差値型の設計現場軽視言語ですから、設計に使用しないデータ型が非常に多く、かつこれらの用法が厳密であり、習得への大きな障壁になりがちです。
そこで、使用するデータの型を合成可能なものかつ絶対必要なものに絞りこんでしまいます。また演算子ごとに使用できるデータの型が異なるため、使用するデータの型を少なくすることは、エラーを少なくすることにつながります。ここでは、三つの型だけを使用します。

B.コンカレントとシーケンシャルの概念

VHDLには、信号結線または単純な信号の伝達、代入(割当)であるコンカレント処理とプロセス文によるシーケンシャル処理の二つの概念が存在します。そして、各種制御文法や宣言や変数が、この二つのなかで入り組んで用いられます。そこでまず、この二つの概念を明確に理解する必要があります。

C.モジュール階層化

一本の長いVHDLソースで設計しないようにします。数百から数千ステップもの一本のソースで記述すると、設計の見通しが悪くなり、スパゲッティー状態になりやすく、デバッグが困難になります。
設計を百ステップ程度の小型のモジュールに分割して設計し、モジュール単位でシュミレーレーションをかけてデバッグし、性能機能を確定しながら、これらを階層的にくみ上げて大きなシステムに統合するようにします。

D.長い記述文 とCADの応用

VHDLでは、論理機能やアルゴリズムの記述部分に比べて、信号の宣言や信号の接続関係のネットワーク記述部分が非常に長くなります。特にテストベンチでは顕著です。そのため、グラフィックスからVHDLソースのテンプレートを出力するようなCAD ツール使用することを薦めます。しかしこれらのツールを使用した場合に、ツールの出したソースを読み切る力は最低限必要になります。現状では、自動生成されたものがそのまま合成に使用可能というわけには行かず、人の手が入ることを想定しておく必要があります。

これまで述べてきたことは、次回以降に順次連載していきたいと思いますので。宜しく。