\documentstyle[a4j,ascmac,fancyhd,11pt]{jarticle} \pagestyle{fancyplain} \lhead[\fancyplain{}{}]{\fancyplain{}{\thepage}} \rhead[\fancyplain{}{}]{\fancyplain{}{\sf Art \& Science Laboratory}} \cfoot{} \setlength{\footskip}{15pt} \setlength{\headheight}{25pt} \setlength{\oddsidemargin}{1in} \setlength{\evensidemargin}{1in} \begin{document} {\Huge 特集：ロジック・プログラミング入門} \section{ロジック・デバイス・プログラミングの基礎知識} \paragraph{はじめに} \paragraph{} 本特集では、「ロジック・プログラミング」について紹介していきます。 この「ロジック・プログラミング」という言葉にあまりなじみのない 方にとっては、パソコンやC言語といった、ソフトウェア用語の 「プログラミング」をイメージされるかもしれませんが、実はかなり {\bf ハードウェア寄りの技術}なのです。 これまで、ディジタル技術、あるいはマイコン技術の世界のエンジニアは、 「ハード屋」と「ソフト屋」とで分業していました。 しかし、これからの時代のエンジニアは違います。 システムをハードとソフトの融合した柔軟な視点で設計・構築して、 ソフトウェアを自由に創造するのと同様に、ハードウェアまでも新しく 生み出すことができるようになってきました。 ここで扱う「ロジック・デバイス」とは、エンジニアが独自のハードウェアを 設計していける、もっともシンプルなデバイスなのです。 この章では、ロジック・デバイスの生まれてきた事情や、ロジック・ プログラミングのポイントをまとめて、より進んだエンジニアとして活用 していくための技術を概観していきます。 いったん理解してしまえば、ディジタル技術のあらゆる局面に 生きてくる強力な技術ですから、ぜひ前向きにトライしてみましょう。 \subsection{ロジック・デバイスの登場} まず最初に、この「ロジック・デバイス」という一群のIC/LSIが 誕生するまでの、簡単な「歴史」をまとめてみましょう。 これはある種の{\bf ディジタル回路技術の歴史}といえる ものかもしれません。 \subsubsection{ディジタル回路の構成要素} ディジタル回路を構成する基本的な要素として、一般にはTTLやハイスピード CMOS(HS-CMOS)などの{\bf 標準ロジックIC}を使って、論理回路や 順序回路、あるいは演算回路などを設計します。 またCPUを使った回路でも、CPUやメモリの周辺に標準ロジックICを使って、 デコード回路やタイミング回路などを実現しています。 もっとも初期の標準ロジックICは、ANDゲートやORゲートなどの、いわゆる {\bf 論理ゲート}をパッケージに複数個入れたものから始まりました。 そしてすぐに、フリップフロップや多入力ゲート、エンコーダやデコーダが 加わり、さらには多ビットのラッチやカウンタや加算器など、特定の機能を もった回路IC群として次第にその種類を増やし、ついに現在のような 数百種類のファミリとなりました。 ディジタル回路を設計するエンジニアは、希望する電子回路に対して、 いろいろな標準ロジックICを{\bf 組み合わせて設計}します。 データブックを何度も参照しては各ICの機能を覚えて、「ブラックボックス部品」 として組み合わせて、回路動作を実現していきました。 各メーカから次々に提供される標準ロジックICも、機能的な互換性を保ちながら ファミリごとに進化して、いろいろなバリエーションを生み出しました。 たとえば \begin{itemize} \item 消費電流の少ないファミリ \item ゲート速度の速いファミリ \item CMOS版のファミリ \end{itemize} などであり、同じ論理機能を表すIC番号(たとえばNANDの00) であっても、無印、LS、ALS、S、F、HC、などの記号がそれぞれ 付けられました。 \subsubsection{標準ロジックICでのディジタル回路設計} これらTTLなどの標準ロジックICによる回路設計のメリットは、IC内部 にあるトランジスタ回路の動作を、アナログ的な意味でまったく気にしなくて いいことです。 つまり、IC同士のピン接続はTTLやCMOSの共通の規格によってインター フェースされるために、よほど多数のICが特定のICの共通ピンに 接続されない限り、電圧はもちろん電流についてもマージンが大きく、純粋に {\bf 論理的動作だけを考える}ことができます。 そこでディジタル回路の設計というのは、希望する回路動作を機能的に分解して 単純化させ、それぞれの細分化された機能に該当する標準ロジックICを捜して 割り当てていくこととなりました。 これは一種のパズルです。 もし、ちょうどぴったり該当するICがなければ、その論理をさらに 細かいゲートに分解していけば、いずれは基本ゲート(AND・OR・NOT、 あるいはNAND・NOR・EXORなど)に分解されるので、これらの 標準ロジックICで構成すればよかったのです。 また、やがてCPUがディジタル回路技術の中心として進出してきました。 このCPUの周辺回路として、クロック回路やメモリのタイミング回路、 I/Oのためのデコード回路やリード/ライトの制御信号回路などが必要に なりますが、これも単純な標準ロジックICで実現できました。 このように、ディジタル回路はすべて基本的にはDIPパッケージに入った 標準ロジックICファミリ、そして+5V単一電源(とユニバーサル基板)によって、 ボード上にずらりとTTLやCMOSが並ぶ、というおなじみの風景となったのです。 たとえば中古のパソコン(MSXや8ビットパソコン)のケースを開けて みると、この時代の標準的なシステム技術の実例がよくわかります。 \subsubsection{マイコン技術の浸透} 秋葉原のパーツ屋さんでTTLを捜してきて、ディジタル回路を実験・製作 するホビーストは今でも多いのですが、エレクトロニクス技術の進展 は、プロの世界をこれとは別のレベルに牽引していきました。 時代は「マイコン化(ソフトウェア化)」「軽薄短小化」に進んだのです。 「マイコン化」とはもちろんCPUの普及です。 かつては「マイコン炊飯器」とか「マイコン扇風機」など、マイコンの名を つければ付加価値が上がった印象を持たれる時代がありました(これは 「AI」とか「ファジイ」「ニューロ」など、つねに繰り返されています)。 そして今では、どんな小さな家電製品であっても、内部にCPUの一つや二つを 使っているのは常識です。 パソコンの場合にも、中心のメインCPUだけでなく、キーボードやI/Oボード 等の周辺機器にも、それぞれ1チップマイコンがふんだんに使われています。 このようにマイコンが「部品」の感覚で使われるようになると、ディジタル・ システムの回路設計法も変化しました。 従来ならばハードウェア(標準ロジックIC)で構成した機能も、 かなりの部分がCPUのソフトウェアとして実現できるのです。 たとえば、ある信号の論理を反転したければ、従来は回路図にインバータ04 を入れたのですが、CPUのソフトとして「反転」を指示すれば、ハードウェアは まったく変更がいりません。 同様に、標準ロジックICで設計できるほとんどの論理機能は、基本的にCPUの ソフトウェアとしても実現できるために、ディジタル・システムにCPUが 使われるようになって、ハードウェアの構成比率はどんどん低下して いきました。 標準ロジックICのチップ価格はそれほど劇的に下がりませんでしたが、 CPUのコストダウンと飛躍的な機能強化は確実に進み、コストの点でもCPUの ソフトウェアとして機能を実現する方が有利になりました。 こうなると、ハードウェアとして残された部分は、{\bf CPUでは遅くて 処理できない部分}を中心とした領域になりました。 たとえばCPU回路のI/Oデコーダ回路やリード／ライト信号回路などは、 CPUの命令サイクルのタイミングより高速でなければなりませんから、 CPUのソフトウェアとして実現することはできません。 また、CPUのソフトでは処理が間に合わない機能(演算・判定・多ビット データ処理など)については、CPUよりも3桁ほど高速な専用ハードウェア の仕事となりました。 \subsubsection{標準ロジックICの限界} そして、「軽薄短小」の流れも標準ロジックICを圧迫していきました。 省エネルギーの視点からみれば、電子回路システムの消費電力を少なく、 さらにシステムの回路基板を小さく軽く設計することは、明らかに プラスとなります。 ところが、従来のトランジスタ回路よりもコンパクトだった DIPパッケージの標準ロジックICは、機能の増大とともに回路規模が どんどん大きくなるディジタル回路では、数量が増えて基板上にずらりと 並ぶと、小型化のネックとなるようになりました。 周辺のチップ部品の充実とともに、ICのミニフラットパッケージが広く 出回ってきたのは、ごく最近のことなのです。 超大手電気メーカでは、ASIC技術によってカスタムLSI化することで、 ディジタル回路部分のサイズを画期的に小さくし、同時に消費電力まで コンパクト化していきました。 ところが汎用の標準ロジックICを使っての回路設計では、必要な機能を実現 するためには、それぞれの標準ロジックICに「余分なゲート」「余分な端子」 が余り、一方でちょっとだけ不足するゲートのために別のICを用意するなど、 どうしても小型化に限界がありました。 また、時代は「一機種大量生産」から、趣味の多様化に対応した「少量多品種 生産」にと移行していきました。 ところが、ある機能のディジタル回路を汎用の標準ロジックICで設計して いると、ちょっとした機能追加・仕様変更・機能種別(ラインアップ)に対しても、 いちいち基板のパターン変更が必要となります。 つまり、ハードウェアによる一品料理のシステム構築はとても効率が悪い、 という時代となってしまったのです。 このように、標準ロジックICという便利な「汎用部品」は、少量多品種の システムを設計する業界のメーカ、あるいは特注試作開発のシステムハウス にとっては一種の「足かせ」となってきました。 \subsubsection{ロジック・デバイスの登場} そしてここに、「ロジック・プログラミング・デバイス」(ここでは 略して{\bf ロジック・デバイス}と呼ぶ)という一群の ICが登場しました。 これは朗報でした。 ロジック・デバイスは基本的に汎用ICで、メーカによっていろいろな品種 のものが大量生産されますから、標準ロジックICに加えてまた新しい ファミリが出てきた、という見方もできます。 しかしここには、本質的な違いがあります。 つまり、{\bf ロジック・デバイスの各チップの「機能」は決まっていない}のです。 この特集でこれから述べるように、ロジック・デバイスはチップの論理機能を ユーザであるエンジニアが{\bf 自分でプログラムできる}ことを特徴と したICです。 これまでは「必要な機能の標準ロジックICをデータ ブックから捜す」ことが設計だったのですが、ロジック・デバイスを 使ったディジタル・システムの設計者は、「必要な機能をロジック・デバイス にプログラムする」ことができるようになりました。 これは従来のハード屋には全く存在していなかった仕事です。 実際はパソコンなどのソフトウェアとして提供されている「設計ツール」 を駆使してロジック・デバイスをプログラミングし、さらにパソコンに つないだ「ロジック・デバイス・ライタ」という装置を使って、チップ機能 の書き込み作業を行います。 ロジック・デバイスの登場は、ハードウェアの設計者に対して、なにやら ソフトウェア屋のような仕事まで生み出したのです。 しかし一方で、{\bf 原理的には任意の回路をチップとして実現できる}と いう、それまでのハードウェア設計エンジニアの夢をかなえたIC、と 見ることもできます。 いわゆるハードウェア屋としての仕事(回路設計からハンダ付けの試作) とは別種の、ソフトウェア屋のような作業さえ理解して身につけてしまえば、 かなり高度なディジタル・システムを、ICチップから自由に設計 することが可能となったのです。 「メーカの大きさを越えたビジネス」の可能性を開拓した、これは一種の革命 とも言えるものになりました。 \subsection{ロジック・デバイス活用のポイント} このようなディジタル回路技術の歴史を受けて登場したロジック・デバイスは、 エンジニアに対して「発想の転換」を求めています。 この新しいデバイスを活用できるのは、新しい発想を受け入れられる柔軟 なアタマと、ハードだけでなくソフトも扱える強固で繊細なカラダをもった、 新世代のエンジニアだったのです(もちろん物理的年齢でなく、精神的年齢)。 ここでは、ロジック・デバイスを活用するエンジニアに必要なポイント を、いくつかの視点からまとめて紹介していきましょう。 \subsubsection{基本はやはり標準ロジックIC} ロジック・デバイスが登場したばかりの頃、ソフトウェアで論理設計できる デバイスができたから、もう分厚いTTLデータブックは不要だ、などと言う 人もいました。 しかし残念ながら、これは間違いです。 ロジック・デバイスもディジタル回路技術の要素ですから、やはり基本は 標準ロジックICにあるのです。 ロジック・デバイスを設計するための基礎的な概念や思考法のためには、 \begin{enumerate} \item TTLやCMOSのDIPパッケージのハンダ付けがサッとできること \item 基本的ゲート(04,08,32,00,02,86等)の論理表をサッと書けること \item 基本的機能(デコーダ、F/F、カウンタ、ラッチ等)を知っていること \item スリーステート、オープンコレクタなどを知っていること \item 1MHzのクウォーツ精度のクロック信号発生回路を作れること \item CPUのアドレスデコーダをTTLで自由に設計できること \item CPUのリセット信号発生回路をサッと作れること \end{enumerate} などのもっとも基本的な事項は、標準ロジックICに関連して理解して いなければなりません。 しかし、たとえば筆者はごく基本的なTTLの番号と機能だけは、いつのまにか 身につきましたが、特殊な機能や複合機能の、あまり使われない 番号のTTLはまったく知りませんし、覚えるつもりもありません。 これはもし必要があれば、その時にデータブックから捜せばいいからなのです。 かつてのハードウェア技術者は、「持ち駒」であるTTLファミリの番号と 機能を、なるべく多く暗記していることが勲章でもありましたが、これは 現代では不要になりました。 つまり、ディジタルICの基本的な機能さえ理解していれば、あとは ロジック・デバイスの開発ソフトがIC番号を捜してくれるし、ちょうど 該当するICがなくても構わないのです。 このように、覚える負担は軽くなったのですから、最低限の基本として、 標準ロジックICの技術をしっかり押さえておきましょう。 \subsubsection{最初のレベル：まず置き換え} 標準ロジックICを使ってディジタル回路を設計していたエンジニアが、 ロジック・デバイスを活用するための最初の方法として、「まずTTLを 単位として回路設計し、これをロジック・デバイスに置き換える」という ステップがあります。 かなり小規模のロジック・デバイスでも、たいていの基本的標準ロジックICを 置き換えることができます。 さらに場合によっては、数個のTTLを1個にできるかもしれません。 これは標準ロジックICの設計に慣れた人にとっては親しみやすく、また ロジック・デバイスの設計方法を理解していきやすいために、おすすめです。 大規模なロジック・デバイスや、その延長にあるASIC設計の世界でも、 ある基本機能をコンパクトに表現する「部品」として、標準ロジックICの 記号は生きています。 たとえば「3入力8出力のデコーダに正と負のイネーブル付き」というよりも、 ひとこと「138」と言ったほうが簡単ですし、ICが実際に存在しなくても、 ロジック・プログラミングの世界では、「138を5入力32出力にしたもの」 という扱いができます。 このように、まず最初のステップとして、ディジタル回路動作の参考として、 標準ロジックICを念頭において、その「置き換え」として設計する視点を もっておきましょう。 \subsubsection{論理プログラミングのレベル} ロジック・プログラミングの考え方と開発環境に慣れてきたら、もっと 回路設計の抽象度を上げていきます。 つまり、標準ロジックICのような具体的な機能単位に置き換えて考える ステップをとばして、最初から論理的にチップ機能を表現します。 あとに詳しく紹介されるように、ロジック・プログラミングのための 論理記述にはいろいろな形式があります。 標準ロジックICに近い表現、データ信号からみた表現、ブラックボックス の入出力としての表現、論理式表現、遷移状態の表現、あるいはソフトウェア の関数表現と似たものもあります。 この全てをマスタする必要はありません。 自分の理解しやすいものから試して、とにかく「実際にやってみる」こと から覚えていくのが早道です。 ロジック・デバイスのプログラミングでは、たとえばパソコン上の ソフトウェアとして、いろいろな種類のツールを活用します。 まずはパソコンのシステム(DOSやコンパイラなど)を理解して、作業に 使うツールとその働きを理解することも必要になります。 そしてこれと並んで、対象となるディジタル電子回路をロジック・デバイス や他の部品の組み合せにブレークダウンする設計技術も、もちろん 必要です。 システム設計の内容が、ハードともソフトともつかない、漠然とした総合的に ものになっていくわけです。 ちょっと大変に感じるかもしれませんが、慣れてみると非常に美しい、 なかなかエンジニア冥利につきる楽しい世界です。 後込みせずに、チャレンジしていきましょう。 \subsubsection{ロジック・デバイス・プログラミングのポイント} 具体的なロジック・デバイスのプログラミング方法については、それぞれの ファミリごとのハードウェア条件(チップ上に搭載された機能)や、 開発支援ソフトなどによって異なります。 以下の章では、このそれぞれが詳しく解説されています。 ここではそのような個別の条件には触れずに、全体として共通する ロジック・プログラミングのポイントについて考えましょう。 まず、パッケージとピン数、そして入出力回路の部分をよく理解すること です。 一般に、ロジック・デバイス化できる回路というのは一通りでなく、 回路の見方によって何通りものブレークダウンの方法があります。 とくに複数ビット単位のデータを扱う場合には、チップのもつ入出力ピン の本数が決定的な制約要因になる場合が多いので、もっとも基礎の部分と して、各チップごとの入出力条件を押さえておくことが大切です。 次に、冗長な設計を避けるための「等価回路パズル」をつねに意識する ことです。 ある回路部分をロジック・プログラミング・ツールで記述できたとして、 そこに冗長な部分や無駄な部分がないか、あるいは余分なステップで遅いものに なっていないか、という確認の視点をつねに意識することは重要です。 そこで、いつも「もっと別の表現でスッキリならないか」と考えるクセ をつけるようにしましょう。 これは少しずつ、経験とともに適切な設計の習慣となっていくものですが、 大規模なシステム設計やASIC化のためには、ぜひとも身につけておきたい センスなのです。 そしてもう一点、「シミュレーションに手を抜かない」ことをあげて おきましょう。 ロジック・プログラミングでは、ソフトウェア上で設計されたロジック・ デバイスのチップ設計の論理を確認するために、テストプログラムによる シミュレーションをサポートしています。 これはロジック・デバイスにちょっと慣れた人にとっては、どうせ正しく 設計されている論理の確認など、形式だけのことだから適当なところでいいや、 とも思えてしまうものです。 しかし、ロジック・デバイスの規模と複雑さは今後もどんどん巨大化して いきます。 また、このロジック・プログラミング技術をASIC設計につながる 基本と考えると、せっかくサポートされているシミュレーション機能を 活用して、「自分の論理設計の正しさをテストプログラムで確認する」 という姿勢を身につけることは、とても重要です。 とくにフレッシュマンには、ちょっとくどいほどのテストを作ってみる、 という姿勢をおすすめします。 \subsubsection{もう一つの視点：知的財産権} ここであと一点、ぜひ触れておきたいのが、ロジック・デバイスの持つ重要な 特徴である、{\bf 機密保持性}というポイントです。 いちばん最初の世代のロジック・デバイスから、ファミリの中には 「フューズタイプ」と呼ばれる、プログラム情報を焼き切って解読できなく する機能をもつものがありました。 つまりロジック・デバイスというのは、海賊版やデッドコピーの製造、 あるいはライバル企業の解析を困難にするという「政策的チップ」でも あったのです。 もし、マイコン応用機器が汎用CPUと汎用の標準ロジックICだけで できていたとしたら、このシステムの解析は非常に容易です。 基板のパターンを追いかけていけば回路図ができ、CPUのプログラムROMを 逆アセンブルすればCPU動作が解析できて、結局その製品を開発した メーカのノウハウは、すべて簡単に入手することができてしまいます。 ところが、回路の中にロジック・デバイスが使われていると、このような 解析はぐっと困難になります。 ロジック・デバイスのピン配置と内部回路とは、標準ロジックICのように 簡単にはわかりません。 さらに内部の論理機能も不明です。 基板上に何個ものロジック・デバイスが置かれてしまえば、かなり強力な コピープロテクトになって、苦労して開発してきたメーカの努力が 守られるのです。 そしてシステムを設計したメーカの方は、そのロジック・デバイスを設計した時の ロジック・プログラムのソースリストやドキュメントがありますから、 ちょっとシステムを変更した応用機器や、バージョンアップ、マイナーチェンジ などの際のロジック・デバイス設計も、ゼロからのスタートよりもかなり 容易になります。 これも、一種のノウハウ優位性の保護といえるでしょう。 \subsection{ロジック・デバイスによるシステム設計} ロジック・デバイスという新しい「持ち駒」を手にしたエンジニアは、 ディジタル・システムを新しく設計する際に、従来よりも柔軟な視点から システム構築をできるようになります。 そしてロジック・デバイスは、{\bf 設計の自由度の増加とともに、コスト 戦略的にも強力}な援軍となるものです。 また、機密保持性とも関係しますが、{\bf 仕様変更への対応が容易}な システムとするためにも、ロジック・デバイスの活用は有効です。 ここでは、このような「システム設計の視点」から、ロジック・デバイスを 全体的に検討していきましょう。 \subsubsection{ディジタルシステムのトレードオフ} なにかディジタル電子回路システムを新規に設計する場合、最初のトレードオフ は{\bf CPUを使うかどうか}です。 まず、スイッチを押して30秒たったらLEDが点滅する、などという非常に 単純な動作だけであれば、標準ロジックの組み合せだけで作ります。 これはいわば「電子工作」のレベルです。 実はディジタル回路の各部分も、分解していくとこのような単純な機能の 組み合せである場合が多いので、軽視すべきものではありませんが、 本特集で検討するシステムはもう少し大規模なものを想定しています。 システムがある程度の複雑な処理を行うのであれば、今は迷うことなく CPU(マイコン)を使うのが常識です。 赤外線リモコンに使われる単純な4ビットCPUなら、100円とか200円のコスト で、もはや「ソフトウェア」という特別意識もない、単純な「部品」でしか ありません。 さらに、もう少し高度な処理内容や処理速度が必要な場合には、8ビット汎用CPU や1チップCPUタイプのものを使います。 もちろん、単体のCPUを使う代わりに、「ボードマイコン」「カードマイコン」 というモジュールを、部品のように使ってしまうことも一般的です。 そして、CPUを使うシステムごとに固有のハードウェア(I/Oアドレスや 周辺など)となる部分が出てきます。 CPUのソフトとしては記述できない、CPUのタイミング信号や制御信号の 部分、アドレスデコーダ、メモリ周辺回路などもハードウェア設計の 対象となります。 さらに、場合によってはCPUのソフトウェアでは処理が間に合わない 部分もあります。 たとえばRS-232-Cのようなシリアル通信では、UARTなどの専用LSIが インターフェース部分をハードウェアとして補助(シリアル---パラレル 変換、データのバッファリング、割り込み信号発生)することで、 ようやく処理の中核部分をCPUが担当できます。 たとえば、CPUの1ビットポートとしてシリアル通信ラインを直接に制御 しようとすれば、ボーレートは100bps程度の超低速通信がやっとです。 このように、スピードの必要な部分はハードウェアによって実現し、 それ以外の部分はなるべくCPUのソフトウェアとして吸収するようにして、 システム機能をハードウェアとソフトウェアに切り分けていくのが、 最初の段階のトレードオフ設計となります。 \subsubsection{ハードウェアの中でのトレードオフ} システム全体のトレードオフ設計でハードウェアの部分が決ってくると、 次にはこのハードウェア部分を具体的にどう実現するか、という トレードオフの検討が待っています。 ここでの持ち駒としては、 \begin{enumerate} \item TTLやCMOSなどの標準ロジックIC \item CPU周辺LSIファミリ \item インターフェースICやD/Aコンバータなどの特定機能チップ \item ロジック・デバイス \item 専用LSI(ASIC) \end{enumerate} などがあります。 なお、ここでは最後の「カスタムチップを起こす」という選択肢は、 解説を別の機会に譲ることとして除外しておきます。 ロジック・デバイスが登場する前の時代のシステム設計であれば、手持ちの 材料は、標準ロジックIC、CPU周辺LSI、特定機能チップという汎用のもの しかありませんから、この「組み合せ」として、設計の考え方も非常に シンプルでした。 つまり、高密度に最適化されている周辺LSIと、アナログのからむ特定機能 チップは優先的に決定されて、「残りの部分を標準ロジックICで組む」と いう方法しかありません。 ところがロジック・デバイスがここに加わると、ちょっと状況は複雑に なってきます。 ロジック・デバイスというのは{\bf 機能をプログラムするIC}ですから、 「この部分に使えるチップは何か」でなく、「この部分をプログラムする」 という発想の転換が必要です。 ある回路部分に使える最善の標準ロジックICというのは、たいてい1種類に決って いますから、これまでのディジタル設計はある意味で「必然的な解答」を 求めていくものでしたが、ロジック・デバイスになって、設計の自由度が 飛躍的に拡大したことになります。 たとえば、デコーダの138では、3つのイネーブル入力のうち1つが正論理で、 2つが負論理です。 ところが、実際の回路設計では、「この逆に2つが正論理であったら よかったのに」とか、「イネーブル入力があと1つ、余分にあったら よかったのに」とか思うことがあります。 このように、標準ロジックICでは個々のパッケージに格納された機能の制限 がありましたが、ロジック・デバイスではこのような制限がなくなります。 これは見かたを変えると、従来は標準ロジックIC単位で機能が(強制的に) 切り分けられていたのに、今度はディジタル回路のどこでチップの単位を切り 分けていけばいいかの指針が、なくなったことになります。 設計者の自由度として、このコントロールが委ねられたわけです。 ここであまり単純なブロックで分けていくと、それでなくてもかなり高価な ロジック・デバイスを、必要以上に数多く使うことになって、標準ロジックIC で設計する以上のメリットがなくなる可能性も大きいのです。 たとえば、回路中の単なるインバータを無理にロジック・デバイスの中に 入れるために、貴重なピンを2本割り当てて、さらに内部の多入力NANDの 他の入力を全部プルアップする、という「設計」をしたとして、これが 妥当なものかどうか、という冷静な視点が常に必要になります。 ロジック・デバイスに、なにがなんでも標準ロジックICによるランダム ロジック部分を全て入れる、というものではないわけです。 そこで、ハードウェアのどの部分をロジック・デバイス化して、どの部分を 標準ロジックICで設計するか、という第2のトレードオフも重要なのです。 \subsubsection{ロジック・デバイス化に適した回路とは} ハードウェアの中でロジック・デバイスに入れるのに適した回路はなにか、 というのはなかなか難しい課題です。 ここでは筆者の経験から、いくつかのポイントをあげてみますが、 システムの特性や回路規模によって、まだまだ別の視点(ノウハウ)も あると思います。 あくまで「一例」として参考にして下さい。 まず、ハードウェアの中で「周辺LSI」を採用した場合の視点が適用できます。 周辺LSIとは、ランダムロジックとして構成するよりも、メーカが専用設計で 高密度にレイアウトして集積度が高く、さらに汎用チップとして量産 されるためにコスト的にも有利なものです。 そこで、標準ロジックICの中でも、たとえば161や166、あるいはアダーの 83に相当する機能などは、ほぼ機能の全てを使う場合には、それぞれの 標準ロジックICを単体で使ったほうが有利となります。 ただし、「クリア入力は不要」とか、「ビット数がもっと少ない」などの 過剰仕様の場合には、ロジック・デバイスで最適化するほうがコンパクト になることもあります。 このポイントとしてまとめると、「標準ロジックICにそのものズバリの 機能ブロックがあれば、無理にロジック・デバイス化しない」ということ になります。 そして、次の視点はやや意外かもしれませんですが、{\bf システム全体の生産 コストから考える}こともあります。 ディジタル・システムの宿命かもしれませんが、機能仕様の変更、 バージョンアップ、マイナーチェンジ、そしてバグの対応などの理由で システムを変更することは非常に多いものです。 ところがROMに書かれたプログラムの改訂と違って、ハードウェアの 変更はとても大変なものです。 ごく少量の場合には、パターンカットやジャンパ線の手作業もありますが、 一般にはプリント基板の変更となります。 これはかなりのコストとともに、相当の開発期間を必要とする対策です。 そしてここに、ロジック・デバイス活用の最大のメリットが効いてくるのです。 つまり、{\bf 変更の可能性のある部分をロジック・デバイス化する}という セオリーです。 たとえばCPUのアドレスデコーダ回路は、ある特定のシステムについては、 138とか688などを使って、かなりコンパクトに設計することができます。 ところが、あとで「I/Oをあと一つ増設したい」とか、「アドレスマップを 変更したい」となると、プリント基板のパターンを変更する大改変となって しまいます。 ここにロジック・デバイスを使ったらどうなるでしょう。 標準ロジックICのピンをぎりぎりまで使い切っている回路では、I/Oの増設は IC数の増加となって、基板のレイアウトにまで影響します。 ところがロジック・デバイスでデコーダを作っておけば、プログラム を変更することで、追加もかなり容易になります。 また、アドレスマップの変更となると、標準ロジックICでは全体に 設計をやり直す必要がありますが、ロジック・デバイスであれば、新しい マップに従ってデバイスをプログラムするだけでよく、基板にソケットを 使っておけば、差し替えるだけで何の変更もいらなくなります。 これは開発・製造コストとしてかなり効きますから、チップとしては 高価なロジック・デバイスを採用するための、重要な要因となります。 もう一つのポイントは、秘密保持を考慮した使い方です。 回路にちらばったランダムロジック(単純な多種類のゲートの組み合せ)の 部分を、ロジック・プログラミング・ツールによって論理的に等価回路 としてうまくロジック・デバイス化すると、基板の姿がスッキリします。 CPUや周辺LSIなどの他に単純なゲートICがなくて、なにやら正体の知れない ロジック・デバイスがあるだけ、というシステムでは、第三者の「解析」 に対して非常に強力に対抗します。 一般にプリント基板の回路解析は、汎用のチップのピンから信号を推定して、 プリントパターンを追って、論理ゲートの論理をたどっていきます。 ところがロジック・デバイスでこのランダムロジックを包んでしまうと、 途端に解析が困難になるわけです。 原理としてはシンプルでもできれば知られたくない回路には、ロジック・ デバイスをさりげなく使ってみる作戦が有効なのです。 \subsubsection{ロジック・デバイス間のトレードオフ} このようなポイントに対してロジック・デバイスを活用していきますが、 ロジック・デバイスにも、最近ではいろいろのタイプのものがあります。 初期のPAL(商標)は、もっとも基本的な多入力AND-ORロジック程度のもの でしたが、F/Fを持つもの、入力フィードバックのできるものなどが 加わって、活用範囲がぐっと広がりました。 また、GALを経てFPGAとかLCAといった大規模なものになると、内部ゲート として数千から一万になるものまであり、コストと実効ゲートを別にすれば 文字通り「ユーザが1個から作れるゲートアレイ」のようなものまで あります。 以下の章で紹介されますからここでは個別に触れませんが、これらの各種の ロジック・デバイスの特徴とか最新状況を常にチェックして、 システムの中でロジック・デバイス化すべき部分があった時に、どの レベル(規模、コスト、機能)のロジック・デバイスを使うか、という 最後のトレードオフも重要なものといえるでしょう。 なお、ディジタル回路設計としてロジック・デバイスを考えると忘れがち ですが、{\bf システム・コストの視点}も大切です。 たとえばそのシステムが、 \begin{itemize} \item 1台かぎりの実験試作システム \item ASIC化の検討のためのブレッド・ボード \item 当面1台だけ試作し、場合によって追加オーダもある特注機器 \item 量産の前に評価するための数セットの試作装置 \item 少しずつ仕様を変えて少量多品種で生産する製品 \item とりあえず1ロット、どーんと量産する製品 \end{itemize} のいずれであるかによって、使えるロジック・デバイスのコスト帯も変わり、 さらには使う意味づけも変わってくるのです。 たとえば実験・試作システムであれば、カットアンドトライのために 高価でも「何度も繰り返しプログラムできるデバイス」(消去可能型)を 使うのが有効です。 あるいはASICのブレッドボードとして使う場合には、ゲート遅延の 影響があるので、かなり高密度なものをリッチに(無理に詰め込まずに) 駆使してスピード重視とします。 このコストは相当ですが、それでも高速標準ロジックICを数百個使った 基板を特注試作するよりも、かなりコストメリットがあります。 また少量生産の高付加価値製品では、ノウハウを守るためにハイレベルの 高価なロジック・デバイスを活用して、基板の秘密保持と機能向上をねらう 場合が多くあります。 もう少しロット数量が多い製品に「部品」として使用する場合には、 通常の部品と同様に単体コストを十分に検討して、標準ロジックICの方が 安くできて基板上のスペースもあるのなら、無理にロジック・デバイスは 使いません。 逆に、数個の標準ロジックICを1個のロジック・デバイスに置換できることで 基板スペースのコンパクト化に貢献する場合には、量産製品の部品として 採用する場合もあります。 ここでは、メーカや代理店が出荷時に、FIXしているデバイス・プログラミング 作業を代行することもあります。 このように、いろいろなロジック・デバイスを機会があるたびに使ってみて、 実際のシステム設計の際の「使える持ち駒」として理解していることは、 これからのディジタル・システム技術者の重要なスキルになることと 思われます。 ある程度は「知らなくてもなんとかなる」技術なのですが、「知っていれば とても強力な材料」となる技術、それがロジック・デバイスなのです。 前向きなエンジニアにとって、興味と手ごたえのある領域だと思います。 \subsection{ロジック・デバイスからASICへ} いくつかの視点からロジック・デバイスを考えてきましたが、筆者の意見と しては、{\bf ロジック・デバイスは終着駅ではない}と思っています。 これには異論があるかもしれません。 ある部分、ある領域のディジタル回路は今後ともロジック・デバイスが 担当していくのだ、という意見もあります。 この意見は尊重するとしても、ディジタル・システム技術者、あるいは マイコン・システム技術者にとっては、ロジック・デバイスに関する 技術を身につけることは「途中駅」であって、最終的には{\bf 誰もがASICを 作る時代}に向かっていって欲しいと願っているのです。 ここで筆者がイメージするASICとは、FPGAやLCAの延長にあるものと一致する のかもしれません。 「システムのソフトウェアとともに、ハードウェアもオリジナル設計する技術者」 というエンジニアの理想に向かって、ここではロジック・デバイスからASIC につながる、ディジタル・システムのエンジニアリングについて考えて いきます。 これは単に「デバイス」というよりも、「技術」そのものの考え方に関する、 より重要なことだと思います。 \subsubsection{ハードウェアを設計するのは誰か} ある一定の機能・規模のディジタル・システムであれば、今後はたいていの ものがCPUを使った「マイコン・システム」になっていくことになります。 従来であれば、このようなマイコン・システムの設計・開発というのは、 ハードウェア屋とソフトウェア屋の共同作業によるものでした。 つまり全体をCPUと周辺のハードウェアとして設計し、ハードウェア部分と CPUとのインターフェースの「仕様」を決定して、その枠組みの中で ソフト屋がプログラムを作っていく、というスタイルでした。 この基本として、「ハードウェアは変更が大変だが、ソフトなら簡単」 とか、その前提として「ハードウェアの材料は決まっている」という 思い込みに近い考え方がありました。 しかし、このような発想では一定の規模以上、あるいは一定の複雑さの機能 を越えるシステムでは、機能仕様の追求やバグが出た場合の対応の面で、 越えられない限界があります。 つまり、ハードウェアの設計者が「私はソフトは知りません」では済まない 時代になってきたというわけです。 ひとつの理想的なやりかたとして、ハードウェア設計者がCPUのソフトウェア まで開発してしまう、という形態があります。 このメリットは、分業するために情報のインターフェースをとる必要がない だけでなく、{\bf 設計そのものが変わってくる}ところにあります。 CPUソフトのことをわかっている技術者と、あまりわかっていない技術者の 設計するマイコン・システムの回路図はハッキリ違います。 とくに、ハードかソフトか原因が不明のバグやトラブルに直面した時に、 ハードウェアだけにしがみつくエンジニアはほとんど無力となってしまいます。 ところがこの逆に、CPUのソフトウェア開発の技術者にも、発想の転換が 必要になります。 「与えられたハードウェアに対して与えられた仕様を満足するソフトを作る」 ことなど、解答のある問題を解くようなもので、慣れれば子供でもできること です。 ここから上を目指すエンジニアであれば、ハードウェアというものを {\bf 自分のソフトが活躍する舞台として最適に設計する}、という領域 に進出していかなければなりません。 ハードウェアの設計は、ソフトウェア技術者がやってもいいのですし、 むしろ「ソフトウェア屋だからこそできるハード設計」もあるのです。 この分野では、従来は「ハードは部品としてメーカから与えられるもの」 という絶対的な条件があって、一種の壁となってきました。 つまり、ソフト屋が「ここはこういうハードがあったら、こんなに美しく 効率のいいシステムとなるのに」と内心思っていても、そういう適切な ハードウェア(ICやLSI)がないために、現実にならないことが多かったのです。 そして、ちょっとした標準ロジックICレベルのハードのミス(論理が反転 していたとか、データのビット対応のミス等)はすべて、ソフトウェアの方で カバーしてきました。 しかし、ここにロジック・デバイスが登場したことで、状況は大きく好転 することになりました。 システムとして適切な、必要なハードウェアを「プログラム」することが できるようになったのです。 ハードウェアの壁である「チップが存在しない」という言い訳は、 「そういうチップを作ればよい」という解決法により打破されました。 こうなれば、ある程度ディジタルを理解してしまったソフト屋の方が、 ハード屋よりもむしろ発想が柔軟で、システム設計にはプラスになってきます。 これは、従来から筆者の持論である、{\bf これからはハード屋もソフト屋 もない}という状況に近づいたものです。 これからのコンピュータ・エレクトロニクス技術の時代をリードしていく のは、{\bf ハードもソフトも活用できる、オールマイティのマイコン屋} だけなのです。 もちろん、これまでに積み上げられてきたハードウェアとソフトウェアの 技術の蓄積には、膨大なものがあります。 これをひとりのエンジニアが全部マスタしていこうとしても、とうてい 扱いきれません。 ところが、ここに{\bf コンピュータの支援環境}という援軍がいるのです。 ロジック・デバイスの開発ツールだけをみても、デバイス・メーカが 提供しているベーシックな記述言語は、あまり分かりやすいものでは ありません。 しかし各ソフトハウスから提供されているツールを使えば、いろいろな 理解しやすい方法でプログラミングできます。 これと同様に、コンピュータの開発支援システム（広義のCASE:Computer Aided System Engineering）のサポートによって、エンジニアの アイデアがそのままシステム化されるような時代に向かっていると 思います。 ハードウェアもソフトウェアもなく、マイコン・システムを全て設計・開発して いくエンジニアこそが、これからの時代をリードしていくのです。 \subsubsection{標準ロジックIC vs ロジック・デバイス vs ASIC vs フルカスタムLSI} それではここで、マイコン・システムのハードウェア部分を実現する ための道具または材料として、 \begin{enumerate} \item 標準ロジックIC \item ロジック・デバイス \item ASIC \item フルカスタムLSI \end{enumerate} について比較・検討しておきましょう。 ASICやフルカスタムLSIとなると、小規模なシステムハウスなどには 縁のないものと思われるかもしれませんが、その発想は間違いです。 ロジック・デバイスのすぐ先、もう手の届くところにASICがきていますし、 すでに十分にこなれてきたASIC技術の世界は、21世紀に向けた エンジニアリングの焦点として、{\bf 一人で1個でも作れるカスタムLSI}、 そして究極には{\bf カスタムメイドのCPU}をターゲットにしています。 開発環境とシリコンファウンドリの状況、そして全てを支えるコンピュータ ソフトウェアの技術は、これが夢物語でなく実際のものになっていくことを 示していますから、この状況を理解することは重要なのです。 \paragraph{ゲート規模} \paragraph{} 標準ロジックICによるディジタル回路では、回路規模としてTTLやCMOSの 個数によって表現します。 これは基板にDIPパッケージが並んだ場合に、まずおおよその基板サイズ が見込めるからです。 実際には標準ロジックICの1パッケージに搭載されている回路規模には かなりの幅があるのですが、小さなシステムで標準ロジックICで十数個 程度までの規模であれば、そのまま標準ロジックICで組んでしまう場合が 多いでしょう。 標準ロジックICで数十個から100個以上のシステムになったら、ちょっと ハンダ付けや再現性の手間を考えると、なにかしたくなってきます。 ロジック・デバイスをうまく活用して、この規模のシステムを合計で 数分の1のチップ数にしてしまう、という対象となる規模です。 また、CPUを使ったマイコン・システムで、CPUとメモリ以外の周辺ロジック を全てロジック・デバイスに格納することで、たとえば「カードサイズの マイコンボード」を実現する、などという活用方法もあります。 これは、機器に組み込むシステムで見かける応用事例です。 ロジック・デバイスのチップ能力としては、「ゲート換算」という数え方 あります。 これはASICやカスタムLSIと同様に、チップ上の論理回路の単位として NANDゲートでいくつ分、などと計算するものです。 ロジック・デバイスで注意しなければいけないのは、ASICのゲート効率に 比べてかなり成績が悪いことで、たとえば「5000ゲート搭載」という ロジック・デバイスに、実際は1000ゲート分の回路も入らない、という場合も よくあります。 これは内部レイアウト・内部配線をしないでプログラムするロジック・デバイス の宿命ですから、プログラム段階で十分に検討しましょう。 ゲート換算で1000ゲートを越えれば、ここから数万ゲート規模あたりまでは、 一般にはASICの世界となります。 それ以上なら、さに高集積度を狙って、カスタムLSI化を検討します。 ただし、少量多品種の装置、あるいは高付加価値の装置、コンパクト化 が至上命令の対象(たとえば人工衛星搭載機器)の場合には、ASICクラス の規模の回路をロジック・デバイスによって作ります。 これは、ASICのブレッド・ボード(試作評価用の等価回路ボード)を ロジック・デバイスによって作る場合も含まれます。 ここでは、回路ブロックのかなり大きな部分をそれぞれ大規模ロジック・ デバイスに分割して、たとえばチップ10数個のボードで、全体として 1-2万ゲートのASIC相当の回路を作ったりします。 ボード単価は高いのですが、非量産システムでは採用される方法です。 \paragraph{開発コスト} \paragraph{} ここでの開発コストという視点は、標準ロジックICだけで回路設計をした 場合をゼロとして、そこにどのような「余分な開発投資が必要か」と いうものです。 標準ロジックICの場合には、技術者がデータブックを捜してハンダ付けを するだけなので、ここでは基準のゼロとします。 他の方法ではそれぞれ、これよりも開発コストが余分にかかりますが、 それに代わる大きなメリットもあり、ここもトレードオフになるわけです。 ロジック・デバイスでは、パソコン上のソフトウェアなどとして、まず 「開発ツール」が必要です。 これはロジック・デバイスに必要な機能をプログラムするためのソフトで、 同時に機能シミュレーションや検証に使います。 さらに、ロジック・デバイスにこのプログラムを書き込むための「ライタ」 と呼ばれる装置も必要になります。 これはEPROMにプログラム／データを書き込む「ROMライタ」と同様のもの で、対象デバイスが広い一般的なものほど高価です。 また、紫外線消去して再プログラムできるロジック・デバイスでは、 イレーサ(消去器)が必要です。 これらを総合すると、ロジック・デバイスでは数十万円規模の開発コストが 必要ですが、これはいちど導入すれば、あとはずっと回転します。 ただし、ロジック・デバイスは日進月歩で変わっていくので、装置の陳腐化 を考慮しておかなければなりません。 これがASICになると、開発コストはさらに桁が上がります。 回路設計／シミュレーションのツールがパソコンよりもEWSベースとなり、 数百万円する開発支援ソフトウェアを自前で導入するよりも、LSIメーカや デザインハウスのデザインルームで設計することが多くなります。 ASICのチップごとに必要な試作開発費もかなりのオーダになります。 ただし、最近の設計ツールとロジック・デバイスのメーカの技術状況としては、 最初に大規模ロジック・デバイスで設計した回路を、そのままASIC化する ために「変換」するだけで、ファウンドリに渡すASICマスクデータまで作れる、 という統合化された環境に近づきつつあります。 こうなると、「ASICは膨大な開発費がかかる」というこれまでの常識とは やや変わってきて、もっと手軽にASICを作れるようになるものと期待されます。 \paragraph{量産コスト} \paragraph{} ここでの量産コストとは、その部品をシステムに使った場合の「部品代」の ことで、標準ロジックICを基準とします。 なお、{\bf 量産コストはロット数量と重要な関係にある}ことに注意しましょう。 汎用標準ロジックICのコストは、半導体の量産効果によって非常に安く なっていますから、チップ単体としてはこれがもっとも有利のように 思えます。 ところがディジタル・システムの製造コストとしては、 \begin{itemize} \item 部品が多い→基板もケースも大きい、重い \item 部品が多い→消費電力が大きい→電源も大きいものが必要 \item 部品が多い→トラブル・故障の可能性が増える \end{itemize} という部分にも効いてきますから、回路規模がある程度大きくなると、 標準ロジックICだけで構成するデメリットが大きくなって、ロジック・ デバイスの登場する余地がでてくるのです。 ロジック・デバイスのチップ単体のコストは、数量の問題で、一般に 汎用の標準ロジックICよりも高価です。 回路によっては、標準ロジックICだと数チップを使わなければならない 回路をうまく小型ロジック・デバイス(PAL)の1チップに格納して、 ロジック・デバイスの方が安価になる場合もあります。 大規模なロジック・デバイスになるとかなり高価で、標準ロジックICより もASICよりも不利になるのが一般的です。 そこで、それでもロジック・デバイスを採用するための動機として、 これまでに述べたロジック・デバイス化のメリットが複合的に関係して いるような場合に利用されているようです。 また、システム内で同一種類のロジック・デバイスをなるべく使うように プログラミングすることで、数量としてまとまるコストダウンも検討 します。 これがASICになると、量産コストの効果が劇的になります。 かなりの開発コストが必要なASICですが、チップ上に大規模な回路を ロジック・デバイスのように制約もなく自由に設計できるために、 その集積度の効果は驚くべきものがあります。 たとえば一般に、最適なレンジ(数千ゲート程度)のゲートアレイでは ゲート単価は十数銭と言われています。 標準ロジックICの00や08(4ゲート入り)が、1円もしない計算です。 さらに集積度の高いスタンダードセルでは、最適なレンジ（1---2万 ゲート程度）でのゲート単価が数銭とも言われています。 これらの最適レンジは、ミクロン・ルールやパッケージのファミリ、 そして工場・ラインの新設など、メーカの技術水準・稼働状況とともに刻々と 変動します。 このようなASICの例として単純計算すると、たとえば \begin{itemize} \item カスタム設計のCPU周辺LSI \item 多ビットの入出力ポートを持つ \item 100ピンプラスチックフラットパッケージ \item ゲート規模は10000ゲート(無駄のない実効ゲート数) \end{itemize} といったLSIを、チップ単価として数百円程度で作れることになります。 ただし、この場合のロット数量としては、メーカとの契約によってかなりの 保証を要求されることになります。 現在のASICのロット数量は、一般に生涯個数で数万個以上とされている ようです。 しかしこれは契約事項ですから、もっと少ないロットのASICも実際に 作られています。 開発環境の標準化と自動設計の導入の進んだメーカでは、「小回りの きくASICビジネス」を狙うところも多いからです。 全体的な傾向としては、このロット数量がかなり小さくなってきている ので、いずれ将来は数十個、あるいは数個単位まで可能(この場合には もうちょっと単価は高い)、とするメーカも出てくることでしょう。 \paragraph{コンパクト化} \paragraph{} 最後の視点として、ディジタル・システムのコンパクト化というメリット を考えましょう。 これは明らかに、標準ロジックICよりもロジック・デバイス、さらに ASICやカスタムLSIと進むにつれて、画期的に集積度が上がって、 システムのコンパクト化が達成されることになります。 システムを小さくできれば、「軽薄短小」のメリット、電源の省エネ といったメリットがあるのはもちろんですが、さらに{\bf 高速化に対応} したポイントであるのも重要です。 現在のASICでは、「ゲート遅延」がナノ秒オーダから1ナノ秒を切るところ にまで進化しています。 このため、従来はASICの動作確認のために作られたブレッド・ボードが、 標準ロジックICではスピードが同等の水準にならず(標準ロジックICの ゲート遅延は数ナノ秒以上)、検証のためにはクロックを下げて エミュレーションする、などという状況になっています。 また、標準ロジックICで数100個のブレッド・ボードでは、プリント基板の 配線長による影響で、正しく動作しない場合も多くなりました。 そこで、高速タイプのロジック・デバイスでブレッド・ボードを作り、 配線長を抑える場合も出てきています。 このような苦労は全て、ASICのコンパクト化というメリットの裏返し でもあり、それだけ重要なポイントになってきています。 パソコンの高速化は、システム・クロックが66MHzとか100MHzとかの時代に なってきましたが、こうなると標準ロジックICの時代とは違ってきます。 少量でも作れるASICを回路の「部品」としてふんだんに活用して、はじめて 到達できるスピードの世界なのです。 \subsubsection{開発支援環境とエンジニア} ASIC開発のためのツール(設計ツール、シミュレーションツール等)は、 ロジック・デバイスのためのツールの上級編とも言えます。 このツール内で「設計を完了」し、「動作を確認」してしまえば、 もうファウンドリからは確実にその動作をするASICが得られる、という 時代になってきました。 半導体メーカは、これまではディジタル技術者に「汎用チップを製造して 提供してやる」という、イニシャチブをもった立場でした。 まずデバイスがメーカから提供されなければ、何もできなかったのです。 ところがロジック・デバイスやASICの技術は、ある意味でこの立場を 逆転させています。 エンジニアは、自分の作りたい回路に合わせて半導体チップを自由に プログラムできるのですから、それをLSIメーカに「製造させる」 という立場にもなってしまう、という現象です。 事実、LSIデザイン・ハウスでは、半導体メーカ(ファウンドリ)を自由に 選べるような設計環境を駆使しており、LSI設計ツールの世界でも、 ファウンドリ自体の世界でも、この標準化は着々と進行しています。 かつてのCAD、CASE(コンピュータ支援ソフトウェア開発)という言葉に 続いて、最近では「統合化CASE(コンピュータ支援システム開発)」とか 「コンカレント・エンジニアリング」などの言葉で宣伝されているのも、 十数年来変わっていない、この「理想的エンジニアリング」への アプローチなのです。 これは要するに、システム構築を支援する統合環境であり、理想とする システム開発の姿は本質的にはあまり変わっていません。 エンジニアリングを支える{\bf 支援環境}として、設計CADや論理 シミュレータ、さらにレイアウト自動生成ツールなどのソフトウェア が揃ってきました。 これとともに、ロジック・デバイスやASICという、ハードウェア自体 もオリジナル設計できるレベルになってきました。 もちろんCPUのソフト開発に関しても、クロスコンパイラやシミュレート デバッガ、そして高機能ICEが強力に支援します。 さらにプリント基板の多層化、チップ部品の普及、基板パターン の自動設計CADと自動製造システム(CIM)との連結も進んでいます。 これらの状況は全て{\bf システム開発の全体を支援する環境}と なって、ここで生き生きと創造性を発揮できるエンジニアに必要なのは、 ハードもソフトも区別なく理解して、支援環境を駆使してシステムを 生み出していく「柔軟性」でしょう。 従来の技術者が苦労して「暗記」したことや、伝承されてきた「ノウハウ」 の多くは、支援環境から適宜示されたり、必要に応じて自在に引き出せる ものとなります。 これからのエンジニアには、ディジタル・システムやマイコン・システム についての理解、あるいは設計の{\bf センス}こそが重要になるのです。 このような視点からすると、ロジック・デバイスというのは、これまで 「ハードウェア屋」、あるいは「ソフトウェア屋」として限定された 領域にしばられていたエンジニアにとって、発想を転換して自分の 可能性に挑戦するための、格好の{\bf 教材}とも位置づけられます。 そしてロジック・デバイスを活用してみて、エンジニアとしての自分を 向上させることが、いま直面しているシステム開発においても、うまく 活用すればメリットとなる可能性の高い、まさにチャンスにもなります。 「従来通り標準ロジックICでも作れるけれど、ここはロジック・デバイスを 使ってみよう」という前向きな姿勢で取り組んだとき、そのエンジニアの スキルアップの扉が開かれていくのだと思います。 \paragraph{} \section*{\gt コラム 新しい環境をマスタするコツとは} コンピュータ・エレクトロニクス技術の世界とは、各種のツールと各種の開発環境と 各種のコンピュータ用語が乱立した、フレッシュマンが困惑してしまう世界です。 ただでさえ、これまで構築されてきたいろいろな技術項目を理解し駆使して いかなければならないのに、さらに「ロジック・デバイス」という新しい概念 と環境まで覚えなければならない、というのは相当なプレッシャとなります。 そこで、いかにこのような「新しい環境をマスタするか」というコツについて 考察してみましょう。 筆者はかつて、日進月歩のこの世界にハマッていくための自衛策として、 \begin{enumerate} \item 特定の言語を覚えない \item 特定のシステムに慣れない \item 情報は必要なときにマニュアルから得る \end{enumerate} という姿勢を提唱しました（インターフェース150号特集の248ページ）。 これは「情報過多に飲み込まれない自衛策」でしたが、実はここで考えている 「新しい環境をマスタするコツ」と本質的に同じものなのです。 ちょっと逆説的に思うかもしれませんが、騙されたと思って実行してみて ください。 新しい分野のエンジニアにとって、もっとも危険なのは「特定のことがらの エキスパートになる」ことです。 たとえば、あるパソコン、あるＣＰＵ、あるソフトウェア言語、あるデバイス を完璧にマスタしたとして、ずっとそこに安住していけるでしょうか。 伝統的な工芸美術の世界ならともかく、技術革新はあらゆるレベルで 進行していきますから、頼りにしていたその対象自体が、「過去のもの」として 消え去っていく確率のほうがずっと高いのです。 （過去のものとなったメジャーなパソコンやＣＰＵを、いくつでも思い出せる でしょう） そこで、限りある自分の記憶領域を「暗記」によって埋めていくのでなく、 常に活性状態のダイナミックＲＡＭとして活用する、というのがポイントに なります。 幸いに、人間の脳には「短期記憶」と「長期記憶」という分業体制があり、 しばしば短期記憶の領域でアクセスされた情報が、「学習」効果によって 長期記憶の領域に（そのままの情報でなく適度に情報圧縮されて）格納 されていくようです。 つまり、マニュアルや教科書に書かれたものを「暗記」することよりも、 「情報のアクセス方法」を自分なりに整理して体得する、という姿勢が もっとも重要なのです。 新しいことがらに直面したら、まずは「覚えよう」と思わずに、とりあえず サンプルプログラムを走らせるとか、もっとも簡単な回路を作成するなど、 「習うより慣れろ」に徹します。 ここで重要なのは、ゲーム感覚で遊んでしまうような、「柔らかい頭」です。 そして、細かいことはわからなくても、とりあえず「やってみた」状態に なれば、しめたものです。 次のステップでは、できれば少し時間をあけて（忘れて）から、もう一度 新たな気持ちで取りかかります。 人間の頭脳とは素晴らしいもので、自分ではまったく忘れ去っていたつもり でも、どこかでこの新概念が吟味・整理されているもので、再度アプローチ してみると、初めての時とは印象が変わります。 自分の技術フィールドに関連して、新しい視点でながめることもできます。 ここでもマニュアルを最初から調べるのですが、今度は「思い出す」のも 早く、カンどころもつかめてきます。 ただし、その新システムを「暗記」することは避けましょう。 ちょっと触れないと忘れてしまう、という状態でいいのです。 このようなアプローチであれば、自分の記憶領域がつねに余裕のある状態で キープできます。 必要な情報は、必要な場面になってからマニュアルから調べればいいし、 「どのマニュアルにあって、どう検索すると見つかる」という 効率的なアクセス方法が次第に身についてきますから、時間は かからなくなります。 そして、この「情報アクセスの視点」こそ、コンピュータ・エレクトロニクス 時代のエンジニアにもっとも必要とされるセンスなのです。 急がば回れ、まず新しい環境に接した時には、そこで遊んでみましょう！ \newpage \paragraph{} \section*{\gt コラム ツールの選択と言語の選択} ロジック・プログラム・デバイスやＡＳＩＣの世界では、設計・開発・ シミュレーション・プログラム（デバイス書き込み）の作業を行う 「開発ツール」と、具体的にハードウェアの設計を記述するための 「プログラム言語」という２つの重要な要素があります。 普通のソフトウェアの走るパソコンやＥＰＲＯＭのプログラマなどであれば、 あまり値のはる装置でもないので自前で揃えますが、大規模なＰＬＤや ＡＳＩＣの開発ツールとなると、極端にはウン百万円のＥＷＳと ウン百万円のシミュレータソフトウェアということになり、なかなか 自前で購入するような自由な選択ができなくなります。 理想的な環境でないからうまくいかない、うまくいかないからいい チップが開発できない、という悪循環の可能性もでてきます。 しかし筆者の経験からいえば、「理想的な環境などない」という視点も 重要だと思います。 これは開発ツール（ハード、ソフト）のメーカから異論の出そうな意見 ですが、確かに理想は永遠に理想である、というのも真実のようです。 少なくともあらゆる開発ツールのメーカが「最新・最高のもの」を 発表しても、それから少したてば別のメーカが、そして当のメーカ 自身も「より最良のもの」を開発してくるのは事実ですから、 「理想的」などというのは、その時点のはかない形容詞でしかないのです。 エンジニアの姿勢としては、とりあえず直面したデバイスメーカや ツールメーカの環境を、「そういうもの」として受け入れてみましょう。 回路設計ＣＡＤの使い勝手が悪ければ、ユーザーインターフェースの 反面教師として、文句・コメントをメモしながら使いましょう。 シミュレーションの表現形式がわかりにくければ、上等なパズルだと 思って解読しましょう。 いずれ必ず、これらの「苦行」は自分の技術力として戻ってきます。 ...しかしこれでは「ツールの選択と言語の選択」になりませんから、 別の視点で「選択」についてのポイントを考えましょう。 筆者の主張したい意見としては、 \begin{enumerate} \item ツールはなるべく買わない \item 言語はいろいろ浮気してみる \end{enumerate} の二つがあります。 ロジック・デバイスにしてもＡＳＩＣにしても、開発ツールはハードも ソフトも高価なものです。 そしてこれらのデバイスを選択する究極の目的は「コストとスペック」 にあります。 つまり、多額の開発費を投資しても見合うだけの量産コスト効果や、 十分な機能仕様を実現できることでメリットがある、という理由です。 一方、デバイス・メーカの側にしてみれば、設計・試作・生産のライン に投下された膨大なコストを回収するためにも、汎用デバイスでなく 自社のＰＬＤ・ＡＳＩＣを「わざわざ採用」して欲しいのですから、 開発ツールの部分でまで儲けることは主目的ではありません。 そこで、デザイン・ルームを開発ツール付きで貸し出すサービスや、小規模 なものであれば、パソコンベースの開発ツールをソフトごと貸し出しています （現在の上級パソコンのマシンパワーは、かつてのミニコンに匹敵しています）。 また、メーカの代理店や商社も、デザインサポート部隊だけでなく、ツール の貸し出しやインプット代行などをしています。 これらのセミカスタム・デバイスのビジネスでは、デバイスの開発費と量産 価格のマージン、そして「工場のラインが埋まる」という隠れた利益で 回っているのですから、ユーザであるシステム開発エンジニアが、ここに 余分な投資をする義理はないのです。 サービスをサービスとして享受しましょう。 数量的な条件などでタダではツールが借りられなければ、購入でなく レンタルやリースにするのも定石です。 この分野はパソコンなどよりも陳腐化が激しく、さらに旧世代にものは 古いパソコン以上に「使えない」ものとなります。 利息や原価償却などを計算する以前に、「自前でツールを購入」という 選択はありえない、厳しい世界でもあるのです。 そして、デバイスをプログラムする言語や表現形式については、新しく 取り組むテーマごとに、できれば「敢えて変えてみる」という姿勢が おすすめです。 これは「頭の体操」「視点を柔軟に」「視野を広く」といった意味も重要 ですが、「ツール／ソフトメーカを絞らない」という戦略でもあるのです。 筆者の体験ですが、あるＡＳＩＣを開発中に、昨日までＯＫだった シミュレーションが今日になってエラーになる、という事態に直面した ことがありました。 実はこれは、メーカのＡＳＩＣデザインセンタのツール保守担当者のミスで、 「ＬＳＩシミュレータ」という巨大なソフトのバージョンアップでバグを 発生させて、シミュレーションモデルに矛盾が発生したためでした。 国内の大手ＬＳＩメーカといっても、ＡＳＩＣの設計ソフトウェアのかなり の部分をアメリカ製の環境に頼っていて、バグの発生のたびにエンジニアが 来日する、という笑えない実話もあります。 ＬＳＩ開発環境をウン億円でソースごと購入して、自社向きにアレンジ しているメーカでも、このようなバージョンアップ時の不整合バグは よく発生します。 このような恐ろしい状況からエンジニアが身を守る一つの方法は、 「いくつかの手法でアプローチできる」という姿勢なのです。 ＰＬＤやＡＳＩＣのプログラムでも、ウェーブ形式、ベクター形式、 論理式形式などのいろいろな方法を機会をみて体得しておくことで、 「なにかヘンだ」という状況の時に別の視点でチェックできる 柔軟性が生まれます。 万一あるメーカのツールがトラブったときにも、別の環境にスッと 移ることができます。 このような意味で、いくつかの言語・表現・手続きを、いろいろと 積極的に「浮気」「つまみ食い」してみていきたいものです。 \end{document}