JP2012009063A - 中央化された割り込みコントローラ - Google Patents

Abstract

【課題】複数の処理ユニットについて中央化されたアドバンスド・プログラマブル・インタラプト・コントローラを提供すること。
【解決手段】ＡＰＩＣロジックのシングルコピーを有する中央化されたインタラプトコントローラは、マルチシーケンサチップ又はシステムのすべての処理ユニットに対してＡＰＩＣインタラプト提供サービスを提供する。中央化されたインタラプトコントローラのインタラプトシーケンサブロックは、公平性スキームに従ってインタラプトサービスをスケジューリングする。中央化されたインタラプトコントローラの少なくとも１つの実施例はまた、選択されたインタラプトメッセージの送信をフィルタアウトするためのファイアウォールロジックを有する。他の実施例がまた記載及び請求される。
【選択図】図１

Description

本発明は、割り込み又はインタラプト（ｉｎｔｅｒｒｕｐｔ）を制御する電子回路に関する。より詳細には、本発明は、複数の処理ユニットについて中央化されたアドバンスド・プログラマブル・インタラプト・コントローラ（Ａｄｖａｎｃｅｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｉｎｔｅｒｒｕｐｔ Ｃｏｎｔｒｏｌｌｅｒ）に関する。

コンピュータシステムのパフォーマンスの基礎となる処理ユニットは、コンピュータシステムに接続されている周辺装置によりリクエストされる各種の断続的な“サービス”の制御を含むいくつかの処理を実行する。プリンタ、スキャナ、表示装置などのコンピュータアイテムを含む入出力（Ｉ／Ｏ）周辺装置は、適切な機能を保証するためホストプロセッサによる断続的なサービスの提供を要求する。例えば、サービスは、デーら送信、データキャプチャ及び／又は制御信号を含むかもしれない。

各周辺装置は、典型的には、装置タイプに依存するだけでなく、それのプログラムされた使用にも依存する異なるサービス提供スケジュールを有している。ホストプロセッサは、１以上のバックグラウンドプログラムを実行しながら、各自の要求に従って装置間へのサービス提供を多重化する。サービスのホストをアドバイスするための少なくとも２つの方法、すなわち、ポーリング（ｐｏｌｌｉｎｇ）とインタラプト（ｉｎｔｅｒｒｕｐｔ）メソッドが使用される必要があった。前者の方法では、各周辺装置は、サービスリクエストを示すフラグがセットされているか確認するため、定期的にチェックがされる。後者の方法では、装置のサービスリクエストは、ホストを中断することが可能なインタラプトコントローラに転送され、それの現在のプログラムから特別なインタラプトサービスルーチンへの分岐が実行される。インタラプトメソッドは、ホストがポーリングのための不要なクロックサイクルを割り当てる必要がないため効果的である。本開示が着目するのはこの後者の方法である。

マルチプロセッサコンピュータシステムの出現によって、プロセッサ間のインタラプトを動的に分散するインタラプト管理システムが実現されてきた。ＡＰＩＣ（Ａｄｖａｎｃｅｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｉｎｔｅｒｒｕｐｔ Ｃｏｎｔｒｏｌｌｅｒ）は、マルチプロセッサインタラプト管理システムの一例である。多数のマルチプロセッサコンピュータシステムにおいて使用されるＡＰＩＣインタラプト送信機構は、他の処理ユニット又は周辺装置からのインタラプトリクエストを検出し、当該インタラプトリクエストに対応する特定のサービスが実行される必要があることを１以上の処理ユニットに通知するのに利用されるかもしれない。ＡＰＩＣインタラプト送信システムに関するさらなる詳細は、Ｃａｒｓｏｎらによる米国特許出願第５，２８３，９０４号“Ｍｕｌｔｉｐｒｏｃｅｓｓｏｒ Ｐｒｏｇｒａｍｍａｂｌｅ Ｉｎｔｅｒｒｕｐｔ Ｃｏｎｔｒｏｌｌｅｒ Ｓｙｓｔｅｍ”に記載されている。

多くの従来のＡＰＩＣは、多数のハードウェアによる設計となっており、このため、多数のゲート（すなわち、ハイ・ゲート・カウント）を必要とする。多くのマルチプロセッサシステムでは、各コアはコア内部に完全に自己完結した自らの専用のＡＰＩＣを有している。他のマルチプロセッサシステムでは、各コアは複数の論理プロセッサによる同時的なマルチスレッドコアである。このようなシステムでは、各論理プロセッサはＡＰＩＣに関連付けされ、各マルチスレッドコアは複数のＡＰＩＣインタラプト送信機構を有し、各機構は、自らのアーキテクチャ状態を維持し、一般に他のすべてのＡＰＩＣの制御ロジックと同一な自らの制御ロジックを実現する。何れかのタイプのマルチプロセッサシステムについて、複数のＡＰＩＣのためのダイエリアとリークパワーのコストは、望ましくないが大きなものとなりうる。さらに、マルチプロセッサシステムにおけるインタラプトを送信するため、複数のＡＰＩＣの動作に関するダイナミックパワーコストがまた、望ましくは大きなものとなりうる。

本発明の課題は、複数の処理ユニットについて中央化されたアドバンスド・プログラマブル・インタラプト・コントローラを提供することである。

上記課題を解決するため、本発明の一態様は、複数の処理ユニットに対するインタラプトメッセージの提供のための優先化及び制御機能を実行し、前記複数の処理ユニットに共有される単一のロジックブロックと、前記ロジックブロックに接続され、前記ロジックブロックにより処理のため前記複数の処理ユニットのインタラプトイベントをスケジューリングするインタラプトシーケンサブロックと、前記複数の処理ユニットのそれぞれのアーキテクチャインタラプト状態情報を維持するストレージエリアと、入力インタラプトメッセージを受信し、前記メッセージからの情報を前記ストレージエリアに配置する１以上の入力メッセージキューと、出力インタラプトメッセージを送信する１以上の出力メッセージキューとを有する装置に関する。

本発明によると、複数の処理ユニットについて中央化されたアドバンスド・プログラマブル・インタラプト・コントローラを提供することができる。

図１は、複数の処理ユニットのインタラプト制御を提供する中央化されたインタラプトコントローラの少なくとも１つの実施例を示すブロック図である。 図２は、中央化されたインタラプトコントローラの少なくとも１つの実施例のさらなる詳細を示すブロック図である。 図３は、マルチシーケンサシステムの各種実施例を示すブロック図である。 図４は、複数のコアのインタラプト状態の中央レポジトリの少なくとも１つの実施例を示すブロック図である。 図５は、中央化されたインタラプトコントローラのインタラプトシーケンサブロックの動作の少なくとも１つの実施例を示す状態遷移図である。 図６は、開示された技術を実行可能な計算システムの少なくとも１つの実施例を示すブロック図である。

以下において、複数の処理ユニットの中央化されたＡＰＩＣのための方法、システム及び製造物の選択された各実施例が説明される。ここに記載される各機構は、シングルコア又はマルチコアマルチスレッドシステムにより利用されるかもしれない。以下において、プロセッサタイプ、マルチスレッド環境、システムコンフィギュレーション、並びにマルチシーケンサシステムのシーケンサの個数及びタイプなどの多数の具体的な詳細が、本発明のより完全な理解を提供するため与えられる。しかしながら、本発明がそのような具体的な詳細なく実現可能であるということは当業者に理解されるであろう。さらに、本発明を不要に不明りょうにしないように、周知の構成、回路などは詳細には説明されない。

