JP6070220B2 - 電子機器用のデバイス - Google Patents

Description

本発明は、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）が実装された電子機器用のデバイスに関する。

多機能周辺装置ＭＦＰ（Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）やプリンタ等の画像形成装置を一例とする電子機器には、画像処理をハードウエアで行うための特定用途向け半導体集積回路（ＡＳＩＣ）が実装されている。

電子機器を製品化する前に行われる試験では、ＡＳＩＣの制御（レジスタ設定）の間違いに起因する障害（例えば異常画像）が発生する場合がある。その障害の原因を特定するための情報としては、ＡＳＩＣのレジスタアクセスや、ＤＭＡＣ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌｌｅｒ）の動作状態、割り込み等の内部モジュール動作のトレース記録が必要になる。レジスタアクセスを記録する方法としては、インサーキット・エミュレータ（Ｉｎ Ｃｉｒｃｕｉｔ Ｅｍｕｌａｔｏｒ（ＩＣＥ）を用いる方法が既に知られている。

ＩＣＥを用いた方法では、ＣＰＵからＡＳＩＣのレジスタへのアクセスを記録することは可能である。一方、ＩＣＥを用いた方法では、ＡＳＩＣの内部モジュールの動作（例えばＤＭＡＣの起動）との詳細なタイミング関係がわからず、その結果、障害の原因特定までに時間がかかってしまうという問題があった。

それに対して、レジスタアクセスやＤＭＡＣの動作状態等の情報をＡＳＩＣ内部に備えたバッファメモリにログデータとして蓄積する方法が考えられる。また、ＤＭＡのアクセスログをＡＳＩＣ内ではなくＤＭＡによりメモリ上に蓄積する方法も提案されている（特許文献１参照）。特許文献１では、外付けのデバッグ装置を設けることなく、効率的に低コストでデバッグ作業を行なうことを目的として、デバッグ用のアクセスアドレス情報をメモリ上に書き込むことでＤＭＡＣ動作の履歴情報を記録する技術が開示されている。

ＣＰＵからのレジスタアクセスや、内部信号の挙動をモニターしてログを作成し、作成したログの内蔵メモリへの保存、外部への出力が可能なハードウェアをデバイス内部に備えることで、デバッグの容易化を図る方法も提案されている（特許文献２参照）。

しかし、レジスタアクセスやＤＭＡＣの動作状態等の情報をＡＳＩＣ内部に備えたバッファメモリにログデータとして蓄積する方法を採用すると、ＡＳＩＣに実装されているレジスタ数や、各レジスタ数のアクセス回数に応じてログデータの情報量が増大する。このため、その分だけバッファメモリサイズが必要になり回路規模が増大しコストが高くなるという問題がある。

また、特許文献１では、ＤＭＡのアクセスログをＡＳＩＣ内ではなくＤＭＡによりメモリ上に蓄積する。このため、本来のデータ転送帯域に影響を与え、結果として異常画像を発生させる可能性があるという問題がある。

また、特許文献２に示されるように、レジスタアクセスや内部信号をモニターしログを作成する方法では、ログとして取得した全てのアクセスに対してアドレス（３２ｂｉｔ）、データ（３２ｂｉｔ）の情報をそのままログとして保存するため、解析時間が長い場合や取得するアクセスの種類数が多い場合にはログのデータ量が膨大になり、保存に必要な内蔵メモリの容量が大きくコストが高くつくという問題がある。

上記課題に鑑み、本発明の目的とするところは、回路規模拡大を抑止しながら、デバッグのためのログデータを記録することが可能な電子機器用のデバイスを提供することにある。

上記課題を解決するために、本発明のある観点によれば、
データを入出力する入出力装置と、
前記データを記憶するメモリと、
前記メモリへの前記データの転送を制御するエンジン制御部と、
前記入出力装置と前記メモリとの間で前記データの転送を行うコントローラと、を備え、
前記エンジン制御部は、
前記データを一時的に蓄積するバッファと、
デバッグ用のログデータを生成し、前記エンジン制御部内の前記バッファの空き状況及び前記コントローラのデータ転送状況に応じて、前記生成されたログデータを前記バッファへ蓄積するか又は前記コントローラへ転送するデバッグ制御部と、
を有することを特徴とする電子機器用のデバイスが提供される。

本発明によれば、回路規模拡大を抑止しながら、デバッグのためのログデータを記録することができる。

第１及び第２実施形態に係る画像形成装置用のデバイスの全体構成図。 一般的なエンジンＡＳＩＣの内部構成図。 第１実施形態に係るコントローラＡＳＩＣの内部構成図。 第１実施形態に係るエンジンＡＳＩＣの内部構成図。 第１実施形態に係るデバッグ制御部（エンジンＡＳＩＣ側）の内部構成図。 第１実施形態に係るバッファ制御部（エンジンＡＳＩＣ側）の内部構成図。 第１実施形態に係る状態信号と使用バッファとの関係を示した図。 第１実施形態に係る状態信号と使用バッファとの関係を示した図。 第１実施形態に係るデバイスの各部の状態を示したシーケンス図。 ログデータの一例を示した図。 第２実施形態に係るデバッグ制御部（エンジンＡＳＩＣ側）の内部構成図。 第２実施形態に係るバッファ制御部（エンジンＡＳＩＣ側）の内部構成図。 第２実施形態に係る状態信号と使用バッファとの関係を示した図。 第２実施形態に係る状態信号と使用バッファとの関係を示した図。 第２実施形態に係るコントローラＡＳＩＣの内部構成図。 第２実施形態に係るデバッグ制御部（コントローラＡＳＩＣ側）の内部構成図。 第２実施形態に係るバッファ制御部（コントローラＡＳＩＣ側）の内部構成図。 第２実施形態に係る状態信号と使用バッファとの関係を示した図。 第２実施形態に係る状態信号と使用バッファとの関係を示した図。 第２実施形態に係るデバイスの各部の状態を示したシーケンス図。 第３実施形態に係る電子機器用のデバイスの全体構成を示した図。 第３実施形態に係るデバッグ制御部の内部構成を示した図。 第３実施形態に係る制御レジスタを示した図。 第３実施形態に係るアクセスログのフォーマットを示した図。 第３実施形態に係るデバッグ制御部の動作を示したシーケンス図。 第３実施形態に係るイベントモードにてレジスタアクセスを検知する場合のタイミングチャート図。 第３実施形態に係るイベントモードにて内部信号を検知する場合のタイミングチャート図。

以下、本発明の好適な実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。

本発明の一実施形態に係る電子機器用のデバイスは、ＡＳＩＣ内部に元々備わっている画像データ用のバッファの空き領域を利用してログデータ（履歴情報）を一時的に蓄積し、かつ、画像データを転送する際の空き時間を利用してログデータをメモリに転送する。これにより、ＡＳＩＣの制御（例えばレジスタ設定）の間違いに起因する障害（例えば異常画像）を特定するために、デバッグに使用するログデータを残すことができる。なお、本実施形態に係る画像形成装置は、電子機器の一例であり、電子機器は、これに限られず、電子機器用の処理をハードウエアで行うためのＡＳＩＣを内蔵した装置であれば、どんな機器であってもよい。また、電子機器の内部又は外部に設けられたメモリに記憶されるデータは画像データに限られず、テキストデータ等、どのようなデータであってもよい。

以下、電子機器として画像形成装置を例に挙げて以下の実施形態について説明する。

＜第１実施形態＞
［全体構成］
ます、本発明の第１実施形態に係る画像形成装置用のデバイスについて、図１を参照しながら説明する。図１は、本実施形態に係る画像形成装置用のデバイスの全体構成を示す。本実施形態に係る画像形成装置用のデバイスは、エンジン制御部１及びコントローラ２を有する。エンジン制御部１は、スキャナ３、プロッタ１１、エンジンＡＳＩＣ４及びエンジンＣＰＵ８を有する。スキャナ３及びプロッタ１１は、画像データを入出力する入出力装置の一例である。図１では、スキャナ３及びプロッタ１１は、エンジン制御部１の内部に設けられているが、これに限らず、エンジン制御部１の外部に設けられてもよい。

エンジンＡＳＩＣ４は、スキャナ３及びプロッタ１１とコントローラ２とのデータ転送制御および画像処理を行う特定用途向け半導体集積回路である。エンジンＣＰＵ８は、エンジン制御部１の動作を制御する。これにより、エンジン制御部１は、スキャナ３及びプロッタ１１（入出力装置）とコントローラ２とのメモリ７への画像データの転送を制御する。

コントローラ２は、コントローラＡＳＩＣ５、チップセット６、メモリ７、ハードディスクドライブ（ＨＤＤ）９及びコントローラＣＰＵ１０を有する。コントローラＡＳＩＣ５は、エンジン制御部１とメモリ７とのデータ転送および画像処理を行う特定用途向け半導体集積回路である。コントローラＣＰＵ１０は、コントローラ２の動作を制御する。これにより、コントローラ２は、スキャナ３及びプロッタ１１とメモリ７との画像データの転送を行う。

メモリ７は、画像データを記憶したり、ログデータを格納したりするための記憶領域である。ハードディスクドライブ９は、画像データを格納するための大型記憶領域である。本実施形態の特徴は、主にエンジンＡＳＩＣ４及びコントローラＡＳＩＣ５の機能により実現される。

以下では、一般的なエンジンＡＳＩＣの内部構成について図２を参照しながら説明する。その後、本実施形態に係るコントローラＡＳＩＣ５及びエンジンＡＳＩＣ４の内部構成について図３及び図４を参照しながら説明する。

（一般的なエンジンＡＳＩＣの内部構成）
まず、一般的なエンジンＡＳＩＣの内部構成について説明する。図２に示した一般的なエンジンＡＳＩＣ９４は、スキャナＩ／Ｆ制御部９０１、プロッタＩ／Ｆ制御部９０２、Ｓ２Ｍ（Ｓｃａｎｎｅｒ ｔｏ Ｍｅｍｏｒｙ）画像処理部９０３、Ｍ２Ｐ（Ｍｅｍｏｒｙ ｔｏ Ｐｌｏｔｔｅｒ）画像処理部９０４、Ｓ２Ｍバッファ９０５、Ｍ２Ｐバッファ９０６、ＷＤＭＡＣ９０７、ＲＤＭＡＣ９０８、アービタ９０９、コントローラＩ／Ｆ制御部９１０、コミュニケーションバッファ９１１及びＣＰＵ Ｉ／Ｆ制御部９１２を有する。

