JP2006040174A - 命令リトライ検証機能付き情報処理装置および命令リトライ検証方法 - Google Patents

Abstract

【課題】命令リトライ機能を何度でも繰り返して実行して動作検証をおこなうこと。
【解決手段】パリティ生成回路２０２は、生成したパリティデータを反転させることで完了判定時に意図的にＣＳＥエントリのパリティエラーを検出させ、命令リトライを実行させる。パリティエラーの検出をおこなうパリティチェック回路２０５は、命令リトライの実行を依頼すると命令リトライ機構によりプログラムが停止し、検証が中止されてしまう場合にはパリティエラーを検出しなかったものとし、命令リトライの実行を抑制する。
【選択図】 図４

Description

この発明は、異常発生時に命令を再実行する命令リトライ機構を備えた情報処理装置およびその情報処理装置における命令リトライ検証方法に関し、特に命令リトライを繰り返して実行させて動作を検証することができ、もって命令リトライ機能の品質を向上させることができる情報処理装置および命令リトライ検証方法に関するものである。

従来より、情報処理装置は、Ｒｅｌｉａｂｉｌｉｔｙ（信頼性）、Ａｖａｉｌａｂｉｌｉｔｙ（可用性）およびＳｅｒｖｉｃｅａｂｉｌｉｔｙ（保守性）を確保するためのＲＡＳ機能と呼ばれる機能を備えている。

ＲＡＳ機能の一つである命令リトライ機能は、情報処理装置の動作中に回路の一部が故障する等の障害が発生した場合に、命令を再実行してプログラムを停止させることなく、正常に動作させる機能である（例えば、特許文献１）。

特開昭５８−３９３５１号公報

しかしながら、命令リトライ機能は、これまで十分な動作の検証をおこなうことができていなかった。これは、命令の再実行が不可能なタイミングが存在し、命令リトライ機能を何回も繰り返して動作させることができないためである。命令の再実行が不可能なタイミングで命令リトライ機能が動作すると、プログラムが停止し、それ以降の動作検証ができなくなってしまう。

この発明は、上述した従来技術による問題点を解消するためになされたものであり、命令リトライ機能を何度も繰り返し動作させて検証することができ、もって高い品質をもった命令リトライ機能を実現させることができる情報処理装置および命令リトライ検証方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明は、異常発生時に命令を再実行する命令リトライ機構と、アウトオブオーダで実行される命令に係る情報を本来のインオーダの順序で保持し、命令の完了順序を制御するコミットスタックエントリとを備えた情報処理装置であって、当該の情報処理装置の状態を通常動作のための通常状態もしくは動作検証のための検証状態に設定する状態設定手段と、前記コミットスタックエントリへ命令に係る情報を登録する際に、当該の情報処理装置が検証状態にある場合には、前記情報の内容を改竄し、パリティエラーが検出される状態で登録するエントリ登録手段と、前記コミットスタックエントリのエントリのうち当該のサイクルで命令が完了する可能性のあるエントリの完了判定とパリティチェックをおこない、いずれかのエントリにパリティエラーを検出した場合には前記命令リトライ機構に対して前記コミットスタックエントリに登録されている最も古い命令からの再実行を依頼する完了判定手段とを備えたことを特徴とする。

また、本発明は、命令の実行中に異常が発覚した場合に実行中の命令を再実行する命令リトライ機構と、アウトオブオーダで実行される命令を本来のインオーダの順序で保持し、命令の完了順序を制御するコミットスタックエントリとを備えた情報処理装置における命令リトライ検証方法であって、前記コミットスタックエントリへ命令に係る情報を登録する際に、当該の情報処理装置が検証状態にある場合には、前記情報の内容を改竄し、パリティエラーが検出される状態で登録するエントリ登録工程と、当該の情報処理装置が検証状態にある場合には、前記コミットスタックエントリへパリティエラーとなるデータを登録するエントリ登録工程と、前記コミットスタックエントリのエントリのうち当該のサイクルで命令が完了する可能性のあるエントリの完了判定とパリティチェックをおこない、いずれかのエントリにパリティエラーを検出した場合には前記命令リトライ機構に対して前記コミットスタックエントリに登録されている最も古い命令からの再実行を依頼する完了判定工程とを含んだことを特徴とする。