図１は、中央化されたインタラプトコントローラ１１０を有するシステム１００の少なくとも１つの実施例を示すブロック図である。システム１００は、複数のコア１０４（０）〜１０４（ｎ）を有する。図１の破線と楕円は、システム１００が任意数ｎ（ｎ≧２）のコアを有することが可能であることを示す。当業者は、システムの他の実施例が、以下に説明されるように、単一の同時マルチスレッディング（ＳＭＴ）コア（ｎ＝１となるように）を有することが可能であることを認識しているであろう。

図１は、単一の中央化されたインタラプトコントローラ１１０が物理的にコア１０４（０）〜１０４（ｎ）から分離されていることを示す。図１はまた、システム１００の各コア１０４（０）〜１０４（ｎ）がローカルインターコネクト１０２を介し中央化されたインタラプトコントローラ１１０に接続されていることを示す。中央化されたインタラプトコントローラ１１０は、ローカルインターコネクト１０２を介し各処理コアとインタフェースをとる。中央化されたインタラプトコントローラ１１０のハイレベルな目的は、複数のＡＰＩＣの動作を、当該ＡＰＩＣが従来のコア単位のＡＰＩＣシステムと同様にパラレルに動作しているようにシステム１００に見えるようにシリアルに模倣することである。

システム１００の単一のコア１０４は、同時マルチスレッディング（ＳＭＴ）、スイッチ・オン・イベントマルチスレッディング（ＳｏｅＭＴ）及び／又はタイム多重化マルチスレッディング（ＴＭＵＸ）を含む各種マルチスレッディングスキームの何れかを実現することが可能である。複数のハードウェアスレッドコンテクスト（論理プロセッサ）からの命令が、何れかの時点において同時にプロセッサ３０４上で実行されると、それはＳＭＴと呼ばれる。あるいは、シングル・コアマルチスレッディングシステムは、プロセッサパイプラインが複数のハードウェアスレッドコンテクスト間で多重化されるが、所与の時点では、１つのハードウェアスレッドコンテクストからの命令のみがパイプラインで実行されるＳｏｅＭＴを実装するかもしれない。ＳｏｅＭＴについては、スレッドスイッチイベントがタイムベースである場合、それはＴＭＵＸとなる。ＳｏｅＭＴ及びＴＭＵＸをサポートするシングルコアはマルチスレッディングをサポート可能であるが、それらは“シングルスレッド”コアと呼ばれる。なぜなら、１つのハードウェアスレッドコンテクストからの命令しか何れか所与の時点で実行されないためである。

各コア１０４は、シングルスレッドを実行可能な単一の処理ユニットであるかもしれない。あるいは、１以上のコア１０４が、当該コアしかある時点で１つのスレッドに対する命令を実行しないように、ＳｏｅＭＴ又はＴＭＵＸマルチスレッディングを実行するマルチスレッディングコアであるかもしれない。このような実施例では、コア１０４は“処理ユニット”と呼ばれる。

少なくとも１つの他の実施例では、各コア１０４は、ＳＭＴコアなどのマルチスレッドコアである。ＳＭＴコア１０４については、コア１０４の各論理プロセッサが“処理ユニット”と呼ばれる。ここで使用される“処理ユニット”とは、スレッドを実行可能な任意の物理的又は論理的ユニットであるかもしれない。各処理ユニットは、所与のスレッドについて実行される次の命令を決定するため、次命令ポインタロジックを有するかもしれない。また、処理ユニットは、“シーケンサ”と同義的に使用されるかもしれない。

何れかの実施例について（シングルスレッドコアとマルチスレッドコア）、各処理ユニットは、自らのインタラプトコントローラの機能のロジックが各処理ユニット内で自己完結せず、中央化されたインタラプトコントローラ１１０により提供されたとしても、当該機能に関連付けされる。何れかのコア１０４がＳＭＴコアである場合、各コア１０４の各論理プロセッサは、ローカルインターコネクト１０２を介し中央化されたインタラプトコントローラ１１０に接続されるかもしれない。

図３を参照するに、上述されるように、処理ユニット（又は“シーケンサ”）は、論理プロセッサ又は物理プロセッサであるかもしれない。図３において、論理処理ユニットと物理処理ユニットの間の相違が示されている。図３は、開示される技術を実行可能なマルチシーケンサシステムの実施例３１０と３５０の選択されたハードウェア構成を示すブロック図である。

図３は、シングルコアマルチシーケンサマルチスレッディング環境３１０の選択されたハードウェア構成を示す。図３はまた、各シーケンサが独立した物理プロセッサコアとなっているマルチコアマルチスレッディング環境３５０の選択されたハードウェア構成を示す。

シングルコアマルチスレッディング環境３１０では、単一の物理プロセッサ３０４は、オペレーティングシステム及びユーザプログラムに対してＬＰ_１〜ＬＰ_ｎにより参照される複数の論理プロセッサ（図示せず）として見えるようにされる。各論理プロセッサＬＰ_１〜ＬＰ_ｎはそれぞれ、アーキテクチャ状態ＡＳ_１〜ＡＳ_ｎの完全なセットを維持する。このアーキテクチャ状態は、少なくとも１つの実施例については、データレジスタ、セグメントレジスタ、コントロールレジスタ、デバッグレジスタ及びモデルに固有のレジスタの大部分を有する。論理プロセッサＬＰ_１〜ＬＰ_ｎは、キャッシュ、実行ユニット、ブランチプレディクタ、コントロールロジック、バスなどの物理プロセッサ３０４の他の大部分のリソースを共有する。しかしながら、各論理プロセッサＬＰ_１〜ＬＰ_ｎは、自らのＡＰＩＣに関連付けされるかもしれない。

多数のハードウェア構成が共有されるが、マルチスレッディング環境３１０における各スレッドコンテクストは、次命令アドレスを独立に生成することが可能である（及び、例えば、命令キャッシュ、実行命令キャッシュ又はトレースキャッシュなどからのフェッチの実行が可能である）。このため、プロセッサ３０４は、複数の論理シーケンサが単一の物理フェッチ／デコードユニット３２２において実現可能であっても、各スレッドコンテクストの命令をフェッチする論理的に独立した次命令ポインタフェッチロジック３２０を有する。シングルコアマルチスレッディングの実施例では、“シーケンサ”という用語は、スレッドコンテクストの少なくとも次命令ポインタフェッチロジックと共に、当該スレッドコンテクストの関連付けされたアーキテクチャ状態３１２の少なくともいくつかを含む。シングルコアマルチスレッディングシステム３１０のシーケンサはシンメトリックである必要はないことに留意すべきである。例えば、同じ物理コアの２つのシングルコアマルチスレッディングシーケンサは、それぞれが維持するアーキテクチャ状態情報の情報量について異なるかもしれない。

このため、少なくとも１つの実施例では、マルチシーケンサシステム３１０は、同時マルチスレッディングをサポートするシングルコアプロセッサ３０４である。このような実施例について、各シーケンサは、同一の物理プロセッサコア３０４がすべてのスレッド命令を実行するが、自らの次命令ポインタフェッチロジックと自らのアーキテクチャ状態情報とを有する論理プロセッサである。このような実施例について、論理プロセッサは、シングルプロセッサコアの実行リソースが同時に実行されるスレッド間で共有される可能性があるが、自らのアーキテクチャ状態のバージョンを維持する。