Ｓ２Ｍバッファ９０５及びＭ２Ｐバッファ９０６は、Ｓ２Ｍバッファ９０５を通る経路及びＭ２Ｐバッファ９０６を通る経路において、Ｓ２Ｍ画像処理部９０３及びＭ２Ｐ画像処理部９０４が行う画像データ処理にて画像データを一時的に保持するために実装されている。また、Ｓ２Ｍバッファ９０５及びＭ２Ｐバッファ９０６は、Ｓ２Ｍバッファ９０５を通る経路及びＭ２Ｐバッファ９０６を通る経路とコントローラ２との転送時の転送速度差吸収のために転送データを一時的に保持するために実装されている。

（コントローラＡＳＩＣ５の内部構成）
次に、本実施形態に係るコントローラＡＳＩＣ５の内部構成について説明する。図３に示した本実施形態に係るコントローラＡＳＩＣ５は、エンジンＩ／Ｆ制御部５０１、コントローラ画像処理部５０２、画像処理バッファ５０３、画像処理ＷＤＭＡＣ５０４、画像処理ＲＤＭＡＣ５０５、画像入力ＷＤＭＡＣ５０６、画像出力ＲＤＭＡＣ５０７、画像入力バッファ５０８、画像出力バッファ５０９、メモリアービタ５１０、システムＩ／Ｆ制御部５１１及びレジスタ制御部５１２を有している。

画像入力バッファ５０８及び画像出力バッファ５０９は、Ｓ２Ｍ（Ｓｃａｎｎｅｒ ｔｏ Ｍｅｍｏｒｙ）動作（エンジン制御部１からの画像入力）及びＭ２Ｐ（Ｍｅｍｏｒｙ ｔｏ Ｐｌｏｔｔｅｒ）動作（エンジン制御部１への画像出力）時に、エンジン制御部１とコントローラ２との間（つまり、エンジンＡＳＩＣ４とコントローラＡＳＩＣ５との間）の転送と、コントローラＡＳＩＣ５とメモリ７との間の転送との転送速度差吸収のために実装されている。画像処理バッファ５０３は、Ｍ２Ｐ動作においてコントローラ画像処理部５０２が行う処理の画像データ処理にて画像データを一時的に保持するために実装されている。

（エンジンＡＳＩＣの内部構成）
次に、本実施形態に係るエンジンＡＳＩＣ４の内部構成について説明する。図４に示した本実施形態に係るエンジンＡＳＩＣ４は、図２に示した一般的なエンジンＡＳＩＣ９４に備わっているバッファの空き領域を利用してログデータを蓄積する構成を有している。本実施形態に係るエンジンＡＳＩＣ４は、一般的なエンジンＡＳＩＣ９４の構成に、デバッグ制御部４１３を追加した構成を有する。デバッグ制御部４１３は、アービタ４０９とコントローラＩ／Ｆ制御部４１０との間に設けられ、ＣＰＵ Ｉ／Ｆ制御部４１２と接続されている。

具体的には、本実施形態に係るエンジンＡＳＩＣ４は、スキャナＩ／Ｆ制御部４０１、プロッタＩ／Ｆ制御部４０２、Ｓ２Ｍ（Ｓｃａｎｎｅｒ ｔｏ Ｍｅｍｏｒｙ）画像処理部４０３、Ｍ２Ｐ（Ｍｅｍｏｒｙ ｔｏ Ｐｌｏｔｔｅｒ）画像処理部４０４、Ｓ２Ｍバッファ４０５、Ｍ２Ｐバッファ４０６、ＷＤＭＡＣ４０７、ＲＤＭＡＣ４０８、アービタ４０９、デバッグ制御部４１３、コントローラＩ／Ｆ制御部４１０、コミュニケーションバッファ４１１及びＣＰＵ Ｉ／Ｆ制御部４１２を有する。

なお、Ｓ２Ｍバッファ４０５及びＭ２Ｐバッファ４０６は、画像データを一時的に蓄積するバッファに相当する。より具体的には、Ｓ２Ｍバッファ４０５は、入力する画像データを蓄積するための入力用バッファに相当し、Ｍ２Ｐバッファ４０６は、出力する画像データを蓄積するための出力用バッファに相当する。

また、ＷＤＭＡＣ４０７及びＲＤＭＡＣ４０８は、画像データのメモリ７へのダイレクトメモリアクセスを制御するダイレクトメモリアクセスコントローラ（ＤＭＡＣ）に相当する。より具体的には、ＷＤＭＡＣ４０７は、Ｓ２Ｍバッファ４０５からメモリ７に画像データを書き込む書込み用ダイレクトメモリアクセスコントローラ（ＷＤＭＡＣ）に相当し、ＲＤＭＡＣ４０８は、メモリ７から画像データを読み込んでＭ２Ｐバッファ４０６に出力する読込み用ダイレクトメモリアクセスコントローラ（ＲＤＭＡＣ）に相当する。ＷＤＭＡＣ４０７及びＲＤＭＡＣ４０８により、画像データをメモリ７に書込む又はメモリ７から読み出すことができる。

デバッグ制御部４１３は、デバッグ用のログデータを生成し、エンジン制御部１内のバッファ（例えばＳ２Ｍバッファ４０５及びＭ２Ｐバッファ４０６）の空き状況及びコントローラ２のデータ転送状況に応じて、ログデータをバッファへ蓄積、またはコントローラ２へ転送する。以下、デバッグ制御部４１３の内部構成について説明する。

（デバッグ制御部４１３の内部構成）
図５に本実施形態に係るデバッグ制御部４１３の内部構成を示す。本実施形態に係るデバッグ制御部４１３は、ログデータの生成、バッファへの蓄積／読み出し、メモリ７への転送を実行する。デバッグ制御部４１３は、ログ生成部４１４、バッファ制御部４１５、デバッグ用ＷＤＭＡＣ４１６、デバッグ用アービタ４１７及び内部レジスタ４１８を有する。

（ログ生成部４１４）
ログ生成部４１４は、図４に示したＣＰＵ Ｉ／Ｆ制御部４１２とＷＤＭＡＣ４０７とＲＤＭＡＣ４０８とに接続され、レジスタアクセスや割り込み、各ＤＭＡＣの動作状態等の信号を入力する。レジスタアクセスが発生する毎に、上記信号の状態を記録したログデータを生成し、バッファ制御部４１５に出力する。ただし、ロギング制御レジスタがオンの場合のみログデータの生成および出力を行い、オフの場合は行わない。

このように、デバッグ用のログデータは、エンジン制御部１が有するレジスタへの書込み及び読込みの履歴情報を含んでもよい。また、デバッグ用のログデータは、ダイレクトメモリアクセスコントローラ（以下、ＤＭＡＣとも称呼する。）の動作状態の遷移を含んでもよい。また、デバッグ用のログデータは、エンジン制御部１への割り込み状態の遷移を含んでもよい。

（バッファ制御部４１５）
バッファ制御部４１５は、各ＤＭＡＣの動作状態に応じて、ログ生成部４１４から受け取ったログデータの蓄積／読み出し先バッファを切り替える。また、バッファにログデータが蓄積されていない場合はバッファエンプティ信号をデバッグ用ＷＤＭＡＣ４１６に出力する。バッファ切り替えの詳細は後述する。

（デバッグ用ＷＤＭＡＣ４１６）
デバッグ用ＷＤＭＡＣ４１６は、バッファ制御部４１５から入力したログデータをメモリ上にライト（書き込み）する。デバッグ用ＷＤＭＡＣ４１６は、デバッグ用アービタ４１７に対してライトリクエストを発生する。デバッグ用ＷＤＭＡＣ４１６は、バッファエンプティでない（すなわち、ログデータがバッファに存在する）限り、ライトリクエストを発行し続ける。

（デバッグ用アービタ４１７）
デバッグ用アービタ４１７は、（Ａ）一般的なアービタからのリクエスト（画像データ転送）と、（Ｂ）デバッグ用ＷＤＭＡＣ４１６からのリクエスト（ログデータの転送）とを調停する。プライオリティは、（Ａ）一般的なアービタからのリクエストが、（Ｂ）デバッグ用ＷＤＭＡＣ４１６からのリクエストより高く、固定値である。ログデータ転送は、本来のデータ転送帯域に影響を与えないように、（Ｂ）デバッグ用ＷＤＭＡＣ４１６からのリクエストを（Ａ）一般的なアービタからのリクエストより低い優先順位とする。これにより、ログデータ転送は、本来のデータ転送が行われていない空き時間を利用して処理される。

（内部レジスタ４１８）
内部レジスタ４１８は、ログ保存領域開始アドレスレジスタ４１９及びロギング制御レジスタ４２０を有する。エンジンＣＰＵ８は、内部レジスタ４１８の制御（レジスタ設定）を行うことができる。ログ保存領域開始アドレスレジスタ４１９には、デバッグ用ＷＤＭＡＣ４１５がログデータを転送する際の転送開始アドレスが設定される。ロギング制御レジスタ４２０には、ロギング（履歴情報の開始）のオン／オフ情報が設定される。

（バッファ制御部４１５の内部構成）
次に、バッファ制御部４１５の内部構成について、図６を参照しながら説明する。バッファ制御部４１５は、バッファセレクタ４２２及びデバッグ用バッファ４２３を有する。バッファセレクタ４２２は、各ＤＭＡＣの動作状態信号（ＷＤＭＡＣ状態信号及びＲＤＭＡＣ状態信号）に応じて、ログ生成部４１４から受け取ったログデータを、どのバッファに蓄積／読み出しするかを選択する。例えば、ＷＤＭＡＣ状態信号が「１」のときには、Ｓ２Ｍバッファ４０５へ画像データを転送中であることを示す。ＲＤＭＡＣ状態信号が「１」のときには、Ｍ２Ｐバッファ４０６へ画像データを転送中であることを示す。