この発明によれば、情報処理装置が検証状態にある場合には意図的にコミットスタックエントリのパリティエラーを発生させ、これにより命令リトライが実行されるように構成したので、情報処理装置を検証状態にすることで命令リトライを繰り返し実行させて動作検証をおこなうことができる。

また、本発明は、上記の発明において、前記エントリ登録手段は、当該の情報処理装置が検証状態にある場合には、前記コミットスタックエントリへ登録するデータのパリティビットを反転させ、パリティエラーが検出される状態で登録することを特徴とする。

この発明によれば、パリティビットを反転させることによってパリティエラーを発生させるように構成したので、情報処理装置が正常動作するのに必要な情報を変更することなく命令リトライを実行させることができる。

また、本発明は、上記の発明において、前記完了判定手段は、当該の情報処理装置が検証状態にあるときにパリティエラーを検出した場合、前記コミットスタックエントリに再実行の依頼をおこなうと前期命令リトライ機構によりプログラムが停止する命令が含まれていることを検出したならば、前記命令リトライ機構に対して命令の再実行の依頼をおこなわずに、パリティエラーがなかったものとして完了判定処理を継続することを特徴とする。

この発明によれば、情報処理装置が検証状態にある場合、命令リトライの実行が不可能なタイミングでは命令リトライをおこなわせないように構成したので、命令リトライの実行が不可能なタイミングが発生してもプログラムを停止させることなく動作検証を継続させることができる。

本発明によれば、情報処理装置が検証状態にある場合には意図的にコミットスタックエントリのパリティエラーを発生させ、これにより命令リトライが実行されるように構成したので、情報処理装置を検証状態にすることで命令リトライを繰り返し実行させて動作検証をおこなうことができるという効果を奏する。

また、本発明によれば、パリティビットを反転させることによってパリティエラーを発生させるように構成したので、情報処理装置が正常動作するのに必要な情報を変更することなく命令リトライを実行させることができるという効果を奏する。

また、本発明によれば、情報処理装置が検証状態にある場合、命令リトライの実行が不可能なタイミングでは命令リトライをおこなわせないように構成したので、命令リトライの実行が不可能なタイミングが発生してもプログラムを停止させることなく動作検証を継続させることができるという効果を奏する。

以下に添付図面を参照して、この発明に係る情報処理装置および命令リトライ検証方法の好適な実施の形態を詳細に説明する。

まず、本実施例に係る情報処理装置の概要について説明する。図１は、本実施例に係る情報処理装置全体の概要を示すブロック図である。同図に示すように、本実施例に係る情報処理装置においては、命令フェッチアドレス生成器１００もしくはブランチヒストリ１０１の指示により１次命令フェッチキャッシュ１０２から読取られた命令は、命令バッファ１０３に一時保持され、命令デコーダ１０４によりインオーダでデコードされる。

デコードされた命令は、命令の種類に応じてアドレス生成リザベーションステーション（ＲＳＡ）１０５、整数演算リザベーションステーション（ＲＳＥ）１０６、浮動小数演算リザベーションステーション（ＲＳＦ）１０７または分岐リザベーションステーション（ＲＳＢＲ）１０８に振り分けられ、アウトオブオーダで実行される。

デコードされた命令に関する情報はコミットスタックエントリ（以下、「ＣＳＥ（Commit Stack Entry）」と言う。）２１０にも送られる。ＣＳＥ２１０は、各リザベーションステーションで実行される命令の実行状況等に関する情報をインオーダの順序で保持し、命令の完了を制御する装置である。

図２は、ＣＳＥ２１０の構成を説明するための説明図である。同図に示すように、ＣＳＥ２１０は、命令デコーダ１０４でデコードされた命令ごとにエントリを作成する。各エントリは、命令デコーダ１０４から送信された信号とデータ誤り検出のためのパリティビットで構成される。