図３はまた、マルチコアマルチスレッディング環境３５０の少なくとも１つの実施例を示す。このような環境３５０は、異なるスレッド／シュレッドの少なくとも一部の実行が同時に進行可能となるとなるように、異なるスレッド／シュレッドをそれぞれが実行可能な２以上の独立した物理プロセッサ３０４ａ〜３０４ｎを有する。各プロセッサ３０４ａ〜３０４ｎは、各自のスレッド又はシュレッドのための命令情報をフェッチするため、物理的に独立したフェッチユニット３２２を有する。各プロセッサ３０４ａ〜３０４ｎが単一のスレッド／シュレッドを実行する実施例では、フェッチ／デコードユニット３２２は、単一の次命令ポインタフェッチロジック３２０を実装する。しかしながら、各プロセッサ３０４ａ〜３０４ｎが複数のスレッドコンテクストをサポートする実施例では、フェッチ／デコードユニット３２２は、サポートされる各スレッドコンテクストについて異なる次命令ポインタフェッチロジック３２０を実装する。マルチプロセッサ環境３５０における追加的な次命令ポインタフェッチロジック３２０の任意的な性質が、図３において破線により示される。

図３に示されるマルチコアシステム３５０の少なくとも１つの実施例について、各シーケンサは、単一のチップパッケージ３６０にある複数のコア３０４ａ〜３０４ｎを有するプロセッサコア３０４であるかもしれない。各コア３０４ａ〜３０４ｎは、シングルスレッド又はマルチスレッドプロセッサコアであるかもしれない。チップパッケージ３６０は、マルチコアシステム３５０の図示されたシングルチップの実施例が単なる一例であることを示すため、図３において破線により示されている。他の実施例では、マルチコアシステムのプロセッサコアは別々のチップに常駐するかもしれない。すなわち、マルチコアシステムは、マルチソケットシンメトリックマルチプロセッシングシステムであるかもしれない。

説明の簡単化のため、以下の説明ではマルチコアシステム３５０の実施例に着目する。しかしながら、この着目は、後述される機構がマルチコア又はシングルコアの何れのマルチシーケンサ環境においても実行可能であるという点で限定的なものと解されるべきでない。

図１を参照するに、システム１００のコア１０４（０）〜１０４（ｎ）は、ローカルインターコネクト１０２を介し互いに接続可能であることは理解できる。ローカルインターコネクト１０２は、コア間で要求されるすべての通信機能（キャッシュスヌープなど）を提供するかもしれない。各コア１０４（０）〜１０４（ｎ）は、ローカルインターコネクト１０２を介しインタラプト関連メッセージを送受信するための比較的小さなインタフェースブロックを有するかもしれない。一般に、コアのこのようなインタフェースは、それがインタラプト関連メッセージに関するアーキテクチャ状態を保持せず、またそれがここに記載される中央化されたインタラプトコントローラ１１０により実行される他の関連する機能を実行せず、又はインタラプトを優先させないため、比較的にシンプルなものである。

コア１０４（０）〜１０４（ｎ）は、シングルダイ１５０（０）上にあるかもしれない。少なくとも１つの実施例について、図１に示されるシステム１００はさらに、任意的な追加的ダイを有するかもしれない。１以上の追加的なダイ（〜１５０（ｎ））の任意的な性質は、図１において破線及び楕円により示される。図１は、他のダイ（１５０（ｎ））上の処理ユニットからのインタラプトメッセージが、システムインターコネクト１０６を介し第１ダイ（１５０（０））に通信されることを示す。中央化されたインタラプトコントローラ１１０は、システムインターコネクト１０６を介し他の何れかのダイ（〜１５０（ｎ））及び周辺のＩ／Ｏ装置１１４に接続される。

当業者は、図１に示されるダイ１５０の構成が、単なる一例に過ぎず、限定的なものと解されるべきでないことを認識するであろう。他の実施例では、例えば、１５０（０）と１５０（ｎ）の両方の要素が、同一のシリコン部分に常駐し、同一のローカルインターコネクト１０２に接続されるかもしれない。他方、各コア１０４は、必ずしも同一のチップ上に常駐する必要はない。各コア１０４（０）〜１０４（ｎ）及び／又はローカルインターコネクト１０２は、同一のダイ１５０上に常駐しないかもしれない。

システム１００の各コア１０４（０）〜１０４（ｎ）はさらに、ローカルインターコネクト１０２を介し他のシステムインタフェースロジック１１２に接続されるかもしれない。このようなロジック１１２は、例えば、シーケンサがシステムインターコネクトを介し他のシステム要素とインタフェースをとることを可能にするキャッシュコヒーレンスロジック又は他のインタフェースロジックなどを有するかもしれない。他のシステムインタフェースロジック１１２はさらに、システムインターコネクト１０６を介し他のシステム要素１１６（メモリなど）に接続されるかもしれない。

図２は、中央化されたインタラプトコントローラ１１０の少なくとも１つの実施例のさらなる詳細を示すブロック図である。一般に、図２は、中央化されたインタラプトコントローラ１１０がシステムのコア（図１のコア１０４（０）〜１０４（ｎ）など）とは物理的に分離されているが、中央化されたインタラプトコントローラ１１０は各シーケンサに関連付けされる各ＡＰＩＣインスタンスの完全なアーキテクチャ状態を維持することを示す。中央化されたインタラプトコントローラ１１０は、従来システムのコア単位の専用のＡＰＩＣにより通常は処理されるインタラプトキューイング及び優先付け機能のすべてを管理する。以下に詳細に説明されるように、中央化されたインタラプトコントローラ１１０はまた、システムインターコネクト１０６に接続されるシステムの残りとシーケンサとの間のファイアウォールとして機能するかもしれない。

図２は、中央化されたインタラプトコントローラ１１０が中央化されたＡＰＩＣ状態２０２を有することを示す。ＡＰＩＣ状態２０２は、典型的なＡＰＩＣ処理に通常関連付けされるアーキテクチャ状態を含む。すなわち、ＡＰＩＣ処理は、アプリケーションプログラマにはアーキテクチャ的に可視的な構成であり、このようなインタフェースは本開示により変更されることを意図したものでない。システムが従来のＡＰＩＣハードウェア（すなわち、各処理ユニットについて１つの自己完結したＡＰＩＣ）又はここに記載される中央化されたインタラプトコントローラを有するか否かに関係なく、少なくとも１つの実施例について、このようなハードウェア設計の選択はアプリケーションプログラマに透過であるべきことが予期される。このように、同時にオペレーティングシステムベンダ及びアプリケーションプログラマが期待する同一のアーキテクチャインタフェースを維持しながら、面積、ダイナミックパワー及びパワーリークの各コストを、システムの単一の中央化されたインタラプトコントローラ１１０を利用することにより低減することができる。

このため、ブロック２０２におけるＡＰＩＣ状態情報の中央レポジトリとして維持されるアーキテクチャ状態は、一般には従来システムのおける各ＡＰＩＣについて維持される状態となる。例えば、システムに８つのシーケンサがある場合、中央化されたＡＰＩＣ状態２０２は、各エントリが従来システムのシーケンサについて維持されるアーキテクチャＡＰＩＣ状態を反映した８つのエントリのアレイを含むかもしれない。（以下の図４の説明は、各エントリがまた特定のマイクロアーキテクチャ状態を含むことを示す。）
少なくとも１つの実施例について、中央化されたＡＰＩＣ状態２０２は、レジスタファイル又はアレイなどの単一のメモリ記憶領域として実現される。レジスタファイル構成は、ランダムロジックとしてコア単位ＡＰＩＣ状態を実現した従来アプローチより良好なエリア効率を可能にするかもしれない。

