JP2812959B2 - マルチチャンネルデータ通信制御器 - Google Patents

Description

【発明の詳細な説明】 技術分野 本発明は、大略、マルチチャンネルデータ通信制御器
に関するものであって、更に詳細には、ホストの処理能
力に対する依存性を最小として広範囲のプロトコル及び
その他のホストシステムの要件を取り扱う為にカスタム
化することの可能な柔軟性があり汎用性がありエンジン
を基礎としたアーキテクチャーを持った通信制御器に関
するものである。

従来技術 ２つのコンピュータ間又は１つのコンピュータシステ
ムの処理の構成部品間のコミュニケーション即ち通信
（同期及び非同期）は、屡々、一度に１ビットづつ直列
的に行なわれている。然し乍ら、マイクロプロセサ、マ
イクロコントローラ、及びその他の計算装置は、実際の
データキャラクタとして、データビットを並列（屡々、
一度に８ビット）で取り扱う。従って、データが電話回
線で送られるか（その場合にはモデムを使用することが
必要である）又は直接的に周辺装置（例えば、シリアル
プリンタ）へ送られるかに拘らず、「ホスト」プロセサ
（パラレルデータ）と例えばモデム又はシリアルプリン
タ（シリアルデータ）等のホストが通信する装置との間
には通信インターフェースが必要とされる。

このインターフェース装置は、ホストから出力される
パラレルデータをシリアルデータビットに変換すること
が必要であり、入力するシリアルデータビットをホスト
用のデータキャラクタに変換することが必要である。更
に、それは、エラーチェック及びその他の種々のプロト
コルに関連する要求を実行する場合があり且つホストシ
ステムとのインターフェース及びホストが通信するシリ
アル装置を取り扱う場合がある。

この様なインターフェース装置は、通常、データコミ
ュニケーションコントローラ即ちデータ通信制御器又は
シリアルコントローラと呼ばれる。何故ならば、該制御
器は、ホストのシリアルポート（モデム、シリアルプリ
ンタ、又はその他のシリアル装置に接続されている）の
１つを介してデータの伝送及び受信を制御するからであ
る。ホストプロセサの各シリアルポート、即ち通信「チ
ャンネルはこの様な装置によって制御されねばならな
い。

各チャンネルに対して別の制御器が使用される場合に
巻き込むハードウエアのオーバーヘッド即ち費用の幾ら
かを回避する為に、マルチチャンネル装置が開発され
た。該装置は、大略、各付加的なチャンネルに対してハ
ードウエアを二重にすることにより、マルチプル即ち複
数個の通信チャンネルを同時的に処理する。

データは、屡々、マルチチャンネルを介して同時的に
送られるので、最近のマルチチャンネル制御器は、マル
チチャンネルを横断してのデータの伝送及び受信の両方
に対して、ハードウエアデータ待ち行列（「先入れ先出
し」待ち行列、乃至は「FIFO」）を有する様になった。
これらのFIFOは、ホストプロセサがこの様なデータをア
クセスする為の時間を持つ迄、一時的に各チャンネルに
関連するデータを格納する。

マルチチャンネル制御器は、又、種々のレジスト（各
チャンネルに対して、ボー速度及びキャラクタ寸法等の
通信パラメータを格納する為）、タイマー／カウンター
（データの伝送及び受信の同期を取る為）、及びデータ
ビットの送受信及びデータキャラクタの組み立て／分解
の主要なタスクを実行する為の略ランダムなロジックを
有している。

例えばナショナルセミコンダクタNS16550ACE（FIFOを
具備する非同期通信要素）等の現在のUART、又シグネテ
ィックスのSCC2698OctalUART（８チャンネルユニバーサ
ル非同期レシーバ／トランスミッタ）等のマルチチャン
ネルUARTでさえも、パラメータの設定（例えば、ボー速
度及びデータキャラクタ寸法）を超える柔軟性は殆どな
いホストシステムを提供している。

ユーザがカスタム化したプロトコル又は異なったプロ
トコルの集りを実行することを所望する場合、現在の制
御器は、この様なタスクを非能率的に実行する（何故な
らば、ホストの処理能力に広範に依存−例えば、「Xon/
Xoff」データフロー制御の実行−及び「特別の」キャラ
クタを認識する能力に欠け、又FIFO及びタイマー／カウ
ンタの数及び寸法を修正する能力でさえも欠如してい
る）か、又はこの様なタスクを実行することは全く不可
能である。

この分野において興味のあるものは、インテル8273、
8273−４、8273−８プログラマブルHDLC/SDLCプロトコ
ル制御器であり、それは、技術的にはマイクロプログラ
ムによってプログラムされるものではあるが、HDLC及び
SDLC同期プロトコルに専用のアーキテクチャーの周辺に
構築されるものである。例えば、UART適用において同一
のアーキテクチャーを使用することは、不可能である
か、又は極めて非能率的な装置となる。

更に、現在のシステム設計技術は、カスタムプロトコ
ルに対してはカスタム制御器アーキテクチャーを必要と
する。この様なカスタム制御器適用によりマルチプルチ
ャンネルをサポートすることが可能ではあるが、このこ
とは、各付加的なチャンネルに対しての単一チャンネル
アーキテクチャーを実際上二重とすることによって達成
される。

この様に柔軟性を欠如する結果、種々の通信要求を持
ったユーザは、チップの大きさが大き過ぎることとなる
か（過剰に不必要な特徴を具備するので）又はチップの
大きさが小さすぎる（ユーザの要求を満足させることが
不可能）こととなる。

目 的 本発明は、以上の点に鑑みなされたものであって、上
述した如き従来技術の欠点を解消し、ホストシステムに
対する依存性を最小とし広範囲のプロトコル及びその他
のホストシステムの要求を取り扱うべくカスタム化させ
ることが可能であり、柔軟性に富み、汎用性があり、且
つエンジンをベースとしたアーキテクチャーを持ったマ
ルチチャンネルデータ通信制御器を提供することであ
る。

構 成 従って、ホストシステムに対して及びホストが通信す
る複数個のシリアル装置に対しての柔軟性のあるデータ
通信アーキテクチャーが必要とされており、即ち、エン
ジンを基礎とし、マイクロプログラムアーキテクチャー
で、制御器の外部インターフェースを取り扱う為の専用
プロセサを有するものが必要とされている。本発明は、
常に存在するタスクのシリアルデータを送信し且つ受信
すること、及びホストへ又はホストからキャラクタを送
ったり受信したりすることを、専用プロセサを使用して
迅速に且つ能率的に行なうことを可能としている。この
ことは、汎用のメインエンジンをこれらの時間的に重要
なタスクの負担を軽減し、それがキャラクタの組み立て
及び分解及びデータのFIFO内の維持及びエラーチェック
及びその他のプロトコル関連タスク等の比較的複雑な
（時間的には重要性は少ないが）タスクを実行すること
を可能としている。

本発明は、例えば、良く使用されている４又は５ボー
（baud）速度に制限されるべきものではなく、妥当な範
囲内において（付加的な外部クロック源の必要性無し
に）事実上任意の特定したボー速度を実施することを可
能としている。更に、チップの基本的なアーキテクチャ
ーに対して修正を施すこと無しに、単にマシンをマイク
ロコード化することによって、カスタムプロトコロルを
実施することが可能であり、設計時間をかなり減少させ
ている。ユーザインターフェース全体をカスタム化させ
ることが可能である。ユーザは、特定のチャンネルに対
して、タイマー／カウンタの数のみならず、FIFO（RAM
に実現されている）の寸法を修正することが可能であ
る。この様な「制御」特徴は、専用のランダムロジック
で固定される代わりに、ファームウエアで実現され且つ
汎用エンジンによって実施されるので、ユーザをインタ
ラプトする方法及び優先順位付けさえも修正することが
可能である。

この汎用アーキテクチャーの柔軟性は、制御器を特定
のユーザの要求に対して一層カスタム化させることを可
能とし、制御器自身による性能が高速であるばかりか、
ホスト処理能力に対する依存性を一層軽減させることを
可能としている。従来ホストによりソフトウエアでのみ
可能であったことが、一層迅速に制御器自身によって実
行することが可能である。最後に、この汎用アーキテク
チャーは、設計時間を短縮化し、且つ向上した機能を具
備するより小型のチップとすることを可能としている。

本発明は、３つの階層のプロトコルからなるヒエラル
キーから構成され、汎用のマルチチャンネルデータ通信
アーキテクチャーを提供することによって上述した如き
従来技術の欠点を解消している。

第１階層のプロセサ、即ち「ビットエンジン」（又
は、幾つかの実施例においては、「キャラクタエンジ
ン」又は所要のデータ単位により定義されるエンジン）
が、最も頻繁に発生するタスク、即ち本制御器が直接的
に通信する複数個のシリアル装置への又はそれからのシ
リアルデータの送信及び受信、を取り扱う。後述する現
在の実施例においては、２個のビットエンジンを使用し
ており、即ちその１つは各ビットを各外部シリアル装置
（「出力ビットエンジン」即ち「OBE」）へ伝送するも
のであり、且つ他の１つは各この様な装置から各ビット
を受け取る為のもの（「入力ビットエンジン」即ち「IB
E」）である。

複数個のシリアル装置は、制御器の関心（ビットの送
信及び受信の両方に対して）を得るべく同時的に競争す
るので、これらのビットエンジンはサービス用の全ての
要求を取り扱わねばならない。IBEは各入力ビットをサ
ンプルし且つ認識せねばならず、一方OBEは各出力ビッ
トの伝送を同期させる。両方のビットエンジンは、常に
サービスの為に「メインエンジン」をインタラプト即ち
中断させ、各入力ビットを伝送し、又は次の出力ビット
を要求し、又そのビットエンジンの次の「状態」に対応
する適宜のタイマー／カウンタに修正させねばならな
い。

後に詳説する如くこれらのビットエンジンによって実
行される精密な機能に拘らず、ビットエンジンは、次の
ビットを伝送するか又は受信せねばならない期間である
次のビット期間をミスしない様に、極めて迅速に（「ビ
ット時間」において）これらの機能を実行せねばならな
い。従って、最も高い優先度はこれらのビットエンジン
に与えられる。

該ビットエンジンからインタラプトを受け取ると、メ
インエンジンは、キャラクタの組み立て及び分解の「フ
ォアグランド（前景）」タスクも迅速に実行せねばなら
ない。換言すると、特定のチャンネルから出力すべきホ
ストからのデータキャラクタが与えられると、メインエ
ンジンはそのキャラクタを個々のビットに分解し、その
際に次のビット転送の準備が出来ている場合にOBEがこ
の様なビットをアクセスするのに間に合う様に分解が行
われねばならない。同様に、メインエンジンは、IBEに
よって受け取られた各ビットを、完成された場合にホス
トへ転送されるべく形成されるキャラクタに組み立てね
ばならない。

本システムに入力され且つ出力される不断のビットの
流れに対しての次の優先度は、「バスインターフェース
ロジック」（即ちBIL）であり、それはホストプロセサ
に対する「ユーザインターフェース」を司る。データキ
ャラクタは、秩序正しい態様で、ホストへ送られ且つホ
ストから受け取られねばならない。周期的にメインエン
ジンがその残存する「バックグラウンド（背景）」タス
クを実行することを可能とする一方、BILがバスを支配
してこれらのタスクを実行することを可能とする為にデ
ータ及びアドレスバス上でアービトレーション即ち仲裁
が行われねばならない。

従って、最低の優先度は、メインエンジンによって実
行されるこれらのバックグラウンドタスクの為にリザー
ブされている。これらのタスクは、FIFO内のデータの管
理、データキャラクタを送信又は受信する為にホストプ
ロセサをインタラプトすることの必要性のスキャニン
グ、及び種々のタイミング遅れ、流れ制御及びブレーク
検知機能の実行等を包含している。要約すると、メイン
エンジンは、バックグラウンドにおいて、カスタム化プ
ロトコルに関連する複雑でキャラクタ指向の（従って時
間的な重要性は比較的低い）タスク及びホストシステム
のその他の特別の要求を実行する。

従って、この３階層プロセサヒエラルキーは、時間的
に重要なタスクをビットエンジンとメインエンジン（フ
ォアグラウンドタスク）によって迅速に且つ能率的に実
施することを可能とし、且つユーザインターフェースBI
Lによって処理し、一方汎用メインエンジンを比較的自
由な状態とさせてユーザがファームウエアを介して制御
器内に組み込むことが可能な巨大なアレイの複雑な（バ
ックグラウンド）タスクを実行することを可能としてい
る。その結果、効率的で且つ一見カスタム化されたチッ
プが得られ、それは迅速に設計することが可能であり、
且つマルチチャンネルデータ通信に関連する時間のかか
るタスクを実行する為の責任をホストプロセサから取り
除いている。

３つの階層のプロセサの間の能率的な相互作用を得る
為に、この汎用アーキテクチャーの構成に多数の独特の
特徴が組み込まれている。これらの特徴の殆どは、ホス
トプロセサのジャブを容易としており、ホストプロセサ
をより世俗的なしかし時間のかかる多くのタスクを処理
することの責任から解除している。これらの特徴は、後
に詳細に説明するが、以下に要約的に説明する。

この様な特徴の１つは「良好データインタラプト」で
あり、それは、殆どの制御器は外部装置から受け取るシ
リアルデータをキャラクタの形に組み立てるのみなら
ず、そのデータに関して或る程度のエラーチェックを実
行する為に、作られた。従って、ホストシステムが制御
器から受け取る各キャラクタの「ステータス」をチェッ
クすることは一般的である。そのステータスが、例え
ば、キャラクタの伝送が伝送エラーとなったことを表す
場合、ホストは適宜のサービスルーチンを実行してこの
様なエラーを処理する場合がある。各キャラクタの存在
及びステータスのチェック（どのような動作を行なうべ
きかを決定する為に）は、ホストプロセスが実行する為
には非常に時間のかかるタスクである。

良好データインタラプトという特徴は、その様なタス
クに関連するオーバーヘッドの殆どをホストプロセサか
ら取り除いている。本制御器によって受け取られるデー
タの殆どは「良好データ」である（即ち、通信エラーの
結果ではなく、又ユーザによって指定される特別のキャ
ラクタの如き例外でもない）ので、可能なステータスの
各タイプをホストプロセサに通知する為にホストプロセ
サをインタラプトすることは実際上必要性がない。むし
ろ、データのタイプのステータスが１つのキャラクタか
ら次のキャラクタに変化したことを通知し且つ転送の為
に使用可能な「良好データ」のキャラクタの数をホスト
へ通知する為にホストをインタラプトすることが必要で
あるに過ぎない。

従って、例えば、22個のキャラクタを受け取ると（10
個の「良好データ」のキャラクタと、それに続いて、不
当なキャラクタ、ユーザによって指定された特別のキャ
ラクタ、次いで10個の良好キャラクタ）、ホストは４回
（22回ではない）インタラプトされることが必要とされ
るに過ぎない、即ち転送用に10個の良好データのキャラ
クタが与えられていることをホストに通知し、２回目は
不当なキャラクタを受け取ったことをホストに通知し、
且つ３度目は、ホストが「待ち望んでいた」特別のキャ
ラクタが到着したことをホストに通知する。最後の４度
目のインタラプトは、良好なキャラクタの第２のストリ
ング（列）をホストに通知することであるが、それはそ
のストリングが何等かのその他のタイプのキャラクタス
テータス（例えば、不当キャラクタ又は特別例外キャラ
クタ）によって破断された時のみ又はキャラクタのホス
トが指定したスレッシュホールドを受け取った時であ
る。

本発明の汎用アーキテクチャーにより可能とされた別
の独特のユーザインターフェースの特徴は、「自動化デ
ータ転送」であり、それは本制御器とホストプロセサと
の間のデータ転送の為に使用される実際の機構を包含し
ている。マルチプルチャンネルを包含することが可能で
あるかも知れないが、このアーキテクチャーはRAMにお
いてFIFOを実現する上で本来的な柔軟性を維持し、一方
専用ハードウエアFIFOによって達成されるものと同等の
性能を与えている。

現在の制御器は、固定アドレスを具備する専用ハード
ウエアFIFOを使用し、ホストプロセサが制御器へ又は制
御器からデータブロックを転送する為にポインターを操
作することを必要とする。例えば、ホストが16個のキャ
ラクタからなるブロックを受け取ることを所望する場
合、現在の制御器は、ホストが制御器に受領チャンネル
に関連するFIFOのアドレスを供給することが必要であ
る。

自動化データ転送機構は、メインエンジンをポインタ
ー操作のオーバーヘッドから解除する。メインエンジン
をこのタスクで過剰に負担をかける代わりに、BILは、
関連するアドレス動作機構を持ったマルチプル専用ハー
ドウエアFIFOの代わりに、１組のポインタ／カウンタハ
ードウエアでこのタスクを実行すべく設計されている。
以下に説明する好適実施例は、実際に２組のポインタ／
カウンタを使用して、引き続くインタラプトのパイプラ
イン動作を与える。

従って、ホストは、３つの独特のアドレスを「記憶」
するだけに過ぎず、即ちデータを受け取る為に１つと、
そのデータのステータスを受け取る為に１つと、データ
を転送する為に１つである。ホストは、FIFOの実際の寸
法又は位置のいずれも知る必要はない。適宜のチャンネ
ル番号及び方向でさえも本制御器によって維持される。