各ＤＭＡＣ動作状態信号と使用バッファ（ログデータの蓄積／読み出し先）との関係を図７に示す。ＷＤＭＡＣ状態信号が「０」、ＲＤＭＡＣ状態信号が「０」のとき、使用バッファは、Ｓ２Ｍバッファ４０５又はＭ２Ｐバッファ４０６となる。ＷＤＭＡＣ状態信号が「０」、ＲＤＭＡＣ状態信号が「１」のとき、使用バッファは、Ｓ２Ｍバッファ４０５となる。ＷＤＭＡＣ状態信号が「１」、ＲＤＭＡＣ状態信号が「０」のとき、使用バッファは、Ｍ２Ｐバッファ４０６となる。ＷＤＭＡＣ状態信号が「１」、ＲＤＭＡＣ状態信号が「１」のとき、使用バッファは、デバック用バッファ４２３となる。

これによれば、デバッグ用バッファ４２３を使用するのはＳ２Ｍバッファ４０５へのデータ転送とＭ２Ｐバッファ４０６へのデータ転送が同時に発生しているときのみである。すなわち、Ｓ２Ｍバッファ４０５とＭ２Ｐバッファ４０６とのどちらかへのデータ転送が止まっている場合には、本来データ転送用に使われるＳ２Ｍバッファ４０５又はＭ２Ｐバッファ４０６の空き領域をログデータ転送用に利用する。本実施形態に係る優先順位を用いた各バッファの利用方法によれば、バッファ用のメモリ領域を無用に拡大する必要がないため、回路規模の増大を抑えることができる。

また、各バッファに対するライト／リード回数をカウントし、等しい場合はバッファエンプティ信号をアサートする。つまり、各バッファに対するライト／リード回数が等しい場合は、バッファログデータが存在しないと判断し、バッファエンプティ信号を有効な状態にする。なお、ライト回数＞リード回数の場合は、バッファログデータが存在すると判定し、バッファエンプティ信号をディアサート、つまり、バッファエンプティ信号を無効な状態にする。

図８には、ＷＤＭＡＣ状態信号とＲＤＭＡＣ状態信号と、使用バッファとの関係が図示されている。使用バッファに記載された「Ｓ２Ｍ」はＳ２Ｍバッファ４０５を示し、「Ｍ２Ｐ」はＭ２Ｐバッファ４０６を示し、「Ｄｅｂｕｇ」はデバッグ用バッファ４２３を示す。図７に示したＷＤＭＡＣ状態信号とＲＤＭＡＣ状態信号と、使用バッファとの関係に基づき、図８に示したように使用バッファが遷移する。例えば、図８では最初、ＷＤＭＡＣ状態信号とＲＤＭＡＣ状態信号は（０，０）であるため、使用バッファはＳ２Ｍバッファ４０５又はＭ２Ｐバッファ４０６を使用可能であるが、図８ではＭ２Ｐバッファ４０６を使用する。次に、ＷＤＭＡＣ状態信号とＲＤＭＡＣ状態信号は（１，０）であるため、使用バッファはＭ２Ｐバッファ４０６のままとなる。次いで、ＷＤＭＡＣ状態信号とＲＤＭＡＣ状態信号は（０，０）の後、（０，１）となった時点で、使用バッファはＳ２Ｍバッファ４０５に遷移する。更に、ＷＤＭＡＣ状態信号とＲＤＭＡＣ状態信号が（０，０）の後、（１，０）となった時点で、使用バッファは再びＭ２Ｐバッファ４０６に遷移する。更に、ＷＤＭＡＣ状態信号とＲＤＭＡＣ状態信号が（１，１）となった時点で、使用バッファはデバッグ用バッファ４２３に遷移する。

これによれば、デバッグ用バッファ４２３を使用するのはＳ２Ｍバッファ４０５へのデータ転送とＭ２Ｐバッファ４０６へのデータ転送が同時に発生しているときのみであることがわかる。なお、ＷＤＭＡＣ状態信号とＲＤＭＡＣ状態信号は（０，０）である場合、使用バッファはＳ２Ｍバッファ４０５又はＭ２Ｐバッファ４０６を使用可能であるから、図８ではＭ２Ｐバッファ４０６を使用しているが、Ｓ２Ｍバッファ４０５を使用するようにしても良い。ＷＤＭＡＣ状態信号とＲＤＭＡＣ状態信号は（０，０）の場合、Ｓ２Ｍバッファ４０５とＭ２Ｐバッファ４０６のいずれを使用バッファとして設定するかは、Ｓ２Ｍバッファ４０５とＭ２Ｐバッファ４０６の使用頻度等に応じて決めることができる。

［動作］
次に、第１実施形態に係る画像形成装置用のデバイスの動作について、図９を参照しながら説明する。図９は、本実施形態に係るエンジンＣＰＵ８、エンジンＡＳＩＣ４、コントローラＡＳＩＣ５、コントローラＣＰＵ１０、メモリ７の各部の状態を示したシーケンス図である。

なお、図９は、Ｓ２Ｍバッファ４０５へのデータ転送、すなわち、メモリ７への書き込みの場合を例に挙げて図示している。Ｍ２Ｐバッファ４０６へのデータ転送の場合は、画像データの転送方向が逆、すなわち、メモリ７からの読み出しとなる。それ以外のシーケンスについては、Ｓ２Ｍバッファ４０５へのデータ転送とＭ２Ｐバッファ４０６へのデータ転送とは共通する。以下では、Ｓ２Ｍバッファ４０５へのデータ転送の場合のみ説明し、Ｍ２Ｐバッファ４０６へのデータ転送の場合の説明は省略する。

（処理の流れ）
図９のシーケンス図に示した処理の流れの詳細説明を以下に示す。
（１）まず、コントローラＣＰＵ１０からエンジンＣＰＵ８に、Ｓ２Ｍバッファ４０５へのデータ転送制御用の各種パラメータを転送する。
（２）次に、コントローラＣＰＵ１０からエンジンＣＰＵ８に、ログ保存領域開始アドレスを転送する。
（３）次に、エンジンＣＰＵ８からエンジンＡＳＩＣ４のレジスタに、Ｓ２Ｍバッファ４０５へのデータ転送制御用の各種パラメータを設定する。
（４）次に、エンジンＣＰＵ８からエンジンＡＳＩＣ４のレジスタに、ログ保存領域開始アドレスを設定する。
（５）次に、エンジンＣＰＵ８の制御によりエンジンＡＳＩＣ４のレジスタは、ロギングオン（ログデータの蓄積開始）に設定される。これにより、エンジンＣＰＵ８からエンジンＡＳＩＣ４へのレジスタアクセスが発生する毎にログデータの生成および転送が開始される。
（６）次に、エンジンＣＰＵ８からエンジンＡＳＩＣ４のダイレクトメモリアクセスコントローラ（ＤＭＡＣ）を起動し、Ｓ２Ｍバッファ４０５へのデータ転送を開始する。これにより、Ｓ２Ｍバッファ４０５を介して、エンジンＡＳＩＣ４からメモリ７への画像データの転送が開始される。
（７）画像データの転送が終了すると、エンジンＡＳＩＣ４からエンジンＣＰＵ８に割り込みが発生し、ＳＳ２Ｍバッファ４０５へのデータ転送の完了が通知される。
（８）次に、エンジンＣＰＵ８の制御によりエンジンＡＳＩＣ４のレジスタはロギングオフ（ログデータの蓄積終了）に設定される。これにより、ログデータの生成および転送が終了する。
（９）次に、コントローラＣＰＵ１０からエンジンＣＰＵ８に、ＳＳ２Ｍバッファ４０５へのデータ転送の完了通知が送られる。
（１０）最後に、コントローラＣＰＵ１０は、メモリ７のログデータの読み出しを行う。

（ログデータの一例）
以上の画像形成装置用のデバイスの動作により記録されたログデータの一例を図１０に示す。Ｓｅｑ＿Ｎｕｍは、シーケンシャルナンバーを示す。ＡＤＤＲは、レジスタアクセスのアドレスを示す。ＤＡＴＡは、レジスタアクセスのリードまたはライトデータを示す。Ｒ／Ｗは、レジスタアクセスのリード／ライト区分を示す。ＥＸＥＣは、各ＤＭＡＣの動作状態を示す。ＩＮＴ＿ＦＬＧは、各割り込みフラグの状態を示す。

シーケンシャルナンバーＳｅｑ＿Ｎｕｍには、１つのログデータにつき１つの番号が割り当てられる。シーケンシャルナンバーＳｅｑ＿Ｎｕｍは、ロギング開始から終了までの間、新たなログデータが発生する毎にインクリメントされる。シーケンシャルナンバーＳｅｑ＿Ｎｕｍをつけることで、イベントの発生順番を記録することができ、これにより、ログデータを使用してより容易に障害の原因を解析することができる。上記をレジスタアクセス１回分のログデータとする。

以上、第１実施形態に係る画像形成装置用のデバイスについて説明した。第１実施形態に係る画像形成装置用のデバイスでは、ＡＳＩＣ内部に元々備わっている画像データ用のバッファの空き領域を利用してログデータを一時的にバッファに蓄積し、かつ、画像データ転送の空き時間を利用して、ログデータをメモリに転送する。これによれば、本来のデータ転送帯域に影響を与えることなく、かつバッファのための回路規模の増大を抑制しながらデバッグのためのログデータを記録することができる。

＜第２実施形態＞
［全体構成］
次に、本発明の第２実施形態に係る画像形成装置用のデバイスについて説明する。第２実施形態に係る画像形成装置用のデバイスの全体構成、エンジンＡＳＩＣ４の内部構成及びコントローラＡＳＩＣ５の内部構成は、第１実施形態に係る画像形成装置用のデバイスの全体構成（図１）、エンジンＡＳＩＣ４の内部構成（図４）及びコントローラＡＳＩＣ５の内部構成（図３）と同様であるため、ここでは説明を省略する。