一般に、中央化されたインタラプトコントローラ１１０は、ローカルインターコネクト１０２及び／又はシステムインターコネクト１０６を介し受信されるインタラプトメッセージの受信を監視し、レジスタファイル２０２の適切なエントリに関連するメッセージを格納する。少なくとも１つの実施例では、これは、入力メッセージのデスティネーションアドレスを監視し、当該デスティネーションアドレスに係るＡＰＩＣインスタンスエントリにメッセージを格納することにより実現される。このような機能は、以下で詳細に説明されるように、入力メッセージキュー２０４、２０６により実行されるかもしれない。

同様に、中央化されたインタラプトコントローラ１１０は、出力インタラプトメッセージの生成を監視し、このようなメッセージがサービス及び送信されるまで、レジスタファイル２０２の適切なエントリにメッセージを格納するかもしれない。少なくとも１つの実施例では、これは、出力メッセージのソースアドレスを監視し、ソースアドレスに係るＡＰＩＣインスタンスエントリにメッセージを格納することにより実現される。このような機能は、以下で詳細に説明されるように、出力メッセージシーケンス２０８、２１０により実行されるかもしれない。

一般に、中央化されたインタラプトコントローラ１１０のインタラプトシーケンサブロック２１４は、その後、サービスのため中央化されたＡＰＩＣ状態２０２に反映されるように、保留中のインタラプトメッセージをスケジューリングするかもしれない。以下で詳細に説明されるように、これは、シーケンサの何れの保留中のインタラプト動作も繰り返し無視されないように、公平性スキームに従って実現されるかもしれない。インタラプトシーケンサブロック２１４は、サービスを実行するため、ＡＰＩＣインタラプト提供ロジック２１２を呼び出すかもしれない。

図２は、中央化されたインタラプトコントローラ１１０がＡＰＩＣインタラプト提供ロジック２１２を有することを示す。システムの各シーケンサのＡＰＩＣロジックを複製するのでなく（ＳＭＴコアの各論理プロセッサ又は各シングルスレッドコアなど）、中央化されたインタラプトコントローラ１１０は、システムのすべてのシーケンサについてインタラプトをサービスするため、ＡＰＩＣロジック２１２の単一の冗長でないコピーを提供する。

例えば、システム（図１のシステム１００など）が、それぞれが８つの同時的なＳＭＴスレッドをサポートする４つのコアを有する場合、システムは従来はＡＰＩＣロジック２１２の３２このコピーを必要とする。他方、図２に示される中央化されたインタラプトコントローラ１１０は、ＡＰＩＣロジック２１２の単一のコピーを利用して、所与の時点でアクティブな３２個のスレッドのすべてにインタラプトコントローラのサービスを提供する。

システムの複数のシーケンサが同時に保留中のインタラプト動作を有する可能性があるため、ＡＰＩＣロジック２１２は、複数のシーケンサから競合を受けるかもしれない。このため、中央化されたインタラプトコントローラ１１０は、インタラプトシーケンサブロック２１４を有する。インタラプトシーケンサブロック２１４は、ＡＰＩＣロジック２１２の各シーケンサに公平なアクセスを提供するように、システムのすべてのインタラプトのサービスをシーケンス処理する。中央化されたインタラプトコントローラ１１０のインタラプトシーケンサブロック２１４は、単一のＡＰＩＣロジックブロック２１２へのアクセスを制御する。

このため、インタラプトシーケンサブロック２１４は、共有されるＡＰＩＣロジック２１２へのシーケンサのアクセスを制御する。この機能は、各シーケンサがＡＰＩＣロジックへの直接的なアドホックアクセスを有するように、各シーケンサの専用のＡＰＩＣロジックブロックを提供する従来のＡＰＩＣシステムと対照的なものである。シングルＡＰＩＣロジックブロック２１２は、システムの各処理ユニットなどのインタラプト優先化に関するＡＰＩＣの完全なアーキテクチャ要求を提供するかもしれない。

システムの何れかの処理ユニットについて、ＡＰＩＣを通過するインタラプトのソース／デスティネーションは、他の処理ユニット又は周辺装置とすることが可能である。イントラダイ処理ユニットのインタラプトは、ローカルインターコネクト１０２を介し中央化されたインタラプトコントローラ１１０により提供される。他のダイ上の周辺装置又は処理ユニットに対するインタラプトは、システムインターコネクト１０６を介し提供される。

図２は、ローカルインターコネクト１０２及びシステムインターコネクト１０６を介し入出力インタラプトメッセージを処理するため、入力システムメッセージキュー２０４、入力ローカルメッセージキュー２０６、出力ローカルメッセージキュー２０８及び出力システムメッセージキュー２１０の４つのメッセージキューを有することを示す。入力ローカルメッセージキュー２０６と出力ローカルメッセージキュー２０８は、ローカルインターコネクト１０２に接続され、入力システムメッセージキュー２０４と出力システムメッセージキュー２１０は、システムインターコネクト１０６に接続される。各キュー２０４、２０６、２０８、２１０は、制御ロジックと共にデータストレージを有するミニコントローラキューである。

キュー２０４、２０６、２０８、２１０の動作のさらなる説明が、図１、２及び４を参照してなされる。図４は、中央化されたＡＰＩＣ状態２０２の少なくとも１つの実施例の詳細な図を提供する。図４は、中央化されたＡＰＩＣ状態２０２が、アーキテクチャ状態３０２と共にマイクロアーキテクチャ状態３０１、３０３の両方を有することを示す。上述されるように、各シーケンサ１０４（０）〜１０４（ｎ）について維持されるアーキテクチャ状態３０２は、シーケンサに従来関連付けされるＡＰＩＣ状態を反映する。アーキテクチャＡＰＩＣ状態３０２の各エントリ４１０は、ここでは“ＡＰＩＣインスタンス”と呼ばれる。例えば、ＡＰＩＣンスタンスの入力インタラプトメッセージは、当該インスタンスに係るアーキテクチャＡＰＩＣ状態３０２のエントリ４１０に格納されるかもしれない。少なくとも１つの実施例について、２４０までの入力インタラプトメッセージが、ＡＰＩＣインスタンスのエントリ４１０に維持されるかもしれない。

アーキテクチャ状態３０２に加えて、中央化されたＡＰＩＣ状態２０２は、一般的なマイクロアーキテクチャ状態３０３と共に各ＡＰＩＣインスタンス４１０に係るマイクロアーキテクチャ状態３０１を有するかもしれない。一般的なマイクロアーキテクチャ状態３０３は、インタラプトシーケンサブロック２１４（図２を参照されたい）がＡＰＩＣロジック２１２（図２を参照されたい）にアクセスする必要があるのは何れのシーケンサであるか決定するのに役立つためのスコアボード３０４を有するかもしれない。少なくとも１つの実施例では、スコアボード３０４は、システムの各シーケンサのためのビットを維持するかもしれない。シーケンサのビットの値は、ＡＰＩＣロジック２１２が要求される何れかの保留中の動作をシーケンサが有しているか示すかもしれない。少なくとも１つの実施例では、インタラプトシーケンサブロック２１４（図２）がＡＰＩＣロジック２１２の注意を何れのシーケンサが必要とするか容易かつ迅速に確認することが可能となるように、スコアボード３０４がアトミックに読み込まれるかもしれない。