図３は、ＣＳＥ２１０をもちいた完了判定動作を説明するための説明図である。同図に示すように、ＣＳＥ２１０は、次サイクルで完了する可能性のある命令のエントリを選択して完了対象エントリ２１１へ登録する。完了対象エントリ２１１の各エントリは、別項で説明する完了判定回路２０４によって完了判定され、完了した命令については、プログラムカウンタやレジスタ等の資源の更新とＣＳＥ２１０のエントリの解放とがおこなわれる。

この完了判定時にいずれかのエントリでパリティエラーが検出された場合には、当該のサイクルで完了対象となった最も古い命令からフェッチ動作をやり直す命令リトライが命令リトライ機構２０６によっておこなわれる。本実施例に係る情報処理装置および命令リトライ検証方法は、このＣＳＥ２１の命令リトライの仕組みを利用して命令リトライの検証をおこなう。

次に、本実施例に係る命令リトライ検証方式に関連する装置の構成について説明する。図４は、本実施例に係る命令リトライ検証方式に関連する装置の構成を示すブロック図である。

命令デコーダ１０４は、既に説明した通り、１次命令フェッチキャッシュ１０２から読取られた命令をインオーダでデコードし、デコードした命令を命令の種類に応じてレザベーションステーションに振り分ける装置である。また、命令デコーダ１０４は、デコードした命令の完了制御をおこなうために、デコードした命令に係る情報をエントリ登録回路２０１へ送出する。

エントリ登録回路２０１は、命令デコーダ１０４から送出された情報をＣＳＥ２９０のエントリへ登録する回路である。エントリ登録回路２０１は、ＣＳＥ２９０のエントリへ情報を登録するに際して、データ誤りを検出するためのパリティデータを情報に付加する。

パリティ生成回路２０２は、エントリ登録回路２０１が付加するパリティデータを生成する回路である。パリティ生成回路２０２は、ＪＴＡＧ機構２０８からのＥＲＲＯＲ＿ＩＮＪＥＣＴＩＯＮ信号の状態により、生成するパリティデータを変化させる。

図５は、パリティ生成回路２０２の構成を示すブロック図である。同図に示すように、命令デコーダ１０４から送出されたＤｘ＿ＴＡＧ＿１〜Ｄｘ＿ＴＡＧ＿ｎの信号から生成された１ビットのパリティデータは、ＥＲＲＯＲ＿ＩＮＪＥＣＴＩＯＮ信号がオフの場合は、Ｄｘ＿ＲＥＬ＿ＣＳＥｍ信号がオンになったタイミングでこの信号に対応するＣＳＥのエントリにそのまま送出される。

一方、ＥＲＲＯＲ＿ＩＮＪＥＣＴＩＯＮ信号がオンの場合は、Ｄｘ＿ＴＡＧ＿１〜Ｄｘ＿ＴＡＧ＿ｎの信号から生成された１ビットのパリティデータは、ＥＯＲ回路によって反転されて送出される。反転されたパリティデータは、命令の完了判定の際にパリティエラーを検出させ、命令リトライを発生させることになる。

このように、本実施例に係る命令リトライ検証方式においては、命令リトライの動作検証をおこなう際は、パリティ生成回路２０２に反転したパリティデータを生成させ、これにより意図的にパリティエラーを検出させて命令リトライを発生させる。命令リトライを発生させるためにパリティエラーを検出させることだけが目的であれば、パリティデータ以外を化けさせてもよいが、パリティデータ以外を化けさせると情報処理装置の動作に影響がでるおそれがあるため、パリティデータのみを反転させる。

完了対象エントリ選択回路２０３は、次のサイクルで完了する可能性のある命令の情報を格納したエントリをＣＳＥ２１０より選択し、完了対象エントリ２１１へ転記する回路である。完了対象エントリ２１１へ転記されたエントリは、完了判定回路２０４による完了判定の対象となる。

完了判定回路２０４は、完了対象エントリ２１１の各エントリに対応する命令が完了したものとしてよいか否かを判定する回路である。完了判定回路２０４は、完了判定をおこなうに際して、エントリに設定された情報のパリティチェックをおこなう。そして、いずれかのエントリでパリティエラーを検出した場合は、完了判定を中止し、ＣＳＥ２１０においてパリティエラーが発生した旨を命令リトライ機構２０６に通知する。