（デバッグ制御部の内部構成）
第２実施形態では、デバッグ制御部は、エンジンＡＳＩＣ側とコントローラＡＳＩＣ側との両方に設けられている。エンジンＡＳＩＣ側は図１１のデバッグ制御部４１３、コントローラＡＳＩＣ側は図１５及び図１６のデバッグ制御部５１３である。そして、エンジンＡＳＩＣ４とコントローラＡＳＩＣ５とが連動し、両方に備わっているデバッグ制御部（デバッグ制御部４１３、デバッグ制御部５１３）にそれぞれ設けられているバッファの空き領域を利用してログデータを蓄積するようになっている。

（エンジンＡＳＩＣ側のデバッグ制御部の内部構成）
まず、デバッグ制御部４１３の内部構成について、図１１を参照しながら説明する。図１１は、第２実施形態に係るエンジンＡＳＩＣ４側のデバッグ制御部４１３の内部構成を示す。第１実施形態に係るデバッグ制御部と下記の点で異なる。
・コントローラＡＳＩＣバッファエンプティ信号を追加
・コントローラＡＳＩＣバッファ指定アドレスレジスタ４２１を内部レジスタ４１８に追加
コントローラＡＳＩＣバッファ指定アドレスは、ログデータをエンジンＡＳＩＣ４からコントローラＡＳＩＣ５のバッファに転送し蓄積する場合の転送先アドレスとなる。

（バッファ制御部４１５の内部構成）
次に、第２実施形態に係るバッファ制御部４１５（エンジンＡＳＩＣ側）の内部構成について、図１２を参照しながら説明する。第２実施形態に係るバッファ制御部４１５は、図６の第１実施形態に係るバッファ制御部４１５に、コントローラＡＳＩＣバッファエンプティ信号を追加した構成となる。また、バッファセレクタ４２２の機能の一部が、第１実施形態とは異なる。

（バッファセレクタ４２２）
バッファセレクタ４２２は、各ＤＭＡＣの動作状態信号（ＷＤＭＡＣ状態信号及びＲＤＭＡＣ状態信号）に応じて、ログ生成部４１４から受け取ったログデータを、どのバッファに蓄積／読み出しするかを選択する。各ＤＭＡＣ動作状態信号と使用バッファ（ログデータの蓄積／読み出し先）との関係を図１３に示す。第２実施形態に係るバッファセレクタ４２２は、この関係に基づき使用バッファを選択する。

ＷＤＭＡＣ状態信号が「０」、ＲＤＭＡＣ状態信号が「０」のとき、使用バッファは、Ｓ２Ｍバッファ４０５又はＭ２Ｐバッファ４０６となる。このとき、バッファの選択に対してコントローラＡＳＩＣバッファエンプティ信号は考慮しなくてよい。

ＷＤＭＡＣ状態信号が「０」、ＲＤＭＡＣ状態信号が「１」のとき、使用バッファはＳ２Ｍバッファ４０５となり、ＷＤＭＡＣ状態信号が「１」、ＲＤＭＡＣ状態信号が「０」のとき、使用バッファはＭ２Ｐバッファ４０６となる。これらのときも、バッファの選択に対してコントローラＡＳＩＣバッファエンプティ信号は考慮しなくてよい。

ＷＤＭＡＣ状態信号が「１」、ＲＤＭＡＣ状態信号が「１」のとき、コントローラＡＳＩＣバッファエンプティ信号を考慮する。つまり、ＷＤＭＡＣ状態信号およびＲＤＭＡＣ状態信号がともに「１」の場合、コントローラバッファエンプティ信号の状態に応じて、ログデータの蓄積／読み出し先を切り替える。具体的には、コントローラＡＳＩＣバッファエンプティ信号が「１」のとき、使用バッファは、コントローラＡＳＩＣのバッファとなり、コントローラＡＳＩＣにログデータを転送する。コントローラＡＳＩＣは、それを受けて内部のバッファにログデータを蓄積する。コントローラＡＳＩＣの動作に関しては後述する。

また、コントローラＡＳＩＣバッファエンプティ信号が「０」のとき、使用バッファは、デバッグ用のバッファとなる。

本実施形態によれば、Ｓ２Ｍバッファ４０５へのデータ転送とＭ２Ｐバッファ４０６へのデータ転送が同時に発生しているとき（つまり、Ｓ２Ｍバッファ４０５及びＭ２Ｐバッファ４０６が共に画像データ用に使用されているとき）でも、コントローラＡＳＩＣのバッファが空いていればそちらを使用することができる。これにより、第１実施形態と比較してデバッグ用バッファによる回路規模の増大をより抑止することができる。

図１４には、ＷＤＭＡＣ状態信号とＲＤＭＡＣ状態信号とコントローラＡＳＩＣバッファエンプティ信号と、使用バッファとの関係が図示されている。使用バッファに記載された「Ｓ２Ｍ」はＳ２Ｍバッファ４０５を示し、「Ｍ２Ｐ」はＭ２Ｐバッファ４０６を示し、「ＡＳＩＣ２」はコントローラＡＳＩＣ５のバッファを示し、「Ｄｅｂｕｇ」はデバッグ用バッファ４２３を示す。

図１３に示したＷＤＭＡＣ状態信号とＲＤＭＡＣ状態信号とコントローラＡＳＩＣバッファエンプティ信号と、使用バッファとの関係に基づき、図１４に示したように使用バッファが遷移する。これによれば、エンジンＡＳＩＣ４のデバッグ用バッファ４２３又はコントローラＡＳＩＣ５のバッファを使用するのはＳ２Ｍバッファ４０５へのデータ転送とＭ２Ｐバッファ４０６へのデータ転送が同時に発生しているときのみであることがわかる。また、コントローラＡＳＩＣバッファエンプティ信号の値で、エンジンＡＳＩＣ４のデバッグ用バッファ４２３又はコントローラＡＳＩＣ５のバッファのいずれを使用するかを切り替えることができる。

（コントローラＡＳＩＣ側のデバッグ制御部の内部構成）
次に、第２実施形態に係るコントローラＡＳＩＣ５の内部構成について、図１５を参照しながら説明する。第２実施形態に係るコントローラＡＳＩＣ５は、第１実施形態に係るコントローラＡＳＩＣ５の内部構成（図３）に加えてデバッグ制御部５１３が追加されている。デバッグ制御部５１３は、メモリアービタ５１０とシステムＩ／Ｆ制御部５１１との間に設けられている。

図１６は、第２実施形態に係るコントローラＡＳＩＣ側のデバッグ制御部５１３の内部構成を示す。デバッグ制御部５１３は、エンジンＡＳＩＣ４から転送されたログデータのバッファへの蓄積／読み出し、バッファ空き状態のエンジンＡＳＩＣ４への通知、ログデータのメモリへの転送を担う。

デバッグ制御部５１３は、アドレスデコーダ５１４、バッファ制御部５１５、デバッグ用ＷＤＭＡＣ５１６、デバッグ用アービタ５１７及び内部レジスタ５１８を有する。

（バッファ制御部５１５）
バッファ制御部５１５は、各ＤＭＡＣ（ＷＤＭＡＣ状態信号及びＲＤＭＡＣ状態信号）および画像処理部の動作状態（画像処理部状態信号）に応じて、エンジンＡＳＩＣ４から取得したログデータの蓄積／読み出し先バッファを切り替える。また、コントローラ側のバッファにログデータが蓄積されていない場合は、コントローラＡＳＩＣバッファエンプティ信号をエンジンＡＳＩＣ４に出力する。

（デバッグ用ＷＤＭＡＣ５１６）
デバッグ用ＷＤＭＡＣ５１６は、バッファ制御部５１５から受け取ったログデータをメモリ上にライトする。デバッグ用ＷＤＭＡＣ５１６は、デバッグ用アービタ５１７に対してライトリクエストを発生する。デバッグ用ＷＤＭＡＣ５１６は、コントローラＡＳＩＣバッファエンプティ信号がアサート（ログデータがバッファに存在）している限り、ライトリクエストを発行し続ける。

（アドレスデコーダ５１４）
アドレスデコーダ５１４は、メモリアービタ５１０から受け取るリクエストのアドレスに応じて、データの出力先を切り替える。アドレスデコーダ５１４は、アドレスが内部レジスタ５１８に設定したコントローラＡＳＩＣバッファ指定アドレスレジスタ５１９と一致する場合、コントローラＡＳＩＣ５のバッファに蓄積するログデータと判定し、バッファ制御部５１５に出力する。アドレスデコーダ５１４は、アドレスが内部レジスタ５１８に設定したコントローラＡＳＩＣバッファ指定アドレスレジスタ５１９と一致しない場合、メモリ７に転送するログデータまたは画像データと判定し、デバッグ用アービタ５１７に出力する。

（デバッグ用アービタ５１７）
デバッグ用アービタ５１７は、（Ｃ）メモリアービタ５１０からのリクエスト（メモリ７に転送するログデータまたは画像データ）と、（Ｄ）デバッグ用ＷＤＭＡＣ５１６からのリクエスト（ＡＳＩＣ２のバッファから読み出したログデータ）とを調停する。
プライオリティは（Ｃ）メモリアービタ５１０からのリクエストが、（Ｄ）デバッグ用ＷＤＭＡＣ５１６からのリクエストより高く、固定値である。これにより、ログデータ転送は、本来のデータ転送が行われていない空き時間を利用して処理される。よって、本実施形態によれば本来のデータ転送帯域に影響を与えず、ログデータを転送することができる。

（内部レジスタ５１８）
内部レジスタ５１８は、コントローラＡＳＩＣバッファ指定アドレスレジスタ５１９及びログ保存領域開始アドレスレジスタ５２０を備える。エンジンＣＰＵ８は、内部レジスタ４１８の制御（レジスタ設定）を行うことができる。

コントローラＡＳＩＣバッファ指定アドレス部レジスタ５１９には、ログデータをエンジンＡＳＩＣ４からコントローラＡＳＩＣ５のバッファに転送し蓄積するときの転送先アドレスが設定される。エンジンＡＳＩＣ４に設定されたレジスタ設定値と同じ値を設定することができる。この値は、アドレスデコーダでのログデータ出力先の判定に用いられる。

ログ保存領域開始アドレス部レジスタ５２０には、コントローラＡＳＩＣ５のデバッグ用ＷＤＭＡＣ５１６がログデータを転送する際の転送開始アドレスが設定される。