インタラプトシーケンサブロック２１４の１つの特徴は、ＡＰＩＣロジック２１２へのアクセスを公平に可能にすることであるが、スコアボード３０４は、インタラプトシーケンサブロック２１４がＡＰＩＣロジック２１２の処理を同時には必要としないシーケンサの処理リソースを浪費することを要求することなく、公平性スキームが利用されることを可能にする。このため、スコアボードは、入力メッセージと上記発行されたリクエストの処理の現在の状態とに基づき、何れのＡＰＩＣインスタンスが実行するべき作業を有しているか追跡する。インタラプトシーケンサブロック２１４は、アクティブなＡＰＩＣインスタンスについて中央化されたＡＰＩＣ状態２０２から現在の状態を読み込み、（当該ＡＰＩＣインスタンス４１０のアーキテクチャ状態３０２とマイクロアーキテクチャ状態３０１の両方に記録されるような）現在状態に適したアクションをとり、その後に（スコアボード３０４のビットにより示されるような）保留中の作業による次のＡＰＩＣインスタンスについて当該処理を繰り返す。

入力インタラプトメッセージがローカルインターコネクト１０２を介し同一ダイ上の他のシーケンサに向けて投入されると、入力ローカルメッセージキュー２０６がこのメッセージを受信し、それの送信先を決定する。インタラプトメッセージは、シーケンサの１つ、多数又はすべてを対象とすることが可能であり、又はその何れも対象としないこともある。キュー２０６は、インタラプトをキューアップするため、対象とされる各シーケンサのアーキテクチャ状態エントリ（図４の４１０など）に書き込むかもしれない。このようなケースでは、インタラプト動作が保留され、シングルＡＰＩＣロジックブロック２１２のサービスが対象となるシーケンサに必要とされていることを示すため、スコアボードエントリがすでに設定されていない場合、キュー２０６はまた対象とされるシーケンサのスコアボードエントリを設定する。

しかしながら、図４は、いくつかのインタラプトが中央化されたＡＰＩＣ状態２０２においてキューアップされることなく、入力ローカルメッセージキュー２０６から出力キュー２０８、２１０に直接的にバイパスされるかもしれないことを示す。これは、例えば、特定のプロセッサに具体的にはアドレス指定されていないブロードキャストメッセージについて起こるかもしれない。図４は、同様のバイパス処理が入力システムメッセージキュー２０４（後述される）からもまた行われることを示す。

キュー２０６について上述されたものと同様の処理がまた、入力インタラプトメッセージがシステムインターコネクト１０６を介し（他のダイ上のＩ／Ｏ装置又はシーケンサから）シーケンサ１０４（０）〜１０４（ｎ）の１つを対象として投入されるときに行われるかもしれない。入力システムメッセージキュー２０４は、メッセージを受信し、それの送信先を決定する。キュー２０６は、インタラプトをキューアップし、何れか対象とされたシーケンサのスコアボードエントリ４１２を更新するため、対象とされる各シーケンサのアーキテクチャ状態エントリ４１０に書き込む。もちろん、入力メッセージは上述されるようにバイパスされてもよい。

メッセージキュー２０４、２０６、２０８、２１０の１以上が、入出力メッセージのファイアウォール機能を実装してもよい。このファイアウォール機能に関して、図２が図１と共に説明される。

入力メッセージに関して、入力システムメッセージキュー２０４は、中央化されたインタラプトコントローラ１１０に係るダイ１５０上のシーケンサを対象としないメッセージの不要な処理を回避するため、インタラプトファイアウォールとして機能するかもしれない。図１に示されるように、システム１００は複数のマルチシーケンサダイ１５０（０）〜１５０（ｎ）を有するかもしれない。特定のダイのシーケンサにより生成されるインタラプトは、システムインターコネクト１０６を介し他のダイに送信されるかもしれない。同様に、周辺装置１１４により生成されるインタラプトは、システムインターコネクト１０６を介しダイに送信されるかもしれない。

ダイ１５０の中央化されたインタラプトコントローラ１１０（及び入力システムメッセージキュー２０４）は、このようなメッセージの送信先アドレスがダイ１５０上の何れかのシーケンサ（コア又は論理プロセッサなど）を有しているか判断するかもしれない。メッセージが当該ダイに係るローカルインターコネクト１０２上の何れかのコア又は論理プロセッサを対象としていない場合、入力システムメッセージキュー２０４は、ローカルインターコネクト１０２上のシーケンサの何れかにメッセージを転送することを拒否する。このように、入力システムメッセージキューは、単に何れのアクションも不要であると決定するため、上記コア／スレッドの“ウェイキング（ｗａｋｉｎｇ）”を回避する。これは、電力を節約し、ローカルインターコネクト１０２の帯域幅を節約する。なぜなら、それは複数の各シーケンサがメッセージがそれらを対象としたものでないことを決定するためだけに、パワーセービング状態からウェイクアップすることを不要にするためである。

１以上の論理プロセッサがパワーセービング状態にない場合でさえ、入力システムメッセージキュー２０４は、入力インタラプトメッセージがそれらの側でアクションを必要としないことを単に決定するため、論理プロセッサが現在実行している作業から論理プロセッサをインタラプトしないように、依然としてファイアウォール機能を実行するかもしれない。

少なくとも１つの実施例について、ファイアウォールはまた出力メッセージに対して実装されるかもしれない。これは、出力システムメッセージと共に、少なくとも１つの実施例については、出力ローカルメッセージについても成り立つかもしれない。少なくとも１つの実施例について、ローカルメッセージのファイアウォール構成は、ローカルインターコネクト１０２上の各メッセージがすべてのシーケンサに配信されることを要求するのでなく、対象とされるインタラプトメッセージが特定のシーケンサに提供されることを可能にする構成をサポートするローカルインターコネクト１０２を有するシステムについてのみ実現される。このようなケースでは、出力ローカルメッセージキュー２０８は、ローカルインターコネクト１０２を介し各インタラプトメッセージをユニキャスト又はマルチキャストメッセージとして、当該メッセージにより対象とされるシーケンサのみに送信するかもしれない。このように、対象とされていないシーケンサは、それらのアクションが当該インタラプトメッセージに必要とされていないことを決定するため、それらの処理をインタラプトする必要はない。出力システムメッセージは、それらが対象とされていないエンティティに不必要に送信されないように、同様に対象とされるかもしれない。

図２は、入力インタラプトメッセージが入力メッセージキュー２０４、２０６により中央化されたＡＰＩＣ状態２０２に配置された後、インタラプトシーケンサブロック２１４が、システムのＡＰＩＣ処理を実行するため、ＡＰＩＣロジック２１２（図２を参照されたい）の１つのコピーへのシステムの各シーケンサ間への公平なアクセスを提供するかもしれないことを示す。インタラプトシーケンサブロック２１４は、実際には、ＡＰＩＣ状態２０２をシーケンシャルにトラバースし、それをひつようとする次のシーケンスのＡＰＩＣロジック２１２へのアクセスを提供することによって、この公平性スキームを実現するかもしれない。インタラプトシーケンサブロック２１４により実現される公平性スキームは、各シーケンサがインタラプト提供ブロックへの等しいアクセスを有することを許可するかもしれない。