パリティチェック回路２０５は、完了対象エントリ２１１の各エントリのパリティをチェックする回路である。このパリティチェック回路２０５がパリティエラーを検出すると、完了判定回路２０４が命令リトライ機構２０６へエラーの発生を通知し、命令リトライがおこなわれることになる。

命令リトライの動作検証をおこなう場合、前述のように、完了対象エントリ２１１にパリティデータを反転させたデータが登録される。このため、命令リトライの動作検証中はＣＳＥ２１０のエントリが有効なときにどのサイクルにおいてもパリティエラーを検出させることが可能となり、命令リトライがおこなわれることになるが、これには問題がある。

命令リトライは常におこなうことができるものではなく、命令リトライ不能なタイミングが存在する。そのようなタイミングで命令リトライをおこなおうとすると、命令リトライ機構２０６によりプログラムが停止してしまい、命令リトライの動作検証を継続することができなくなってしまう。

ここでは、命令リトライ不能なタイミングとして２つ例を挙げる。一つ目の例は、マルチフロー命令が完了対象エントリ２１１の最も古い命令の場合である。マルチフロー命令とは、１命令を複数のフローに分けた命令で、それぞれのフロー毎にＣＳＥ２１０のエントリを必要とし、一つのサイクルで一つのフローしか完了させることができない。完了対象エントリ２１１の最も古い命令がマルチフロー命令である場合、マルチフロー命令の途中のフローである可能性があり、ここで命令リトライをおこなうと最初のフローからやり直してしまうために、同じフローを何回も完了してしまい、プログラムに異常が起きるために、命令リトライをおこなうことができない。

二つ目の例は、ＣＳＥ２１０のエントリにノンキャッシュアクセス中の命令が存在している場合である。ノンキャッシュアクセス中に命令リトライをおこない、再度同じ命令でノンキャッシュアクセスをおこなうとロードされるデータが異なる場合があるため、この場合も、命令リトライをおこなうことができない。

本実施例に係る命令リトライ検証方式においては、命令リトライの動作検証中にこのような命令リトライをおこなうことができないタイミングになった場合は、パリティチェック回路２０５がパリティエラーを検出しないようにないようにしている。パリティエラーを検出しなければ、完了判定や完了した命令の解放等が通常通りおこなわれ、プログラムが停止することはない。

このように、命令リトライをおこなうことができないタイミングの場合は、パリティエラーを検出しないようにすることにより、プログラムの停止による検証作業の中断を回避することができる。

なお、命令リトライの動作検証中以外は、命令リトライをおこなうことができないタイミングであっても、パリティチェック回路２０５にパリティエラーを検出させ、命令リトライ機構に再実行の依頼をおこない、命令リトライ機構が命令リトライをおこなうかを判断する。実際に何らかの障害が発生しパリティエラーされている場合に、障害が発生したまま処理を継続することは危険だからである。

図６は、完了対象エントリ２１１のＴＯＱエントリのパリティチェックをおこなう回路の構成を示すブロック図である。同図に示すように、この回路は当該のエントリに有効なデータが設定されていることを示すＴＯＱ＿ＣＳＥ＿ＶＡＬＩＤ信号がオンであり、かつ、エントリに登録されているデータにパリティエラーが存在している場合にパリティエラーを検出する。他の完了対象エントリ２１１のエントリにも同様な回路が存在する。

図７は、完了対象エントリ２１１のパリティチェックをおこなう回路の構成を示すブロック図である。同図に示すように、この回路は、完了対象エントリ２１１のエントリのいずれかにおいてパリティエラーが発生していた場合にパリティエラーを検出する。