（バッファ制御部５１５の内部構成）
次に、コントローラＡＳＩＣ側のバッファ制御部５１５の内部構成について、図１７を参照しながら説明する。バッファ制御部５１５は、バッファセレクタ５２１及びデバッグ用バッファ５２２を有する。

バッファセレクタ５２１は、各ＤＭＡＣの動作状態信号（ＷＤＭＡＣ状態信号及びＲＤＭＡＣ状態信号）と画像処理部状態信号とに応じて、エンジンＡＳＩＣ４から受け取ったログデータを、どのバッファに蓄積／読み出しするかを選択する。

例えば、ＷＤＭＡＣ状態信号が「１」のとき、エンジンＡＳＩＣ４からの画像転送中（Ｓ２Ｍバッファ４０５に転送中）を示す。ＲＤＭＡＣ状態信号が「１」のとき、エンジンＡＳＩＣ４への画像転送中（Ｍ２Ｐバッファ４０６に転送中）を示す。画像処理部状態信号が「１」のとき、Ｍ２Ｍ（Ｍｅｍｏｒｙ ｔｏ Ｍｅｍｏｒｙ）動作での画像処理実行中を示す。Ｍ２Ｍ動作は、ＤＭＡによってメモリからデータを読み出し、各種処理をして再度メモリに書き込む動作である。Ｓ２Ｍ（Ｓｃａｎｎｅｒ ｔｏ Ｍｅｍｏｒｙ）動作及びＭ２Ｐ（Ｍｅｍｏｒｙ ｔｏ Ｐｌｏｔｔｅｒ）動作と対比される動作であり、本実施形態では、メモリ７→画像処理ＲＤＭＡＣ５０５→コントローラ画像処理部５０２→画像処理ＷＤＭＡＣ５０４→メモリ７の経路がＭ２Ｍ動作の経路となる。

各動作状態信号と使用バッファ（ログデータの蓄積／読み出し先）との関係を図１８に示す。デバッグ用バッファを使用するのはＳ２Ｍ動作、Ｍ２Ｐ動作、Ｍ２Ｍ動作が同時に発生しているときのみで、いずれかの転送が止まっている場合は、本来的には画像データの転送又は画像処理用に使われる画像入力又は画像出力又は画像処理用のバッファの空き領域を利用する。これにより、バッファのためのメモリ領域拡大が不要になり、回路規模の増大を抑えることができる。

また、各バッファに対するライト／リード回数をカウントし、等しい場合はコントローラＡＳＩＣバッファエンプティ信号をアサート、つまりバッファエンプティ信号を有効な状態にする。なお、ライト回数＞リード回数の場合は、バッファにログデータが存在することを示す。よって、この場合にはコントローラＡＳＩＣバッファエンプティ信号をディアサートし、バッファエンプティ信号を無効な状態にする。

図１９には、ＷＤＭＡＣ状態信号とＲＤＭＡＣ状態信号と画像処理部状態信号と、使用バッファとの関係が図示されている。使用バッファに記載された「出力」は画像出力バッファ５０９を示し、「入力」は画像入力バッファ５０８を示し、「処理」は画像処理バッファ５０３を示し、「Ｄｅｂｕｇ」はデバッグ用バッファ５２２を示す。

図１８に示したＷＤＭＡＣ状態信号とＲＤＭＡＣ状態信号と画像処理部状態信号と、使用バッファとの関係に基づき、図１９に示したように使用バッファが遷移する。デバッグ用バッファ５２２が使用されるのは、ＷＤＭＡＣ状態信号とＲＤＭＡＣ状態信号と画像処理部状態信号が（１，１，１）に遷移したタイミングである。

［動作］
次に、第２実施形態に係る画像形成装置用のデバイスの動作について、図２０を参照しながら説明する。図２０は、本実施形態に係るエンジンＣＰＵ８、エンジンＡＳＩＣ４、コントローラＡＳＩＣ５、コントローラＣＰＵ１０、メモリ７の各部の状態を示したシーケンス図である。

なお、図２０は、Ｓ２Ｍバッファ４０５へのデータ転送、すなわち、メモリ７への書き込みの場合を例に挙げて図示している。Ｍ２Ｐバッファ４０６へのデータ転送の場合は、画像データの転送方向が逆、すなわち、メモリ７からの読み出しとなる。それ以外のシーケンスについては、Ｓ２Ｍバッファ４０５へのデータ転送とＭ２Ｐバッファ４０６へのデータ転送とは共通する。以下では、Ｓ２Ｍバッファ４０５へのデータ転送の場合のみ説明し、Ｍ２Ｐバッファ４０６へのデータ転送の場合の説明は省略する。

第１実施形態との差異は以下の４つの処理を追加した点である。
・「（６）コントローラ側のログ保存領域開始アドレスのレジスタ設定」の処理を追加
・「（７）コントローラＡＳＩＣバッファ指定アドレスのレジスタ設定」の処理を追加
・「コントローラＡＳＩＣバッファエンプティ信号のアサート／ディアサート」の処理を追加
・「（１３）ログデータ読み出しの際の、ログ保存領域が２つになる」処理を追加
（処理の流れ）
図２０のシーケンス図に示した処理の流れの詳細説明を以下に示す。
（１）まず、コントローラＣＰＵ１０からエンジンＣＰＵ８に、Ｓ２Ｍバッファ４０５へのデータ転送制御用の各種パラメータを転送する。
（２）次に、コントローラＣＰＵ１０からエンジンＣＰＵ８に、ログ保存領域開始アドレスを転送する。
（３）次に、エンジンＣＰＵ８からエンジンＡＳＩＣ４のレジスタに、Ｓ２Ｍバッファ４０５へのデータ転送制御用の各種パラメータを設定する。
（４）次に、エンジンＣＰＵ８からエンジンＡＳＩＣ４のレジスタに、エンジンＡＳＩＣ側のログ保存領域開始アドレス４１９を設定する。
（５）次に、エンジンＣＰＵ８からエンジンＡＳＩＣ４のレジスタに、コントローラＡＳＩＣバッファ指定アドレスを設定する。
（６）コントローラＣＰＵ１０からコントローラＡＳＩＣ５に、コントローラＡＳＩＣ側のログ保存領域開始アドレス５２０を設定する。
（７）コントローラＣＰＵ１０からコントローラＡＳＩＣ５に、コントローラＡＳＩＣバッファ指定アドレスを設定する。
（８）エンジンＣＰＵ８からエンジンＡＳＩＣ４のレジスタにロギングオン（ログデータの蓄積開始）が設定される。これにより、エンジンＣＰＵ８からエンジンＡＳＩＣ４へのレジスタアクセスが発生する毎にログデータの生成および転送が開始される。これによれば、コントローラＡＳＩＣ５のバッファの空き状況に応じて、コントローラＡＳＩＣ５からエンジンＡＳＩＣ４へコントローラＡＳＩＣバッファエンプティ信号がアサート／ディアサートされる。
（９）エンジンＣＰＵ８がエンジンＡＳＩＣ４のＤＭＡＣを起動し、Ｓ２Ｍバッファ４０５へのデータ転送を開始する。これにより、コントローラＡＳＩＣ５を介して、エンジンＡＳＩＣ４からメモリ７への画像転送が開始される。
（１０）画像転送が終了すると、エンジンＡＳＩＣ４からエンジンＣＰＵ８に割り込みが発生し、Ｓ２Ｍバッファ４０５へのデータ転送の完了を通知する。
（１１）エンジンＣＰＵ８からエンジンＡＳＩＣ４のレジスタに、ロギングオフが設定される。これにより、ログデータの生成および転送が終了する。
（１２）コントローラＣＰＵ１０からエンジンＣＰＵ８に、Ｓ２Ｍバッファ４０５へのデータ転送の完了通知を送る。
（１３）コントローラＣＰＵ１０は、メモリ７のログデータを読み出す。ログデータが保存される領域は２つ（ログ保存領域アドレス開始４１９およびログ保存領域開始アドレス５２０）に分かれているので、両方の領域のログデータを読み出す。

以上、第２実施形態に係る画像形成装置用のデバイスについて説明した。以上のように第２実施形態に係る画像形成装置用のデバイスにおいて、コントローラ２は、画像データの前記メモリへのダイレクトメモリアクセスを制御するＤＭＡＣと、画像データを一時的に蓄積するバッファと、デバッグ用のログデータを生成し、前記エンジン制御部内の前記バッファの空き状況及び前記コントローラへのデータ転送状況に応じて、前記生成されたログデータをバッファへ蓄積するか又は前記コントローラへ転送するデバッグ制御部とを有する。エンジン制御部のデバッグ制御部は、前記エンジン制御部側のバッファの空き状況と、前記コントローラ側のバッファの空き状況とに応じて前記生成したログデータを前記コントローラへのデータ転送状況に応じて、前記生成されたログデータを前記エンジン制御部側のバッファ又は前記コントローラ側のバッファへ蓄積するか又はコントローラへ転送する。

これによれば、ＡＳＩＣ内部に元々備わっている画像データ用のバッファの空き領域を利用してログデータを一時的に蓄積し、かつ、画像データ転送の空き時間を利用して、ログデータをメモリ７に転送する。これによれば、本来のデータ転送帯域に影響を与えることなく、かつバッファ用のメモリ領域の拡大のための回路規模の増大を抑制しながらデバッグのためのログデータを記録することができる。また、本実施形態によれば、エンジン制御部１又はコントローラ２のいずれかのバッファに空き領域があれば、本来画像データ蓄積用に用いられるバッファをログデータの蓄積に用いることができる。このため、エンジン制御部１およびコントローラ２に実装されるログバッファのための回路規模の増大を抑えながら、確実にログ情報を蓄積することができる。

また、第２実施形態に係る画像形成装置用のデバイスによれば、エンジン制御部１側またはコントローラ２側の両方のバッファを使用して、いずれかのバッファに空き領域があれば本来画像データ蓄積用に用いられるバッファをログデータの蓄積に用いることができる。このため、第１実施形態の場合より、より確実にログ情報を蓄積することができる。

