Ada言語の流れをくむVHDLによる設計
　――ソフトウェア開発者の視点で

伊藤 昌夫（いとう・まさお）
(株)ニルソフトウェア
ソフトウェア・コンサルタント


　初めて，VHDLのコードを見たときの感想は，「Adaにそっくり」というものでした．それとともに，「回路設計の人はよくこんなむずかしい言語をつかっているなあ」と感心した覚えがあります．筆者が最初に覚えたプログラム言語はAdaでした．ただし，そういう人はめったにいないでしょう．現在，Ada言語を使用している人は，交換機や航空宇宙関係の一部にしかいないように思います．それだけ，使われることの少ない言語です．

　しかし，この言語が作られたときはそうではありませんでした．DOD（米国国防総省）が数百ある言語を統一し，信頼性・保守性に優れた，主として組み込み用途の言語を作りたいという意図のもと，国際競争入札を行い制定したのがAdaなのです．ちなみに，この入札で優勝したのはフランス人のチームでした（これも，VHDLがヨーロッパで普及していることと関係があるのかもしれません）．Adaが国際規格に制定された当時（1983年ANSI標準，1987年ISO標準），多くの優れた特徴をもつ統一的な言語として非常に注目を浴びました．


●枠組みが厳格なAda

　Adaの典型的な特徴を，いくつか挙げてみましょう．

(1)強く型付けされた（strongly-typed）言語である

　既定義のデータ型と同様に，ユーザ型を定義できます．また，型に対する操作が，限定されていると言えます．つまり，今，かりに“リンゴ型”と“ミカン型”というデータ型を定義したときに，“加える（＋）”という操作が定義されていなければ，両者を加えることはできません．リンゴとミカンの数を合わせて数えることはしないという意図を，反映しています．

　VHDLの場合，ユーザ型を定義できるものの，抽象データ型を中心とするAdaとは異なっているようです．

(2)インターフェースの分離

　プログラム単位の一つにパッケージがあります．パッケージは，宣言部と本体部からなり，パッケージにアクセス可能なのは，宣言部に書かれたインターフェースを通してのみとなります．つまり，宣言部を読めば，パッケージの仕様が分かります．また，設計途中では，この仕様に相当する宣言部だけを記述し，詳細は開発が進むにつれて書き加えていく，ということが可能になります．

　規模の大きいプログラムの場合，複数人で開発することになります．共同で開発している人は，宣言部の情報だけを見ることにすれば，実現の詳細（本体部）に対する不正なアクセスを避けられるということです．

　VHDLコードでは，外部インターフェースを定める宣言部がエンティティ部，その実現である本体部がアーキテクチャ部に対応します．


●VHDLによる設計に役立つ三つのテクニック

　さて，ここではAdaの紹介を意図しているわけではありません．これらのアイデアは，現在のオブジェクト指向言語であるC++やJavaに引き継がれています．また同様に，いかに設計するかについての議論も Adaとともに深まり，現在につながっています．それらのアイデアのうち，仕様からVHDLコード作成に至る過程で役に立ちそうなアイデアを，主として設計過程の表現の観点から説明したいと思います．

(a)図式化

　図式化というと，「せっかく，回路図からコードに変りつつあるのに…」，と思われるかもしれません．ここで言う図式とは，設計をより抽象化させた表現としての図式です．要求仕様からRTL設計の間には，距離があります．要求仕様にある機能は，より小さな機能単位に分割されます．また，この小さな機能単位中にどのようなエンティティが含まれているか，概観したいと考える場合もあるでしょう．また，同一のVHDLコードでも，2種類の表現があるかもしれません．一つは，特定の視点から見たコード（たとえばふるまいの記述），それから最終的なRTLを意識したコードです．このような場合に，図式が利用できます．たとえば，ソフトウェアの世界で標準的になりつつあるUML（unified modeling language）が利用可能です注．

　図式にすることで，一つには見通しがよくなるという利点があります．また，VHDLを含めて，新しいプログラム言語は多くの構造を持ちます（先の例でいうと，抽象データ型およびインターフェースの分離）．図式にすることによって，これらの構造も明確になります．

(b)設計手法と設計過程

　ソフトウェア設計の場合，先のAda言語の場合では，BoochやBuhrという人たちによって開発された方法論があります．プログラム言語としてのよさや潜在能力は，システムを表現する場合の記述能力とは異なります．したがって，先に述べたモデル化や詳細化の過程を支援する手法が必要になるということです．

　さらに，これら詳細化の過程を記録することは，設計のトレーサビリティ（追跡可能性）の確保を考える上で重要です．このトレーサビリティにより，最終的に，要求仕様中にある機能と，VHDLコードの対応関係をつけることができます．要求仕様に対して，ある変更が加えられたときに，VHDLコードのどの部分に影響が及ぶのか，あるいはVHDLコードのある部分がどの設計に対応しているのかが分かることによって，仕様変更に対応しやすくなったり，次に述べる再利用も容易になります．

(c)再利用

　仕様をモデル化する過程で，再利用可能なかたまりが見つかる場合があります．もちろん，このレベルで物理的なコンポーネントを意識する必要ありません（上記に示したUMLでこのコンポーネントもまた図式化することができます）．

　もちろん，このコンポーネントは組み合わせ回路や順序回路，さらには複雑なIPコアとして実現化されるかもしれません．しかし，大事なのは，このコンポーネントをモデル化および文書化することだと思います．

　ソフトウェアの世界でも，ずいぶんと再利用が言われてきましたが，その結論は，設計情報ともに，モデルや文書の共有を図るということです．この場合，必ずしもコード（プログラム）がなく，設計情報だけが共有される場合も含みます．もちろん，この情報のなかには，先にAdaの例で見たような明確な仕様の定義が必要です．


●なぜ，Adaは普及しなかったのか

　さて，最後に一言．なぜ，信頼性や保守性を向上させるためのアイデアを盛り込んだAda言語は普及しなかったのでしょうか．考えられる理由の一つとして，厳格な検定プログラムがあって，このプログラムを通らない限りAdaコンパイラとして認められなかったこと（移植性・保守性を確保するための要件である）が挙げられます．あるいは，処理系が高価だったことも，理由の一つかもしれません．

　それとも，仕様が膨大で，むずかしかったから？ ソフトウェアに関わる人間としては悔しいので，こうは思いたくはないのですが…．



注　UMLについては，標準策定中のOMGのホームページ 「http://www.omg.org/」，または「http://www.rational.com/」に情報があります．最新の正式バージョンは1.1になります．


(本コラムは1999年8月発売の本誌23号付属CD-ROMに収録されました)


◆筆者プロフィール◆
伊藤昌夫（いとう・まさお）．自動車会社，航空機関連会社のソフトウェア・エンジニアを経て，ニルソフトウェアを設立．ソフトウェア・プロセスおよび開発環境が専門で，そのためのコンサルテーションおよびツールの提供を行っている．設計における人間の認知活動に興味を持っている．



Copyright(C) 1999 CQ Publishing Co., Ltd. All Rights Reserved.