図８は、パリティチェック回路２０５の構成を示すブロック図である。同図に示すように、命令リトライの動作検証中であることを示すＯＰＳＲ＿ＥＮＢ＿ＲＥＴＲＹ＿ＭＯＤＥ信号がオンである場合は、完了対象エントリ２１１の最も古い命令がマルチフロー命令であることを示すＴＯＱ＿ＣＳＥ＿ＭＵＬＴＩＦＬＯＷ信号もしくはＣＳＥ２１０のエントリにノンキャッシュアクセス中の命令が存在していることを示すＮＯＮＣＡＣＨＥ＿ＡＣＣＥＳＳ＿ＰＥＮＤ信号のいずれかがオンである場合には、パリティエラーが検出されないようになっている。

なお、命令リトライ不能なタイミングは、ここに示した例に限定されるものではなく、情報処理装置の仕様により、これ以外のタイミングが存在する場合もある。ここに示した以外に命令リトライ不能なタイミングが存在する情報処理装置であっても、上記のようにそのタイミングをパリティチェック回路２０５へ通知する仕組みを設けることにより、本実施例に係る命令リトライ検証方式を適用することができる。

命令リトライ機構２０６は、命令の再実行をおこなう機構である。情報処理装置に何らかの障害が発生した場合であっても、命令リトライ機構２０６が命令を再実行することにより、プログラムを停止させることなく処理を正常に継続することができる。

資源更新回路２０７は、完了判定回路２０４によって実行が完了したと判定された命令の各種資源とＣＳＥ２１０のエントリを解放する回路である。

ＪＴＡＧ機構２０８は、情報処理装置の挙動を検査するための機構であり、検査用の入出力インターフェースを備える。本実施例に係る命令リトライ検証方式においては、このＪＴＡＧ機構２０８をもちいて命令リトライの動作検証をおこなうモードと通常動作のモードの切り替えをおこなう。具体的には、命令リトライの動作検証をおこなう場合は、ＪＴＡＧ機構２０８から発信されるＥＲＲＯＲ＿ＩＮＪＥＣＴＩＯＮ信号およびＯＰＳＲ＿ＥＮＢ＿ＲＥＴＲＹ＿ＭＯＤＥ信号をオンにし、通常動作させる場合は、これらをオフにする。

ＣＳＥ２１０は、命令デコーダ１０４から送出された命令に係る情報をエントリに保持する装置である。ＣＳＥ２１０の各エントリは、データ誤りを検出するためのパリティビットを備える。完了エントリ２１１は、完了対象エントリ選択回路２０３によって、次サイクルで完了する可能性のある命令の情報がＣＳＥ２０１から転記される装置である。

次に、図４に示した装置の通常時と命令リトライ検証時の処理手順について説明する。図９は、図４に示した装置の通常時の処理手順を示すフローチャートである。

同図に示すように、命令デコーダ１０４が、命令のデコードをおこない、この命令に係る情報をエントリ登録回路２０１へ送出したならば（ステップＳ１０１）、パリティ生成回路２０２が送出された情報に応じたパリティデータを生成する（ステップＳ１０２）。そして、エントリ登録回路２０１は、送出された情報にパリティデータを付加してＣＳＥ２１０のエントリへ書き込む（ステップＳ１０３）。

完了対象エントリ選択回路２０３は、ＣＳＥ２１０のエントリから次サイクルで命令の実行が完了する可能性のあるエントリを選択して、完了対象エントリ２１１へ転記する（ステップＳ１０４）。サイクルが完了すると、完了判定回路２０４が完了対象エントリ２１１の各エントリの命令について実行が完了したものとしてよいか否かの完了判定をおこなう（ステップＳ１０５）。

完了対象エントリ選択回路２０３が完了判定をおこなう際に、パリティチェック回路２０５がエントリのパリティチェックをおこなう。いずれのエントリにおいてもパリティエラーが検出されなければ（ステップＳ１０６否定）、資源更新回路２０７は、実行が完了したとされた命令の各種資源の更新とＣＳＥのエントリの解放をおこなう（ステップＳ１０７）。

いずれかのエントリにおいてパリティエラーが検出された場合（ステップＳ１０６肯定）、完了判定回路２０４は、完了判定を中止し、パリティエラーが検出されたことを命令リトライ機構２０６に通知する（ステップＳ１０８）。