従って、上述した例において、16個のキャラクタのデ
ータを受け取ったことを表すインタラプトを受け取ると
（ホストはそのデータが「良好データ」であるか否かを
既に知っている）、ホストは「データFIFOの受け取り」
の為に「アドレス」を供給することのみが必要であり、
且つ自動化データ転送機構は、そのデータが格納されて
いるRAM内の実際の初期アドレスへのポインターを使用
することによりそのアドレスに応答する。更に、専用カ
ウンタは、16個の全てのキャラクタが転送される迄、キ
ャラクタのカウントを自動的にデクリメントし、一方こ
れらのキャラクタが格納されている実際のRAMアドレス
へポインターをインクリメントさせる。同一の機構が、
ホストによるデータの転送のみならずステータス情報の
転送を許容し、ホストから実際のアドレスを維持し且つ
ポインターを操作することの責任を取り除いている。

上に説明したBIL機構は、アドレス動作方法を（「文
脈指向アドレス動作」）、このアーキテクチャーの別の
独特の特徴である「状態インタラプト処理」機構と共用
している。文脈指向アドレス動作は、ホスト、BIL及び
メインエンジンに関連する特定のチャンネルに拘らず機
能を実行する為に、これらをイネーブルさせる為に実行
される。このアドレッシング機能は、特定のチャンネル
に関連する適宜の資源をアクセスすることとは別に、ホ
スト、BIL及びメインエンジンによって実行される機能
が基本的にチャンネルと独立しているので、有用であ
る。

従って、ローカル及びグローバルなアドレスが使用さ
れる。グローバルアドレスとは、IBE,OBE,BIL,メインエ
ンジン及びチャンネルに特定的ではない制御器のその他
のモジュールと関連する実際のハードウエアレジスタの
みならず、FIFO及びその他のRAMを基礎にしたデバイス
の実際の「メモリマップ」した位置のことを言う。ロー
カルアドレスは、基本的に、メモリマップを特定のチャ
ンネルに関連する等価のセグメントに区間分けする。従
って、ローカルアドレスは、チャンネルのいずれかにお
いて対応するレジスタをアクセスするために使用するこ
とが可能である。

ローカル／グローバルアドレス動作手法は、今日の多
くのコンピュータの命令の組によってサポートされてい
るが、メインエンジンのインタラプトハンドラーにおい
て使用される文脈指向アドレス動作機構は、そのマイク
ロコード化したエンジンが、専用インタラプトベクトル
動作機構と結合されて、ハードワイアードステートマシ
ンの如くに動作することを可能とさせる。「文脈RAM」
として指定されたRAMのエリアは、ファームウエアルー
チンへの一連のエントリ個所（即ちチャンネル番号及び
それらの方向（即ち、伝送か又は受領か）の各組合せに
対して１つ）を有している。

IBE又はOBEからのインタラプトを受け取ると、ビット
エンジンによって供給される既知のチャンネル番号及び
方向を使用して、メインエンジンは、直ぐに適宜のファ
ームウエアルーチンのエントリポイント（文脈RAMテー
ブルに含まれている）へベクトル動作させる。文脈指向
アドレス動作は、このベクトル化処理を、それがあたか
もハードワイアードであるかの様に迅速に発生すること
を可能とする。

更に、付加的な機構（以下に説明する「文脈リター
ン」命令コード（opcode））が、これらのベクトルがチ
ャンネル番号／方向組合せが存在する場合よりも一層ル
ーチンが存在する場合であっても、これらのベクトルが
適宜のファームウエアルーチンに対してポイントする即
ち指し示すことを可能とする。このことは、各ルーチン
の終了の前にファームウエア自身に文脈RAMエントリポ
イントを修正させ、次の適宜の（その同一のチャンネル
及び方向に対する次のビットエンジンインタラプトの後
に何時か後の時間に実行されるべき）ルーチンの既知の
エントリポイント内にローディングさせることによって
達成される。

最後に、独特の機構である「キャラクタ組み立て／分
解」命令は、キャラクタの組み立て及び分解に関連する
時間的に重要なフォアグランドタスクの汎用メインエン
ジンの実行を容易とさせる。これらの独特の命令コード
は、その各々が１マシンサイクルにおいてメインエンジ
ンのALUによって実行され、キャラクタ組み立て／分解
処理の基本的なビュルディングブロックを表している。

要約すると、これらの命令は４つの命令コードを持っ
ており、即ち、（１）「ish」命令コードは組み立てら
れたキャラクタが右揃えとなる様に、受け取ったビット
を組み立て中のキャラクタにおける適宜の位置内に効率
的にシフトさせ、（２）「osh」命令コードは、キャラ
クタ分解に対して同等の機能を実行し、（３）「bcap」
命令コードは、キャラクタ全体が伝送又は受信された時
を表す為にビットカウントをデクリメントさせ、一方そ
のキャラクタの蓄積されたパリティをビット毎に計算し
（パリティ発生の為と出力するキャラクタの為及びパリ
ティエラー検知の為及び入力キャラクタの為の両方）、
且つブレーク条件（キャラクタ全体がゼロで構成されて
いる）に対するチェックを行ない、（４）「文脈リター
ン」命令コードにおいては、各ファームウエアルーチン
がその時に現在のチャンネルを介してのデータの伝送又
は受領の為に実行されるべき適宜のルーチンのエントリ
ポイントをリターンさせる。

上に要約した３階層処理アーキテクチャーは、その関
連する良好データインタラプト、自動化データ転送、状
態インタラプト処理、及びキャラクタ組み立て／分解機
構と共に、本発明の好適実施例（CL−CD180 ８チャン
ネル非同期通信制御器「MCCCOCTART」）として後に詳細
に説明する。

注意すべきことであるが、本発明によって達成される
柔軟性は、同期及び非同期プロトコルを取り扱うことの
可能な多数のその他の実施例を実現することを可能とす
る。例えば、キャラクタ指向プロトコル（character−o
riented protocol）は、ビットエンジンを「キャラクタ
エンジン」に変換させ、且つ付加的なキャラクタ認識ロ
ジック、及び多分DMAハードウエア（メモリ処理能力を
高速化させる為）及びCRCエラーチェックハードウエア
（メインエンジンの負担を軽くする為）等を付加するこ
とによって実現させることが可能である。ビット指向プ
ロトコルでさえも、インテリジェント「バッファマネジ
ャー」及び「メモリコントローラ」を必要とする場合が
あるかも知れないが、このアーキテクチャーで実現させ
ることが可能である。

付加的なハードウエアサポートが必要であるかも知れ
ないが、複雑なカスタム化した同期プロトコルでさえも
この汎用アーキテクチャーを単に再マイクロコード化す
ることによって取り扱うことが可能であり、マルチチャ
ンネル通信制御器をカスタム化させる為に必要な時間を
著しく減少させている。

可変数のタイマー／カウンタ、フロー制御（例えば、
「Xon/Xoff」）、特別キャラクタ検知、インタラプト処
理、及び現存のプロダクトエミュレーションでさえもこ
のようにして実現させることが可能である。更に、この
汎用アーキテクチャーを「記憶ロジックアレイ（SL
A）」技術を使用して実現することにより、多様なハー
ドウエアロジック変形例を単にメタルマスクの変化によ
って達成することが可能である。

実施例 以下、添付の図面を参考に、本発明の具体的実施の態
様に付いて詳細に説明する。

以下の説明は、単に例示的なものであって、何等特定
的な限定を付することを意図してなされるものではな
い。本発明の好適実施例に関して説明するが、その他の
実施例（カスタム同期及びその他のシリアルプロトコ
ル、「セントロニクス」インタフェース等のパラレルプ
ロトコル、及び制御器のユーザインターフェースへの種
々の改良を実現するもの）は以下の記載の範囲に自明な
ものである。

アーキテクチャー概説 第1b図は、シグネティックスSCC2698OctalUARTの典型
的なマルチチャンネルUARTアーキテクチャーを図示して
いる。注意すべきことであるが、ブロックA1は、２つの
外部のシリアルデバイス（装置）のいずれかへ又はそれ
からシリアルデータを伝送するか又は受信する為、及び
データキャラクタを組み立て且つ分解（チャンネルA4及
びチャンネルB5を使用して）する為の専用ロジックを有
している。

チャンネルＡ内の専用ロジックは、１つの外部シリア
ル装置と通信を行なう為にデータキャラクタを組み立て
且つ分解する為に、ビットを保持用レジスタ内にシフト
入力し且つそれからシフト出力させる。この様なロジッ
クは、チャンネルＢ内に複製されており、２つの別々の
外部シリアル装置との通信の為にキャラクタの組み立て
及び分解を行なうことを可能としている。付加的なタイ
ミングロジック６は、ハードウエアカウンタレジスタ内
にロードされる予め定義されたパラメータに基づいて、
この様な通信を行なう為の適宜のボー速度（baud rat
e）を実現する為に使用されている。

注意すべきことであるが、タイミングロジック、及び
その入力ポート、出力ピン、チャンネルＡ及びチャンネ
ルＢモジュール等を包含するブロックＡの全ては、８チ
ャンネル装置の機能性を得るために、もうあと３つ複製
されている。換言すると、この８チャンネル「octart」
は、その殆どの部分が、第1a図に示した２チャンネル
「duart」のロジックを複製させることによって形成さ
れている。勿論、あるロジックは複製されていない。例
えば、ホストプロセサとの通信を取り扱う操作制御７及
びインタラプト制御８モジュール、及びボー速度発生器
９及びその他のタイミングロジック10等がそれである。
然し乍ら、該２チャンネル装置（第1a図）におけるロジ
ックのかなりの部分が単純に複製されてこの８チャンネ
ル装置を形成している。

第1a図及び第1b図を第２図（本発明の好適実施例MCCC
OCTARTのブロック図）と比較すると、この概略のブロッ
ク図からでさえも、この様なロジックの複数が行なわれ
ていないことを理解することが可能である。外部シリア
ル装置からデータのビットを受け取る為に単に１つのエ
ンジンIBE Ａが設けられているに過ぎない。このエン
ジンは、これらのビットをデータキャラクタに組み立て
る為のロジックを有することもない。その代わりに、８
個の外部シリアル装置のいずれかからのデータをサンプ
ルし且つ受け取り、次いでキャラクタ組み立てを実行す
る為のファームウエアルーチンを実行するメインエンジ
ンＢをインタラプトするためにのみの専用となってい
る。

同様に、外部シリアル装置へデータのビットを伝送す
る為に単に１つのエンジンOBE Ｃが設けられているに
過ぎない。このエンジンは、データキャラクタを分解す
る為のロジックを有するものではなく、８個の外部シリ
アル装置のいずれかへのデータ転送の同期をとり、ファ
ームウエアを介してキャラクタ分解機能を開始し且つ転
送用の付加的なデータビットを与える為にする為にメイ
ンエンジンをインタラプトするためにのみの専用とされ
ている。

従って、これら２つのI/Oビットエンジンは、それら
のロジックを複数個複製することによってではなく、複
数個のチャンネルにおいてビットの伝送及び受領の「時
分割」処理に対する時分割多重方式を使用することによ
って、複数個のチャンネルを取り扱う。基本的に、該２
つのビットエンジンの各々は、各チャンネルを迅速にス
キャンして、入力するビットをサンプル即ち採取し且つ
出力ビットを伝送乃至は送信する。

MCCCOCTARTは、例えばシグネティックスOctalUART等
のその他のマルチチャンネルシリアル制御器が実行する
ものと、同一の基本的機能（外部装置とのシリアルデー
タ転送、ホストプロセサとのデータキャラクタ転送、及
びキャラクタ組み立て及び分解）を１個のチップ上で実
行する。然し乍ら、MCCCOCTARTは、これらの機能をプロ
セサの３つの個別的な階層に分離させる。

BIL Ｄはインタラプト及びデータキャラクタ転送を
包含する全てのホストプロセサとの通信を処理する。IB
E及びOBEは、外部装置との全てのシリアルデータ転送を
処理する。メインエンジンは、キャラクタ組み立て及び
分解の時間的に重要な機能を実行することが可能とさ
れ、又マイクロコード制御下で（即ち、多大のカスタム
化用の柔軟性を持って）多くのその他の複雑な内部デー
タ管理及びプロトコル指向機能を実行することも可能と
している。

例えば、シグネティックスOctalUARTの受領データFIF
Oは、３つのキャラクタの固定容量を持っている。この
ことは、ある通信要求に対しては十分であるかも知れな
いが、その他の場合に不十分となり、データ転送中に大
きな遅れとなる。MCCCOCTARTアーキテクチャーは、ハー
ドウエアFIFOではなくRAMを基礎としたFIFO Ｅを有し
ており、且つこれらのFIFOの寸法を再度決定することが
可能であるから（動的に、又はファームウエアを修正す
ることにより）、FIFOの寸法をユーザの特定の要求に合
せてカスタム化させることが可能である。１つのチャン
ネルは３キャラクタFIFOを必要とする場合があるかも知
れず、一方別のチャンネルは10キャラクタFIFOを必要と
する場合があるかも知れず、又更に別のチャンネルはFI
FOをぜんぜん必要としない場合があるかも知れない。更
に、カウンタ／タイマーは、データビットの伝送又は受
領の同期、伝送又は受領されるキャラクタ又はデータビ
ットの数のカウント、又は特定のデータキャラクタの受
領の間にどれだけの時間が経過したかの決定等の多様な
目的の為に作用することが可能である。この様なカウン
タ／タイマーの異なった使用態様の数は事実上無制限で
ある。従って、カウンタ／タイマー等の特徴の数及び寸
法のみならず正確な機能をカスタム化することが可能で
あることは極めて有用である。このことは、MCCCOCTART
においては、ファームウエアを変化させることによって
達成される。カウンタ／タイマーは所望の数だけ且つ所
望の大きさとすることが可能であり、この様な目的の為
に形成されるRAMの量によってのみ制限されるに過ぎな
い。更に重要な点であるが、カウンタの機能性は真にプ
ログラムすることが可能である（例えば、カウンタをデ
クリメントする速度は、ある時刻を過ぎると加速する場
合がある。一方、シグネティックスのOctalUARTは、４
つのカウンタ／タイマーを与える制限された柔軟性を提
供するのみであり、それはあるタイマー／カウンタの値
を特定することが可能であるという意味においてのみ
「プログラム」する（即ち、パラメータ化する）ことが
可能であるに過ぎない。それらの正確な機能性は修正す
ることが出来ず、又それらの数及び寸法もユーザの明細
に従ってカスタム化させることは不可能である。その結
果、ハードウエア資源の機能性は不十分なものであり、
又その使用度は非効率的である。

フロー制御（「Xon/Xoff」）は、MCCCOCTARTのファー
ムウエア内において完全に実現させることが可能であ
り、そのことはホストプロセサをこのタスクから解放す
ることを意味している。本制御器は、データストリーム
内における或る特別のキャラクタを「埋込命令」として
解釈するべくプログラムさせることが可能である。専用
ランダムロジックを使用する代わりに、汎用マイクロコ
ード化アーキクテクチャーを使用することから得られる
柔軟性は著しく向上され、その具体的な例は正な無限で
ある。

要するに、過去においてはホストの著しい相互作用を
介してのみ達成することが可能であったソフトウエア構
成の多くをMCCCOCTARTのファームウエアで実現すること
が可能である。この様な柔軟性は、例えばシグネティッ
クスOctalUART、又はシグネティックスの初期の通信制
御器で、SCN2651プログラマブル通信インターフェー
ス、SCN2652/SCN68652マルチプロトコル通信制御器、SC
N2661/SCN68661エンハンストプログラマブル通信インタ
ーフェース、及びSCN2681シリーズDUART等において従前
に存在した固定型のランダムロジック構成の場合には全
く得ることが不可能なものである。

注意すべきことであるが、多くの制御器（コントロー
ラ）が「プログラマブル」という用語を使用している
が、それは実際上単に「パラメータ設定可能」、即ちユ
ーザは、制御器が特定のデータに関して固定した機能を
実行する為に制御によって使用される特定のデータの値
（例えば、16個のボー速度の１つ）にレジスタを設定す
ることが可能であるということ、であることを意味する
に過ぎない。

一方、MCCCOCTARTは、制御器によって使用されるデー
タパラメータのみならず、制御によって実行される実際
の機能的ステップ（カスタムプロトコルの実行及び特定
のホストインタラプトの優先度付け）及び制御器によっ
て使用される「仮想資源」のカスタム化（例えば、可変
FIFO深さ、及びカウンタ／タイマーの可変の数、寸法及
び機能性）を修正することが可能である。

MCCCOCTARTを以前のシリアル制御器と区別しているプ
ロセサの３つの階層に加えて、第２図は又、例えば、ホ
ストプロセサが各端部においてモデムを必要とする電話
回線を介して別のコンピュータと通信をしている場合、
MCCCOCTARTが使用する「モデル制御ロジック」（「MC
L」）Ｆを示している。MCLは、スタンダードなモデム
「ハンドシェイク」信号（「データセットレディ」、
「キャリア検知」、「送信要求」及び「送信の為にクリ
ア」）を与え、メインエンジンをこのタスクから解放し
ている。モデム制御ロジックの同様の構成の多数の例が
当該技術分野において存在している。例えば、ナショナ
ルセミコンダクタINS8250−Ｂ非同期通信要素、NS16450
/IN8250A/NS16C450/INS82C50A非同期通信要素及びNS165
50FIFO付き非同期通信要素等がある。然し乍ら、これら
の制御器のいずれもが、MCCCOCTARTアーキテクチャーの
中心である汎用マイクロコード化メインエンジンＢにお
いて本質的な柔軟性を所有するものではない。

MCCCOCTARTの３つの「プロセサ」モジュール（即ち、
I/Oビットエンジン、BIL及びメインエンジン）に付いて
詳細に説明するが、その説明において特に上に要約した
独特の機能（良好データインタラプト、自動化データ転
送、ステートインタラプト処理、及びキャラクタ組み立
て／分解）に特に焦点を当てる。

