JPH11508066A - データ・フロー制御および複数の処理装置を有する画像圧縮コプロセッサ - Google Patents

Abstract

(57)【要約】 本発明は、単一チップに集積された画像圧縮／圧縮解除を提供する。制御バスは異なった特定の目的の処理ユニット（４１４、４２０、４２２、４２４、４２８）のいくつかに内部、グローバル・バス（４１６）によって接続されている。各処理ユニットは圧縮及び圧縮解除の特定のステップのみを処理するように特別に設計されている。

Description

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

【手続補正書】 【提出日】１９９８年７月９日 【補正内容】 請求の範囲 １．単一の半導体チップ上で集積された画像圧縮コプロセッサにおいて、 記憶されたプログラムに応じて前記コプロセスを操作する制御ユニット手段と 、 前記制御ユニット手段に結合された内部バスと、 それぞれ、画像圧縮／圧縮解除プロセス中のステップ群のサブセットを実行す るために前記バスに結合された複数の専用処理手段と を備えることを特徴とする画像圧縮コプロセッサ。 ２．単一の半導体チップ上に集積されたプロセッサにおいて、 制御ユニットと、 前記制御ユニットに結合され、記憶されたプログラムを有するメモリと、 前記制御ユニットに結合された内部グローバル・バスと、 各々が前記グローバル・バスに結合されており、前記プロセッサによって実行 されるプロセスにおけるステップのグループのサブセットを実行する複数の処理 回路と、 前記グローバル・バスに結合され、前記処理回路がアクセスできるデータ・ト ークン・メモリとを備えており、 前記の記憶されたプログラムがデータ・フロー・プログラムであり、前記制御 ユニットが命令とデータ・トークンを前記グローバル・バス上を非同期に前記複 数の処理回路へ転送し、 前記データ・トークンがデータ・ベクトルであることを特徴とするプロセッサ 。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ， ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，Ｇ Ｂ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ， ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＩ，ＳＫ，ＴＴ，ＵＡ，Ｕ Ｚ，ＶＮ (72)発明者 コペット，トーマス・ジイ アメリカ合衆国 80906 コロラド州・コ ロラド スプリングス・ローウィック ド ライブ・15 (72)発明者 テイラー，ブラッドフォード・ジイ アメリカ合衆国 80920 コロラド州・コ ロラド スプリングス・バーナムウッド ドライブ・3410 (72)発明者 ルイ クオ，ゲリー・シイ アメリカ合衆国 90919 コロラド州・コ ロラド スプリングス・オーク ヴァレー ドライブ・6905 (72)発明者 ルー，スティーブン・ディ アメリカ合衆国 80910 コロラド州・コ ロラド スプリングス・ラルフズ リッジ ロード・ナンバー202・1828

Claims (1)