命令リトライ機構２０６は、完了対象の最も古い命令から再実行をおこなう。このとき、命令リトライが可能なタイミングであれば（ステップＳ１０９肯定）、命令の再実行は成功し（ステップＳ１１０）、命令リトライが不可能なタイミングであれば（ステップＳ１０９否定）、プログラムが停止する。

図１０は、図４に示した装置の命令リトライ検証時の処理手順を示すフローチャートである。

同図に示すように、命令デコーダ１０４が、命令のデコードをおこない、この命令に係る情報をエントリ登録回路２０１へ送出したならば（ステップＳ２０１）、パリティ生成回路２０２が送出された情報に応じたパリティデータを生成した後（ステップＳ２０２）、パリティエラーを意図的に検出させるためにこのパリティデータを反転させる（ステップＳ２０３）。そして、エントリ登録回路２０１は、送出された情報にパリティデータを付加してＣＳＥ２１０のエントリへ書き込む（ステップＳ２０４）。

完了対象エントリ選択回路２０３は、ＣＳＥ２１０のエントリから次サイクルで命令の実行が完了する可能性のあるエントリを選択して、完了対象エントリ２１１へ転記する（ステップＳ２０５）。サイクルが完了すると、完了判定回路２０４が完了対象エントリ２１１の各エントリの命令について実行が完了したものとしてよいか否かの完了判定をおこなう（ステップＳ２０６）。

完了対象エントリ選択回路２０３が完了判定をおこなう際に、パリティチェック回路２０５がエントリのパリティチェックをおこなう。ステップＳ２０３でパリティデータを反転させているため、ここではパリティエラーが検出されることになる（ステップＳ２０７）。

このとき、命令リトライが可能なタイミングであれば（ステップＳ２０８肯定）、パリティエラーはそのまま検出され、完了判定回路２０４は、完了判定を中止し、パリティエラーが検出されたことを命令リトライ機構２０６に通知する（ステップＳ２０９）。そして、命令リトライ機構２０６は、完了対象の最も古い命令から再実行をおこなう。

命令リトライが不可能なタイミングの場合は（ステップＳ２０８否定）、パリティエラーが検出されなかったものとされて完了判定が継続され（ステップＳ２１１）、資源更新回路２０７は、実行が完了したとされた命令の各種資源とＣＳＥのエントリの解放をおこなう（ステップＳ２１２）。

上述してきたように、本実施例では、意図的にＣＳＥ２１０のパリティエラーを発生させて命令リトライを実行させ、命令リトライが失敗し動作検証が失敗する場合にはパリティエラーが検出されないように構成したので、命令リトライを何度でも繰り返して実行させることができ、命令リトライの検証を十分におこなうことができる。

（付記１）異常発生時に命令を再実行する命令リトライ機構と、アウトオブオーダで実行される命令に係る情報を本来のインオーダの順序で保持し、命令の完了順序を制御するコミットスタックエントリとを備えた情報処理装置であって、
当該の情報処理装置の状態を通常動作のための通常状態もしくは動作検証のための検証状態に設定する状態設定手段と、
前記コミットスタックエントリへ命令に係る情報を登録する際に、当該の情報処理装置が検証状態にある場合には、前記情報の内容を改竄し、パリティエラーが検出される状態で登録するエントリ登録手段と、
前記コミットスタックエントリのエントリのうち当該のサイクルで命令が完了する可能性のあるエントリの完了判定とパリティチェックをおこない、いずれかのエントリにパリティエラーを検出した場合には前記命令リトライ機構に対して前記コミットスタックエントリに登録されている最も古い命令からの再実行を依頼する完了判定手段と
を備えたことを特徴とする情報処理装置。

（付記２）前記エントリ登録手段は、当該の情報処理装置が検証状態にある場合には、前記コミットスタックエントリへ登録するデータのパリティビットを反転させ、パリティエラーが検出される状態で登録することを特徴とする付記１に記載の情報処理装置。