少なくとも１つの実施例について、ＡＰＩＣ状態２０２のエントリを介した上記概念的なシーケンシャルなステッピングは、スコアボード（図４の３０４を参照されたい）を利用することによってより効率的なものとなり、スコアボードは、何れのアクティブなシーケンサが次にＡＰＩＣサービスを必要とするか決定するため、アトミックにクエリされるかもしれない。少なくとも１つの実施例について、図５に関連してより詳細に以下で説明される方法に従って、シーケンシャルなアクセスが制御可能である。

図５は、システムのＡＰＩＣ処理を実行するために、ＡＰＩＣロジック２１２（図２を参照されたい）の１つのコピーへのシステムの各シーケンサへの公平なアクセスを提供するため、インタラプトシーケンサブロック２１４（図２を参照されたい）の少なくとも１つの実施例により利用される方法５００を示す状態図である。図５の以下の説明は、図２及び４を参照してなされる。

全体として、図５は、インタラプトシーケンサブロック２１４がアクティブなＡＰＩＣインスタンスの中央化されたＡＰＩＣ状態２０２０から現在状態を読み取り、現在状態に適したアクションをとり、保留中の作業を有する次のＡＰＩＣインスタンスについて当該処理を繰り返すことを示す。

図５は、方法５００が状態５０２でスタートすることを示す。状態５０２において、インタラプトシーケンサブロック２１４は、何れのＡＰＩＣインスタンスが実行すべき作業を有しているか決定するため、スコアボード３０４を照会する。上述されるように、各ＡＰＩＣインスタンスについてスコアボード３０４に１つのエントリ４１２が存在するかもしれない。エントリ４１２は、少なくとも１つの実施例では、１ビットエントリであるかもしれない。ビット４１２は、入力メッセージが当該ＡＰＩＣインスタンスの中央化されたＡＰＩＣ状態２０２に書き込まれるときに設定されるかもしれない。

もちろん、当業者は、スコアボード３０４がすべての実施例に必ずしも存在する必要がないパフォーマンスエンハンスメントであることを認識するであろう。少なくとも他の１つの実施例について、例えば、インタラプトシーケンサブロック２１４は、何れのアクティブなＡＰＩＣインスタンスがサービスを必要としているか決定するため、順番に（シーケンシャルなど）中央化されたＡＰＩＣ状態２０２の各エントリをトラバースするかもしれない。

スコアボード３０４の何れのビットも設定されていない場合、何れのシーケンサも保留中のＡＰＩＣイベントを有していない。このようなケースでは、方法５００は状態５０２から５０８に移行する。状態５０８において、方法５００は、ロジック２１２が必要としない間、ＡＰＩＣロジックブロック２１２の少なくとも一部を省電力にパワーダウンするかもしれない。パワーダウンが完了すると、方法５００は、新たなＡＰＩＣ動作が検出されるか判断するため、状態５０２に移行する。

状態５０２において、新たな動作が検出されず（すなわち、スコアボード３０４の何れのエントリも設定されていない）、ＡＰＩＣロジック２１２がすでにパワーダウンされていた場合、方法５００は、新たなＡＰＩＣ動作を待機するため、状態５０２から５０６に移行するかもしれない。

待機状態５０６の期間中、方法５００は、何れかのＡＰＩＣインスタンスが保留中有のＡＰＩＣ作業を取得したか決定するため、スコアボード３０４のコンテンツを定期的に評価するかもしれない。スコアボード３０４のコンテンツに反映されるような入力ＡＰＩＣメッセージは、状態５０６から５０２への移行を引き起こす。入力ローカルメッセージキュー２０４及び入力システムメッセージキュー２０６の上記説明は、アーキテクチャＡＰＩＣ状態３０２と、少なくとも一部の実施例では、スコアボード３０４のエントリが、保留中のＡＰＩＣ作業をＡＰＩＣインスタンスが取得したことを反映するようどのように更新されるか説明する。

方法５００は、状態５０２において、スコアボード３０４の何れかのエントリ４１２が設定されている場合、少なくとも１つのＡＰＩＣインスタンスが実行すべき保留中のＡＰＩＣ作業を有していると判断するかもしれない。このようなエントリが複数設定されている場合、インタラプトシーケンサブロック２１４は、何れのＡＰＩＣインスタンスがＡＰＩＣロジック２１２によりサービスを次に受け付けるか決定する。少なくとも１つの実施例では、インタラプトシーケンサブロック２１４は、設定されている次のスコアボードエントリを選択することによって、上記決定を実行する。このように、インタラプトシーケンサブロック２１４は、ＡＰＩＣロジック２１２へのアクセスのため、次にアクティブなＡＰＩＣインスタンスをシーケンシャルに選択することによって、公平性スキームを課す。

状態５０２においてＡＰＩＣインスタンスを選択すると、方法５００はブロック５０２から５０４に移行する。ブロック５０４において、インタラプトシーケンサブロック２１４は、中央化されたＡＰＩＣ状態３０２から選択されたバーチャルＡＰＩＣのエントリ４１０を読み込む。このように、インタラプトシーケンサブロック２１４は、選択されたＡＰＩＣインスタンスについて何れのＡＰＩＣイベントが保留中であるか決定する。複数のＡＰＩＣイベントが保留中であるかもしれず、ＡＰＩＣエントリ４１０に反映されているかもしれない。状態５０４の各繰り返し中、ＡＰＩＣインスタンスに１つの保留中のイベントしか処理されない。このため、ラウンドロビンタイプのシーケンシャルな公平性スキームが維持されるかもしれない。

同一のアクティブなＡＰＩＣインスタンスについて複数の保留中のインタラプトイベントから選択するため、インタラプトシーケンサブロック２１４は、状態５０４において優先化処理を実行する。このような優先化処理は、従来システムの専用ＡＰＩＣにより実行される優先化スキームをエミュレートするかもしれない。例えば、ＡＰＩＣインタラプトは、重要性の各クラスに入るよう規定される。各ＡＰＩＣインスタンスのアーキテクチャ状態エントリ４１０（図４）は、少なくとも１つの実施例では、論理プロセッサ毎に２４０までの保留中のインタラプトを保持するかもしれない。これらは、１６の重要性のクラスに属することが可能であり、１６の優先化されたグループに分類される。クラス１６〜３１のインタラプトは、クラス３２〜４７のものより高い優先度を有する。インタラプトクラス番号が低いほど、インタラプト優先度は高くなる。このため、インタラプトシーケンサブロック２１４は、ＡＰＩＣインスタンスの２４０ビットを観察し、複数設定されている場合、状態５０４において１つのイベントのみを抽出する（ＡＰＩＣの既存のアーキテクチャ優先化ルールに基づき）。少なくとも１つの実施例では、インタラプトシーケンサブロック２１４は、この優先化を実行するためＡＰＩＣロジック２１２を呼び出す。

その後、方法５００は、状態５０４において、選択されたイベントに適したアクションをスケジューリング又は実行する。例えば、このイベントは、出力メッセージキューの１つから以前に送信されたインタラプトメッセージに対するアクノリッジメントを待機していることであるかもしれない。あるいは、イベントは、出力インタラプトメッセージが送信される必要があることであるかもしれない。または、シーケンサの１つについて、入力インタラプトメッセージ又はアクノリッジメントがサービスされる必要があるかもしれない。インタラプトシーケンサブロック２１４は、状態５０４において、イベントのサービスルためＡＰＩＣロジック２１２を起動するかもしれない。

