(57)【特許請求の範囲】
【請求項１】
ＩＥＥＥ１３９４高速シリアルバス対応の機器に内蔵されているコンフィギュレーションＲＯＭを検査する方法であって、
前記コンフィギュレーションＲＯＭ内の全ての情報を、前記コンフィギュレーションＲＯＭに書かれているディレクトリー、リーフの長さ及びオフセット値等の情報をもとに前記バスを介して読み出すことを特徴をするコンフィギュレーションＲＯＭの検査方法。
【請求項２】
前記コンフィギュレーションＲＯＭ内の情報を全て読み出した後、ＣＲＣ計算を実行することにより、コンフィギュレーションＲＯＭ内の情報が正しいかどうかを判断する請求項１に記載のコンフィギュレーションＲＯＭの検査方法。
【請求項３】
読み出したコンフィギュレーションＲＯＭ内の全情報を、オフセット値及び各情報の意味と共に表示し、かつ読み出した情報が正しいかどうかを表示する請求項２に記載のコンフィギュレーションＲＯＭの検査方法。
【請求項４】
前記の表示した全情報をファイルにセーブする請求項３に記載のコンフィギュレーションＲＯＭの検査方法。
【請求項５】
ＩＥＥＥ１３９４高速シリアルバス対応の機器に内蔵されているコンフィギュレーションＲＯＭを検査する装置であって、
前記コンフィギュレーションＲＯＭ内の全ての情報を、前記コンフィギュレーションＲＯＭに書かれているディレクトリー、リーフの長さ及びオフセット値等の情報をもとに前記バスを介して読み出すことを特徴をするコンフィギュレーションＲＯＭの検査装置。
【請求項６】
前記コンフィギュレーションＲＯＭから読み出した情報のＣＲＣ計算を実行する手段を有する請求項５に記載のコンフィギュレーションＲＯＭの検査装置。
【請求項７】
読み出したコンフィギュレーションＲＯＭ内の全情報を、オフセット値及び各情報の意味と共に表示し、かつ読み出した情報が正しいかどうかを表示する手段を有する請求項６に記載のコンフィギュレーションＲＯＭの検査装置。
【請求項８】
前記の表示した全情報をファイルとして記憶する手段を有する請求項７に記載のコンフィギュレーションＲＯＭの検査装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＩＥＥＥ１３９４高速シリアルバス対応の機器を開発する際に、ＩＥＥＥ１３９４で規定しているプロトコルを満たしているかどうかを検査するための方法及び装置に関する。
【０００２】
【従来の技術】
ＩＥＥＥ１３９４高速シリアルバス（以下１３９４シリアルバスという）を用いてデジタルビデオ信号及びデジタルオーディオ信号の送受信を行う機能を備えたデジタルビデオカメラが既に商品化されている。また、パーソナルコンピュータ（以下ＰＣという）に周辺装置を接続するインターフェースとして１３９４シリアルバスが注目されている。
【０００３】
１３９４シリアルバス対応の機器内では６４ビットのアドレスを使用することができる。そのうち上位１６ビットはノードＩＤを示し、図１１に示すようにノードＩＤに続く４８ビットのアドレスの“ＦＦＦＦ  Ｆ０００  ００００ｈ”から“ＦＦＦＦ  ＦＦＦＦ  ＦＦＦＦｈ”までのエリアはレジスタ空間と呼ばれており、１３９４シリアルバスに接続された機器間で共通な情報が書き込まれる。レジスタ空間の“ＦＦＦＦ  Ｆ０００  ０４００ｈ”からコンフィギュレーションＲＯＭが設けられる。
【０００４】
図１２にコンフィギュレーションＲＯＭの構成例を示す。１３９４シリアルバス対応の機器を開発する際には、コンフィギュレーションＲＯＭに正しいデータが書き込まれているかどうかを検査することが必要である。
【０００５】
従来は、この検査を以下の手順で実行していた。コンフィギュレーションＲＯＭの先頭のオフセット値“ＦＦＦＦ  Ｆ０００  ０４００ｈ”は決まった値である。また、オフセット値以降に書かれているバス情報ブロック（Ｂｕｓ＿Ｉｎｆｏ＿Ｂｌｏｃｋ）やルートディレクトリーの長さ（ｒｏｏｔ＿ｄｉｒｅｃｔｏｒｙ＿ｌｅｎｇｔｈ）等が例えば図１２に示したように分かっていれば、そこに書かれている長さ分のデータを読み出せば、コンフィギュレーションＲＯＭ全体の情報を読み出すことができる。
【０００６】
【発明が解決しようとする課題】
しかしながら、従来の方法では、コンフィギュレーションＲＯＭ全体の情報は簡単に読み出せるが、その情報を人間が見て、ＲＯＭの構造やＣＲＣデータが正しいかどうかを判断する必要があった。また、コンフィギュレーションＲＯＭに書かれている各種データの長さを判断する必要があった。このため、コンフィギュレーションＲＯＭをバージョンアップして内部のデータ構造が変わった場合やデータ構造の分からないコンフィギュレーションＲＯＭに対しては正しいかどうかを判断することができなかった。
【０００７】
また、長さが合っていても、各ディレクトリー（ｄｉｒｅｃｔｏｒｙ）やリーフ（ｌｅａｆ）のオフセットが図１２のように連続して取られておらず、飛び飛びになっている場合には、全体の情報を正しく読み出すことができなかった。
【０００８】
本発明はこのような問題点に鑑みてなされたものであって、コンフィギュレーションＲＯＭに書かれているデータを自動的に読み出すと共に、読み出したデータのチェックやそのチェック結果の表示を自動的に行えるようにしたコンフィギュレーションＲＯＭの検査方法及び装置を提供することを目的とする。
【０００９】
【課題を解決するための手段】
本発明では、コンフィギュレーションＲＯＭ内のディレクトリーやリーフのオフセット値やそこに書かれている長さ情報等をもとに、全体の情報を読み出す。また、読み出した情報をもとにＣＲＣ計算を行い、その読み出したデータの信頼性を検査する。また、さらに視覚的にもコンフィギュレーションＲＯＭの構造が理解しやすいように、データの意味を示すテキスト情報と共に全体を表示し、コンフィギュレーションＲＯＭ情報にエラーがあった場合には、エラー情報も表示する。
【００１０】
【発明の実施の形態】
以下本発明の実施の形態について図面を参照しながら詳細に説明する。
【００１１】
図１に本発明を適用したシステムの構成を示す。このシステムはＰＣシステム１のＰＣ本体２とカメラ一体型ビデオテープレコーダ（以下ＣＡＭという）５との間を１３９４シリアルバス６で接続したものである。そして、ＰＣＩバス対応のＩＥＥＥ１３９４インターフェースボード（以下１３９４  Ｉ／Ｆボードと略す）４をＰＣ本体２のＰＣＩスロットに挿入し、ＰＣ本体２上で本発明のアプリケーションを作成し、アシンクロナスパケットを送受信することによって、所望の機器（ここではＣＡＭ）のＩＥＥＥ１３９４プロトコルを検査することを実現した例である。なお、この場合のＣＡＭ５が備えているコンフィギュレーションＲＯＭに書かれているデータの構成は図１２に示した通りとする。
【００１２】
図２は図１のＰＣ本体２の内部の構成の概略を示すものである。ここで、図１と同一の部分には図１に付した番号と同一の番号が付してある。
【００１３】
ＰＣ本体２の内部に設けられた１３９４  Ｉ／Ｆボード４には、物理層コントロールブロック（ＰＨＹ）１１と、リンク層コントロールブロック（ＬＩＮＫ）１２とが設けられている。
【００１４】
物理層コントロールブロック１１は１３９４シリアルバスの初期化やバスの使用権の調停等を行う。また、リンク層コントロールブロック１２との間で、各種制御信号の通信を行うとともに、これらの信号を１３９４シリアルバス６に対して送受信する。
【００１５】
リンク層コントロールブロック１２は、パケットの作成／検出、誤り訂正処理等を行う。コンフィギュレーションＲＯＭはリンク層コントロールブロック１２の内部に設けられている。
【００１６】
ＰＣシステム１のＰＣ本体２の内部には、さらにＣＰＵ１４と、ＲＡＭ１５と、モニターインターフェース１６と、ファイルメモリ１７と、アプリケーションメモリ１８とが設けられている。
【００１７】
ＣＰＵ１４はＰＣ本体２の全体の制御等を行う。ＲＡＭ１５はＣＰＵ１４が各種データの処理を行う際のワークエリアとなる。モニターインターフェース１６はモニター３との間の制御信号の通信やモニター３に対するビデオ信号の送信を行う。ファイルメモリ１７は各種ファイルを格納する。アプリケーションメモリ１８は各種アプリケーションを格納する。ファイルメモリ１７及びアプリケーションメモリ１８は、実際にはハードディスク装置の記憶エリアの一部として構成される。
【００１８】
ＲＡＭ１５上のアプリケーションプログラムは物理層コントロールブロック１１とリンク層コントロールブロック１２の制御、コマンドやレスポンスの作成等の処理を行う。このアプリケーションプログラムはコマンドやレスポンスを作成するときにはリンク層コントロールブロック１２内に設けられたレジスタの所定のアドレスにデータを書き込む。また、他の機器が送信したコマンドやレスポンスは、前記レジスタの所定のアドレスに書き込まれた後、このアプリケーションプログラムにより読み出される。
【００１９】
なお、実際にはＰＣ本体２内には、さらにキーボードインターフェースやＲＯＭ等が設けられているが、ここでは省略した。
【００２０】
図３は図２に示したＰＣ本体２がコンフィギュレーションＲＯＭを検査する際の処理を示すフローチャートである。まず、ＰＣ本体２内のアプリケーションメモリ１７上のコンフィギュレーションＲＯＭ検査用アプリケーションを立ち上げ、検査を開始する。
【００２１】
ＰＣ本体２内の１３９４インターフェースボード４は、１３９４バス６を介してＣＡＭ５内のコンフィギュレーションＲＯＭの先頭の１クワドレット（ｑｕａｄｌｅｔ）分のデータを読み出し、ＣＲＣの長さ（ＣＲＣ＿Ｌｅｎｇｔｈ）とＲＯＭ ＣＲＣ値（ｒｏｍ＿ｃｒｃ＿ｖａｌｕｅ）をＲＡＭ１５に保存する（ステップＳ１）。このＣＲＣの長さには、先頭の１クワドレットを除く、コンフィギュレーションＲＯＭ全体の長さが書かれている。
【００２２】
コンフィギュレーションＲＯＭの先頭の１クワドレットのデータから、バス情報ブロックの長さ（Ｂｕｓ＿Ｉｎｆｏ＿Ｂｌｏｃｋ＿ｌｅｎｇｔｈ）が０４ｈであると分かるので、さらに４クワドレット分のデータを読み出し、保存する（ステップＳ２）。
【００２３】
次に、ルートディレクトリー（ｒｏｏｔ＿ｄｉｒｅｃｔｏｒｙ）の先頭１クワドレット分のデータを読み出し、ルートディレクトリーのＣＲＣ値を保存する（ステップＳ３）。
【００２４】
ルートディレクトリーの先頭１クワドレット分のデータから、ルートディレクトリーの長さ（ｒｏｏｔ＿ｄｉｒｅｃｔｏｒｙ＿ｌｅｎｇｔｈ）が０４ｈであると分かるため、さらに４クワドレット分のデータを読み出し、保存する（ステップＳ４）。
【００２５】
ルートディレクトリー等のディレクトリー（ｄｉｒｅｃｔｏｒｙ）には、さらに他のディレクトリーやリーフへのオフセット値が書かれている可能性があるため、保存しておいたルートディレクトリーのキーデータをもとに、オフセットを指し示すデータがないか検索する（ステップＳ５）。
【００２６】
キーデータの構造例を図４に、キータイプ（ｋｅｙ＿ｔｙｐｅ）のコードを図５に、キータイプ及びキーの値（ｋｅｙ＿ｖａｌｕｅ）のコードを図６に示す。例えばルートディレクトリーの３クワドレット目のキーデータである“８Ｄｈ”は、“１０００１１０１”である。したがって、先頭の２ビットの“１０”（＝１）がキータイプのオフセットを示す。そして、残りの６ビットの“００１１０１”（＝０Ｄ）に対応するエントリーネームはノードユニークＩＤであり、キータイプがリーフである。つまり、これはノードユニークＩＤリーフ（Ｎｏｄｅ＿Ｕｎｉｑｕｅ＿Ｉｄ  ｌｅａｆ）へのオフセットであることを意味する。同様に、３クワドレット目のキーデータである“Ｄ１ｈ”は、ユニットディレクトリー（Ｕｎｉｔ＿Ｄｉｒｅｃｔｏｒｙ）へのオフセットであることを意味する。
【００２７】
ステップＳ５での検索の結果、オフセットを指示するデータがあった場合には、そのオフセット値が示すアドレスからデータを読み出し、保存する（ステップＳ６）。ここでは、ノードユニークＩＤリーフとユニットディレクトリーを読み出す。この時、ノードユニークＩＤリーフとユニットディレクトリーのオフセット値を比較して小さいほうのオフセットから読み出す。
【００２８】
図１２では、ノードユニークＩＤリーフのオフセット値が“０５ｈ”であり、ユニットディレクトリーのオフセット値が“０１ｈ”であるから、ユニットディレクトリーのオフセット値のほうが小さい。したがって、まずユニットディレクトリーのオフセット値が指し示すアドレスを１クワドレット分だけ読み出すと、ユニットディレクトリーの長さ（Ｕｎｉｔ＿Ｄｉｒｅｃｔｏｒｙ＿ｌｅｎｇｔｈ）は“０２ｈ”であることが分かる。したがって、さらに２クワドレット分のデータを読み出し、保存する（ステップＳ６）。このとき、ユニットディレクトリーのＣＲＣ値も保存しておく。
【００２９】
ユニットディレクトリーもディレクトリーであるため、ステップＳ５と同様にしてキーデータをもとに、他のリーフやディレクトリーへのオフセットが書かれていないかチェックする（ステップＳ７）。
【００３０】
もし、他のリーフやディレクトリーへのオフセットが含まれていたら、再びまだ読み出していないノードユニークＩＤリーフのオフセットと新たに検索して発見したオフセットを合わせ、オフセットの昇順に並べ換える。
【００３１】
図１２の場合には、オフセット情報は含まれていなかったため、次にノードユニークＩＤリーフを１クワドレット分だけ読み出し、保存する。読み出しによりノードユニークＩＤリーフの長さ（Ｎｏｄｅ＿Ｕｎｉｑｕｅ＿Ｉｄ＿ｌｅａｆ＿ｌｅｎｇｔｈ）は“０２ｈ”であることが分かる。したがって、さらに２クワドレット分読み出し、読み出したデータを保存する。このとき、ノードユニークＩＤリーフのＣＲＣ値も保存しておく。
【００３２】
さらに読み出すべきディレクトリーやリーフのオフセットはこれ以上存在しないため、これでコンフィギュレーションＲＯＭの情報を全て読み出すことができた。
【００３３】
それを確認するために、読み出した全データと保存しておいたＣＲＣの長さに１加えた値とを比較する。そして、その値が等しければ良い。もし、この値が等しくなければ、各々のリーフやディレクトリーの長さや情報が間違っているか、あるいはリーフやディレクトリーへのオフセット値が間違っている可能性がる。読み出した長さの正誤情報もチェック結果として、モニターインターフェース１５を介してモニター３に表示する（ステップＳ８）。
【００３４】
そして、読み出したコンフィギュレーションＲＯＭの値をＩＳＯ／ＩＥＣ１３２１３で定義されているＣＲＣ−１６計算式に通して、データの正当性をチェックする。まず、各々のディレクトリー及びリーフ単位でＣＲＣ計算を行い、保持しておいた各々のＣＲＣ値と等しいかどうかチェックする。全ディレクトリー及びリーフについてのチェックが終わったら、コンフィギュレーションＲＯＭ全体のＣＲＣを計算し、ＲＯＭ＿ＣＲＣ値と等しいかどうかチェックする。ＣＲＣ値の正誤情報もチェック結果として表示する。最後に、読み出したデータにデータの意味を示すテキスト情報も付加して、コンフィギュレーションＲＯＭを表にしてモニター３に表示する。その下に読みだしたＲＯＭ情報のチェック結果も表示する（ステップＳ８）。
【００３５】
読み出したデータが正しかった場合のチェック結果の表示例を図７に示す。この表示例では、画面上部に日時等が、中央部にはコンフィギュレーションＲＯＭ内部のアドレス及びデータ構造等が、下部にはチェック結果が表示されている。そして、チェック結果は、ＣＲＣ長のチェック結果、バス情報ブロックのＲＯＭ＿ＣＲＣ値のチェック結果、ルートディレクトリーのＣＲＣ値のチェック結果、ユニットディレクトリーのＣＲＣ値のチェック結果、及びノードユニークＩＤリーフのＣＲＣ値のチェック結果が全てＯＫであることが表示されている。
【００３６】
一方、誤りがあった場合の表示例を図８に示す。ここでは、ＣＲＣ長のチェック結果とノードユニークＩＤリーフのＣＲＣ値のチェック結果はＯＫであるが、バス情報ブロックのＲＯＭ＿ＣＲＣ値のチェック結果及びルートディレクトリーのＣＲＣ値のチェック結果にエラーがあることが表示されている。そして、エラーについてはＣＲＣ値について具体的に表示している。
【００３７】
また、ディレクトリーの階層構造がより深い場合のチェック結果例を正しかった場合について図９及び図１０に示す。ここで、図９はモニター３に表示されている画面の上部を示し、図１０は下部を示す。
【００３８】
図７〜図１０に示したように、チェックした日時やチェック内容のタイトルなども表示しておけば、後でそのファイルを参照したときに、バージョン管理やデバッグ等に非常に有効である。
【００３９】
以上の検査結果はテキストファイルとしてファイルメモリ１６に保存することができる（ステップＳ９）。
【００４０】
なお、本実施の形態では、ＣＲＣの計算を最後に実行したが、各リーフ／ディレクトリー単位あるいはデータを読み出しながらクワドレット単位で計算してもよい。
【００４１】
このように、本実施の形態では、コンフィギュレーションＲＯＭの各ディレクトリーやリーフ間が連続で確保されていなくても、全情報を正確に読み出し、表示することができる。また、キータイプやキーの値をもとに、各ディレクトリー内の情報をテキストでも表示することによって、どのような情報が書かれているのかが理解しやすい。
【００４２】
さらに、全データ及び各ディレクトリー／リーフのＣＲＣチェックを行い、データの信頼性を検査し、結果を表示することによって、エラーの検出も行える。
また、検査結果をファイルにセーブすることによって、その場限りの検査ではなく、履歴を残すことができる上に、バグが出た場合にも後でそのデータをもとに原因を追及することが容易にできる。
【００４３】
さらに、簡単操作かつ短時間でＩＥＥＥ１３９４プロトコルを自動的にチェックできる。
【００４４】
また、ＩＥＥＥ１３９４コンフォーマンステスター（ＣｏｎｆｏｒｍａｎｃｅＴｅｓｔｅｒ）を操作するユーザーは、プロトコルを知らなくても検査できる。検査結果はテキストファイルとして保存できるため、履歴を残したりデバッグなどに非常に有効に使える。検査用データの文法エラーもチェックできるため、プロトコルを正しく検査でき、かつ、ソースは書き換えなくても、データを書き換えるだけで任意のパケットの送受を行えるため、プロトコル及びセット仕様の変更等にも柔軟に対応できる。
【００４５】
【発明の効果】
以上詳細に説明したように、本発明によれば、コンフィギュレーションＲＯＭの各ディレクトリー／リーフ構造がコンフィギュレーションＲＯＭ上に連続的に取られていなくても、正しく全情報を読み出すことができる。また、読み出した結果を、視覚的に理解しやすく表示し、データのチェックまで行ってくれるため、検査装置のユーザーはプロトコルを知らなくても、その仕様を満たしているかどうかをチェックすることができる。
【００４６】
さらに、その結果をファイルにセーブできるため、デバッグやバージョンの管理などに非常に有効である。
【図面の簡単な説明】
【図１】本発明を適用したシステムの構成を示す図である。
【図２】図１のＰＣ本体の内部の構成の概略を示す図である。
【図３】図２に示したＰＣ本体がコンフィギュレーションＲＯＭを検査する際の処理を示すフローチャートである。
【図４】キーデータの構造例を示す図である。
【図５】キータイプのコードを示す図である。
【図６】キータイプ及びキーの値のコードを示す図である。
【図７】読み出したデータが正しかった場合のチェック結果の表示例を示す図である。
【図８】読み出したデータに誤りがあった場合の表示例を示す図である。
【図９】ディレクトリーの階層構造がより深い場合のチェック結果の表示例の画面上部を示す図である。
【図１０】ディレクトリーの階層構造がより深い場合のチェック結果の表示例の画面下部を示す図である。
【図１１】レジスタ空間のアドレスを示す図である。
【図１２】コンフィギュレーションＲＯＭの構成例を示す図である。
【符号の説明】
１…ＰＣシステム、２…ＰＣ本体、３…モニター、４…１３９４インターフェースボード、６…１３９４シリアルバス、１４…ＣＰＵ、１７…ファイルメモリ、１８…アプリケーションメモリ。
【図１】
0003763182.tif 000002
【図２】
0003763182.tif 000003
【図３】
0003763182.tif 000004
【図４】
0003763182.tif 000005
【図５】
0003763182.tif 000006
【図６】
0003763182.tif 000007
【図７】
0003763182.tif 000008
【図８】
0003763182.tif 000009
【図９】
0003763182.tif 000010
【図１０】
0003763182.tif 000011
【図１１】
0003763182.tif 000012
【図１２】
0003763182.tif 000013