(57)【要約】【課題】各機能実行部に対して複数の依頼元がある場合に、各依頼元からの依頼処理を個別に独立して管理できるプロセッサを提供する。【解決手段】プロセッサ１は、複数のタスクのそれぞれからの処理依頼に応じて所定の処理を複数受付可能な機能ブロック１２と、機能ブロック１２について、各タスクからの処理依頼の識別情報を保持するレジスタｒ１と、識別情報に対応して処理依頼に応じた所定の処理の終了を示す終了情報を保持するレジスタｒ２と、各タスクからの処理依頼を受け付け、各処理依頼に対して識別情報を生成してレジスタｒ１に記憶し、機能ブロック１２に各処理依頼の所定の処理を実行させ、かつ機能ブロック１２の動作状態を監視して所定の処理の終了を検出すると、終了情報を生成してレジスタｒ２に記憶する制御部１２ｃとを有する。【選択図】図１
2009151569.tif 000002
【特許請求の範囲】
【請求項１】
複数のタスクのそれぞれからの処理依頼に応じて所定の処理を複数受付可能な機能実行部と、
前記機能実行部に対する前記各タスクからの前記処理依頼の識別情報を保持する第１の情報保持部と、
前記識別情報に対応して前記処理依頼に応じた前記所定の処理の終了を示す終了情報を保持する第２の情報保持部と、
前記各タスクからの前記処理依頼を受け付け、各処理依頼に対して前記識別情報を生成して前記第１の情報保持部に記憶し、前記機能実行部に前記各処理依頼の前記所定の処理を実行させ、かつ前記機能実行部の動作状態を監視して前記所定の処理の終了を検出すると、前記終了情報を生成して前記第２の情報保持部に記憶する制御部と、
を有することを特徴とするプロセッサ。
【請求項２】
前記識別情報に対応して、前記識別情報の生成可否を制御するための識別情報生成可否情報を保持する第３の情報保持部を有し、
前記各タスクは、前記識別情報に対応する前記第３の情報保持部を介して、前記制御部に対して前記識別情報の生成可否を制御することを特徴とする請求項１に記載のプロセッサ。
【請求項３】
前記第１及び前記第２の情報保持部は、それぞれ第１及び第２のカウンタにより構成され、前記識別情報は、前記第１のカウンタのカウント値であり、前記終了情報は、前記第２のカウンタのカウント値であり、
前記制御部は、前記各タスクからの前記処理依頼に対して前記第１のカウンタをインクリメントすることによって前記識別情報を生成し、かつ前記機能実行部の動作状態を監視して前記所定の処理の終了を検出すると前記第２のカウンタをインクリメントすることによって前記終了情報を生成することを特徴とする請求項１に記載のプロセッサ。
【請求項４】
前記制御部は、前記各タスクからの前記処理依頼について、前記所定の処理の終了についての割込の発生の有無を制御できることを特徴とする請求項１から３のいずれか一つに記載のプロセッサ。
【請求項５】
前記複数のタスクのそれぞれからの処理依頼を出力するCPUを有し、前記CPU及び前記機能実行部は、１つの半導体基板上に設けられていることを特徴とする請求項１から４のいずれか一つに記載のプロセッサ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プロセッサに関し、特に、所定の処理を複数受付可能な機能実行部を有するプロセッサに関する。
【背景技術】
【０００２】
従来より、複数の機能ブロックを有するプロセッサが開発され、実用化されている。そして、シングルチップ上において、複数のコアを設けて処理能力を向上させるための技術の提案も各種行われている（例えば、特許文献１参照）。
【０００３】
プロセッサ内の複数の機能ブロックには、それぞれ各種処理の実行が依頼される。各機能ブロックにおける処理が実行中かあるいは停止中かを示す1bitのフラグは、各機能ブロックに関連付けられる。処理依頼をする依頼元のプログラムは、このフラグの状態をポーリングして参照することによって、その機能ブロックに依頼した処理が終了しているか否かの判定をすることができる。
【０００４】
しかしながら、複数の依頼元プログラム（以下、単に依頼元ともいう）が存在しうるオペレーティングシステムの動作する環境下において、このような1bitフラグの機構が用いられると、複数の依頼元からの各処理依頼に対して排他制御をした上で、各機能ブロックの1bitフラグの状態をポーリングしなければ、参照しているフラグの状態が各依頼元の処理に起因するものかを正しく判定することができない。
【０００５】
つまり、もし排他制御を行わないと、ある依頼元のタスクXのポーリング中にディスパッチが起こり、他のタスクYから機能ブロックの再実行がかかった場合、再び最初のタスクXにディスパッチがされると、最初のタスクXは自己の依頼した処理が未処理状態であるとの誤判定を引き起こす可能性がある。すなわち、1bitフラグしか使用できないので、依頼元Yによる機能ブロックの使用中を依頼元Xの処理が未完了であると誤判定することが起こりうる。
【０００６】
そこで、オペレーティングシステムにおいて排他制御を利用するようにしてもよいが、オペレーティングシステムで排他制御を利用する場合、機能ブロックの使用権を得た依頼元のポーリング動作がシステム全体で優先的に実行されないと、他の依頼元が必要以上に待たされるという非効率な状態が発生するという問題があった。
【０００７】
また、オペレーティングシステムにおける排他制御は、一般的にオーバーヘッドが存在する。そのため、複数の依頼元が存在する環境下では、各機能ブロックを利用するための共通の下請けタスクZを利用するような実装も可能である。その下請けタスクZは、対応する機能ブロックの状態ビットをポーリング機能または割り込み機能により監視し、WAITキューを用いて各依頼元からの機能ブロックの利用を管理する。下請けタスクZは、オペレーティングシステムの提供するイベント通知機能で、依頼順にWAITキューに入ったタスクを起床、あるいは各依頼元に持たせた状態ビットを処理済に書き換えるといった処理を実行する。
【０００８】
しかし、依頼元のプログラムがユーザータスクとカーネルの両方の場合が有り得たり、割り込み禁止区間内での依頼が含まれる場合には、このような下請けタスクを利用することができない場合もある。これは、カーネルとユーザタスク間で、排他制御の手続きを使用できないことがあるためである。また、排他制御を行いながらFIFOキューおよび機能ブロックを操作する下請けライブラリを用いる方法と採ると、前記ライブラリに対して各依頼元からのデータ構造や依頼手続きを統一しなければならない不具合がある。
【特許文献１】特開2005-216283号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は、各機能実行部に対して複数の依頼元がある場合に、各依頼元からの依頼処理を個別に独立して管理できるプロセッサを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一態様によれば、複数のタスクのそれぞれからの処理依頼に応じて所定の処理を複数受付可能な機能実行部と、前記機能実行部に対する前記各タスクからの前記処理依頼の識別情報を保持する第１の情報保持部と、前記識別情報に対応して前記処理依頼に応じた前記所定の処理の終了を示す終了情報を保持する第２の情報保持部と、前記各タスクからの前記処理依頼を受け付け、各処理依頼に対して前記識別情報を生成して前記第１の情報保持部に記憶し、前記機能実行部に前記各処理依頼の前記所定の処理を実行させ、かつ前記機能実行部の動作状態を監視して前記所定の処理の終了を検出すると、前記終了情報を生成して前記第２の情報保持部に記憶する制御部と、を有するプロセッサを提供することができる。
【発明の効果】
【００１１】
本発明によれば、各機能実行部に対して複数の依頼元がある場合に、各依頼元からの依頼処理を個別に独立して管理できるプロセッサを実現することができる。
【発明を実施するための最良の形態】
【００１２】
以下、図面を参照して本発明の実施の形態を説明する。  
まず図１に基づき、本実施の形態に係わるプロセッサの構成を説明する。図１は、本実施の形態に係わるプロセッサの構成を示す構成図である。
【００１３】
プロセッサ１は、複数のタスク、すなわちプログラムが実行される中央処理装置（以下、CPUという）１１と、複数の機能ブロック１２、１３、１４とを有して構成されている。CPU１１と複数の機能ブロックは、内部バス１５によって接続されている。ここでは、複数の機能ブロックは、３つの機能ブロック１２、１３、１４であり、それぞれ、汎用の、あるいは専用の、コアプロセッサあるいは、専用の処理を実行するハードウエアエンジンである。CPU１１は、図示しないメモリから処理すべき複数のタスクを読み出して実行することが可能なCPUであり、各タスクの実行に際して、各機能ブロック１２、１３、１４に必要な処理依頼を行う処理依頼機能を有する。
【００１４】
プロセッサ１では、CPU１１から各機能ブロック１２に必要な処理依頼がされ、各タスクの処理の一部を並列に処理するようにして処理能力の向上が図られている。なお、CPU１１と複数の機能ブロックは、一つの半導体基板上に設けられている、SoC（System on Chip）のチップである。  
各機能ブロックは、複数のタスクのそれぞれからの処理依頼に応じて所定の処理を複数受付可能でかつ実行可能な機能実行部である。そのため、各機能ブロックは、その所定の処理を複数受け付けて、受け付けた複数の処理を並列にあるいは逐次に実行すなわち処理するためのハードウエア回路を含む。例えば、所定の処理が画像処理であれば、一つの機能ブロックは、その画像処理を複数受け付けて、並列にあるいは逐次に実行するために、１つ以上の画像処理回路を、有している。あるいは、１つの機能ブロックが異なる処理を受け付けて、受け付けた処理を並行にあるいは逐次に実行するための、互いに異なる処理を実行する処理回路を有している。
【００１５】
よって、CPU１１上で実行される各タスクが、それぞれが２以上の処理を受付可能で、受け付けた処理の実行管理を可能な１以上の機能ブロックに対して処理依頼することによって、処理能力の向上が図られている。
【００１６】
以下、本実施の形態を説明するにあたり、説明を簡単にするために、CPU１１上で実行される複数のタスクから一つの機能ブロック１２に複数の処理依頼がされる場合について説明する。まず、CPU１１上では、タスクAとタスクBとが実行されているとする。
【００１７】
機能ブロック１２は、内部に２つのコア１２ａ、１２ｂを有している。すなわち、ここでは、機能ブロック１２の利用できるコア部の資源数は２である。機能ブロック１２は、処理依頼の依頼元であるCPU１１の２つのタスクA,Bから２つの処理依頼を受け付け、２つのコア部、すなわちコア１２ａ、１２ｂにおいて並列に実行可能に構成されている。
【００１８】
また、機能ブロック１２は、制御部１２ｃと、記憶部としての状態レジスタ１２ｄを有している。制御部１２ｃは、各タスクからの処理要求すなわち処理依頼を受け付け、各コア１２ａ、１２ｂに依頼された処理を実行させると共に、状態レジスタ１２ｄのデータ管理を行う。言い換えると、制御部１２ｃは、状態レジスタ１２ｄのデータを管理しながら、各コア部の実行制御を行う。
【００１９】
なお、ここでは、プロセッサ１は、３つの機能ブロック１２、１３、１４を有し、機能ブロック１２は、２つのコア１２ａ、１２ｂを有しているが、プロセッサ１は、１つ、２つあるいは４つ以上の機能ブロックを有していてもよく、各機能ブロックは、１つあるいは３つ以上のコア部を有していてもよい。例えば、機能ブロック１２は、暗号処理専用の機能ブロックであり、機能ブロック１３は、画像処理専用の機能ブロックであり、機能ブロック１４は、通信処理専用の機能ブロックである。機能ブロック１２の２つのコア部は、それぞれ同じ暗号処理を実行可能である。
【００２０】
ここで、状態レジスタ１２ｄの構成について説明する。図２は、状態レジスタ１２ｄの構成を説明するための図である。なお、図２では、初期状態が示され、状態レジスタ１２ｄの各ビットデータは、「０」（ゼロ）となっている。  
状態レジスタ１２ｄは、情報保持部として、３つのレジスタｒ１、ｒ２、ｒ３、ｒ４を含み、それぞれが８ビットのデータを保持できる。  
レジスタｒ１は、各タスクからの処理依頼の識別情報（以下、IDと略す）に関するID発行レジスタである。よって、情報保持部としてのレジスタｒ１には、依頼元毎のIDが保持される。ここでは、８ビットのビット列の各ビットの「１」が、依頼元のIDを示す。
【００２１】
レジスタｒ２は、各依頼元の処理状態に関する状態通知レジスタである。情報保持部としてのレジスタｒ２には、各依頼元に対応して、依頼された処理が未終了であるか、または処理が終了したかを示す情報が保持される。
【００２２】
レジスタｒ３は、IDのクリアに関するクリアレジスタである。情報保持部としてのレジスタｒ３は、タスクに割り当てられたIDに対応するレジスタｒ１中の「１」に対応して、レジスタｒ３に「１」を書き込むことによって、制御部１２ｃに、そのIDを生成すなわち発行が可能であることを知らしめるためのレジスタである。後述するように、各タスクは、このレジスタｒ３を介して、制御部１２ｃに対してIDの生成可否を制御する。
【００２３】
レジスタｒ４は、タスクへIDを通知するためのレジスタ、すなわちID通知レジスタである。
【００２４】
タスクにとっては、レジスタｒ２とｒ４は、データを読み出すためのレジスタであり、レジスタｒ３は、データを書き込むためのレジスタである。  
制御部１２ｃにとっては、レジスタｒ１とｒ２は、データを書き込むためのレジスタであり、レジスタｒ３は、データを読み出すためのレジスタであり、レジスタｒ４は、IDを通知するために、一時的にIDを保持するためのレジスタである。
【００２５】
なお、ここでは、機能ブロック１２について着目して説明するが、他の機能ブロック１３、１４においても、それぞれ状態レジスタ１２ｄが設けられ、各タスクからの処理依頼のIDを保持するレジスタｒ１と、IDに対応して処理依頼に応じた所定の処理の終了を示す終了情報を保持するレジスタｒ２と、IDのクリアを指示する、言い換えるとそのIDの識別情報の生成可否を制御するための識別情報生成可否情報を保持するレジスタｒ３と、タスクにIDを通知するためのID通知レジスタｒ４とを有している。
【００２６】
タスクAとBは、それぞれ、機能ブロック１２へ処理を依頼するときは、IDの読み出し要求をすることによって処理依頼を行う。すなわち、各タスクは、IDの読み出し要求に対して、IDが読み出せれば、処理依頼が受け入れられたと認識することになる。
【００２７】
なお、IDの読み出し要求自体を処理依頼あるいは処理要求とするのではなく、IDの読み出し要求に対して受信したIDに基づき、各タスクは、そのIDと共に処理依頼を、機能ブロック１２へ送信することによって処理依頼を行うようにしてもよい。
【００２８】
はじめに、機能ブロック１２における状態レジスタ１２ｄのデータの変化について、説明する。初期状態において、機能ブロック１２が何も処理を実行していないとする。図３と図４は、状態レジスタ１２ｄのデータの変化を説明するための図である。  
まず、タスクAが暗号処理の処理依頼を機能ブロック１２へ送信すると、制御部１２ｃは、タスクAからの処理依頼を受け付け、タスクAからの処理依頼に対して、状態レジスタ１２ｄを参照して、コア部に空きがあれば、IDを生成して発行する。例えば、ここでは、８ビット中の右端から１ビット目に、タスクAからの処理依頼についてのIDが付与できたとする。制御部１２ｃは、状態レジスタ１２ｄの内容を、状態SS0から状態SS1の状態に変更する。ここでは、８ビット中の右端から１ビット目の「１」が、タスクAからの処理依頼についてのIDを意味する。すなわち、８ビット中の右端から１ビット目が、タスクAのIDに対応する位置のビットである。
【００２９】
すなわち、状態レジスタ１２ｄにおいて、ID発行レジスタであるレジスタｒ１が「０００００００１」に変更され、かつ、そのIDが、ID通知レジスタｒ４に反映される。そして、そのID通知レジスタｒ４の情報がタスクAに送信され、タスクAは、IDデータとして、「０００００００１」を取得する。レジスタｒ４の内容は、タスクにIDが通知されるとクリアされる。
【００３０】
そして、制御部１２ｃは、タスクAからの処理依頼に基づく処理を実行中のときは、処理状況レジスタであるレジスタｒ２の、タスクAのIDに対応する位置のビットは「０」のままとしておく。レジスタｒ２の、タスクAのIDに対応する位置のビットは、８ビット中の右端から１ビット目である。すなわち、制御部１２ｃは、タスクAからの処理依頼を終了するまでは、状態レジスタ１２ｄを図３の状態SS1に維持する。
【００３１】
タスクAからの処理依頼に基づく処理の実行が終了すると、制御部１２ｃは、処理状況レジスタであるレジスタｒ２の、タスクAのIDに対応する位置のビットを「０」から「１」に書き換える。すなわち、制御部１２ｃは、タスクAからの処理依頼に基づく処理が終了すると、状態レジスタ１２ｄを図３の状態SS2に変更する。
【００３２】
一方、タスクAは、機能ブロック１２に処理を依頼した後、状態レジスタ１２ｄを参照し、データの変化の有無をチェックする。具体的には、タスクAは、レジスタｒ２の、タスクAのIDに対応する位置のビットが「０」から「１」に変更されたか否かをチェックする。レジスタｒ２の、タスクAのIDに対応する位置のビットが「０」から「１」に変更されていれば、タスクAは、自己の依頼した処理が終了したことを知ることができる。
【００３３】
タスクAは、レジスタｒ２の、タスクAのIDに対応する位置のビットが「０」から「１」に変更されたときは、クリアレジスタｒ３の、タスクAのIDに対応する位置のビットを、「１」に書き換える。レジスタｒ３の、タスクAのIDに対応する位置のビットは、８ビット中の右端から１ビット目である。このとき、状態レジスタ１２ｄの内容は、図３の状態SS3のようになる。  
制御部１２ａは、クリアレジスタｒ３のデータが「１」になると、レジスタｒ１、ｒ２、ｒ３の、タスクAのIDに対応する位置の各ビットを初期値、すなわち「０」に変更するように書き換え、その結果、状態レジスタ１２ｄは、図３の状態SS0のようになる。その結果、制御部１２ｃは、その後タスクAあるいはタスクBから処理依頼があったときには、その処理依頼に上記IDと同じID、すなわち「０００００００１」を再度生成して使用することができる。このように、タスクAは、レジスタｒ３を介して、制御部１２ｃに対してIDの生成可否を制御することができる。
【００３４】
また、タスクAからの処理依頼に加えて、タスクBからも処理依頼があった場合は、図４のようになる。
【００３５】
図４において、まず、タスクAからの処理依頼を受け付け、制御部１２ｃが、IDを発行し、ID通知レジスタｒ４にタスクAのIDの書き込みを行ったとき、状態レジスタ１２は、状態SS10のようになる。その後、レジスタｒ４の内容は、クリアされる。続いて、タスクBからの処理依頼も受け付けられ、制御部１２ｃが、IDを発行し、ID通知レジスタｒ４にタスクBのIDの書き込みを行ったとき、状態レジスタ１２ｄは、状態SS11のようになる。レジスタｒ１の、タスクBのIDに対応する位置のビットは、８ビット中の右端から２ビット目である。その後、レジスタｒ４の内容は、クリアされる。
【００３６】
その後、一つのコア部において、タスクAからの処理依頼に基づく処理が終了すると、状態レジスタ１２ｄは、状態SS12のようになる。
【００３７】
そして、タスクAからの処理依頼が終了したことによって、クリアレジスタであるレジスタｒ３の、タスクAのIDに対応する位置のビットが、タスクAにより「１」にされ、その結果、制御部１２ｃは、レジスタｒ１，ｒ２，ｒ３のそれぞれの、タスクAのIDに対応する位置のビットを「０」にする。このときの状態レジスタ１２ｄの内容は、状態SS13のようになる。
【００３８】
さらに、タスクBからの処理依頼に基づく処理が終了したときは、レジスタｒ２の、タスクBのIDに対応する位置のビットが「０」から「１」に変更される。このときの状態レジスタ１２ｄの内容は、状態SS14のようになる。その後の状態レジスタ１２ｄの内容の変化は、上述したタスクAについての処理と同様である。タスクBからの処理依頼についても処理が終了し、他にも処理依頼がなければ、状態レジスタ１２ｄの内容は、SS0の状態に戻る。
【００３９】
このように、状態レジスタ１２ｄには、各タスクからの処理依頼について発行されたIDのデータと、ID毎に処理が終了したか否かを示すデータと、各IDについての状態レジスタ１２ｄのデータをクリアすることを指示するデータとが保持される。また、状態レジスタ１２ｄのレジスタｒ４には、ID通知用のデータが保持される。本実施の形態では、IDは、８ビットのビット列のビット位置の情報であり、８つのIDの発行が可能な状態レジスタが用いられている。そして、上述したように、IDの発行及び管理と、処理の終了通知と、IDのクリア通知の３つの機能が、個別に区別されて実行可能となっているので、プロセッサ１において、複数の独立なタスクによる機能実行部の利用を、プロセッサ全体の少ない負荷で可能となっている。
【００４０】
次に、上述したような動作を実現する制御部１２ｃの処理の流れについて説明する。図５は、制御部１２ｃの処理依頼のコマンド受信時の処理の流れの例を示すフローチャートである。
【００４１】
まず、制御部１２ｃは、タスクからの処理依頼のコマンドを受信すると、処理依頼の受付処理を行う（ステップS1）。次に、制御部１２ｃは、各コア部の実行状態を確認する（ステップS2）。
【００４２】
そして、制御部１２ｃは、受け付けた処理依頼に対して、IDの発行が可能か否かを判定する（ステップS3）。IDの発行が可能か否かは、レジスタｒ１の８ビットの全てが「１」になっているか否かによって判定される。８ビットの全てが「１」になっている場合は、IDの発行が不可と判定され、８ビット中に一つ以上の「０」があれば、IDの発行が可能と判定される。
【００４３】
IDの発行が可能であるときには、ステップS3でYESとなり、次に、制御部１２ｃは、コア部に空きがあるか否かを判定する（ステップS4）。コア部に空きがあるか否かは、ここでは、２つのコア部が共に使用中すなわち実行中である場合は、コア部に空きが無しと判定され、１つ以上のコア部が使用中でなければ、コア部に空きが有りと判定される。
【００４４】
コア部に空きがあれば、ステップS4でYESとなり、制御部１２ｃは、そのタスクからの処理依頼に対して、IDを生成すなわち発行して、図３の状態SS1のように、そのIDをレジスタｒ１に記憶し、さらに、レジスタｒ４にそのIDを反映して、処理依頼を送信してきたタスクへ、そのレジスタｒ４のデータ、すなわち生成したIDのデータを送信する（ステップS5）。
【００４５】
そして、制御部１２ｃは、空いているコア部に依頼された所定の処理の実行指示を出力する（ステップS6）。各コア部は、制御部１２ｃからの実行指示に応じて、その所定の処理を実行する。以上のように、IDの発行ができたときには、制御部１２ｃは、IDの発行すなわち生成と同時に、空いているコア部に対して処理開始指示を行う。制御部１２ｃは、IDと実行を指示したコア部との対応関係の情報は保持している。
【００４６】
また、ステップS3およびS4において、IDの発行が不可あるいはコア部に空きがないときは、それぞれ、NOとなって、空きが無いことを、IDの読み込みをしたタスクに通知する（ステップS7）。
【００４７】
以上のように、図５の処理は、処理依頼のコマンドを受信すると、制御部１２ｃにおいて、その受信したコマンド毎に実行されることにより、タスク側における排他制御が不要となる。すなわち、制御部１２ｃでは、一つの処理依頼のコマンドを受信すると、その受信した処理依頼のコマンドについて、図５の処理が実行されるが、複数の処理依頼のコマンドを受信しても、受信した複数のコマンドのそれぞれについて、所定の順番に、図５の処理を実行することによってIDが発行されるので、複数の処理依頼のコマンド間でIDが重複する等の状態は生じない。
【００４８】
図６は、コア部への処理の実行指示後の制御部１２ｃの処理の流れの例を示すフローチャートである。  
制御部１２ｃは、各コア部の動作状態を監視し、コア部が、依頼された処理の実行を終了したか否かを判定する（ステップS11）。
【００４９】
２つのコア部のうち一つでも、依頼された処理の終了を検出したときは、ステップS11でYESとなり、制御部１２ｃは、レジスタｒ２の、そのコア部に処理を依頼したタスクのIDに対応する位置のビットに「１」を書き込む(ステップS12)。すなわち、制御部１２ｃは、処理の終了を検出すると、終了情報を生成して、レジスタｒ２に記憶させる。状態レジスタ１２ｄは、例えば、図３の状態SS2のような状態になる。制御部１２ｃは、レジスタｒ２に、終了情報としてのデータ「１」を書き込むことによって、処理の終了をタスクに知らせる。コア部が依頼された処理を終了していないときは、ステップS11でNOとなり、制御部１２ｃは、処理の終了を待つ。
【００５０】
次に、各タスクの処理を説明する。図７は、各タスクにおける処理の流れの例を示すフローチャートである。  
図７に示すように、各タスクは、処理を依頼したい機能ブロックに対してIDの読み出しを要求、すなわちIDの読み出し要求を送信する（ステップS21）。本実施の形態では、IDの読み出し要求は、処理依頼コマンドの送信と同じ意であるので、ステップS21の処理は、タスクから機能ブロックへの処理依頼である。
【００５１】
次に、タスクは機能ブロック１２から、IDを受信したか否かを判定する（ステップS22）。この判定は、IDが発行されたか否か、すなわち機能ブロック１２からIDを受信したか否かによって行われる。IDを受信せず、上述したステップS7に応じた通知があれば、ステップS22でNOとなり、依頼された処理は実行できないこととなるので、処理は、終了する。また、上述したステップS5に応じたIDを受信すれば、ステップS22でYESとなり、処理依頼が受け付けられたことになる。よって、ステップS22でNOの場合は、処理は終了するが、その場合、そのタスクは、例えば、一定の時間が経過後に、図７の処理を再度実行、すなわちリトライをすることになる。
【００５２】
タスクは、IDを受信すると、その後は、ポーリングによってレジスタｒ２のデータの読み出しを行う（ステップS23）。なお、この場合のポーリングは排他的に行われる必要はなく、各タスクが、レジスタｒ２にアクセスすることによって行われる。これにより、機能ブロックの処理の終了と、各タスクへの通知が非同期に行われることが可能となっている。
【００５３】
そして、タスクは、読み出したレジスタｒ２のデータにおいて、受信した自己のIDに対応する位置のビットが「１」であるか否かを判定する(ステップS24)。
【００５４】
ステップS24で読み出したレジスタｒ２の、自己のIDに対応する位置のビットが「１」でなければ、ステップS24でNOとなり、処理は、ステップS23に戻る。
【００５５】
ステップS24で読み出したレジスタｒ２の、IDに対応する位置のビットが「１」であると、ステップS24でYESとなり、タスクは、依頼した処理の終了を検出することができる（ステップS25）。そして、タスクは、機能ブロックのレジスタｒ３の、IDに対応する位置のビットを「１」に変更するように制御部１２ｃに指示する（ステップS26）。タスクがレジスタｒ３の、IDに対応する位置のビットを「１」にするように指示することによって、タスクは、制御部１２ｃに、そのIDを別なタスクからの処理依頼に対して発行可能になったことを通知することができる。
【００５６】
すなわち、タスクは、レジスタｒ３の、自己のIDに対応する位置のビットに「１」を記憶することによって、再度そのIDが生成可能あるいは利用可能になったことを示すID生成可能情報を、制御部１２ｃに通知することになる。
【００５７】
図８は、制御部１２ｃにおけるクリア処理の流れの例を示すフローチャートである。ステップS26の結果、レジスタｒ３の内容が変更されるので、制御部１２ｃは、レジスタｒ３のデータを定期的に監視し、レジスタｒ３中のいずれかのビットが「１」になった場合、図８の処理を実行する。すなわち、制御部１２ｃは、３つのレジスタｒ１、ｒ２、ｒ３における、レジスタｒ３の「１」になっている位置のビットに対応するビット位置の「１」を消去して、全てを初期値の「０」に変更する（ステップS31）。
【００５８】
なお、タスクがステップS26においてレジスタｒ３に「１」の書き込みを指示するが、その指示を受信すると、制御部１２ｃが、ステップS31のような、IDに対応する位置のビットを初期化するようにしてもよい。
【００５９】
以上のように、各タスクからの処理依頼に応じてIDが発行され、そのIDがレジスタｒ４に記憶され、処理を依頼したタスクに通知される。そのID毎に依頼された処理が終了すると、その処理が終了したことを示す情報が、ID毎に対応してレジスタｒ２に記憶される。そのレジスタｒ２の情報を参照することによって、各タスクは、自己の依頼した処理が終了したことを知ることができる。
【００６０】
このような構成によれば、先に依頼された処理よりも後に依頼された処理が早く終了することが許容され、その結果、各機能ブロックに対する処理依頼の開始のタイミングと処理の終了の通知のタイミングの順序が自由となる。
【００６１】
以上のように、上述した実施の形態によれば、各機能ブロックに対して複数の依頼元のタスクがある場合に、各依頼元からの依頼処理を個別に独立して管理できるプロセッサを実現することができる。上述した例では、複数のビット列の各ビットに対応したIDが各タスクに発行されるので、そのビット列のビット数の数だけの複数の依頼元が一つの機能ブロックにアクセス可能となっている。
【００６２】
なお、上述した例では、コア部への処理依頼であるIDの読み出しと、処理の開始とは同時であるが、同時にしなくてもよい。例えば、タスクがIDの読み出しをできたときに、処理の開始を明示的に行うように、そのタスクが機能ブロックに対して、受信したIDと共に処理開始指示を送信するようにしてもよい。
【００６３】
さらになお、上述した例では、コア部に空きがない場合は、IDは生成されず、コア部に空きがあるときにIDが生成され、コア部への実行指示がなされているが、コア部に空きがない場合であっても、１つのコア部において複数の処理を代わる代わる実行可能な場合は、受け付け可能な範囲で複数の処理依頼が受け付けられてコア部への実行指示がなされるようにしてもよい。
【００６４】
また、上述した例では、各タスクはレジスタｒ２のデータをポーリングにより読み出していたが、機能ブロックの各コア部の処理終了を割込処理により、対応するタスクに知らせるようにしてもよい。コア部の処理終了を割込処理により、タスクに処理終了を通知するようにすると、タスクは、その通知に応じてレジスタｒ２のデータを読み出す。その場合、タスクは、先に依頼した処理よりも、後から依頼した処理が先に終了したことの検出が可能となる。
【００６５】
（第２の実施の形態）
上述した第１の実施の形態では、状態レジスタは４つのレジスタから構成され、IDはレジスタのビット位置の情報によって示されて、ビット位置の情報をクリアすることによって、ビット位置のIDの再利用を行うようにしている。
【００６６】
これに対して、第２の実施の形態では、状態レジスタは２つのカウンタから構成され、IDはカウンタ値により示すようにして、上述したクリア処理を不要としている。
【００６７】
以下、第２の実施の形態のプロセッサについて説明するが、本実施の形態のプロセッサは、第１の実施の形態のプロセッサの構成とほとんど同一の構成要素から構成されるので、異なる構成について主として説明する。
【００６８】
図９は、第２の実施の形態の状態レジスタの構成を説明するための図である。状態レジスタ１２ｄ１は、情報保持部としての２つのカウンタｃ１１とｃ１２とを含んで構成されている。カウンタｃ１１が、IDの情報を保持するカウンタである。後述するように、IDは、カウンタｃ１１のカウンタ値で示される。
【００６９】
カウンタｃ１２は、処理の終了したIDの情報を保持するカウンタである。後述するように、処理の終了したIDは、カウンタｃ１２のカウンタ値で示される。
【００７０】
制御部１２ｃにおける処理依頼のコマンド受信時の処理の流れは、上述した図５の処理と同様であるが、ステップS5において、制御部１２は、カウンタとしてのカウンタｃ１１を１だけインクリメントしたカウント値を、IDとして決定して送信するようにした点が、第１の実施の形態と異なっている。カウンタｃ１１は、ID発行レジスタであると共に、ID通知レジスタでもある。
【００７１】
従って、IDは、制御部１２ｃの指示によってインクリメントされるカウント値として決定される。
【００７２】
そして、制御部１２ｃにおけるコア部への処理の実行指示後の処理は、図６に代えて、図１０のようになる。図１０は、制御部１２ｃのコア部への処理の実行指示後の処理の流れの例を示すフローチャートである。
【００７３】
図１０に示すように、コア部における処理が終了すると、制御部１２ｃは、カウンタｃ１２をインクリメントする（ステップS41）。機能ブロックにおいて処理が順番に行われ、その順番で処理が終了するものとすれば、カウンタｃ１２のカウント値は、処理の終了したIDを示すことになる。タスクは、通知を受けたIDを保持する。
【００７４】
一方、各タスクは、IDの読み出し要求を行った後は、図１１に示す通りの処理を実行する。図１１は、各タスクにおける処理の流れの例を示すフローチャートであり、図７と同じ処理については、説明は省略する。
【００７５】
図１１に示すように、各タスクは、ステップS5に応じたIDを受信して、ステップS22でYESとなり、処理依頼が受け付けられた後は、カウンタｃ１２のデータを読み出す（ステップS23）。
【００７６】
そして、各タスクは、読み出したカウンタｃ１２のカウント値と、保持しているIDとを比較し、カウンタｃ１２のカウント値が、ID以上であるか否かを判定する(ステップS51)。
【００７７】
ステップS51において、カウンタｃ１２のカウント値がIDの値以上でなければ、タスクは、依頼した処理が終了していないので、ステップS51でNOとなり、処理は、ステップS23に戻る。
【００７８】
ステップS51において、カウンタｃ１２のカウント値が、発行されたIDの値以上であれば、タスクは、依頼した処理が終了したことになるので、ステップS51でYESとなり、依頼した処理の終了を検出することができる。
【００７９】
なお、カウンタｃ１１とｃ１２のビット数が十分に大きな場合を除き、各カウンタｃ１１とｃ１２の各カウント値はオーバフローする場合もあるので、処理の終了したカウント値がオーバフローする充分に前のタイミングである所定のタイミングで、状態レジスタ１２ｄ１の各カウンタに対してクリア処理を行うようなカウンタ管理処理が、制御部１２ｃによって実行される。
【００８０】
以上のように、本実施の形態によれば、IDをカウント値としたことにより、情報保持部としてのレジスタは少なくとも２つで済むので、回路構成が簡素となり、かつクリア処理も不要となる。
【００８１】
（第３の実施の形態）
本第３の実施の形態に係るプロセッサでは、制御部は、タスクからの処理依頼の中で特定の、あるいは所望の処理依頼について依頼された処理の終了について割込発生の有無を制御できるようにした。
【００８２】
以下、第３の実施の形態のプロセッサについて説明するが、本実施の形態のプロセッサは、第１の実施の形態と同じであるため、異なる構成について説明する。
【００８３】
図１２は、本実施の形態の状態レジスタ１２ｄ２の構成を説明するための図である。状態レジスタ１２ｄ２は、ID発行レジスタであるレジスタｒ１に加えて、後述する割り込みオプション付きの処理依頼用の第２のID発行レジスタｒ１ａも有している。さらに、割り込みオプション付きの処理依頼用のID通知レジスタｒ４ａも有している。
【００８４】
後述するオプション付きの処理依頼の場合には、IDは、第２のID発行レジスタｒ１ａにも記憶される。
【００８５】
図１３は、本実施の形態における割込オプション付きの処理依頼をした場合における各タスクにおける処理の流れの例を示すフローチャートである。図７と同じ処理については、同じステップ番号を付し、説明は省略する。なお、割込オプション付きでない処理依頼のときの処理は、第１の実施の形態と同様である。
【００８６】
図１３に示すように、タスクは処理を依頼するときに、その処理の重要度あるいは優先度を認識している場合があり、各タスクは、機能ブロックに処理を依頼するときに、処理の終了を割り込み処理により通知してもらいたい場合がある。その場合、タスクは、割込オプション付きのIDの読み出し要求を機能ブロックへ送信する（ステップS61）。割込オプション付きのIDの読み出し要求は、処理依頼のコマンドに、依頼した処理が終了したときにその終了を割込処理で通知する指示が付加されたものである。
【００８７】
なお、この割込オプション付きのIDの読み出し要求でない場合は、タスクは、レジスタｒ４の内容が制御部１２ｃから送信されることにより、あるいはレジスタｒ４の内容を読み出すことにより、IDを取得するが、割込オプション付きのIDの読み出し要求の場合は、タスクは、レジスタｒ４ａの内容が制御部１２ｃから送信されることにより、あるいはレジスタｒ４ａの内容を読み出すことにより、IDを取得する。
【００８８】
そして、タスクは、IDを受信後は、割り込み信号を受信したか否かが判定され（ステップS62）、割り込み信号を受信しないときは、処理は何もしない。割り込み信号を受信したときは、ステップS62でYESとなって、タスクは、依頼した処理の終了を検出することができる（ステップS25）。そして、タスクは、機能ブロックのレジスタｒ３の、自己のIDに対応する位置のビットを「１」に変更するように制御部１２ｃに指示する（ステップS26）。
【００８９】
一方、制御部では、図１４に示す処理が行われる。図１４は、コア部への処理の実行指示後の制御部１２ｃの処理の流れの例を示すフローチャートである。
【００９０】
制御部１２ｃは、各コア部の実行状態を監視し、コア部が依頼された処理の実行を終了したか否かを判定し（ステップS11）、コア部が依頼された処理の実行を終了したときは、制御部１２ｃは、レジスタｒ２の、そのコア部に処理を依頼したタスクについて発行されたIDに対応する位置のビットに「１」を書き込む(ステップS12)。そして、制御部１２ｃは、処理の終了をタスクに知らせるために、コア部が依頼された処理の実行を終了したことを示す割り込み信号を依頼元のタスクに送信する割込処理を実行する（ステップS71）。
【００９１】
なお、処理が終了すると、クリア処理においては、レジスタｒ１からｒ２だけでなく、第２のID発行レジスタｒ１ａについても、IDに対応する位置のビットがクリアされる。
【００９２】
以上のように、本実施の形態によれば、制御部は、各タスクからの処理依頼について、その依頼された所定の処理の終了について割込の発生の有無を制御できるように構成されている。上述した例では、制御部は、割込処理により通知する指示があったときは、所定の処理の終了を割込処理によりタスクに通知する。従って、タスクは、処理の重要度あるいは優先度に応じて、機能ブロックへの処理依頼を割込オプション付きで行うことができるので、応答速度の向上を図ることができる。
【００９３】
なお、上述した例では、IDの読み出し要求自体に割込オプションが付加されていたが、割込処理によって通知する指示は、読み出し要求とは別になされるようにしてもよい。例えば、IDが発行されて通知を受けた後に、処理の実行指示をするような構成の場合は、その処理の実行指示に割込オプションを付加して行うようにしてもよい。
【００９４】
また、本実施の形態によれば、割込処理を利用しない非リアルタイムな処理を実行するタスクと、割込処理を利用してリアルタイムの処理を実行するタスクの混在も可能となる。
【００９５】
以上説明したように、上述した各実施の形態に係るプロセッサによれば、各機能ブロックに対して複数の依頼元がある場合に、各依頼元からの依頼処理を個別に独立して管理することができる。
【００９６】
そして、上述した各実施の形態に係るプロセッサによれば、各タスクからの処理依頼の区別と、各処理依頼に基づく処理の終了の通知が、非同期に行うことができるので、プロセッサ上の各タスクからの処理の依頼から終了までの制御ための負荷を軽減することができる。
【００９７】
本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。
【図面の簡単な説明】
【００９８】
【図１】本発明の第１の実施の形態に係わるプロセッサの構成を示す構成図である。
【図２】本発明の第１の実施の形態に係わる状態レジスタの構成を説明するための図である。
【図３】本発明の第１の実施の形態に係わる状態レジスタのデータの変化を説明するための図である。
【図４】本発明の第１の実施の形態に係わる状態レジスタのデータの変化を説明するための図である。
【図５】本発明の第１の実施の形態に係わる制御部の処理依頼のコマンド受信時の処理の流れの例を示すフローチャートである。
【図６】本発明の第１の実施の形態に係わる、コア部への処理の実行指示後の制御部の処理の流れの例を示すフローチャートである。
【図７】本発明の第１の実施の形態に係わる、各タスクにおける処理の流れの例を示すフローチャートである。
【図８】本発明の第１の実施の形態に係わる、制御部におけるクリア処理の流れの例を示すフローチャートである。
【図９】本発明の第２の実施の形態に係わる状態レジスタの構成を説明するための図である。
【図１０】本発明の第２の実施の形態に係わる制御部１２ｃのコア部への処理の実行指示後の処理の流れの例を示すフローチャートである。
【図１１】本発明の第２の実施の形態に係わる、各タスクにおける処理の流れの例を示すフローチャートである。
【図１２】本発明の第３の実施の形態に係わる、状態レジスタの構成を説明するための図である。
【図１３】本発明の第３の実施の形態に係わる、割込オプション付きの処理依頼をした場合における各タスクにおける処理の流れの例を示すフローチャートである。
【図１４】本発明の第３の実施の形態に係わる、コア部への処理の実行指示後の制御部１２ｃの処理の流れの例を示すフローチャートである。
【符号の説明】
【００９９】
１  プロセッサ、１１  ＣＰＵ、１２，１３，１４・・・機能ブロック、１２ａ、１２ｂ  コア、１２ｃ  制御部、１２ｄ、１２ｄ１、１２ｄ２  状態レジスタ、１５  バス
【図１】
2009151569.tif 000003
【図２】
2009151569.tif 000004
【図３】
2009151569.tif 000005
【図４】
2009151569.tif 000006
【図５】
2009151569.tif 000007
【図６】
2009151569.tif 000008
【図７】
2009151569.tif 000009
【図８】
2009151569.tif 000010
【図９】
2009151569.tif 000011
【図１０】
2009151569.tif 000012
【図１１】
2009151569.tif 000013
【図１２】
2009151569.tif 000014
【図１３】
2009151569.tif 000015
【図１４】
2009151569.tif 000016