I/Oビットエンジン 第3a図は、入力ビットエンジンの内部構成要素を示し
ており、その機能はデータのビットを受け取る為に全て
の外部装置をスキャンすることである（各チャンネルは
それ自身のボー速度を持っている）。ビットが受け取ら
れると、入力ビットエンジンはメインエンジンのインタ
ラプト処理機１をインタラプトし、それはそのビットを
処理する為に適宜のファームウエアルーチンを開始させ
る。

チャンネルスキャナー２はIBEのマスターチャンネル
カウンタである。MCCCOCTARTは最大８個迄の外部装置と
通信するので、チャンネルスキャナーは、MCCCOCTARTの
システムクロックによってクロック動作されて、１から
８へ繰返しカウントを行なう。従って、そのシステムク
ロックの各サイクルの期間中に、チャンネルスキャナー
の値はスキャン中の現在のチャンネルを表す。

各チャンネルに対して１つのボー速度カウントレジス
タ３（本実施例においては16ビット）及び１つのボー速
度延長カウントレジスタ４（本実施例においては５ビッ
ト）が設けられている。これらのレジスタは、ボー速度
延長カウントレジスタを最大桁５ビットとして、カスケ
ード構成とされている。共に、それらは初期的に、各ビ
ットに対して２回そのチャンネルから入力をサンプルす
ることが必要な（即ち、「半ビット時間」）クロック数
（チャンネル総数で除算）に等しい値がロードされる。

ボー速度カウントレジスタは、1/16ビット時間（８チ
ャンネルの場合）がロードされ、且つボー速度延長カウ
ントレジスタは、８の値がロードされ、複合カウントは
サンプリングを半ビット時間の間隔で発生させる。従っ
て、これら２つのレジスタは、1/16ビット時間増分で、
1/16ビット時間から２ビット時間への範囲をアクセスす
ることが可能である。

例えば、1,200ビット／秒のボー速度のチャンネル及
び10MHのシステムクロックが与えられると、各１秒の間
に、1,200ビットが送られるか又は受け取られ、且つ一
千万個のクロックが発生する。従って、３個のチャンネ
ルの形態を仮定すると、ボー速度カウントレジスタは、
チャンネル数で割ったビット当たりのクロック数（即
ち、10,000,000を1,200で割ったもの）、即ち約2,778の
値にセットされると、各ビット（「ビット時間」）毎に
一度入力をサンプルすべく同期してゼロへカウントダウ
ンする（デクリメンター５を介して）。従って、ボー速
度カウントレジスタは、その値の半分（即ち、1,389）
にセットされ、各半ビット時間毎にビットをサンプルす
ることを許容する。

IBEは２つのモードの内の１つのモードにおいて入力
をサンプルするが、それらの２つのモードとは、「同期
サンプル」モード（半ビット時間毎又は全ビット時間毎
のいずれかに入力がサンプルされる）及び「ゼロサー
チ」モード（二進「０」が検知される迄可及的に多くの
データがサンプルされる）である。各チャンネルに対し
て２つの制御ビットが存在する。制御モードビット６
は、どのモードでIBEが動作するかを決定し（ボー速度
延長カウントレジスタは、IBEが同期サンプルモードで
動作する周波数を決定する）、且つ制御イネーブルビッ
ト７は、そのチャンネルがイネーブルされるか否かを決
定する（何故ならば、特定のチャンネルを完全にディス
エーブルさせることが望ましい場合があるからであ
る）。

ボー速度カウントレジスタ（初期的にはホストによっ
て設定される）、ボー速度延長カウントレジスタ、及び
制御ビットの「次の状態」の値は期間レジスタ８内に維
持される。ボー速度カウントレジスタ又はボー速度延長
カウントレジスタがゼロへ（以下に説明する如くに）デ
クリメントされると、カウンタMUX9はこの事実を検知し
且つそのチャンネルに対応する期間レジスタからの夫々
の値を再ロードする。

このMCCCOCTART実施例によって処理されるものの如き
非同期プロトコルにおいては、通常のキャラクタは「開
始ビット」（二進「０」）及び「ストップビット」（二
進「１」）によって「フレーム」化され、キャラクタ自
身（通常５乃至８ビット）はそれらの間にある。

開始ビットに対するサーチが開始すると、各チャンネ
ルに対する現在の制御モードビット（ボー速度カウント
レジスタに関連している）によって示される如く、IBE
は常にゼロサーチモードにある。このモードの期間中、
ボー速度カウントレジスタはデクリメントされない。そ
の代わりに、現在のチャンネル上の入力は可及的に頻繁
にサンプルされ（即ち、ｎをチャンネル数として、各
「ｎ番目」のクロック）、チャンネルMUX10を喚起して
現在のチャンネル入力をサンプルさせる。

制御ロジック11は、サンプルした入力をチェックする
（制御モードビットから、それがゼロサーチモードにあ
ることを知りながら）。サンプルしたビットが二進
「０」でない場合、ゼロサーチが繰返し行なわれる。こ
の処理は、二進「０」が検知されるまで（潜在的な開始
ビットの「端部」を表す）、無限的に継続し、その時点
において、制御ロジックは、現在の制御モードビットを
修正することによって、IBEを同期サンプルモードへ変
換させる。この時点において、有効な開始ビットが検知
されていない場合も有り得る（例えば、ノイズが瞬間的
に「０」の値を発生した場合）。この可能性は同期サン
プルモードにおいて処理される。

同期サンプルモードになると、各チャンネルがスキャ
ンされ（ｎ個のチャンネルに対すてｎ番目毎のクロッ
ク）、現在のスキャンされるチャンネルはチャンネルス
キャナーによって表される。対応するボー速度カウント
レジスタ及びボー速度延長カウントレジスタは、２個の
カスケードレジスタとして、デクリメンターによってデ
クリメントされる。これら２つのレジスタのいずれかが
ゼロに到達すると、それはその初期値で再ロードされ、
それはその対応する期間レジスタ８内に維持される（各
チャンネルに対して１つ）。

ボー速度延長期間レジスタは、初期的に、半ビット時
間でサンプルすべくセットされる。このことは、有効開
始ビットが検知されるか否かを決定する為に、潜在的開
始ビットの「中間」を検査することを可能とさせる（こ
の時点において「０」が再度検知されると仮定され
る）。

この、カスケート構成としたボー速度カウントレジス
タ及びボー速度延長カウントレジスタをデクリメントす
る処理は、ボー速度延長カウントレジスタがゼロに到達
し、現在のチャンネルから入力をサンプルする時間であ
ることを表す迄、継続する。次いで、チャンネルMUXが
喚起され、現在のチャンネルの入力をサンプルさせる。

制御ロジックは、同期サンプルモードにおいては、ゼ
ロサーチモードにおけるのとは多少異なって機能する。
それは、制御モードビット（ゼロサーチモードにおける
如く）から、IBEが同期サンプルモードにあるか否かを
決定する。ボー速度延長カウントレジスタは、チャンネ
ルスキャナーが各チャンネルをスキャンする速度（ｎ個
のチャンネルが与えられたとして、ｎサイクル毎）と比
較して比較的頻繁にゼロに到達するので、制御ロジック
は付加的な機能を実行せねばならない。

比較的頻繁ではないが、ボー速度延長カウントレジス
タがゼロに到達すると、制御ロジックはサンプルしたビ
ット（チャンネルMUXの喚起により受領）をサンプルデ
ータビットレジスタ内へロードし且つサンプルビットフ
ラッグ（各チャンネルに対して１個）をセットする。こ
のフラッグは、サンプルしたビットはメインエンジンに
よる検査の為の準備がなされていることを表す。メイン
エンジンがこのビットをサンプルすると、それは該フラ
ッグをクリアする（それば、ボー速度延長カウントレジ
スタが再度そのチャンネルに対してゼロに到達する時の
前である）。しかし、メインエンジンは、インタラプト
を介して、ビット（現在のチャンネルに対して）が検査
の為に準備がなされていることをどうにかして通知され
ねばならない。

この問題を解消する為に、サンプルビットフラッグ
は、又、制御ロジックに対して、IBEのインタラプトロ
ジック14を喚起することの必要性を通知し（それがサン
プルデータビットをロードし且つサンプルデータビット
フラッグをセットする前に）、それによりメインエンジ
ンをインタラプトさせ、メインエンジンに対してビット
が検査の為に準備がなされていることを通知する。従っ
て、多くのｎ番目のサイクル期間の間、ボー速度延長カ
ウントレジスタは未だゼロへカウントダウンしている
が、制御ロジックは条件付きによってメインエンジンに
対するインタラプトを開始する。

IBEは任意の与えられた時間においてメインエンジン
に対する１つのインタラプトペンディングのみを持つこ
とが可能であるので、制御ロジックがインタラプトペン
ディングフラッグ15をチェックすることが必要である。
それがセットされると、制御ロジックは別のインタラプ
トを開始することはできない。それがセットされず、且
つそのチャンネルに対してのサンプルビットフラッグが
セットされると、制御ロジックはインタラプトロジック
を喚起し、それをしてメインエンジンをインタラプトさ
せる。

更に、制御ロジックは、現在サンプルされたデータビ
ットをテストし、且つ、それが二進「１」である場合に
のみ、「次の状態」の制御モードビット期間レジスタか
ら制御モードビットレジスタを再ロードする（無効開始
ビットの場合には、現在の制御モードビットをセットさ
せ、且つゼロサーチモードを自動的に再開させる）。

従って、ゼロサーチモード（常に初期的なモード）に
おいて、制御ロジックはサンプルデータレジスタをロー
ドし、且つ、サンプルビットが二進「０」である場合
に、制御モードビットを修正し、IBEを同期サンプルモ
ードとさせる。同期サンプルモードにおいて、全てのｎ
番目のサイクルの期間中（ｎチャンネルの場合）、制御
ロジックがインタラプトペンディングフラッグをチェッ
クし、且つ、それがセットされておらず且つサンプルデ
ータビットフラッグがセットされていると、制御ロジッ
クはインタラプトロジックを喚起してメインエンジンを
インタラプトする。ボー速度延長カウントレジスタがゼ
ロに到達し（比較的頻繁ではなく）てビットをサンプル
させると、制御ロジックもサンプルデータビットレジス
タをロードし且つそのチャンネルに対するサンプルビッ
トフラッグをセットする。対応するボー速度期間レジス
タからボー速度カウントレジスタを再ロードする付加的
ロジック（二進「１」が検知された場合にのみ制御モー
ドビットを再ロードする）は、有効な開始ビットが検知
される迄、IBEが自動的にゼロサーチモードに留まるこ
とを保証する。

然し乍ら、残りのロジックの殆どは、メインエンジン
におけるファームウエアルーチンによって実行される。
IBEは初期的にゼロサーチモードにあり（開始ビットの
初期端部に対するサーチ）且つこの処理は二進「０」
（開始ビットの初期端部）が検知される迄継続し、その
時点において、制御ロジックは制御モードビットを修正
し、IBEを同期サンプルモード（半ビット時間）とさせ
ることに付いては既に説明した。

同期サンプルモードにおいて、IBEはチャンネルを常
にスキャンする（ｎ個のチャンネルの各々がｎ番目のサ
イクル毎にスキャンされる）が、チャンネル入力をサン
プルする代わりに、ｎサイクル毎に、制御ロジックは、
インタラプトが現在ペンディング（未決）ではなく且つ
チャンネルのサンプルビットフラッグがセットされる
と、インタラプトを開始する。

このインタラプト機能（メインエンジンがサンプルビ
ットを検査することを許容するのに必要）に加えて、制
御ロジックは、開始ビット端部（ゼロサーチモードで検
知される）が実際に有効な開始ビットであるか否かを検
証する上で、メインエンジンを助けねばならない。上述
した如く、同期サンプルモードは、初期的に、IBEをし
て半ビット時間毎に入力をサンプルさせる。従って、潜
在的開始ビットの「中間」がサンプルされる。インタラ
プトされると、メインエンジンは、有効な開始ビットを
チェックする（状態インタラプト処理において後に説明
する）ファームウエアルーチンを喚起することを知得す
る。

そのファームウエアルーチンが開始ビットが有効であ
ると決定（何故ならば、ビットの端部と中間の間の
「０」から「１」へ値が変化したので）すると、そのル
ーチンはそれ自身のエントリーポイントを「文脈RAM」
内へロードさせ、有効な開始ビットが検知される迄、そ
のチャンネル上で各サンプルビットの後に同一のルーチ
ンを実行させる。然し乍ら、ファームウエアルーチン
が、開始ビットが有効であると決定（ビットがその初期
端部から中間へ二進「０」を維持すると仮定）すると、
それは「開始ビット終端」ルーチンに対するエントリー
ポイントをロードし、且つボー速度延長期間レジスタを
修正し、IBEを同期サンプルモードに留まらせる。

IBEは、半ビット時間でサンプルし、次に、申立られ
た開始ビットの終端をサンプルする（そのサンプルは、
該ファームウエアによって無視される）。このインタラ
プトにおいて、フォアグラウンドルーチンはボー速度延
長期間レジスタを再ロードして、将来のサンプルをして
全ビット時間間隔で発生させる。

然し乍ら、ボー速度期間レジスタは、キャラクタの第
１ビットの「中間」（半ビット時間の後）がサンプルさ
れ、メインエンジンに対して付加的なインタラプトを発
生する後迄、ボー速度カウントレジスタ内にロードされ
ることはない。そのキャラクタの引き続くビットに対し
てのみならず（１ビット時間間隔で）そのキャラクタの
この第１ビットの中間のサンプリングからインタラプト
が発生される。これらのインタラプトの各々は、メイン
エンジンをしてそのファームウエアを喚起して、該サン
プルしたビットからそのキャラクタを組み立てる。これ
らの機能は、メインエンジン及びキャラクタ組み立て／
分解セクションにおいて以下に詳細に説明する。

IBEによって取られる最後のアクションは、ストップ
ビットの検知を包含する。メインエンジンはデータキャ
ラクタの幅（ビット数）を知っているので、それは、何
時ストップビットが発生するかを知っており、該ストッ
プビットの中間をサンプルした後に、このストップビッ
トが実際に有効であるか否かを決定する。有効であれ
ば、メインエンジンファームウエアルーチンは、単に
「次の状態」制御モードビット（期間レジスタに関連）
を修正し、究極的にIBEをゼロサーチモードに戻し（次
のキャラクタの開始ビットの初期端部を捜索）、キャラ
クタ検知処理全体を再度開始させる。ストップビットが
無効であると、メインエンジンファームウエハはその事
実を検知し且つフレーミングエラーをホストプロセサに
通知することが可能である。

第3b図に示したOBEは、IBEの機能と極めて類似した態
様で機能する。チャンネルスキャナ２は、８番目のクロ
ックサイクル毎に１つの態様で、８個のチャンネルをカ
ウントする同一の機能を実行する。ボー速度カウントレ
ジスタ３は、IBEにおけるものと同一である。しかし、
ボー速度延長カウントレジスタ４は一層簡単な機能を実
施し、それは、通常、全ビット時間サンプリングを行な
うべくセットされ、その際にOBEをして特定したボー速
度でビットを出力させることを可能とさせる。開始ビッ
ト又はストップビット検知は必要ではない（メインエン
ジンファームウエアルーチンはキャラクタをスタートビ
ット及びストップビットによってフレーム構成させる
が、その処理はOBEにとって透明である）。スタート及
びストップビットの検知を行なうことが必要ではないの
で、１つ又はそれ以上のチャンネルをディスエーブルさ
せることを許容する為に制御イネーブルビット７は未だ
存在しているが、「制御モードビット」の必要性は存在
しない。

制御ロジックにおいて及びメインエンジンをインタラ
プトする処理において差は存在しない。サンプルデータ
ビットレジスタの代わりに、OBEは、１ビット（各チャ
ンネルに対して出力すべき「次の」ビット）を有する出
力データビットレジスタを有している。第２ビットはデ
ータは出力ラッチレジスタ内にラッチされて、外部シリ
アル装置に対する連続的な出力を発生し、２ビット出力
パイプラインを形成する。サンプルビットフラッグの代
わりに、IBEは出力ビット必要フラッグを有し、それは
メインエンジンに対して、該２ビットパイプラインをフ
ィル即ち充填する為に出力の付加的なビットが必要であ
ることを示す。

制御ロジックはIBEにおけるよりも著しく簡単であ
る。それは、単に、出力データビットをデータ出力ラッ
チ中に移動させ、且つ出力ビット必要フラッグをセット
するだけである。更に、インタラプトがペンディング即
ち未決でない場合（即ち、インタラプトペンディングフ
ラッグ15がセットされていない場合）、制御ロジックは
インタラプトロジック14をしてメインエンジンをインタ
ラプトさせる。

この処理は、キャラクタの全てのビットが送られる
（最後のストップビットを含んで）迄継続し、その時点
において、該処理は単純に何度も繰返し行なわれる。メ
インエンジンは、次のキャラクタを分解し且つ該２ビッ
トパイプラインをそのキャラクタのビットで充填する
が、その処理もOBEにとっては完全に透明であり、１つ
のキャラクタを次のものから区別することは必要ではな
い。

IBE及びOBE機能は極めて個別的であり、且つMCCCOCTA
RTの残部にとって比較的透明である。それらの機能性を
ビットの送りだし及び受け取りに拘束させることにより
（スタートビット及びストップビット検知でさえも主に
メインエンジンファームウエアによって制御される）、
それらは例えば高度にカスタム化したプロトコル又はメ
インエンジンに対する埋込命令（ファームウエア制御の
下で殆どいかなる想像可能な機能の実行も可能とする）
の如き非常に異なった目的に対して再使用する為に著し
い量の柔軟性を維持している。