（付記３）前記完了判定手段は、当該の情報処理装置が検証状態にあるときにパリティエラーを検出した場合、前記コミットスタックエントリに再実行の依頼をおこなうと前期命令リトライ機構によりプログラムが停止する命令が含まれていることを検出したならば、前記命令リトライ機構に対して命令の再実行の依頼をおこなわずに、パリティエラーがなかったものとして完了判定処理を継続することを特徴とする付記１または２に記載の情報処理装置。

（付記４）前記完了判定手段は、当該の情報処理装置が通常状態にあるときにパリティエラーを検出した場合、前記コミットスタックエントリに再実行の依頼をおこなうと前期命令リトライ機構によりプログラムが停止する命令が含まれていることを検出したならば、前記命令リトライ機構に対して命令の再実行の依頼をおこない、前記命令リトライ機構が命令リトライをおこなうか否かを判定することを特徴とする付記３に記載の情報処理装置。

（付記５）命令の実行中に異常が発覚した場合に実行中の命令を再実行する命令リトライ機構と、アウトオブオーダで実行される命令を本来のインオーダの順序で保持し、命令の完了順序を制御するコミットスタックエントリとを備えた情報処理装置における命令リトライ検証方法であって、
前記コミットスタックエントリへ命令に係る情報を登録する際に、当該の情報処理装置が検証状態にある場合には、前記情報の内容を改竄し、パリティエラーが検出される状態で登録するエントリ登録工程と、
当該の情報処理装置が検証状態にある場合には、前記コミットスタックエントリへパリティエラーとなるデータを登録するエントリ登録工程と、
前記コミットスタックエントリのエントリのうち当該のサイクルで命令が完了する可能性のあるエントリの完了判定とパリティチェックをおこない、いずれかのエントリにパリティエラーを検出した場合には前記命令リトライ機構に対して前記コミットスタックエントリに登録されている最も古い命令からの再実行を依頼する完了判定工程と
を含んだことを特徴とする命令リトライ検証方法。

（付記６）前記エントリ登録工程は、当該の情報処理装置が検証状態にある場合には、前記コミットスタックエントリへ登録するデータのパリティビットを反転させ、パリティエラーが検出される状態で登録することを特徴とする付記５に記載の命令リトライ検証方法。

（付記７）前記完了判定工程は、当該の情報処理装置が検証状態にあるときにパリティエラーを検出した場合、前記コミットスタックエントリに再実行の依頼をおこなうと前期命令リトライ機構によりプログラムが停止する命令が含まれていることを検出したならば、前記命令リトライ機構に対して命令の再実行の依頼をおこなわずに、パリティエラーがなかったものとして完了判定処理を継続することを特徴とする付記５または６に記載の命令リトライ検証方法。

（付記８）前記完了判定工程は、当該の情報処理装置が通常状態にあるときにパリティエラーを検出した場合、前記コミットスタックエントリに再実行の依頼をおこなうと前記命令リトライ機構によりプログラムが停止する命令が含まれていることを検出したならば、前記命令リトライ機構に対して命令の再実行の依頼をおこない、前記命令リトライ機構が命令リトライをおこなうか否かを判定することを特徴とする付記７に記載の命令リトライ検証方法。

以上のように、本発明にかかる情報処理装置および命令リトライ検証方法は、命令リトライ機能の検証に有用であり、特に、命令リトライを何度でも繰り返して実行させて動作検証をおこないたい場合に適している。

本実施例に係る情報処理装置全体の概要を示すブロック図である。 ＣＳＥの構成を説明するための説明図である。 ＣＳＥをもちいた完了判定動作を説明するための説明図である。 本実施例に係る命令リトライ検証方式に関連する装置の構成を示すブロック図である。 パリティ生成回路の構成を示すブロック図である。 完了対象エントリのＴＯＱエントリのパリティチェックをおこなう回路の構成を示すブロック図である。 完了対象エントリのパリティチェックをおこなう回路の構成を示すブロック図である。 パリティチェック回路の構成を示すブロック図である。 図４に示した装置の通常時の処理手順を示すフローチャートである。 図４に示した装置の命令リトライ検証時の処理手順を示すフローチャートである。

符号の説明