＜第３実施形態＞
次に説明する第３実施形態に係る電子機器用のデバイスでは、ＣＰＵからアクセスが可能なデバイス、およびデバイスを搭載する電子機器の障害解析のために、ＣＰＵからレジスタへのアクセスや内部信号の挙動という特定のイベントが、ログデータとして取得したい特定のイベントとして登録される。そして、登録されたイベントが発生した場合のみ、イベント番号を含むログデータが保存される。これにより、電子機器に内蔵されるメモリの容量を小さく抑えることができる。

［全体構成］
以下、第３実施形態に係る電子機器に搭載されたデバイス（回路）の全体構成について、図２１を参照しながら説明する。第３実施形態に係る電子機器に搭載されたデバイス（回路）は、ターゲット基板６００に形成されている。

ターゲット基板６００は、電子機器の回路部を構成する部品である。ターゲット基板６００には、ＣＰＵ６２０（所定のコントローラに相当）と、ＣＰＵ６２０からアクセスを受けるデバイス６０１とが搭載されている。図２１の構成例では、ＣＰＵ６２０が、デバイス６０１に対して外付けになっており、デバイス６０１内で取得されるアクセスログデータ（以下、アクセスログという。）を記憶する記憶装置としての内蔵メモリ６０９がデバイス６０１に内蔵されているが、ＣＰＵ６２０及び内蔵メモリ６０９のいずれも、デバイス６０１に対して外付けされても、内蔵されてもよい。

例えば、デバイス６０１を搭載する電子機器が画像形成装置である場合、デバイス６０１は、例えば、プリンタ制御用のエンジンＡＳＩＣといった、ＣＰＵ Ｉ／Ｆを有するデバイスである。図２１に示すように、デバイス６０１は、ＣＰＵ Ｉ／Ｆ６０３、割り込みコントローラ６０５、機能モジュール６０７ａ、６０７ｂ、６０７ｃ、内蔵メモリ６０９、シリアルＩ／Ｆ６１１及びデバッグ制御部６１３を有する。

ＣＰＵ Ｉ／Ｆ６０３は、ＣＰＵ６２０にＣＰＵバスを介して接続され、ＣＰＵ６２０からレジスタへのアクセスをデバイス６０１の内部のレジスタＩ／Ｆに変換して各機能モジュール６０７ａ、６０７ｂ、６０７ｃに接続する。

機能モジュール６０７ａ、６０７ｂ、６０７ｃは、デバイス６０１に内蔵された所望の機能を有するモジュールに相当し、それぞれＣＰＵ６２０にアクセス可能なレジスタを有し、内部バス経由でＣＰＵ６２０へのアクセスが行われる。図２１では、機能モジュール６０７ａ、６０７ｂ、６０７ｃの３つのモジュールを例に挙げているが、モジュール数はいくつでも構わない。機能モジュール６０７ａ、６０７ｂ、６０７ｃは、以下、総称して機能モジュール６０７ともいう。

内蔵メモリ６０９は、アクセスログを格納するために用いられる記憶装置である。内蔵メモリ６０９に格納されたアクセスログには、ＣＰＵ６２０および後述するターミナルＰＣ６３０から直接アクセスすることが可能である。

シリアルＩ／Ｆ６１１は、ターミナルＰＣ６３０から内蔵メモリ６０９にアクセスするためのＩ／Ｆとして機能する。

ターミナルＰＣ６３０は、シリアル操作及び表示用のＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）であり、シリアルＩ／Ｆ６１１を介して内蔵メモリ６０９にアクセスし、格納されたアクセスログを取得することが可能な管理端末機である。

デバッグ制御部６１３は、ＣＰＵ６２０からのアクセスを監視し、アクセスログを作成して内蔵メモリ６０９に出力するモジュールである。デバッグ制御部６１３は、デバイス６０１の内部信号を監視することも可能である。

デバッグ制御部６１３は、監視状況に応じて、割り込みコントローラ６０５を介してＣＰＵ６２０に割り込みを通知することも可能である。

（デバッグ制御部）
第３実施形態に係るデバッグ制御部６１３の機能の詳細について、図２２を参照しながら説明する。図２２は、第３実施形態に係るデバッグ制御部６１３の内部構成を示す。デバッグ制御部６１３は、イベント検出回路６４１、タイマー６４３、ログ作成回路６４５及びイベント登録部６４７を有する。イベント登録部６４７は、制御レジスタを有する。

イベント検出回路６４１は、レジスタＩ／ＦにてＣＰＵ６２０からのレジスタのアクセスと内部信号を監視する。イベント検出回路６４１は、イベント登録部６４７により予め制御レジスタ６４８に設定されたイベント検知条件に基づき、制御レジスタ６４８に設定された特定のイベントが発生したら検知結果をログ作成回路６４５に通知する。イベント検出回路６４１は、モジュールへのアクセスを分析し、特定のイベントを検知するイベント検出部に相当する。

イベント検出回路６４１は、特定のイベント発生時、以下のような処理も可能である。
・ＣＰＵ６２０に対して割り込みを発生させる。
・任意のレジスタへのライト（書込み）をマスクする。
・任意のレジスタに、任意の値を書き込む。

タイマー６４３は、図示しないカウンターを用いて時間を計測する。タイマー６４３によるカウント単位は、制御レジスタ６４８で設定可能である。タイマー６４３によるカウント値は、リアルタイムでイベント検出回路６４１に通知される。

ログ作成回路６４５は、イベント検知回路６４１からの検知結果に、タイマー６４３からの時間情報（タイムスタンプ）を付加し、ログデータを作成する。ログ作成回路６４５は、作成したログデータを内蔵メモリ６０９に転送する。ログ作成回路６４５は、イベント検知部により検知された特定のイベントに対するログデータを生成するログ生成部に相当する。

制御レジスタ６４８は、デバッグ制御部６１３を制御するレジスタである。以下では、図２３を参照して、制御レジスタ６４８に含まれる各レジスタの詳細を説明する。
［制御レジスタ］
（デバッグモードレジスタ＜ＤＢＧ＿ＭＯＤＥ＞６４７ａ）
デバッグモードレジスタ６４７ａは、デバッグのモードを選択する。「ｄｂｇ＿ｅｎ」は、デバッグをイネーブルにする。つまり、「ｄｂｇ＿ｅｎ」が「０」のときには、ログデータを取得しない。「ｄｂｇ＿ｅｎ」が「１」のときには、ログデータを取得する。

「ｅｖ＿ｅｎ」は、イベントモードをイネーブルにする。つまり、「ｅｖ＿ｅｎ」が「０」のときには、ノーマルモードで動作し、ＣＰＵからのレジスタアクセスを監視し、アドレス、データ、リード／ライトの情報を全てログデータとして取得する。「ｅｖ＿ｅｎ」が「１」のときには、イベントモードで動作し、レジスタに設定されたイベント検知条件と一致した場合のみ、ログデータを取得する。

「ｔｉｍｅ＿ｅｎ」は、タイムスタンプの付加をイネーブルにする。つまり、「ｔｉｍｅ＿ｅｎ」が「０」のときには、ログデータにタイムスタンプを付加しない。「ｔｉｍｅ＿ｅｎ」が「１」のときには、ログデータにタイムスタンプを付加する。

（タイマー周期レジスタ＜ＰＥＲＩＯＤ＞６４７ｂ）
タイマー周期レジスタ６４７ｂは、タイマー周期を設定する。タイマー周期レジスタ６４７ｂは、設定された周期の分だけ時間が経過する毎に、タイムスタンプの値をインクリメントする。例えばタイマーが１６ｂｉｔで設定値０ｘ４とした場合、タイマー１周で６５．５３５ｓのタイムスタンプが付加されることになる。
０ｘ０： タイマー周期１００ｎｓ
０ｘ１： タイマー周期１μｓ
０ｘ２： タイマー周期１０μｓ
０ｘ３： タイマー周期１００μｓ
０ｘ４： タイマー周期１ｍｓ
０ｘ５： タイマー周期１０ｍｓ
０ｘ６： タイマー周期１００ｍｓ
０ｘ７： タイマー周期１ｓ
以下で説明するレジスタにおいて、「イベント（ｎ）ｘｘレジスタ」は、それぞれ登録可能なイベント数ｎ個分だけ存在する。ｎは各イベントを識別するイベント番号となる。

（イベント（ｎ）モード選択レジスタ＜ＥＶ＿ＭＯＤＥ＞６４７ｃ）
イベント（ｎ）モード選択レジスタ６４７ｃは、イベントモードがイネーブルの場合、検知するイベントの種類を選択する。

「ＥＶ＿ＭＯＤＥ」が「０」のときには、レジスタへのアクセスを検知するモード（レジスタアクセス検知モード）である。このとき、下記イベント（ｎ）アドレス登録レジスタ＜ＡＤＤＲ＞６４７ｄ，イベント（ｎ）アドレスマスクレジスタ＜ＡＤＤＲ＿ＭＳＫ＞６４７ｅ，イベント（ｎ）データ登録レジスタ＜ＤＡＴＡ＞６４７ｆ，イベント（ｎ）データマスクレジスタ＜ＤＡＴＡ＿ＭＳＫ＞６４７ｇ，イベント（ｎ）リードライト選択レジスタ＜ＲＷ＞６４７ｈの各レジスタに設定された条件を満たすレジスタアクセスが検知される。

「ＥＶ＿ＭＯＤＥ」が「１」のときには、内部信号を検知するモード（内部信号検知モード）である。このとき、下記イベント（ｎ）割り込み選択レジスタ＜ＩＮＴ＞６４７ｉ，イベント（ｎ）内部信号選択レジスタ＜ＳＩＧ＞６４７ｊ，イベント（ｎ）エッジ選択レジスタ＜ＥＤＧＥ＞６４７ｋの各レジスタに設定された条件を満たす内部信号の変化が検知される。

（イベント（ｎ）アドレス登録レジスタ＜ＡＤＤＲ＞６４７ｄ）
イベント（ｎ）アドレス登録レジスタ６４７ｄは、レジスタアクセス検知モード時に検知する、レジスタアクセスのアドレスを設定する。