アクノリッジメントが待機されている場合、インタラプトシーケンサブロック２１４は、このようなアクノリッジメントが待機されていることを判断するため、マイクロアーキテクチャ状態３０３に照会する。そうである場合、インタラプトシーケンサブロック２１４は、状態５０４においてアクノリッジメントが受信されたか判断するため、ＡＰＩＣ状態２０２の適切なエントリを照会する。そうでない場合、次のシーケンサのイベントを処理するように、状態５０４から抜け出す。

アクノリッジメントが受信された場合、アクノリッジメントがもはや待機されていないことを反映するため、マイクロアーキテクチャ状態３０３が更新される。インタラプトシーケンサブロック２１４はまた、状態５０２に戻る前にＡＰＩＣインスタンスのスコアボード３０４のエントリをクリアするかもしれない。少なくとも１つの実施例では、スコアボードのエントリ３０４は、現在サービスされているイベントがＡＰＩＣインスタンスの保留中のイベントのみである場合に限ってクリアされる。

他の例では、状態５０４においてサービスされるイベントがインタラプトメッセージの送信である場合（ローカルインターコネクト１０２又はシステムインターコネクト１０６を介した）、そのようなイベントは状態５０４において以下のようにサービスされる。インタラプトシーケンサブロック２１４は、現在サービスされている論理プロセッサのＡＰＩＣインスタンスから、上述した優先化処理が与えられた場合に何れの出力メッセージが提供される必要があるか判断する。その後、出力メッセージは、所望される送信先アドレスと共に、適切な出力メッセージキュー（出力ローカルメッセージキュー２０８又は出力システムメッセージキュー２１０）への送信のためスケジューリングされる。

出力メッセージが、アクノリッジメントの受信などの追加的なサービスをイベントが完全にサービスされる前に必要とする場合、中央化されたコントローラ１１０は、さらなるサービスが当該イベントに必要とされることを示すため、マイクロアーキテクチャ状態３０３を更新するかもしれない。（ローカルインターコネクト１０２又はシステムインターコネクト１０６を介した入力アクノリッジメントは、入力メッセージキュー２０４、２０６においてキューアップされ、最終的には、関連するＡＰＩＣインスタンスの状態５０４の次の繰り返しで処理可能となるように、中央化されたＡＰＩＣ状態２０２に更新されるかもしれない。その後、本方法は状態５０４から５０２に移行する。

図６は、開示された技術を実行可能なマルチスレッド計算システム９００の少なくとも１つの実施例を示す。計算システム９００は、少なくとも１つのプロセッサコア９０４（０）とメモリシステム９４０とを有する。システム９００は、破線及び楕円により示されるような追加的なコア（〜９０４（ｎ））を有するかもしれない。

メモリシステム９４０は、命令キャッシュ９４４及び／又はデータキャッシュ９４２などの１以上の小型で相対的に高速なキャッシュと共に、大型で相対的に低速なメモリストレージ９０２を有するかもしれない。メモリストレージ９０２は、プロセッサ９０４の動作を制御するための命令９１０とデータ９１２とを格納するかもしれない。

メモリシステム９４０は、メモリの一般化された表現として意図され、ハードドライブ、ＣＤ−ＲＯＭ、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ ＲＡＭ）、ＳＲＡＭ（Ｓｔａｔｉｃ ＲＡＭ）、フラッシュメモリ及び関連する回路などの各種形態のメモリを有するかもしれない。メモリシステム９４０は、プロセッサ９０４により実行可能なデータ信号により表される命令９１０及び／又はデータ９１２を格納するかもしれない。命令９１０及び／又はデータ９１２は、ここに記載された技術の何れか又はすべてを実行するためのコード及び／又はデータを有するかもしれない。

図６は、各プロセッサ９０４が中央化されたインタラプトコントローラ１１０に接続されていることを示す。各プロセッサ９０４は、命令情報を実行コア９３０に供給するフロントエンド９２０を有するかもしれない。フェッチされた命令情報は、実行コア９３０による実行を待機するため、キャッシュ２２５にバッファされるかもしれない。フロントエンド９２０は、命令情報を実行コア９３０にプログラム順に供給するかもしれない。少なくとも１つの実施例では、フロントエンド９２０は、実行される次の命令を決定するフェッチ／デコードユニット３２２を有する。システム９００の少なくとも１つの実施例では、フェッチ／デコードユニット３２２は、単一の次命令ポインタフェッチロジック３２０を有するかもしれない。しかしながら、各プロセッサ９０４が複数のスレッドコンテクストをサポートする実施例では、フェッチ／デコードユニット３２２は、サポートされる各スレッドコンテクストについて異なる次命令ポインタフェッチロジック３２０を実装する。マルチプロセッサ環境において追加的な次命令ポインタフェッチロジック３２０の任意的な性質は、図６の破線により示される。

ここに記載された方法の各実施例は、ハードウェア、ハードウェアエミュレーションソフトウェア若しくは他のソフトウェア、ファームウェア又はこのような実現アプローチの組み合わせにより実現可能である。本発明の各実施例は、少なくとも１つのプロセッサ、データストレージシステム（揮発性及び不揮発性メモリ及び／又はストレージ要素を含む）、少なくとも１つの入力装置及び少なくとも１つの出力装置を有するプログラマブルシステムについて実現可能である。このアプリケーションのため、処理システムは、デジタル信号プロセッサ（ＤＳＰ）、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、マイクロプロセッサなどのプロセッサを有する任意のシステムを含む。

プログラムは、汎用又は特定用途のプログラム可能な処理システムにより可読なストレージメディア又は装置（ハードディスクドライブ、フロッピー（登録商標）ディスクドライブ、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ−ＲＯＭ装置、フラッシュメモリ装置、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、又は他のストレージ装置など）に格納されてもよい。処理システムのプロセッサにアクセス可能な命令は、ストレージメディア又は装置がここに記載された手順を実行するため処理システムにより読み込まれると、処理システムを設定及び実行する。本発明の各実施例はまた、処理システムにより使用するため構成されたマシーン可読ストレージ媒体として実現されると考えられ、そのように構成されたストレージメディアは、処理システムにここに記載された機能を実行するため特定かつ所定の方法により実行させる。

一例となるシステム９００は、他のシステム（他のマイクロプロセッサ、エンジニアリングワークステーション、携帯情報端末、他の携帯装置、セットトップボックスなどを含む）がまた利用可能であるが、インテルコーポレイションから利用可能なＰｅｎｔｉｕｍ（登録商標）、Ｐｅｎｔｉｕｍ（登録商標）Ｐｒｏ、Ｐｅｎｔｉｕｍ（登録商標）ＩＩ、Ｐｅｎｔｉｕｍ（登録商標）ＩＩＩ、Ｐｅｎｔｉｕｍ（登録商標）４、Ｉｔａｎｉｕｍ（登録商標）、Ｉｔａｎｉｕｍ（登録商標）２マイクロプロセッサ、Ｍｏｂｉｌｅ Ｉｎｔｅｌ（登録商標）Ｐｅｎｔｉｕｍ（登録商標）ＩＩＩ Ｐｒｏｃｅｓｓｏｒ−Ｍ、Ｍｏｂｉｌｅ Ｉｎｔｅｌ（登録商標）Ｐｅｎｔｉｕｍ（登録商標）４ Ｐｒｏｃｅｓｓｏｒ−Ｍに基づく処理システムを表す。一実施例では、一例となるシステムは、他のオペレーティングシステム及びグラフィカルユーザインタフェースなどがまた利用可能であるが、マイクロソフトコーポレイションから利用可能なＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムのバージョンを実行するかもしれない。