1. 【特許請求の範囲】 １．単一の半導体チップ上で集積された画像圧縮コプロセッサにおいて、 記憶されたプログラムに応じて前記コプロセスを操作する制御ユニット手段と 、 前記制御ユニット手段に結合された内部バスと、 それぞれ、画像圧縮／圧縮解除プロセス中のステップ群のサブセットを実行す るために前記バスに結合された複数の専用処理手段と を備えることを特徴とする画像圧縮コプロセッサ。 ２．前記各専用処理手段が、異なる専用ハードウェアを有することを特徴とする 請求項１に記載の画像圧縮コプロセッサ。 ３．前記記憶されたプログラムがデータ・フロー・プログラムであり、前記制御 ユニット手段が命令およびデータ・トークンを前記バスを介して前記複数の専用 処理手段へ転送することを特徴とする請求項１に記載の画像圧縮コプロセッサ。 ４．前記各データ・トークンが、１つないし複数のデータ・ブロックまたはデー タ・ベクトルを含むことを特徴とする請求項３に記載の画像圧縮コプロセッサ。 ５．前記各データ・トークンがさらに、前記トークンをデータ・トークンとして 識別し、接続されたデータ・ブロックの数を示すトークン記述子を含むことを特 徴とする請求項４に記載の画像圧縮コプロセッサ。 ６．前記命令が、前記処理手段に対するデータ信号または制御信号とは別にパケ ットで前記複数の処理手段に転送されることを特徴とする請求項３に記載の画像 圧縮コプロセッサ。 ７．前記複数の処理手段が、 １つの前記命令を保持するために前記バスに結合された命令レジスタ手段と、 前記少なくとも１つの前記データ・トークンを保持するために前記バスに結合 されたバッファ手段と、 前記ステップ・サブセットを実行するために前記バッファ手段および前記命令 レジスタ手段に結合された処理論理手段と、 前記命令レジスタおよびバッファと前記バスのインタフェーシングを制御する ために前記命令レジスタ手段および前記バッファ手段に結合された状態マシン手 段とを含むことを特徴とする請求項３に記載の画像圧縮コプロセッサ。 ８．さらに、 マスタ・ホスト・プロセッサに結合されるホスト・インタフェース・ポートと 、 前記マスタ・ホスト・プロセッサと通信できるようにデータを前記トークン・ フォーマットとラン・レングス・フォーマットの間で変換するために前記バスと 前記ホスト・インタフェース・ポートの間に接続されたラン・レングス・プロセ ッサ手段とを備えることを特徴とする請求項３に記載の画像圧縮コプロセッサ。 ９．さらに、 マスタ・ホスト・プロセッサに結合されるホスト・インタフェース・ポートと 、 前記ホスト・プロセッサがトークンを直接挿入し前記バス上のトークンを見る ことができるようにするために前記バスと前記ホスト・インタフェース・ポート の間に結合されたトークン・インタフェース手段とを備えることを特徴とする請 求項３に記載の画像圧縮コプロセッサ。 １０．さらに、 前記バスを外部ビデオ・メモリに結合するビデオ・インタフェースと、 前記バスを外部ホスト・プロセッサに結合するプロセッサ・インタフェースと を備えることを特徴とする請求項１に記載の画像圧縮コプロセッサ。 １１．前記制御ユニット手段が、前記制御ユニット手段と前記複数の処理手段の 間での前記バスの使用を調停するために前記バスに結合されたバス調停手段を備 えることを特徴とする請求項１に記載の画像圧縮コプロセッサ。 １２．前記制御ユニット手段が、外部ホストからロードされた少なくとも第１お よび第２のプログラムを保持する命令メモリと、前記第２のプログラムが完了す る前に前記第１のプログラムからの命令を実行させる手段とを含むことを特徴と する請求項１に記載の画像圧縮コプロセッサ。 １３．さらに、外部補助プロセッサを前記グローバル・バスに結合するために前 記グローバル・バスと補助インタフェースの間に結合された補助ユニット手段を 備えることを特徴とする請求項１に記載の画像圧縮コプロセッサ。 １４．さらに、 前記制御ユニット手段に結合されたセマフォ・レジスタと、 データ・トークンへのアクセス時に前記セマフォ・レジスタ中のカウントを修 正し、前記セマフォ・レジスタ中のセマフォ値を試験し、前記セマフォ値が最大 値を超えている場合に新しいデータ・トークンがアクセスされるのを防止し、デ ータ・トークンが前記制御ユニットから離れた時点で前記カウントを修正する、 前記データ・フロー・プログラム中の複数のセマフォ命令とを備えることを特徴 とする請求項３に記載の画像圧縮コプロセッサ。 １５．第１のセマフォ命令が、各命令がデータ・トークンを要求する前に前記カ ウントを試験して減分し、第２のセマフォ命令が、各データ・トークンが前記制 御ユニットから離れた後に前記カウントを増分することを特徴とする請求項１４ に記載の画像圧縮コプロセッサ。 １６．さらに、 前記制御ユニット手段に結合されたセマフォ・レジスタと、 数を含む制御フィールドを有する前記データ・フロー・プログラム中の複数の 命令と、 命令中の前記制御フィールド中の前記数を前記セマフォ・レジスタ中のカウン ト比較し、前記数が前記カウントに一致するときに、前記命令を、処理するため に前記制御ユニット手段を通過させる手段とを備えることを特徴とする請求項３ に記載の画像圧縮コプロセッサ。 １７．前記制御フィールド中の前記数が、シーケンス中の１つの数であり、前記 コプロセッサがさらに、一度に１つの命令しか通過できないように前記セマフォ ・レジスタ中の前記カウントを修正する手段を備えることを特徴とする請求項１ ６に記載の画像圧縮コプロセッサ。 １８．前記制御ユニットが、 前記内部バスに結合された内部バス・インタフェースと、 前記専用処理手段に転送すべき命令を保持するために前記内部バス・インタフ ェースに結合されたイネーブル済み命令待ち行列手段と、 前記内部バス・インタフェースに結合されたデータ・トークン・メモリと、 前記イネーブル済み命令待ち行列手段に命令を提供するために前記イネーブル 済み命令待ち行列手段に結合された更新ユニット手段とを備えることを特徴とす る請求項３に記載のコプロセッサ。 １９．前記更新ユニット手段が、 前記命令待ち行列手段中に命令があるかどうかを判定する第１の手段と、 前記命令に関するデータ・トークンが前記データ・トークン・メモリ中にある かどうかを判定する第２の手段と、 前記命令が必要とする１つの前記専用処理手段がビジー状態であるかどうかを 判定する第３の手段と、 前記第１、第２、第３の判定手段に応答して、前記イネーブル済み命令待ち行 列手段に前記命令を提供する手段とを備えることを特徴とする請求項１８に記載 のコプロセッサ。 ２０．さらに、 前記イネーブル済み命令待ち行列手段が満杯であるかどうかを判定する第４の 手段を備えることを特徴とする請求項１８に記載のコプロセッサ。 ２１．前記更新ユニット手段がさらに、 セマフォ・レジスタと、 前記データ・トークン・メモリ中のデータ・トークンへのアクセス時に前記セ マフォ・レジスタ中のカウントを修正し、前記セマフォ・レジスタ中のセマフォ 値を試験し、前記セマフォ値が最大値を超えている場合に新しいデータ・トーク ンがアクセスされるのを防止し、データ・トークンが前記制御ユニットから離れ た時点で前記カウントを修正するために前記セマフォ・レジスタに結合された手 段とを備えることを特徴とする請求項１８に記載のコプロセッサ。 ２２．前記コプロセッサがさらに、第１のレジスタを含み、前記プログラムが、 前記プログラム中で一度しか実行できないＣＲＴＯＫＥＮ命令を含み、前記ＣＲ ＴＯＫＥＮ命令が、前記第１のレジスタが第１の値を有する場合にのみ実行を許 可され、前記ＣＲＴＯＫＥＮ命令によって、前記第１レジスタが実行後に前記第 １の値を有し、前記コプロセッサが、前記第１のレジスタを前記第１の値以外に 変更するリセット手段を含むことを特徴とする請求項３に記載のコプロセッサ。 ２３．さらに、 前記データ・トークン用のデータ・ブロックを記憶するブロック割振りメモリ と、 それぞれ、データ・トークンに対応する、前記メモリ・ブロックを指すポイン タを記憶するトークン・アドレス・メモリと、 前記ポインタを修正することによってデータ・ブロックをあるデータ・トーク ンから他のデータ・トークンにコピーするために前記トークン・アドレス・メモ リに結合された制御手段とを備えることを特徴とする請求項３に記載のコプロセ ッサ。 ２４．さらに、前記データ・トークン用の記述子を記憶するヘッダ・メモリを備 え、前記トークン・アドレス・メモリが、前記ヘッダ・メモリ中の記述子を指す ポインタと、各データ・トークンごとの前記ブロック割振りメモリ中のデータ・ ブロックを指すポインタを記憶することを特徴とする請求項２３に記載のコプロ セッサ。 ２５．さらに、外部プロセッサ中に機能ユニットがビジー状態であるかどうかを 判定する第４の手段を備えることを特徴とする請求項１９に記載のコプロセッサ 。 ２６．１つの前記専用処理手段が、外部処理ユニットとのインタフェースをとる 補助インタフェース・ユニットであり、前記第４の手段が、前記補助インタフェ ース・ユニット中に状況テーブルを備えることを特徴とする請求項２５に記載の コプロセッサ。 ２７．前記状況テーブルが、各機能ユニットごとの位置を有する状況レジスタで あり、前記コプロセッサがさらに、 前記外部プロセッサ中の第１の機能ユニットを指定する命令が送信されたとき に前記状況レジスタ中の第１の状況ビットをセットする手段と、 前記外部プロセッサ中の前記第１の機能ユニットからの結果パケットが受信さ れたときに第１の状況ビットをクリアする手段とを備えることを特徴とする請求 項２６に記載のコプロセッサ。 ２８．前記内部バス・インタフェースが、カウントを修正し前記更新手段中のセ マフォ値を試験した後にセマフォ命令のオペランドを結果トークンにコピーする スカラ・プロセッサ・ユニット手段を含むことを特徴とする請求項２１に記載の コプロセッサ。