（イベント（ｎ）アドレスマスクレジスタ＜ＡＤＤＲ＿ＭＳＫ＞６４７ｅ）
イベント（ｎ）アドレスマスクレジスタ６４７ｅは、レジスタアクセス検知モード時に検知する、レジスタアクセスのアドレスにおいて、各ビットのマスクを設定する。すなわち、「１」と設定されたビットはマスクされ、処理外のビット（Ｄｏｎ'ｔ ｃａｒｅ扱い）になる。
例えばＡＤＤＲ＝０ｘ３２１０７６５４、ＡＤＤＲ＿ＭＳＫ＝０ｘ００００ＦＦＦＦ、と設定された場合、アドレス０ｘ３２１０ｘｘｘｘ（「ｘ」はＤｏｎ'ｔ ｃａｒｅ）へのアクセスが検知条件を満たす。

（イベント（ｎ）データ登録レジスタ＜ＤＡＴＡ＞６４７ｆ）
イベント（ｎ）データ登録レジスタ６４７ｆは、レジスタアクセス検知モード時に検知する、レジスタアクセスのデータを設定する。

（イベント（ｎ）データマスクレジスタ＜ＤＡＴＡ＿ＭＳＫ＞６４７ｇ）
イベント（ｎ）データマスクレジスタ６４７ｇは、レジスタアクセス検知モード時に検知する、レジスタアクセスのデータにおいて、各ビットのマスクを設定する。
例えば、ＤＡＴＡ ＝ ０ｘ３２１０７６５４、ＤＡＴＡ＿ＭＳＫ＝０ｘ００００ＦＦＦＦ、と設定された場合、データ０ｘ３２１０ｘｘｘｘ（ｘはＤｏｎ'ｔ ｃａｒｅ）のアクセスが検知条件を満たす。

（イベント（ｎ）リードライト選択レジスタ＜ＲＷ＞６４７ｈ）
イベント（ｎ）リードライト選択レジスタ６４７ｈは、レジスタアクセス検知モード時に検知する、レジスタアクセスのリード／ライトを選択する。「ＲＷ」が「０」のときには、リードアクセスを検知する。「ＲＷ」が「１」のときには、ライトアクセスを検知する。

（イベント（ｎ）割り込み選択レジスタ＜ＩＮＴ＞６４７ｉ）
イベント（ｎ）割り込み選択レジスタ６４７ｉは、内部信号検知モード時に検知する、割り込み信号を選択する。各ビットは、割り込みコントローラにおける割り込み要因に対応づけてられている。例えば、「ｉｎｔ０」のときには、割り込み要因０の変化が検知される。また、例えば、「ｉｎｔ３１」のときには、割り込み要因３１の変化が検知される。

（イベント（ｎ）内部信号選択レジスタ＜ＳＩＧ＞６４７ｊ）
イベント（ｎ）内部信号選択レジスタ６４７ｊは、内部信号検知モード時に検知する、内部信号を選択する。各ビットは、デバイス実装時に選択された、解析に有用な代表的な内部信号に対応づけられている。例えば画像形成装置の場合、各ＤＭＡＣの起動信号や、各画像転送チャネルの転送制御信号（ＬＳＹＮＣ， ＬＧＡＴＥ， ＦＳＹＮ， ＦＧＡＴＥ）等を割り当てる。例えば、「ｓｉｇ０１」のときには、内部信号０の変化が検知される。また、例えば、「ｓｉｇ３１」のときには内部信号３１の変化が検知される。

（イベント（ｎ）エッジ選択レジスタ＜ＥＤＧＥ＞６４７ｋ）
イベント（ｎ）エッジ選択レジスタ６４７ｋは、内部信号検知モード時に検知する、内部信号のエッジを選択する。「ＥＤＧＥ」が「０」のときには、立下りエッジが検知される。「ＥＤＧＥ」が「１」のときには、立上りエッジが検知される。

［アクセスログのフォーマット］
次に、アクセスログのフォーマットについて、図２４を参照しながら説明する。図２４は、取得可能なアクセスログのフォーマットを示す。

本実施形態では、デバッグモードレジスタ６４７ａの「ｅｖ＿ｅｎ」および「ｔｉｍｅ＿ｅｎ」レジスタの設定値に応じて、図２４に示した４種類のフォーマットＬＦ１、ＬＦ２，ＬＦ３，ＬＦ４でログを取得することが可能である。

（フォーマットＬＦ１）
「ｅｖ＿ｅｎ＝０」，「ｔｉｍｅ＿ｅｎ＝１」の場合、フォーマットＬＦ１でログが取得される。ログサイズは１ログあたり７２ｂｉｔとなる。フォーマットＬＦ１の場合、ノーマルモードで動作するため、レジスタアクセスのアドレスｆ２、データｆ３、リードライトの情報が取得され、さらにタイムスタンプｆ１が付加される。

（フォーマットＬＦ２）
「ｅｖ＿ｅｎ＝０」，「ｔｉｍｅ＿ｅｎ＝０」の場合、フォーマットＬＦ２でログが取得される。ログサイズは１ログあたり５６ｂｉｔとなる。フォーマットＬＦ２の場合、レジスタアクセスのアドレスｆ２、データｆ３が取得される。

（フォーマットＬＦ３）
「ｅｖ＿ｅｎ＝１」，「ｔｉｍｅ＿ｅｎ＝１」の場合、フォーマットＬＦ３でログが取得される。ログサイズは１ログあたり２４ｂｉｔとなる。フォーマットＬＦ３の場合、イベントモードで動作するため検知したイベント番号ｆ４が取得され、さらにタイムスタンプｆ１が付加される。

（フォーマットＬＦ４）
「ｅｖ＿ｅｎ＝１」，「ｔｉｍｅ＿ｅｎ＝０」の場合、ログサイズは１ログあたり８ｂｉｔとなる。フォーマットＬＦ４の場合、イベントモードで動作するため検知したイベント番号ｆ４が取得される。

上記の通り、レジスタ設定により取得するログのフォーマットを変更することが可能である。よって、デバッグの用途に応じて、レジスタアクセスの詳細を観測したい場合にはフォーマットＬＦ１、内部信号を含めてポイントを絞った観測をしたい場合にはフォーマットＬＦ４といった使い分けができる。

また、例えば、フォーマットＬＦ２とフォーマットＬＦ４とを比較すると、イベントモードを使用することで１ログあたりのサイズを８ｂｉｔ／５６ｂｉｔ＝１／７に圧縮することが可能であり、限られた内蔵メモリの容量を効率よく活用することが可能である。

［デバッグ制御部の動作］
次に、デバッグ制御部６１３の動作について、図２５を参照しながら説明する。図２５は、第３実施形態に係るデバッグ制御部の動作を示したシーケンス図である。

イベント登録部６４７は、あらかじめＣＰＵ６２０からのアクセスに対するデバッグ制御部６１３の各制御レジスタ６４８の設定（モード、イベント設定）を行う（ステップＳ１０）。

電子機器を動作させると、ＣＰＵ６２０からデバイス６０１の機能モジュール６０７に対してのレジスタアクセス（ステップＳ１２）や、ＣＰＵ６２０への割り込み（ステップＳ１４）や、（図示しない）内部信号の変化が発生する。

デバッグ制御部６１３は、それらの挙動を監視し、あらかじめ制御レジスタ６４８に設定された特定のイベントを検知するとログデータを作成し、内蔵メモリ６０９に蓄積する（ステップＳ１６）。

動作終了後、ターミナルＰＣ６３０からコマンド操作することで（ステップＳ１８）、内蔵メモリ６０９からログデータが読み出され、ログデータが取得される（ステップＳ２０）。

図示しないが、ログデータの読み出しは、ターミナルＰＣ６３０からではなくソフトウェアによりＣＰＵ６２０から行うことも可能である。

図２６に、イベントモードにてレジスタアクセスを検知する場合のタイミングチャートを示す。図２６では、以下のようにレジスタ設定された場合が想定されている。「ｄｂｇ＿ｅｎ＝１」、「ｅｖ＿ｅｎ＝１」、「ｔｉｍｅ＿ｅｎ＝１」、「ｅｖ＿ｍｏｄｅ＝０」
図２６において、「ｒｅｑ＊」、「ａｃｋ＊」は、イベント検知回路６４１とログ作成回路６４５との間で、イベント検知結果を通知するための信号であり、設定可能なイベント数分だけ存在する。「ｔｉｍｅ」は、タイマーからログ作成回路６４５に通知されるタイムスタンプ情報である。「ｌｏｇ＿ｄａｔａ」は、ログ作成回路６４５にて作成さ、内蔵メモリ６０９に出力されるログデータである。「ｍｅｍ＿ｒｄｙ」は、内蔵メモリ６０９が書き込み可能状態であることを示す信号であり、待機時は「１」、メモリへの書き込み中のみ「０」に設定される。

また、本実施形態においては、イベント設定次第で、同時に複数のイベントを検知する可能性がある。図２６の（Ａ）は、あるタイミングで１つのイベントが検知された場合を示し、図２６の（Ｂ）はあるタイミングで２つのイベントが検知された場合を示す。

（Ａ）１つのイベントが検知された場合
イベント検知回路６４１は、レジスタＩ／Ｆにて「ｃｓ」の立上りを検知すると、Ｔ４のタイミングで「ｒｗ」、「ａｄｄｒ」、「ｄａｔａ」をラッチする。イベント検知回路６４１は、イベント検知条件と比較し、図ではイベント３と一致したためＴ５のタイミングで「ｒｅｑ３」をアサートし、イベント３を検知したことをＣＰＵ６２０に通知する。

ログ作成回路６４５は、「ｍｅｍ＿ｒｄｙ＝１」、つまりメモリ書き込み可能状態であれば、最短のＴ６のタイミングで「ａｃｋ４」をアサートし、イベント３の検知結果を受け取ると同時に、同タイミングでのタイムスタンプ値０ｘ１４３を付加し、「ｌｏｇ＿ｄａｔａ＝０ｘ０１４３＿０３」を内蔵メモリ６０９に書き込む。内蔵メモリ６０９は、ログデータの書き込み開始と同時に「ｍｅｍ＿ｒｄｙ」をネゲートし、書き込みが完了すると（ここでは書き込みに３サイクルかかる場合の例を示している）Ｔ９のタイミングで再び「ｍｅｍ＿ｒｄｙ」をアサートする。