ハードウエアを複製することを無しに、IBE及びOBE
を、スタートビット、ストップビット、中間ビット、又
は非同期型の又は同期型の想像可能などのようなプロト
コルも検知する為に使用することが可能である。付加的
なハードウエアが必要な場合があるが、ファームウエア
制御型メインエンジンにより提供される柔軟性の特徴を
フルに活用して、IBE及びOBEの完全な機能性を極めて効
率的に使用することが可能である。

バスインターフェースロジック （自動化データ転送） IBE及びOBEは、MCCCOCTARTのインターフェースを外部
シリアル装置で処理するが、BILはMCCCOCTARTのその他
のインターフェースをそのホストプロセサで処理する。
OBEが転送する為にビットに分解する為にメインエンジ
ンに対してホストからキャラクタを受け取らねばなら
ず、且つ、その逆に、IBEによって受け取られ且つメイ
ンエンジンによってデータキャラクタに組み立てられる
ビットはホストへ転送されねばならない。全てのシリア
ル制御器はこれらのデータキャラクタ転送機能を実行せ
ねばならないが、このデータ転送処理を自動化するBIL
の方法はむしろユニークであり、ホストプロセサから何
時FIFOが空であるかを決定する為のかなりの責任を取り
除いている。この処理は、又、各チャンネルに対するポ
インターアドレス機能の複製を回避することにより実効
コストにおいて著しい減少をもたらしている。

例えばシグネティックスSCC2698等の第１図に示した
如き現存のシリアル制御器は、単にアドレスをデコード
し（それはホストによって維持され且つ供給されねばな
らない）且つ読取／書込回路を提供する。ホストプロセ
サはその他のことを行なわねばならない。例えば、この
様な制御によってキャラクタが組み立てられ且つホスト
へ転送する準備がなされたとすると、ホストプロセサ
は、マルチプルのチャンネルの中で、どのアドレス（チ
ャンネルに従属）が第１データキャラクタを有している
かを決定し、且つそのアドレスを制御器に特定せねばな
らない。更に、各キャラクタが転送された後に、各ホス
トは、FIFOが空であるか否かを決定せねばならない。

BILはこの処理におけるホストの役割を著しく簡単化
させる。文脈指向アドレス動作のMCCCOCTARTの使用に起
因し（状態インタラプト処理に関し後に説明する）、ホ
ストはどのチャンネルからデータを受け取ったかを特定
することは必要ではない。BILはこの情報に対してのア
クセスを持っており（バックグラウンドファームウエア
ルーチンによってロードされる）、且つそれをホストへ
供給することが可能である。

メインエンジンのファームウエアルーチンは、そのデ
ータを転送することが可能であることを示す為にホスト
をインタラプトすることの必要性を検知する。例えば、
MCCCOCTARTは、メインエンジンがホストプロセサによっ
て伝送されたデータキャラクタを分解し且つOBEを介し
て個々のビットを伝送する為の準備がなされる迄、FIFO
に該データキャラクタを格納させる。ファームウエアル
ーチンは、特定のチャンネルの伝送データFIFOが何時空
であるかを検知し、ホストがインタラプトされそのチャ
ンネルを介して伝送されるべき付加的なデータキャラク
タを送ることが可能であることを示す。

ファームウエアルーチンは、又、特定のチャンネルの
受け取りデータFIFOにおけるホストが特定したスレッシ
ュホールドが何時到達したか（例えば、何時５バイトが
８バイトFIFO内に格納されたか）を検知し、ホストをイ
ンタラプトしてそれがこれらのデータキャラクタを受け
取ることが可能であることを示す。伝送及び受け取りイ
ンタラプトに加えて、外部装置の１つとしてモデムを使
用する場合、ファームウエアは、又、そのモデムのステ
ータス信号が何時変化したかを検知し、ホストがインタ
ラプトされてそれがモデムの新たなステータスを読み取
ることが可能であることを示す。

注意すべきことであるが、メインエンジンのファーム
ウエアルーチン（その機能を修正することは可能）は、
通常、このホストプロセサをインタラプトする為の必要
性を決定するタスクを実行する。更に、ファームウエア
は、又、適宜のBILレジスタを初期化して、BILが必要な
データ転送を実行することを可能とさせる。

該ファームウエアは、そのレジスタが「アイドル」状
態にある場合、この様なレジスタの２つのバンクの１つ
から、３つのレジスタ、即ち受け取りインタラプトレジ
スタ１、伝送インタラプトレジスタ２、及びモデムイン
タラプトレジスタ３、の１つのレジスタを初期化させる
（特定のインタラプトに対して）。該ファームウエア
は、どのタイプのインタラプトが必要とされるかを知っ
ているので、それは該３個のレジスタのどれを初期かさ
せるべきかを知っている。この初期化は、適宜のレジス
タを、チャンネル番号４（例えば、その伝送データFIFO
が空であるチャンネル）及びそのインタラプトの状態５
（初期的には「アサート（assert）する為の準備完
了」）でローディングさせることを包含する。その状態
は、究極的に、「アサーテッド（asserted）」へ次いで
「確認（acknowledged）」に変化され、次いでその「ア
イドル」状態へ戻される。

更に、該ファームウエアはポイントレジスタ６及びカ
ウントレジスタ７の対応するバンクを初期化させる（各
「インタラプトタイプ」に対して）。パイプラインを形
成する為に本実施例においてこれらのレジスタの各々の
２つのバンクがあり、メインエンジンが次のインタラプ
トの準備をしている間にBILが１つのインタラプトに応
答することを可能とさせる。特定のバンクに対して、ポ
インタレジスタの各組は、ポインタ受け取りデータ／ス
テータスレジスタ８及びポインタ伝送データレジスタ９
を有している。特定のバンクに対して、カウントレジス
タの各組は、カウント受け取りデータ／ステータスレジ
スタ10及びカウント伝送データレジスタ11を有してい
る。

ポインタ受け取りデータ／ステータスレジスタは、
「ローカルアドレス」を有しており、即ち、チャンネル
番号を連結された場合に、それは該受け取りFIFOのその
チャンネル内の最初の（初期的な）データキャラクタの
実際の位置に対して「ポイント（指摘）」する。この
「文献指向アドレス動作」（以下の状態インタラプト処
理の部分において説明する）の方法は、MCCCOCTART（BI
Lを包含する）の種々の構成要素が、ホストがチャンネ
ル番号（BILが内部的に維持している）を特定すること
の必要性無しに、実際のレジスタ及びFIFO位置をアドレ
スすることを可能とする。受け取りFIFOは、インターリ
ーブした受け取りデータ（偶数アドレスにおいて）及び
ステータス情報（奇数アドレスにおいて）を有してい
る。ポインタ伝送データレジスタも、該伝送FIFOの最小
（初期的）位置をポイントするローカルアドレスを有し
ている。伝送FIFOは、メインエンジンがデータキャラク
タを分解する準備が完了する迄、ホストによって伝送さ
れるデータキャラクタを格納する。

カウント受け取りデータ／ステータスレジスタは、MC
CCOCTARTによって受け取られ且つホストプロセサへ伝送
する準備が完了しているデータキャラクタの総数（初期
的に）を有している。カウント伝送データレジスタ（初
期的には０）は、ホストによって実際に転送されるデー
タキャラクタの数をカウント即ち計数する。

該ファームウエアがこれらのレジスタ（インタラプト
レジスタ、対応するポインタ及びカウンタレジスタの３
つのタイプの内の１つ）を初期化すると、BILハードウ
エハは、インタラプト制御ロジック12を介して、制御を
行なう。インタラプト制御ロジックは、インタラプトレ
ジスタを常にスキャンする。これらのインタラプトレジ
スタの１つの状態が該ファームウエアによってその「ア
サート準備完了」にセットされると、インタラプト制御
ロジックがホストプロセサに対するインタラプトをアサ
ート即ち積極的に動作させる。次いで、該ホストは、
「インタラプト確認」を出すことによって、そのインタ
ラプトに応答する。

ホストのインタラプト確認信号は、１乃至７の数で構
成されており、それはスタンダードなモトローラ68000
インタラプトレベルを表している。ホストプロセサは、
以前に、文脈アドレスメモリ（各チャンネルに対して）
を所望のインタラプトレベルへ初期化している。インタ
ラプト制御ロジックは、インタラプト確認レベルを、対
応するチャンネルに対しての文脈アドレスメモリ内の予
め特定したレベルと比較する。それらが合致し、且つ対
応するインタラプト５の状態が「アサート」されると、
該インタラプトはMCCCOCTARTに対して意図される。そう
でなければ、ホストのインタラプト確認はその他のほか
の装置に対して意図され、且つインタラプト制御ロジッ
クは単にその確認信号を無視する。

インタラプト制御ロジックがそのインタラプトが正確
に確認されたことを決定すると、それはインタラプトス
タック13の頂部へ情報（即ち、実行中の現在のインタラ
プトの関する情報）を押し上げることによってその事実
を格納する。この情報は、インタラプトのタイプ（即
ち、伝送、受け取り、モデム、又は「何も無し」）を表
す２ビットから構成される。この情報は、チャンネル番
号と組合わされると、後にアドレス翻訳ロジック14（デ
ータ伝送用に適切なレジスタをアドレスする為に）又は
ポインタ・カウンタレジスタ（その特定のタイプのイン
タラプトに対してのポインタを正確にインクリメント及
びデクリメントする為に）によって後の時間において使
用することが可能である。

インタラプト制御ロジックがこの情報をインタラプト
スタック上に押し上げると、インタラプト制御ロジック
がステータスベクトルをホストプロセサへ送る。このベ
クトルは、「チップID」（他のチップもある場合に、ど
のチップがホストをインタラプトしているかをホストが
決定することを可能とする）及びインタラプトのタイプ
（受け取りデータインタラプト用の「良好データ」とし
てステータス情報を含む）を有している。伝送されるべ
きキャラクタの数、チャンネル番号、及び付加的な雑多
な情報はホストによってアクセスされることが可能であ
る。

「良好データインタラプト」機構（以下に説明）は、
ホストを、受け取った各データキャラクタのステータス
をチェックするタスクから解放している。その代わり
に、ホストは、受取るべきキャラクタの数を正確に知
り、且つそれらが全て特定のステータスタイプであるこ
とを知る。

ホストがこのステータスベクトルを受け取ると、それ
はデータ伝送を開始すべく手続を進めることが可能であ
る。上述した如く、ホストのジャブは極端に簡単化され
ている。ホストは４つのアドレスを維持することが必要
であるに過ぎない。１つのアドレスは、モデムステータ
スを受け取る為に使用される。第２のアドレスはデータ
キャラクタを伝送する為に使用される。第３のアドレス
は、データキャラクタを受け取る為に使用され、且つ第
４のアドレスはデータステータス情報を受け取る為に使
用される。注意すべきことであるが、チャンネル数及び
FIFOアドレス（ここにデータキャラクタが格納される）
は、全てMCCCOCARTによって維持される。ホストは、こ
の情報を維持することは必要ではない。

更に重要なことであるが、ホストは、例えば、「良好
データ」の10個のキャラクタが受け取りデータFIFOにお
いて待機していることを知っている。これらのキャラク
タの正確な位置を知ること無しに、ホストは、単純に、
１つのみの受け取りデータアドレスを指定することによ
って読取を開始する。BILのアドレス翻訳ロジックは、
最初のアドレスキャラクタの実際のアドレスを完成し、
且つそのアドレスを自動的にインクリメントして残りの
キャラクタにアクセスする。

これらの４個のアドレスの１つを受け取ると、アドレ
ス翻訳ロジックはそのレジスタ又はFIFOデータの実際の
アドレスを決定する。注意すべきことであるが、このレ
ジスタ翻訳ロジックは、データキャラクタの転送の為に
のみ使用されるものではなく、レジスタの読取及び書込
の全ての為に使用される。従って、アドレス翻訳ロジッ
クは、最初に、このアドレスが「グローバルレジスタ」
（即ち、いずれの特定のチャンネルとも関連していない
レジスタ）であるか否かを決定する。そうである場合に
は、それはホストの特定したアドレスに単にゼロを付加
し、且つそのレジスタに関して読取か又は書込動作のい
ずれかを開始する。そのアドレスが「チャンネルレジス
タ」である場合、アドレス翻訳ロジックは既知のチャン
ネル番号をそのアドレスに付加し、且つそのレジスタに
関して読取又は書込動作のいずれかを開始する。モデム
インタラプトはこのカテゴリイに入る。BILはデータの
ブロックを転送する必要がなく、従ってそれは、単に、
ホストの「モデムステータスレジスタ」に対するアクセ
ス（モデムからの最近変化されたステータス信号を有す
る）及びインタラプト用装置のその他のチャンネル特定
的レジスタに対してのアクセスをサポート即ち支持す
る。

ホストが通常のデータキャラクタ転送を開始せず単に
MCCCOCART上のレジスタから読み取るか又はそれに書込
を行なう上述した場合において、データバスインターフ
ェース16が動作する場合がある。殆どの場合、データは
単にホストとMCCCOCTARTとの間で転送され、データバス
インターフェースは単に内部データバスと外部データバ
スとの間の通信の同期を取るに過ぎない。然し乍ら、ホ
ストがこのインターフェースを「プログラム」すること
を欲する場合、付加的なタスクを実行することが可能で
ある。例えば、ホストは、それがあるレジスタに書込を
行なう場合に、付加的な情報（例えば、チャンネル番
号）をそのレジスタに書き込むことを欲する場合がある
かも知れない。データバスインターフェースはこのタス
クを実行することが可能である。その他の実施例におい
て、ファームウエアの制御下において、多様なその他の
タスクを実施することが可能であり、無制限の可能性を
形成する。

然し乍ら、アドレス翻訳ロジックがホストが実際にデ
ータキャラクタ転送を開始することを決定する場合、即
ちホストがポインターレジスタの２つのバンク（ポイン
ター受け取りデータ／ステータスレジスタ８及びポイン
ター伝送データレジスタ９）の内の１つと関連するアド
レスを供給する場合、アドレス翻訳ロジックは、単に、
そのポインターレジスタによってポイントされる位置を
アクセスする（チャンネル番号を付加して）。この位置
は、ホストによって読み取られるべき最初のデータキャ
ラクタの受け取りFIFOにおける正確な位置（奇数アドレ
スの場合、又は偶数アドレスに対してはステータス情
報）であるか、又はホストによってデータが転送される
べき転送FIFO内の最初の位置である。

アドレス翻訳ロジックが、１組のポインタ操作ロジッ
ク17及びカウンタ操作ロジック18を介して、ポインタレ
ジスタ及びカウントレジスタがそれらの重要なタスクを
実行することを支持するのはこの時点においてである。
チャンネル毎を基礎にする場合に付加的なロジックは必
要ではない。この１組のロジック及びポインタ及びカウ
ンタレジスタの２つのバンクで十分である。注意すべき
ことであるが、現在動作中のインタラプトのタイプ（受
け取りデータ、受け取りステータス、又は伝送データ）
に関する情報は、インタラプトスタックの頂部から得る
ことが可能である。

ホストによるデータ伝送の場合、適宜のポインタレジ
スタ（データキャラクタが書き込まれる最初の位置にポ
イントすべくファームウエアが初期化する）は、ホスト
が書込動作を開始する度に単に１（ポインター操作ロジ
ックを介して）だけインクリメントさせる。このこと
は、ホストがアドレスを維持し（且つインクリメントさ
せること）の必要性を取り除いており、正確なグローバ
ルアドレスを維持する必要性はない。

カウントレジスタ（ファームウエアは書き込まれるべ
きデータキャラクタの総数で初期化する）は、１だけデ
クリメントされ（カウンタ操作ロジックを介して）、BI
Lがホストによって実際に書き込まれたデータキャラク
タの正確なカウントを維持することを可能とする。

ホストによるデータの受領の場合、カウントレジスタ
は未だ１だけデクリメントされるが、ポインタレジスタ
（それはデータキャラクタが読み取られる位置をポイン
トする）は２だけインクリメントされる（何故ならば、
ステータス情報はデータキャラクタ間においてインター
リーブされている）。このことは、ホストがステータス
情報を受け取ることを回避することを可能としている
（何故ならば、良好データインタラプト機構によって、
ホストは既に該データのステータスを知っているからで
ある）。

ホストによるステータスの受領の場合、ポイントレジ
スタは奇数アドレスをポイントする（そのステータスが
関連するデータキャラクタを通過して１個のバイト）。
読取動作が開始されるが、その最初のデータキャラクタ
のステータスをホスト、ポインターレジスタ及びカウン
トレジスタへの転送はインクリメントもデクリメントも
されない。

このことは、ホストが受け取ったデータのステータス
を既に知っていたものではない制限された条件を考える
まで、異常なことにように思えるかも知れない。一般的
に、殆どの受け取ったデータキャラクタは「良好デー
タ」であるので、そのステータスを知られている。然し
乍ら、ステータスが何等かのエラー又は特別のキャラク
タのタイプである場合、良好データインタラプト特徴は
正確なタイプのエラーは特別キャラクタを表すものでは
ない（その他の実施例において、異なったタイプのエラ
ー又は所望の特別キャラクタの数に依存して、ホストが
いずれのキャラクタのステータスをチェックすることの
必要性を解消することが実現可能であるかも知れない
が）。

従って、ホストはエラー又は特別キャラクタのタイプ
をチェックし、次いでその状態をソフトウエアサービス
ルーチンで処理することを所望するかも知れない。この
様な場合に、プロックデータ転送は通常必要ではない。
従って、ポインターレジスタは、この時にはインクリメ
ントされずに、ホストソフトウエアサービスルーチンが
後の時間において該特別キャラクタを読み取ることを可
能とする。