本発明の特定の実施例が図示及び説明されたが、添付した請求項の範囲から逸脱することなく各種変更及び改良が可能であることは当業者に明らかであろう。例えば、中央化されたＡＰＩＣ状態２０２の少なくとも１つの実施例は、シングルリードポートとシングルライトポートのみを含むかもしれない。このような実施例では、入力システムメッセージキュー２０４、入力ローカルメッセージキュー２０６及びインタラプトシーケンサブロック２１４は、中央化されたＡＰＩＣ状態２０２へのアクセスを取得するため、アービトレーションロジック（図示せず）を利用するかもしれない。

また、例えば、図５に示された方法５００の少なくとも１つの実施例は状態５０８を排除するかもしれない。当業者は、状態５０８がパフォーマンスエンハンスメント（パワーセービング）を提供するだけであり、添付した請求項の発明の実施例には必要でないことを認識するであろう。

また、例えば、上述した中央化されたインタラプトコントローラ１１０の少なくとも１つの実施例は、スコアボード３０４を排除してもよいということが上述された。このような実施例では、インタラプトシーケンサ２１４は、ＡＰＩＣロジック２１２からのサービスを受け取るための次のＡＰＩＣインスタンスを決定するため、アーキテクチャＡＰＩＣ状態３０２のエントリ４１０をシーケンシャルにトラバースするかもしれない。

このため、当業者は、本発明から逸脱することなくそれの最も広範な側面において各種変更及び改良が可能であることを認識するであろう。添付した請求項は、本発明の真の範囲内に属するそのようなすべての変更及び改良をその範囲内に含むものである。

１００ システム
１０４ コア
１１０ インタラプトコントローラ
３５９ マルチコアスレッディング環境

Claims (24)

1. 複数の処理ユニットに対するインタラプトメッセージの提供のための優先化及び制御機能を実行し、前記複数の処理ユニットに共有される単一のロジックブロックと、
   前記ロジックブロックに接続され、前記ロジックブロックにより処理のため前記複数の処理ユニットのインタラプトイベントをスケジューリングするインタラプトシーケンサブロックと、
   前記複数の処理ユニットのそれぞれのアーキテクチャインタラプト状態情報を維持するストレージエリアと、
   入力インタラプトメッセージを受信し、前記メッセージからの情報を前記ストレージエリアに配置する１以上の入力メッセージキューと、
   出力インタラプトメッセージを送信する１以上の出力メッセージキューと、
   を有する装置。
2. 前記単一のロジックブロックは、各処理ユニットの冗長なロジックを有するのでなく冗長でない回路を有する、請求項１記載の装置。
3. 前記インタラプトシーケンサブロックは、公平性スキームに従って前記複数の処理ユニットのインタラプトイベントをスケジューリングする、請求項１記載の装置。
4. 前記インタラプトシーケンサブロックは、前記ストレージエリアのシーケンシャルなトラバースに従って前記複数の処理ユニットのインタラプトイベントをスケジューリングする、請求項３記載の装置。
5. 前記処理ユニットの何れが保留中のインタラプトイベントを有しているかに関するデータを維持するためのスコアボードをさらに有する、請求項１記載の装置。
6. 前記ストレージエリアはさらに、マイクロアーキテクチャ状態情報を格納する、請求項１記載の装置。
7. 前記複数のプロセッサは、ローカルインターコネクトを介し通信する、請求項１記載の装置。
8. 前記１以上の入力メッセージキューは、前記ローカルインターコネクトを介し入力インタラプトメッセージを受信するためのメッセージキューを有し、
   前記１以上の出力メッセージキューは、前記ローカルインターコネクトを介し出力インタラプトメッセージを送信するためのメッセージキューを有する、請求項７記載の装置。
9. 前記１以上の入力メッセージキューは、システムインターコネクトを介し入力インタラプトメッセージを受信するためのメッセージキューを有し、
   前記１以上の出力メッセージキューは、前記システムインターコネクトを介し出力インタラプトメッセージを送信するためのメッセージキューを有する、請求項７記載の装置。
10. 前記１以上の出力メッセージキューはさらに、前記ストレージエリアから前記出力インタラプトメッセージに関する情報を抽出する、請求項１記載の装置。
11. 前記１以上の出力メッセージキューはさらに、前記出力インタラプトメッセージの１以上の送信を禁止するためのファイアウォールロジックを有する、請求項１記載の装置。
12. 前記１以上の入力メッセージキューはさらに、前記処理ユニットの１以上への前記入力インタラプトメッセージの１以上の送信を禁止するためのファイアウォールロジックを有する、請求項１記載の装置。
13. 複数の処理ユニットの１つのアーキテクチャインタラプト状態を決定するため、ストレージアレイを照会するステップと、
    冗長でないインタラプト提供ブロックのインタラプト提供サービスについて前記処理ユニットの１つをスケジューリングするステップと、
    を有する方法であって、
    前記スケジューリングするステップは、各処理ユニットが前記インタラプト提供ブロックへの等しいアクセスを有することを可能にする公平性スキームに従って実行される方法。
14. 前記インタラプト提供ブロックは、アドバンスド・プログラマブル・インタラプト・コントローラロジックを有する、請求項１３記載の方法。
15. 前記公平性スキームは、１以上の保留中のインタラプトイベントを有する前記処理ユニットに対するシーケンシャルラウンドロビンスキームである、請求項１３記載の方法。
16. １以上のスレッドを実行する複数の処理ユニットと、
    前記処理ユニットに接続されるメモリと、
    前記複数の処理ユニットのインタラプト提供サービスを提供する共有されたインタラプトコントローラと、
    を有するシステム。
17. 前記共有されたインタラプトコントローラはさらに、前記複数の処理ユニットのＡＰＩＣインタラプト提供サービスを提供する、請求項１６記載のシステム。
18. 前記処理ユニットは、自己完結したＡＰＩＣインタラプト提供ロジックを有さない、請求項１６記載のシステム。
19. 前記共有されたインタラプトコントローラはさらに、ファイアウォールロジックを有する、請求項１６記載のシステム。
20. 前記複数の処理ユニットに接続されるローカルインターコネクトをさらに有する、請求項１６記載のシステム。
21. 前記共有されたインタラプトコントローラはさらに、前記ローカルインターコネクトを介し１以上のインタラプトメッセージの送信を禁止するファイアウォールロジックを有する、請求項２０記載のシステム。
22. 前記共有されたインタラプトコントローラに接続されるシステムインターコネクトをさらに有する、請求項１６記載のシステム。
23. 前記共有されたインタラプトコントローラはさらに、前記システムインターコネクトを介し１以上のインタラプトメッセージの送信を禁止するファイアウォールロジックを有する、請求項２２記載のシステム。
24. 前記共有されたインタラプトコントローラはさらに、前記複数の処理ユニットの間のインタラプトのシリアルサービスをスケジューリングする、請求項１６記載のシステム。

Images