JP2005182359A - データ処理装置の設計方法及び記録媒体 - Google Patents

データ処理装置の設計方法及び記録媒体 Download PDF

Info

Publication number
JP2005182359A
JP2005182359A JP2003420698A JP2003420698A JP2005182359A JP 2005182359 A JP2005182359 A JP 2005182359A JP 2003420698 A JP2003420698 A JP 2003420698A JP 2003420698 A JP2003420698 A JP 2003420698A JP 2005182359 A JP2005182359 A JP 2005182359A
Authority
JP
Japan
Prior art keywords
bus
function
data
api
access
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2003420698A
Other languages
English (en)
Inventor
Norimasa Otsuki
典正 大槻
Yasuhiko Saito
靖彦 斎藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Renesas Technology Corp
Original Assignee
Renesas Technology Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Renesas Technology Corp filed Critical Renesas Technology Corp
Priority to JP2003420698A priority Critical patent/JP2005182359A/ja
Publication of JP2005182359A publication Critical patent/JP2005182359A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Test And Diagnosis Of Digital Computers (AREA)

Abstract


【課題】 システム性能の評価に際してバスとのデータ送受信に関する機能修正を容易に行なうことができるデータ処理装置の設計方法を提供する。
【解決手段】 バスに接続された複数の回路モジュールを有するデータ処理装置を設計する方法は、回路モジュールで実現すべき機能をモデル化してこれを評価するのに、前記機能をモデル化する評価用プログラム記述においてバスに対するデータ送受信を行なう記述にAPI関数(DataRead、DataWrite)を用い、前記API関数は複数種類のバス仕様に共通化される変数を持つ。API関数は複数のバス仕様で共通化されるから、モデル化された機能を実現する回路モジュールの接続先のバスを変更しても、また、その機能をソフトウェアで実現しても、或いはハードウェアで実現しても、評価用プログラム記述の修正変更を要しない。
【選択図】 図5

Description