インタラプトが処理されると（即ち、ホストが全ての
データキャラクタの転送又は受領を完了）、ホストは
「インタラプト終了」信号をBILへ送る（インタラプト
レジスタの状態を「インタラプト終了」に修正）。この
信号を受け取ると、インタラプト制御ロジックは、イン
タラプトスタックの頂部から情報を取り出す。この状態
において、ファームウエアは、そのインタラプトレジス
タバンクを更にデータ転送させる為に再度イネーブルさ
せる（そのインタラプトレジスタ状態をその「アイド
ル」状態に変化させることにより）前に必要となること
のある何等かの付加的なクリーンアップを（適宜の折り
に）実行することが可能であり、その時に、BILは、フ
ァームウエアから出された場合に（チャンネル、ポイン
ト、及びカウントレジスタを初期化した後に、該状態を
「アサート準備完了」状態に変化させることによって）
次のインタラプトに対してこの処理を繰り返し行なうこ
とが可能である。

インタラプトスタックの頂部が「インタラプト無し」
（上述した如く）を表す値を有する場合、ポインタレジ
スタ及びカウントレジスタはアイドル状態のままであ
る。特定の時間においてインタラプトが処理されていな
いが、BILはホストから読取及び書込要求の受け取り、
及びアドレス翻訳（上述した如く）の実行を継続して行
ない、ホストがMCCCOCART上のグローバル又はローカル
（チャンネル特定性）レジスタに対して読取及び書込を
行なうことを可能とする。

メインエンジン 概説 I/Oビットエンジン（上述した）は、例えばモデム及
びシリアルプリンタ等の外部シリアル装置に対するMCCC
OCTARTのインターフェースを処理する。このインターフ
ェースを介してビットがMCCCOCTARTへ及びそれから転送
される。バスインターフェースロジック（これも上述し
た）は、外部ホストプロセサに対するMCCCOCTARTのその
他のインターフェースを処理する。このインターフェー
スを介して、キャラクタがMCCCOCTARTから及びそこへ転
送される（MCCCOCTARTへのパラメータ及び命令も同
じ）。

これらの２つのインターフェースの間にメインエンジ
ン（第５図に図示）が設けられており、それは、外部シ
リアル装置へ送るべきOBE用のビットにキャラクタ（ホ
ストからBILによって受領）から分解し、且つビット（I
BEを介して外部装置から受領）をホストへ送るべきBIL
用のキャラクタに組み立てる主要なタスクを実行する。
これらの主要なビット指向型（従って、時間重要型）の
タスクに加えて、メインエンジンは、例えばデータFIFO
の管理、タイマー／カウンタの維持、複雑なプロトコル
関連タスク、及びその他のファームウエア内にプログラ
ムされる所望のタスク等の多様な複雑なキャラクタ指向
型（従って時間重要性の少ない）タスクも実行せねばな
らない。

メインエンジンのアーキテクチャーの殆どは、どのよ
うなマイクロプログラム化されたエンジンにとってもス
タンダードなものである。例えば、マイクロコードROM1
は、レジスタ間のデータ転送及びALUの動作を制御する
マイクロコード（ファームウエア）のシーケンスを有し
ている。スタンダードなマイクロコードシンケンサ２が
設けられており、それはマイクロコードROM内へのアド
レスをインクメントして、その物理的アドレスに従って
逐次にマイクロ命令を実行させる。

勿論、事実上いかなるマイクロコードシーケンサの場
合における如く、この逐次的な実行は、「分岐」命令
（それは実行を特定したアドレスへ転送させる）又は
「サブルーチンコール」（それは単に分岐であるが、現
在のアドレスの次に続くアドレスを格納して、サブルー
チンが「サブルーチンリターン」マイクロ命令によっ
て、完了された時に実行をその位置へリターンさせるこ
とが可能である）によって、修正させることが可能であ
る。

いかなるマイクロプログラムエンジンの場合にもそう
である様に、マイクロ命令デコーダ３が設けられてお
り、それは種々のフィールドのマイクロ命令を認識し且
つこれらのフィールドにおけるビットをこの様なビット
によって制御されるハードウエアへそらさせる。例え
ば、マイクロ命令デコーダは、マイクロ命令のあるフィ
ールドをメインエンジン内に位置されていないチップの
レジスタに対するアドレスとして認識し、その場合に、
それはこれらのビットをアドレスロジック４内へそらさ
せ、それは適宜のレジスタを読取又は書込させる。該チ
ップのレジスタの幾つかのみが物理的にメインエンジン
レジスタファイル５内に位置しており、一方その他は該
チップ上の他の個所にある場合があり、それらはチップ
の内部アドレスバスを介してアクセスされることが必要
であるから、該アドレスロジックが必要である。

ALU6は、他の２つのALUとは異なっている。それは、
基本的な論理的且つ演算命令を実行することが可能であ
り、その結果はフォアグランドアキュムレータ７又はバ
ックグラウンドアキュムレータ８のいずれかにゲート入
力される。或るALU操作はステータスフラッグをセット
させる（例えば、「ゼロフラッグ」はALU操作の結果が
ゼロに等しいことを表す）。これらのステータスフラッ
グは、フォアグラウンドインデックスレジスタ９、又は
バックグラウンドインデックスレジスタ10のいずれかの
中にゲート入力され、爾後のマイクロ命令によってテス
トすることが可能である。上述した特徴は事実上いずれ
のALUにとってもスタンダードである。

然し乍ら、メインエンジンには３つの著しく非スタン
ダードであり且つ全く独特の要素がある。その１つはAL
U自身の中に存在しており、キャラクタ組み立て及び分
解の処理は極めて迅速に行われねばならないという事実
から派生している。OBEからインタラプトを受け取り、
例えば、それが送るべき次のビットを必要とすることを
表す場合、メインエンジンは、OBEがそのビットを特定
したボー速度で送信するのに同期してキャラクタ（ホス
トによって供給）からそのビットを剥離せねばならな
い。同じことが次のビットに対しても言え、且つそのキ
ャラクタの全てのビットが送信される迄、次々のビット
に対して言える。

従って、スタンダードな論理的且つ演算的命令を実行
することに加えて、ALUは、キャラクタ組み立て及び分
解処理の迅速な実行を容易とさせる為に構成された幾つ
かの独特の命令を実行する。これらの独特のマイクロ命
令操作コードに付いては以下に説明する。

第２の独特の特徴は前に説明した良好データインタラ
プト機構であり、それにより、メインエンジン内のファ
ームウエハは、受け取ったビットをキャラクタに組み立
て且つこれらのキャラクタのステータス（良好データ、
パリティエラー等）を決定した後に、１つのキャラクタ
から次のキャラクタへステータス変化があった時を決定
し、且つBIL内にレジスタをセットアップしてホストを
ステータス変化に対してインタラプトさせ、その際にホ
ストから各キャラクタのステータスをチェックするタス
クを解放する。この手順に付いては以下に説明する。

メインエンジンの第３の独特の特徴は、そのインタラ
プト処理器11において使用される機構である。この機構
は、ビットエンジンの１つからインタラプトを受け取る
と（ビットが外部シリアル装置の１つから受け取られた
か又は送信することが必要であることを表す）、文脈RA
M12内に維持されているファームウエアエントリポイン
トを介して、チャンネル番号及びキャラクタ組み立て又
は分解処理の状態を再決定することの必要性無しに、適
宜のファームウエアルーチンを直ぐにアクセスさせる。
このことは、以下に説明する如く、疑似状態マシン及び
インタラプトベクトル化機能によって達成される。

以下に説明するメインエンジンの３つの独特の特徴に
加えて、メインエンジンは、キャラクタ組み立て及び分
解の少なくとも時間的に重要なタスクに対して、主にイ
ンタラプト駆動されることに注意すべきである。インタ
ラプトを実行する場合、メインエンジン（ファームウエ
アによって制御されている）はこれらの時間的に重要な
タスクをフォアグラウンドで実行する（即ち、それは直
ぐにインタラプトに応答する）。これらのタスクは、時
間的に非常に重要なので、ファームウエアのタスクが可
及的に簡単化されたもの（ハードウエアの能力と比較し
て）であることが重要である。例えば、このことが、独
特のキャラクタ組み立て／分解マイクロ命令命令コード
に対する理由である。キャラクタ組み立て及び分解の基
本的なステップを１サイクルで実行することにより、全
処理を比較的迅速に行なうことが可能である。

インタラプトを実行中でない場合、メインエンジン
（未だファームウエア制御下にある）はバックグラウン
ドにおいて時間的により重要性の少ないその他のタスク
を実行する（即ち、インタラプト間において比較的のん
びりとしたペースで）。これらのバックグラウンドタス
クは、それほど時間的に拘束されていないので、一層複
雑なものとすることが可能である。それらは、全キャラ
クタが組み立て中及び分解中の間に（即ち、キャラクタ
時間）、実行することが可能である。

これらのバックグラウンドタスクは、現在の実施例に
おいては、事実上無制限である。ファームウエアは、比
較的汎用のALUを使用して、メインエンジンをして巨大
なアレイのタスクを実行させる。本実施例においてバッ
クグラウンドにおいて実行される主要タスクの１つに付
いては既に言及した。即ち良好データインラプト機構
（以下に説明する）。キャラクタのステータスの決定は
時間的に重要ではないので（それはキャラクタ時間にお
いて実施されることを必要とするのみ）、典型的に500
マイクロ秒未満かかり、このタスクはバックグラウンド
において実行することが可能である。

その他のバックグラウンドタスクは、FIFO及びカウン
タ／タイマーの管理を包含する。例えば、上述した如
く、メインエンジンは、ホストへ転送すべきキャラクタ
の初期数（与えられたインタラプトに対して）をBILの
カウントレジスタ内にロードさせる為の責任がある。別
の例は、組み立てたキャラクタの受け取りデータFIFO内
への格納である。キャラクタが組み立てられ、且つその
ステータスが決定されると、それは受け取りデータFIFO
の次の自由な位置内に格納させねばならない（特定のチ
ャンネルに対して）。

付加的なバックグラウンドタスクは、複雑なプロトコ
ル指向タスクを包含する。例えば、ホストが「Xon/Xof
f」フロー制御（データ転送を停止させ且つ再度開始す
ることを可能とするハンドシェイクプロトコル、例えば
１つの装置のデータバッファが満杯の時）を実行するこ
とを所望する場合、ファームウエアは、インタラプトが
必要な条件のメインエンジンの検知を制御し、次いで適
宜の動作を発生させる。事実上無制限の極めて複雑なプ
ロトコル関連特徴（時に、同期プロトコルに対して）を
本実施例及びその他の実施例において実施することが可
能である。

最後であるが非常に重要な本実施例において実施され
るバックグラウンドタスクは、ホストインタラプト条件
の検知の為の不変のチャンネルのスキャニング（及び、
所望により、モデム信号のステータスにおける変化の検
知）である。上述した如く、メインエンジンファームウ
エアは、何時ホストをインタラプトすることが必要であ
るかを決定する（例えば、伝送データFIFOが空の時）。
ファームウエアは、常に、チャンネルをスキャンし、FI
FOをチェックして、これらの条件のいずれかが充足され
るか否かを決定する。充足する場合、それは適宜のBIL
レジスタをセットアップし（上述した如く）、BILにホ
ストをインタラプトすることの必要性を通知する。

これらのバックグラウンドタスクのどれもが、「ビッ
ト時間」内に実行されることを必要とするものではな
い。従って、それらをバックグラウンドで実行され、一
方メインエンジンはこれらの比較的複雑なタスクを実行
する十分な時間を持っている。メインエンジンの３つの
特に独特の特徴の説明に続いて、典型的なデータ通信セ
ッションの期間中にメインエンジンによって実行される
フォアグラウンド及びバックグラウンドタスクの例であ
る。

良好データインタラプト メインエンジンファームウエアがIBEを介して受け取
ったビットをデータキャラクタに組み立てた後、そのフ
ァームウエアは、この様なデータキャラクタの各々のス
テータスを決定せねばならず、従ってホストはキャラク
タ自身のみならず、そのキャラクタに関してのステータ
ス情報も受け取ることが可能である（例えば、パリティ
エラーがそのキャラクタの伝送中に発生したか否か）。
事実上全てのシリアル制御器は、このタイプのステータ
ス情報をホストへ供給する。

しかし、外部装置から伝送されたデータキャラクタの
多くのはパリティ又はその他の通信エラーを発生するも
のではなく、且つホストがシリアル制御器に検知するこ
とを要求する場合のある数値の特別のキャラクタでもな
いので、極めて大多数のキャラクタに対して、そのキャ
ラクタが「良好データ」であることを決定する為にだけ
全てのキャラクタに対してホストがステータス情報を受
け取り且つ検査することを要求することは極めて非効率
的である。

従って、ホストは受け取ったデータキャラクタのステ
ータスにおける変化を通知するのみであるということは
本発明の顕著な特徴であり、従ってホストは、10個のデ
ータキャラクタの各々の個別的なステータスを受領し且
つチェックすること無しに、これら良好なデータの10個
のキャラクタを転送することの必要性を表すインタラプ
トを受け取るだけである。

この特徴の多様な可能なファームウエア（及びハード
ワイヤーロジック）実施例がある。MCCCOCTARTにおいて
使用される好適実施例は、その基礎となるロジックを第
６図に示してあるが、最初に受領したデータキャラクタ
のステータスのファームウエアによる決定を包含してい
る。このステータスは、３つのカテゴリーの１つの中に
入る場合がある。該キャラクタは、パリティエラー又は
フレーミングエラー等の通信エラーを発生したものかも
知れず、又は該キャラクタは、ホストが、MCCCOCTARTに
検知することを要求した特別のキャラクタの１つである
かも知れず、又はそのキャラクタは単位「良好データ」
であるかも知れない。

その他の実施例において、ホストに各可能なタイプの
ステータス情報に対する異なったインタラプトを供給
し、ホストがその他のいかなるステータスチェック動作
を実行することの必要性を完全に解消することが望まし
い場合がある。然し乍ら、この実施例において、該キャ
ラクタの正確なステータスはそのキャラクタと共に格納
されるが、ユーザは３つの異なったインタラプトの１つ
のみが与えられる。

該ファームウエアは、各ビットが受け取られる毎に受
領中の該キャラクタのステータスを決定する。例えば、
以下に詳細に説明する独特のALU命令コードによって継
続的なパリティチェックが実行される。１つのキャラク
タの全てのビットが受け取られると、蓄積されたパリテ
ィチェックは、そのキャラクタに対してパリティエラー
が発生したか否かに関する情報を有している。フレーミ
ングエラーもこの様にして検知されるが、何等独特のAL
U命令コードの助け無しに該ファームウエア自身によっ
て行なわれる。通信エラーが発生しない場合、該ファー
ムウエアは、該データキャラクタをホストが特定した
「特別」のキャラクタと比較して、受領したキャラクタ
が該特別のキャラクタのいずれかと合致するか否かを決
定する。通信エラーが発生せず、且つ該キャラクタが特
別のキャラクタでないと、該キャラクタは「良好デー
タ」とみなされる。

該ファームウエアが該キャラクタのステータスを決定
した後、それは、勿論、データキャラクタ自身とそれに
関連するステータス情報の両方を受け取りデータFIFO内
に書き込まねばならない。更に、該ファームウエアは、
そのキャラクタのステータスは前のキャラクタのステー
タスと異なっているか否かを決定する。異なっている場
合、該ファームウエアはBILにホストをインタラプトす
ることを通知せねばならず、その前のキャラクタのステ
ータスを表すと共に同一のステータスを持ったその前の
キャラクタ迄の連続的なキャラクタの数を表す。

このタスクを実施する為に、該ファームウエアは、異
なったステータスを持ったキャラクタを受け取る迄（又
はホストが特定したキャラクタのスレッシュホールドを
受け取る迄）、特定のステータスのキャラクタのカウン
トを維持せねばならない。その時点において、該ファー
ムウエアは、チャンネル番号をBILの受け取りインタラ
プトレジスタ内に書き込み且つ「アサート準備完了」フ
ラッグ（前述した如く）をセットせねばならないばかり
か、そのチャンネルに対してカウントレジスタをセット
アップせねばならず（これも前述した）、従ってBILの
インタラプト制御ロジックは、ホストに対して、伝送す
る準備が完了した特定のデータタイプのデータキャラク
タの数を通知することが可能である。次いで、該ファー
ムウエアは、該カウンタを１にリセットし、且つ、前の
キャラクタのステータスからそのステータスが変化した
最も最近に受け取られたキャラクタで開始して、この処
理を繰り返す。

例えば、良好なデータの６個のキャラクタを受け取
り、次にパリティエラーとなる１つのキャラクタが続
き、次いでホストによって検知が要求されていた特別キ
ャラクタが続き、次に更に３個の良好なデータが続くと
仮定する。更に、受け取りデータFIFOが８個のキャラク
タを保持することが可能であるが、ホストがそのスレッ
シュホールドを５にセットするものと仮定する。

該ファームウエアは、「ステータスカウント」をゼロ
に初期化し、且つ「最後のステータスタイプ」を「良好
データ」に初期化し、次いで最初のキャラクタ及びそれ
に関連するステータス情報（「良好データ」）を受け取
りデータFIFO内に格納する（メインエンジンファームウ
エアによって実行される別のバックグラウンドタスクで
ある受け取りデータFIFOのポインターのインクリメント
をしながら）。次いで、該ファームウエアは、該スレッ
シュホールドに到達しておらず且つそのステータスタイ
プは変化していないことを決定する。該ファームウエア
は、次いで、ステータスカウンタを１へインクリメント
する。この同一の処理は、次の４個のキャラクタの各々
に対して継続し、該ステータスカウンタは究極的に５へ
インクリメントされる。

