(57)【要約】      （修正有）【課題】ドライバプログラムの開発工数の削減やバグの混入を予防する。【解決手段】ジェネレータ４０は、ハードウェアブロックを検証するための検証プログラムを解析して特定のパターンを抽出するパーサー４１と、前記パーサー４１の出力に基づいてドライバプログラムを生成するコード生成部４２と、を有する。パーサー４１はハードウェアブロックのアドレス情報であるポートを介してハードウェアブロックにアクセスする制御処理情報をパターンとして抽出する。【選択図】図８
2014229013.tif 000002
【特許請求の範囲】
【請求項１】
ハードウェアブロックを検証するための検証プログラムを解析して特定のパターンを抽出するパーサーと、
前記パーサーの出力に基づいてドライバプログラムを生成するコード生成部と、を有するドライバプログラム作成支援装置。
【請求項２】
前記特定のパターンが、前記検証プログラムで使用されている検証用の制御処理情報であることを特徴とする請求項１に記載のドライバプログラム作成支援装置。
【請求項３】
前記制御処理情報が前記ハードウェアブロックにアクセスする情報であることを特徴とする請求項２に記載のドライバプログラム作成支援装置。
【請求項４】
前記ハードウェアブロックにアクセスする情報には、前記ハードウェアブロックのアドレス情報であるポートが含まれることを特徴とする請求項３に記載のドライバプログラム作成支援装置。
【請求項５】
前記ハードウェアブロックにアクセスする情報には、前記ハードウェアブロックのアドレス情報であるポートを介してアクセスするデータが含まれることを特徴とする請求項３又は４に記載のドライバプログラム作成支援装置。
【請求項６】
前記パーサーは、前記特定のパターンを所定のタグで指定された範囲から抽出することを特徴とする請求項１から５のいずれか１項に記載のドライバプログラム作成支援装置。
【請求項７】
前記パーサーは、前記検証プログラムにおけるコメント部分を抽出し、
前記コード生成部は、抽出したコメント部分に基づいて生成するドライバプログラムにコメントを記載することを特徴とする請求項６に記載のドライバプログラム作成支援装置。
【請求項８】
前記所定のタグは、前記コメント部分に記載されていることを特徴とする請求項７に記載のドライバプログラム作成支援装置。
【請求項９】
前記所定のタグは、前記範囲の開始を示す開始タグ、及び、前記範囲の終了を示す終了タグを含むことを特徴とする請求項６から８のいずれか１項に記載のドライバプログラム作成支援装置。
【請求項１０】
パーサーが、ハードウェアブロックを検証するための検証プログラムを解析して特定のパターンを抽出するステップと、
コード生成部が、前記パーサーの出力に基づいてドライバプログラムを生成するステップと、を含むことを特徴とするドライバプログラム作成支援方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ドライバプログラム作成支援装置及び方法に関し、特に、ドライバプログラムの開発工数の削減やバグの混入を予防する技術に関する。
【背景技術】
【０００２】
システムLSI(Large Scale Integration)の開発・設計においては、シミュレーションにより仮想化されたハードウェア上でソフトウェアプログラムを実行してハードウェアの検証を行うことが行われている（例えば、特許文献１）。このようなプログラムを「検証シナリオ」、「テストベンチ」、或いは、「検証プログラム」と呼ぶ（以下では、「検証プログラム」の呼称に統一する）。なお、検証プログラムは、ハードウェア・シミュレーションするための言語（例えば、SystemVerilogなど）で記述される。
【０００３】
特許文献２には、ハードウェアを検証するシミュレーション上で抽象化されたハードウェアと、仮想化したソフトウェアとを連携させて、一のシステムとして評価及び設計を行うことについて記載がある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来のシステムLSIのドライバソフトウェア開発は、ソフトウェアエンジニアがシステムLSIの仕様書を理解する必要があった。そのため、システムLSIの膨大な量の仕様書を理解するための工数がかかり、ソフト開発工数の増大や制御仕様の誤認識によるソフトウェアバグが混入する場合があるという問題があった。
【０００５】
本発明は、上記実情に鑑みてなされたものであって、ドライバプログラムの開発工数の削減やバグの混入を予防することを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するため、ハードウェアブロックを検証するための検証プログラムを解析して特定のパターンを抽出するパーサーと、前記パーサーの出力に基づいてドライバプログラムを生成するコード生成部と、を有するドライバプログラム作成支援装置を提供する。
【発明の効果】
【０００７】
本発明によれば、ドライバプログラムの開発工数の削減やバグの混入を予防することが可能となる。
【図面の簡単な説明】
【０００８】
【図１】画像形成装置の構成例を示す図である。
【図２】図１のSOC11の内部モジュールの制御フローの一例を示す図である。
【図３】図１の画像形成装置１の層的構成例を示す図である。
【図４】図３のドライバの構成例を示す図である。
【図５】本発明による実施形態が解決する課題に関するソフトウェア実装ミスを説明するための図である。
【図６】検証プログラムの例を示す図である。
【図７】本発明による実施形態に入力される検証プログラムの例を示す図である。
【図８】本発明による実施形態の構成を示すブロック図である。
【図９】本発明による実施形態におけるドライバプログラムの例を示す図である。
【発明を実施するための形態】
【０００９】
以下、本発明を実施形態により詳細に説明する。以下の開示においては、ハードウェアのシミュレーションをするためのシナリオ（テストベンチ。以下、「検証プログラム」と呼ぶ。）からソフトウェアを実行可能な形に変換する。要するに、ハードウェアのシミュレーションをするための検証プログラムから一部を抽出し、抽出した検証プログラムの一部をソフトウェアで実行可能な言語に変換することが特徴になっている。
【００１０】
ハードウェアのシミュレーションをするための検証プログラムから一部を抽出し、抽出した検証プログラムの一部をソフトウェアで実行可能な言語に変換することで、ソフトウェア技術者がシステムLSIの膨大な量の仕様書を完全に理解する必要がなくなる。また、制御仕様の誤認識によるソフトウェアバグのないソフトウェアを生成することが可能になる。よって、システムLSIの膨大な量の仕様書を理解する工数を削減することが可能になり、ソフトウェアバグが混入することを防ぐことができる。
【００１１】
本実施形態においては、プリンタやMFP(Multi-Functional Peripheral)などの画像形成装置に搭載するSOC(System on Chip)上のモジュール（ハードウェア）のドライバプログラムの生成を支援する装置を例示する。しかしながら、生成を支援するドライバプログラムがSOCのものに限定されないことは言うまでもなく、他のLSIのものでもよい。また、SOCを搭載する装置は画像形成装置に限定されない。
【００１２】
以下では、まず、ドライバプログラムがどのようなものであるのか、図１ないし図４を参照しながら説明する。次に、図５を参照してドライバプログラムの実装ミスについて説明する。次に、図６を参照して検証プログラムがどのようなものであるか説明する。次に、図７ないし図９を参照しながら本実施形態について説明する。
【００１３】
図１は、画像形成装置の構成の一例である。なお、以下では、「インターフェース」のことをI/Fと略記することがある。画像形成装置1は、コントローラ部10と、エンジン部20と、操作部30とを含んでなる。エンジン部20は、画像を形成するプロッタと、画像を入力するスキャナを含む。操作部30は、画像形成装置1への操作を指示し、画像形成装置1の状態をユーザが確認できるようなユーザI/Fを備えている。コントローラ部10は、外部I/Fであるネットワークと、USB115を備え、外部のパーソナルコンピュータ（以下、PC）やエンジン部20や操作部30と接続可能に構成されている。
【００１４】
コントローラ部10は、画像形成装置1の制御をするSOC（System on Chip）11と、SOC11内部のCPU111を動作させるプログラム、データを格納してある第1の記憶手段であるROM12と、CPU111のプログラム、データを実行させるための第2の記憶手段であるDDRRAM13と、ネットワークと通信するための物理層であるPHY14を有する。
【００１５】
操作部30は、コントローラ部10からのデータを表示する表示手段であるLCD31と、画像形成装置1の状態を示す表示手段であるLED32と、スイッチの状態を検出するSW33と、LCD31上に取付けられ、タッチパネル情報をコントローラ部10に送付するタッチパネル34を有する。
【００１６】
SOC11は、ROM12又はDDRRAM13上のプログラムを実行し、ROM12又はDDRRAM13上のデータにアクセスするCPU111と、前記ROMのインターフェースであるROM I/F112と、前記DDRのインターフェースであるMEM I/F113と、ネットワークPHY14のI/FであるMAC114と、PCと接続可能なUSB（Device）115と、操作部30のLCD31を制御する制御部であるLCDC116と、操作部30のタッチパネル（TP）34を制御するTP I/F117と、操作部30のSW33、LED32を制御するGIO118と、プロッタとスキャナを接続するPCIeI/F120と、内部バスであるInternal BUS119を含んでなる。
【００１７】
以下SOC11のUSB115、ROM I/F112、MEM I/F113、MAC114、GIO118、TP I/F117、LCDC116、PCIe I/F120のことを「モジュール」とする。
【００１８】
図２に、SOC11内部のモジュールの制御フローの一例を示す。
まず、モジュールを初期化する。初期化するステップは処理A、B、C、Dの４つある。
割込み処理は、図２の割込みハンドラの部分である。
まず、割込みを検知すると割込み処理が開始される。処理Eでは割込み要因を判断するために、割込み状態（Xとする）を検出する。割込み状態Xがa、ｂ、ｃ、ｄに応じた処理をする。
【００１９】
例えば、割込み状態Xがaならば、割り込み処理a1、a2、a3を実行する。
割込み状態Xがbならば、割り込み処理b1、b2、b3を実行する。
割込み状態Xがcならば、割り込み処理c1、c2、c3を実行する。
割込み状態Xがdならば、割り込み処理d1、d2、d3を実行する。
割込み状態Xがa、ｂ、ｃ、d以外ならば、割り込み処理e1、e2、e3を実行する。
【００２０】
割込み処理aはリード処理、割込み処理bはライト処理、割込み処理ｃはリードエラー処理、割込み処理ｄはライトエラー処理、割込み処理eはリード/ライト以外の割込み処理である。
【００２１】
図３に、画像形成装置1の階層（レイヤー）的構造の一例を示す。最下層はハードウェア、ハードウェアの上位層にドライバ、ドライバの上位層にアプリケーションがある。カーネルはアプリケーションからコールされたり、またはドライバアクセスしたりして、画像形成装置1の資源の管理を行う。カーネルはLinux（登録商標）などが使用できる。
【００２２】
ハードウェアはコントローラである。ドライバは図２のモジュール制御フローのことである。ドライバからしかハードウェアをアクセスできない。アプリケーションは直接ハードウェアをアクセスできないので、アプリケーションはドライバを介してハードウェアにアクセスする。
【００２３】
図４にドライバの構成例を示す。図４に例示するドライバプログラムは、モジュールのドライバを登録して、ドライバの機能を有効にする登録ルーチン、モジュールを初期化する初期化ルーチン、アプリからのリード要求を制御するリードルーチン、アプリからのライト要求を制御するライトルーチン、アプリからの詳細な制御をするIOCTLルーチン、ハードウェアからの割込み処理を行う割込み処理ルーチン、アプリからの処理が終了するとドライバを解放するリリースルーチンからなる。
【００２４】
ドライバの初期化ルーチンは、図２のフローの初期化ステップを実装する（図５（Ａ））。しかしながら、ソフトウェア担当者は初期化の順番を間違えて図５（Ｂ）のように実装する場合がある。処理の順番を間違えるとモジュールは正しい動作をしない可能性がある。このように、ソフトウェアバグが発生する。
【００２５】
一方で、SOC開発担当者であるハードウェア担当者は、SOC内部のモジュールの動作が正しく動作するかどうかを、ハードウェアのシミュレーションで予め確認する。確認後、シミュレーションで問題ないことを確認してからSOCチップを作成する。シミュレーションには、モジュール毎に検証プログラムがある（図６参照）。この検証プログラムは、SOCの仕様書に基づいて作成されている。
【００２６】
本実施形態では、SOC開発時にハードウェアの動作確認を行うシミュレーションで使用した検証プログラム（検証シナリオ）の一部からデバイスドライバの一部を生成するので、処理の順番を間違えることなく、制御フローと同じ手順の処理をデバイスドライバに組み込むことができるので、処理の順番を間違えるというソフトウェアバグは発生しない。
【００２７】
図７は、本実施形態に係るジェネレータに入力する検証プログラムの一部である。図７は、図６と同じく、モジュール（GIO）の検証プログラムの一部である。検証プログラムは、ハードウェア・シミュレーションするための言語（例えばSystemVerilogなど）で記述されている。
【００２８】
図７に示されているように、ドライバの初期化ルーチンで必要な箇所はGIO118の初期化部分である。GIO初期化部分を切り出すために、検証プログラムにタグを挿入して切り出す部分を明確にする。
【００２９】
タグは開始と終了の２つからできている。
開始タグは
//<!-- DeviceDriverGen:gio_init begin   -->
で、終了タグは
//<!-- DeviceDriverGen:end    -->
である。
【００３０】
“//”はコメントの意味で、検証プログラム中にタグを挿入してもシミュレーション時にはコメントであるため、無視される。
【００３１】
開始タグと終了タグで範囲を指定できるようになったので、この指定範囲からドライバの初期化ルーチンを別のプログラムであるジェネレータが生成する。
【００３２】
図８に、本実施形態に係るジェネレータの構成を示すブロック図である。図示のジェネレータ40のパーサー41に図７のような検証プログラムが読み込まれる。ジェネレータ40は検証プログラムを解析するパーサー41と、コード生成部42を含んで構成される。ジェネレータ40は、汎用のコンピュータに以下で述べるような機能を実現させるようなソフトウェアプログラムにより提供されたドライバプログラム作成支援装置である。
【００３３】
前記パーサー41は、解析パターン411を記憶している。また、図７のような検証プログラムを解析してタグで指定された範囲と解析パターン411からポートを抽出するポート解析部412と、図７のような検証プログラムを解析してタグで指定された範囲と解析パターン411から変数を抽出する変数解析部413と、図７のような検証プログラムを解析してタグで指定された範囲と解析パターン411からコメントを抽出するコメント解析部414と、図７のような検証プログラムを解析してタグで指定された範囲と解析パターン411からシナリオを抽出するシナリオ解析部415を有する。
【００３４】
コード生成部42は、ポート解析部412から解析したポートを宣言するポート生成部422と、変数解析部413から解析した変数を宣言する変数生成部423と、コメント解析部414から解析したコメントを生成するコメント生成部424と、シナリオ解析部415から解析したシナリオを生成するシナリオ生成部425を有する。
【００３５】
コメント解析部414は、検証プログラムの中のコメントタグを検出する。
コメントタグは開始と終了の２つからなる。
コメント開始タグは
//<!-- DeviceDriverGen:comment  begin-->
で、コメント終了タグは
//<!-- DeviceDriverGen:comment end  -->
である。
【００３６】
コメント生成部424はコメント開始タグとコメント終了タグで指定された範囲のコメントをドライバのコメントとして生成する。
【００３７】
前記パーサー41にはポート解析部412、変数解析部413、シナリオ解析部415で使用する解析パターン411を予め登録しておく。
本実施形態で一例として使用する解析パターン411は
CPUW
である。
検証プログラムで使用されているCPUWは
CPUW（ポート名、変数）；
と記述されている。
CPUW(PA、VA)；
上記例（図７）では、PAがポート、VAが変数である。また、CPU(PA,VA)はシナリオである。
【００３８】
ポート解析部412では、CPUWの文の第1の引数をポートPAと認識する。同様にして、次の解析パターン411を解析して次のポートPB、PC、PDを認識する。
【００３９】
また、変数解析部413では、CPUWの文の第2の引数を変数VAと認識する。同様にして、次の解析パターン411を解析して次の変数VB、VC、VDを認識する。
【００４０】
図９を参照して、コード生成部42が生成するドライバプログラムの例を示す。
ポート生成部422では、ドライバの変数宣言部において、ポートを以下のような宣言文を生成する。
unsigned int PA,PB,PC,PD;
変数生成部423では、ドライバの変数宣言部において、ポートを以下のような宣言文を生成する。
unsigned int VA,VB,VC,VD;
【００４１】
シナリオ解析部415では、解析パターン411で設定されたパターンを解析する。解析パターン411はCPUWなので、以下の４パターンを解析する。
CPUW(PA,VA);
CPUW(PB,VB);
CPUW(PC,VC);
CPUW(PD,VD);
シナリオ生成部425は、シナリオ解析部415で解析したパターンをドライバのレジスタ設定部として生成する。
【００４２】
このようにして、ジェネレータ40で生成されたドライバの初期化ルーチンは図９になる。ソフトウェア担当者は、この初期化ルーチンを使用することで、SOCの仕様書を理解する工数を大幅に削減することが可能になり、制御手順ミスというソフトウェアバグを含まないドライバを作成することができる。
【００４３】
本実施形態では、SOC開発で使用するハードシミュレーション用シナリオの一部からジェネレータを使ってドライバのルーチンを生成したが、本ジェネレータはSOCの評価用のプログラム生成にも使用できる。本実施形態では、SOC開発を例にしたが、SOC開発以外の大規模LSIの開発にも適用できる。
【００４４】
上記開示の実施形態によれば、検証プログラムからドライバプログラムを生成するので、制御手順が間違ったソフトウェアバグを含まないドライバプログラムを生成することができる。また、検証プログラムにおけるハードウェアブロックのアドレス情報からドライバプログラムを生成するので、ソフトウェアバグを含まないドライバプログラムを生成できる。また、検証プログラムにおけるハードウェアブロックのアクセスするデータ情報からドライバプログラムを生成するので、ソフトウェアバグを含まないドライバプログラムを生成できる。また、検証プログラムの指定された範囲からドライバプログラムを生成するので、ソフトウェアバグを含まないドライバプログラムを生成できる。
【００４５】
また、検証プログラムの指定された範囲からコメントを生成するので、可視性が向上したドライバプログラムを生成できる。また、検証プログラムに挿入されたタグはハードウェアの動作検証時、コメントと見なされるので、タグは、ハードウェアの動作検証時に影響を与えることがない。また、開始タグと終了タグで指定された範囲を検証プログラムから抽出するので、ソフトウェアバグを含まないドライバプログラムを生成できる。
【符号の説明】
【００４６】
1    画像形成装置
11    SOC
40    ジェネレータ（ドライバプログラム作成支援装置）
41    パーサー
42    コード生成部
【先行技術文献】
【特許文献】
【００４７】
【特許文献１】特許第４９０９７７２号公報
【特許文献２】特許第５０５６４９３号公報
【図１】
2014229013.tif 000003
【図２】
2014229013.tif 000004
【図３】
2014229013.tif 000005
【図４】
2014229013.tif 000006
【図５】
2014229013.tif 000007
【図６】
2014229013.tif 000008
【図７】
2014229013.tif 000009
【図８】
2014229013.tif 000010
【図９】
2014229013.tif 000011