本発明はシステムLSIなどのデータ処理装置の設計過程において評価用プログラム記述を用いて行なわれる機能モデルの性能評価に関し、特に、バスとのデータ送受信に関する機能修正に着目した技術に関し、例えばシステム性能評価ツール、IP(知的所有権)モジュールに適用して有効な技術に関する。
機能モデルに対する性能評価という点に関し、特許文献1には、テスト容易化設計による変更が当初の論理設計の仕様を満足しなくなったとき、論理機能の設計変更を一々ハードウェア記述言語のゲートレベルで行なうことの煩雑さを解消するために、論理回路の機能レベルの接続データに対してテスト容易化設計処理を施したときのシステム性能を予め見積もるようにする技術が記載される。
特開2001−14358号公報
本発明はシステムLSIなどのデータ処理装置の設計過程において評価用プログラム記述を用いて行なう機能モデルの性能評価について検討した。これによれば、プロセッサ、複数のバス、IPモジュール、外部メモリなどから構成されるシステムLSIを設計する際、そのシステムで実現すべき機能をハードウェアとソフトウェアの何れで実現するか、ハードウェアで実現する場合はどのバスに接続するか、このときバスマスタかバススレーブの何れの形態でバスに接続すべきかなど、様々な要因を考慮する必要がある。このような要因を考慮して最適なシステムを構成するためには、システム全体の性能を正確に見積もる必要があり、そのためにはハードウェア化する機能をC言語などのプログラム記述でモデル化し、様々なシステム構成のもとでシミュレーションを行なう必要がある。このように、システム全体の性能評価を行うためには、ハードウェア化する機能だけでなく、バスの動作も正確にモデル化する必要がある。このとき、ハードウェア化される機能が接続されるバスや、接続の形態を変更するためには、プログラム記述でモデル化した動作モデルを修正する必要がある。また、メモリに格納されるソフトウェアに対しても、ハードウェア化された機能を呼び出すための記述の追加を行う必要がある。システムの最適化を行うためには、様々なケースでシミュレーションを行う必要があるが、構成を変更する度にモデルやソフトウェアの修正が必要となるのでは、評価効率が著しく低下し、評価コストが著しく高くなることが明らかにされた。特に、バス接続の変更に応じてバスプロトコルをモデル化するのに多くの工数を要することが本発明者によって見出された。
本発明の目的は、システム性能の評価に際してバスとのデータ送受信に関する機能修正を容易に行なうことができるデータ処理装置の設計方法を提供することにある。
本発明の別の目的は、システム性能の評価に際して機能モデルの評価用プログラム記述に対してバス接続の変更を容易化する技術を提供することにある。
本発明の前記並びにその他の目的と新規な特徴は本明細書の記述及び添付図面から明らかになるであろう。
本願において開示される発明のうち代表的なものの概要を簡単に説明すれば下記の通りである。
〔1〕バスに接続された複数の回路モジュールを有するデータ処理装置を設計する方法は、回路モジュールで実現すべき機能をモデル化してこれを評価するのに、前記機能をモデル化する評価用プログラム記述(20)においてバスに対するデータ送受信を行なう記述にAPI関数(Application Program Interface関数)を用い、前記API関数は複数種類のバス仕様に共通化される変数を持つ。
前記API関数は複数のバス仕様で共通化されるから、モデル化された機能を実現する回路モジュールの接続先のバスを変更しても、また、その機能をソフトウェアで実現しても、或いはハードウェアで実現しても、前記評価用プログラム記述を修正変更することを要しない。各バスのプロトコル動作をモデル化したバスアクセス関数をバスの接続先の変更に応じて選択すればよい。
本発明の具体的な形態として、前記API関数が持つ変数は、例えばアクセス先の場所を示すアドレス変数と、アクセス対象情報の所在を示すデータ変数とである。前記API関数は、データリードAPI関数とデータライトAPI関数である。
前記API関数は、モデル化されるべき機能をハードウェアとして実現する場合とソフトウェアとして実現する場合との何れの場合にも用いられる。
API関数による具体的な処理内容を決定するには、前記API関数の各バスのプロトコル動作をモデル化したバスアクセス関数のライブラリ(21)を用いてバスに対するデータ送受信の動作を決定すればよい。前記ライブラリからAPI関数に適用するバスアクセス関数を選択するにはバス接続情報を用いればよい。望ましい形態として、前記バス接続情報はプラグマ(#pragma)やディファイン(#define)のようなコンパイラ指令を用いて前記API関数にリンクされればよい。前記バスアクセス関数は更に、接続されるバス特有の付加情報に関する付加情報変数を有してよい。付加情報変数を用いて指定する情報は例えばバスロックの情報、転送サイズ情報、バースト転送の有無情報などとされる。
〔2〕機能モデルの評価用プログラム記述(所謂ソフトIPモジュールデータ)をコンピュータ読取り可能に記録した記録媒体(30)において、前記機能モデルの評価用プログラム記述はバスに対するデータ送受信を行なう記述に複数種類のバス仕様に共通化されるAPI関数を用いる。このときのソフトIPモジュールのような機能モデルはバスマスタ機能を有するものである。
本発明の具体的な態様として、前記API関数は、アクセス先の場所を示すアドレス変数と、アクセス対象情報の所在を示すデータ変数とを持つ。また、記録媒体は更に複数のバスアクセス関数をコンピュータ読取り可能に記録してあり、前記バスアクセス関数は前記API関数のバスのプロトコル動作をモデル化する関数とされる。
〔3〕複数のバスアクセス関数をコンピュータ読取り可能に記録した記録媒体(30)において、前記バスアクセス関数はAPI関数のバスのプロトコル動作をモデル化する関数であり、前記API関数は機能モデルの評価用プログラム記述においてバスに対するデータ送受信を行なう記述であって複数種類のバス仕様に共通化される。
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば下記の通りである。
すなわち、システム性能の評価に際してバスとのデータ送受信に関する機能修正を容易に行なうことができる。また、システム性能の評価に際して機能モデルの評価用プログラム記述に対してバス接続の変更を容易に行なうことができる。
図1には本発明に係る設計方法によって開発しようとするデータ処理装置の構成が例示される。同図に示されるデータ処理装置はマイクロコンピュータのようなシステムオンチップのシステムLSI(半導体集積回路)を想定する。論理設計の段階においてデータ処理装置は例えばHDL(ハードウェアディスクリプションランゲージ)又はRTL(レジスタトランスファレベル)の設計データによって特定される。シミュレーションによる性能評価ではデータ処理装置の機能は例えばC言語による機能モデル(評価用機能記述プログラム)として記述される。シミュレーションではその評価用機能記述プログラムが実行される。
データ処理装置1は、第1の内部バス(Bus1)2に接続されたCPU(中央処理装置)3、内部メモリ(MEM1)4及び第1のIPモジュール(IP1)5と、第2のバス(Bus2)6に接続された第2のIPモジュール(IP2)7とを有する。第1の内部バス2と第2の内部バス6は第1のバスブリッジ(BBRG1)8を介してインタフェースされる。第2の内部バス6と外部バス(Bus3)9は第2のバスブリッジ(BBRG2)10を介してインタフェースされる。外部バス9には外部メモリ(MEM2)11が接続される。外部メモリ11にはCPU3が実行するプログラムのようなソフトウェア12が格納される。
前記CPU3は図示を省略する命令制御部と演算部を有し、命令制御部が外部メモリ11から命令をフェッチし、フェッチした命令を解読して、演算部の動作を制御する。演算部はその動作制御にしたがって、アドレス演算、データ演算、オペランドアクセスなどを行なって命令を実行する。
IPモジュール5,7はIPモジュールデータを用いて設計される回路モジュールである。IPモジュールデータは、特に制限されないが、所要の回路モジュールを機能的に定義したソフトIPモジュールデータとされ、マスクパターンデータによって回路モジュールを特定するハードIPモジュールデータとは相違される。ソフトIPモジュールデータには、HDLのような機能記述言語でその構成を定義するもの、C言語のような高級言語を用いた性能評価用プログラムによってその機能を特定するものがある。
図2には図1のデータ処理装置で実行したいソフトウェアの例を示す。この例では、main関数から呼び出されるfunc1関数は、変数data0で示される所在のデータを入力とし、変数data1が示す場所に処理結果を格納する機能を、代表的に示している。
図3には図2のソフトウェアが内部メモリ4に格納されているとき、CPU3が内部メモリ4からfunc1関数を読み込んで実行する様子を模式的に示す。要するに図3では、func1関数の機能はCPU3のソフトウェアによって実現されている。
図4には前記func1関数の機能をIPモジュール5によるハードウェアで実現し、このIPモジュール5を第1の内部バス2にバスマスタとして接続したときの構成を例示する。この場合、CPU3が内部メモリ4からプログラムを読み込むのに加え、IPモジュール5もメモリ4に対してアクセスを行う。CPU3が読み込むべきソフトウェアとして残るmain関数では、IPモジュール5に対する動作の起動を行う必要がある。
前記func1関数の機能をハードウェアとして実現するIPモジュール5の動作モデルでは、func1_bodyの機能に加え、データをメモリ4などから読み込むデータ準備処理、func1_bodyが完了したデータをメモリ4などに書き出すデータ格納処理が必要となる。メモリ4などからデータを読み書きすることは、バスアクセスを行うことを意味する。
IPモジュール5を第1の内部バス(Bus1)2ではなく第2の内部バス(Bus2)6に接続した場合は、データ準備処理とデータ格納処理は第2の内部バス(Bus2)6のバスプロトコルに適合することが必要になる。データ準備処理とデータ格納処理を図2のソフトウェア中で個別に記述する場合には、接続するバスの変更に応じてそのバスプロトコルに則してプログラムの記述を変更することが必要になる。本発明では、回路モジュールで実現すべき機能をモデル化する評価用プログラム記述においてバスに対するデータ送受信を行なう記述にAPI関数(データ送受信用API関数)を用いる。後述するように前記データ送受信用API関数は複数種類のバス仕様に共通化される変数を持つ。
図5には関数func1_bodyの実行に必要なデータ送受信にデータ送受信用API関数を適用したソフトウェアの一例が示される。これは図1のソフトウェアに前記データ送受信用API関数を適用した例である。データ準備処理をDataRead()、データ格納処理をDataWrite()として共通化している。DataRead()はデータリードAPI関数であり、DataWrite()はデータライトAPI関数であり、夫々データ送受信用API関数の一例とされる。この例では、関数の引数若しくは変数としてデータアクセス先の場所を示すアドレス変数としてのaddrと、データ送受用の領域即ちアクセス対象情報の所在を示すデータ変数としてのdataを与えている。
前記データ送受信用API関数に対しては各バスのプロトコル動作をモデル化したバスアクセス関数のライブラリを用いてバスに対するデータ送受信の動作を決定することになる。
図6は第1の内部バス(Bus1)2のバスアクセス関数を共通API化した関数を示す。バスアクセス関数は、データリードAPI関数DataRead()及びデータライトAPI関数DataWrite()のバスプロトコルを具体的に示す。この例では、第1の内部バス(Bus1)2はコマンド(変数READで示される)、アドレス(変数addrで示される)、データ(変数dataで示される)を逐次的に送受するバスを代表する。例えばバスに対するアクセスリクエストを出した後、アクノリッジが返されるのを待ってアドレスを出力し、これに対するアクノリッジを待ってバスからデータをリードし、或いはバスにライトデータを出力する。尚、図においてAddr,Dataはデータ型、addr,*dataは変数を意味する。
図7には第2の内部バス(Bus2)6のバスアクセス関数を共通API化した関数を示す。この例では、第2の内部バス(Bus2)6はコマンド、アドレス、データをパケットとして一括送信する、所謂スプリットトランザクションバスを代表する。例えばスプリットトランザクションバスではコマンドなどを含むパケットを送信した後、レスポンスを待つ。
図5のソフトウェアにおいて、データ送受信用API関数(DataRead()、DataWrite())として第1の内部バス(Bus1)2に対しては図6のバスアクセス関数を呼び、第2の内部バス(Bus2)6に対しては図7のバスアクセス関数を呼んで利用するようにすればよい。このように、IPモジュールを接続するバスの仕様に応じた共通API化されたバスアクセス関数を呼ぶことで、図5に例示されるようなソフトウェアそれ自体の記述を変更する必要はない。
図8は図3のようにfunc1()の機能をCPU3のソフトウェアで実現する際のバスアクセス関数が例示される。この例では、メモリアドレス(変数addrで示される)に対してデータサイズ分のデータを読み出してデータ領域(変数dataで示される)を先頭とする領域にロードされる。また、データ領域(変数dataで示される)を先頭とするデータサイズ分の領域のデータをメモリアドレス(変数addrで示される)からデータサイズ分のメモリアドレスにストアする。このように、func1()をIPモジュールによってハードウェア化せずにソフトウェアとして残した場合も、このバスアクセス関数を用いればよいため、図5に例示されるようなソフトウェアそれ自体の記述を変更する必要はない。このように前記データ送受信用API関数は、モデル化されるべき機能をハードウェアとして実現する場合とソフトウェアとして実現する場合との何れの場合にも用いることができる。
func1の機能をIPモジュールのようなハードウェアで実現するかCPUの実行プログラムのようなソフトウェアで実現するかの選択、ハードウェア化した際にIPモジュールを接続するバスの選択などは、図9のように#pragmaのようなコンパイラ指令によってコンパイラに指示を与えることで実現できる。図10のように#defineによる実行ルーチンの切り替え、ライブラリ差替えによる実現も可能である。また、バスの種類によっては転送サイズ、バスロック情報、バースト転送などの機能を有する。これら付加情報も#pragmaや#defineで指定可能である。
図11には図3のfunc1をIPモジュール5を用いてハードウェアで実現し、第1の内部バス(Bus1)2にバススレーブとして接続した際のシステム構成図を例示する。図4ではIPモジュール5をバスマスタモジュールとして説明したが、バススレーブモジュールであるIPモジュール5は自分で能動的にバスアクセスを行うことができないため、CPU3は内部メモリ(MEM1)4からのプログラム読込みに加え、IPモジュール5内のバッファに対してデータ送受処理を行う必要がある。すなわち、データ準備処理、データ格納処理を含むfunc1()はソフトウェアとして実現し、IPモジュール5の動作モデルは、func1_bodyの機能を備える。データ準備処理、データ格納処理はソフトウェアとして実現されるため、図8のソフトウェア用の共通APIであるバスアクセス関数を用いればよい。したがって、ある機能をハードウェアとして実現する際、バスマスタモジュールであればデータ準備処理、データ格納処理、func1_bodyを含むfunc1を当該ハードウェアの動作モデルとして利用し、バススレーブモジュールとして実現する際はfunc1_bodyのみを当該ハードウェアの動作モデルとして利用する。動作モデルは、開発すべきデータ処理装置の評価用プログラムとしてシミュレーションに供され、システム性能の見積りに利用される。
図12はシステム性能見積もり装置の構成図である。評価用プログラム記述としてのソフトウェア20は、開発対象のシステムで実行すべき機能を記述したもので、データ送受信に関してはデータ送受信用API関数を用いたソフトウェアであり、図5に代表されるようなソフトウェアを意味する。バス関数ライブラリ21は前記データ送受信用API関数の各バスのプロトコル動作をモデル化したバスアクセス関数として、図6乃至図8に代表されるバスアクセス関数を保有する。IPバス接続情報22はデータ送受信に利用するバスを指定する情報である。
IPモデル生成装置23は、データ処理装置で実行するソフトウェア20と、各種バスへのアクセス関数であるバス関数ライブラリ21を入力とし、ハードウェア化する関数と接続されるバス、接続形態を指定することで、バス接続動作が可能なIPモジュールの動作モデル24を生成する。
ソフトウェア変換装置25は、同じくソフトウェア20とバス関数ライブラリ21を入力とし、ハードウェア化する関数と接続されるバス、接続形態を指定することで、ソフトウェアからハードウェア化する関数を除去し、ハードウェアとして実現されたIP動作モデルと通信するためのバスアクセス関数を挿入し、変換済ソフトウェア26を生成する。ハードウェア化する関数がバスマスタ機能を有する場合には前記バスアクセス関数は変換済みソフトウェアが保有せずIPモジュールの動作モデルが保有することになる。
システムシミュレーション装置27は、CPU3やバスブリッジ8,10、メモリ4等のシステムLSIの基本となるモジュールの動作モデル(基本モジュール動作モデル28)と、IP動作モデル24、変換済みソフトウェア26を用いて、システム全体のシミュレーションを行うことで、システム性能を見積もる。
以上説明したデータ処理装置の設計方法によれば、ハードウェア化する可能性のある機能のモデル化を行う際に、バスに対してデータ送受信を行う箇所を上記データ送受信用API関数を用いて記述しておくことで、パラメータ設定を行うだけでシステム構成を変更することが可能となる。このため、モデル修正工数を削減することができる。したがって、変更箇所が少ないことによる変更工数の低減、及びバグ混入率の低下に役立つ。要するに、IPモジュールの動作モデルを修正する工数、ソフトウェアの修正工数が低減されるためシステム性能の評価を効率的に行なうことができる。
また、ハードウェア/ソフトウェア分割試行の工数削減につながるため、ハードウェア/ソフトウェア協調設計、要するに、特定機能をハードウェアで実現する場合とソフトウェアで実現する場合の利害得失を考慮して何れを採用すべきかを判断する設計工程に好適である。
また、データ送受信用API関数が統一されているため再利用性が高く、他製品への展開が容易となる。システム構成の変更工数低減、モデル修正時のバグ混入の防止、API関数共通化によるモデル再利用性の向上、早期システム性能評価により設計手戻りの削減、及びシステム構成最適化による製品価値の向上を実現することができる。
次に、上記データ処理装置の開発に用いるIPモジュールデータ及びバスアクセス関数ライブラリの提供について説明する。上記IPモジュールデータ及びバスアクセス関数ライブラリは半導体集積回路の製造メーカが独自に開発して用意することも可能であるが、上記開発方法に好適なIPモジュールデータ及びバスアクセス関数ライブラリが流通され、容易に入手することができれば、上記方法による半導体集積回路の設計を更に能率化することができる。ここで言うIPモジュールデータとは、IPモジュールの機能をソフトウェアによってモデル化するものであり、C言語のような高級言語を用いた評価用プログラム記述によってその機能を特定するものとされる。
図13にはコンピュータ読取り可能な記録媒体が示される。同図に示される記録媒体30はリームーバブルな記録媒体とされ、例えば、磁気テープ、フレキシブルディスク、ハードディスク、CD−ROM、MO(マグネット・オプチカル・ディスク)などとされ、ここに、IPモジュールデータ及びバスアクセス関数ライブラリがエンジニアリングワークステーションなどのコンピュータ装置31によって読取り可能に記録されている。記録媒体30から読み込まれたIPモジュールデータ及びバスアクセス関数ライブラリは固定ディスク装置32にストアされ、コンピュータ装置31を利用してシステム開発が行なわれるときはIPモジュールデータ及びバスアクセス関数ライブラリはコンピュータ装置31のメモリに読み込まれて使用される。IPモジュールデータによって特定される機能モデルにバスマスタ機能が含まれている場合には、機能モデルの評価用プログラム記述としてのIPモジュールデータはバスに対するデータ送受信を行なう記述に複数種類のバス仕様に共通化される前記データ送受信用API関数を用いている。
図14には設計データなどを記録した記録媒体30とコンピュータ装置31との別の関係が例示される。記録媒体30はIPモジュールデータ及びバスアクセス関数ライブラリの提供に供されるサーバ33に保持されている。サーバ33はインタネットなどのネットワーク36を介してエンジニアリングワークステーションなどのコンピュータ装置31に接続される。記録媒体30に格納されているIPモジュールデータ及びバスアクセス関数ライブラリはネットワーク36を介してコンピュータ装置31にダウンロードされる。ダウンロードされた設計データはコンピュータ装置31のローカルなハードディスク或はメモリなどにストアされて、システムの開発に用いられる。
以上本発明者によってなされた発明を実施形態に基づいて具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは言うまでもない。
例えば、本発明マイクロコンピュータ以外の種種のデータ処理用半導体集積回路やその他データ処理装置の開発に広く適用することが可能である。機能モデルの評価用プログラム記述としてのIPモジュールデータの記述言語はC言語に限定されずそのJava(登録商標)などのその他の高級言語であってもよい。
本発明に係る設計方法によって設計しようとするデータ処理装置の構成を例示するブロック図である。 図1のデータ処理装置で実行するソフトウェアを例を示す説明図である。 CPUが内部メモリから図2のソフトウェアのfunc1関数を読み込んで実行する様子を模式的に示す説明図である。 func1関数の機能をIPモジュールによるハードウェアで実現し当該IPモジュールを第1の内部バスにバスマスタとして接続したときの構成を例示する説明図である。 API関数を共通化したソフトウェアの一例がを示す説明図である。 第1の内部バスのバスアクセス関数を共通API化した例を示す説明図である。 第2内の部バスのバスアクセス関数を共通API化した例を示す説明図である。 図3のようにfunc1()の機能をCPUのソフトウェアで実現する際のバスアクセス関数の例を示す説明図である。 バスプロトコルを#pragmaのようなコンパイラ指令によってコンパイラに指示を与える場合の記述例を示す説明図である。 バスプロトコルを#defineによる実行ルーチンの切り替え又はライブラリ差替えによって指示する場合の記述例を示す説明図である。 図3のfunc1をハードウェアIP1として実現し第1の内部バスにバススレーブとして接続する場合の構成を示す説明図である。 開発すべきデータ処理システムの性能を見積もる装置の構成を例示する説明図である。 記録媒体とコンピュータ装置との代表的な関係を例示する説明図である。 記録媒体とコンピュータ装置との別の関係を例示する説明図である。
符号の説明
1 データ処理装置
2 第1の内部バス
3 CPU
4 内部メモリ
5 IPモジュール
6 第2の内部バス
7 IPモジュール
9 外部バス
11 外部メモリ
20 ソフトウェア
21 バス関数ライブラリ
22 IPバス接続情報
23 IPモデル生成装置
24 IP動作モデル
25 ソフトウェア変換装置
26 変換済みソフトウェア
27 システムシミュレーション装置
28 基本モジュール動作モデル
30 記録媒体
31 コンピュータ装置

Claims (12)

  1. バスに接続された複数の回路モジュールを有するデータ処理装置を設計する方法であって、回路モジュールで実現すべき機能をモデル化してこれを評価するのに、前記機能をモデル化する評価用プログラム記述においてバスに対するデータ送受信を行なう記述にAPI関数を用い、前記API関数は複数種類のバス仕様に共通化される変数を持つことを特徴とするデータ処理装置の設計方法。
  2. 前記API関数が持つ変数は、アクセス先の場所を示すアドレス変数と、アクセス対象情報の所在を示すデータ変数とであることを特徴とする請求項1記載のデータ処理装置の設計方法。
  3. 前記API関数は、データリードAPI関数とデータライトAPI関数であることを特徴とする請求項2記載のデータ処理装置の設計方法。
  4. 前記API関数は、モデル化されるべき機能をハードウェアとして実現する場合とソフトウェアとして実現する場合との何れの場合にも用いられることを特徴とする請求項1記載のデータ処理装置の設計方法。
  5. 前記API関数の各バスのプロトコル動作をモデル化したバスアクセス関数のライブラリを用いてバスに対するデータ送受信の動作を決定することを特徴とする請求項4記載のデータ処理装置の設計方法。
  6. 前記バスアクセス関数は更に、接続されるバス特有の付加情報に関する付加情報変数を有することを特徴とする請求項5記載のデータ処理装置の設計方法。
  7. バス接続情報を用いて、前記ライブラリからAPI関数に適用するバスアクセス関数を選択することを特徴とする請求項5記載のデータ処理装置の設計方法。
  8. 前記バス接続情報はコンパイラ指令を用いて前記API関数にリンクされることを特徴とする請求項7記載のデータ処理装置の設計方法。
  9. 機能モデルの評価用プログラム記述をコンピュータ読取り可能に記録した記録媒体であって、前記機能モデルの評価用プログラム記述はバスに対するデータ送受信を行なう記述に複数種類のバス仕様に共通化されるAPI関数を用いることを特徴とする記録媒体。
  10. 前記API関数は、アクセス先の場所を示すアドレス変数と、アクセス対象情報の所在を示すデータ変数とを持つことを特徴とする請求項9記載の記録媒体。
  11. 更に複数のバスアクセス関数をコンピュータ読取り可能に記録してあり、前記バスアクセス関数は前記API関数のバスのプロトコル動作をモデル化する関数であることを特徴とする請求項10記載の記録媒体。
  12. 複数のバスアクセス関数をコンピュータ読取り可能に記録した記録媒体であって、前記バスアクセス関数はAPI関数のバスのプロトコル動作をモデル化する関数であり、前記API関数は機能モデルの評価用プログラム記述においてバスに対するデータ送受信を行なう記述であって複数種類のバス仕様に共通化されることを特徴とする記録媒体。
JP2003420698A 2003-12-18 2003-12-18 データ処理装置の設計方法及び記録媒体 Pending JP2005182359A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2003420698A JP2005182359A (ja) 2003-12-18 2003-12-18 データ処理装置の設計方法及び記録媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2003420698A JP2005182359A (ja) 2003-12-18 2003-12-18 データ処理装置の設計方法及び記録媒体

Publications (1)

Publication Number Publication Date
JP2005182359A true JP2005182359A (ja) 2005-07-07

Family

ID=34782152

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003420698A Pending JP2005182359A (ja) 2003-12-18 2003-12-18 データ処理装置の設計方法及び記録媒体

Country Status (1)

Country Link
JP (1) JP2005182359A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007286671A (ja) * 2006-04-12 2007-11-01 Fujitsu Ltd ソフトウェア/ハードウェア分割プログラム、および分割方法。
JP2009026113A (ja) * 2007-07-20 2009-02-05 Fujitsu Microelectronics Ltd シミュレーション装置及びプログラム
JP2010231633A (ja) * 2009-03-27 2010-10-14 Fujitsu Ltd 検証支援プログラム、検証支援装置および検証支援方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007286671A (ja) * 2006-04-12 2007-11-01 Fujitsu Ltd ソフトウェア/ハードウェア分割プログラム、および分割方法。
US7908592B2 (en) 2006-04-12 2011-03-15 Fujitsu Semiconductor Limited Software/hardware partitioning program and method
JP2009026113A (ja) * 2007-07-20 2009-02-05 Fujitsu Microelectronics Ltd シミュレーション装置及びプログラム
JP2010231633A (ja) * 2009-03-27 2010-10-14 Fujitsu Ltd 検証支援プログラム、検証支援装置および検証支援方法

Similar Documents

Publication Publication Date Title
US7036114B2 (en) Method and apparatus for cycle-based computation
JP4564110B2 (ja) 二重プロセッサ回路の動作をシミュレーションするためのコンピュータ実行方法及び信号プロセッサシミュレータ
EP1966730A2 (en) System and method for generating a plurality of models at different levels of abstraction from a single master model
JP2002259157A (ja) 回路内エミュレーション装置及びそのチップ設計方法、及び回路内エミュレーションシステム
US20120029900A1 (en) Simulation method and system for simulating a multi-core hardware platform
JP2006285333A (ja) 動作合成装置及び方法
EP3532936B1 (en) Debugging system and method
JP2008140405A (ja) 電子回路と制御プログラムとのコバリデーション方法
Darringer et al. Early analysis tools for system-on-a-chip design
US20070271080A1 (en) Model generation method for software/hardware collaboration design
US10409935B2 (en) Modeling a bus for a system design incorporating one or more programmable processors
JP2008282308A (ja) 協調検証装置、協調検証方法、協調検証プログラム
JP2007310565A (ja) システムlsi検証装置及びシステムlsi検証プログラム
JP2005182359A (ja) データ処理装置の設計方法及び記録媒体
US20050071145A1 (en) Simulation apparatus, simulation program, and recording medium
Maillet-Contoz et al. Transaction Level Modeling: An Abstraction Beyond RTL
JP2004310568A (ja) シミュレータ装置、シミュレーション方法および性能解析方法
JP2000259445A (ja) ソフトウェア/ハードウェア協調シミュレーション方法
JP2007164596A (ja) 設計システムおよび設計方法
JP2004013227A (ja) シミュレーション装置並びにシミュレーションモデル生成プログラム
JP2006011840A (ja) 組み込みシステム
JP3214459B2 (ja) シミュレーション方法及び装置
JP2007156728A (ja) 論理検証方法及び論理検証システム
JP2011145880A (ja) 半導体集積回路の論理検証にて使用するテストタスクの生成方法
US20050108501A1 (en) Systems and methods for identifying unending transactions

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20061207

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090327

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090414

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090901