６番目のキャラクタとそのステータス（「パリティエ
ラー」）を格納した後であるが、ステータスカウンタが
６へインクリメントされる前に、該ファームウエアは、
ステータスカウンタがホストが特定したスレッシュホー
ルドと等しいことを決定し且つBILレジスタをセットア
ップして（前述した如く）、BILにホストへの最初のイ
ンタラプトを発生させ、ホストに良好データの５個のキ
ャラクタが受け取りデータFIFOからホストへ転送される
べき準備が完了していることを通知する。次いで、ホス
トは、全て「良好なデータ」であることを知りながら
（各キャラクタのステータスをチェックする必要性無し
に）、適宜にこれら５個のキャラクタを検索することが
可能である。

該ファームウエアは、ステータスカウンタをゼロにリ
セットした後に、６番目のデータキャラクタの処理を継
続する。６番目のデータキャラクタの処理が再開され、
該ファームウエアはステータスタイプは変化しなかった
ことを決定し、次いでステータスカウンタを１へインク
リメントする。然し乍ら、７番目のキャラクタを処理す
ると、該ファームウエアは、スレッシュホールドに到達
していないが、そのステータスタイプは変化された
（「良好なデータ」から「エラー」へ）ことを決定す
る。該ファームウエアは、この新たなステータスタイプ
（この特定の実施例において「エラー」を示すのみ）、
且つBILレジスタをセットアップして、BILをしてホスト
に対して第２インタラプトを発生させ、ホストにステー
タスタイプ「良好データ」（前のキャラクタ）の１個の
キャラクタが受け取られたことを通知する。次いで、該
ファームウエアは、ステータスカウンタをゼロにリセッ
トし、次いでそのステータスカウンタの通常のインクリ
メントを実行する（この場合、ステータスカウンタを１
へインクリメントする）。

次いで、該ファームウエアは、８番目キャラクタ及び
そのステータス情報（「特別」）を受け取りデータFIFO
内に格納する。該ファームウエアは、再度、ステータス
タイプが変化したこと（「エラー」から「特別」へ）を
決定し、且つこの新たなステータスタイプを（この特定
の実施例において「特別」を表すのみ）格納し、且つBI
LレジスタをセットアップしてBILをしてホストへの３番
目のインタラプトを発生し、ホストに、ステータスタイ
プの１つのキャラクタ「エラー」が受け取られたことを
通知する。次いで、該ファームウエアはステータスレジ
スタをゼロにリセットし、次いでそのステータスカウン
トをインクリメントする。注意すべきことであるが、
「エラー」又は「特別」ステータスタイプに対して、ホ
ストは、適切に応答する為に、受け取った通信エラー又
は特別のキャラクタの正確なタイプを決定する為に付加
的な処理（多分、ソフトウエアにおいて、インタラプト
サービスルーチンにおいて）実行することが必要な場合
があるかも知れない。

次いで、該ファームウエアは、９番目のキャラクタ及
びそのステータス情報（「良好データ」）を受け取りデ
ータFIFO内に格納し、再度、そのステータスタイプが変
化（「特別」から「良好データ」へ）したことを決定す
る。該ファームウエアは、この新たなステータスタイプ
（「良好データ」）を格納し、且つBILレジスタをセッ
トアップして、BILをしてホストに対しての４番目のイ
ンタラプトを発生させ、該ホストに対してステータスタ
イプ「特別」の１個のキャラクタが受け取られたことを
通知する。次いで、該ファームウエアは、ステータスカ
ウンタをゼロにリセットし、次いでそのステータスカウ
ンタをインクリメントする。

次いで、該ファームウエアは、10番目のキャラクタ及
びそのステータス情報（「良好データ」）を受け取りデ
ータFIFO内に格納するが、この時は、スレッシュホール
ドに到達しないばかりか、ステータスタイプが「良好デ
ータ」のまま留まることを決定する。従って、該ファー
ムウエアは、単位、ステータスカウンタを２へインクリ
メントし、且つ11番目のキャラクタに対してこの処理を
繰返し行ない、ステータスカウンタを３へインクリメン
トする。究極的に、付加的なキャラクタは、ステータス
タイプの変化となるか、又は「良好データ」キャラクタ
の数がホストが特定したスレッシュホールドと等しくな
い、その時点において別のインタラプトが発生する。

この例において、注意すべきことであるが、11個のキ
ャラクタが受け取られたとしても、ホストは４回インタ
ラプトされたに過ぎない（データステータスタイプにお
ける３つの変化とホストが特定した受け取りFIFOスレッ
シュホールドを超えた場合の１回に対応）。更に、ホス
トは、「良好データ」の９個のキャラクタのステータス
をチェックすること又は転送することは必要ではない。
然し乍ら、「パリティエラー」及び「特別」キャラクタ
を発生したキャラクタは、ホストによる付加的な処理を
必要とする場合がある。然し乍ら、通信エラー及び特別
キャラクタは、あまり頻繁に発生することはなく（「良
好なデータ」と比較して）、且つホストによる特別な処
理を常に必要とする（インタラプトサービスルーチンに
おいて）、従って、この機構は、これらの巨大な大多数
のキャラクタが単に「良好なデータ」であったとして
も、ホストが受け取った全てのデータキャラクタのステ
ータスをチェックすることを必要とする現存するシリア
ル制御器よりも、ホストの処理能力の一層効率的な使用
となる。

状態インタラプト処理 上述した良好データインタラプト機構は、比較的ゆっ
たりとしたペースでメインエンジンのバックグラウンド
ファームウエアルーチンによって実行されるので、メイ
ンエンジンのフォアグラウンドファームウエアルーチン
は、インタラプト駆動を基礎にして非常に時間的に重要
なキャラクタ組み立て及び分解タスクを実行せねばなら
ない。換言すると、I/Oビットエンジンからインタラプ
トを受け取ると、メインエンジンはビット時間における
これらのインタラプトに迅速に応答せねばならない。

この処理の速度を向上させる為の１つの明らかな方法
は、特別なマイクロ命令命令コード（以下に説明する）
を使用することであり、それはキャラクタ組み立て及び
分解の基本的な構成要素ステップの多くを１マシンサイ
クル内において発生することを可能とする。MCCCOCTART
内において使用される付加的な方法は、第５図における
メインエンジンのインタラプト処理器モジュール内に示
した適宜のファームウエアルーチンを迅速に喚起させる
ことである。メインエンジンがI/Oビットエンジンのい
ずれかからインタラプトを受け取ると、この状態インタ
ラプト処理機構は、２つのマシンサイクルにおいて適宜
のファームウエアルーチンの実行を開始する。

上述した如く、I/Oビットエンジンの各々はメインエ
ンジンに対するインタラプトを開始することが可能であ
る。インタラプトが発生されるサイクルの期間中、メイ
ンエンジンのインタラプト処理器11は、最初に、実際の
２つのインタラプトが存在する場合に（IBEから１つとO
BEから１つ）、これら２つのインタラプトの優先度付け
をせねばならず、次いでより高い優先度のインタラプト
を確認せねばならない。この実施例において、IBEイン
タラプトは、OBEインタラプトよりも高い優先度が与え
られている。何故ならば、IBEインタラプト（通常、半
ビット時間）はOBEインタラプト（通常、全ビット時
間）よりも一層頻繁に発生するかたである。

インタラプト処理器は、サンプルビットフラッグ（IB
E）又は出力ビット必要フラッグ（OBE）のいずれかをク
リアすることによってインタラプトを確認する。この確
認を受け取ると、IBE（又はOBE）はチャンネル番号及び
オプションのインターフェースビット（１ビット、即
ち、OBEインタラプトの為に使用されずIBEによってサン
プルされたビット）をインタラプト処理器の文脈レジス
タ13内に駆動する。該インタラプト処理器は、又、文脈
レジスタをT/Rビットでロードし、該インタラプトが伝
送インタラプト（OBE）であるか、又は受け取りインタ
ラプト（IBE）であるかを表す。

文脈レジスタは、インタラプト処理器がI/Oビットエ
ンジンインタラプトをパイプライン動作することを可能
とし、インタラプト処理器が次のインタラプトに対して
のフォアグランドコードに対してベクトル化の処理中に
メインエンジンのフォアグラウンドコードが１つのイン
タラプトに応答する。

インタラプト処理器は、適宜のファームウエアルーチ
ンの開始アドレスを得る為に「文脈」（即ち、チャンネ
ル番号及びT/Rビット）を使用する。上述した如く、全
てのファームウエアルーチンは、その文脈に対する次の
ファームウエアルーチンの開始アドレスでプログラムさ
れている。例えば、ファームウエアルーチンが、有効開
始ビットが検知されることを決定すると、それは、その
文脈に対して次のインタラプトが発生する場合に、通常
のキャラクタビットを処理するファームウエアルーチン
が実行されるべきであることを知得する。従って、全て
のファームウエアルーチンは、制御をリターンする前
に、対応する文脈RAM位置における次の適宜のファーム
ウエアルーチンのエントリイポイントを格納する（その
文脈に対して）。このことは、次のセクションで説明す
る独特の「文脈リターン」マイクロ命令命令コードによ
り達成される。

文脈RAMは、各可能な文脈に対して１ワードのメモリ
を有している、即ちチャンネル及び方向の各組合せに対
して、従って、MCCCOCTART内の文脈RAMは、８個のチャ
ンネルの各々の２つの方向（伝送又は受領）の各々に対
して、16ワードのメモリを有している。文脈RAM内のメ
モリの各ワードは、適宜のファームウエアルーチン（同
一の文脈に対する前に実行したファームウエアルーチン
の「文脈リターン」マイクロ命令により既にロードされ
ている）の開始アドレス（エントリーポイント）を有し
ている。

然し乍ら、注意すべきことであるが、ファームウエア
ルーチンの数は異なった文脈の数に対応しない。従っ
て、文脈RAMにおけるエントリーポイントは、特定の文
脈に関連するファームウエアルーチンに対しての単なる
ベクトルのみならず、むしろ、その文脈の現在の「状
態」をも表すベクトル（例えば、チャンネル５上のキャ
ラクタ組み立ての初期状態で、その場合に、有効開始ビ
ットが検知されたか否かの決定がなされる）を表す。

換言すると、文脈RAMのエントリーは２つの目的を達
成する。即ち、（１）特定の文脈の対する進行における
ファームウエアタスクの現在の「状態」を表す適宜のフ
ァームウエアルーチン（多数の現存するルーチンの中
で）の現在の選択、及び（２）そのファームウエアルー
チンのあ開始位置に対するベクトル、である。

従って、インタラプト処理器がサイクルＮにおいてビ
ットエンジンインタラプトを受け取ると、それは、イン
タラプト（存在する場合）に優先度を付け、より優先度
の高いインタラプトを確認し、文脈をフェッチし、且
つ、Ｎ＋２サイクルにおいて、その文脈をメインエンジ
ンインデックスレジスタ内にロードする（その間に、該
ファームウエアルーチンの最初のマイクロ命令がフェッ
チされる）。従って、I/Oビットエンジンがメインエン
ジンをインタラプトするサイクルに続く２つのマシンサ
イクルで、適宜のファームウエアルーチンの最初のマイ
クロ命令が実行される。

文脈をメインエンジンのインデックスレジスタ内にロ
ードすることによって、フォアグラウンドルーチンは、
チャンネル特定レジスタ及びFIFO位置をアドレスする為
にこの文脈にアクセスすることが可能である。更に、そ
れらは、以下に説明する「ish」マイクロ命令命令コー
ドを介して、インターフェースビットをテストし、又は
それを組み立て中のデータキャラクタ内に付加すること
が可能である。

上述した如く、インタラプト処理器は、「２段階イン
タラプトパイプライン」を維持し、それはファームウエ
ア命令のメインエンジンの実行と同時的に動作する。従
って、ファームウエアインタラプトルーチンがその最初
のフォアグラウンド命令を実行する一方、インタラプト
処理器は次のIBE又はOBEインタラプトを確認する（存在
する場合）。インタラプトルーチンの２番目の命令の期
間中、インタラプト処理器は、２番目のインタラプトル
ーチンの最初の命令をフェッチ動作することをサポート
する準備が完了する。従って、最初のインタラプトルー
チンの２番目の命令が文脈リターン命令である場合、実
行される次の命令は２番目のインタラプトルーチンの最
初の命令である。

従って、メインエンジンは、インタラプト処理機構に
起因して何等実行サイクルを「失う」ことはない。この
機構がI/Oビットエンジンインタラプトを処理するこれ
ら２つのサイクルの期間中、メインエンジンは、並列的
に、バックグラウンドコードを実行するか、又は最初
（少なくとも２つの内の）のフォアグラウンドI/Oビッ
トエンジンインタラプトサービスルーチンを実行してい
る。

キャラクタ組み立て／分解 ビット時間においてキャラクタを組み立て且つ分解す
る為のメインエンジンの能力に対する主要な理由は（フ
ォアグラウンドのインタラプト駆動タスクとして）、１
つのマシンサイクルでキャラクタの組み立て及び分解の
重要な構成要素ステップをALUが実行することを可能と
すべく設計されたカスタム化したマイクロ命令命令コー
ドを使用することである。この様な命令コードは４つあ
り、即ちキャラクタ組み立ての基本的なビットごとのス
テップを実行するもの（「ish」）と、キャラクタ組み
立ての対応するステップを実行するもの（「osh」）
と、パリティをチェックし且つ蓄積し且つブレーク条件
を検知しながら組み立て中のキャラクタ内のビットの現
在の数をカウントする基本的なビット毎のステップを実
行するもの（「bcap」）と、現在の文脈に対して実行さ
れるべき次のファームウエアルーチンのエントリーポイ
ントをその文脈に対応する文脈RAM位置内に書き込むも
の（「文脈リターン」）との４つである。

「ish」命令コードの目的は、それが特定したレジス
タ内において右揃えとなる前、ビット毎にキャラクタを
組み立てることである。その目標は、一般化したタスク
を実行することであり、従って同一の「ish」マイクロ
命令を、最後の繰返しの後に、キャラクタが組み立てら
れ且つ右揃えとされる迄、繰返し使用することが可能で
ある（組み立て中のキャラクタの特定のビット間の区別
をすること無しに）。

マイクロ命令命令コードは、「ish r1,r2」（第7a図
に図示）の形態であり、r2はキャラクタ組み立て用に特
定されたレジスタであり、且つr1は、シフト用情報とし
て使用されるエンコードされたキャラクタ長さ（この実
施例においては５乃至８ビット）を有している。r1レジ
スタは、実際上、以下に説明する「bcap」命令コードに
対して主に使用されるが、その２つの最小桁ビットはこ
の「ish」命令コードの為に使用される。

「ish」命令コードの結果は以下の如くである。r1の
最小桁ビットが「00」であると、そのキャラクタは５ビ
ットの長さである。従って、r2レジスタ（８ビットレジ
スタ）の最小桁５ビットは５ビットシフトレジスタとし
て処理され、一方最大桁３ビットはゼロに設定される。
「ish」命令コードの各実行の期間中、最小桁５ビット
は右へ１ビットシフトされ（最小桁ビットは破壊され
る）、現在の受け取ったビットはALUのインデックスレ
ジスタからr2の５番目の最小桁ビットによって前に占有
されていた位置内に転送される。より桁位置の低いビッ
トは最初に転送され（取り決めによって）、且つ、この
命令を５回繰返し行なった後、データキャラクタを形成
する５個の受け取られたビットは、第7a図に示した如
く、r2レジスタ内において右揃えされる。

６ビット、７ビット、及び８ビットのキャラクタの場
合、該命令は、単に、r2を６ビット、７ビット、又は８
ビットのシフトレジスタとして処理し、且つ、右へ１ビ
ットシフトした後に、現在のビットをr2の６番目、７番
目、又は８番目の最小桁位置内に挿入する。従って、
「ish」命令コードの実行結果は、以下の如くに纏める
ことが可能である（ＩはIBEによって受け取られた現在
のビットであり、且つr1［1:0］はエンコードされたキ
ャラクタ長さを有しており、且つr2［7:0］は組み立て
られ右揃えされたキャラクタを有している）。

「ish」命令コードは、メインエンジンハードウエア
をしてr2の５、６、７、又は８個の最小桁ビットを１ビ
ット右側へシフトさせ（r1を２個の最小桁ビットにおけ
る値に依存して）、その処理中においてr2の最小桁ビッ
トを破壊する。次いで、それはALUのインデックスレジ
スタから現在のビットをフェッチし、且つそれをr2の５
番目、６番目、７番目、又は８番目の最小桁ビット内に
挿入し（該シフトの後に）、r2の３、２、又は１最大桁
ビット内に二進「０」をゲート入力させる。

従って、１マシンサイクルにおいて、「ish」命令
は、キャラクタ組み立ての基本的なステップを実行し、
それは、5,6,7,又は８回繰り返すことにより（即ち、キ
ャラクタの各ビットに対して１度）、組み立てられた且
つr2内において右揃えされたキャラクタが発生される。

「osh」マイクロ命令命令コードは、第7b図に示して
あり、「ish」命令コードに類似しているが、キャラク
タ分解の為のものである。「osh」命令コードの形態
は、「osh r1」であり、その場合、r1レジスタはホスト
プロセサによって送られるキャラクタを有している。メ
インエンジンハードウエアは、単にr1レジスタを１ビッ
ト右へ回転させ、シフト後にr1の最小桁ビット（r1
［０］）をr1の最大桁ビット内に回転入力させるのみな
らず、そのビットを、ビット伝送（以下に説明する）の
サポートにおいてパリティの発生の為の「bcap」命令に
より使用する為に、メインエンジンのインデックスレジ
スタ内に格納する。

従って、「osh」命令は、単に、r1内におけるキャラ
クタの最小桁ビットを分解し、それをインデックスレジ
スタ内に格納し、且つr1を右へ１ビットシフトし、従っ
て「osh」命令の次の実行が該キャラクタの２番目の最
小桁ビットであったものに対して同一の動作を行ない、
且つ、該キャラクタの全てのビットが分解され且つOBE
を介して伝送される為の準備がなされる迄、以下同様に
繰返し行なわれる。