１００ 命令フェッチアドレス生成器
１０１ ブランチヒストリ
１０２ １次命令フェッチキャッシュ
１０３ 命令バッファ
１０４ 命令デコーダ
１０５ アドレス生成リザベーションステーション（ＲＳＡ）
１０６ 整数演算リザベーションステーション（ＲＳＥ）
１０７ 浮動小数演算リザベーションステーション（ＲＳＦ）
１０８ 分岐リザベーションステーション（ＲＳＢＲ）
２０１ エントリ登録回路
２０２ パリティ生成回路
２０３ 完了対象エントリ選択回路
２０４ 完了判定回路
２０５ パリティチェック回路
２０６ 命令リトライ機構
２０７ 資源更新回路
２０８ ＪＴＡＧ機構
２１０ コミットスタックエントリ（ＣＳＥ）
２１１ 完了対象エントリ

Claims (5)

1. 異常発生時に命令を再実行する命令リトライ機構と、アウトオブオーダで実行される命令に係る情報を本来のインオーダの順序で保持し、命令の完了順序を制御するコミットスタックエントリとを備えた情報処理装置であって、
   当該の情報処理装置の状態を通常動作のための通常状態もしくは動作検証のための検証状態に設定する状態設定手段と、
   前記コミットスタックエントリへ命令に係る情報を登録する際に、当該の情報処理装置が検証状態にある場合には、前記情報の内容を改竄し、パリティエラーが検出される状態で登録するエントリ登録手段と、
   前記コミットスタックエントリのエントリのうち当該のサイクルで命令が完了する可能性のあるエントリの完了判定とパリティチェックをおこない、いずれかのエントリにパリティエラーを検出した場合には前記命令リトライ機構に対して前記コミットスタックエントリに登録されている最も古い命令からの再実行を依頼する完了判定手段と
   を備えたことを特徴とする情報処理装置。
2. 前記エントリ登録手段は、当該の情報処理装置が検証状態にある場合には、前記コミットスタックエントリへ登録するデータのパリティビットを反転させ、パリティエラーが検出される状態で登録することを特徴とする請求項１に記載の情報処理装置。
3. 前記完了判定手段は、当該の情報処理装置が検証状態にあるときにパリティエラーを検出した場合、前記コミットスタックエントリに再実行の依頼をおこなうと前期命令リトライ機構によりプログラムが停止する命令が含まれていることを検出したならば、前記命令リトライ機構に対して命令の再実行の依頼をおこなわずに、パリティエラーがなかったものとして完了判定処理を継続することを特徴とする請求項１または２に記載の情報処理装置。
4. 前記完了判定手段は、当該の情報処理装置が通常状態にあるときにパリティエラーを検出した場合、前記コミットスタックエントリに再実行の依頼をおこなうと前期命令リトライ機構によりプログラムが停止する命令が含まれていることを検出したならば、前記命令リトライ機構に対して命令の再実行の依頼をおこない、前記命令リトライ機構が命令リトライをおこなうか否かを判定することを特徴とする請求項３に記載の情報処理装置。
5. 命令の実行中に異常が発覚した場合に実行中の命令を再実行する命令リトライ機構と、アウトオブオーダで実行される命令を本来のインオーダの順序で保持し、命令の完了順序を制御するコミットスタックエントリとを備えた情報処理装置における命令リトライ検証方法であって、
   前記コミットスタックエントリへ命令に係る情報を登録する際に、当該の情報処理装置が検証状態にある場合には、前記情報の内容を改竄し、パリティエラーが検出される状態で登録するエントリ登録工程と、
   当該の情報処理装置が検証状態にある場合には、前記コミットスタックエントリへパリティエラーとなるデータを登録するエントリ登録工程と、
   前記コミットスタックエントリのエントリのうち当該のサイクルで命令が完了する可能性のあるエントリの完了判定とパリティチェックをおこない、いずれかのエントリにパリティエラーを検出した場合には前記命令リトライ機構に対して前記コミットスタックエントリに登録されている最も古い命令からの再実行を依頼する完了判定工程と
   を含んだことを特徴とする命令リトライ検証方法。

Images