(57)【特許請求の範囲】
【請求項１】
単一の半導体チップ上に集積された画像圧縮コプロセッサ（４１０）において、
記憶されたプログラムに応じて前記コプロセッサを動作させる制御ユニット手段（４１８）を備え、
前記制御ユニット手段に結合された内部グローバル・バス（４１６）に結合された複数の専用処理手段（４２０−４３２）を備え、前記専用処理手段のそれぞれは、画像圧縮／圧縮解除プロセス中にステップ群のサブセットを実行すものであり、
前記制御ユニット手段は、実行用の命令及びデータを、前記専用処理手段に対して及び前記専用処理手段から、前記内部グローバル・バスを介して並列に非同期で転送するように構成され、
前記制御ユニット手段は、外部ホスト・プロセッサからロードされたデータ・フロー・プログラムを保持する命令メモリ（８２４）を含み、前記データ・フロー・プログラムの命令をデータ駆動手法で実行させる更新ユニット手段（８１２）とを備えており、前記制御ユニット手段によりデータ・トークンが前記内部グローバル・バスを介して前記複数の専用処理手段へ転送され、前記命令は、前記専用処理手段に対する前記データ・トークンとは別に、パケットで前記複数の専用処理手段に転送される
ことを特徴とする画像圧縮コプロセッサ。
【請求項２】
請求項１に記載の画像圧縮コプロセッサにおいて、前記各専用処理手段が異なる専用ハードウェアを有する、ことを特徴とする画像圧縮コプロセッサ。
【請求項３】
請求項１に記載の画像圧縮コプロセッサにおいて、前記各データ・トークンにはさらに、
データ・トークンであることを示し、接続されたデータ・ブロックの数を示すトークン記述子が含まれている
ことを特徴とする画像圧縮コプロセッサ。
【請求項４】
請求項１に記載の画像圧縮コプロセッサにおいて、
前記外部ホスト・プロセッサに結合されるホスト・インタフェース・ユニット（４１２）と、
前記内部グローバル・バスと前記ホスト・インタフェース・ユニットとの間に接続されていて、前記外部ホスト・プロセッサと通信できるようにデータを内部データ・トークン・フォーマットと外部ラン・レングス・フォーマットとの間でデータ・フォーマットを変換するラン・レングス・プロセッサ手段（４２６）と
をさらに備える、ことを特徴とする画像圧縮コプロセッサ。
【請求項５】
請求項１に記載の画像圧縮コプロセッサにおいて、
前記外部ホスト・プロセッサに結合されるホスト・インタフェース・ユニット（４１２）と、
前記内部グローバル・バスと前記ホスト・インタフェース・ユニットとの間に接続されていて、前記ホスト・プロセッサがトークンを直接挿入し前記バス上のトークンを見ることができるようにするトークン・インタフェース手段（４２８）と
を備える、ことを特徴とする画像圧縮コプロセッサ。
【請求項６】
請求項１に記載の画像圧縮コプロセッサにおいて、
前記内部グローバル・バスを外部ビデオ・メモリに結合するビデオ・インタフェース・ユニット（４１４）と、
前記内部グローバル・バスをランレングス・プロセッサ・ユニット（４２６）を介して外部ホスト・プロセッサに結合するプロセッサ・インタフェース・ユニット（４１２）とを備える、ことを特徴とする画像圧縮コプロセッサ。
【請求項７】
請求項１に記載の画像圧縮コプロセッサにおいて、前記制御ユニット手段には、
前記内部グローバル・バスに結合されていて、前記制御ユニット手段と前記複数の専用処理手段の間での前記バスの使用を調停するバス調停手段（１３１０）が備えられていることを特徴とする画像圧縮コプロセッサ。
【請求項８】
請求項１に記載の画像圧縮コプロセッサにおいて、さらに、
前記制御ユニット手段に結合されたセマフォ・レジスタ（１１１７）と、
数を含む制御フィールドを有する前記データ・フロー・プログラム中の複数の命令と、
命令中の前記制御フィールド中の前記数を前記セマフォ・レジスタ中のカウントと比較し、前記数が前記カウントに一致するときに、前記命令を、処理するために前記制御ユニット手段を通過させる手段（１１１３）と
を備えることを特徴とする画像圧縮コプロセッサ。
【請求項９】
請求項８に記載の画像圧縮コプロセッサにおいて、
前記制御フィールド中の前記数が、シーケンス中の１つの数であり、
前記コプロセッサがさらに、一度に１つの命令しか通過できないように前記セマフォ・レジスタ中の前記カウントを修正する手段（１１１３）を備えている
ことを特徴とする画像圧縮コプロセッサ。
【請求項１０】
請求項１に記載の画像圧縮コプロセッサにおいて、前記制御ユニットには、
前記内部のバスに結合された内部バス・インタフェース（８１６）と、
前記専用処理手段に転送すべき命令を保持するために前記内部バス・インタフェースに結合されたイネーブル済み命令待ち行列手段（８１４）と、
前記内部バス・インタフェースに結合されたデータ・トークン・メモリ（８１０）と、
前記イネーブル済み命令待ち行列手段に結合されていて、前記イネーブル済み命令待ち行列手段に命令を提供する更新ユニット手段（８１２）と
が備えられている、ことを特徴とする画像圧縮コプロセッサ。
【請求項１１】
請求項１０に記載の画像圧縮コプロセッサにおいて、前記更新ユニット手段には、
前記イネーブル済み命令待ち行列手段中に命令があるかどうかを判定する第１の判定手段と、
前記命令に関するデータ・トークンが前記データ・トークン・メモリ中にあるかどうかを判定する第２の判定手段と、
前記命令に必要とされる前記専用処理手段の１つがビジー状態であるかどうかを判定する第３の判定手段と、
前記第１、第２、第３の判定手段に応答して、前記イネーブル済み命令待ち行列手段に前記命令を提供する手段とを備えることを特徴とする画像圧縮コプロセッサ。
【請求項１２】
請求項１０に記載の画像圧縮コプロセッサにおいて、さらに、
前記イネーブル済み命令待ち行列手段が満杯であるかどうかを判定する第４の判定手段を備えることを特徴とする画像圧縮コプロセッサ。
【発明の詳細な説明】
本出願は、１９９３年４月２７日に出願された米国特許出願第０８／０５４９５０号の一部継続出願である。
付録Ｉには、本発明のコプロセッサが使用する命令の説明が記載されている。
発明の背景
本発明は、専用画像圧縮コプロセッサに関する。
データ圧縮は、送信し記憶する必要があるデータの量を減少させるために使用される。多数のデータ圧縮タイプがあり、簡単なタイプとしてラン・レングス圧縮がある。ラン・レングス圧縮では、たとえば１行で２５個のディジタル１を送信するのではなく、２５個のディジタル１があることを示す符号と共に単一の１が送信される。これは、データが失われない無損失圧縮方法である。一方、「有損失」方法では、精度または分解能のビット数を減少させることなど異なる技法によって、無損失圧縮方法よりもはるかにデータを圧縮する。
画像において、画素アレイは、各画素ごとに１つまたは複数のディジタル値を備える。グレイ・スケール画像では、ディジタル画素値は、そのグレイネス・レベルを示す。たとえば、０が白であってよく、２５５が黒であってよい。カラー画像では、それぞれ、ＲＧＢシステムの赤成分、青成分、および緑成分（あるいはＹＵＶシステムの３つの成分）を示す、３つの異なる値を使用することができる。データを圧縮する１つの方法は、２５６個の可能な変形例を表す８ビットの代わりに最上位４ビットが使用されるように、単に画素の各成分ごとに分解能ビット数を減少させることである。しかし、この方法では、他の方法よりも画質が低下する。大部分の画像圧縮方法では、画像の十分に小さな部分を削除した場合、大部分の例で色は不変であり、あるいは、緩やかに変動することが分かっている。したがって、多数の画像圧縮方式は、平均強度または平均色、あるいは主強度または主色を識別し、次いで、この色からの変動を識別することに焦点を当てている。平均色または主色に高分解能を使用することによって、その色からの変動により低い分解能を使用することができる。
画像データ圧縮に関していくつかの規格が作成された。ＪＰＥＧ（JointPhotography Experts Group）規格は静止画像用に使用されている。ＭＰＥＧ（Motion Picture Experts Group）およびＰｘ６４は、フルモーション・ビデオ用に使用されている。Ｐｘ６４は、ＣＣＩＴＴ（国際電信電話諮問委員会）ではＨ．２６１とも呼ばれている。
ある上述の圧縮プロセスがどのように働くかの一例を簡単に説明すると、本発明を理解するうえで有用である。第１Ａ図は、ＪＰＥＧ規格を示す図である。ソース画像は、一辺が８画素のブロック、またはブロック当たり合計６４画素に分割される。各画素は、グレイ・スケールでは０ないし２５５の単一のディジタル値で表され、ＲＧＢカラー・イメージまたはＹＵＶカラー・イメージでは３つの異なる値で表される。６４個の値に対して二次元離散余弦変換（ＤＣＴ）が実行される。ＤＣＴとは、各成分周期波形ごとに異なる係数または乗数を有するいくつかの異なる周期波形を加算することによって任意の波形を近似するために使用される技法である。８×８画素ブロック中の点のプロッティングは、時間によって変化する通常の波形ではなく空間の変動または空間周波数の波形表現である。変換の最終結果は、主色を表すＤＣ値と、そのＤＣ値からの変動を表すいくつかの係数である。この結果得られるＤＣ係数およびＡＣ係数はブロック１２として記憶され、左上の値が各ブロックごとのＤＣ値である。画素が調べられる順序は、行ごとではなくジグザグ・パターン１４であってよい。このジグザグ・パターンは、色の変動をより円滑にするはずである。
第１Ｂ図は、ＪＰＥＧ圧縮に関するデータ・フローである。入力画像データはまず、オフセット論理ブロック２０でオフセットされる。このオフセットは、図の例では１２８であり、範囲が通常０ないし２５５であるので、０の周りにデータをセンタリングする効果を有する。これは、ＤＣ成分の値を減少させ、したがって、ＤＣ成分を表すのに必要なビット数を減少させる。次いで、データが順ＤＣＴ（ＦＤＣＴ）論理ブロック２２を通過して、離散余弦変換ＤＣおよび複数の処理装置係数および離散余弦変換ＡＣ係数が生成される。これらの係数は次いで順量子化論理ブロック２４で量子化テーブル２６の制御の下で量子化される。この量子化は基本的に丸め関数であり、各係数を表すのに必要なビット数を制限する。次いで、論理ブロック２８で、ＡＣ係数が上述のラン・レングス符号化方式に類似のラン・レングス符号化方式で符号化される。
差分符号化論理ブロック３０でＤＣ成分が符号化される。第１のＤＣ値は絶対値で表されるが、その後の論理ブロックでの残りのＤＣ値は、その第１の値からの差分として符号化され、この場合も、ＤＣ値を表すのに必要なビット数が制限される。最後に、ハフマン符号化器３２を介してデータが処理される。ハフマン符号化とは、ＪＰＥＧ規格で指定された方法のうちの１つであり、エントロピー符号化の一形態である。ハフマン符号化では基本的に、ある種のデータ・パターンの代わりにテーブル中のいくつかの符号のうちの１つを使用することによってディジタル・データが圧縮される。
第１Ｃ図は、圧縮済みデータの復号に関する第１Ｂ図を逆にした図を示す。すべての論理ブロックは基本的に、第１Ｂ図に記載された論理ブロックを逆にしたものである。これらの論理ブロックは、ハフマン符号化器４０、ラン・復号化４２、差分復号化４４、量子化テーブル４８を有する逆量子化論理ブロック４６、逆ＤＣＴ論理ブロック５０、およびオフセット論理ブロック５２である。
データ圧縮および圧縮解除は従来、１つの方法または２つの異なる方法で行われている。第１は、第１Ｂ図および第１Ｃ図に示したデータ・フローに必要な所望のタスクを実行するように一般的なマイクロプロセッサをプログラムすることである。このプログラム可能性によって、ハードウェアの融通性が向上するが、同時に、圧縮および圧縮解除が非常に低速になることは明らかである。第２は、特定のフロー経路を実施するように専用ハードウェアを設計することである。この専用ハードウェアは、より高速になるが、融通性が制限されることは明らかである。ＬＳＩロジック社（ＬＳＩ  Ｌｏｇｉｃ）とＳＧＳトンプソン社（ＳＧＳ  Ｔｈｏｍｐｓｏｎ）は共に、画像圧縮／圧縮解除システムに使用できるビルディング・ブロックを含むチップ・セットを販売している。このチップには、ＤＣＴプロセッサ、符号化／復号化、ＤＣＴ量子化プロセッサ、ＣＣＩＴＴ可変長復号化などが含まれる。
他の手法では、いくつかの会社が、データ圧縮／圧縮解除向けに最適化された専用コプロセッサを生産している。Ｃキューブ社（Ｃ−Ｃｕｂｅ）は、製品部品番号ＣＬ５５０、すなわち、ＪＰＥＧ画像圧縮プロセッサを発表した。このプロセッサは、ＪＰＥＧ規格向けに最適化されている。ゾラン社（Ｚｏｒａｎ）もそのようなコプロセッサを発表した。
本発明は、データ・フロー技法にも関する。ＮＥＣは、データ・フロー技法を実施する画像コプロセッサを導入した。標準マイクロプロセッサでは、ジャンプがない限り、順次実行によって、プログラム命令が一度に１つずつ実行され、プログラム・カウンタがインラインで次の命令を指し示す。
一方、データ・フロー・プロセッサには、標準プログラム・カウンタ概念はない。その代わり、一連の命令が記憶され、各命令の実行タイミングは、そのデータの準備がいつ完了するかによって決定される。データ・フロー・プログラムの説明は、ジャックＢ．デニス（Ｊａｃｋ  Ｂ．Ｄｅｎｎｉｓ）著"Data Flow Super Computers"Computer Magazine, １９８０年１１月，４８ページないし５６ページに記載されている。この論文は、マルチプロセッサ・アーキテクチャにデータ・フロー技法を使用することを提案している。基本命令実行機構は、第１０図に記載されており、円形パイプラインを有する。命令待ち行列が、実行の準備が完了した命令を保持し、取出し装置が、これらの命令をパケットの形で実際の演算装置上に渡す。演算装置は、データ・トークンも受信する。この結果得られるパケットは、完成後、命令用の活動ストアに戻され、追加データのためにある命令を繰り返す場合、前記活動ストアからその命令を再び選択することができる。ＮＥＣ画像コプロセッサは、そのような円形パイプラインを使用している。
発明の概要
本発明は、単一のチップ上で集積された画像圧縮／圧縮解除コプロセッサを提供するものである。このコプロセッサは、内部グローバル・バスによっていくつかの異なる処理装置に接続された制御装置を有する。各処理装置は、圧縮プロセスおよび圧縮解除プロセス中のあるステップしか処理しない。
本発明は、圧縮プロセスおよび圧縮解除プロセスの実行速度を増加させるように専用ハードウェアと並行処理を共用できるようにするネットワーク状アーキテクチャを単一のチップ上で実施する。本発明は、トークンを内部グローバル・バスを介して様々な専用処理装置へ送信するデータ・フロー型制御装置で実施することが好ましい。
一実施形態では、このコプロセッサは、別々のホスト・インタフェースとビデオ・メモリ・インタフェースとを有する。ホスト・インタフェースは、内部バス上で使用されるトークンと、ホストに送信されるラン・レングス・データの間の変換を行う。ビデオ・インタフェースは、トークンとビデオ・データ・フォーマットの間の変換を行う。内部グローバル・バスの使用は、制御装置中の調停回路によって調停される。
一実施形態では、好ましくは、演算プロセッサと、量子化プロセッサと、ＤＣＴプロセッサとを含む専用処理装置が使用される。データ・フロー制御技法を使用することによって、トークンを送信し、個別の処理装置によって並列処理することができる。専用処理装置を使用することによって、高速に動作できない単一の円形パイプラインを使用する従来技術、または専用でないためにやはり高速に動作できないいくつかの同じ並列プロセッサを使用する従来技術が改良される。
本発明は、データ・フロー実施態様では、制御トークンとデータ・トークンとを含むユニークなトークンを使用する。データ・トークンは、単一のトークン中に大きなデータ・ブロックを含むことができる。内部バスは、外部インタフェース・バスよりもずっと大きく、したがって、コプロセッサ・チップ上の装置間で一度により多くの量のデータを送信することができる。
本発明の性質および利点をより完全に理解するために、添付の図面と共に以下の詳細な説明を参照されたい。
【図面の簡単な説明】
第１Ａ図は、ＪＰＥＧ規格に従ったデータ・ブロックの図である。
第１Ｂ図は、符号化に関するＪＰＥＧデータ・フローの図である。
第１Ｃ図は、復号化に関するＪＰＥＧデータ・フローの図である。
第２図は、本発明を使用する画像圧縮システムのブロック図である。
第３Ａ図は、オペランドＲＡＭの図である。
第３Ｂ図は、結果パケットの図である。
第３Ｃ図は、イネーブル済み命令パケットの図である。
第３Ｄ図は、トークン・アドレス・メモリの図である。
第３Ｅ図は、プロセッサ・パケット・フォーマットの図である。
第３Ｆ図は、プロセッサ・パケット・フォーマットの図である。
第３Ｇ図は、異なるデータ・ブロック構成の図である。
第４図は、本発明による画像圧縮コプロセッサのブロック図である。
第５図は、第４図のコプロセッサを使用するシステムの図である。
第６図は、第５図のメモリ接続のより詳細な図である。
第７図は、本発明の制御トークンおよびデータ・トークンを示す図である。
第８図は、第４図のデータ・フロー制御装置のブロック図である。
第９図は、本発明のデータ・フロー命令用の命令フィールドの図である。
第１０図は、本発明の典型的なデータ・フロー・プログラムに関するデータ・フロー・チャートである。
第１１図は、第８図の更新装置のブロック図である。
第１２図は、第８図のイネーブル済み命令待ち行列のブロック図である。
第１３図は、第８図のグローバル・バス・インタフェース装置のブロック図である。
第１４図は、第８図のトークン・メモリ装置のブロック図である。
第１５図は、第４図のＤＣＴプロセッサ装置の機能ブロック図である。
第１６図は、第１５図のＤＣＴプロセッサ装置のグローバル・バス状態マシンに関する状態マシン遷移図である。
第１７図は、第４図の量子化プロセッサ装置のブロック図である。
第１８図は、第４図の演算プロセッサ装置のブロック図である。
第１９図は、第４図のラン・レングス・プロセッサ装置のブロック図である。
第２０図は、第４図のトークン・インタフェース装置の機能ブロック図である。
第２１図は、第４図のホスト・インタフェース装置のブロック図である。
第２２図は、第４図のビデオ・インタフェース装置のブロック図である。
第２３図は、第４図の補助インタフェース装置のブロック図である。
第２４図は、本発明のセマフォの使用を示す図である。
第２５図は、本発明のセマフォの使用を示す図である。
第２６図は、本発明のセマフォの使用を示す図である。
特定の実施形態の説明
典型的システム構成
第２図は、本発明（ＩＣＣ）による画像圧縮／圧縮解除プロセッサ４１０と動き推定コプロセッサ（ＭＥＣ）２１２チップとを備える、ＪＰＥＧ規格、Ｈ．２６１規格、およびＭＰＥＧ規格向けのビデオ圧縮システムの基本構成を示す。ＭＥＣは、１９９３年４月２７日に出願され、”Ｍｏｔｉｏｎ  Ｅｓｔｉｍａｔｉｏｎ  Ｃｏｐｒｏｃｅｓｓｏｒ”と題し、引用によって本明細書に合体された関連米国特許出願第０８／０５５７１１号（「ＭＥＣ出願」）に記載されている。２つのチップは共に、コプロセッサであり、性能レベルがアプリケーションに依存するホスト・プロセッサによってサポートされる必要がある。一般に、インテル（Ｉｎｔｅｌ）１９６０ファミリのメンバーなど市販のＲＩＳＣ制御装置で十分である。ＩＣＣは、動き推定、ハフマン符号化および復号化、ならびにストリーム管理を除く典型的なシステム中のすべてのビデオ圧縮機能を実行する。上記の後者の２つの機能はホスト・プロセッサによって処理され、動き推定はＭＥＣによって処理される。動き補償フレーム符号化を必要としないアプリケーションはＭＥＣチップを必要としない。このことはたとえば、ＪＰＥＧベースの符号化および復号化と、ＭＰＥＧベースの復号化に当てはまる。
３種類のバス、すなわち、ホスト・プロセッサ・バス（Ｈバス）２１４、補助プロセッサ・バス（Ｘバス）２１６、ビデオ・メモリ・バス（Ｖバス）２１８を第２図に示す。各バスは特定の目的を有する。Ｈバスは、プログラムおよびパラメータをホストからＩＣＣチップおよびＭＥＣチップにダウンロードし、ラン・レングス符号化データをホストとＩＣＣの間でリアリタイムで送信するために使用される。Ｘバスは、以下で説明するように、ＩＣＣが、ＭＥＣを含めて「外部」プロセッサ・タイプとのインタフェースをとることができ、融通性に富む。最後に、Ｖバスは、オフ・ザ・シェルフＤＲＡＭまたはＶＲＡＭ２２０、あるいはその両方とのグルーレス・インタフェースを形成し、リフレッシュ・サイクルは、ＩＣＣでもＭＣＣでも生成される。最大の性能を得るには、ＩＣＣおよびＭＥＣのビデオ・バスを、第２図に示したように分割して別々のメモリに接続することも、あるいは、これらのバスを共用することもできる。
これに対して、ＡＴ＆Ｔ社のＡＶＰ１０００チップ・セットは、符号化機能および復号化機能を別々のチップに配置する。このことは、符号化機能および復号化機能が同じ計算資源を共用するＩＣＣとは異なる。また、ＡＴ＆Ｔチップ・セットは、シリコン中心の動き推定機能を符号化チップ上の他の機能と組み合わせているが、ＩＣＣ／ＭＥＣチップ・セットは、別個のチップ（すなわち、ＭＥＣ）を動き推定専用にしている。このため、話を簡単にすると、ＭＰＥＧ  Ｉ−フレームのみに基づく静止画像符号化／復号化アプリケーションでは、ＡＴ＆Ｔ符号化チップとＡＴ＆Ｔ復号化チップが共に必要である（デフォルトでは、不要な動き推定機能も提供される）が、ＩＣＣ／ＭＥＣチップ・セットを使用する同じアプリケーションで必要なのはＩＣＣだけである。ＩＣＣ／ＭＥＣチップ・セットとは異なり、ＡＴ＆Ｔチップ・セットは、高品質静止画像圧縮の場合にＭＰＥＧよりも好ましいＪＰＥＧ規格に対処できないことにも留意されたい。
ＡＴ＆Ｔチップ・セットは、ＩＣＣ／ＭＥＣではホスト・プロセッサ上にマップされる機能を与える、Ｈ．２６１ベースのアプリケーション向けに最適化されたシステム制御装置も含む。ＡＴ＆Ｔシステムでは常に、システム制御装置プロセッサだけでなくある種の専用汎用プロセッサも必要であるが、ＩＣＣ／ＭＥＣシステムでは、ユーザは、適当な実行レベルを有する単一のシステム制御装置プロセッサの時間の一部のみを使用して等価機能を実行することができる。
ＩＣＣは内部で、複数命令−複数データ（ＭＩＭＤ）アーキテクチャを使用して真の「静的データ・フロー」計算モデルを実施する。これは、以前に発表されたマルチメディア・チップとは著しく異なる。たとえば、ＩＩＴ社のビジョン・プロセッサ（Ｖｉｓｉｏｎ  Ｐｒｏｃｅｓｓｏｒ）チップは、すべて、単一の６４ビット・マイクロ命令で制御される加算器、マルチプライヤなどの計算ブロックの集合から成るいわゆる超長命令ワード（ＶＬＩＷ）を実施する。ＡＴ＆Ｔ社のチップ・セットの各符号化チップおよび復号化チップは、すべて、同じ命令を並列に実行する６つの同じ処理要素を有する信号プロセッサを中心とする単一命令複数データ（ＳＩＭＤ）アーキテクチャを使用する。
データ・フロー計算は以前から、並列プロセッサ研究およびハードウェア実施プロジェクトの主要な対象とされている。ＳＩＭＤアーキテクチャおよびＶＬＩＷアーキテクチャを使用するコンピュータを含めて、すべてのデータフロー・コンピュータは、他のコンピュータと異なり、「制御駆動」ではなく「データ駆動」であるという共通の特性を有する。データフロー・コンピュータは、プログラム・カウンタを有さず、その代わり、ある命令に関するデータ・オペランドが利用できるかどうかと、その命令の結果を置く場所のみに基づいてその命令を実行または「ファイア」する。理論的には、多数の命令が一度にファイアすることができ、その結果、複数の並列計算要素を組み込んだデータフロー・アーキテクチャが得られる。データフロー・コンピュータ・プログラムは基本的に、命令間のデータの流れを表す「アーク」によって相互接続された命令「ノード」から成るデータ・フローグラフを使用して表される。プログラム・メモリ中の命令の順序付けは命令の実行に影響を与えない。このようなフローグラフ・アーク上を移動するデータ・オブジェクトを「トークン」と呼ぶ。「静的」データフロー・コンピュータ、たとえばＩＣＣでは、任意の一時点でアーク上で単一のトークンしか許容されず、アーク上で複数のトークンを許容する「動的」データフロー・コンピュータよりも簡単に実施することができる。
制御駆動アーキテクチャは、主要な例として現在のマイクロプロセッサがあり、プロセッサのプログラムの一部である一連のデータ依存決定またはデータ独立決定、あるいはその両方を下すことによって実行すべき命令のアドレスを選択する。プログラムは、命令の相対的な物理配置が実行の順序で重要な役割を果たす、知られている線形リストの形をとる。
ＩＣＣのデータフロー計算アーキテクチャは、第４図に示されており、単一の９６ビット二方向グローバル・バス４１６を介して相互接続された並列処理要素または「機能ユニット」の集合から成る。このバスは、５０Ｍｈｚクロック・サイクルごとに８つの１２ビット語を送信することができ、最大スループット４００Ｍ語／秒をもたらす。トークンは、それぞれ、８つないし２６４個の１２ビット語のベクトルから成り、データフロー制御装置中の機能ユニットとバッファ・メモリの間でバスを介して渡される。データフロー制御装置は、機能ユニットからの結果トークンを、オンチップ１２８語プログラムＲＡＭに記憶されている命令のオペランド・フィールドに突き合わせ、次いで、一致した命令とそのオペランドをグローバル・バスを介して適当な機能ユニットにディスパッチする。
性能を最大にするために、各機能ユニットは、特定の命令サブセットを実行するように最適化され、機能ユニットは全体的に、１０ＢＰＯＳを超えるピーク性能を達成する。たとえば、ＤＣＴプロセッサ・ユニット（ＤＰＵ）４２４は、順方向ＤＣＴおよび逆ＤＣＴのみを実行することができ、量子化プロセッサ・ユニット（ＱＰＵ）４２２は、順方向量子化および逆量子化を実行するように最適化される。いくつかの機能ユニットは、ＩＣＣと外部のインタフェースをとる責任を負う。たとえば、ビデオ・インタフェース・ユニット（ＶＩＵ）４１４は、イメージ・データをオフチップＤＲＡＭから読み取り、オフチップＤＲＡＭに書き込むために使用され、トークン・インタフェース・ユニット（ＴＩＵ）４２８およびラン・レングス・プロセッサ・ユニット（ＲＰＵ）４２６は、ＩＣＣとホスト・プロセッサの間でデータを送信するために使用される。機能ユニット上で実行されるすべてのＩＣＣ命令は、単一のデータ語ではなくデータ・ベクトルから成るトークンを処理するという意味で「ハイ・レベル」である。この特徴のために、ＩＣＣプログラムを極めて小規模にすることができる。ＩＣＣの主要な演算命令コードの要約を表３に示す。
ＩＣＣは、補助インタフェース・ユニット（ＡＩＵ）４３０と呼ばれる特殊な機能ユニットを有し、このインタフェース・ユニットによって、ＩＣＣは、高速同期補助バスを使用して、ＭＥＣを含めて他の特殊な処理チップをサポートすることができる。ＩＣＣは、融通性に富む通信プロトコルと、ＩＣＣのプログラムＲＡＭのユーザ定義命令を使用して、補助バス上でプロセッサを制御する。
性能
ＩＣＣの機能最適化並列処理装置によって、ＩＣＣは、ＪＰＥＧ規格、Ｈ．２６１規格、およびＭＰＥＧ規格を使用するアプリケーション向けの優れた性能を提供することができる。たとえば、通常、ＣＣＩＲ６０１フレーム・サイズ（４８０行×７２０画素／行）を扱うビデオ編集など高画像品質ベースのアプリケーションでは、単一のＩＣＣは、ＪＰＥＧ規格を使用して毎秒３０フレームでこのような画像を符号化し復号化するのに十分な馬力を有する。実際は、ＩＣＣは、最大４０９６行×４０９６画素／行の画像を処理することができる。
しかし、ＩＣＣの高性能は、ビデオ会議（Ｈ．２６１規格を使用する）やＣＤ  ＲＯＭベースのマルチメディア（ＭＰＥＧを使用する）など、より小さなＣＩＦサイズ（２８８行×３５２画素／行）の画像を扱うアプリケーションにも非常に有用である。このようなアプリケーションの場合、単一のＩＣＣ／ＭＥＣチップ・セットは、複数の画像チャネルを処理することができる。たとえば、マルチポイント・ビデオ会議では、単一のＩＣＣ／ＭＥＣチップ・セットを使用して、単一の画像（すなわち、送信されるもの）を符号化し、受信した複数の可能性がある画像を復号することができるビデオｃｏｄｅｃを実施することができる。ＰＣまたはワークステーション上のウインドウ環境で動作するＭＰＥＧ規格に基づくマルチメディア・アプリケーションの場合、単一のＩＣＣは、２つのＳＩＦ画像をリアルタイムで復号することによって複数のウィンドウをサポートすることができる。また、ＣＤ  ＲＯＭベースの画像シーケンスも作成するマルチメディア・アプリケーションの場合、単一のＩＣＣ／ＭＥＣチップ・セットは、Ｐフレーム当たり２Ｂフレーム符号化構造を使用する毎秒３０フレームのＣＩＦ画像のＭＰＥＧ符号化をサポートすることができる。
拡張性およびスケーラビリティ
ＩＣＣの補助バス・インタフェースは自動的に、性能および機能の拡張性とスケーラビリティを共にＩＣＣ／ＭＥＣベースのシステムに組み込む。これは、このバスが、現在の所ＩＣＣの内部アーキテクチャの一部ではない他のプロセッサおよび命令の定義をサポートし、融通性に富むからである。ＭＥＣは、そのようなプロセッサの一例である。最大４つの外部プロセッサが単一の補助バス上に共存することができ、たとえば、ユーザは、複数のＭＥＣを使用することによって動き推定性能を向上させることができる。
ＩＣＣは、補助バスを提供するだけでなく、ユーザのプログラムの実行時に、ホスト・プロセッサをある意味でサブルーチンに類似するものと呼べるようにする特殊な命令も実施する。このような命令により、システムのタイミング上可能なら、ＩＣＣによって、ホスト・プロセッサがオンチップでは実施しない関数を計算するためにホスト・プロセッサを使用することができる。また、この同じ命令によって、ＩＣＣを、ホストから従来型のコプロセッサと同様に見えるようにプログラムすることができる。すなわち、ホストは、それが供給する入力データに対して個別の関数を実行して結果を返すようＩＣＣに命令することができる。
プログラミングの容易さ
ＩＣＣのフローグラフ・ベースのプログラミング環境によって、ユーザは容易に、命令の並列処理を指定することができる。プログラマが行う必要があるのは、命令間でデータがどのような流れるかを指定することだけである。ＩＣＣのデータフロー制御装置は、オペランドが利用できるかどうかに基づいて実行時に命令の実行を自動的にスケジューリングすることによって残りのことを実行し、命令とオペランドを適当な機能ユニットにディスパッチする。ＩＣＣはさらに、高レベル命令を使用して、通常１０個以上の基本命令を必要とするＤＣＴや量子化など標準演算命令を実行することによって、プログラム作成を簡略化する。
これに対して、ＶＬＩＷ（および、これよりも程度は低いが、ＳＩＭＤ）などのアーキテクチャでは、並列計算資源を効率的に使用する負担がプログラマにかかる。ＶＬＩＷでは、プログラマは、単一の命令でいくつかの並行活動を同時に管理する必要があり、また、時間が経過してもこれらの命令が同期したままになるように命令を順序付けなければならない。命令レベルでのＶＬＩＷマシンの大規模プログラミングは、短時間のうちに手に負えないほどの規模になることがあり、一般に、精巧なマイクロコード・コンパイル・ツールを必要とする。ＳＩＭＤプログラミングは、ユーザが複数の処理装置にわたって共通に実行される単一の制御駆動プログラムを作成するので、ユーザにとってはある程度容易である。しかし、ＳＩＭＤプログラミングは、実行すべき命令のシーケンスが主としてデータ独立のものである（すなわち、多数の枝分かれを使用しない）アプリケーションの場合しか効率的でない。このことは、ＤＣＴなど多数の圧縮機能に当てはまるが、しきい値処理済み量子化などある種の機能は、さらにプログラミンを複雑にするある種のデータ依存動作を導入することがある。さらに、ＳＩＭＤアーキテクチャでもＶＬＩＷアーキテクチャでも、プログラマは一般に、ハードウェア・パイプライニングを使用して機能を向上させることを強く意識していなければならない。これに対して、ＩＣＣの機能ユニットは内部でパイプライン化されるが、このことはプログラマから完全に隠される。
第４図は、本発明の一実施形態による画像圧縮／圧縮解除コプロセッサ４１０のブロック図である。コプロセッサ４１０は、ホスト・インタフェース４１２および内部ホスト・バス４１３を介してホスト・コンピュータとのインタフェースをとる。ビデオ・メモリはビデオ・インタフェース４１４を介してアクセスされる。このインタフェースによって内部グローバル・バス４１６との間でデータおよび命令がやり取りされる。コプロセッサは、内部グローバル・バス４１６によって特定のプロセッサに接続された制御ユニット４１８の制御の下で動作する。
画像圧縮／圧縮解除である特定の機能を実行するためにいくつかの専用処理ユニットが用意されている。これらの処理ユニットとは、演算プロセッサ・ユニット４２０、量子化プロセッサ・ユニット４２２、および離散余弦変換（ＤＣＴ）プロセッサ・ユニット４２４である。これらのユニットは、同じハードウェアを使用しカスタム・プログラミングを行ってもよく、またそれぞれ専用のハードウェアを使ってもよい。ホスト・インタフェースと内部グローバル・バスの間に他の２つの専用ユニットが接続される。これらのユニットとは、ラン・レングス・プロセッサ・ユニット４２６およびトークン・インタフェース・ユニット４２８である。コプロセッサ４１０は、追加処理装置に接続すべき補助インタフェース・ユニット４３０も含む。コプロセッサ４１０を試験する試験制御ユニット４３２も用意されている。
動作時には、コプロセッサ４１０は、ホスト・マイクロプロセッサのスレーブとして動作する。ホスト・マイクロプロセッサは、圧縮／圧縮解除用の適当なプログラムをホスト・インタフェース４１２およびラン・レングス・プロセッサ４２６を介して制御ユニット４１８にロードする。制御ユニットは次いで、プログラムの制御の下で、ビデオ・インタフェース４１４またはホスト・インタフェースを介して提供されたデータを圧縮または圧縮解除するようコプロセッサを操作する。圧縮アルゴリズムまたは圧縮解除アルゴリズム中の様々なステップは、内部バスに接続された適当な処理ユニットによって実行される。このようなユニットは、並列にかつ非同期的に動作することができる。したがって、コプロセッサは、チップ上のネットワークとみなすことができるように動作する。データは、必要に応じて、それぞれ、データまたは命令をいつバスを介して送信すべきかを決定する調停回路を含む、処理ユニットおよび制御ユニット間で内部バスを介して送信される。プログラムが完了した後、ホストは、次のプログラムをロードすることができる。
補助インタフェース・ユニット４３０は、他の専用処理ユニットを、オンチップの場合と同様にバスに結合できるようにすることによって、コプロセッサを拡張できるようにする。
内部グローバル・バス４１６は９６ライン幅で大型である。ビデオ・インタフェースおよびホスト・インタフェースは、これよりも行数がより少ない。したがって、内部の様々な専用処理ユニット間で迅速に大量のデータおよび命令を移動することができる。
制御ユニット４１８は、標準マイクロプロセッサに含まれるタイプの標準マイクロプログラム済み制御ユニットなど任意のタイプの制御ユニットでよい。そのようなシステムでは、命令を非同期的に並行に実行することの利点が得られる。しかし、データ・フロー制御ユニットを使用することによって追加効率を得ることができる。
第５図は、第４図の画像圧縮コプロセッサ４１０を使用できるシステムの一実施形態を示す。画像圧縮コプロセッサ４１０は、任意選択の組込み制御プロセッサ５１４を介してＣＰＵバス５１２に接続される。制御プロセッサ５１４を使用して、ハフマン符号化などコプロセッサ４１０では実行されないある種の圧縮解除機能および圧縮機能をＣＰＵ５１６からオフロードすることができる。あるいは、これをＣＰＵ自体で行うこともできる。ローカル・メモリ５４０は組込み制御プロセッサ５１４に結合されたバス上にある。ＣＰＵにはＲＯＭ５１８とＤＲＡＭ５２０が連結されている。ディジタル・ビデオ制御ユニット５２２は、カメラ５２４およびディスプレイ５２６に接続される。データは、カメラ５２４から受信して、ＣＰＵバス５１２またはビデオ・プリ／ポスト・プロセッサ５２８からビデオ制御ブロック５２２を介してディスプレイ５２６に供給することができる。プロセッサ５２８は、ビデオ・メモリ５３０に接続され、ビデオ・メモリ５３０は画像コプロセッサ４１０に接続される。
ＣＰＵバス５１２とディジタル・ビデオ制御ユニット５２２の間に接続されたグラフィックス制御プロセッサ５３２およびグラフィックス・メモリ５３４を介して個別のグラフィックス制御を用意することができる。
モーション・ビデオの場合、ビデオ予測記憶メモリ５４２と共に、動き推定コプロセッサ５３８を追加することができる。
オーディオ機能は、オーディオ変換回路５４８に接続されたマイクロフォン５４４およびスピーカ５４６によって追加することができる。オーディオ圧縮コプロセッサ５５０は、組込み制御プロセッサ５１４とオーディオ変換ユニット５４８の間に接続することができる。
第６図は、画像圧縮コプロセッサ４１０とビデオ・メモリ５３０および組込みコプロセッサ５１４との接続をさらに詳しく示す。ローカル・メモリ５４０用のリフレッシュ信号およびアドレス信号を提供するメモリ・バス制御ユニット６１２も示されている。第６図は、第５図の図で指摘した直接制御プロセッサ５１４を介する接続を有するのではなく、ＣＰＵバス５１２に接続するためのＣＰＵインタフェース６１４も示す。
第４図に戻ると分かるように、画像圧縮コプロセッサの内部グローバル・バス上の通信は、パケットまたは「トークン」を使用することによって行われる。制御トークンおよびデータ・トークンの２種類のトークンが使用される。これらのトークンを第７図に示す。制御トークンとデータ・トークンは共に、トークン記述子と呼ばれる共通データ構造を有する。これは、１２の８ビット・バイトから成る９６ビット・フィールドである。制御トークンとは、制御トークンであることを示すように設定されたトークン・タイプを示す制御ビットを有するトークン記述子である。トークン記述子は、５２ビットの様々な制御ビットと、追加４４ビットのスカラ・データとから成る。
データ・トークンは、同じトークン記述子を含むが、ベクトル・データを含む１つないし４つのデータ・ブロックも有する。データ・トークン中のトークン記述子は、データ・トークンであることを示すように設定された制御ビットを有し、他の２つの制御ビットは、接続されたベクトル・データ・ブロックの数を示すように設定される。スカラ・データ・フィールドは空でよく、あるいは、データ・ブロック・フィールド中のベクトル・データと共にスカラ・データを含むこともできる。
トークン記述子および各ベクトル・データ・ブロックの９６ビット幅は、内部グローバル・バスの９６行幅に対応する。トークン記述子の様々なフィールドを以下の表１にさらに詳しく記載する。
0003806936.tif 000002
0003806936.tif 000003
制御トークンは、そのトークン記述子中のｔｙｐｅ＝０によって識別され、記述子のみから成り、他のデータを含まない。制御トークンは、命令間でブール・データまたは数値スカラ・データ、あるいはその両方を運ぶために使用される。制御トークンの一般的な使用法は、ビデオ・メモリ読取り命令用のメモリ・アドレスを保持することと、プログラム・データフローをゲートするために使用されるブール・データを保持することが含まれる。
データ・トークンは、そのトークン記述子中のｔｙｐｅ＝１によって識別され、記述子と１つまたは複数の６４語データ・ブロックとから成る。データ・トークンは主として、命令間でデータの数値ベクトルを運ぶために使用される。データ・トークンは、最大で４つのｎｂｌｏｃｋｓ＋１個のデータ・ブロックを含む。各データ・ブロックは、表２に示したように８行×８列構成で構成された６４個の１２ビット語を含む。
0003806936.tif 000004
前述のように、トークン記述子のｔｙｐｅフィールドは、制御トークンとデータ・トークンを区別するものであり、ｎｂｌｏｃｋｓフィールドは、データ・トークンを構成するデータ・ブロックの数を示すものである。
データ・トークンを構成するブロックはさらに、トークン記述子中のｃｏｍｐｓフィールドによって識別される構成要素としてグループ化される。最大３つの構成要素（番号０、１、２）がトークン中に共存することができ、より小さい数の構成要素に対応するブロックは、より大きな数の構成要素に対応するブロックよりも前に位置する。表１に示したように、３ビットｃｏｍｐｓフィールドの各ビットは、それに対応する番号の構成要素がトークン中に存在するかどうかを識別する。構成要素が存在する場合、その構成要素を構成するデータ・ブロックの数および形状構成は、制御装置４１８中の対応する番号のＣＯＮＦＩＧレジスタで示される。構成要素は、１つ、２つ、または４つのデータ・ブロックで構成することができる。ＣＯＮＦＩＧレジスタは、構成要素内のデータ・ブロックの構成を示す数０ないし３を含む。これらの構成を第３Ｇ図に示す。構成要素の性質に関して仮定はなされず、すなわち、構成要素は、（Ｙ，Ｕ，Ｖ）データ、（Ｒ，Ｇ，Ｂ）データで構成することができる。
表１中のｅｒｒｆｌａｇフィールドは、命令の実行時に出会ったエラーの発生を示すために様々な画像圧縮コプロセッサ４１０（ＩＣＣ）命令によってセットされる。各結果トークンの記述子中のｅｒｒｆｌａｇビットの論理状態は、ＩＣＣのデータフロー制御装置（ＤＣＵ）４１８によって検査され、真であることが判明した場合、その論理状態によって、ＤＣＵは次のプログラム実行を遮断する。
ｍｂｔｙｐｅフィールドは、データ・トークンに関連するデータ・ブロックを、必要に応じて圧縮または圧縮解除するために使用すべき方法または「モード」を示すものである。ｍｂｔｙｐｅは、復号アプリケーションで使用されるとき、プログラム・データフローを制御するために様々なＩＣＣ命令によって検査することができる。符号化時には、ｍｂｔｙｐｅを使用して、どのモードを使用してデータ・トークン中のデータを圧縮したかを示すことができる。
ｑｕａｎｔフィールドは、ＩＣＣのＭＰＥＧアルゴリズムおよびＰｘ６４量子化アルゴリズムに固有のものである。ＭＰＥＧ順量子化および逆量子化の場合、ｑｕａｎｔは、ＭＰＥＧ規格で定義されたｑｕａｎｔｉｚｅｒ＿ｓｃａｌｅの値を含む。同様に、Ｐｘ６４順量子化および逆量子化の場合、ｑｕａｎｔは、この規格のＭＱＵＡＮＴパラメータの値を含む。ｑｕａｎｔは、ＪＰＥＧ量子化では有効ではない。
ｖｐｏｓ（「垂直位置」）フィールドおよびｈｐｏｓ（「水平位置」）フィールドはそれぞれ、ビデオ・メモリ読取りおよび書込みなどの動作に関するイメージ内のデータ・トークンの位置を識別する行アドレス・カウンタおよび列アドレス・カウンタとして使用されるものである。ｃｎｔｒ１フィールドおよびｃｎｔｒ２フィールドの汎用用途には、ＪＰＥＧ、Ｐｘ６４、ＭＰＥＧなどの規格を実施するアルゴリズムの必要に応じてブロック、マクロブロック、ブロック群、スライスなどをカウントすることが含まれる。ｃｎｔｒ１フィールドは、セマフォ命令を使用することによってプログラム・データフローを制御する特殊な役割も果たす。ｖｐｏｓフィールド、ｈｐｏｓフィールド、ｃｎｔｒ１フィールド、およびｃｎｔｒ２フィールドの内容はすべて、トークン記述子修正命令を介して処理される。
ｕｓｒｂｉｔｓフィールドの使用法は主として未定義であり、プログラマは、このフィールドをいくつかの方法で使用することができる。たとえば、Ｐｘ６４規格を実施するアプリケーションでは、ｕｓｒｂｉｔｓを使用して「ＦＩＬ」や「ＭＣ」などモード・ビットを保持することができる。
最後に、ｓｆｉｅｌｄは、基本的に３種のスカラ・データを保持するために使用され、ｓｆｉｅｌｄ（２３：０）は、ＩＣＣのＭＥＡＮＳＱ命令、ＶＡＲ命令、およびＳＵＢＶＡＬ命令によって生成される２４ビットの２の補数結果を保持する。１ビット・ブール値は、１ｆｌａｇ、ｂｙｔｅ１、ｂｉｔ７に記憶し、プログラム・データ・フローの制御に関連するいくつかの命令によって読み取り、あるいは書き込むことができる。第３のデータ・タイプの動きベクトルは、ｓｆｉｅｌｄの４４ビットをすべて使用する。ｓｆｉｅｌｄ（４３：３３）は、順方向動きベクトルの水平成分を保持し、ｓｆｉｅｌｄ（３２：２２）は垂直成分を保持する。逆方向動きベクトルの場合、ｓｆｉｅｌｄ（２１：１１）が水平成分を保持し、ｓｆｉｅｌｄ（１０：０）が垂直成分を保持する。順方向動きベクトルまたは逆方向動きベクトルの分解能は、それぞれ、ＤＣＵ４１８中のＦＵＬＬＦＭＶフラグ・レジスタおよびＦＵＬＬＢＭＶフラグ・レジスタで示されるように、全画素でも、半画素でもよい。
制御トークンおよびデータ・トークンは、オンチップ・メモリに記憶される。トークン記憶域は、９６ビット・ヘッダおよび１６×９６ビット・ブロック割振り単位（ＢＡＵ）の２種類の単位で割り振られる。各制御トークンは１つのヘッダを必要とし、各データ・トークンは１つのヘッダ・プラス（ｎｂｌｏｃｋｓ＋１）／／２ＢＡＵ（「／／」は、最近の整数への丸め、すなわち半値切上げを含む整数除算を示す）を必要とする。
すべてのヘッダおよびＢＡＵは、ＩＣＣメモリにオンチップで記憶される。ＩＣＣは、合計で１２８個のヘッダと６４個のＢＡＵを記憶する。すべてのヘッダおよびＢＡＵの割振りおよび割振り解除は、命令によってトークンが作成または使用されたときに、ＩＣＣのデータフロー制御装置（ＤＣＵ）によって自動的に処理される。
ＩＣＣ４１０は、５３個の内部命令を使用する。データ・フロー技法によれば、これらの命令は、それらが必要とするオペランドが利用可能になった直後に実行される。ある種の命令は、第４図中のある機能ユニット向けに指定される。命令は、実行可能になると、その命令を処理する妥当なプロセッサ装置に経路指定される。以下の表３には、各命令の簡単な説明が、その命令を処理する機能ユニットと共に記載されている。
0003806936.tif 000005
0003806936.tif 000006
0003806936.tif 000007
0003806936.tif 000008
0003806936.tif 000009
0003806936.tif 000010
各命令のより詳しい説明は、本明細書に添付した付録１に記載されている。
プログラム
ＩＣＣプログラムは、「ノード」が、そのデータ・オペランドを利用できるかどうかに基づいて実行されるデータ駆動命令フロー・グラフから成る。プログラム構造および実行に対するこのデータ駆動手法が、ＩＣＣの並列計算アーキテクチャと結合され、その結果、ＩＣＣは、アルゴリズムの融通性を損なわずにリアルタイム画像圧縮に必要な極めて高いスループットをもたらすことができる。
プログラムは、ホスト・プロセッサ・インタフェースを介してＩＣＣの命令メモリにダウンロードされる。ホストはダウンロード後、プログラムを、実行できるようにイネーブルし、その後、オペランドが利用できるかどうかに基づいて命令が自動的に実行される。命令は通常、他の命令、ビデオ・メモリ、またはホスト・プロセッサから得られた画像データのパケットまたは「トークン」に作用して、結果トークンを生成する。
ＩＣＣ命令セットは、Ｐｘ６４（Ｈ．２６１とも呼ばれる）、ＭＰＥＧ、ベースラインＪＰＥＧなどの業界標準のリアルタイム圧縮アルゴリズム・プログラミング要件を満たすように特定的に設計される。ＩＣＣ命令は、下記の６つのクラスに分割される。演算（Ａｒｉｔｈｍｅｔｉｃ）命令は、加算、減算、順方向ＤＣＴ（離散余弦変換）および逆ＤＣＴ、順量子化および逆量子化など演算を実行する。論理（ｌｏｇｉｃａｌ）命令は、ブール演算およびトークン・コピー演算を実行する。記述子修正（Ｄｅｓｃｒｉｐｔｏｒ  Ｍｏｄｉｆｉｃａｔｉｏｎ）命令は、トークンに関する記述情報を修正できるようにする。ビデオ・メモリ（Ｖｉｄｅｏ  Ｍｅｍｏｒｙ）命令は、ＩＣＣとビデオ・メモリの間での画像データのトークンを送信する。データフロー制御（Ｄａｔａｆｌｏｗ  Ｃｏｎｔｒｏｌ）命令は、データ依存条件またはフラグ依存条件に基づいて命令間でトークンを渡すことを制御する。ホスト・インタフェース（Ｈｏｓｔ  Ｉｎｔｅｒｆａｃｅ）命令は、ＩＣＣとそのホスト・プロセッサ間でデータを都合よく転送できるようにする。
ＩＣＣとそのホスト・マイクロプロセッサは、画像圧縮アルゴリズムの実行時に協働する。ＩＣＣは、命令メモリにダウンロードされたプログラムの実行に全責任を負い、プログラム実行中の様々な時点で、圧縮済み画像データを転送し、あるいは、重大な制御情報を得るためにホストと通信するようにＩＣＣを強制することができる。ＩＣＣは、ホスト・ポール可能なフラグまたは割込みが利用可能である場合、それを使用してホスト・アテンションを要求する。ホストの観点からは、ＩＣＣは、画像圧縮アルゴリズムのすべての計算多用部分を実行する極めて自律的なスレーブ・コプロセッサである。ホストは、ＩＣＣ内の一般演算パラメータを設定し、ＩＣＣでは処理されないハフマン符号化および復号などの演算を実行する。
ＩＣＣのビデオ・バスの使用は、直接プログラマによって制御される。命令に応じて３２ビット幅または１６ビット幅になるように構成できるバスに、１つ、または物理的に異なる複数のビデオ・メモリを接続することができる。複数のバス・マスタが同じビデオ・バス上に存在することができ、競合は、デージーチェーン調停方式によって解決される。ビデオ・インタフェースは、高速ページ・モードＤＲＡＭまたはＶＲＡＭ、あるいはその両方と共に使用できるように最適化されて通常の読取り／書込み転送をサポートし、ＶＲＡＭ間転送、ＳＡＭ・ＤＲＡＭ間転送、ＤＲＡＭ・ＳＡＭ間転送向けにも最適化される。このインタフェースの１１ビット・アドレス３２ビット・データ・バスは、最大４０９６×４０９６画素の画像にアクセスすることも、あるいは、５μｓよりも短い時間で１６×１６画素ブロックを書き込むこともできる。
ＩＣＣの補助バス・インタフェースは、最大４つの外部インタフェース装置に接続することができる。補助プロセッサは、ＩＣＣがサポートしない追加機能を提供するようにＩＣＣに接続することも、あるいは、すでにサポートされている機能（動き推定など）を加速するようにＩＣＣに接続することもできる。補助プロセッサの一例は、動き推定コプロセッサ（ＭＥＣ）である。
データフロー制御装置（第８図）
ＤＣＵ４１８は、様々な機能ユニット間のトークン・トラフィックをスケジューリングし、ＤＣＵのスカラ命令およびセマフォ命令を実行する責任を負う（表３参照）。制御ユニットは、４つの主要なユニットから構成される。これらのユニットとは、更新ユニット８１２、イネーブル済み命令待ち行列８１４、グローバル・バス・インタフェース・ユニット８１６、およびトークン・メモリ・ユニット８１０である。
更新ユニット８１２は、すべての命令の実行状態を連続的に監視する。ある命令が実行を完了すると、更新ユニット８１２はその宛先命令を見つけて、データおよび処理資源が利用可能であるときは、宛先命令を実行できるようにスケジューリングする。更新ユニット８１２は、セマフォ命令実行の第１の部分を実行する責任も負う。
イネーブル済み命令待ち行列８１４は、実行可能な命令を更新ユニット８１２から受信し・グローバル・バス・インタフェース・ユニット８１６の処理準備が完了するまでその命令を保持する。これによって、機能ユニットに命令を分配することから命令のスケジューリングが分離され、そのため、いくつかの実行可能な命令が一度に存在することができる。
グローバル・バス・インタフェース・ユニット８１６はいくつかの機能を実行する。グローバル・バス・インタフェース・ユニット８１６は、イネーブル済み命令待ち行列８１４から新しい命令を受信した後、トークン・メモリ・ユニット８１０から必要なトークンを取り出し、実行するために命令と共に妥当な機能ユニットへ送信し、あるいは、命令がスカラ命令またはセマフォ命令である場合、その命令を実行してトークン・メモリ・ユニット８１０に結果を返す。機能ユニットが実行を終了すると、グローバル・バス・インタフェース・ユニット８１６は、結果トークン（もしあれば）を受信し、トークン・メモリ・ユニット８１０へ転送し、命令の処理が完了したことを更新ユニット８１２に通知する。
トークン・メモリ・ユニット８１０は、ブロック割振りユニット（ＢＡＵ）メモリ８１８、ヘッダ・メモリ８２０、トークン・アドレス・メモリ８１９、メモリ割振り機構８２２の４つの主要な部分から成る。ＢＡＵメモリ８１８は、処理を完了して、機能ユニットへ送信されるのを待っているデータ・トークンのデータ・ブロックを含む。ヘッダ・メモリ８２０は、各データ・トークンまたは制御トークンのトークン記述子を含む。トークン・アドレス・メモリ８１９は、ＢＡＵメモリ８１８中のＢＡＵをヘッダ・メモリ８２０中のトークン記述子に関連付け、トークン記述子も、それを作成した命令に関連付ける。メモリ割振り機構８２２は、それぞれ新しいトークン記述子およびＢＡＵ用のヘッダ・メモリ８２０およびＢＡＵメモリ８１８中のメモリ空間を割り振り、データが機能ユニットに送信されたときにメモリ空間を割り振り解除する。
ＩＣＣ命令は、プログラム実行前にホスト・プロセッサによってロードされるオンチップ１２８語×４０ビット命令ＲＡＭ８２４に存在する。第９図に示したように、各ＩＣＣ命令は、単一の４０ビット語を占有するが、４つの異なるフォーマットのうちの１つを有することができる。この４つのフォーマットは、各フォーマットが保持できる宛先命令アドレスの数、すなわち、３、２、１、または０によって区別される。
命令は、アドレス０で始まる命令ＲＡＭ内のメモリの連続ブロックを占有しなければならない。すべてのＣＲＴＯＫＥＮ命令がアドレス０から位置決めされ、他のタイプの命令の前に位置しなければならないことを除いて、一般に、命令は命令ＲＡＭ内で任意の方法で順序付けることができる。
命令は、ＩＣＣ４１０自体（Ｘ＝０）、またはＩＣＣの補助バス・インタフェースに接続された補助（すなわち、外部）プロセッサ（Ｘ＝１）によって実行される命令コードを有することができる。ＩＣＣ上の補助インタフェース・ユニット（ＡＩＵ）４３０は、最大４つの補助プロセッサを同時に管理する責任を負う。各６ビット外部命令コードの最下位２ビットは、適当な補助プロセッサを選択するためにＡＩＵによって復号される。
動作時には、ＩＣＣが圧縮機能または圧縮解除機能を実行できるように、ホスト・インタフェースを介して外部ホスト・コンピュータからデータ・フロー制御ユニットにプログラムがロードされる。プログラムは、第８図の命令メモリ８２４に記憶される。この命令は、付録１に記載した命令のうちの一連の命令であり、それぞれ、第９図に記載したフォーマットのうちの１つのフォーマットを有する。
復号化アルゴリズム・プログラムの一例を第１０図に示す。第１０図中の各ブロックは、実行すべき特定の命令を示し、データ・フロー・フォーマットで記載されている。各命令は、オペランド・トークン内のすべてのデータに作用し、オペランド・トークンが必要とされない場合は、他の何らかのソースから得たデータに作用する。たとえば、第１０図中の第１の命令”ＲＵＮＤＥＣ”は、ホスト・プロセッサによって配置されたＲＰＵのレート・バッファ中のデータから結果トークンを作成する。その結果トークンが利用可能になると、次の命令がそのトークンに作用し、以下同様である。その間、ＲＵＮＤＥＣ命令は次の利用可能なＲＰＵデータに作用することができる。
各結果トークンを構成するデータ・ブロックは、各命令を実行する処理ユニットから第８図のＢＡＵメモリ８１８に転送され、表２に記載したベクトル・フォーマットで記憶される。各トークンに関連するトークン記述子は、ヘッダ・メモリ８２０に記憶される。トークン記述子のフォーマットは表１に記載されている。トークン・アドレス・メモリ８１９には、トークンを作成した命令のアドレスと、各データ・トークンごとに、トークンのデータ・ブロックを記憶しているＢＡＵの数、およびＢＡＵメモリ８１８中のＢＡＵのアドレスも書き込まれる。
命令は命令ＲＡＭ８２４に記憶される。各命令を実行するのに必要なトークン・オペランド（もしあれば）のアドレスと、各命令の動作状況が、更新ユニット８１２（第１１図参照）、オペランドＲＡＭ８２１および命令ビジーＲＡＭ８２３に記憶される。オペランドＲＡＭ８２１中の「オペランド存在」ビットで示され（かつ他の何らかの補助条件が満たされる）るように命令ＲＡＭ８２４中の特定の命令のオペランドの準備が完了すると、命令は、更新ユニット８１２によってオペランド・アドレスと共にイネーブル済み命令待ち行列８１４に転送される。命令および関連情報は後で、イネーブル済み命令待ち行列８１４から読み取られ、グローバル・バス・インタフェース・ユニット８１６へ転送される。
グローバル・バス・インタフェース８１６は、命令を、グローバル・バス上で送信されるように、第３Ｅ図に示したようにプロセッサ・パケットに入れる。命令に関連するオペランド・データは、ヘッダ・メモリ８２０から得た記述子およびＢＡＵメモリ８１８から得たベクトル・データ自体を使用してトークン・メモリ・ユニット８１０から検索され、トークンとしてアセンブルされる。次いで、プロセッサ・パケットとオペランド・トークンは共に、グローバル・バス・インタフェース・ユニット８１６によって、命令を実行する責任を負う処理ユニットへ送信される。
処理ユニットが、命令に応じてデータを処理した後、結果トークンがＤＣＵ４１８に返される。結果トークンのデータは、トークン・メモリ・ユニット８１０に戻され、更新ユニット８１２は、結果トークンのヘッダ・メモリ・アドレスをトークン・メモリ・ユニット８１０から受信し、この結果をもたらした命令のアドレスをグローバル・バス・インタフェース・ユニット８１６から受信する。更新ユニットは、この結果をもたらした命令から宛先を読み取り、各宛先命令の妥当なオペランド・アドレス・フィールドにトークン・ヘッダ・アドレスを置く。更新された命令は、それに必要なすべてのオペランドが存在するときに実行に関してイネーブルされる。
イネーブル済み命令は、そのイネーブル済み命令パケットがアセンブルされ、イネーブル済み命令待ち行列８１４へ送信されときにファイアされたと言われる。一般に命令がファイアされるのは、下記の条件が満たされた場合である（ある種の命令は条件３しか必要としない）
１．命令を発行すべきプロセッサがアイドル状態である。
２．イネーブル済み命令待ち行列８１４中の同じプロセッサに対する他の命令はない。
３．命令ビジーＲＡＭ中で命令の「ビジー・ビット」がでセットされていない。これは、命令が現在実行されておらず、命令の前の実行の結果がトークン・メモリ・ユニット８１０に残っていないことを意味する。
ファイアされたすべての命令は、命令ビジー・ビットをセットされている。このビットは、命令によって作成された結果トークン（もしあれば）がすべての宛先命令によって使用されるまでクリアされない。
更新ユニット（第１１図）
更新ユニット８１２は主として、ＩＣＣの様々な機能ユニット上での命令を開始し、終了する責任を負う。更新ユニット８１２は、グローバル・バス・インタフェース・ユニット８１６内のスカラ・プロセッサ・ユニットと共に、いわゆるセマフォ命令１ＮＩＴＳＥＭ、ＴＳＴＳＥＭ、ＩＮＣＳＥＭ、およびＴＳＴＤＥＣを実行する責任も負う。更新ユニット８１２は、
１．主制御装置ブロック１１２１
２  ホスト・バス・インタフェース・ブロック１１２５
３．命令イネーブル・ブロック１１１３
４．セマフォ命令ブロック１１１７
５．命令更新ブロック１１２３
６．命令ＲＡＭ８２４
７．命令復号化ＲＯＭ１１１１
８．オペランドＲＡＭ８２１
９．命令ビジーＲＡＭ８２３
の各主要ブロックから成る。
命令ＲＡＭ１１１８は、幅４０ビットであり、長さ１２８語であり、各語は、第９図に示したようにフォーマットされた単一のＩＣＣ命令を含む。このＲＡＭは通常、システム初期設定時に外部ホスト・プロセッサによって内部ホスト・バス４１３を介してロードされる。
命令復号化ＲＯＭ１１１１は、幅１１ビットであり、長さ１２８語である。命令イネーブル・ブロック１１１３は、命令の６ビット命令コード・フィールドと１ビットＸフィールドを連結したものを使用して命令復号化ＲＯＭにアドレスする。ＲＯＭの各語では、単一ビットのみが、内部ＩＣＣ機能ユニットまたは外部プロセッサ・ユニットが命令を実行する必要があることを示す「１」にセットされる。Ｘビットが「１」にセットされた命令は、「外部」命令であり、オフチップ機能ユニット（すなわち、物理的にＩＣＣの一部ではない機能ユニット）によって実行する必要がある。
オペランドＲＡＭ８２１は、幅２１ビットで長さ１２８語であり、命令ＲＡＭ１１１８中の各命令ごとに１語を有する。各語は、第３Ａ図に示したようにフォーマットされ、ＩＣＣがリセットされたとき必ずゼロにセットされる。各語のビット２０ないし１６に記憶されているデータは、セマフォ命令の実行時にセマフォ命令ブロック１１１７によって使用される。ビット１５ないし０は、対応する命令のすべての必要なオペランド・トークン（もしあれば）が現在、トークン・メモリ・ユニット８１０に存在しているかどうかを判定し、そうである場合、トークン・メモリ・ユニット８１０のトークン・アドレス・メモリ８１９中の前記オペランド・トークンのアドレスが何であるかを判定するために命令イネーブル・ブロック１１１３によって使用される。
命令ビジーＲＡＭ８２３は、幅１ビットで長さ１２８語であり、命令ＲＡＭ８２４中の各命令ごとに１語を有する。オペランドＲＡＭ８２１の場合と同様に、このＲＡＭ中の各語は、ＩＣＣがリセットされると必ずゼロにセットされる。このＲＡＭ中の語が「１」にセットされた場合は、下記の条件のうちの１つが真であることを示す。
１．対応する命令が実行できるようにスケジューリングされた（すなわち、その命令がイネーブル済み命令待ち行列８１４に存在する）。
２．対応する命令が現在、機能ユニット上で実行されている。
３．対応する命令が、そのすべての宛先によって使用されたわけではないトークン・メモリ・ユニット８１０中に存在する結果トークンを有する。
主制御装置ブロック１１２１は、更新ユニット８１２内の活動の調和を図り、命令イネーブル・ブロック１１１３または命令更新ブロック１１２３の実行を活動化する。命令イネーブル・ブロック１１１３は最初、プログラムが動作を開始するときに活動化される。
ホスト・バス・インタフェース・ブロック１１２５は、様々なＤＣＵレジスタを保持し、ＩＣＣの内部ホスト・バスとＤＣＵレジスタを使用するＤＣＵの他の部分の両方とＤＣＵレジスタとのインタフェースをとる。内部ホスト・バスは、ＩＣＣを制御する外部ホスト・プロセッサが様々なＩＣＣレジスタおよびメモリにアクセスできるようにするホスト・インタフェース・ユニット４１２に接続される。このブロック中のレジスタは、４つのセマフォ・レジスタＳＥＭＲＥＧ（０）ないしＳＥＭＲＥＧ（３）と、「最後のプログラム・アドレス・レジスタ」ＬＡＳＴＡＤＤＲと、構成要素構成レジスタＣＯＮＦＩＧ０、ＣＯＮＦＩＧ１、ＣＯＮＦＩＧ２と、プロセッサ状況レジスタＰＳＷと、エラー状況レジスタＥＲＲＳＴＡＴとを含む。ホスト・バス・インタフェース・ブロック１１２５は、内部ホスト・バスと命令ＲＡＭ８２４とのインタフェースもとる。
更新ユニット８１２内の命令イネーブル・ブロック１１１３は、命令ＲＡＭ８２４中の各命令を、適当な時間に実行されるように「イネーブルする」責任を負う。一般的に言えば、命令は、下記の「イネーブル」条件をすべて満たしたときに実行がイネーブルされる。
１．すべての必要なオペランド・トークン（もしあれば）がトークン・メモリ・ユニット８１０中に存在する。
２．命令ビジーＲＡＭ８２３中の命令の対応する項目が０である。
３．命令が必要とする特殊イネーブリング条件が満たされている。
命令イネーブル・ブロック１１１３は、所与の命令の「オペランド数（ＮＯ）」フィールドを調べて、その命令がオペランドを必要とするかどうかを判定し、次いで、オペランド・メモリ８２１中の命令の「オペランド存在」ビットを調べてそのオペランドがトークン・メモリ８１０中に存在するかどうかを判定することによって、その命令に関する条件（１）を試験する。条件（３）で試験される「特殊イネーブリング条件」は、命令の命令コードに依存する。そのような条件を有する命令は、トークン・オペランドを有さず、あるいは、トークン・メモリ・ユニット８１０中に存在するそのオペランド・トークンを有するだけでなく、満たすべき何らかの論理条件を必要とする。前者の範疇の命令は、ＣＲＴＯＫＥＮ、ＲＵＮＤＥＣ、およびＳＮＥＡＫであり、セマフォ命令およびＳＮＯＯＰ命令は後者の範疇に入る。外部命令は、どちらの範疇に入ることもできる。
命令イネーブル・ブロック１１１３によって「イネーブルされた」命令を使用して、７２ビット「イネーブル済み命令パケット」（第３Ｃ図）が形成され、次いで、命令イネーブル・ブロック１１１３がこのパケットをイネーブル済み命令待ち行列８１４に入れようとする。この試みは、下記のすべての「待ち行列」条件が真である場合には成功する。
１．命令を実行するのに必要な機能ユニットがアイドル状態である。
２．イネーブル済み命令待ち行列８１４は現在、着信命令と同じ機能ユニットを必要とする他の命令からのイネーブル済み命令パケットを含まない。
３．イネーブル済み命令待ち行列８１４が満杯ではない。
表３にリストしたＤＣＵ命令は例外であり、イネーブル済み命令待ち行列８１４に入れられる前に上記の条件（３）を満たしておくだけでよい。
現在、命令イネーブル・ブロック１１１３によってイネーブルすべきかどうかを調べられている、命令のアドレスは通常、７ビット「イネーブル済み命令カウンタ」（ｅｎ＿ｃｏｕｎｔｅｒ）の内容によって与えられ、ある種の環境では、この代わりに、命令更新ブロック１１２３によってこのアドレスが提供される。ｅｎ＿ｃｏｕｎｔｅｒは、ＩＣＣがリセットされたときにゼロにリセットされる。ｅｎ＿ｃｏｕｎｔｅｒは、その内容が「最後のプログラム・アドレス」レジスタＬＡＳＴＡＤＤＲに一致するまで、（命令イネーブル・ブロック１１１３が動作していない間でも）連続的に「１」だけ増分される。一致した時点で、ｅｎ＿ｃｏｕｎｔｅｒはゼロにリセットされ、再び増分を開始する。
命令イネーブル・ブロック１１１３は、３段パイプラインを使用して、命令をイネーブルしそのイネーブル済み命令パケットをイネーブル済み命令待ち行列８１４に書き込む。第１パイプライン段で、命令イネーブル・ブロック１１１３は、前述の３つのイネーブリング条件を検査する。最初の２つの条件はあらゆる命令の場合に検査される。しかし、この段では、「特殊イネーブリング条件」はＣＲＴＯＫＥＮ命令、ＲＵＮＤＥＣ命令、およびＳＮＥＡＫ命令の場合にのみ検査される。いわゆる「イネーブル」ビットは、命令がそのすべての第１段イネーブリング条件に合格したときに第１パイプライン段の出力レジスタ中で「１」にセットされる。
ＣＲＴＯＫＥＮ命令は、プログラム中のＣＲＴＯＫＥＮ命令の各インスタンスが一度しか実行されないという点でユニークである。ＣＲＴＯＫＥＮ命令は、オペランド・トークンを有さず、その目的は、プログラムが開始されたとき、プログラムの残りの部分の実行を「ブートストラップ」するために単一のトークンを作成することである。この動作を実施するために、命令イネーブル・ブロック１１１３は、特殊な１ビット・レジスタを含み、命令イネーブル・ブロック１１１３の第１パイプライン段は、このレジスタがゼロにセットされない限りＣＲＴＯＫＥＮ命令をイネーブルしない。このレジスタは、ＩＣＣがリセットされたときに必ずゼロにセットされ、命令イネーブル・ブロック１１１３が初めてＣＲＴＯＫＥＮ命令ではない命令をイネーブルしょうとしたときに「１」にセットされ、ＩＣＣが再びリセットされるまで「１」にセットされたままである。プログラムは、最大３つのＣＲＴＯＫＥＮ命令を含むことができ、すべての命令は、命令ＲＡＭ８２４中にアドレス０から連続的に位置しなければならない。
ＣＲＴＯＫＥＮと同様に、ＲＵＮＤＥＣ命令およびＳＮＥＡＫ命令はオペランド・トークンを有さない。ＲＵＮＤＥＣは、ＩＣＣのラン・レングス・プロセッサ・ユニット（ＲＰＵ）によって実行される。命令イネーブル・ブロック１１１３は、ＲＵＮＤＥＣをイネーブルするために、ＲＰＵの入力ＦＩＦＯが空でないときにＲＰＵによってアサートされる状況信号を検査する。同様に、命令イネーブル・ブロック１１１３は、ＳＮＥＡＫをイネーブルするために、ＴＩＵのトークン・パッシング・バッファがホスト・プロセッサから得た新しいトークンを含むときにトークン・インタフェース・ユニット（ＴＩＵ）によってアサートされる状況信号を検査する。
命令イネーブル・ブロック１１１３の第２パイプライン段では、ＳＮＯＯＰ命令、セマフォ命令、および外部命令に関する特殊イネーブリング条件が、第１の２つの待機条件と同様に、検査される。いわゆる「ビジー」ビットは、ある命令に関して検査されたすべての条件が真であるときに第２パイプライン段の出力レジスタ中で「１」にセットされ、第１パイプライン段から得た命令のイネーブル・ビットも「１」にセットされる。
ＳＮＯＯＰ命令はＴＩＵによって実行される。第２パイプライン段は、ＳＮＯＯＰ命令をイネーブルするために、ＴＩＵのトークン・パッシング・バッファが空であり、新しいトークンを受信する準備が完了したときにＴＩＵによってアサートされる状況信号を検査する。このトークンは、以前に第１パイプライン段で存在が検証されたＳＮＮＯＰ命令のオペランドから提供される。
外部命令は、第２４図に示したＩＣＣの補助プロセッサ・インタフェース・ユニット（ＡＩＵ）を介してオフチップ機能ユニットに渡される。ＡＩＵは、それぞれ、最大４つの並行機能ユニットを含むことができる、最大４つの外部プロセッサ・チップと通信する責任を負う。外部命令を実行するのに必要な外部プロセッサ・チップは、外部命令の６ビット命令コード・フィールドの最下位２ビット（ビット１および０）によって指定され、プロセッサ内の機能ユニットは、命令コードのビット３および２によって指定される。
ＡＩＵは、外部命令状況テーブル２４１５、すなわち、幅１ビット、長さ１６語のＲＡＭを含む。このＲＡＭは、ＩＣＣがリセットされ命令イネーブル・ブロック１１１３によって読み取られ、外部命令を実行するのに必要なオフチップ機能ユニットがアイドル状態であるかどうかが判定されたときに必ずクリアされる。このＲＡＭは、第２パイプライン段中に、外部命令の命令コード・フィールドの最下位４ビットを使用してアドレスされる。この語がゼロである場合、対応する外部プロセッサ・チップ内の対応する機能ユニットはアイドル状態である。オフチップ機能ユニットとＡＩＵが共にアイドル状態であり、第２の待機条件が満たされている場合、第２のパイプラインのビジー・ビットが「１」にセットされる。
セマフォ命令は、ＩＣＣの４つのセマフォ・レジスタのうちの１つの内容を試験し、あるいは処理し、あるいはその両方を行い、次いで、命令のオペランド・トークンをレジスタの出力にコピーする。ＴＳＴＳＥＭ命令およびＴＳＴＤＥＣ命令の場合、前記コピー動作は、何らかのセマフォ試験が満たされるまで遅延する。第１パイプライン段でイネーブルされたセマフォ命令は、第２パイプライン段で検出され、さらに条件を検査し部分的に実行できるようにセマフォ命令ブロック１１１７にセットされる。
ＩＮＩＴＳＥＭ命令の場合、セマフォ命令ブロック１１１７は、２つの命令パラメータによって選択されたセマフォ・レジスタ・ビットを、第３の命令パラメータから与えられた値に設定するに過ぎない。ＩＮＣＳＥＭでは、この命令は、他の２つの命令パラメータによって選択されたセマフォ・レジスタ・ビットに２つの命令パラメータのうちの一方を加える。この加算用に選択されるパラメータは、オペランドＲＡＭ８２１中の命令に対応する語の最上位ビット（ビット２０）の状態によって決定される。セマフォ命令ブロック１１１７は、ＩＮＩＴＳＥＭまたはＩＮＣＳＥＭを処理した後、「セマフォ・ビジー」（ｓｅｍ＿ｂｚ）信号を「１」にセットして命令イネーブル・ブロック１１１３に戻す。
ＴＳＴＤＥＣ命令の場合、セマフォ命令ブロック１１１７は、２つの命令パラメータとは別の２つの命令パラメータによって選択されたセマフォ・レジスタ・ビットから、前者の２つの命令パラメータのうちの一方を減じる。減算用に選択されるパラメータは、オペランドＲＡＭ８２１中の命令に対応する語の最上位ビット（ビット２０）の状態によって決定される。この差は、ゼロ以上であり、選択されたセマフォ・レジスタ・ビットの内容がこの差と置換され、ｓｅｍ＿ｂｚが「１」にセットされる。この差がゼロ未満である場合、選択されたセマフォ・レジスタは変更されず、ｓｅｍ＿ｂｚはゼロにセットされる。
最後に、ＴＳＴＳＥＭ命令の場合、セマフォ命令ブロック１１１７は、２つの命令パラメータを使用してセマフォ・レジスタ・ビットを選択し、第３のパラメータを使用してこのビットをマスクし、次いで、このビットが第３のパラメータによってマスクされた後のオペランドＲＡＭ８２１中の命令に対応する語のビット１９ないし１６の状態とこのビットを比較する。この比較の結果、一致した場合、ｓｅｍ＿ｂｚは「１」にセットされ、そうでない場合、ｓｅｍ＿ｂｚはゼロにセットされる。
セマフォ命令ブロック１１１７がセマフォ命令の処理を終了した後、命令イネーブル・ブロック１１１３の第２パイプライン段は、そのビジー・ビットをｓｅｍ＿ｂｚと同じ値を有するようにセットする。セマフォ命令のトークン・コピー動作は、命令がイネーブル済み命令待ち行列８１４に送られた後にグローバル・バス・インタフェース８１６中のスカラ・プロセッサ・ユニット（ＳＰＵ）によって実行される。ＳＰＵは、セマフォ命令を待ち行列から読み取り、コピー命令と同様に処理する。
命令イネーブル・ブロック１１１３の第３の最後のパイプライン段で、第２パイプライン段から得たビジー・ビットの状態と同様に、第３の待機条件が検査される。イネーブル済み命令待ち行列８１４が満杯でなく、パイプライン・ビジー・ビットが「１」にセットされている場合、命令用のイネーブル済み命令パケットが作成され、イネーブル済み命令待ち行列８１４にセットされ、命令ビジーＲＡＭ中の命令に対応する語が「１」にセットされる。イネーブル命令待ち行列８１４が満杯であり、あるいは、パイプライン・ビジー・ビットがゼロにセットされている場合、前記事象はいずれも発生しない。
命令更新ブロック１１２３は、トークン・メモリ・ユニット８１０またはグローバル・バス・インタフェース・ユニット８１６によってそれぞれ、「ビジー・クリア」（ｃｌ＿ｂｚ）信号または「結果パケット・ロード」（ｌｄ＿ｒｅｓ＿ｐａｃ）信号が主制御装置ブロック１１２１にアサートされたときに必ず活動化される。ｃｌ＿ｂｚ信号は、トークン・メモリ・ユニット８１０のヘッダ使用メモリ１４１１中のトークン使用率カウントがゼロに減分したときに必ずアサートされ、関連するトークンがもはやどの命令からも必要とされないことを示す。トークン・メモリ・ユニット８１０は、ｃｌ＿ｂｚをアサートするだけでなく、トークンを作成した命令のアドレスも命令更新ブロック１１２３へ送り、トークン・アドレス・メモリ８１９中のトークンの語の最上位７ビットからこのアドレスを読み取る。命令更新ブロック１１２３は次いで、命令ビジーＲＡＭ８２３中のそのアドレスにある語をゼロにセットし、それにより、命令イネーブル・ブロック１１１３によって、将来のあるときに対応する命令を再びイネーブルできるようにする。
ｌｄ＿ｒｅｓ＿ｐａｃ信号は、実行を終了した命令からの「結果パケット」レディを有するときは必ず、グローバル・バス・インタフェース８１６内のバス・アービタ１３１０によってアサートされ、主制御装置ブロック１１２１に命令イネーブル・ブロック１１１３を中断させ、命令更新ブロック１１２３を活動化させる。５４ビット結果パケットは、第３Ｂ図に示したようにフォーマットされ、通常、実行を終了した命令の各宛先命令に対応するオペランド・メモリ８２１中の位置を修正するために命令更新ブロック１１２３によって使用される。結果パケットは、グローバル・バス４１６を介して送信され、命令更新ブロック１１２３内の「更新レジスタ」に記憶される。
ｌｄ＿ｒｅｓ＿ｐａｃ信号には他の「非更新」信号（ｎｏ＿ｕｐｄａｔｅ）が伴い、「非更新信号」は、アサートされると、終了した命令が結果トークンを有さないことを示す。命令のＮＯフィールドがゼロであるために命令が結果トークンを生成しないことが保証される（この範疇の命令はＲＵＮＥＮＣ、ＳＮＯＯＰ、ＷＲＶ１６、およびＷＲＶ３２である）ケース、または命令がときどき結果トークンを生成する（この範疇の命令はスカラ命令ＣＧＡＴＥ、ＤＧＡＴＥ１、ＤＧＡＴＥ２、ＦＧＡＴＥ、およびＧＡＴＥである）ケースの２つのケースがあり得る。どちらの場合も、命令更新ブロック１１２３は、終了した命令のアドレスを更新レジスタから抽出し、命令ビジー・メモリ８２３中のその位置にある語をゼロにセットする。トークン・メモリ・ユニット８１０は、結果トークンを生成しない命令に対してはｃｌ＿ｂｚ信号をアサートしないので、前記動作は、そのような命令を命令イネーブル・ブロック１１１３によって再びイネーブルできるようにするために必要である。
ｌｄ＿ｒｅｓ＿ｐａｃがアサートされ、ｎｏ＿ｕｐｄａｔｅがアサートされていないとき、命令更新ブロック１１２３は、結果パケットの命令の「宛先数」フィールド（ＮＤ）を命令更新ブロックの「更新カウンタ」にロードし、更新状態マシンを開始する。オペランド・メモリ８２１を修正するプロセスは、宛先当たり３クロック・サイクルを必要とし、各宛先は順番に処理される。第１クロック・サイクル中に、更新レジスタ内の適当な宛先フィールドの７ビット「命令アドレス」部分によって選択される位置でオペランド・メモリ８２１が読み取られ、取り出された２１ビット・ワードが、３つのレジスタに記憶される。すなわち、５ビット・セマフォ・フィールドは「セマフォ・レジスタ」に記憶され、各８ビット・オペランド・アドレス・フィールドは「オペランド・アドレス・レジスタ」に記憶される。第２クロック・サイクル中に、適当な更新レジスタ宛先フィールドの１ビット「オペランド選択」部分によって選択されるオペランド・アドレス・レジスタの最上位ビットが、「オペランド存在」を示す「１」にセットされ、この同じレジスタの最下位７ビットに更新レジスタの「結果アドレス」フィールドがロードされる。セマフォ・レジスタには、更新レジスタの最上位５ビットがロードされる。最後のクロック・サイクル中に、セマフォ・レジスタおよび２つのオペランド・アドレス・レジスタのそれぞれの内容が、それが読み取られたときと同じ位置でオペランド・メモリ８２１に書き直される。更新カウンタは、宛先が処理されるたびに「１」だけ減分され、このカウンタがゼロになると、命令更新ブロック１１２３が非活動化され、主制御装置ブロック１１２１が命令イネーブル・ブロック１１１３を再開する。
命令更新ブロック１１２３によって最後に処理される宛先命令（もしあれば）のアドレスは、命令イネーブル・ブロック１１１３が再開されるときにこのブロック１１１３に渡され、この命令は、命令イネーブル・ブロック１１１３が最初にイネーブルしようとする命令となる。しかし、この命令のアドレスは、イネーブル命令カウンタｅｎ＿ｃｏｕｎｔｅｒにはロードされない。その後、命令イネーブル・ブロック１１１３は、命令更新ブロック１１２３のために中断されるまで、ｅｎ＿ｃｏｕｎｔｅｒを命令アドレス・ソースとして使用し続ける。
イネーブル済み命令待ち行列（第１２図）
イネーブル済み命令待ち行列８１４（「待ち行列」）は、第１２図にさらに詳しく示されており、更新ユニット８１２とグローバル・バス・インタフェース・ユニット８１６の間のメモリ・バッファとして働く。この待ち行列が必要なのは、通常グローバル・バスユニット８１６が命令およびオペランド・トークンを機能ユニットにディスパッチするのに要する時間中に、いくつかの命令を更新ユニット８１２によってイネーブルすることができるからである。更新ユニット８１２は厳密に待ち行列への書込みを行い、グローバル・バス・インタフェース・ユニット８１６は厳密に待ち行列からの読取りを行う。この待ち行列は、ＦＩＦＯメモリ１２１０、ＦＩＦＯ制御機構１２１２、および待ち行列状況ブロック１２１６の３つの主要なブロックから成る。
ＦＩＦＯメモリ１２１０は４つの７２ビット・レジスタから成る。各レジスタは、１つのイネーブル済み命令パケットを保持することができ、あるレジスタからの読取りを行い、同時に別のレジスタへの書込みを行うことができる。ＦＩＦＯ制御機構１２１２は、ＦＩＦＯメモリ１２１０へのアクセスを「先入れ先出し」的に制御するのに必要な論理機構およびレジスタを含む。これには、”ｌｄ＿ｐｔｒ”と呼ばれる２ビット書込みポインタ、”ｒｄ＿ｐｔｒ”と呼ばれる２ビット読取りポインタ、およびＦＩＦＯメモリ１２１０が空であるか、満杯であるか、それとも、部分的に書き込まれているかを追跡する状態マシンが含まれる。ｌｄ＿ｐｔｒとｒｄ＿ｐｔｒは共にラップアラウンド的に増分し（すなわち、「３」の後に「０」が続く）、ＩＣＣがリセットされたときにゼロにセットされる。状態マシンは、ＦＩＦＯメモリ１２１０が満杯であるときに「イネーブル済み命令待ち行列満杯」（ｅｎ＿ｉｎｓｔ＿ｆｕｌｌ）信号を更新ユニット８１２にアサートし、このユニットがイネーブル済み命令パケットを要求しＦＩＦＯメモリ１２１０が空でないときに「次の命令のロード」（ｌｄ＿ｎｅｘｔ＿ｉｎｓｔ）信号をグローバル・バス・インタフェース・ユニット８１６にアサートする。
更新ユニット８１２は、書込みを要求する前に、ｅｎ＿ｉｎｓｔ＿ｆｕｌｌ信号を検査する。この信号がアサートされていない場合、更新ユニット８１２は、「イネーブル済み命令パケット・ロード」（ｌｄ＿ｅｎ＿ｉｎｓｔ＿ｐａｃ）信号を待ち行列にアサートする。待ち行列は、イネーブル済み命令パケットを、更新ユニット８１２から、ｌｄ＿ｐｔｒによって選択されたＦＩＦＯメモリ１２１０のレジスタにロードすることによって応答し、次いで、ｌｄ＿ｐｔｒが「１」だけ増分される。次いで、ＦＩＦＯ制御機構１２１０は、ＦＩＦＯメモリ１２１０が現在満杯である場合にｅｎ＿ｉｎｓｔ＿ｆｕｌｌをアサートする。
グローバル・バス・インタフェース・ユニット８１６は、「次の命令の読取り」（ｒｄ＿ｎｅｘｔ＿ｉｎｓｔ）信号をアサートすることによって、待ち行列からイネーブル済み命令パケットを要求する。ＦＩＦＯメモリ１２１０が空でない場合、待ち行列は、ｌｄ＿ｎｅｘｔ＿ｉｎｓｔ信号をアサートし、ｒｄ＿ｐｔｒによって選択されたＦＩＦＯメモリ１２１０中のレジスタをグローバル・バス４１６上に出力することによって応答する。次いで、ｒｄ＿ｐｔｒが増分され、ＦＩＦＯ制御機構１２１２内部の状態マシンが、ＦＩＦＯメモリ１２１０が現在空であるかどうかを検査する。
待ち行列状況ブロック１２１６は、どの機能ユニットが待ち行列中に命令を有するかを連続的に監視し、この情報を１１ビット「待ち行列状況」（ｕｎｉｔ＿ｑ＿ｓｔａｔ）出力信号を介して更新ユニット８１２に報告する。待ち行列が、ｕｎｉｔ＿ｑ＿ｓｔａｔ中の当該のビット位置に対応する機能ユニットによって実行すべき命令を含むときは必ず、当該のビットが「１」にセットされる。ビット位置と機能ユニットの対応は、更新ユニット８１２内の命令復号ＲＯＭ１１１１に関する対応と同じである。
グローバル・バス・インタフェース・ユニット（第１３図）
グローバル・バス・インタフェース・ユニット８１６は、４つの主要なブロックの周りに構築される。これらのブロックとは、バス・アービタ１３１０、命令コンポーザ１３１２、スカラ・プロセッサ・ユニット（ＳＰＵ）１３１４、および主制御装置１３２２である。これらのブロックのうちの最初の２つはそれぞれ、ＤＣＵとその他の機能ユニットの間でトークンを受信し、送信する責任を負う。第３のブロックは、トークン記述子を処理するすべての命令を実行することができる。第４のブロックは、イネーブル済み命令待ち行列８１４とのインタフェースをとり、他の３つのブロックのうちのどれを活動化すべきかを判定する。最初の３つのブロックのうちで、一度に活動化できるのは１つだけである。命令コンポーザ１３１２およびスカラ・プロセッサ・ユニット１３１４が優先される。というのは、これらのブロックはトークン・メモリを空にする傾向があるからである。これらのブロックのうちのどちらも機能しておらず、グローバル・バス調停が要求されている場合、バス・アービタ１３１０が機能する。
非ＳＰＵ命令が実行を完了し、その結果トークン（もしあれば）をＤＣＵ４１８に送り返すプロセスは、そのような各命令の機能ユニットがその「アービタ要求」信号（ａｒｂ＿ｒｅｑｕｅｓｔ）を主制御装置１３２２にアサートすることによって開始する。その後、主制御装置１３２２は、バス・アービタ１３１０に通知し、バス・アービタ１３１０は、そのアービタ許可カウンタ（ａｒｂ＿ｇｒａｎｔ＿ｃｏｕｎｔ）の増分を開始する。このカウンタの各状態は、機能ユニットに対応する。このカウンタの状態が、サービスを要求している機能ユニットに一致するとき、カウンタは停止し、主制御装置１３２２が次に、他の機能ユニットに応答するようバス・アービタ１３１０に通知するまでその状態のままである。この機構によって、各機能ユニットは同様にグローバル・バス４１６にアクセスすることができる。バス・アービタ１３１０は次いで、一致する機能ユニットの「プロセッサ・パケット送信」信号（ｐｒｏｃ＿ｐａｃ＿ｌｄ＿ｏｕｔ）をアサートし、次いで、この機能ユニットが「プロセッサ・パケット準備完了」信号（ｐｒｏｃ＿ｐａｃｋｅｔ＿ｒｅａｄｙ）およびプロセッサ・パケット自体をグローバル・バス４１６上でアサートすることによって応答するのを待つことによって、プロセッサ・パケットを送信することをこの機能ユニットに要求する。プロセッサ・パケットは、第３Ｆ図に示したようにフォーマットされる。
バス・アービタ１３１０は、プロセッサ・パケットを読み取り、機能ユニットが送信したいトークン・データの語の数を判定する。この機能ユニットが結果トークンを有する場合、バス・アービタ１３１０は、トークン・メモリ・ユニット８１０にそのトークン用のメモリ空間を割り当てさせ、選択されたこの機能ユニットに「アービタ許可」信号（ａｒｂ＿ｇｒａｎｔ）信号をアサートする。バス・アービタ１３１０は次いで、この機能ユニットが「データ・レディ」信号（ｄａｔａ＿ｒｅａｄｙ）をアサートしグローバル・バス４１６を介してトークン・データを送信するのを待つ。グローバル・バス４１６を介して転送されるすべての語は、トークン・メモリ・ユニット８１０へ、記憶するために送信される。転送の終わりは、機能ユニットがｄａｔａ＿ｒｅａｄｙをアサート解除することによって通知され、バス・アービタ１３１０はその後、ａｒｂ＿ｇｒａｎｔをアサート解除する。
バス・アービタ１３１０は、機能ユニットから送信されたプロセッサ・パケットで「結果パケット」も形成し、更新ユニット８１２へ送信する。結果パケットは、第３Ｂ図に示したようにフォーマットされ、実行を終了した命令のアドレスと、トークン・メモリ・ユニット８１０中のトークンの記憶域アドレスと、結果トークンのトークン記述子のｃｎｔｒｌフィールドのビット３：０およびｎｂｌｏｃｋｓフィールドのビット１とから成る。後者の５ビットは、ＴＳＴＳＥＭセマフォ命令およびＴＳＴＤＥＣセマフォ命令を実行する際に更新ユニット８１２によって使用される。
制御ユニットからのトークンの転送は、命令コンポーザ１３１２によって行われる。主制御装置はまず、「次の命令の読取り」信号（ｒｄ＿ｎｅｘｔ＿ｉｎｓｔ）をアサートして命令待ち行列８１４をイネーブルする。
イネーブル済み命令待ち行列８１４は、新しい命令を出力する準備が完了すると、「次の命令のロード」（ｌｄ＿ｎｅｘｔ＿ｉｎｓｔ）を主制御装置１３２２にアサートし、その命令のイネーブル済み命令パケットが命令パケット・レジスタ１３２０にロードされる。次いで、主制御装置１３２２は、命令コンポーザ１３１２およびＳＰＵ１３１４に「コンポーザ」をアサートし、これらのユニットが、命令パケット・レジスタ１３２０の「命令復号化ＲＯＭ」フィールドを調べて、命令を実行するのにどの機能ユニットが必要であるかを判定する。
命令がスカラ・プロセッサ・ユニット１３１４によって実行されるものでない場合、命令コンポーザ１３１２が活動化される。命令コンポーザ１３１２の動作状態は、ｒｅａｄ＿ｃｎｔと呼ばれる４ビット・カウンタの内容によって与えられる。命令コンポーザ１３１２がアイドル状態であるときは常に、ｒｅａｄ＿ｃｎｔカウンタはゼロである。ｒｅａｄ＿ｃｎｔがゼロでないときは必ず、命令コンポーザ１３１２は、「コンポーザ・ビジー」（ｃｏｍｐｏｓｅｒ＿ｂｕｓｙ）信号を主制御装置１３２２にアサートする。ｓｅｎｄ＿ｃｎｔと呼ばれる他のカウンタは、命令コンポーザ１３１２がグローバル・バス４１６を介して機能ユニットに渡す語をカウントするために命令コンポーザ１３１２によって使用される。ｒｅａｄ＿ｃｎｔとｓｅｎｄ＿ｃｎｔは共に、命令コンポーザ１３１２が活動化されるときゼロにセットされる。ｎｕｍ＿ｂｌｏｃｋｓと呼ばれる他のレジスタの内容とカウンタｓｅｎｄ＿ｃｎｔを比較して、いつグローバル・バス転送が終了するかが判定される。
命令コンポーザ１３１２は、活動化された後、命令パケット・レジスタ１３２０中の「オペランド数」（ＮＯ）フィールドを調べることによって、命令が必要とするトークン・オペランドの数を判定する。オペランドが必要とされない場合、命令コンポーザ１３１２は単に、命令パケット・レジスタ１３２０の内容から、第３Ｅ図に示したフォーマットのプロセッサ・パケットを作成し、「データ・レディ」（ｄａｔａ＿ｒｅａｄｙ）信号および「プロセッサ・パケット・ロード」（ｐｒｏｃ＿ｐａｃ＿ｌｄ）信号と共にグローバル・バス４１６上にアサートする。同時に、ｒｅａｄ＿ｃｎｔとｓｅｎｄ＿ｃｎｔが共に値「１」に増分される。次のクロック・エッジで、前記カウンタが共にゼロにセットされ、命令コンポーザ１３１２が、ｃｏｍｐｏｓｅｒ＿ｂｕｓｙをアサート解除することによって、終了したことを主制御装置１３２２に通知する。
１つまたは２つのトークン・オペランドが必要である場合、命令コンポーザ１３１２は、「データ・メモリ読取り」（ｒｅａｄ＿ｄｍｅｍ）信号をトークン・メモリ・ユニット８１０にアサートし、命令パケット・レジスタ１３２０から第１のオペランドのアドレスを抽出し、バスｄｍｅｍ＿ａｄｄｒを介してトークン・メモリ・ユニット８１０へ送信する。ｒｅａｄ＿ｃｎｔも、次の立上りクロック・エッジで値「１」に増分する。次いで、トークン・メモリ・ユニット８１０が、次の２クロック周期中に、指定されたアドレスにあるトークン・ヘッダを読み取り、各立上りクロック・エッジでｒｅａｄ＿ｃｎｔが増分する。ｒｅａｄ＿ｃｎｔが「３」であるとき、トークン・ヘッダはレジスタに存在し、命令コンポーザ１３１２は、このトークン・ヘッダを使用して、トークンがデータ・トークンであるかどうかを判定し、そうである場合、トークンがトークン・メモリ・ユニット８１０に記憶したデータ・ブロックの数を判定する。ブロックの数は、ｎｕｍ＿ｂｌｏｃｋｓレジスタに記憶される。次いで、ｒｅａｄ＿ｃｎｔカウンタが値「４」に増分し、ｓｅｎｄ＿ｃｎｔが値「１」に増分する。ｒｅａｄ＿ｃｎｔが「４」であり、ｓｅｎｄ＿ｃｎｔが「１」である間、命令コンポーザ１３１２は、命令パケット・レジスタ１３２０の内容からプロセッサ・パケットを作成し、適当な機能ユニットへの「データ・レディ」（ｄａｔａ＿ｒｅａｄｙ）信号および「プロセッサ・パケット・ロード」（ｐｒｏｃ＿ｐａｃ＿ｌｄ）信号と共にグローバル・バス４１６上にアサートする。同時に、ｒｅａｄ＿ｃｎｔとｓｅｎｄ＿ｃｎｔが共に値「１」に増分される。次のクロック・サイクルの立上りで、ｒｅａｄ＿ｃｎｔが「５」に増分し、ｓｅｎｄ＿ｃｎｔが「２」に増分し、そのサイクルの間に、ｐｒｏｃ＿ｐａｃ＿ｌｄがアサート解除され、命令コンポーザ１３１２が、トークンのトークン記述子をグローバル・バス４１６を介して適当な機能ユニットへ送信するようトークン・メモリ・ユニット８１０に命令する。トークンが制御トークンである場合、第１のトークン・オペランドに関する転送はこの点で終了する。そうでない場合、トークン・メモリ・ユニット８１０は、トークンのブロック割振りユニットからトークンのデータ・ブロックを読み取り、グローバル・バス４１６を介して機能ユニットへ送信する。ｓｅｎｄ＿ｃｎｔカウンタは、語が転送されるたびに増分する。
命令が１つのオペランド・トークンしか必要としない場合、ｒｅａｄ＿ｃｎｔカウンタは、ｓｅｎｄ＿ｃｎｔが（ｎｕｍ＿ｂｌｏｃｋｓ×８）＋２に等しくなるまで値「５」のままである。このクロック・サイクル中に、最後の語が転送され、ｒｅａｄ＿ｃｎｔがゼロにセットされる。次のクロック・サイクル中に、ｄａｔａ＿ｒｅａｄｙがアサート解除され、命令コンポーザ１３１２がアイドル状態になる。
これに対して、命令が第２のオペランドも必要とする場合、ｓｅｎｄ＿ｃｎｔが（ｎｕｍ＿ｂｌｏｃｋｓ×８）−１に等しいクロック・サイクル中に、ｒｅａｄ＿ｃｎｔが値「６」に増分する。次のクロック・サイクルの間、ｒｅａｄ＿ｃｎｔは「６」であり、命令コンポーザ１３１２は、トークン・メモリ・ユニット８１０に、第２のオペランド・トークンの読取りを前記トークンのヘッダから開始するよう要求する。メモリ・パイプラインの遅延を補償し、第１のオペランドの最後のデータ記述子の直後に、グローバル・バス４１６上の第２のオペランドのトークン記述子が続くようにするために、この要求は、トークン・メモリ・ユニット８１０によって第１のオペランドの最後の語が出力される２クロック・サイクル前に行われる。第１のオペランドの最後の２つの語の転送中に、ｒｅａｄ＿ｃｎｔカウンタはそれぞれ、値「７」および「８」を有する。ｒｅａｄ＿ｃｎｔが「９」であるクロック・サイクル中に、トークン・メモリ８１０は、第２のオペランドのトークン記述子をグローバル・バス４１６上で出力する。第２のオペランドが制御トークンである場合、ｒｅａｄ＿ｃｎｔは前記クロック・サイクルおよび次のサイクル中にゼロにセットされ、ｄａｔａ＿ｒｅａｄｙがアサート解除され、命令コンポーザ１３１２がアイドル状態になる。そうでない場合、ｒｅａｄ＿ｃｎｔは、「１０」に増分し、トークン・メモリ８１０がグローバル・バス４１６を介する第２のオペランドの残りの部分の転送を終了するまでこの状態のままとなる。最後の転送中に、ｒｅａｄ＿ｃｎｔがゼロにセットされ、命令コンポーザ１３１２が次のクロック・サイクルからアイドル状態になる。
スカラ・プロセッサ・ユニット
スカラ・プロセッサ・ユニット１３１４（”ＳＰＵ”）は、主制御装置１３２２から「コンポーズ」信号を受け取り、スカラ命令またはセマフォ命令を復号することによって活動化される。これが行われると、ＳＰＵは、「スカラ・ビジー」（ｓｃａｌａｒ＿ｂｕｓｙ）信号で主制御装置１３２２に応答する。
ＳＰＵは、命令を３つのフェーズで実行する。第１フェーズで、命令は復号され、必要なトークン・オペランドがトークン・メモリ・ユニット８１０（”ＴＭＵ”）から読み取られる。ＳＰＵによって実際に読み取られ作用されるのはトークン記述子だけである。なぜなら、ＳＰＵはオペランド・トークン内のＢＡＵの内容を修正することができないからである。命令が１つまたは２つのオペランド・トークンを有する場合、ＳＰＵは、トークンのアドレスを７ビットｄｍｅｍ＿ａｄｄｒバス上に置き、「記述子読取り」（ｒｅａｄ＿ｄｅｓｃｒ）信号をアサートすることによって、各トークンを順番にＴＭＵに要求する。
第２フェーズで、命令が実行され、結果トークン（もしあれば）がＴＭＵへ送信され、結果パケットが更新ユニット８１２へ送信される。ＳＰＵは、トークン記述子の内容に作用する必要がある場合、実行中の命令が必要とする記述子フィールドを抽出し、両方の記述子フィールドと関数符号を２５ビット幅ＡＬＵへ送信する。ＡＬＵは次いで、その関数（加算、減算、ブール、または比較）を実行し、必要に応じて、出力を使用して結果トークンのトークン記述子を形成する。ある種のケース（たとえば、ＤＧＡＴＥ１命令）では、ＳＰＵは、ＡＬＵの出力を使用して、結果トークンを作成するかどうかを決定する。ＳＰＵは次いで、「スカラ・パケット・ロード」信号（ｌｄ＿ａｕｘ＿ｐａｃ）をアサートすることによってＴＭＵに通知し、結果トークンのトークン記述子（もしあれば）、終了した命令のアドレスおよび「宛先数」フィールド、および３ビット・スカラ制御パケット（ａｕｘ＿ｃｏｎｔｒｏｌ）をＴＭＵへ送信する。
スカラ制御パケット中の３ビットを”ｗｒｉｔｅ＿ｄｅｓｃｒ”、”ｃｏｐｙ＿ｏｐｅｒａｎｄ”、および”ｄｉｓｃａｒｄ＿ｏｐｅｒａｎｄ”と呼び、このうちの１つだけが「１」にセットされる。ｗｒｉｔｅ＿ｄｅｓｃｒビットは、ＳＰＵが、ＴＭＵに、ＳＰＵの結果トークン記述子を使用して結果トークンを作成させたい場合にセットされる。オペランド・トークンのＢＡＵは結果トークンには関連付けられない。ｃｏｐｙ＿ｏｐｅｒａｎｄビットは、ＳＰＵが、ＴＭＵに、ＳＰＵの第１の（または唯一の）オペランド・トークンに関連するＢＡＵアドレス・フィールドを、結果トークンに関連する同じフィールドにコピーすることによって、結果データ・トークンを作成させたい場合にセットされる。このように、ＳＰＵは、オペランド・データ・トークンのＢＡＵを実際には読み取らずに「コピー」し、それによって、グローバル・バス４１６上の負荷を低減させる。最後に、ｄｉｓｃａｒｄ＿ｏｐｅｒａｎｄビットは、ＳＰＵが、ＴＭＵに、結果トークンを作成させたくない場合にセットされる。
最後の第３フェーズで、ＳＰＵは更新ユニット８１２に結果パケットを送り、また結果トークンが生成されなかった場合にはｎｏ＿ｕｐｄａｔｅ信号をアサートする。
データ・トークン・メモリ・ユニット（第１４図）
トークン・メモリ・ユニット８１０（”ＴＭＵ”）は、命令を実行した結果得られたトークン用のメモリ空間を割り振り、割振り解除し、かつ前記メモリ空間に対して読取りおよび書込みを行う。第１４図に図示したこのユニットの主要なブロックは、メモリ制御機構１４１４、ヘッダ・メモリ８２０、ＢＡＵメモリ８１８、トークン・アドレス・メモリ８１９、ヘッダ・スタック１４１６、ＢＡＵスタック１４１８、ヘッダ使用メモリ１４１１、およびＢＡＵ使用メモリ８２２である。
トークン・メモリ・ユニット８１０は、合計で１２８個の制御トークンおよびデータ・トークンを収容することができる。ヘッダ・メモリ８２０は、幅９６ビットで長さ１２８語であり、各語は、１つのトークンの９６ビット・トークン記述子を記憶することができる。データ・トークンのデータ・ブロック部分は、ＢＡＵメモリ８１８内のブロック割振りユニット（ＢＡＵ）に記憶される。各ＢＡＵは、最大２つの８語×９６ビット・データ・ブロックを記憶することができ、ＢＡＵメモリ８１８は、最大６４個のＢＡＵを記憶することができる。データ・トークンにＢＡＵが割り振られるとき、各トークンが必要とするデータ・ブロックの数に応じて、各トークンに１つまたは２つのＢＡＵ全体が割り振られる。所定のＢＡＵの未使用部分は、他のトークンには割り当てられない。
トークン・アドレス・メモリ８１９は、幅が２３ビットであり、長さが１２８語である。各語は、第３Ｄ図に示したようにフォーマットされ、１つの制御トークンまたはデータ・トークンに対応する。所与のトークンの場合、トークン・アドレス・メモリ８１９中の前記トークンに対応する語は、前記トークンを作成した命令のアドレスと、前記トークンのデータ・ブロックを記憶しているＢＡＵの数（トークンが制御トークンである場合は０であり、データ・トークンである場合は１または２である）を記憶し、トークンがデータ・トークンである場合はＢＡＵメモリ８１８中の前記トークンのＢＡＵのアドレスも記憶する。第３Ｄ図中の２つのＢＡＵアドレス・フィールドのそれぞれは、長さ７ビットであり、最大１２８個のＢＡＵを収容する。これに対して、ＢＡＵメモリ８１８の現行の実施態様では、６４個のＢＡＵしか記憶されない。
ヘッダ・スタック１４１６は、幅７ビット・長さ１２８語の後入れ先出し（ＬＩＦＯ）メモリであり、現在、新しいトークンに割り当てることができる、ヘッダ・メモリ８２０中のトークン記述子のアドレスを記憶する。現在、ＬＩＦＯメモリの「１番上」にある語のアドレスは、７ビット・ヘッダ・スタック・ポインタ・レジスタ（ｈｅａｄｅｒ＿ｓｔａｃｋ＿ｐｔｒ）の内容によって与えられ、ｈｅａｄｅｒ＿ｓｔａｃｋ＿ｐｔｒが指す語の内容もヘッダ割振りアドレス・レジスタ（ｈｅａｄｅｒ＿ａｌｌｏｃ＿ａｄｄｒ）に記憶される。ＩＣＣ４１０が最初にリセットされるとき、ヘッダ・スタック１４１６中の１２８語のそれぞれに、そのアドレスに対応する値が書き込まれる。たとえば、アドレス６７の語には値「６７」が書き込まれる。ｈｅａｄｅｒ＿ｓｔａｃｋ＿ｐｔｒレジスタおよびｈｅａｄｅｒ＿ａｌｌｏｃ＿ａｄｄｒレジスタも共に、ゼロに初期設定される。
ＢＡＵスタック１４１８は、別の幅７ビット・長さ１２８語の後入れ先出し（ＬＩＦＯ）メモリであり、現在、新しいトークンに割り当てることができる、ＢＡＵメモリ８１８中のＢＡＵのアドレスを記憶する。トークン・アドレス・メモリ８１９中のＢＡＵアドレス・フィールドと同様に、ＢＡＵスタック１４１８は、最大１２８個のＢＡＵを収容するサイズを有する。現在、ＬＩＦＯメモリの「１番上」にある語のアドレスは、７ビットＢＡＵスタック・ポインタ・レジスタ（ＢＡＵ＿ｓｔａｃｋ＿ｐｔｒ）の内容によって与えられ、ＢＡＵ＿ｓｔａｃｋ＿ｐｔｒが指す語の内容もＢＡＵ割振りアドレス・レジスタ（ＢＡＵ＿ａｌｌｏｃ＿ａｄｄｒ）に記憶される。ＩＣＣ４１０が最初にリセットされるとき、ＢＡＵスタック１４１８中の１２８語のそれぞれに、そのアドレスに対応する値が書き込まれる。ＢＡＵ＿ｓｔａｃｋ＿ｐｔｒレジスタおよびＢＡＵ＿ａｌｌｏｃ＿ａｄｄｒレジスタも共に、ゼロに初期設定される。
ヘッダ使用メモリ１４１１は、幅２ビットで長さ１２８語であり、制御トークンまたはデータ・トークン当たり１つの位置を有する。ヘッダ使用メモリ１４１１は、トークンがいつＩＣＣプログラム中のトークンの各宛先命令によって「消費」されたかを判定するためにトークン・メモリ・ユニット８１０によって使用される。各位置は、依然としてトークンを使用する必要があるＩＣＣプログラム中の宛先の数をカウントし、トークンを作成した命令から得た「宛先数」（ＮＤ）フィールドのコピーによって初期設定される。トークン・メモリ・ユニット８１０は、命令コンポーザ１３１２またはスカラ・プロセッサ・ユニット１３１４へ、命令オペランドとして使用すべきトークンを送信するたびに、ヘッダ使用メモリ１４１１中のトークンの「使用率カウント」を減分する。このカウントがゼロになると、トークンは、もはや命令から必要とされず、ヘッダ・メモリ８２０から割り振り解除される。
ＢＡＵ使用メモリ８２２は、幅４ビットで長さ１２８語であり、ＢＡＵ当たり１つの位置を有する。ＢＡＵ使用メモリ８２２は、ＢＡＵスタック１４１８と同様に、最大１２８個のＢＡＵを収容する寸法を有する。これに対して、ＢＡＵメモリ８１８の現行の実施態様では、６４個のＢＡＵしか記憶されない。このメモリが存在するのは、複数のトークンを同じＢＡＵに関連付けることができ、メモリ中の各位置が、対応するＢＡＵを依然として参照するトークンの数をカウントするからである。複数のトークンが同じＢＡＵを参照する状況は、ＩＣＣ命令がグローバル・バス・インタフェース・ユニット８１６内のスカラ・プロセッサ・ユニット１３１４（”ＳＰＵ”）によって処理されるときに発生する。各ＳＰＵ命令は常に、データ・トークン・オペランドに関連するデータ・ブロックを破棄し、あるいは、前記データ・ブロックをＳＰＵ命令の結果トークンにコピーする。しかし、データ・ブロックのコピーは、物理的にデータを移動するのではなく、トークン・アドレス・メモリ８１９中の結果トークンのＢＡＵアドレス・フィールドを適当なオペランド・トークンのＢＡＵアドレス・フィールドと同じになるようにセットすることによって行われる。スカラ命令が、１つまたは２つのＢＡＵを参照する結果トークンを作成するたびに、ＢＡＵ使用メモリ８２２中の対応する「使用率カウント」が増分される。同様に、トークンが割振り解除されるときは常に、それに対応するＢＡＵ使用率カウントが減分される。ＢＡＵの使用率カウントがゼロに減分されると、ＢＡＵはもはやトークンから必要とされず、ＢＡＵメモリ８１８から割振り解除される。
グローバル・バス・インタフェース・ユニット８１６は、命令を実行することから得た結果トークンを有するとき、トークン・メモリ・ユニット８１０に「データ書込み」（ｗｒ＿ｄａｔａ）信号をアサートする。しかし、グローバル・バス・インタフェース・ユニット８１６は、トークンを送信する前に、トークン・メモリ・ユニット８１０に、トークンに空間を割り振るよう命令する。トークン割振りプロセスは、メモリ制御機構１４１４が、ｈｅａｄｅｒ＿ａｌｌｏｃ＿ａｄｄｒの現内容を７ビット幅メモリ・アドレス・レジスタ（ｄｍｅｍ＿ａｄｄｒ＿ｒｅｇ）にロードし、ヘッダ・スタック１４１６に「ヘッダ割振り」信号をアサートすることによって開始する。ヘッダ・スタック１４１６は、これに応答して、ｈｅａｄｅｒ＿ｓｔａｃｋ＿ｐｔｒを増分し、ＬＩＦＯメモリのそのアドレスの内容を読み取り、その内容をｈｅａｄｅｒ＿ａｌｌｏｃ＿ａｄｄｒに書き込むことによって、ヘッダ・スタックのＬＩＦＯメモリから語を「ポップ」する。ｈｅａｄｅｒ＿ｓｔａｃｋ＿ｐｔｒがオーバフローした場合（すなわち、ｈｅａｄｅｒ＿ｓｔａｃｋ＿ｐｔｒが「１２７」から「０」に「ロールオーバ」する）、ヘッダ・スタック１４１６は満杯であり、ＤＣＵ４１８の他の部分に対してエラー信号が生成される。
次に、結果トークンを作成した命令の「宛先数」（ＮＤ）フィールドのコピーが、ｄｍｅｍ＿ａｄｄｒ＿ｒｅｇの指すヘッダ使用メモリ１４１１の位置に書き込まれ、その命令のアドレスが保持レジスタに書き込まれる。結果トークンが制御トークンである場合、保持レジスタ・アドレスが「命令アドレス」フィールドに書き込まれ、ｄｍｅｍ＿ａｄｄｒ＿ｒｅｇの指す位置にあるトークン・アドレス・メモリ８１９中の「ＢＡＵ数」フィールドにゼロが書き込まれる。
結果トークンがデータ・トークンである場合、メモリ制御機構１４１４は、ＢＡＵ＿ａｌｌｏｃ＿ａｄｄｒの現内容を７ビット幅ＢＡＵアドレス・レジスタ（ＢＡＵ＿ａｄｄｒ＿ｒｅｇ）にロードすることによってトークン用のＢＡＵを割り振り、ＢＡＵスタック１４１８に「ＢＡＵ割振り」信号をアサートする。ＢＡＵスタック１４１８は、これに応答して、ＢＡＵ＿ｓｔａｃｋ＿ｐｔｒを増分し、ＬＩＦＯメモリのそのアドレスの内容を読み取り、その内容をＢＡＵ＿ａｌｌｏｃ＿ａｄｄｒに書き込むことによって、ＢＡＵスタックのＬＩＦＯメモリから語を「ポップ」する。ＢＡＵ＿ａｄｄｒ＿ｒｅｇの指すＢＡＵ使用メモリ８２２の位置に値「１」が書き込まれる。グローバル・バス・インタフェース・ユニット８１６中のバス・アービタ１３１０からの「ブロック数」（ｎｂｌｏｃｋ）信号が、他のＢＡＵが必要であることを示す場合、ＢＡＵ＿ａｄｄｒ＿ｒｅｇの内容が他のレジスタに保存され、第２のＢＡＵのアドレスがＢＡＵスタック１４１８から同様に読み取られる。ＢＡＵ使用メモリ８２２も更新される。ＢＡＵ＿ｓｔａｃｋ＿ｐｔｒがオーバフローした場合（すなわち、ＢＡＵ＿ｓｔａｃｋｐｔｒが値「６４」に達する）、ＢＡＵスタック１４１８は満杯であり、ＤＣＵ４１８の他の部分に対してエラー信号が生成される。
データ・トークンの割り振りの最後のステップは、保持レジスタに記憶された命令アドレスを、新たに割り振られたＢＡＵのアドレスおよびＢＡＵの数と共に、ｄｍｅｍ＿ａｄｄｒ＿ｒｅｇの指すトークン・アドレス・メモリ８１９の位置に書き込むことである。
また、制御トークンでもデータ・トークンでも、ｄｍｅｍ＿ａｄｄｒ＿ｒｅｇの内容は、バス・アービタ１３１０に返され、そのため、この結果は、バス・アービタ１３１０が更新ユニット８１２へ送信する結果パケットに含めることができる。
制御トークンまたはデータ・トークンが割り振られた後、グローバル・バス・インタフェース・ユニット８１６は、グローバル・バス４１６を介して書込みを行う。トークンのトークン記述子はヘッダ・メモリ８２０に書き込まれ、トークンのデータ・ブロック（もしあれば）は、ＢＡＵメモリ８１８の割り振られたアドレスに書き込まれる。
また、グローバル・バス・インタフェース・ユニット８１６は、トークンを、命令実行時に使用できるようにトークン・メモリ・ユニット８１０から読み取る。非ＳＰＵ命令の場合、グローバル・バス・インタフェース・ユニット８１６内の命令コンポーザ１３１２は、メモリ制御機構１４１４に「メモリ・アドレス・ロード」（ｌｄ＿ｄｍｅｍ＿ａｄｄｒ）信号をアサートし、読み取るべきトークンのアドレスを７ビット「メモリ・アドレス・バス」（ｄｍｅｍ＿ａｄｄｒ）を介してＴＭＵのメモリ・アドレス・レジスタ（ｄｍｅｍ＿ａｄｄｒ＿ｒｅｇ）にロードすることによって、トークン・メモリ・ユニット８１０にトークンを要求する。メモリ制御機構１４１４は次いで、アドレスされたトークン記述子をヘッダ・メモリ８２０から読み取り、トークン使用率カウントをヘッダ使用メモリ１４１１から読み取り、ＢＡＵの数、ＢＡＵアドレス、およびトークンを作成した命令のアドレスをトークン・アドレス・メモリ８１９から読み取る。後者のデータはすべてレジスタに記憶される。次いで、トークン使用率カウントを記憶しているレジスタが１だけ減分され、結果がヘッダ使用メモリ１４１１に書き込まれる。減分された使用率カウントがゼロである場合、メモリ制御機構１４１４は、ヘッダ・スタック１４１６に「ヘッダ割振り解除」信号（ｈｅａｄｅｒ＿ｄｅ＿ａｌｌｏｃ）をアサートし、トークンのアドレスをヘッダ・スタックへ送信することによって、トークンを割振り解除する。ヘッダ・スタック１４１６は次いで、そのＬＩＦＯメモリ上にアドレスを「プッシュ」する。同時に、メモリ制御機構１４１４は、更新ユニット８１２に「割振り解除」信号（ｄｅ＿ａｌｌｏｃ＿ｏｕｔ）をアサートし、割振り解除済みトークンを作成した命令のアドレスも更新ユニットに送信する。前記アドレスは、対応する命令に「非ビジー状態」のマークを付けるために更新ユニット８１２によって使用される。読み取り中のトークンがデータ・トークンである場合、メモリ制御機構１４１４は、トークン中のデータ・ブロックの数と、第１のＢＡＵのアドレスもＢＡＵメモリ８１８へ送信する。
次いで、トークン記述子は、グローバル・バス４１６上にドライブされる。トークンが制御トークンである場合、現トークンに関してはバス４１６上で他の転送は行われない。必要な数の９６ビット語がＢＡＵメモリ８１８の第１のＢＡＵのアドレスから順に読み取られ、各語がグローバル・バス４１６上にドライブされる。トークン中のデータ・ブロックの数が２つ以上である場合、ＢＡＵの１６語がすべて読み取られ、そうでない場合、８語のみが読み取られる。ＢＡＵを読み取っている間、ＢＡＵ使用メモリ８２２中のＢＡＵの使用率カウントは１だけ減分される。減分された使用率カウントがゼロである場合、メモリ制御機構１４１４は、ＢＡＵのアドレスをＢＡＵスタック１４１８へ送信することによってＢＡＵを割振り解除し、ＢＡＵスタックはその後、そのＬＩＦＯメモリ上にアドレスをプッシュする。
トークン中のデータ・ブロックの数が３つまたは４つである場合、トークンの第２のＢＡＵアドレスにあるＢＡＵが読み取られ、各語がグローバル・バス４１６上にドライブされる。トークン中のデータ・ブロックの数が４つである場合、ＢＡＵの１６語がすべて読み取られ、そうでない場合、８語のみが読み取られる。第１のＢＡＵの場合と同様に、第２のＢＡＵが読み取られている間、第２のＢＡＵの使用率カウントは１だけ減分される。減分された使用率カウントがゼロである場合、メモリ制御機構１４１４は、ＢＡＵのアドレスをＢＡＵスタック１４１８へ送信することによってＢＡＵを割振り解除し、ＢＡＵスタックはその後、そのＬＩＦＯメモリ上にアドレスをプッシュする。
スカラ・プロセッサ・ユニット１３１４は、スカラ命令またはセマフォ命令を実行する際にＴＭＵの特別な相互作用を必要とする。ＳＰＵは、オペランドＢＡＵの内容を修正することができず、その内容を結果トークンにコピーし、あるいは破棄する。最初に、命令が１つまたは２つのオペランド・トークンを有する場合、ＳＰＵは、オペランド・トークンのアドレスを７ビットｄｍｅｍ＿ａｄｄｒバス上に置き、「記述子読取り」（ｒｅａｄ＿ｄｅｓｃｒ）信号をアサートすることによって各トークンを順にＴＭＵに要求する。ＴＭＵは、各トークンのトークン記述子をヘッダ・メモリ８２０から読み取り、グローバル・バス４１５を介してＳＰＵへ送信する。各トークンのＢＡＵはもしあっても読み取られない。ヘッダ使用メモリ１４１１中の適当なトークン使用率カウントが減分され、前述の方法を使用して必要に応じて記述子が割振り解除される。さらに、第２のオペランド・トークンに関連するいずれかのＢＡＵのＢＡＵ使用率カウントが減分され、必要ならばそのＢＡＵが割振り解除される。しかし、ＴＭＵは第１のオペランド・トークンのＢＡＵアドレスおよび名前をトークン・アドレス・メモリ８１９から読み取り、ＳＰＵ命令が実行を終了したときに使用できるように「ＢＡＵアドレス・レジスタ」に保存する。
ＳＰＵ命令が終了すると、ＳＰＵは、「スカラ・パケット」信号（ｌｄ＿ａｕｘ＿ｐａｃ）をアサートし、結果トークンのトークン記述子（もしあれば）、終了した命令のアドレスおよび「宛先数」フィールド、ならびに３ビット・スカラ制御パケット（ａｕｘ＿ｃｏｎｔｒｏｌ）をＴＭＵへ送信することによってＴＭＵに通知する。パケット中の３ビットを”ｗｒｉｔｅ＿ｄｅｓｃｒ”、”ｃｏｐｙ＿ｏｐｅｒａｎｄ”、および”ｄｉｓｃａｒｄ＿ｏｐｅｒａｎｄ”と呼び、これらのうちの１つだけが「１」にセットされる。
ＴＭＵは、新しいトークン記述子用の記憶域を割り振り、記述子を適切に記憶し、記述子のアドレスをＳＰＵに返すことによって、ｗｒｉｔｅ＿ｄｅｓｃｒが「１」にセットされたことに応答する。また、ＳＰＵ命令がデータ・トークン・オペランドを有していた場合、ＴＭＵは、アドレスがＢＡＵアドレス・レジスタに記憶されているＢＡＵのＢＡＵ使用率カウントを減分し、必要に応じて割振り解除する。
ｗｒｉｔｅ＿ｄｅｓｃｒと同様に、ｃｏｐｙ＿ｏｐｅｒａｎｄビットは、ＴＭＵに、新しいトークン記述子用の記憶域を割り振らせ、記述子をヘッダ・メモリ８２０に記憶させ、記述子のアドレスをＳＰＵに返させる。しかし、ｃｏｐｙ＿ｏｐｅｒａｎｄは次いで、ＴＭＵに、トークン・アドレス・メモリ８１９中の新しいトークンの位置の「ＢＡＵ数」フィールドおよびＢＡＵアドレス・フィールドにＢＡＵアドレス・レジスタの内容をコピーさせる。ＳＰＵ命令のオペランド・トークンが以前に割振り解除されていない場合、これらのＢＡＵアドレスにあるＢＡＵ使用率カウントも１だけ増分される。
最後に、ｄｉｓｃａｒｄ＿ｏｐｅｒａｎｄが「１」にセットされた場合、ＴＭＵは、新しいトークン記述子用の空間を割り振らず（何れも必要でないため）、ＢＡＵアドレス・レジスタから得たアドレスにある使用率カウントが１だけ減分される。次いで、必要に応じて、対応するＢＡＵが割振り解除される。
ＤＣＴプロセッサ・ユニット（第１５図）
ＤＣＴユニット４２４は、いくつかの８×８データ・ブロックから成るデータ・トークンに対して順方向離散余弦変換および逆離散余弦変換を実行する。８×８データ・ブロックの二次元ＤＣＴは、結果的に得られるデータ・ブロックの行を変換し、その後列を変換することによって行われる。
着信データ・トークンおよび処理すべき命令は、グローバル・バス状態マシン１５１０を介してＤＣＵ４１８から受信される。データ・トークンは、トークン・バッファ１５１２に保存される。処理は、データ・トークンをＤＣＴプロセッサ１５１４を通過させることによって開始する。第１段処理（行変換）の結果は、中間行バッファ１５１６に保存される。処理は、マルチプレクサ１５１８を使用して行バッファの内容を再びプロセッサを通過させることによって完了する。この結果は、ＤＣＵ４１８へ送信できるように再びトークン・バッファに記憶される。
グローバル・バス制限状態マシン
グローバル・バス制御状態マシンは、ＤＣＴユニット中の主シーケンサとして働く。第１６図は、グローバル・バス制御状態マシンの状態遷移図を示す。インタフェース・プロトコルをサポートするには８つの状態が必要である。また、状態マシンは、命令用のレジスタ記憶域とトークン・ヘッダ（すなわち、トークン記述子）用のレジスタ記憶域を統合する。グローバル・バス４１６上の他の処理ユニットで類似の状態マシンが使用される。
９６ビット二方向グローバル・バスは、８つの１２ビット・データ値を含む。順方向ＤＣＴ機能では、各１２ビット・データは、適切に符号拡張された９ビット画像画素を含む。
グローバル・バス制御状態マシンは、リセット後アイドル状態から開始する。この状態で、グローバル・バス制御状態マシンは、ＤＣＵ４１８からの入力シーケンスに関してグローバル・バスを監視し、出力シーケンスに関して内部状況フラグＯＴＫＮ＿ＲＤＹおよびＥＲＲＯＲを監視する。ＧＢ＿ＤＡＴＡ−ＲＤＹ＿が活動状況になることにより、ＤＣＵ４１８によって入力シーケンスが開始されたことが示されると、ＩＮＳＴレジスタに命令語が保存され、その後、状態マシンがヘッダ受信状態に遷移する。グローバル・データ・バスは、ＩＮＳＴレジスタにロードされる。ヘッダ受信状態によって、グローバル・データ・バスに含まれるデータは、ＨＤＲレジスタにロードされる。データ・トークン中に含まれるデータ・ブロックの数よりも１だけ少ない数がヘッダ情報から抽出され、この数は、ＭＡＸ＿ＢＬＫＣＮＴと呼ばれる。ヘッダ受信状態では、６ビット・グローバル・バス転送サイクル・カウンタ（ＧＢ＿ＣＹＣ＿ＣＮＴ）がイネーブルされて０からカウントし、トークンＲＡＭアドレス経路中のパイプラインとして働く。６ビット・グローバル・バス転送サイクル・カウンタは最大［８＊（ＭＡＸ＿ＢＬＫＣＮＴ＋１）−１］をカウントする。次のクロック・サイクルで、状態マシンは、ブロック受信状態に遷移する。各クロックごとに、グローバル・データ・バスは、グローバル・データ・バス・パイプライン・レジスタＲ＿ＧＢ＿ＤＡＴＡにロードされる。ＴＫＮ＿ＲＡＭアドレスを生成する際に使用すべきＧＢ＿ＣＹＣ＿ＣＮＴ（Ｐ１＿ＧＢ＿ＣＹＣ＿ＣＮＴ）のパイプライン式バージョンもバッファ制御ブロックに提供される。Ｒ＿ＧＢ＿ＤＡＴＡ中の値は、次のクロック・サイクルでトークン・バッファに転送される。Ｐ１＿ＧＢ＿ＣＹＣ＿ＣＮＴと共に、遅延グローバル・バス書込み転送実行中信号（Ｐ１＿ＧＢ＿ＷＸＦＲ＿ＩＰ）も提供される。
カウンタＧＢ＿ＣＹＣ＿ＣＮＴが最大カウントに達すると、状態マシンがエラー検査状態に遷移し、ヘッダに含まれるトークン・タイプ・ビットが検査される。データ・トークンではなく制御トークンが受信された場合、エラーが検出される。そのような場合、ＥＲＲＯＲ状況フラグがセットされ、状態マシンが、アイドル状態に戻り、ＥＲＲＯＲ状況によって状態マシンが未処理データ・トークンをＤＣＵ４１８に返す。ヘッダ（トークン記述子）の”ｅｒｒｆｌａｇ”（ビット８８）は、ＤＣＵ４１８に返されるときにセットされる。エラー条件は、制御トークンの形で報告される。
エラー検査状態でエラーが検出されなかった場合、状況フラグＩＴＫＮ＿ＲＤＹが１サイクル間だけハイにパルスされて、入力データ・トークンが受信され処理準備が完了したことを示す。状態マシンは、次のクロック・サイクルでアイドル状態に戻る。
アイドル状態で、状態マシンはＯＴＫＮ＿ＲＤＹフラグおよびＥＲＲＯＲフラグを監視する。ＣＴＫＮ＿ＲＤＹは、処理状態マシンよって１クロック・サイクル間だけ活動化され、処理済みデータ・トークンがトークン・バッファに書き直されたことを示し、同時に、ＥＲＲＯＲフラグは、未処理の誤ったデータがＤＣＵ４１８に返される予定であることを示す。ＯＴＫＮ＿ＲＤＹまたはＥＲＲＯＲが検出されると、状態マシンはバス要求状態に遷移する。同時に、状態マシンは、ＤＣＵ４１８へのＧＢ＿ＲＥＱ線を活動化してグローバル・バス・アクセスを要求する。状態マシンは、ＤＣＵ４１８がＧＢ＿ＰＡＣ−ＬＤを活動化するまでこの状態のままである。ＤＣＴユニットは、命令送信状態に遷移することによって応答し、グローバル・データ・バス上に命令を置き、ＧＢ＿ＰＡＣ＿ＲＤＹを活動化する。状態マシンは、ＤＣＵ４１８がＧＤ＿ＧＲＡＮＴ線を活動化することによってユニットの要求を許可するまで命令送信状態のままである。状態マシンは次いで、ヘッダ送信状態に遷移する。ＧＢ＿ＣＹＣ＿ＣＮＴカウンタが始動され、トークン・バッファからデータが事前に取り出しされる。状態マシンによってＧＢ＿ＤＡＴＡ＿ＲＤＹ線が活動化され、ＨＥＡＤＥＲレジスタの内容がグローバル・バス４１６に経路指定される。トークン・バッファから取り出されたデータは、Ｒ＿ＧＢ＿ＤＡＴＡパイプラインレジスタにロードされる。次のクロックで、状態マシンはブロック送信状態に遷移する。ＧＢ＿ＣＹＣ＿ＣＮＴは、ヘッダに含まれる最大カウントをカウントする。Ｒ＿ＧＢ＿ＤＡＴＡは、グローバル・データ・バス上に置かれる。最大カウントに達すると、状態マシンがアイドル状態に戻り、１クロック・サイクル後にバス要求が非活動化される。
状態マシンは、ＤＣＵ４１８に対するＢＵＳＹ信号を生成する。状態マシンがセットされるのは、ＤＣＵが開始するシーケンスが開始されたときであり、リセットされるのは、処理済みデータ・トークンがＤＣＵ４１８に返された後だけである。
量子化処理ユニット（ＱＰＵ）（第１７図）
量子化処理ユニット４２２は、いくつかのデータ・ブロックから成るデータ・トークンの順量子化および逆量子化を行う。このユニットは、量子化を行うだけでなく、平均平方および分散も算出し、相対画像活動の尺度に基づいて量子値を修正することができる。
このユニットによって処理すべき命令およびトークンは、グローバル・バス４１６を介してＤＣＵ４１８からグローバル・バス・インタフェース１７１０へ送信される。このトークンはトークン・バッファ１７１２にセーブされる。命令は、トークンを量子化プロセッサ・ブロック１７１４を通過させることによって実行される。命令の処理が量子化プロセッサ内部で行われるので、量子化プロセッサによる処理をトークン・バッファ１７１２に記憶し直すことができる。命令の実行の完了時に、トークンがＤＣＵに送り返される。
このユニットは、完全ＣＣＩＲ−６０１画像に対するビデオ・レートＪＰＥＧ（符号化または復号）、ＣＩＦ画像に対するビデオ・レートＰｘ６４（符号化と復号の両方）、ＭＰＥＧ（符号化または復号、あるいはその両方）の各圧縮アルゴリズムに関する順量子化および逆量子化をサポートすることができる。
量子化プロセッサは、順量子化または逆量子化、平均平方、分散、および量子修正を行う資源である。処理状態マシン１７１６は、ＱＰＵ中の命令実行用のシーケンサとして働く。処理状態マシンは、グローバル・バス制御状態マシンと協働して入力トークンを処理する。
Ｑ＿ＲＡＭ１７１８は、最大１９２個の８ビット量子化値用の記憶域を含む。このＲＡＭは、ＩＣＣによる処理が開始される前に外部ホスト・プロセッサによって初期設定される。ＲＡＭ中の記憶空間は、論理的に３つの６４バイト・テーブルに区画される。ＪＰＥＧ量子化の場合、ＲＡＭは通常、ＹＵＶ画像の輝度成分および色差成分用の量子化マトリックスを含む。ＭＰＥＧ量子化の場合、最初の２つのテーブルしか使用されない。テーブル０は、内部符号化用の量子化マトリックスで初期設定される。テーブル１は、非内部符号化用の量子化マトリックスで初期設定される。Ｐｘ６４の場合、このＲＡＭは使用されず、したがって、初期設定する必要はない。Ｑ＿ＲＡＭの内容は、ホスト・プロセッサによってホスト・インタフェースを介して読み取ることができる。
バッファ制御ブロック１７２０は、トークン・バッファおよび量子化マトリックスＲＡＭ（Ｑ＿ＲＡＭ）にアドレスおよび制御信号を提供する。ＲＡＭアドレスは主として、ＰＨＡＳＥ＿ＣＮＴ、ＰＲＥ２＿ＰＥＬ＿ＣＮＴなどカウンタ値で形成される、ＲＡＭのパイプラインは処理状態マシンで形成される。バッファ制御ブロックは、３２×１６ジグザグＲＯＭも含む。このＲＯＭは、入力データ・ブロックおよび量子化テーブルをジグザグ走査するために使用される。
演算プロセッサ・ユニット（ＡＰＵ）（第１８図）
第１８図は、第４図の演算プロセッサ・ユニット４２０のブロック図である。グローバル・バス状態マシン１８１０は、内部グローバル・バス４１６と通信する。一対のトークン・バッファ１８１２および１８１４は、処理すべきトークンを記憶する。プロセッサ状態マシン１８１６は、入力トークンの処理を管理する。ユニット制御装置１８１８は、演算ユニットに必要な制御信号を生成する。フィルタ演算プロセッサ・ブロック１８２０は、３タップ・ループ・フィルタの伝達関数と、加算、減算、平均、およびクリッピング演算を実行する。演算処理ユニット１８２０との間でデータをバッファするために一対のバッファ１８２２および１８２４が提供される。
ラン・レングス・プロセッサ・ユニット（ＲＰＵ）（第１９図）
第１９図は、第４図のＲＰＵ４２６の機能ブロック図である。ＲＰＵは、トークンＲＡＭ制御論理機構２０１２によって制御されるトークンＲＡＭ２０１０を含む。これらは、グローバル・バス４１６に接続される。ｃｏｄｅｃプロセッサ２０１４は、ホスト通信向けの内部データ・トークン・フォーマットと外部ラン・レングス・フォーマットの間のデータ・フォーマット・チェンジャとして働く。ｃｏｄｅｃプロセッサは、量子化済み変換係数を一連のラン・レベルとして符号化し、一連のラン・レベル対を復号して量子化済み変換係数を形成する。また、ｃｏｄｅｃプロセッサは符号化時に、トークン記述子からヘッダ語を作成し、復号時に、符号化データ・シーケンスからヘッダ語を抽出する。ｃｏｄｅｃプロセッサは、トークンＲＡＭと、ホスト２０１８に接続されたラン・データ・インタフェース２０１６との間に接続される。インタフェース２０１６は、ブロック２０２０によって制御され、ラン・レングスｃｏｄｅｃは、状態マシン２０２２によって制御される。ＲＰＵは、割込み論理機構２０２４とホスト・アドレス復号化ブロック２０２６も含む。
トークン・インタフェース・ユニット（ＴＩＵ）（第２０図）
第２０図は、第４図のトークン・インタフェース・ユニット４２８のブロック図である。トークン・インタフェースは、ＩＣＣとホスト・プロセッサの間で共用されるＲＡＭメモリ２１１０を有する。制御論理ブロック２１１２は、バッファ・アクセス・モードおよび２アクセス・モード、グローバル・バス・アクセス・モード、ならびにホスト・アクセス・モードを制御する。
ホスト・インタフェース・ユニット（ＨＩＵ）（第２１図）
第２１図は、第４図のホスト・インタフェース・ユニット４１２のブロック図である。ＨＩＵは、ホスト・バスと様々な機能ユニット中のＩＣＣメモリ・マップ済みレジスタとの間のインタフェースの役割を果たす。
ビデオ・インタフェース・ユニット（ＶＩＵ）（第２２図）
第２２図は、ＶＩＵインタフェースのブロック図である。ＶＩＵは、バッファ制御論理機構２３１２の制御を受けるトークンＲＡＭ２３１０に内部グローバル・バス４１６を介して接続される。ホスト・インタフェース論理ブロック２３１４によって、第４図のホスト・インタフェース４１２を介する直接制御が可能になる。
グローバル・バス状態マシン２３１６は、グローバル・バス４１６へのアクセスを制御する。バッファ２３１８は、外部ビデオ・メモリ・データ・バスに接続される。ビデオ・メモリ調停ユニット２３２０は、リフレッシュ論理機構２３２２、ＳＡＭ−ＤＲＡＭ転送ブロック２３２４、およびページ・モード画像取出しブロックからのビデオ・バス要求、ならびに外部バス要求を調停する。補間回路２３２６は、状態マシン２３２８の制御の下で動作する。最後に、状態マシン２３３０はビデオ・メモリ・バス・アクセスを制御する。
補助インタフェース・ユニット（ＡＩＵ）（第２３図）
補助インタフェース・ユニット（ＡＩＵ）４３０は、ＩＣＣと、物理的にＩＣＣの一部ではない最大４つの外部プロセッサとの間のインタフェースとして働く。各外部プロセッサは、並行して動作できる最大４つの機能ユニットを含むことができる。ＡＩＵは、ＩＣＣ内部の他の機能ユニットと同様に機能する。すなわち、ＡＩＵは、グローバル・バス４１６を介してプロセッサ・パケットおよびオペランド・トークンをＤＣＵ４１８から受信し、グローバル・バス４１６を介してプロセッサ・パケットおよび結果トークンをＤＣＵ４１８に返す。命令は、そのＸビットが「１」にセットされた場合のみ、ＤＣＵ４１８によって実行のためにＡＩＵに送信される。しかし、ＡＩＵは、そのような命令を実行するのではなく、オフチップで適当な外部プロセッサへ送信する。ＡＩＵ４３０のブロック図を第２３図に示す。
ＡＩＵは、「外部命令状態テーブル」（ＥＩＳＴ）２４５０と呼ばれる１６語×１ビット・メモリを含む。ＥＩＳＴは、各外部機能ユニットごとに単一の語を有する。ＥＩＳＴ中の外部機能ユニットの項目は、この単位が現在、命令を実行中でビジー状態である場合は「１」にセットされ、この単位がアイドル状態である場合は「０」にセットされる。ＥＩＳＴ中のすべての項目は、ＩＣＣがリセットされたとき「０」にセットされる。ＥＩＳＴは、ＤＣＵ４１８内の更新ユニット８１２によって読み取られ、ＡＩＵから書き込まれ、独立に書き込み読み取ることができる。
外部命令（すなわち、Ｘビットが「１」である命令）は、その命令コード・フィールドの最下位４ビットを使用して外部機能ユニット上にマップされる。最下位２ビットは、外部プロセッサを選択するものであり、それらのビットのすぐ上の２ビットは、外部プロセッサ内の機能ユニットを選択するものである。この４ビットは、ＥＩＳＴにアドレスするためにＤＣＵとＡＩＵの両方によっても使用される。
グローバル・バス制御機構２４１０は、プロセッサ・パケットをＤＣＵ４１８との間で送受信する責任を負う。グローバル・バス制御機構は、プロセッサ・パケット・レジスタ・制御ブロック２４２０との間でプロセッサ・パケットの読取りおよび書込みを行う。また、グローバル・バス制御機構は、トークン・データ・バッファ２４４０から結果トークンを読み取り、トークン・データ・バッファ２４４０にオペランド・トークンを書き込む。
トークン・データ・バッファ２４４０は、３３語×９６ビット・メモリを含み、単一の制御トークンまたは単一の４ブロック・データ・トークンを記憶することができる。すなわち、外部命令が有することができるオペランド・トークンは１つだけである。メモリ中のトークンは、外部機能ユニットへ送信されるのを待つオペランド・トークンでも、これらの単位のうちの１つから返された結果トークンでもよい。
補助インタフェース・バス制御機構２４３０は、プロセッサ・パケットおよびトークンを外部機能ユニットとの間で送受信する責任を負う。このような転送に使用されるプロトコルは、ＭＥＣ出願に記載されている。このような転送は、補助インタフェース・バス・クロックＸＣＬＫとは非同期的に行われる。ＸＣＬＫは、グローバル・バス４１６を介してデータを転送するために使用される内部プロセッサ・クロックＰＣＬＫには同期しない。グローバル・バス制御機構２４１０と同様に、補助インタフェース・バス制御機構２４３０は、プロセッサ・パケット・レジスタ制御ブロック２４２０との間でプロセッサ・パケットの読取りおよび書込みを行う。また、補助インタフェース・バス制御機構は、トークン・データ・バッファ２４４０からオペランド・トークンを読み取り、トークン・データ・バッファ２４４０に結果トークンを書き込み、かつＥＩＳＴ２４５０中のビットをセットしクリアする責任を負う。
グローバル・バス制御機構２４１０と補助インタフェース・バス制御機構２４３０が共に、ＡＩＵ内の同じ資源にアクセスするので、主制御装置２４６０は、これらの機構の活動の調和を図る責任を負う。主制御装置２４６０は、ＡＩＵの「アイドル」状態も判定し、その状況を信号として更新ユニット４１２へ送信する。ＡＩＵ４３０は、グローバル・バス制御機構２４１０と補助インタフェース・バス制御機構２４３０のうちの一方がビジー状態でない場合はアイドル状態である。
ＤＣＵ４１８は、プロセッサ・パケットおよびオペランド・トークン（もしあれば）をＡＩＵ４３０へ送信する前に、ＡＩＵと、前記データを受信すべき外部機能ユニットが共にアイドル状態であるかどうかを検査する。ＤＣＵは次いで、グローバル・バス制御機構２４１０へデータを送信する。プロセッサ・パケットおよびオペランド・トークン（もしあれば）がそれぞれ、プロセッサ・パケット・レジスタ制御ブロック２４２０およびトークン・データ・バッファ２４４０に記憶された後、主制御装置は、補助インタフェース・バス制御機構２４３０を活動化して適当な外部機能ユニットへデータを送信する。補助インタフェース・バス制御機構２４３０は、この機能ユニットに対応するＥＩＳＴ２４５０中のビットも「１」にセットする。
ＡＩＵ４３０に結果を送り返したい機能ユニットを有する各外部プロセッサ・ユニットは、ＸＲＱＳＴ−入力ピンをＩＣＣ上でアサートする。補助インタフェース・バス制御機構２４３０は、同時に発生したそのような要求間の調停を行う。主制御装置２４６０が、ＡＩＵはビジー状態でないと判定した場合、補助インタフェース・バス制御機構２４３０は、ＭＥＣ出願に記載されたプロトコルを使用して、補助インタフェース・バスを介して、選択されたプロセッサに通知する。次いで、このプロセッサは、それ自体内の場合によっては複数の機能ユニットから、サービスを要求した機能ユニットを選択し、選択した機能ユニットのプロセッサ・パケットおよび結果トークン（もしあれば）でＡＩＵ４３０に応答する。前記データは、ＭＥＣ出願に記載されたプロトコルに類似のプロトコルを使用して補助バスを介して転送される。補助インタフェース・バス制御機構２４３０は、データを受信し、必要に応じてプロセッサ・パケット・レジスタ制御ブロック２４４０およびトークン・データ・バッファ２４４０に記憶し、応答側機能ユニットに対応するＩＳＴ２４５０中のビットを「０」にセットする。主制御装置２４６０は次いで・プロセッサ・パケットおよび結果トークンをＤＣＵ４１８へ送り返すようグローバル・バス制御機構２４１０に通知する。
ＩＣＣセマフォ
本発明は、セマフォのユニークな使用法を提供する。従来、セマフォは、複数のソフトウェア・プロセス間で臨界的なハードウェア・コンピュータ資源およびソフトウェア・コンピュータ資源を共用できるようにする通知機構を実施するために使用されている。そのような資源は、それぞれ、一度に１つのプロセスからしかアクセスできないという点で「臨界的」である。セマフォ自体は、ソフトウェア・プロセスが通常、実際に共用資源を処理する臨界ソフトウェア領域に入る前に「試験し設定」する臨界変数である。この「試験・設定」動作では、セマフォに関連する臨界領域へのアクセスを可能にする妥当な値を有するかどうかを調べるためにセマフォの値が「試験され」、次いで、同じ分割不能な動作の一部としてセマフォがこの値に「設定」される。
たとえば、プロセスが、２進セマフォＰによって保護されている臨界領域に入るには、このセマフォの値が１でなければならないと仮定する。その領域に入りたいプロセスは次いで、Ｐを「試験」して１に「設定」する。すなわち、Ｐは、値が「１」であるかどうか試験され、次いで、試験の結果にかかわらず「１」に設定される。試験結果が正である場合、プロセスはこの領域に入らない。試験結果が負である場合、プロセスはこの領域に入り、分割不能な「試験・設定」動作の「設定」部分によって、他のプロセスがこの領域に入ることが防止される。この場合、首尾良くこの領域に入ったプロセスは、この臨界領域から出る際に特殊な動作を介してＰを「０」に設定し直し、それによって、その領域に入る機会を他のプロセスに与える。
セマフォに対する動作は、セマフォがアクセスされるときに相互の排他性を保証するハードウェア・レベルでの特殊な命令によってサポートしなければならない。たとえば、上述の「試験・設定」動作を別々の「試験」動作および「設定」動作として実行した場合、一方のプロセスが、セマフォを試験して、関連する臨界領域に入ることができると結論し、その後、他方のプロセスが、第１のプロセスがセマフォを設定しないうちに同じセマフォを試験して同じ結論に達し、次の入力を妨げる可能性がある。
ＩＣＣは、特にプログラム可能な並列データフロー環境内で使用すべきセマフォ通知機構を実施することによって最新のデータフロー・コンピュータを改良するものである。ＩＣＣセマフォは主として、
１．任意の時点で存在するデータ・トークンの数を制限すること
２．データフロー・プログラムのサイズを最小限に抑えること
３．プログラム・データフローを外部事象に同期させることの各目的に使用される。
項目１が必要であるのは、データ・トークンを記憶するためのＩＣＣのオンチップ・メモリが限られているからである。ＩＣＣが、すべてのタイプの最大１２８個のトークンを同時に記憶できる（すなわち、命令当たり１つ）が、記憶できるデータ・トークンの最大数を決定する６４個のブロック割振りユニット（ＢＡＵ）用の空間しか有さないことを想起されたい。データ・トークンには１つまたは２つのＢＡＵが必要であり、フローグラフ中に同時に存在できるデータ・トークンの数の上限は各データ・トークン生成命令ごとに１つである。すなわち、あらゆる命令出力アーク上に１つのトークンが存在することができる。したがって、理論的には、チップ上で利用できるＢＡＵよりも多くのＢＡＵを要求する、ＩＣＣプログラムを作成することがあり得る。すべてのアーキテクチャは最終的にメモリが制限されるので、ＩＣＣ以外のデータ・アーキテクチャにも類似の状況が存在する。
ＩＣＣでは、フローグラフが過度に多くのＢＡＵを使用する可能性が高いときに新しいデータ・トークンのフローグラフへの流れを一時的に停止するために使用できるセマフォ命令を与えることによって、プログラマが、データ・トークン・メモリ使用率を制限することができる。これをサポートするＩＣＣ命令をＴＳＴＤＥＣ（セマフォの試験および減分）およびＩＮＣＳＥＭ（セマフォの増分）と呼ぶ。
第２４図は、ＴＳＴＤＥＣおよびＩＮＣＳＥＭの使用法の一例を示す。この例を支持する原則は、トークンがフローグラフのＴＳＴＤＥＣ命令とＩＮＣＳＥＭ命令の間に入るたびに、前記トークンが、フローグラフ内で有界数の新しいトークンを「生成」することである。たとえば、新しい２ＢＡＵデータ・トークンが第２４図のＴＳＴＤＥＣ命令を介してフローグラフに入るたびに、最大で２つのトークンが生成され、正味で４つのＢＡＵが増加する。したがって、Ｎ個のトークンがフローグラフに入った後、最大で２Ｎ個の新しいトークンまたは４Ｎ個のＢＡＵがフローグラフ内で作成される。もちろん、すべてのトークンが、ＩＮＣＳＥＭ命令を介してフローグラフを離れるまでに使い尽くされるので、作成される新しいトークンの正味数が引き続き非有界的に増加することはない。
第２４図中の例は、セマフォ・レジスタ０（ＳＥＭＲＥＧ０）を使用して、フローグラフによってＴＳＴＤＥＣ命令とＩＮＣＳＥＭ命令の間で使用されるＢＡＵの最大数を追跡する。ＩＮＩＴＳＥＭ命令は、セマフォを８、すなわち、フローグラフ中に存在できるＢＡＵの最大数よりも２だけ少ない数に初期設定する（なぜ２だけ少ないかについては、後で説明する）。ＴＳＴＤＥＣ命令への入力にトークンがあると、ＴＳＴＤＥＣ命令は、値「４」（入力されたトークンが生成するＢＡＵの最大数）をセマフォの現行の値と比較することによって、フローグラフへの入力を「保護」する。「４」がセマフォの値以下である場合（すなわち、フローグラフには新しいトークン用の「空間」がある）、ＴＳＴＤＥＣは、セマフォを「４」だけ減少させ、トークンをフローグラフに入れる。そうでない場合、ＴＳＴＤＥＣは、トークンを通過させず、前記試験条件が満たされるまでＴＳＴＤＥＣの入力にトークンを保持する。これに対して、フローグラフの１番下では、ＩＮＣＳＥＭがセマフォを「４」だけ増加させ、使い尽くされたすべての増分ＢＡＵに対処する。
ＩＮＣＳＥＭ命令が、その入力トークンを使用する前にセマフォの値を減少させておくことに留意されたい。したがって、このトークンに対処するために、セマフォは最初、ＢＡＵの最大数よりも２だけ少ない数に設定される。ＴＳＴＤＥＣ命令とＩＮＣＳＥＭ命令が、それらに、相互に排他的にセマフォに作用するよう強制する、ＩＣＣ内の同じハードウェアによって実行されることにも留意されたい。
セマフォの第２の使用法は、ＩＣＣのプログラム・メモリの長さが１２８語しかないため、ＩＣＣプログラムのサイズを制限することである。これは、ＴＳＴＳＥＭセマフォ命令およびＩＮＣＳＥＭセマフォ命令を使用して、複数のソースから得たトークンを同じフローグラフ・セグメントとして時間多重化することによって行われ、そのため、命令を重複する必要がなくなる。一例を第２５図に示す。時分割マルチプレクサは、出力がＩＮＣＳＥＭ命令の入力に接続された３つのＴＳＴＳＥＭ命令によって形成される。各ＴＳＴＳＥＭ命令は、その入力トークン中のトークン記述子中のｃｎｔｒｌフィールドの値とＳＥＭＲＥＧ０を比較する。入力トークンは、第２５図ではＴ１、Ｔ２、Ｔ３として示されており、それぞれのＴＳＴＳＥＭ命令の入力に任意の順序で現れることができる。ｃｎｔｒｌフィールドがＳＥＭＲＥＧ０に一致する場合、ＴＳＴＳＥＭ命令は、入力トークンをそれ自体の出力にコピーする。そうでない場合、ＴＳＴＳＥＭ命令は、一致が達成されるまでそれ自体の入力にトークンを保持する。その根拠となる考えは、任意の時点に１つのＴＳＴＳＥＭ命令しかその入力を通過しないように、ｃｎｔｒｌフィールドを使用してトークンに通し番号を付けることである。ＩＮＣＳＥＭ命令は次いで、トークンを活動状況ＴＳＴＳＥＭ命令からそれ自体の出力にコピーし、マルチプレクサが次のトークンを通過させることができるようにセマフォを増分する。第２５図に示したように、ＩＮＣＳＥＭ命令は、トークンのｃｎｔｒｌフィールドの値で決定されるＴ３、Ｔ２、Ｔ１の順序でトークンを出力する。
セマフォの第３の使用法は、ＩＣＣデータフロー・プログラムをＩＣＣの外部の事象に同期させることである。これは、ＴＳＴＳＥＭ命令を使用して、外部ホスト・プロセッサがセマフォを所定の値に設定するまでデータフローを一時的に停止することによって行われる。たとえば、第２６図に示したＴＳＴＳＥＭ命令は、入力トークン「Ｔ」のｃｎｔｒｌフィールド中の値「３」がＳＥＭＲＥＧ０の値に一致するまで入力トークンを通過させない。ホスト・プロセッサは最終的に、ＩＣＣホスト・インタフェース・バスを介してＳＥＭＲＥＧ０に「３」をロードする。
当業者にはおわかりのように、本発明は、その趣旨からも基本的特性からも逸脱せずに他の特定の形で具体化することができる。したがって、本発明の好ましい実施形態の開示は、下記の請求の範囲に記載された本発明の範囲を例示するものであり、制限するものではない。いくつかの代替実施形態を以下に記載する。
各専用処理ユニットは、汎用処理ユニットでもよい。汎用処理ユニットは、ある種の命令のみを受け入れるように、プログラムに応じて専用ユニットとなるようにプログラムすることもできる。他の実施形態では、特別に構成されたある処理ユニット向けに各命令を指定するのではなく、複数の処理ユニットをある種の命令を処理するように構成することができ、その結果、命令は、それを実行する複数のユニットを選択することができ、したがって、パイプライン動作が向上する。
前述の実施形態では、各処理ユニットは単一バッファ型のものであり、その結果、新しいトークンは、ユニットが前のトークンの処理を終了するまで待機しなければならない。処理ユニットが前のデータおよび命令を実行している間に新しい命令、データ、およびトークンを受信できるように、二重バッファリング・システムを使用することもできる。
第１４図のトークン・メモリ・ユニットに関しては、ある代替実施形態では、各命令ごとに指定されたトークン・アドレスを有するようにこのハードウェアをセットアップすることができ、この結果、たとえば、命令１は常にトークン・アドレス１に対応し、命令２はトークン・アドレス２に対応し、以下同様である。これによって、各トークン・アドレスを異なる命令に動的に割り当てるヘッダ・スタック・メモリをなくすることができる。そのような静的指定では、第３Ａ図のオペランドＲＡＭフォーマット中のオペランドＲＡＭフィールドをなくすることもできる。その代わり、このフィールドは、システムの初期設定時に静的に確立される。これによって、更新ユニットがオペランド・ファイルに書込みを行うことが不要になる。ただし、セマフォ・フィールドおよびオペランド存在ビットは依然として更新ユニットによって書き込む必要がある。第３Ｂ図に示した結果パケット・フォーマットでも、結果トークン・アドレスをなくすることができる。なぜなら、これは、すでにパケット中に存在する命令アドレスに対応するものに過ぎないからである。
本発明の好ましい実施形態の他の変形例は当業者には明らかであろう。したがって、本発明の範囲は、下記の請求の範囲に記載したとおりである。
【図１Ａ】
0003806936.tif 000011
【図１Ｂ】
0003806936.tif 000012
【図１Ｃ】
0003806936.tif 000013
【図２】
0003806936.tif 000014
【図３Ａ】
0003806936.tif 000015
【図３Ｂ】
0003806936.tif 000016
【図３Ｃ】
0003806936.tif 000017
【図３Ｄ】
0003806936.tif 000018
【図３Ｅ】
0003806936.tif 000019
【図３Ｆ】
0003806936.tif 000020
【図３Ｇ】
0003806936.tif 000021
【図４】
0003806936.tif 000022
【図５】
0003806936.tif 000023
【図６】
0003806936.tif 000024
【図７】
0003806936.tif 000025
【図８】
0003806936.tif 000026
【図９】
0003806936.tif 000027
【図１０】
0003806936.tif 000028
【図１１】
0003806936.tif 000029
【図１２】
0003806936.tif 000030
【図１３Ａ】
0003806936.tif 000031
【図１３Ｂ】
0003806936.tif 000032
【図１４】
0003806936.tif 000033
【図１５】
0003806936.tif 000034
【図１６】
0003806936.tif 000035
【図１７】
0003806936.tif 000036
【図１８】
0003806936.tif 000037
【図１９】
0003806936.tif 000038
【図２０】
0003806936.tif 000039
【図２１】
0003806936.tif 000040
【図２２】
0003806936.tif 000041
【図２３】
0003806936.tif 000042
【図２４】
0003806936.tif 000043
【図２５】
0003806936.tif 000044
【図２６】
0003806936.tif 000045