「osh」命令コード（opcode）が該分解したビットを
インデックスレジスタ内に格納し、且つそのビットをr1
の最大桁ビット位置内に回転入力させた後、通常の「ou
td」マイクロ命令はそのビットをr1から内部データバス
を介してOBE出力データ（チャンネルアクセスレジスタ
内のホストによって特定されたチャンネルに対し）へ転
送する。

第7c図に示した「bcap」命令は、３つの著しいタスク
を同一のマシンサイクルにおいて実行する。それは、ビ
ット３のカウントを維持し、該カウントはデクリメント
され、且つそれがゼロに到達すると（キャラクタの全て
のビットが処理されたことを表す）、ALUのインデック
スレジスタ内に「ゼロ」フラッグを設定する（条件付き
分岐マイクロ命令による使用の為、例えば、キャラクタ
全ては組み立てられたか又は分解されたかを知る為にフ
ァームウエアが必要とする時）。

該「bcap」命令は、又、蓄積した「ブレークビット」
を該インデクッスレジスタ内の現在のビットと論理的に
「OR」動作させることにより「ブレーク」条件２（全て
ゼロ）を検知するのみならず、継続的なパリティ発生を
実行し（且つパリティエラーを決定）１する。

「bcap」命令コードの形態は、「bcap r1,r2」であ
り、r1は「オプションレジスタ」４であり、且つr2は
「操作レジスタ」５である。オプションレジスタr1は、
８ビットレジスタであって、その２つの最小桁ビットは
エンコードされたキャラクタ長さ（「ish」命令コード
に関連して既に上述した）を有している。これらのビッ
トは、３番目及び４番目の最小桁ビットと共に、「bca
p」命令コードによって使用されることはない。「bca
p」命令コードは、r1の４個の最大桁ビットを使用し、
それは（最大桁から最小桁へかけて）パリティが奇数で
あるか又は偶数のタイプであるかを表す１ビートと、該
パリティのタイプ（パリティ無しの場合に「00」、強制
パリティに対して「01」［奇数に対して１へ又偶数に対
して０へ強制］、且つ通常パリティに付いて「10］
［「11」は不使用］）を表す２ビットと、パリティを無
視すべき場合に設定される１ビットとを有している。

操作レジスタr2も８ビットレジスタであり、その２つ
の最大桁ビット及び４つの最小桁ビットのみであるが、
それらのビットが使用される。最大桁ビットは、蓄積し
たパリティを表し、次の最大桁ビットは「ブレーク検
知」ビットを表し、且つ４つの最大桁ビットは現在のキ
ャラクタに対して処理されるビットの蓄積した「カウン
ト」を表す。

上述した如く、「カウント」は単にデクリメントされ
且つゼロに対してテストされ、それが、もし真である場
合には、インデックスレジスタ内の「ゼロフラッグ」を
セットさせる。「蓄積パリティ」ビット及びインデック
スレジスタ内の現在のビットは、どのタイプのパリティ
操作がr1内において特定されているかに依存して、新た
な「蓄積パリティ」ビットを決定する為に使用される。
受領したビットの場合、キャラクタの全てのビットが全
て受け取られると、サンプルしたパリティビットを該蓄
積パリティビットに対して比較してパリティエラーが実
際に発生したか否かを決定することが可能である。

「bcap」命令コードの３番目及び最後の操作は、「ブ
レーク」検知を包含する。上述した如く、「ブレーク検
知」ビットと現在のビットとに関して論理「OR」を単純
に実行することにより、キャラクタの全てのビットが処
理された後の「ブレーク検知」ビットの状態は、ブレー
ク条件が満足されたか否かを表す。換言すると、キャラ
クタのいずれかのビットがゼロでない場合、「ブレーク
検知」ビットはそのキャラクタに対してセットされる。
そうでないと、該ビットはゼロのままであり、該ブレー
ク条件が満足されることを表す。「ブレーク検知」ビッ
ト出力は、インデックスレジスタの「ｃ」フラッグへ接
続されており、従ってそれは条件付き分岐及びリターン
マイクロ命令によってテストされ得る。

４番目の独特のマイクロ命令命令コードである「文脈
リターン」命令コードは第7d図に示してあり、それは今
までの説明において何度も出てきた。このマイクロコー
ドが書き込まれると、プログラマーは、現在のルーチン
の完了後に（与えられた文脈に対して）どのルーチンを
実行するかを知っている（多分、与えられたルーチンに
対して複数個の出口がある場合には、条件的に）。従っ
て、「文脈リターン」命令コードは、単に、条件付き又
は条件無しのリターン命令であり、それはスタンダード
のリターン実行を行なうのみならず、その文脈に対応す
る文脈RAM位置内に書き込むべき「文脈リターン」命令
（即ち、その文脈に対応して実行されるべき次のルーチ
ンのエントリイポイント）内に特定されたアドレスをコ
ピーする。

例えば、命令「rxz addr」に対して、ALUはインデッ
クスレジスタ内のゼロフラッグがセットされているか否
かを決定する。決定されておれば、特定されたアドレス
を現在の（既知の）文脈に対応する文脈RAM位置内に書
き込んだ後に、スタンダードなリターンが実行される。
決定されていない場合、そのルーチン内の次のマイクロ
命令の実行は逐次的に継続する。

従って、「文脈リターン」命令コードは「rx add
r」、「rxz addr」、「rxnz addr」、「rxc addr」、
「rxnc addr」、「rxi addr」、又は「rxni addr」の形
態である。該命令コードのこれらの異なった形態は、リ
ターン（及び文脈RAM内へのアドレスの書込）が発生す
るか否かを決定する条件においてのみ異なる。「rx」命
令コードは、無条件リターンである。「rxz」及び「rxn
z」命令コードは、ALUインデックスレジスタ内の「ゼロ
フラッグ」がセットされているか又はセットされていな
いかの条件に従ってリターンする。「rxc」及び「rxn
c」命令コードは、ALUのインデックスレジスタないの
「ｃフラッグ」がセットされているか又はセットされて
いないかの条件に拠ってリターンする。最後に、「rx
i」及び「rxni」命令コードは、ALUのインデックスレジ
スタ内の「ｉフラッグ」がセットされているか又はセッ
トされていないかの条件に拠ってリターンする。

例 MCCCOCTARTの上述した構成要素の一体的な動作は、典
型的な通信セッションの一部の期間中のそれらの動作を
検討することによって良く理解することが可能である。

ホストプロセサが、最初に、種々のパラメータ（例え
ば、キャラクタ毎のビット数、及び所望のボー速度）を
MCCCOCTARTの適宜レジスタ内に書き込むことによって、
使用中の各チャンネルの種々のレジスタを初期化させる
ことによって、通信セッションを開始する。例えば、グ
ローバルチャンネルアクセスレジスタがあり、それに対
して、ホストはコンフィギャー即ち特定の形態に構成す
べきチャンネル（８個の可能なチャンネルの内）の数を
書き込む。そのレジスタを初期化させた後に、ホスト
は、特定のチャンネルを参照する必要性無しに、単にロ
ーカルアドレス動作を使用することが可能である。

従って、チャンネル番号を再度特定する必要性無しに
又種々のボー速度受け取りレジスタ用の１つを超えるア
ドレスを監視する必要性無しに、単にIBE内のボー速度
期間カウントレジスタへ書込を行なうことによって、ボ
ー速度を受け取りデータに対して特定することが可能で
ある。更に、ホストは、パリティオプション、キャラク
タ長さ、及びMCCCOCTARTにより検知されるべき特別のキ
ャラクタ等のパラメータでその他のレジスタを初期化さ
せることが可能である。又、ホストは種々のインタラプ
トモードのいずれかをサポートさせることが可能であり
（MCCCOCTARTがホストをインタラプトする条件を特定す
る為に）、且つデータを伝送又は受け取る為にチャンネ
ルのいずれかを活性化させることが可能である。

実際のデータ転送自身のみならず（例えば、ホストが
特定のチャンネルを介してデータキャラクタを伝送する
場合、又はそのチャンネルからキャラクタを受け取る場
合）この「パラメータ化」の全ては、BILによって制御
される。例えば、MCCCOCTARTのレジスタのいずれかの初
期化させる為にパラメータを送ることをホストが所望す
る場合には、BILのアドレス翻訳ロジックが、ホストに
よって特定されたアドレスを、グローバルアドレス（ホ
ストが特定したアドレスの最大桁ビット上にゼロを付加
することにより）又はローカルアドレス（ホストが特定
したアドレスの最大桁ビット上に既知のチャンネル番号
を付加することにより）のいずれかに翻訳する。このア
ドレス翻訳機構は、前に詳細に説明した。注意すべきこ
とであるが、データ転送の場合、ホストがBILのポイン
ターレジスタをアドレスすると、アドレス翻訳ロジック
はこれらのレジスタを、ポインター及びカウンタ操作ロ
ジック（爾後のキャラクタにアクセスする為）を活性化
するのみならず、データFIFO内へのポインターとして使
用する。

ホストが特定したアドレスを翻訳すると、BILはその
アドレスを内部アドレスバスに沿って送り、適宜のレジ
スタをイネーブルして、ホストによる読取又は書込動作
の開始と共に、内部次いで外部のデータバスを介してデ
ータを送信又は受信する（多分、データバスインターフ
ェースにより、上述した如くそのデータは多少修正され
る）。多分最も顕著ことは、BILが、アドレスポインタ
ーを維持し且つ操作することにより、（上述した）デー
タキャラクタ転送処理を自動化させ、その際にホストプ
ロセサがこのタスクを実行することの必要性を除去して
いることである。

本発明の実施例に戻ると、ホストによってMCCCOCTART
のレジスタがパラメータ化され（且つデータの受領及び
／又は送信の為に１つ又はそれ異常のチャンネルが活性
化された）後に、メインエンジンが文脈RAM（全ての活
性チャンネルに対して）を「スタートビット確認」ファ
ームウエアルーチンの開始アドレスで初期化し、且つゼ
ロサーチを開始させるIBEをイネーブルさせて、活性チ
ャンネルのいずれかにおいてスタートビットの初期端部
を探す。

I/Oビットエンジンの部分において上述した如く、入
力ビットエンジンは、二進「０」がサンプルされる迄、
ｎ番目のサイクル毎に（尚、ｎはチャンネル数）各活性
チャンネルの入力をサンプルし、その時点において、ス
タートビット端部が仮定され、且つIBEがそのボー速度
カウンタを活性化させ、半ビット時間毎にサンプリング
を行なわせる。スタートビット端部がチャンネル１にお
いて検知されたと仮定する。注意すべきことであるが、
IBEは今や文脈を知っており（チャンネル１に沿っての
データの受信）、且つBILのみならずメインエンジンを
イネーブルさせて、その文脈情報をアクセスする。

この時間中に、メインエンジンのファームウエアは、
その時間において適宜のバックグラウンドルーチンを実
行する（例えば、ホストがインタラプトされるべき条件
に対してのスキャニング）。申立られたスタートビット
の中間がサンプルされると、IBEはメインエンジンをイ
ンタラプトし（そのバックグラウンドルーチンの１つの
実行中に）、その時点において、メインエンジンは直ぐ
にこのインタラプトに応答し、上述した状態インタラプ
ト処理機能（既に初期化されたチャンネル１上にデータ
の受領の為の文脈RAMエントリーを具備）を使用して
「スタートビット確認」ルーチンを喚起させる。

次いで、このフォアグラウンドファオムウエアルーチ
ンが、IBEのサンプルデータレジスタ内において得られ
る最初のサンプルしたビットの「中間」を検査する。そ
れが二進「１」である場合、無効スタートビットが検知
され、該ルーチンは、それ自身のスタートアドレスを
「チャンネル１受け取りデータ」文脈に対応する文脈RA
M位置内にロードした後に単純に外部に出る（次のスタ
ートビット端部が見つかり且つ該申立たスタートビット
の中間をサンプルした後にこのルーチンを実行させ
る）。

I/Oビットエンジンの部分において説明した如く、無
効スタートビットの場合、IBEは自動的にゼロサーチモ
ードに復帰し（申立たスタートビット自身の「中間」を
検査した後に）、且つ有効スタートビットの場合には同
期サンプルモードを継続する（ファームウエアが現在の
文脈に対してのボー速度期間延長カウントレジスタを修
正してIBEをして全ビット時間（半ビット時間ではな
い）サンプリングを実行するが）。

然し乍ら、究極的に、サンプルしたビットは二進
「０」であり、有効スタートビットが検知されたことを
表し、且つ該ルーチンは、「オプション」レジスタを初
期化し（ホストが特定したキャラクタ長さ及びパリティ
タイプで）且つ次のルーチン（スタートビットの終端で
喚起される）のエントリイポイントを文脈RAM内に格納
した後に、外部へ出る。注意すべきことであるが、半ビ
ット時間後に（即ち、スタートビットの終端において）
チャンネル１上の次の入力をサンプルする為にIBEは既
にボー速度を再ロードしている。

例えば、このルーチン用のマイクロコードは、以下の
如きものである。

スタートビットの終端をサンプルした後に、IBEは再
度メインエンジンをインタラプトし、その時点におい
て、インタラプト処理器が該ルーチン（そのエントリイ
ポイントは、上述した如く、以前に文脈RAM内にロード
された）を喚起し、それはチャンネル１用のIBEボー速
度延長カウント期間レジスタを修正することにより、半
ビット時間ではなく、全ビット時間においてIBEをして
サンプリングを開始させることにより、スタートビット
の終端を処理する。注意すべきことであるが、この修正
が効果を表す時迄に、IBEはデータキャラクタの最初の
ビットの中間のサンプルを完了している（半ビット時間
で）。然し乍ら、現在のルーチンは、サンプルしたデー
タを無視し（スタートビットの終端において）、且つ
「キャラクタ組み立て」ルーチンのアドレスを文脈RAM
内に格納した後にリターンする。

データキャラクタの最初のビットの中間をサンプルす
ると、IBEは再度メインエンジンをインタラプトし、キ
ャラクタ組み立てルーチンを実行させる。このルーチン
は、その最初のサンプルしたビットを、上述した「is
h」命令を使用して、組み立て中のキャラクタ内に挿入
する。注意すべきことであるが、「ish」命令の繰返し
の実行は、組み立てられたキャラクタを右揃えとさせ
る。次いで、メインエンジンが「bcap」命令を実行し
て、（１）キャラクタカウントをデクリメントして、キ
ャラクタ組み立てが次のビットの後に完了する場合に
「ゼロフラッグ」をセットさせ、（２）継続的パリティ
発生を実行し（従って、キャラクタの終端において、ホ
ストがその様に特定すると、その発生したパリティ値を
受信したパリティビットと比較することが可能であ
る）、且つ（３）各データビットを（キャラクタの全て
のビットが「０」である場合に、「ブレーク」キャラク
タを決定する為に）現在のキャラクタに対する以前の
「OR」の蓄積値と論理的に「OR」動作させることにより
継続的な「ブレーク検知」チェックを実行する。

次いで、このルーチンは、「ゼロフラッグ」をテスト
して、キャラクタ組み立てが次のビットの後に完了する
か否かを決定する。否定の場合には、同一のルーチンの
エントリイポイントを（キャラクタ組み立てを継続する
為に）文脈RAM内に格納した後にリターンする。そうで
ない場合には、このルーチンは、オプションレジスタ
（r1）内の「パリティタイプ」をチェックして、パリテ
ィがこのキャラクタと共に伝送されるか否かを決定す
る。否定の場合には、それは、「パリティ無し最終キャ
ラクタビット」ルーチンのエントリイポイントを文脈RA
M内に格納する。そうでない場合には、それは、「パリ
ティ有り最終キャラクタビット」ルーチンのエントリイ
ポイントを文脈RAM内に格納する。

付加的なルーチンが、パリティ又はフレーミングエラ
ーが発生したか否か、且つ「ブレーク」キャラクタ（全
てゼロ）が受け取られたか否かを決定し、且つ適宜のフ
ラッグをセットする。IBEの制御モードビットを修正し
（スタートビット検知を開始する為に）、組み立てたキ
ャラクタを一時的保持用レジスタ内に格納し、且つキャ
ラクタ組み立てが完了したことを表すフラッグをセット
した後に、「スタートビット確認」ルーチンのエントリ
イポイントを文脈RAM内に格納することによって、本処
理を繰返し行なう。

全てのチャンネルは同様の処理が行なわれ、IBEはメ
インエンジンをインタラプトして、インタラプト処理器
をしてファームウエアフォアグラウンドルーチンを開始
させて、キャラクタを組み立て且つ通信エラーを検知す
る。同様の処理は、OBEを介して伝送されるビットに対
して実行される（但し、「osh」命令はキャラクタ分解
の為に使用され、且つスタート、ストップ及びパリティ
ビットをサンプルし且つ確認する代わりに、これらのビ
ットは単にキャラクタビットと共に伝送される）。

メインエンジンがI/Oビットエンジンインタラプトに
応答してキャラクタを組み立て及び分解していない間、
メインエンジンのファームウエアバックグラウンドルー
チンが実行される。これらのバックグラウンドルーチン
は、例えば、キャラクタ組み立ての完了の検知（時々、
次のキャラクタが受信され且つ組み立てられる前）及び
RAM内の受信データFIFOの次の自由なエリア内への組み
立てたキャラクタの格納等の多様な機能を実行すること
が可能である。その他のルーチンは、受信キャラクタの
ステータスを検査し、且つこのステータス情報をRAM内
の受信データFIFO内に格納する（データ自身とインター
リーブされている）。ホストがその様に特定すると、バ
ックグラウンドルーチンは、受信したキャラクタをホス
トが特定した「特別」キャラクタと比較し、且つそのこ
とをホストに通知する為に付加的なステータスFIFOビッ
トを設定する。