（Ｂ）同時に２つのイベントが検知された場合
同時に複数のイベントが検知された場合、本実施形態では、イベント番号の小さいイベントほど高い優先度で、順番にログデータを作成する。

図２６では、Ｔ１３のタイミングでイベント３，４を同時に検知したため、イベント検知回路６４１はＴ１４のタイミングで「ｒｅｑ３」と「ｒｅｑ４」を同時にアサートする。

ログ作成回路６４５は、優先度の高い順に、まず「ａｃｋ３」をアサートし、「ｌｏｇ＿ｄａｔａ＝０ｘ０１４５＿０３」を内蔵メモリ６０９に書き込む。その間、「ａｃｋ４」はネゲートされたままであり、イベント検知回路６４１は「ｒｅｑ４」をアサートし続ける。

Ｔ１８のタイミングでイベント３のログデータの書き込みが完了すると、Ｔ１９のタイミングで「ａｃｋ４」をアサートし、イベント４の検知結果を受け付ける。

本実施形態によれば、上記のような動作により、同時に複数のイベントを検知した場合でも、発生したイベントを取りこぼすことなく、ログデータを取得することが可能となる。また、上記本実施形態では優先度が固定（イベント番号が小さいほど優先度高）の場合の例であるが、別途レジスタを設けることでイベント番号ごとに優先度を変更できる構成とすることも可能である。例えば、イベント番号の大きいイベントほど高い優先度にしてもよい。

図２７に、イベントモードにて内部信号を検知する場合のタイミングチャートを示す。以下のようにレジスタ設定された場合を想定している。「ｄｂｇ＿ｅｎ＝１」、「ｅｖ＿ｅｎ＝１」、「ｔｉｍｅ＿ｅｎ＝１」、「ｅｖ＿ｍｏｄｅ＝１」
「内部信号ｓｉｇ０の立ち上がり」をイベント番号５として登録した場合の例である。基本的なログ取得の動作は、レジスタアクセス検知時と同じであるが、内部信号検知時は、イベント設定された内部信号の変化を監視して、ログデータが作成される。イベント検知後にログデータを作成しメモリに書き込む機能はレジスタアクセス検知時と共通であるため、図２６に（Ｂ）にて説明した、同時に複数のイベントが発生した場合の対応も同様に可能である。

ＣＰＵ６２０からのアクセスをモニタし、ログデータを取得する場合、アドレス（３２ｂｉｔ）、データ（３２ｂｉｔ）の情報をそのままログデータとして保存するため、ログデータのデータ量が膨大になり、保存に必要な内蔵メモリ６０９の容量が大きくコストがかかる。

これに対して、第３実施形態に係る電子機器用のデバイスによれば、電子機器の障害解析のためにあらかじめログとして取得したいＣＰＵからのレジスタアクセスや内部信号の挙動をイベントとして登録しておき、登録したイベントが発生した場合のみ、イベント番号をログとして保存する。これにより、必要とする内蔵メモリの容量を小さく抑えることができる。

また、第３実施形態に係る電子機器用のデバイスによれば、CPUアクセスだけでなく、デバイスの内部信号の変化もイベントとして検知しログを取得することができる。また、ログにタイムスタンプを付加することで、より詳細な解析ができるようになる。また、イベントが検知されたことを、割り込みによりソフトウェアに通知することができる。また、シリアル通信可能な機器、例えばPCを接続して、ログを取得することができる。解析するタイムレンジに応じて適切な分解能のタイムスタンプをログに付加することで、より詳細な解析ができるようになる。アドレスやデータの一部（例えば上位16bit）のみを比較して、イベント検知することができ、より柔軟な解析ができる。また、同時に複数のイベントが発生した場合でも、全てのイベントのログを取得することができ、より確実な解析ができる。

以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明した。しかしながら、本発明の技術的範囲はかかる例に限定されない。本発明の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属する。

例えば、各ＣＰＵにより実行される各機能を実現するためのプログラムは、はじめから図示しないコンピュータに備えられた図示しないＲＯＭ等の記憶手段に格納されてもよいし、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録され、メモリに記録されたプログラムをコンピュータにインストールして各ＣＰＵに実行させるか、又はＣＰＵにそのメモリからこのプログラムを読み出して実行させてもよい。さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードすることもできる。

１ エンジン制御部
２ コントローラ
３ スキャナ
４ エンジンＡＳＩＣ
５ コントローラＡＳＩＣ
７ メモリ
８ エンジンＣＰＵ
１０ コントローラＣＰＵ
１１ プロッタ
４１３ デバッグ制御部（エンジンＡＳＩＣ側）
４１５ バッファ制御部（エンジンＡＳＩＣ側）
４１８ 内部レジスタ（エンジンＡＳＩＣ側）
４２２ バッファセレクタ（エンジンＡＳＩＣ側）
４２３ デバッグ用バッファ（エンジンＡＳＩＣ側）
５１３ デバッグ制御部（コントローラＡＳＩＣ側）
５１５ バッファ制御部（コントローラＡＳＩＣ側）
５１８ 内部レジスタ（コントローラＡＳＩＣ側）
５２１ バッファセレクタ（コントローラＡＳＩＣ側）
５２２ デバッグ用バッファ（コントローラＡＳＩＣ側）
６００ ターゲット基板
６０１ デバイス
６２０ ＣＰＵ
６４１ イベント検知回路
６４５ ログ作成回路
６４７ イベント登録部
６４９ 制御レジスタ

特開２００３‐２７１４１４号公報 特開２００８‐２８７３１９号公報

Claims (10)

1. データを入出力する入出力装置と、
   前記データを記憶するメモリと、
   前記メモリへの前記データの転送を制御するエンジン制御部と、
   前記入出力装置と前記メモリとの間で前記データの転送を行うコントローラと、を備え、
   前記エンジン制御部は、
   前記データを一時的に蓄積するバッファと、
   デバッグ用のログデータを生成し、前記エンジン制御部内の前記バッファの空き状況及び前記コントローラのデータ転送状況に応じて、前記生成されたログデータを前記バッファへ蓄積するか又は前記コントローラへ転送するデバッグ制御部と、
   を有することを特徴とする電子機器用のデバイス。
2. 前記エンジン制御部は、
   前記データの前記メモリへのダイレクトメモリアクセスを制御するダイレクトメモリアクセスコントローラを更に備え、
   前記ダイレクトメモリアクセスによる前記コントローラへのデータ転送中、前記ログデータを前記バッファへ蓄積することを特徴とする請求項１に記載の電子機器用のデバイス。
3. 前記エンジン制御部は、
   前記生成されたデバッグ用のログデータを一時的に蓄積するためのデバッグ用のログバッファを更に有し、
   前記バッファの空き状況に応じて前記生成されたログデータを前記デバッグ用のログバッファへ蓄積することを特徴とする請求項１又は２に記載の電子機器用のデバイス。
4. 前記デバッグ用のログデータは、
   前記エンジン制御部が有するレジスタへの書込み及び読込みの履歴情報を含むことを特徴とする請求項１〜３のいずれか一項に記載の電子機器用のデバイス。
5. 前記デバッグ用のログデータは、
   前記ダイレクトメモリアクセスコントローラの動作状態の遷移を含むことを特徴とする請求項２に記載の電子機器用のデバイス。
6. 前記デバッグ用のログデータは、
   前記エンジン制御部への割り込み状態の遷移を含むことを特徴とする請求項１〜５のいずれか一項に記載の電子機器用のデバイス。
7. 前記データを一時的に蓄積するバッファは、
   入力するデータを蓄積するための入力用バッファと、出力するデータを蓄積するための出力用バッファとを有し、
   前記ダイレクトメモリアクセスコントローラは、
   前記入力用バッファから前記メモリにデータを書き込む書込み用ダイレクトメモリアクセスコントローラと、前記メモリからデータを読み込み前記出力用バッファに出力する読込み用ダイレクトメモリアクセスコントローラとを有し、
   前記エンジン制御部内の前記入力用バッファの空き状況、前記出力用バッファの空き状況及び前記コントローラのデータ転送状況に応じて、前記生成されたログデータを前記入力用バッファへ蓄積するか、前記出力用バッファへ蓄積するか又は前記コントローラへ転送することを特徴とする請求項２又は５に記載の電子機器用のデバイス。
8. 前記コントローラは、
   前記データの前記メモリへのダイレクトメモリアクセスを制御するコントローラ側のダイレクトメモリアクセスコントローラと、
   前記データを一時的に蓄積するコントローラ側のバッファと、
   前記コントローラ側のバッファの空き状況及び前記コントローラのデータ転送状況の少なくともいずれかを前記エンジン制御部へ通知するデバッグ制御部と、を有し、
   前記エンジン制御部のデバッグ制御部は、
   前記エンジン制御部内の前記バッファの空き状況と、前記コントローラ側のバッファの空き状況と前記コントローラのデータ転送状況に応じて、前記生成されたログデータを前記エンジン制御部側のバッファへ蓄積するか、前記コントローラ側のバッファへ蓄積させるか、又は前記コントローラへ転送することを特徴とする請求項１〜７のいずれか一項に記載の電子機器用のデバイス。
9. 前記デバッグ制御部は、アクセスされるモジュールを有し、
   前記モジュールへのアクセスを分析し、特定のイベントを検知するイベント検知部と、
   前記イベント検知部により検知された特定のイベントに対するログデータを生成するログ生成部と、
   前記イベント検知部により検知される特定のイベントを登録するイベント登録部と、
   を有することを特徴とする請求項１に記載の電子機器用のデバイス。
10. データを入出力する入出力装置と、
    前記データを記憶するメモリと、
    前記メモリへの前記データの転送を制御するエンジン制御部と、
    前記入出力装置と前記メモリとの間で前記データの転送を行うコントローラと、を備え、
    前記エンジン制御部は、
    前記データを一時的に蓄積するバッファと、
    デバッグ用のログデータを生成し、前記エンジン制御部内の前記バッファの空き状況及び前記コントローラのデータ転送状況に応じて、前記生成されたログデータを前記バッファへ蓄積するか又は前記コントローラへ転送するデバッグ制御部と、
    を有する電子機器用のデバイスを備えることを特徴とする画像形成装置。

Images