上述した如く、ホストは、MCCCOCTARTがキャラクタを
インタラプトし且つホストに通知する態様を変化させる
場合がある。これらの変化は、実行時にチップへ異なっ
たパラメータ値を書き込むだけでなく、例えば、ホスト
の明細に対する通信処理を著しくカスタム化させる為に
実際にファームウエアルーチンを書き込むことも包含す
る。この様な場合の１例は、「Xon/Xoff」フロー制御の
実行である。MCCCOCTART用に特別に設計すること無し
に、この特徴は単にファームウエアの変化によって付加
させることが可能であり、ホストプロセサから著しい処
理時間を解除させている。本汎用マイクロコードエンジ
ンの柔軟性が著しく高いので、その他の多数の変形例が
存在することは勿論である。

本実施例に戻ると、キャラクタが継続して到着する
と、ホストをインタラプトすることが必要（例えば、伝
送データFIFOが空の場合、又は受信データFIFOスレッシ
ュホールド（ホストによって特定される）に到達した場
合）な時間に到達する。上述した良好データインタラプ
ト機構及びこれも上述したBILの自動化データ転送機構
が役割を果たすのはこの時点である。ホストがインタラ
プトされ且つ特定のステータスタイプのデータがホスト
へ転送される（且つデータがホストから受け取られる）
処理は、既に、良好データインタラプト及び自動化デー
タ転送の部分のいて詳細に説明したの。

以上、本発明の具体的実施の態様に付いて詳細に説明
したが、本発明はこれら具体例にのみ限定されるべきも
のでは無く、本発明の技術的範囲を逸脱すること無しに
種々の変形が可能であることは勿論である。

【図面の簡単な説明】

第1a図及び第1b図は典型的なマルチチャンネルデータ通
信制御器の柔軟性に欠けるアーキテクチャーを示した各
概略図であって、２チャンネル（第1a図）から専用ロジ
ックを繰り返すことによって８チャンネル（第1b図）と
することを示しており、第２図は本発明の好適実施例で
あるMCCCOCTARTの汎用アーキテクチャーを示す概略図、
第3a図はMCCCOCTARTの入力ビットエンジン（IBE）のア
ーキテクチャーを詳細に示した概略図、第3b図はMCCCOC
TARTの出力ビットエンジン（OBE）のアーキテクチャー
を詳細に示した概略図、第４図はMCCCOCTARTのバスイン
ターフェースロジック（BIL）のアーキテクチャーであ
って特に自動化データ転送機能を詳細に示した概略図、
第５図はMCCCOCTARTのメインエンジンモジュールのアー
キテクチャーであって特に状態インタラプト処理機能を
詳細に示した概略図、第６図は良好データインタラプト
機構（ランダムロジックにても実現可能）のファームウ
エア実施例の基礎となるロジックの流れを示した概略
図、第7a図乃至第7d図はMCCCOCTARTのメインエンジンモ
ジュールにおけるALUによって実行されるキャラクタ組
み立て／分解命令コード（「ish」、「osh」、「bca
p」、「context return」）のロジックの流れを示した
各説明図、である。 （符号の説明） 6:タイミングロジック 7:操作制御器 8:インタラプト制御器 9:ボー速度発生器 10:タイミングロジック A:入力ビットエンジン B:メインエンジン C:出力ビットエンジン D:バスインターフェースロジック E:RAMベースFIFO F:モデム制御ロジック

───────────────────────────────────────────────────── フロントページの続き (72)発明者 アンソニー オツール アメリカ合衆国，カリフォルニア 95129，サン ノゼ，コルベット ドラ イブ 1009 (72)発明者 シャヒン ヘダヤット アメリカ合衆国，カリフォルニア 94566，プリザントン，フェアランズ ドライブ 4318 (72)発明者 シュリカント アチャーヤ アメリカ合衆国，カリフォルニア 94539，フリモント，フェルナルド コ モン 46894 (56)参考文献 特開 昭61−288246（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁶，ＤＢ名) H04L 29/02

Claims (12)

(57)【特許請求の範囲】
1. 【請求項１】ホストプロセサ等の計算装置と１組の外部
   装置等の１つ又はそれ以上の計算装置との間の通信イン
   ターフェースとして機能する装置において、１つ又はそ
   れ以上のビットのデータを有する複数個のデータキャラ
   クタを格納する手段を具備する格納エリア、前記格納エ
   リアから前記ホストプロセサへ前記データキャラクタを
   伝送する手段、前記ホストプロセサから前記データキャ
   ラクタを受け取り且つ前記データキャラクタを前記格納
   エリア内に格納する手段、複数個の外部装置から単位時
   間当たり１つ又はそれ以上のビットのデータを受け取る
   手段、複数個の外部装置へ単位時間当たり１つ又はそれ
   以上のビットのデータを送る手段、前記１つ又はそれ以
   上のビットのデータを受け取る手段によって受け取られ
   た前記１つ又はそれ以上のビットのデータをデータキャ
   ラクタに組み立てる手段、前記組み立てたデータキャラ
   クタを前記格納エリア内に格納する手段、前記ホストプ
   ロセサから前記データキャラクタを受け取る手段によっ
   て受け取られ且つ前記格納エリア内に格納されたデータ
   キャラクタを前記１つ又はそれ以上のビットのデータを
   送る手段によって前記１つ又はそれ以上の外部装置へ送
   るべき１つ又はそれ以上のビットのデータに分解する手
   段、本装置がデータキャラクタを組み立て且つ分解する
   ステップを修正する手段を具備しており本装置のプログ
   ラムを行なう手段、を有することを特徴とする装置。
2. 【請求項２】特許請求の範囲第１項において、外部装置
   から受け取られたデータキャラクタに関する複数個のタ
   イプのステータス情報の任意の１つを認識する手段、最
   も最近に受け取ったデータキャラクタが次前に受け取っ
   たデータキャラクタと異なったタイプのものである場合
   に第１信号を発生する手段、前記第１信号に応答し且つ
   最も最近に受け取ったデータキャラクタがその直前の１
   つ又はそれ以上のデータキャラクタの前のタイプと異な
   るタイプのものであることを前記ホストプロセサへ通知
   する手段、を有することを特徴とする装置。
3. 【請求項３】特許請求の範囲第１項において、前記デー
   タキャラクタを前記ホストプロセサへ伝送する手段、及
   び前記ホストプロセサからデータキャラクタを受け取る
   手段とが、前記データキャラクタが前記ホストプロセサ
   へ伝送されるか又はそれから受け取られる前記格納エリ
   アにおける位置を前記ホストプロセサから受け取ること
   無しにその位置をアクセスする手段を有していることを
   特徴とする装置。
4. 【請求項４】特許請求の範囲第１項において、前記デー
   タキャラクタを組み立て且つ分解する手段が、各々が本
   装置に対して特定の機能を実行することを支持する複数
   個の制御信号を具備する複数個の制御ワードを有する制
   御格納エリア、各々が前記制御ワードの予め定義された
   シーケンスの第１制御ワードの前記制御格納エリアにお
   ける位置を具備する複数個のベクトルを有する文脈格納
   エリア、特定した順序で制御ワードのシーケンスを実行
   する手段、を有する装置であって、且つ、前記実行する
   手段が、データキャラクタを１つ又はそれ以上のビット
   のデータへ分解し且つ前記１つ又はそれ以上のビットの
   データを前記外部装置の１つへ伝送した後にどの外部装
   置へ前記１つ又はそれ以上のビットのデータが伝送され
   たかを決定する手段と、１つ又はそれ以上のビットのデ
   ータが前記外部装置の１つから受け取られ且つ前記１つ
   又はそれ以上のビットのデータがデータキャラクタに組
   み立てられた後にどの外部装置から前記１つ又はそれ以
   上のビットのデータが受け取られたかを決定する手段
   と、前記１つ又はそれ以上のビットのデータが伝送され
   たか又は受け取られた前記外部装置に対応するベクトル
   を決定し且つ前記シーケンスの第１制御ワードへアクセ
   スする為に前記ベクトルを使用する手段と、前記制御ワ
   ードによって本装置に特定の機能を実行させることによ
   り前記第１制御ワード次いで前記シーケンスにおける爾
   後の制御ワードを実行する手段と、以前に前記シーケン
   スの前記第１制御ワードの位置を有していた前記ベクト
   ルを修正し前記ベクトルをして前記１つ又はそれ以上の
   ビットのデータが伝送されたか又は受け取られた前記外
   部装置に対応する異なったシーケンスの制御ワードの前
   記第１制御ワードの位置を有さしめる手段と、を有する
   ことを特徴とする装置。
5. 【請求項５】特許請求の範囲第１項において、それによ
   り本装置が１つ又はそれ以上のビットのデータをデータ
   キャラクタに組み立てる前記手段が、制御ワードを実行
   する手段を有しており、前記制御ワードは、ｎを組み立
   てるべき前記キャラクタにおけるビット総数としそれが
   ｎ回繰り返された場合にその組み立てられたｎビットキ
   ャラクタをデータ格納装置内に右揃えで格納させる機能
   を本装置に実行させる複数個の制御信号を有しており、
   前記機能は、組み立てられる前記キャラクタにおけるビ
   ットの総数であるｎを決定する為に前記制御ワードの第
   １部分を使用し、前記キャラクタが組み立てられている
   データ格納装置を識別する為に前記制御ワードの第２部
   分を使用し、前記データ格納装置のｎ個の最下位ビット
   を１ビット右へシフトさせ、外部装置から受け取られた
   現在のビットを前記データ格納装置のｎ番目の最下位ビ
   ットとして組み立て中のキャラクタ内へ挿入し、前記現
   在のビットよりもより上位の前記データ格納装置の各ビ
   ット内にゼロを挿入する、上記各ステップを有すること
   を特徴とする装置。
6. 【請求項６】特許請求の範囲第１項において、それによ
   って本装置がデータキャラクタを１つ又はそれ以上のビ
   ットのデータへ分解する前記手段が、制御ワードを実行
   する手段を有しており、前記制御ワードは、本装置をし
   て前記キャラクタが組み立てられる第１データ格納装置
   を識別する為に前記制御ワードの一部を使用し且つ前記
   第１データ格納装置のビットをシフトさせる複数個の制
   御信号と、前記１つ又はそれ以上のビットを伝送する前
   記手段によって前記外部装置の１つへ伝送すべき前記第
   １データ格納装置の前記最小桁ビットを前記シフトの前
   に格納する手段とを有することを特徴とする装置。
7. 【請求項７】特許請求の範囲第１項において、それによ
   り本装置が１つ又はそれ以上のビットのデータをデータ
   キャラクタに組み立てる前記手段が、制御ワードを実行
   する手段を有しており、前記制御ワードは、ｎを前記組
   み立て中のキャラクタにおけるビット総数として、ｎ回
   繰り返された場合に、組み立てられたｎビットキャラク
   タに関する最終機能の実行となる中間機能を本装置に実
   行させる複数個の制御信号を有しており、前記中間機能
   は、前記既に受け取ったキャラクタに基づいて組み立て
   中のキャラクタの蓄積したパリティエラーチェックステ
   ータスの決定、前記既に受け取ったキャラクタのビット
   に基づいて組み立て中のキャラクタの蓄積したブレーク
   条件ステータスの決定、及び前記入力データモジュール
   により既に受け取られた前記組み立て中のキャラクタの
   現在のビット数の決定、を有しており、且つ前記最終機
   能が、前記組み立てたキャラクタのパリティエラーチェ
   ックステータスの決定、前記組み立てたキャラクタのブ
   レーク条件ステータスの決定、及び前記組み立てたキャ
   ラクタのビット総数の決定、を有することを特徴とする
   装置。
8. 【請求項８】特許請求の範囲第４項において、前記デー
   タキャラクタを伝送するか又は受け取った前記外部装置
   に対応する次のシーケンスの制御ワードの前記第１制御
   ワードの位置を前記ベクトルに有させる前記ベクトルを
   修正する手段が、制御ワードを実行する手段を有してお
   り、前記制御ワードが前記中央処理モジュールをして前
   記ベクトルをその様に修正させる複数個の制御信号を有
   することを特徴とする装置。
9. 【請求項９】各々が本装置をして特定の機能を実行させ
   る複数個の制御信号を具備する複数個の制御ワードを有
   する制御格納エリア、各々が前記制御ワードの予め定義
   したシーケンスの第１制御ワードの前記制御格納エリア
   における位置を具備する複数個のベクトルを有する文脈
   格納エリア、各々が１つ又はそれ以上のビットのデータ
   を有するデータキャラクタ、前記データキャラクタを１
   つ又はそれ以上のビットのデータへ分解し且つ前記ビッ
   トのデータを１つ又はそれ以上の外部装置へ伝送する手
   段、複数個の外部装置からデータビットを受け取る手
   段、前記データビットをデータキャラクタに組み立てる
   手段、制御ワードのシーケンスを特定した順序で実行す
   る手段、を有する装置において、前記実行する手段が、
   データキャラクタを１つ又はそれ以上のビットのデータ
   に分解し且つ前記１つ又はそれ以上のビットのデータを
   前記外部装置の１つへ伝送した後に前記１つ又はそれ以
   上のビットのデータが伝送された外部装置を決定する手
   段と、前記外部装置の１つから１つ又はそれ以上のビッ
   トのデータが受け取られ且つ前記１つ又はそれ以上のビ
   ットのデータがデータキャラクタに組み立てられた後に
   どの外部装置から前記１つ又はそれ以上のビットのデー
   タを受け取ったかを決定する手段と、前記１つ又はそれ
   以上のビットのデータが伝送されたか又は受け取られた
   前記外部装置に対応するベクトルを決定し且つ前記シー
   ケンスの第１制御ワードにアクセスする為に前記ベクト
   ルを使用する手段と、前記制御ワードにより本装置が特
   定の機能を実行させることにより前記第１制御ワード次
   いで前記シーケンスにおける爾後の制御ワードを実行す
   る手段と、以前に前記シーケンスの前記第１制御ワード
   の位置を有しており前記ベクトルをして前記１つ又はそ
   れ以上のビットのデータが伝送されたか又は受け取られ
   た前記外部装置に対応する制御ワードの異なったシーケ
   ンスの前記第１制御ワードの位置を有さしめる前記ベク
   トルを修正する手段とを有することを特徴とする装置。
10. 【請求項１０】各々が１つ又はそれ以上のビットのデー
    タを有するデータキャラクタ、複数個の外部装置からデ
    ータビットを受け取る手段、及び、制御ワードを実行す
    ることにより前記受け取ったデータビットをデータキャ
    ラクタに組み立てる手段、を有する装置において、前記
    制御ワードは、ｎを組み立て中のデータキャラクタにお
    けるビットの総数として、ｎ回繰返し行なわれた場合
    に、組み立てられたｎビットキャラクタをデータ格納装
    置内に右揃えさせる機能を本装置に実行させる複数個の
    制御信号を有しており、前記機能は、前記組み立て中の
    キャラクタにおけるビット総数ｎを決定する為に前記制
    御ワードの第１部分を使用し、前記キャラクタが組み立
    て中のデータ格納装置を識別する為に前記制御ワードの
    第２部分を使用し、前記データ格納装置のｎ個の最小桁
    ビットを右へ１ビットシフトさせ、外部装置から受け取
    った現在のビットを前記データ格納装置のｎ番目の最小
    桁ビットとして組み立て中のキャラクタ内に挿入し、前
    記現在のビットよりも一層桁位置の高い前記データ格納
    装置の各ビット内にゼロを挿入する、上記各ステップを
    有することを特徴とする装置。
11. 【請求項１１】各々が１つ又はそれ以上のビットのデー
    タを有するデータキャラクタ、データビットを複数個の
    外部装置へ伝送する手段、制御ワードを実行することに
    より１つ又はそれ以上の外部装置へ伝送する為にデータ
    キャラクタをデータビットへ分解する手段、を有する装
    置において、前記制御ワードが、前記キャラクタが組み
    立てられる第１データ格納装置を識別する為に本装置を
    して前記制御ワードの一部を使用させ且つ前記第１デー
    タ格納装置のビットをシフトさせる複数個の制御信号
    と、前記１つ又はそれ以上のビットを伝送する手段によ
    り前記外部装置の１つへ伝送すべき前記第１データ格納
    装置の前記最小桁ビットを前記シフトの前に格納する手
    段と、を有することを特徴とする装置。
12. 【請求項１２】各々が１つ又はそれ以上のビットのデー
    タを有するデータキャラクタ、複数個の外部装置からデ
    ータビットを受け取る手段、制御ワードを実行すること
    により前記データビットをデータキャラクタに組み立て
    る手段、を有する装置において、前記制御ワードが、ｎ
    を組み立て中の前記キャラクタにおけるビット総数とし
    て、ｎ回繰返し行なわれた場合に、組み立てたｎビット
    キャラクタに関する最終機能の実行となる中間機能を本
    装置に実行させる複数個の制御信号を有しており、前記
    中間機能が、前記既に受け取られたキャラクタのビット
    に基づいて組み立て中のキャラクタを蓄積したパリティ
    エラーチェックステータスの決定、前記既に受け取った
    キャラクタのビットに基づいて組み立て中のキャラクタ
    の蓄積したブレーク条件ステータスの決定、及び既に受
    け取った組み立て中のキャラクタの現在のビット数の決
    定、を有しており、且つ前記最終機能が、前記組み立て
    たキャラクタのパリティエラーチェックステータスの決
    定、前記組み立てたキャラクタのブレーク条件ステータ
    スの決定、及び前記組み立てたキャラクタのビット総数
    の決定、を有することを特徴とする装置。