JP2006505057A - 制御データフローグラフ表現を区分化するためのシステムおよび方法 - Google Patents
制御データフローグラフ表現を区分化するためのシステムおよび方法 Download PDFInfo
- Publication number
- JP2006505057A JP2006505057A JP2004549997A JP2004549997A JP2006505057A JP 2006505057 A JP2006505057 A JP 2006505057A JP 2004549997 A JP2004549997 A JP 2004549997A JP 2004549997 A JP2004549997 A JP 2004549997A JP 2006505057 A JP2006505057 A JP 2006505057A
- Authority
- JP
- Japan
- Prior art keywords
- data flow
- cfg
- code
- flow graph
- dfg
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Devices For Executing Special Programs (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
この発明の一実施例は、制御フローグラフ表現(202)を、再構成可能ハードウェア部分(210)と命令プロセッサ部分(208)とに区分化するためのシステム(100)を含む。この発明の別の実施例は、制御データフローグラフ表現(202)を区分化する方法を含み、この方法は、上記制御データフローグラフを2つ以上の区分ブロック(210)に分割するステップと、再構成可能ロジック対命令プロセッサコード(206)としての上記区分ブロックのうちの少なくとも1つについての推定性能を比較するステップと、上記比較するステップに基づいて上記区分ブロックのうちの上記少なくとも1つを再構成可能ハードウェア(210)または命令プロセッサ(208)に割当てるステップとを含む。
Description
著作権表示/許可
この特許文献の開示の一部には、著作権保護の対象となる資料が含まれる。著作権所有者は、米国特許商標局の特許ファイルまたは特許記録に現われるように、特許開示の特許文献の何人による複製にも異議を唱えないが、それ以外ではいかなるすべての著作権を保有する。以下の表示は、適用可能であれは図面を含む以下に記載のソフトウェアおよびデータに適用される。(C)2002 エス・アール・シィ・コンピューターズ・インコーポレイテッド(SRC Computers, Inc.)
発明の背景
発明の分野
本発明は一般的に、高級言語プログラムをハイブリッドの再構成可能なハードウェア命令プロセッサの計算環境で動作するように適合させることに関する。より特定的に、本発明は、高級言語プログラムをハイブリッドの再構成可能なハードウェア命令プロセッサコンピュータで実行することのできる統一された実行可能要素に変換することに関する。
この特許文献の開示の一部には、著作権保護の対象となる資料が含まれる。著作権所有者は、米国特許商標局の特許ファイルまたは特許記録に現われるように、特許開示の特許文献の何人による複製にも異議を唱えないが、それ以外ではいかなるすべての著作権を保有する。以下の表示は、適用可能であれは図面を含む以下に記載のソフトウェアおよびデータに適用される。(C)2002 エス・アール・シィ・コンピューターズ・インコーポレイテッド(SRC Computers, Inc.)
発明の背景
発明の分野
本発明は一般的に、高級言語プログラムをハイブリッドの再構成可能なハードウェア命令プロセッサの計算環境で動作するように適合させることに関する。より特定的に、本発明は、高級言語プログラムをハイブリッドの再構成可能なハードウェア命令プロセッサコンピュータで実行することのできる統一された実行可能要素に変換することに関する。
背景
命令プロセッサが処理能力を急速に向上させ続ける中で、命令プロセッサはかつてスーパーコンピュータのみによって行なわれていたコンピュータを多用する計算を行なうために用いられることが多くなった。しかしながら、たとえば、現代の命令プロセッサで行なうにはまだ実用的でない、数値計算のイメージ処理および流体力学的なシミュレーションを含むコンピュータを多用するタスクが存在する。
命令プロセッサが処理能力を急速に向上させ続ける中で、命令プロセッサはかつてスーパーコンピュータのみによって行なわれていたコンピュータを多用する計算を行なうために用いられることが多くなった。しかしながら、たとえば、現代の命令プロセッサで行なうにはまだ実用的でない、数値計算のイメージ処理および流体力学的なシミュレーションを含むコンピュータを多用するタスクが存在する。
再構成可能な計算は、計算技術において関心の高まっている技術である。従来の汎用計算は、1つ以上の汎用プロセッサで順次実行されるコンピュータコードを特徴とする。再構成可能な計算は、フィールド・プログラマブル・ゲートアレイ(FPGA)等の再構成可能なハードウェアを論理ルーチンを実行するようにプログラムすることを特徴とする。
再構成可能な計算によって、コンピュータを多用する処理において著しい性能の進歩がもたらされる。たとえば、再構成可能なハードウェアは、従来の命令プロセッサと比較して高い並列性およびパイプライン化の特性を有する論理構成でプログラムされ得る。さらに、再構成可能なハードウェアは、プログラムによって割当てられたタスクを実行するのに非常に効率的なカスタム論理構成でプログラムされ得る。さらに、プログラムの処理要求を命令プロセッサおよび再構成可能なハードウェア間で分割することによって、コンピュータの全体的な処理能力が向上し得る。
汎用プロセッサおよび再構成可能なハードウェアの双方を含むハイブリッド計算プラットフォームが開発された。例示のハイブリッド計算プラットフォームは、米国、コロラド州、コロラドスプリングズ(Colorado Springs)のSRCコンピュータ株式会社(SRC Computers, Inc.)から市販されているSRC−6Eである。このSRC−6Eシステムアーキテクチャは、標準のオペレーティングシステム、たとえばリナックス(Linux)(登録商標)を実行する多数の汎用命令プロセッサを含む。汎用命令プロセッサに取付けられているのは、特別に構成された多重適応プロセッサ(MAP)である。
再構成可能な計算を用いることを望み得るユーザにとっての重要な障害要素は、再構成
可能なハードウェアをプログラムすることが困難であるという問題がある。再構成可能なハードウェアをプログラムする従来の方法には、ハードウェア記述言語(HDL)、すなわちデジタル回路の専門技術およびタイミングの明示的処理を必要とする低級言語の使用が含まれた。したがって、高級言語で書かれたプログラムを受入れ、かつこれを、元のプログラムに最小限の修正を行なうだけでハイブリッドで再構成可能なハードウェア命令プロセッサコンピュータで実行することのできるコードに変換できるプロセスが必要である。
可能なハードウェアをプログラムすることが困難であるという問題がある。再構成可能なハードウェアをプログラムする従来の方法には、ハードウェア記述言語(HDL)、すなわちデジタル回路の専門技術およびタイミングの明示的処理を必要とする低級言語の使用が含まれた。したがって、高級言語で書かれたプログラムを受入れ、かつこれを、元のプログラムに最小限の修正を行なうだけでハイブリッドで再構成可能なハードウェア命令プロセッサコンピュータで実行することのできるコードに変換できるプロセスが必要である。
概要
本発明の一実施例は、高級言語ソフトコードを統一された実行可能要素に変換する方法を含み、上記方法は、高級言語ソースコードの再構成可能なハードウェア部分からオブジェクトファイルを生成するステップと、オブジェクトファイルを統一された実行可能な要素に統合するステップとを含む。
本発明の一実施例は、高級言語ソフトコードを統一された実行可能要素に変換する方法を含み、上記方法は、高級言語ソースコードの再構成可能なハードウェア部分からオブジェクトファイルを生成するステップと、オブジェクトファイルを統一された実行可能な要素に統合するステップとを含む。
本発明の別の実施例は、統一された実行可能要素を形成する方法を含み、上記方法は、高級言語プログラムを制御フローグラフ表現に変換するステップと、制御フローグラフ表現を制御データフローグラフ表現に変換するステップと、制御データフローグラフを命令プロセッサ部分および再構成可能なハードウェア部分に区分化するステップと、制御データフローグラフの再構成可能なハードウェア部分をハードウェア定義言語部分に、および命令プロセッサ部分を命令プロセッサオブジェクトファイルに変換するステップと、ハードウェア定義言語部分を再構成可能なハードウェアビットストリームに変換するステップと、再構成可能なハードウェアビットストリームを命令プロセッサが読むことのできるビットストリームオブジェクトファイルに変換するステップと、ビットストリームオブジェクトファイルを命令プロセッサオブジェクトファイルと統合して、統一された実行可能要素を形成するステップとを含む。
本発明の別の実施例は、制御データフローグラフ表現を、再構成可能なハードウェア部分および命令プロセッサ部分に区分化するための区分化部を含む統一された実行可能要素を形成するためのシステムを含む。
本発明の別の実施例は、ハイブリッドの再構成可能なハードウェア命令プロセッサコンピュータで実行可能な統一された実行可能要素を形成するためのシステムを含み、上記システムは、高級言語を制御フローグラフ表現に変換するための高級言語コンバータと、制御フローグラフ表現を制御データフローグラフ表現に変換するための制御フローグラフから制御データフローグラフへのコンバータと、制御データフローグラフ表現を、再構成可能なハードウェア部分および命令プロセッサ部分に区分化するための区分化部と、制御データフローグラフ表現の再構成可能なハードウェア部分をハードウェア定義言語ファイルに変換するための制御データフローグラフからハードウェア定義言語へのコンバータと、ハードウェア定義言語ファイルをビットストリームファイルに変換するためのハードウェア定義言語からビットストリームへのコンバータと、ビットストリームファイルをビットストリームオブジェクトファイルに変換するためのビットストリームからオブジェクトファイルへのコンバータと、ビットストリームオブジェクトファイルを統一された実行可能要素に統合するためのリンカとを含む。
本発明の別の実施例は、コンピュータプログラム製品を含み、上記コンピュータプログラム製品は、統一された実行可能要素を形成させるために組み入れられたコンピュータ読取可能プログラムコードを有するコンピュータ利用可能媒体を含み、上記コンピュータ読取可能プログラムコードは、コンピュータに高級言語ソースコードを制御フローグラフ表現に変換させるためのコンピュータ読取可能プログラムコード、コンピュータに制御フロ
ーグラフ表現を制御データフローグラフ表現に変換させるためのコンピュータ読取可能プログラムコード、コンピュータに制御データフローグラフを命令プロセッサ部分および再構成可能なハードウェア部分に区分化させるためのコンピュータ読取可能プログラムコード、コンピュータに制御データフローグラフの再構成可能なハードウェア部分をハードウェア定義言語部分に、および命令プロセッサ部分を命令プロセッサオブジェクトファイルに変換させるためのコンピュータ読取可能プログラムコード、コンピュータにハードウェア定義言語部分を再構成可能なハードウェアビットストリームに変換させるためのコンピュータ読取可能プログラムコード、コンピュータに再構成可能なビットストリームを命令プロセッサが読むことのできるビットストリームオブジェクトファイルに変換させるためのコンピュータ読取可能プログラムコード、およびコンピュータにビットストリームオブジェクトファイルを命令プロセッサオブジェクトファイルと統合して、統一された実行可能要素を形成させるためのコンピュータ読取可能プログラムコードとを含む。
ーグラフ表現を制御データフローグラフ表現に変換させるためのコンピュータ読取可能プログラムコード、コンピュータに制御データフローグラフを命令プロセッサ部分および再構成可能なハードウェア部分に区分化させるためのコンピュータ読取可能プログラムコード、コンピュータに制御データフローグラフの再構成可能なハードウェア部分をハードウェア定義言語部分に、および命令プロセッサ部分を命令プロセッサオブジェクトファイルに変換させるためのコンピュータ読取可能プログラムコード、コンピュータにハードウェア定義言語部分を再構成可能なハードウェアビットストリームに変換させるためのコンピュータ読取可能プログラムコード、コンピュータに再構成可能なビットストリームを命令プロセッサが読むことのできるビットストリームオブジェクトファイルに変換させるためのコンピュータ読取可能プログラムコード、およびコンピュータにビットストリームオブジェクトファイルを命令プロセッサオブジェクトファイルと統合して、統一された実行可能要素を形成させるためのコンピュータ読取可能プログラムコードとを含む。
さらに新しい特徴は、部分的には以下に続く説明で述べられ、部分的には以下の明細書を検討すれば当業者にとって明らかになり、または本発明を実施することによって知ることができる。本発明の特徴および利点は、別掲の特許請求の範囲で特に指摘される手段、組合せ、および方法によって実現され、達成され得る。
詳細な説明
システムの概観
ここで図1を参照すると、高級プログラミング言語で書かれたプログラムを、統一された実行可能要素に変換するためのハイブリッドの再構成可能なハードウェア命令プロセッサシステム100の実施例が示されている。一実施例において、システム100の再構成可能なハードウェア部分は、多重適応プロセッサ(MAP)を含み得、これはフィールド・プログラマブル・ゲートアレイ(FPGA)の再構成可能な回路をロジックと統合して、FPGAを制御し、システム100の命令プロセッサ部分と通信し得る。別の実施例において、システム100における再構成可能なハードウェアおよび命令プロセッサ間の電子通信は、スイッチ/ネットワークアダプタポートおよび/または多重MAPを命令プロセッサにリンクするためのスイッチの使用を含み得る。
システムの概観
ここで図1を参照すると、高級プログラミング言語で書かれたプログラムを、統一された実行可能要素に変換するためのハイブリッドの再構成可能なハードウェア命令プロセッサシステム100の実施例が示されている。一実施例において、システム100の再構成可能なハードウェア部分は、多重適応プロセッサ(MAP)を含み得、これはフィールド・プログラマブル・ゲートアレイ(FPGA)の再構成可能な回路をロジックと統合して、FPGAを制御し、システム100の命令プロセッサ部分と通信し得る。別の実施例において、システム100における再構成可能なハードウェアおよび命令プロセッサ間の電子通信は、スイッチ/ネットワークアダプタポートおよび/または多重MAPを命令プロセッサにリンクするためのスイッチの使用を含み得る。
システム100の実施例は、特に、MAP、命令プロセッサ、高級言語(HLL)ファイルから統一された実行可能要素へのコンバータ104、サポートハードウェアロジックモジュール118、ユーザハードウェアロジックモジュール120およびランタイムライブラリ122を含むMAPプログラミング環境を含む。システム100の実施例において、HLLソースコードファイル102はコンバータ104に入力される。HLLソースコードファイル102は、たとえば特に、C,C++,Fortran,COBOL,BASIC,PASCALおよびJava(登録商標)等の従来の高級言語で書かれるかもしれない。
HLLファイル102はコンバータ104に入力され、これはコンバータ104の構成要素によって統一された実行可能要素124に変換され得る。コンバータ104の実施例は、特に、HLLコンバータ106、CFGからCFG−DFGへのコンバータ108、区分化部110、CFG−DFGからHDLへのコンバータ112、HDLからビットストリームへのコンバータ114およびリンカ116を含み得る。
コンバータ104は、高級言語ファイルを制御フローグラフ(CFG)表現に変換するHLLコンバータ106を含み得る。一実施例において、HLLコンバータ106は、高級言語ソースコードを読出し、ソースコードをパーズし、コードを内部表現およびシンボルテーブルに変換することによって、従来のコンパイルを開始するための論理命令を含むソフトウェアモジュールを含む。HLLコンバータ106は、ソースコードの構文および
意味検査を行ない、かつソースコードにおけるエラーに応じて適切な診断メッセージを生成するための論理命令を含み得る。
意味検査を行ない、かつソースコードにおけるエラーに応じて適切な診断メッセージを生成するための論理命令を含み得る。
さらに、HLLコンバータ106は、ソースコードの内部表現の最適化のための論理命令を含み得る。特に、HLLコンバータ106はCFG表現を出力する。CFG表現は、命令プロセッサコンパイラによって命令プロセッサシーケンスを生じるようにさらに処理されるか、またはデータフロー分析および再構成可能なプロセッサ(たとえばMAP)のための論理生成のために、CFGからCFG−DFGへのコンバータ108等の別のソフトウェアモジュールに渡される可能性がある。
一実施例において、CFGからCFG−DFGへのコンバータ108は、HLLコンバータ106によって生成されたCFG表現を受信し、かつCFG表現を制御データフローグラフ表現に変換するための論理命令を含むソフトウェアモジュールであるかも知れない。制御データフローグラフは、コンパイラの段階の残り全体にわたって用いられ得る。CFGからCFG−DFGへのコンバータ108は、コンパイル済みのコードにおける並列度を最適化し得る。CFGからCFG−DFGへのコンバータ108の機能は、特に、コンバータ104の残りの構成要素によって用いられ得る、HLLコンバータ106によって渡されたCFG表現からの制御データフローグラフの生成と、基本ブロックの、データフローグラフにおけるコードブロックへの変換と、入出力スカラの変換と、出入力アレイの変換と、コードブロックにおけるスカラ参照の処理と、コードブロックにおけるアレイ参照の処理と、ループ制御の構成と、ポインタ参照の処理と、命令プロセッサコードへのコールの処理と、命令プロセッサOSへのシステムコールの処理と、組込関数コールの拡張と、外部関数コールの拡張と、ループの最適化と、マルチスレッドの最適化と、データ経路および論理装置のデータ幅の最適化と、不必要な構造の除去を含む構造の最適化とを含み得る。
区分化部110は、ロジックをハイブリッドの計算システムの利用可能な資源に適合するようにサイズ設定するための論理命令を含むソフトウェアモジュールであるかもしれない。区分化部110は、入力としてCFGからCFG−DFGへのコンバータ108によって生成された制御データフローグラフを受信し得、制御データフローグラフを利用可能なリソースにマップして性能を最適化し得る。
例示の実施例において、区分化部110は、以下の情報、すなわちハードウェアロジックモジュール情報ファイルからの論理演算装置のサイズ、リソースファイルからのチップサイズ、リソースファイルからのインターフェイスサイズおよび速度、リソースファイルからのデータ記憶性能およびサイズ、プラグマまたは指示子等のプログラマからの区分化構文入力、制御データフローグラフ(CFG−DFG)エミュレータからのプロファイリング情報、ならびに命令プロセッサプロファイリングツールからのプロファイリング情報を入力として受信し得る。
例示の実施例において、区分化部110は、CFG−DFGに上記の情報の注釈を付け、かつ命令プロセッサおよびMAPにおける実行に基づくサブグラフの性能パラメータを推定するための論理命令を含み得る。区分化部110は、ロジックのサイズ設定を評価し、かつたとえば集積回路およびMAPのリソースに基づいてロジックを割付けるための論理命令をさらに含んでもよい。
区分化部110は、MAP上でインターフェイスロジックを定義し、かつMAPプロキシコードを命令プロセッサに割当てるための論理命令を含んでもよい。MAPプロキシは、MAP上の制御されたスレッドに遷移する命令プロセッサコードの目標を与える。MAPプロキシはコールを受け、MAPに必要とされるいかなるパラメータの受け渡しも開始
する。MAPプロキシはMAPからの要求も受信し得る。
する。MAPプロキシはMAPからの要求も受信し得る。
区分化部110の出力は、MAPにおけるロジックとして実現化され得るCFG−DFG、および命令プロセッサで実現化され得るCFG−DFGを含んでもよい。
CFG−DFGからHDLへのコンバータ112は、CFG−DFGを、MAPにおける再構成可能なプロセッサでインスタンス化される物理的なロジックのハードウェア定義に変換するための論理命令を含むソフトウェアモジュールであってもよい。CFG−DFGからHDLへのコンバータ112は、入力としてCFGからCFG−DFGへのコンバータ108からのCFG−DFGファイルを受信し、CFG−DFGファイルを内部表現に変換する。ハードウェアロジックモジュール情報ファイルを読み出して、ノード入力、出力および待ち時間の情報を与える。ノードおよびノード間の経路は、その互換性およびビット幅の一貫性を検査される。
一部のノードは、ノードをインスタンス化するのではなくインライン化される。インライン化とは、インスタンス化された論理モジュールとしての定義を参照することではなく、ハードウェア定義を生成することを示す。CFG−DFGにおけるノードのすべては、適切なノード依存および一貫したデータフローかどうかを検査される。各ノードは次にインスタンス化されて、ノードを接続するすべての配線が宣言される。ハードウェア定義言語を含む出力ファイルが生成される。出力ファイルは、VerilogまたはEDIF等のハードウェア定義言語で書かれるかもしれない。
HDLからビットストリームへのコンバータ114は、VerilogからEDIFへコンパイルするための従来の合成ツールを含み得、EDIFファイルをMAPにロード可能なビットストリームに変換するための位置およびルート(Place and Route)ツールを用いて、CFG−DFGからHDLへのコンバータ112の出力を処理し得る。
リンカ116は、ビットストリームオブジェクトファイル、命令プロセッサファイルおよび他のオブジェクトファイルを含むオブジェクトファイルを受入れ、かつこれらを統合して統一された実行可能要素124を形成するための論理命令を含むソフトウェアモジュールであるかも知れない。
別の実施例において、システム100は、MAPで実行されるべきロジックに変換されない高級言語の一部をコンパイルするために用いられ得る従来の命令プロセッサコンパイラ(図示せず)を含んでもよい。
システム100はまた、統一された実行可能なファイルを生成するための論理命令を含むソフトウェアモジュールを含み得るビットストリーム構成部(コンフィギレータ)(図示せず)を含んでもよい。ビットストリームファイルは、コンパイル済みのCルーチンとしてカプセル化され、このCルーチンはコンパイラおよび標準リンカを用いて、実行可能なファイルに組込むことができる。アプリケーション命令プロセッサの命令、MAP論理ビットストリーム、およびいかなる必要とされるライブラリコードをも含む実行可能要素は、統一された実行可能要素と呼ばれるかもしれない。
システム100は、コンバータ104への比較ツールであるバイナリトランスレータ(図示せず)を含み得る。コンバータ104は、入力として高級言語ソースコードを受入れ、かつCFG表現および統一された実行可能要素を生成し得る。バイナリトランスレータは、実行可能なファイルを受入れ、これをCFG表現に変換し、かつこれをコンバータ104への二次入力に与えて、ソースコードの必要性を回避し得る。
システム100は、モジュール118および120ならびにライブラリ122を含み、これはHLLから統一された実行可能要素への変換プロセスのためのランタイム環境を与え得る。ランタイム環境は、各アプリケーションの命令プロセッサ部分に含まれるライブラリルーチンを含み得る。これらのライブラリルーチンは、MAPのためのサポートサービスを与える。これは、リソースの割付けおよび割付け解除、命令プロセッサおよびMAP間の通信、デバッグおよび性能分析を含む。少なくとも3つの別個の環境、すなわち1)MAPハードウェアでの実行、2)エミュレートされるMAPおよびデータフローグラフエミュレーションでの実行、3)エミュレートされるMAPおよびシミュレートされるユーザロジックでの実行が、ランタイムルーチンによってサポートされ得る。
方法の概観
ここで図2を参照すると、本発明の実施例に従って高級言語(HLL)を統一された実行可能要素に変換する方法200が示されている。方法200は、ステップ202でHLLプログラムを制御フローグラフ(CFG)に変換することによって開始され得る。一実施例において、HLLプログラムの、指定されたCFGフォーマットへの変換202は、従来のHLLコンパイラによって行なわれ得る。HLLプログラムのCFGへの変換202では、HLLプログラムをCFG表現にパーズし、かつ命令プロセッサで実行可能な命令コードを生成するためにコンパイラが用いられるかもしれない。命令コードは次にオブジェクトファイルに書込まれ、このオブジェクトファイルはアドレスを解くリンカ・ローダとともにリンクされ得る。
ここで図2を参照すると、本発明の実施例に従って高級言語(HLL)を統一された実行可能要素に変換する方法200が示されている。方法200は、ステップ202でHLLプログラムを制御フローグラフ(CFG)に変換することによって開始され得る。一実施例において、HLLプログラムの、指定されたCFGフォーマットへの変換202は、従来のHLLコンパイラによって行なわれ得る。HLLプログラムのCFGへの変換202では、HLLプログラムをCFG表現にパーズし、かつ命令プロセッサで実行可能な命令コードを生成するためにコンパイラが用いられるかもしれない。命令コードは次にオブジェクトファイルに書込まれ、このオブジェクトファイルはアドレスを解くリンカ・ローダとともにリンクされ得る。
HLLプログラムで用いられるプログラミング言語は、特にC,C++,Fortran,COBOL,BASIC,Java(登録商標),PASCAL等の従来の高級言語であるかもしれない。HLLプログラムは、スカラ、アレイおよびユーザ指定の集合体、特にその関連のオペレータを含むさまざまなデータエンティティを含み得る。HLLプログラムは、関数コール、サブルーチン、ループおよび条件、特に演算を含み得る。
本発明の実施例において、方法200の次のステップは、ステップ204での、CFG表現のハイブリッドな制御データフローグラフ表現(CFG−DFG)への変換であり得る。簡単に言うと、この変換204は、CFG表現をその構成要素の基本ブロックに分離するステップと、ロードおよび記憶データを基本ブロックの上部および下部に追加するステップと、基本ブロックをCFG−DFG表現のコードブロックに変換するステップとを含み得る。変換204のより詳細な説明が以下で行なわれる。
方法200の次のステップは、ステップ206での、CFG−DFG表現の再構成可能なハードウェア部分および命令プロセッサ部分への区分化であるかもしれない。一実施例において、CFG−DFG表現は、区分化プログラムに入力され得、この区分化プログラムはデータをスキャンして、それを構成可能なハードウェアの部分および命令プロセッサの部分に分割し得る。別の実施例において、区分化プログラムは、ユーザが挿入した区分化構文からの命令、たとえばCプラグマまたはコンパイラ指示子を受信し得、この命令はCFG−DFGコードがいかにして再構成可能なハードウェア部分および命令プロセッサ部分に区分化されるかを案内する。たとえば、プラグマは、区分化プログラムに、区分化されたCFG−DFG表現の命令プロセッサ部分に特定のループ演算を入れるように命令してもよい。プラグマは、元のHLLプログラムのソースコードに含まれてもよく、または区分化プログラムに直接与えられてもよい。
方法200のこの実施例におけるこの時点で、区分化ステップ206からの区分化されたCFG−DFG表現は、別々のプロセスステップに分割され得る。区分ステップ106からの命令プロセッサ部分は、命令プロセッサオブジェクトファイル208に変換され得る。一実施例において、ハイブリッドのCFG−DFG表現の命令プロセッサ部分は、C
FG表現に戻され、次に命令プロセッサで実行可能な命令コードに変換され得る。命令コードは、次に、アドレスを解くリンカ・ローダとともにリンクされ得るオブジェクトファイルに書込まれ得る。別の実施例において、ハイブリッドのCFG−DFG表現の命令プロセッサ部分は、元のCFG表現の一部と同一とみなされてもよく、元のCFG表現のこの部分はオブジェクトファイルに変換されてもよい。
FG表現に戻され、次に命令プロセッサで実行可能な命令コードに変換され得る。命令コードは、次に、アドレスを解くリンカ・ローダとともにリンクされ得るオブジェクトファイルに書込まれ得る。別の実施例において、ハイブリッドのCFG−DFG表現の命令プロセッサ部分は、元のCFG表現の一部と同一とみなされてもよく、元のCFG表現のこの部分はオブジェクトファイルに変換されてもよい。
ここで区分化ステップ206からのCFG−DFG表現の再構成可能なハードウェア部分に注目すると、この部分は、CFG−DFG表現からHDL(hardware definition language)に変換され得る(210)。ハードウェア定義言語は、特にVerilogおよびEDIFの従来のHDLを含み得る。
ハードウェア定義言語ファイルは、次にビットストリームデータファイルに変換されてもよく(212)、このファイルは再構成可能なハードウェアにおける個々の再構成可能な回路にロード(load)することができる。たとえば、ビットストリームデータファイルは、本発明のハイブリッドの命令プロセッサの再構成可能なハードウェアコンピュータで用いられる多重適応プロセッサ(MAP)におけるフィールド・プログラマブル・ゲートアレイ(FPGA)にロードされてもよい。実施例において、「位置およびルート」プログラムを用いて、HDLからビットストリームへの変換212を行なってもよい。HDLファイルに基づいて、「位置およびルート」プログラムはインスタンス化され、再構成可能なハードウェアのハードウェアロジックモジュールと相互接続されてもよい。「位置およびルート」プログラムは、モジュールが物理的にどこに進み得るか、およびこれらが再構成可能なハードウェアにおいていかにして互いに結合されるかを指示する。
方法200の実施例において、ビットストリームファイルが生成された後で、これらはステップ214でビットストリームオブジェクトファイルに変換され得る。ビットストリームからオブジェクトファイルへの変換214は、ビットストリームデータを高級言語ソースコードに変換し(たとえばC構造にビットストリームを配置し)、かつ高級言語ファイルを命令プロセッサが読むことのできるオブジェクトファイルに変換するステップを含み得る。
方法200の実施例において、ステップ214でビットストリームファイルをビットストリームオブジェクトファイルに変換し、かつステップ208でCFG−DFG表現の命令プロセッサ部分を命令プロセッサオブジェクトファイルに変換した後で、オブジェクトファイルはステップ216で収集され得る。追加のオブジェクトファイルは、ビットストリームオブジェクトファイルおよび命令プロセッサのオブジェクトファイルとともに収集され得る。たとえば、追加のオブジェクトファイルは、方法200の前の反復からもたらされるかもしれない。追加のオブジェクトファイルは、前の命令プロセッサのコンパイルから、およびオブジェクトライブラリから取得してもよい。
ビットストリームオブジェクトファイル、マイクロプロセッサオブジェクト命令プロセッサファイル、およびいかなる追加のオブジェクトファイルが一旦収集されると、これらは互いにリンクされて(218)、統一された実行可能要素220を形成する。実施例において、オブジェクトファイル218のリンクは、リンカプログラムによって行われてもよい。統一された実行可能要素220は、命令プロセッサによって読取り可能であり、このプロセッサは、統一された実行可能要素220を実行して、ハイブリッドの再構成可能なハードウェア・マイクロプロセッサコンピュータがHLLプログラムを実行するように構成し得る。
ここで図3を参照すると、本発明の実施例に従って高級言語ソースコードをハードウェアロジック実行可能要素に変換する方法のフロー図が示されている。この方法は、区分化
ステップ304で処理される高級言語(HLL)ソースコード302の分析で開始され得る。HLLソースコード302で区分が発見された場合、このコードは、ステップ306および308で分割され、制御フローグラフ(CFG)表現に変換され得る。
ステップ304で処理される高級言語(HLL)ソースコード302の分析で開始され得る。HLLソースコード302で区分が発見された場合、このコードは、ステップ306および308で分割され、制御フローグラフ(CFG)表現に変換され得る。
一実施例において、HLLソースコード302の区分化された部分がステップ308でCFG表現に変換された後で、このCFG表現を用いて、MAPプロキシ322(高級言語コンバータセクションのMAPプロキシの詳細を参照)を生成するか、またはステップ316でハードウェアロジックのためのCFG−DFG表現に変換し得る。CFG表現のうちMAPプロキシ322の生成をもたらす部分について、この部分はステップ324でバイナリ命令プロセッサコードに変換され、次にステップ326ですべての他のバイナリファイルとリンクされて、ハードウェアロジックの実行可能要素328の一部となり得る。CFG表現のうち、ステップ316でハードウェアロジックのためにCFG−DFG表現に変換された部分について、CFG−DFG表現は、ステップ318でVerilogコード等のHDL(hardware definition logic)コードに変換され、次にステップ320でハードウェアロジックバイナリに変換され、ステップ326ですべての他のバイナリファイルとリンクされて、ハードウェア実行可能要素328の一部となり得る。区分化されたソースコードの一部ではない残りのHLLソースコード302は、ステップ306でCFG表現に変換され得る。次に、CFG表現は、ステップ324で命令プロセッサのバイナリコードに変換された後で、すべての他のバイナリファイルとリンクされて(326)、ハードウェアロジック実行可能要素328(すなわち統一された実行可能要素)の一部となり得る。
区分を有さないHLLソースコード302について、コード全体はステップ310でCFG表現に変換されてもよく、ステップ312で再構成可能なハードウェア部分および命令プロセッサ部分に区分化されてもよい。命令プロセッサ部分は、ステップ324で命令プロセッサバイナリコードに変換され、最終的にハードウェアロジック実行可能要素328へと形成され得る。再構成可能なハードウェア部分は区分化され得、この部分はステップ322でMAPプロキシを生成し、一方でこの同じ部分はCFG−DFG表現に変換される。この区分化された部分は、最終的にハードウェアロジック実行可能要素328の一部になり得る。
ここで図4を参照すると、本発明の実施例に従ったバイナリトランスレータの演算方法400のフロー図が示されている。一実施例において、命令プロセッサ実行可能要素402は、ステップ404で編集されて、これがハードウェアロジック実行可能要素426の一部になるようにしてもよい。別の実施例において、命令プロセッサ実行可能要素402は、ステップ406でCFG表現に翻訳されてもよい。
ステップ406で命令プロセッサ実行可能要素402がCFG表現に変換され、かつCFG−DFG表現に変換された後で、これは次にステップ408で再構成可能なハードウェア部分および命令プロセッサ部分に区分化され得る。命令プロセッサ部分およびCFG表現のいかなる残りの部分420も、次にステップ422で命令プロセッサバイナリコードに変換され得る。命令プロセッサバイナリコードは、次にステップ424ですべての他のバイナリファイルとリンクされて、ハードウェアロジック実行可能要素426の一部になり得る。
再構成可能なハードウェア部分は区分化され得、この部分はステップ416でMAPプロキシを生成し、一方でこの同じ部分がステップ414でハードウェア定義言語(HDL)コード(たとえばVerilog)に変換され、これは次にステップ418でハードウェアロジックバイナリに変換され得る。ハードウェアロジックバイナリは、ステップ424ですべての他のバイナリファイルとリンクされて、ハードウェアロジック実行可能要素426
の一部になり得る。
の一部になり得る。
区分化された部分によって生成されたMAPプロキシは、ステップ422で命令プロセッサバイナリコードに変換され、次にステップ424ですべての他のバイナリファイルとリンクされて、ハードウェアロジック実行可能要素426の一部になり得る。
図2および3は、本発明の実施例に従って、HLLプログラムを統一された実行可能要素またはハードウェアロジック実行可能要素に変換するステップで用いられ得る方法のステップを示している。図4は、命令プロセッサ実行可能ファイルをハードウェアロジック実行可能要素に変換するプロセスで用いられ得る方法のステップを示している。追加のステップおよび示されたステップの代替のシーケンスが、本発明の追加の実施例で考察されることを認識すべきである。
マップ実行セレクタ
例示の実施例において、ハードウェアロジックのために分離されかつ目標にされ得る高級言語で書かれたソースコードの領域を識別するための方法が提供され、一方でコードの他の部分は従来のプロセッサで実行するためにコンパイルされ得る。例示の方法では、コードのうちどの領域がハードウェアロジックで実行されるべきかを示す特別なブラケット構文が用いられ、ブラケット領域内に含まれる変数のスコーピング(scoping)情報が提供される。この情報を用いて、ユーザがさらに介入することなく、ハードウェアロジックで実行するように識別された領域の実行を容易にする通信およびデータ移動ルーチンを構築し得る。
例示の実施例において、ハードウェアロジックのために分離されかつ目標にされ得る高級言語で書かれたソースコードの領域を識別するための方法が提供され、一方でコードの他の部分は従来のプロセッサで実行するためにコンパイルされ得る。例示の方法では、コードのうちどの領域がハードウェアロジックで実行されるべきかを示す特別なブラケット構文が用いられ、ブラケット領域内に含まれる変数のスコーピング(scoping)情報が提供される。この情報を用いて、ユーザがさらに介入することなく、ハードウェアロジックで実行するように識別された領域の実行を容易にする通信およびデータ移動ルーチンを構築し得る。
多くの高級プログラミング言語は言語構成体を含み、この言語構成体を用いて、汎用プロセッサではなく、ハードウェアロジックでコンパイルされ実行され得るユーザコードの領域を指定し得る。たとえば、Fortran言語で、構文“!dir$”を用いてもよく、Cにおいて構文“#pragma”を用いてもよい。これらの構成体を用いて、ユーザコードにブラケットを付ける構文は、開始または停止識別子のいずれか、ブラケットコード内に含まれる変数のスコーピングルール、および専用に(privately)計算されたデータをコピーするための追加の構文を含む。
たとえば、以下の小さなFortranプロシージャを考えることにする。
このコードセグメントは、最初に3つのアレイ(a,b,c)を宣言し、このアレイは計算で用いられるデータを保持するために用いられる。このアレイは共通のブロックで宣言され、これらの記憶の割付けが、命令プロセッサのメモリで行なわれ、このプロシージャに関連したローカルスタックスペースでは行なわれないことを意味している。プロシージャに対する外部コールがあり、これはアレイにおけるデータを初期化するものと想定することができる。この初期化の後で、コールはこのプロシージャの計算部分を含むドゥ・ループ(do-loop)である。
コードのうちハードウェアロジックで実行するように識別された部分は、ドゥ・ループ構成体で囲まれたループ本体であると決定される。ハードウェアロジックを生成する、コンパイルシステムによって認識される構文を用いて、Fortranコードを以下に類似するように修正してもよい。
ここで、ドゥ・ループは、コンパイルシステムが必要とする情報を与える一対の指示子とともにブラケットを付けられている。コンパイルシステムは、この情報を処理して、汎用プロセッサで実行するプロシージャ、およびハードウェアロジックで実行するサブプログラムの双方を構築する。
この単一のFortranプロシージャの、別々にコンパイル可能なプロシージャへの変換は、複数のコンパイル段階を含み得る。1つの段階において、コンパイルシステムはプログラムに含まれる個々のソースファイルを処理し、ハードウェアコンパイルが望まれることを示す構文を有さないさらなる再構成可能なハードウェアロジックコンパイルソースファイルを廃棄する。コンパイルシステムが、再構成可能なハードウェアコンパイルが望まれることを示す構文に遭遇したときに、コンパイルシステムは、命令プロセッサおよびハードウェアロジックのブラケット部分の双方でこのソースファイルのコンパイルを実行するのに必要なインフラストラクチャを構築し始める。命令プロセッサのコンパイル段階およびハードウェアロジックのコンパイル段階に必要とされるソースファイルを生成することに加えて、ハードウェアロジックリソースを割付け、予約し、かつ解放するために用いられる機構が生成される。
ブラケット構文は、ブラケット領域内で用いられるすべての変数のためのスコーピング情報を含み得る。このスコーピング情報は、コンパイルシステムによって用いられて、補正データ移動文を構築し、プログラムの完全性が、完全に命令プロセッサで実行された場合と同じであることを保証し得る。「グローバル」としてのスコーピングデータおよび変数は、コンパイルシステムに対して、このデータが命令プロセッサおよびハードウェアロジック間のコール境界にわたって持続性を有することを示す。データをハードウェアロジックに動かしかつハードウェアロジックからデータを取出す機構は、コンパイルシステム
によって生成される新しいサブプログラムに構築され得る。グローバルデータは同様の態様で処理されてデータの完全性が保護され得る。
によって生成される新しいサブプログラムに構築され得る。グローバルデータは同様の態様で処理されてデータの完全性が保護され得る。
「専用」とされたスコーピングデータおよび変数は、コンパイルシステムに対して、これらの変数がスコープにおいてちょうどハードウェアロジックのローカルにあるため、その結果として生じる値がハードウェアロジックの実行地点を越えて持続する必要がないことを示す。この構文の変形として、専用データをソースファイルの命令プロセッサバージョンでローカル変数に「コピー」することのできる追加の構文がある。
このコンパイルシステムはこのデータスコーピング情報を用いて、2つの分離したソースファイルを生成し、その各々はブラケット構文を含む元のソースファイルの一部を示す。新しいソースファイルのうちの1つがコンパイルされて、命令プロセッサのシステムで実行される。他のソースファイルを用いてハードウェアロジックを生成する。このプロセスは図5に示されている。
高級言語コンバータ
コンパイルシステムのうち最初にコールされた構成要素が、いかなる命令プロセッサシステムでのコンパイルと同様の従来のコンパイル段階を開始する。この構成要素は、入力としていかなるプログラミング言語コードも受信し、ソースファイルから次にパーズすることのできるトークンを抽出する。パーズ段階が行なわれている間、意味解析も行なわれて、この段階の後でコードおよびシンボルテーブルの内部表現が生成されるようにしてもよい。意味上の誤り検査が行なわれて、適切な診断メッセージが出される。
コンパイルシステムのうち最初にコールされた構成要素が、いかなる命令プロセッサシステムでのコンパイルと同様の従来のコンパイル段階を開始する。この構成要素は、入力としていかなるプログラミング言語コードも受信し、ソースファイルから次にパーズすることのできるトークンを抽出する。パーズ段階が行なわれている間、意味解析も行なわれて、この段階の後でコードおよびシンボルテーブルの内部表現が生成されるようにしてもよい。意味上の誤り検査が行なわれて、適切な診断メッセージが出される。
現在このコンパイル段階で生成されたソースコードの内部表現は、コードの制御フローブロックと類似している。次のステップでは、この制御フローブロックを、オプティマイザが処理する内部言語に拡張する。この拡張段階の間に、各制御フローブロックは、基本ブロックまたは拡張された基本ブロックのいずれかと呼ばれるユニットに拡張され得る。フローグラフは、関数での基本ブロックの有向グラフであってもよく、これは関数の制御フローを示している。グラフの各ノードは基本ブロックに相当する。このフローグラフは、最適化が行なわれると、コンパイルの際に更新され得る。このステップの間に行なわれる主要なグローバルとしての最適化は、一定したコードの動き、すなわち誘導変数分析、グローバルレジスタの割当を含み得る。他の最適化は、コードブロックのマージおよび最適化された制御フローコードブロックをもたらすピープホールの最適化を含んでもよい。
グローバルレジスタの割当の最適化の後で、ルーチンのコールパラメータが中間ファイルに書込まれ、このファイルは次のコンパイル段階への入力として用いられ得る。コールパラメータは、そのデータタイプとともに書込まれ、次にルーチンおよびそのデータタイプに関連したユーザシンボルが続く。ルーチンで用いられるシンボルを書出した後で、ファイルの次の部分は端末コードブロックのトラバーサルを含み、これは示された基本ブロックのタイプおよびコードブロックに関連した命令を示している。一旦この制御フロー表現が生成されると、最終的なステップでは、ルーチンのコンパイルの際に生成されたすべての命令が生成される。これらの命令は、制御フローブロックにリストされた命令に相当するかもしれない。
いかなるアーキテクチャでもそうであるように、コンパイラは、高級言語で書かれたプログラムを、コンピュータで実行するために機械語での等価のプログラムに処理することが必要とされる。システム100は、従来の命令プロセッサのみのためのプログラムを翻訳する能力によって、または再構成可能なプロセッサとの組合せによって、上記の要求を満たしている。この高級言語を翻訳するのに用いられるコンパイラの段階は、命令プロセッサコンパイラ技術に基づいている。HLLコンバータは、言語特定のフロントエンドを
有するコンパイルの混合モデルを用いて、共通の高級中間表現を生成する。この第1のレベルの表現は次に、制御フロー分析を含むさまざまな基本的な最適化に入力されるため、結果として生じる第2のレベルの中間表現は制御フロー表現と呼ぶことができる。制御フロー表現は、HLLコンバータが出力として生成する制御フロー情報における主要な構成要素となる。以下の文章では、このファイルおよびこの段階でのコンパイルの結果として生成することのできる追加のファイルの内容についてのさらなる詳細が示される。
有するコンパイルの混合モデルを用いて、共通の高級中間表現を生成する。この第1のレベルの表現は次に、制御フロー分析を含むさまざまな基本的な最適化に入力されるため、結果として生じる第2のレベルの中間表現は制御フロー表現と呼ぶことができる。制御フロー表現は、HLLコンバータが出力として生成する制御フロー情報における主要な構成要素となる。以下の文章では、このファイルおよびこの段階でのコンパイルの結果として生成することのできる追加のファイルの内容についてのさらなる詳細が示される。
HLLコンバータへの入力は、2つの異なるタイプのソースコードからなる可能性がある。いかなる高級言語のソースコードも、このコードがそれが示す言語表示に準拠するように書き込まれた場合、HLLコンバータへの入力として用いることができる。HLLコンバータへの別の入力は、もともと表現された高級言語の制御フロー情報を表わすソースコードである。この制御フロー情報を、(以下で説明されるように)明確に規定されたインターフェイス仕様に書込んで、以前のコンパイルからの制御フロー情報を用いることができるようにするか、または別のマイクロプロセッサ実行可能要素等の別のソースから導き出された制御フロー情報を用いることができるようにする。
制御フロー分析が各プロシージャにおける制御の階層的なフローを明らかにした後で、制御フローの表現を中間言語として生成することができる。この時点で生成される制御フロー情報ファイルは、以下のもの、すなわち特にエントリ信号、ユーザシンボル、基本ブロックおよび中間表現命令を含むが、必ずしもこれらに限定されない。
エントリシンボルは、HLLコンバータによって生成されたシンボルを表わし、これはコールルーチンで渡されたパラメータであり、これは実行可能要素の命令プロセッサの部分およびハードウェアロジック間のインターフェイスとして機能する。これらのシンボルは、計算のためにハードウェアロジックおよびスカラ値がアクセスするデータのアドレスを渡し得る。
ユーザシンボルは、コードのうちハードウェアロジックのためにコンパイルされる領域における変数を示すシンボルである。これらのシンボルは、アレイおよび構造等の構成体を含む高級ソースコードにおける変数名に対応する。シンボルはいかなる外部ルーチンコールも表わし得る。ここでハードウェアロジックモジュールはコンパイルプロセスで見ることができるかもしれない。
基本ブロックは最大シーケンスの命令であるかもしれず、この命令はその最初の部分のみで入力され、かつその最後の部分のみから終了することができる。所与のコードソースを示す基本ブロックがここに列挙される。すべての基本ブロックは、ブロック情報ヘッダエントリとともに開始される。このエントリは、相対ブロック番号、この基本ブロックを示すソース行番号、関連のシンボルテーブルで示されるように(存在すれば)このブロックが定義したラベルを与える。この情報の後には、これらの基本ブロックのための属性を示すフラグのリストがある。これらのフラグは、たとえばこのブロックがプロシージャへのエントリを含むか、このブロックが何らかの外部参照を有するか、およびこのブロックの制御が失敗してすぐ次の後続点に渡されるかといったブロックに関するさらに多くの情報を与える。このブロック情報ヘッダラインの直後に来るのは端末ノードを示す命令のリストである。これらのタイプの命令の例として、メモリへのデータの記憶(store)、無条件のもしくは条件付きの分岐、またはプロシージャコールが挙げられる。各端末ノードは、基本ブロック内のその相対数、文を示す命令の「木」を指す行番号、およびこのノードについてのさらに多くの情報を与えるフラグによって示されている。
この基本ブロックセクションが参照した命令は、中間表現命令において列挙され得る。このセクションは、コンパイルの際に生成されかつこの時点まで最適化のために用いられ
た個々の命令を含む。これらの命令は、基本ブロックに分類され、その互いの関係は前のセクションで既に確立されている。これらはここで、コンパイルのプロセスで生成された順序で生成される。
た個々の命令を含む。これらの命令は、基本ブロックに分類され、その互いの関係は前のセクションで既に確立されている。これらはここで、コンパイルのプロセスで生成された順序で生成される。
第1のエントリは、この命令リストにおける命令の相対数である。次に来るのは命令名であり、その後にこの命令の各オペランドが続く。オペランドが変数のテーブルにおけるエントリおよびエントリポイント名を指すラベルであれば、オペランドのための情報が提供され得る。内部で生成されたコンパイルからの名前が示される。メモリからロードされたまたは記憶されたデータベースに関する情報が提供されてもよい。制御フロー情報ファイルで参照することのできる命令のタイプに関するさらなる詳細が、インターフェイス仕様セクションにおいて示される。
制御フロー情報ファイルの生成は、コンパイルコマンドラインまたはソースコードそれ自体のいずれかで与えられたオプションに基づく。このオプションをコンパイルコマンドに追加することによって、サブプログラムのより大きなソースファイルに含まれるサブプログラムのうちどれがハードウェアロジックの目標にされてるべきかを指定する。コンパイルの際に、指定されたサブプログラムのみが、さらなるハードウェアロジックコンパイルのために分離ファイルに書出されるその制御フロー情報を有する。残りのソースコードサブプログラムはコンパイルされて、命令プロセッサ機械コードを生成する。
制御フロー情報ファイルは、区分化またはブラケット、コンパイラによって認識されかつパーズされる構文の存在に基づいて生成することができる。この区分化構文は、言語特定のソース行と関連して用いられて、このソースコードが異なるアーキテクチャのためにコンパイルされる場合、区分化構文はコンパイルの際に無視されるようにし得る。この構文のために定義されたキーワードによって、ソースコード全体の領域を、ハードウェアロジックのための分離したサブプログラムとして抽出し、コンパイルすることができる。コマンドラインオプションについて上述したように、この特別にブラケットを付けられた領域のみが、さらなるハードウェアロジックのコンパイルのために分離した制御フロー情報ファイルへと書出されるその制御フロー情報を有する。
区分化構文がコードに存在せず、かつハードウェアロジックコンパイルために目標にされる特定のサブプログラムを指定するコマンドラインオプションがない場合、コンパイラは省略値をとって、ハードウェアロジックの候補としてソースコード全体をコンパイルし得る。各サブプログラムに関する制御フロー情報が書出され、さらなるコンパイルために渡され得る。次のコンパイルステップでは、部分集合の制御フロー情報を生成するために区分化するための、制御フローにおける最良の地点を決定する際に必要とされる分析を行なう。この新しい制御フロー情報ファイルはHLLコンバータに戻されて、必要とされるMAPプロキシルーチンを生成する。
高級言語から制御フロー情報ファイルを生成し、または以前に生成された制御フロー情報ファイルを処理するために用いられるコンパイラは、ハードウェアロジックの実行のために必要な機能性を提供するさまざまな他のプロシージャも生成しなければならない。これらのプロシージャは、マイクロプロセッサのコードの実行および再構成可能なプロセッサのコードの実行の間のインターフェイスをサポートすることによって機能性を提供する。このインターフェイスの機能性は、「MAPプロキシ」と呼ばれる。図6はインターフェイスの機能性の例を示している。
制御フロー情報ファイル610に含まれるコードは、ハードウェアロジックで実行されるソースコードの領域を含んでもよい。このファイルは、コンパイルプロセスを継続し、その結果としてFPGAビットストリームはハードウェアロジックの実行に好適なものと
なる。
なる。
MAPプロキシ615に含まれるコードは、ハードウェアロジックで実行されるように区分化された制御フロー情報の領域に代わって、命令プロセッサで実行するためにスケジュールされてもよい。このコードは、目標とされる再構成可能なプロセッサにとって適切なデータ操作構成物を挿入することによってハードウェアロジックの実行をサポートするのに必要とされるデータ移動を処理する。MAPプロキシはまた、オペレーティングシステムと対話するように実行されるときに用いられるランタイムライブラリコールを挿入してもよい。この対話は、ハードウェアロジックリソースの割付け、すなわちハードウェアロジックステータスの照会、ハードウェアロジックリソースのシステムへの解放、および命令プロセッサのプロセスからハードウェアロジックへの制御の移動を含む。
HLLコンバータの最終的なステップでは、目標とされる命令プロセッサで実行する必要のある機械コードが生成される。HLLコンバータは、ソースコード全体およびMAPプロキシコードのための制御フロー情報を生成する。この情報は次に機械コードに翻訳されて、このコンパイルから生成されたバイナリファイルは、統一された実行可能要素をもたらすリンクステップへの入力として用いることができる。
ハードウェアロジックモジュール情報ファイル:概念および構造
コンパイルシステムの別の構成要素は、オペレータ、組込関数コール、および既存の(規定されたシステムの)ハードウェアロジックモジュールへのMAPプロシージャのソースにおけるプロシージャコールのマッピングを示すデータベースである。このデータベースはシステムinfoファイルと呼ばれる。
コンパイルシステムの別の構成要素は、オペレータ、組込関数コール、および既存の(規定されたシステムの)ハードウェアロジックモジュールへのMAPプロシージャのソースにおけるプロシージャコールのマッピングを示すデータベースである。このデータベースはシステムinfoファイルと呼ばれる。
選択的に、ユーザは追加のハードウェアロジックモジュールを定義してもよく、このモジュールは、MAPプロシージャのソースにおけるプロシージャをコールすようにコールされてもよく、またはシステムinfoファイルに記載された組込システムで定義されたハードウェアロジックモジュールを再定義するために用いられてもよい。ユーザが定義したハードウェアロジックモジュールを用いたMAPのためのコンパイルを行なうために、ユーザは、ユーザが定義したハードウェアモジュールにオーバーロードされたプロシージャの名前またはオペレータをマップするデータベースを提供しなければならない。
コンパイルされるMAPプロシージャのデータフローグラフ表現のノードにおけるすべてのオペコードがinfoファイルエントリで定義されなければならない。
ハードウェアロジックモジュール情報ファイルは、CFGからCFG−DFGへのコンバータのデータフローグラフ生成部、およびCFG−DFGからHDLへのコンバータのコンパイルのVerilog生成段階の双方によって用いられる。
ハードウェアロジックモジュール情報ファイルは、単一のファイルに連結される1つ以上のエントリを含む。各エントリは、データグラフにおいて示される一意の演算(オペコード)または、コンパイルされるMAPプロシージャからのコールを通してインスタンス化された関数またはサブルーチンを示している。この記述は、ハードウェアロジックモジュールへのインターフェイスを含み、これはその入力、出力、モジュールが接続されるべきいかなる入力または出力信号、およびハードウェアロジックモジュールの特徴を含む、演算を行なうようにインスタンス化されるべきである。選択的に、入力は機能的に等しい擬似コードを含んでもよく、このコードはデータフローグラフのエミュレートモード、またはモジュールの機能性をエミュレートする/シミュレートするさまざまなシミュレーションモードで用いられてもよい。
ハードウェアロジックモジュール情報ファイルエントリは、開始-defおよび終了-defマーカで区切られ、以下の形をとる。
<opcode>は、演算に対応するデータフローグラフにおけるオペコードに一致するASCIIストリング、またはMAPプロシージャのソースコードでコールされるプロシージャの名前である。この<mapping and emulation information>は、入力のシーケンスからなり、各々はセミコロンで終わる。ハードウェアロジックモジュール情報ファイルエントリのこれらのセクションの順序は重要ではない。
<macro_name>は、ハードウェアロジックモジュール情報ファイルエントリが示す演算またはプロシージャの機能を果たすハードウェアロジックモジュールの名前を示すASCIIストリングである。
<num>は、ハードウェアロジックモジュールの入力へのデータの提示および出力に関する対応する結果の可用性の間のクロックサイクルの数を指定する整数値である。
YESは、ハードウェアロジックモジュールが典型的に内部レジスタにおける反復の間の状態を保持することを指し、NOはそれが保持しないことを指す。
YESは、ハードウェアロジックモジュールがそのコードブロックの外部のエンティティと対話することを指し、NOはそれが対話しないことを指す。
YESは、ハードウェアロジックモジュールが各クロックで新しい入力を受取ることができるようにパイプライン化されることを指し、NOはそうでないことを指す。
<num>は、MAPプロシージャのソースにおける演算もしくはプロシージャへの、またはデータフローグラフでそれを示すノードへの入力もしくは出力の数である。入力または出力規則子で指定された<num>入力または出力の仕様がなければならない。
各<input spec>は以下の形をとる。
各<output spec>は以下の形をとる。
<n>は、MAPプロシージャのソースにおけるもしくはデータフローグラフのノードにおける演算またはプロシージャコールへのゼロに基づく入力もしくは出力シーケンスの数を指定している。入力および出力の番号付けは独立しており、各々はゼロから始まる。
<type>は、入力または出力のデータタイプである。これは、INT,FLOATまたはADDRESSであるかもしない(これは追加のタイプ、COMPLEX, LOGICAL, REAL, INTEGER, CHAR, CHARACTERを含むように拡張される)。<input_port_name>および<output_port_name>は、関連のハードウェアロジックモジュールの対応する入力または出力ポート名を示している。
これらは、ソースコードまたはデータフローグラフのレベルでは見ることのできないハードウェアロジックモジュール接続を示している。<nbits>は、入力または出力信号のビット数である。<macro_port_name>は、ハードウェアロジックモジュールへの信号(IN_SIGNAL)のまたはそこからの信号(OUT_SIGNAL)の名前である。<internal_signal_name>は、ソース(IN_SIGNAL)、またはコンパイルされたハードウェアロジックにおける目標の(OUT_SIGNAL)信号の名前である。
現在のところ3つの内部ソース信号が利用可能である。
CLOCKは、すべてのハードウェアロジックモジュールのクロックソースである。rstは一度限りのグローバルリセットである。code_blok_resetは、ハードウェアロジックモジュールのコードブロックを起動したときに常に起動されるリセット信号である。
現在目標とされる信号は記録されていない。これらは、将来的にハードウェアロジックモジュールの実行の際に検出される、エラー、オーバーフロー、または例外条件を含む。
<simcode>は、データフローのエミュレーションの際にハードウェアロジックモジュールの動作を機能的に定義するものとして用いられるCコードである。
ハードウェアロジックモジュールのこれらのまたは追加の特徴の変化を指定するハードウェアロジックモジュールの情報ファイルエントリへの構文拡張が計画される。これらの特性の変化および追加は、n回の反復ごとに新しい入力を受信することができる、およびn回の反復のための入力を受信し、かつjのクロック期間の後でiを生成することのできるハードウェアロジックモジュールの記述、ハードウェアロジックモジュールが実行される頻度を指定する手段、実際のコードまたはシミュレーションのためにハードウェアロジックモジュールを定義するHDLコードを含むファイルへのディレクトリパス(path)、およびハードウェアロジックモジュールのためのリソース要求の仕様を含むがこれらに限定されない。
ハードウェアロジックモジュール情報ファイルの翻訳
データフローグラフに加えて、CFG−DFGからHDLへのコンバータへの第2の入力ファイルがある。これは、CFG−DFGからHDLへのコンバータバイナリファイルであり、このファイルはインターフェイスおよびハードウェアロジックモジュール情報ファイルに含まれるハードウェアロジックモジュールに関する情報を含む。本発明の実施例において、小さな実行可能要素を用いてもよく、この要素は、ASCIIハードウェアロジックモジュール情報ファイルをCFG−DFGからHDLへのコンバータの内部テーブルに翻訳し、CFG−DFGからHDLへのコンバータをコールす前にコンパイルの際に実行される。
データフローグラフに加えて、CFG−DFGからHDLへのコンバータへの第2の入力ファイルがある。これは、CFG−DFGからHDLへのコンバータバイナリファイルであり、このファイルはインターフェイスおよびハードウェアロジックモジュール情報ファイルに含まれるハードウェアロジックモジュールに関する情報を含む。本発明の実施例において、小さな実行可能要素を用いてもよく、この要素は、ASCIIハードウェアロジックモジュール情報ファイルをCFG−DFGからHDLへのコンバータの内部テーブルに翻訳し、CFG−DFGからHDLへのコンバータをコールす前にコンパイルの際に実行される。
この翻訳プログラムは、1つの必須のおよび2つの選択的なコマンドラインのオプションでコールされ得る。必須のオプション、-o outfileは、CFG−DFGからHDLへのコンバータテーブルが書出されるべき出力ファイルの名前を示している。オプション−ddeleted_signalは、無視されるべきハードウェアロジックモジュール情報ファイルの入力および出力信号の名前を示している。すなわち、翻訳プログラムは、a−dオプションで指定されたハードウェアロジックモジュール情報ファイルでdeleted_signalとよばれる信号の処理をスキップする。これによって、ハードウェアロジックモジュールのためのハードウェアロジックモジュール情報ファイルのエントリが、実際のハードウェアロジックを生成するときに存在しないかもしれない、シミュレーションで用いられる検査信号または信号を含むことができる。第2の選択的なコマンドラインの引き数は、-r sigval=newsig
valである。この翻訳プログラムは、ハードウェアロジックモジュール情報ファイルにおけるsigvalによって指定されたピンまたはワイヤ名の出現を、結果として生じるCFG−DFGからHDLへのコンバータテーブルにおけるストリングnewsigvalと置き換える。このオプションによって、CFG−DFGからHDLへのコンバータによって接続されるべきハードウェアロジックモジュールの入力および出力信号の改名が可能になる。CFG−DFGからHDLへのコンバータは、名前が“unconnected_”で始まるワイヤに接続されるべきいかなる接続も無視し得る。このオプションによって“unconnected_”ワイヤを改名することによって、これらはCFG−DFGからHDLへのコンバータによって処理され得る。−dオプションに関して、−rはVerilogのようなHDLを生成するときに有用であり、Verilogは、テストベンチまたはシミュレーション環境において用いられ、結果として生じるハードウェアロジックのために生成されたVerilogには実際に存在しない信号を有し得る。多重の−dおよび−rのオプションを指定してもよい。
valである。この翻訳プログラムは、ハードウェアロジックモジュール情報ファイルにおけるsigvalによって指定されたピンまたはワイヤ名の出現を、結果として生じるCFG−DFGからHDLへのコンバータテーブルにおけるストリングnewsigvalと置き換える。このオプションによって、CFG−DFGからHDLへのコンバータによって接続されるべきハードウェアロジックモジュールの入力および出力信号の改名が可能になる。CFG−DFGからHDLへのコンバータは、名前が“unconnected_”で始まるワイヤに接続されるべきいかなる接続も無視し得る。このオプションによって“unconnected_”ワイヤを改名することによって、これらはCFG−DFGからHDLへのコンバータによって処理され得る。−dオプションに関して、−rはVerilogのようなHDLを生成するときに有用であり、Verilogは、テストベンチまたはシミュレーション環境において用いられ、結果として生じるハードウェアロジックのために生成されたVerilogには実際に存在しない信号を有し得る。多重の−dおよび−rのオプションを指定してもよい。
翻訳プログラムは、構築されるべきCFG−DFGからHDLへのコンバータテーブルを初期化し、かつCFG−DFGからHDLへのコンバータサポートライブラリにおけるgr_tables_initをコールすことによって開始され得る。次に、コマンドラインオプションが処理され得る。−dコマンドラインオプションによって指定された削除済信号のリストを含むキャラクタポインタのアレイが構築される。2つの並列のアレイのキャラクタポインタは、改名された信号(−rオプション)のために構築される。第1のアレイはオプションにおけるsigvalで指定されたストリングを含み、第2のアレイはオプションにおけるnewsigvalで指定されたストリングを含む。第1のアレイにおける所与の改名された信号について、その対応する新しい名前は、第2のアレイの同じ索引に配置される。−oオプションで指定された出力ファイル名は、CFG−DFGからHDLへのコンバータOUTPUT_FILESテーブルに挿入される。
テーブルが初期化され、かつコマンドラインが処理された後で、ハードウェアロジックモジュール情報ファイルはパーズされ、subrefデータ構造のアレイが構成される。任意の数のエントリを含む2つのハードウェアロジックモジュール情報ファイルがあるかもしれない。1つのハードウェアロジックモジュール情報ファイルは、インターフェイスを含むものと想定され、このインターフェイスはコンパイルシステム(組込み演算)に知られる特定のハードウェアロジックモジュールへのデータフローグラフのノードで現れるオペコードをマップするものである。このハードウェアロジックモジュール情報ファイルは、システムハードウェアロジックモジュール情報ファイルと呼ばれ、環境変数を読出すことによって配置される。オプションとしての第2のハードウェアロジックモジュール情報ファイルは、本来コンパイラには知られていないハードウェアロジックモジュールを備えたユーザ、および組込みハードウェアロジックモジュールのいずれの再定義をも与えられたいかなるユーザに対するインターフェイスを含む。ハードウェアロジックモジュール情報ファイルのパーズおよびsubref構造のアレイの生成は、CFGからCFG−DFGへのコンバータと共有される機能、fetch_all_subrefによって行なわれる。fetch_all_subrefのパーザおよび意味ルーチンは、GNUツールのフレックス(flex)およびバイソン(bison)によって生成され得る。
subref構造を用いて、翻訳プログラムおよびCFGからCFG−DFGへのコンバータの内部にあるハードウェアロジックモジュール情報ファイルに情報を記憶する。各オペコード情報ファイルの定義がパーズされると、情報はsubref構造に記憶される。パーズは、すべてのハードウェアロジックモジュール情報ファイルがパーズされ、かつsubref構造のアレイが構築されるまで継続される。翻訳プログラムは次に、一度に1つのsubref構造を処理するアレイを通してループに入り、一方でハードウェアロジックモジュールインターフェイスを保持するCFG−DFGからHDLへのコンバータテーブルを構築する。
subref構造を処理することによって構築されたCFG−DFGからHDLへのコンバータテーブルは、EQUIV_IN, EQUIV_OUT, EQUIV_IN_PRS,PIN_NAMES,HELD,BEHAV_VおよびBEHAV_Cである。これらのテーブルの各々の内容は、(以下の)subref構造の処理の説明で示される。処理される各subref構造のために生成された1つのEQUIV_INおよび1つのEQUIV_OUTテーブルエントリがある。所与のsubrefのためのEQUIV_INおよびEQUIV_OUTテーブルエントリのテーブル索引は同じである。
subref構造の処理は、subref構造のオペコードの名前欄を検査することによって開始される。ハードウェアロジックモジュール情報ファイルエントリで名前が指定されていなければ、エラーが出され、現在のsubref構造の残りがスキップされる。名前が指定される場合、以前のsubref処理から構築されたCFG−DFGからHDLへのコンバータテーブルは、同じオペコード名を有する以前のsubrefがないかを探索される。これが見つかった場合、警告が発せられ、重複して名前をつけられたsubrefのさらなる処理がスキップされ得る。オペコード名のための第1のハードウェアロジックモジュール情報ファイルエントリが用いられる。なおユーザの情報ファイルエントリがパーズされる最初のエントリであり、その対応のsubref構造は最小のアレイ索引を有するsubrefアレイで現れる。したがって、ユーザは本来コンパイラに知られるいかなる所与のオペコードのための独自のハードウェアロジックモジュールを提供し得、subrefアレイの処理の順序のために、そのオペコードのためのユーザのinfoファイルエントリは、システムのinfoファイルにおけるいなかるエントリとも置き換えられる。
EQUIV_IN_PRSにおける最初の自由なエントリの索引が保存され、後で現在のハードウェアロジックモジュール情報ファイルエントリのためのEQUIV_INテーブルエントリに置かれる。これを用いて、ハードウェアロジックモジュールのための第1の入力パラメータを置く。ハードウェアロジックモジュールの待ち時間は、現在のinfoファイルエントリのためのEQUIV_OUTテーブルエントリに後で挿入するために保存される。待ち時間が指定されていないまたはそれが負である場合、エラーが出されて、ゼロの値が待ち時間のために用いられる。
出力パラメータが最初に処理され得る。各出力について、EQUIV_IN_PRSテーブルエントリが生成される。出力のビット幅およびこのsubrefのためのEQUIV_IN/EQUIV_OUTテーブルエントリへの索引がEQUIV_IN_PRSテーブルエントリに挿入される。これが出力であることを示すフラグがEQUIV_IN_PRSテーブルエントリに設定されて、これを入力と区別する。次にPIN_NAMESテーブルエントリが出力パラメータのために生成される。PIN_NAMESテーブルエントリは、出力パラメータの名前、そのビット幅、その以前に生成されたEQUIV_IN_PRSテーブルエントリへの索引、現在のsubrefのEQUIV_IN/EQUIV_OUTテーブルエントリの索引、およびこれが出力ピンのセットであることを示すフラグを有する。これが現在のsubref(モジュールのために処理された最初の出力パラメータ)のために生成された最初のPIN_NAMESテーブルエントリである場合、PIN_NAMESテーブル索引が、現在のsubrefのためのEQUIV_OUTテーブルに後で挿入されるために保存される。
オペコードの出力信号は出力パラメータの後で処理される。−dコマンドラインオプションによって指定された削除済信号のリストを探索して、出力信号をCFG−DFGからHDLへのコンバータHELDおよびPIN_NAMESテーブルに入力すべきかどうかを決定する。これが見つかった場合、信号はスキップされる。そうでなければHELDテーブルエントリが生成される。このHELDテーブルエントリは、信号のための関連したPIN_NAMESテーブルエントリへの索引、信号のビット幅、および出力信号が接続
されるべき外部信号の名前を含む。−rコマンドラインオプションで指定された改名された信号のテーブルを探索して、信号が再びマップされたかどうかを見ることができる。再びマップされていれば、再びマップされた信号名が用いられる。そうでなければ、ハードウェアロジックモジュール情報ファイルで指定された名前が用いられる。外部信号名が指定さない場合、エラーが出される。PIN_NAMESテーブルエントリが、次に出力信号のために生成され得る。PIN_NAMESテーブルエントリは、現在のsubrefエントリのためのEQUIV_IN/EQUIV_OUTテーブル索引、出力信号のビット幅、この信号のために生成されるHELDテーブルエントリの索引、ハードウェアロジックモジュールの内部の信号名、および信号が出力でありかつ信号のためのHELDテーブルエントリがあることを示す2つのフラグを含む。これがsubref構造のために処理される最初の信号である場合、PIN_NAMESテーブルエントリの索引は、subrefのためのEQUIV_OUTテーブルエントリに挿入されるために保存される。
されるべき外部信号の名前を含む。−rコマンドラインオプションで指定された改名された信号のテーブルを探索して、信号が再びマップされたかどうかを見ることができる。再びマップされていれば、再びマップされた信号名が用いられる。そうでなければ、ハードウェアロジックモジュール情報ファイルで指定された名前が用いられる。外部信号名が指定さない場合、エラーが出される。PIN_NAMESテーブルエントリが、次に出力信号のために生成され得る。PIN_NAMESテーブルエントリは、現在のsubrefエントリのためのEQUIV_IN/EQUIV_OUTテーブル索引、出力信号のビット幅、この信号のために生成されるHELDテーブルエントリの索引、ハードウェアロジックモジュールの内部の信号名、および信号が出力でありかつ信号のためのHELDテーブルエントリがあることを示す2つのフラグを含む。これがsubref構造のために処理される最初の信号である場合、PIN_NAMESテーブルエントリの索引は、subrefのためのEQUIV_OUTテーブルエントリに挿入されるために保存される。
出力信号が処理された後で、subrefのための入力パラメータが処理される。EQUIV_IN_PRSおよびPIN_NAMESテーブルエントリが各入力について生成される。EQUIV_IN_PRSエントリの内容は、出力パラメータを示すフラグが設定されていないことを除き、出力パラメータのために生成されたものと内容が一致しているかもしれない。PIN_NAMESテーブルエントリは、出力パラメータを指すフラグではなく、入力を指すフラグが設定されることを除いて、出力パラメータのためのPIN_NAMESテーブルエントリと同じ情報を含む。
入力信号は入力パラメータの後で処理される。各入力信号について、HELDおよびPIN_NAMESテーブルエントリが生成される。入力信号の処理および結果として生じるテーブルエントリは、信号が出力ではなく入力であることを示しているフラグがPIN_NAMESテーブルエントリに挿入されることを除いて、出力信号のそれと同じである。
最後のPIN_NAMESエントリがsubrefのために生成され、最後のエントリの索引は、subrefのEQUIV_OUTテーブルエントリに挿入するために保存される。
最終的に、subrefのためのEQUIV_INおよびEQUIV_OUTテーブルエントリが生成される。このEQUIV_INテーブルエントリは、このsubref構造を処理するために生成された最初のEQUIV_IN_PRSテーブルエントリの索引を含む。このsubrefのための最後のEQUIV_IN_PRSテーブルエントリの索引が生成され、テーブルフローグラフのオペコードの名前はこのsubrefが定義する。EQUIV_OUTテーブルエントリは、関連するハードウェアロジックモジュールの待ち時間、ハードウェアロジックモジュールの名前、subrefと関連した第1のPIN_NAMESテーブルエントリの索引、subrefと関連した最後のPIN_NAMESテーブルエントリの索引を含む。
ここでsubrefの処理が完了する。info2grfはすべてのsubref構造が処理されるまで継続される。処理の際にエラーが発見されなければ、CFG−DFGからDHLへのコンバータテーブルは出力ファイルに書込まれ、ゼロステータスコードが戻される。そうでなければ、テーブルは出力されず、非ゼロステータスコードが戻される。次に翻訳プログラムが終了され得る。
CFGからハイブリッドCFG−DFGへの変換
CFG表現をハイブリッドCDFG−DFG表現に変換するための実施例がここで記載される。もとのCFG表現は、ノードおよび有向の辺(directed edges)を含んでもよく、各ノードはコードの基本ブロックであるかもしれず、各辺は1つのブロックの終わりから別のブロックの始めへの制御の移動を示し得る。基本ブロックにおけるコードは、エン
トランスの単一の点、および単一の出口を有し得、すなわちこれは、始めおよび終わりのそれぞれ以外へ、またはそれ以外から分岐することのできない直線のシーケンスの文を示し得る。基本ブロックにおける文は順次であるかもしれない。
CFG表現をハイブリッドCDFG−DFG表現に変換するための実施例がここで記載される。もとのCFG表現は、ノードおよび有向の辺(directed edges)を含んでもよく、各ノードはコードの基本ブロックであるかもしれず、各辺は1つのブロックの終わりから別のブロックの始めへの制御の移動を示し得る。基本ブロックにおけるコードは、エン
トランスの単一の点、および単一の出口を有し得、すなわちこれは、始めおよび終わりのそれぞれ以外へ、またはそれ以外から分岐することのできない直線のシーケンスの文を示し得る。基本ブロックにおける文は順次であるかもしれない。
ハイブリッドCFG−DFG表現は、その上位レベルでCFG表現を有し得るが、各コードブロックにおいてデータフローグラフを有する。一実施例において、CFGからCFG−DFGへの変換は、内部ループをフラットでおそらくパイプライン化されたコードブロックへと形成するグループを含む基本ブロックのグループを統合し得る。
図7は、以下のコードフラグメントに対応するCFGの一部の例を示している。
この例において、‘a’および‘b’を比較する条件テストは、レジスタまたは一時変数に記憶され得、これはその基本ブロックにおける最後の文であるかもしれない。比較の結果に基づいて、制御は条件付き構成体の「真」および「偽」の部分を示す2つのブロックのうちの1つに移動され得る。これらのブロックの各々は、その文を実行した後で、制御を条件に従うコードを含むブロックに移動し得る。なお、CFGにおけるコードブロックは順次の文を含み得、この各々はレジスタまたは変数を読出し、書込むことによってこれらを参照し得る。さらに、ブロック間の有向の辺は、1ビットの「トリガ」信号としてみなされる制御の移動を示し得ることに注目されたい。
CFG表現は内部中間表現のように多くのコンパイラにおいて用いられるかもしれないが、データフローグラフは通常用いられない。なぜなら、データフロー実行パラダイムは、任意の多くの機能ユニットの使用および非同期の実行のため、従来のノイマン型プロセッサにあまり適していないからである。しかしながら、データフローモデルは再構成可能なハードウェアに非常入力よく適している。データフローグラフにおいて、ノードは機能ユニット(たとえば整数の加算)を示すかもしれない。ノード間の有向の辺は、1つの機能ユニットからの出力データ項目を他の機能ユニットの入力にもたらすデータ接続を示し得る。図4は以下のコードフラグメントのデータフローグラフを示している。
入力値の‘b’および‘c’がグラフの上部にロードされ得る。これらの値はLOADノードの出力ポート(底部)から流れ得る。データフローグラフでは、命令レベルの並列性が明らかにされ得る。ここで、3つの命令(2つの乗算および1つの減算)が同時に起こり得る。なお、‘d’変数は記憶を必要としないかもしれない。なぜならこれはグラフのローカルにあるかもしれず、辺として存在するかもしれないからである。さらに、‘a’に割当てられた中間値はその変数に記憶されず、単に辺として存在するかもしれない。なぜなら以下の順次の割当では‘a’の最終値が生成されるかもしれないからである。このようなデータフローグラフは、選択された機能ユニットを初期化することによって、再構成可能なハードウェアに直接マップされ得る。この例において、1つの加算、2つの減算、および2つの乗算が生成される。
CFG表現の各基本ブロックにおける順次の文は、データフローグラフに変換されることにより、ハイブリッドを生成し、このハイブリッドで上位レベルのノードはシングルビットの辺を有するコードブロックであり、各ブロック内では、ノードが機能ユニットであり、かつ辺がデータ接続であるデータフローグラフであるかもしれない。図8は、図7のCFGに適用されたこのような変換の例を示している。
本発明の実施例において、CFG表現における基本ブロックの部分集合は、単一のデータフローコードブロックにマージされ、条件は、双方の側を計算し、次に条件の述語式に基づいて適切な値を選択することによって処理され得る。図9は、このようなコードブロックの例を示しており、ここでは図8のコードブロックがマージされる。
スカラおよびアレイデータのタイプに追加して、高級言語はより単純なタイプの複合であるかもしれないユーザ指定のデータタイプの構造を有し得る。従来のコンパイラのフロントエンドは、CFG表現を生成するときに、生成する基本ブロックにおいて適切なアドレス計算をもたらすことによってこれらを処理し得る。このような構造がローカルメモリであるときに、アドレス計算は、グラフをコントロールデータフローグラフに変換する際に変更されないままであるかもしれない。ローカル変数としての構造の場合、変換プロセスは、アドレスのオフセットとともにタイプ情報を用いて、構造のどのフィールドが参照されるべきかを決定する。
ポインタは、目標のマシンのアーキテクチャの詳細に従って扱われ得る。再構成可能なハードウェアが、それに対するアドレスパラメータを渡したプロセッサと同じメモリ空間を「見つけた」場合、ポインタ演算は修正されずに作用し得る。これを見つけられなかった場合、調整因子がランタイムで計算される。この因子は、プロセッサのメモリにおけるアドレスおよび、データが再構成可能なハードウェアのOBMにコピーされた場所の差であるかもしれない。制御データフローグラフは、ポインタを参照するときにこの因数の加算を含み得るように生成される。
従来の高級言語は、小さな組をなす固定サイズの算術データタイプ(たとえば32ビットの整数および64ビットの整数)を有し得る。これは、目標にするノイマン型プロセッサが固定サイズの機能ユニットを有し得るということに対応している。再構成可能なハードウェアにおいて、いかなるビット幅の機能ユニットもインスタンス化することが可能であるかもしれず、これは所与のプログラムに必要とされる量の精度を用いることによってスペースの節約を達成し得る。この節約を行ない得る1つの方法は、高級言語をユーザ指定のビット幅を有する新しいデータタイプを含むように拡張することであるかもしれない。別のアプローチは、ユーザがソースコードのセクションのための標準タイプ(たとえば“int”)のビット幅を指定することができるようにすることであるかもしれない。
コンパイラが、一部の機能ユニットおよびそれらが接続されるデータ経路の精度を減じ
ることの安全性を推論することが可能であるかもしれない。たとえば、
ることの安全性を推論することが可能であるかもしれない。たとえば、
のコードにおいて、加算の演算を8ビットの加算器に変更することが無難であるかもしれない。なぜなら、高いビットの結果は、その結果を割当てるときに失われるかもしれないからである。
別の実施例において、CFG表現の制御データフローグラフへの翻訳の構成要素は、オペレータおよび既存のハードウェアロジックモジュールへの関数コールのマップを記述するデータベースであるかもしれない。このデータベースは、「infoファイル」と呼ばれるかもしれず、コンパイルの際にさまざまなステップで用いられるかもしれない。
関数コールは、コールされるルーチンの性質に依存してさまざまな方法で扱われ得る。すなわち、ルーチンがハードウェアロジックモジュールを有する「infoファイル」を介して関連付けられた場合、単一のノードがデータフローグラフにおいて生成されて、それを機能ユニットとして示し得る。ルーチンが適切な基準に達した場合、これはコール機構を必要としないようにインライン化され得る。関数が末端再帰的である場合、これはループに変換され得る。関数が上記のカテゴリに当てはまらない場合、スタック志向のコール機構が用いられ得る。別の実施例において、LIFOスタックが再構成可能なロジックで実現されてもよく、このロジックは、再帰が起るとローカル変数のさまざまなインスタンス化を保持し得る。スタック情報は、制御の流れを、再帰的なコールの復帰が適切に生じるように導き得る。
ハイブリッド制御データフローグラフは、それ自身を再構成可能なハードウェアにコンパイルしたサブルーチン内の実行の多重スレッドに適合させ得る。高級言語の意味が順次の実行(1コードブロックはいかなる所与の時間でも活動状態であり得る)を指定する一方で、コードブロックレベルでの並列性は、コンパイラが、並列な実行が不正確な結果をもたらさないと決定することができるときに実現しやすいかもしれない。この決定は、言語およびその可能な拡張に依存してさまざまな方法で行なわれ得る。たとえば、言語が並列の構成体を含む場合、並列性はCFG表現の一部で生じるかもしれない。さらに、逐次型言語はユーザプラグマによって拡張されるかもしれず、このユーザプラグマによって、プログラマはコンパイラを、コード並列のある部分を生成するように導くことができる。分析によって、コンパイラは、あるコードブロックが並列した状態で無事に実行され得ることを証明することができる。
図11は、左にCFG表現の順次の部分を、右に2つのコードブロックが並列に置かれた変形されたグラフを有する実施例を示している。先行のブロックからのトリガ信号は、双方の並列したブロックをトリガするように広がり、LATCH_ANDと呼ばれる「結合」機構を用いて、2つのブロックからの「完了(done)」信号をマージし得る。LATCH_ANDは、ハイになったときに各入力信号をラッチするように設計されて、入来トリガが同時に起らないようにし得る。
制御データフローグラフの接続性の情報を用いて、FPGAにおける論理配置の性能を向上させ得る。現在の位置およびルートツールにおいて、配置の問題は非常に低位レベル
で見られ、配置される項目は非常に小さな論理ブロックであるかもしれない。コンパイラが利用できるハードウェアロジックモジュールが指定された形状であると既に決定されている場合、コンパイラは、さらに高度な、したがってさらに単純な細分性のレベルで配置を行い、プロセスを潜在的にかなり高速化することができる。
で見られ、配置される項目は非常に小さな論理ブロックであるかもしれない。コンパイラが利用できるハードウェアロジックモジュールが指定された形状であると既に決定されている場合、コンパイラは、さらに高度な、したがってさらに単純な細分性のレベルで配置を行い、プロセスを潜在的にかなり高速化することができる。
図12は、サブルーチンのCFG表現をハイブリッド制御データフローグラフに変換するための最高レベルにおけるプロセスを示す。1つ以上の「infoファイル」が読込まれて、再構成可能ロジックとしてのデータフローグラフの実現のために利用可能であり得る利用可能なハードウェアロジックマクロについての情報が入手され得る。CFG表現をその内部データ構造の中に読込んだ後、コンパイラは「外部」ハードウェアロジックモジュールコールを個々のブロックに分離し得る。これが行われ得るのは、外部モジュールがそのコードブロックの外側のリソースと対話し、並行的に実行する場合には乱調状態が結果として生じ得るからである。次に、図10の例におけるように、個々のブロックはより大きなブロックへと組合せられ得る。
次に各々のブロックが処理され得る。非ループのブロックの場合、参照される種々のスカラ値についてLOADノードが作成され得る。次に、ブロックの計算のデータフローグラフが作成され得る。最後に、各々のスカラ変数につきSTOREノードが作成されてその終値が記憶され得る。内部ループはいくらかの追加の処置を必要とし得る。内部ループのヘッドブロックが見つかると、このループのブロックの残りが集められて位相的にソートされ得る。次に、LOADおよびCIRCULATE(循環)ノードが当該のスカラについて構築され得る。次に、ループのコードブロックは、非ループブロックのそれに類似の仕方で処理され得る。
各々のDFGが作成された後、データフローグラフを通じて(クロックの刻みで測ることのできる)経路長さのバランスをとるために遅延ノードが挿入され得る。次に、上記グラフに対して種々の最適化が実行され得る。DFGがすべて作成された後、これらはDFGファイルに書込まれてロジックエミュレートファイルが作成され得る。
CFG表現は2つの部分、すなわち、オペコードのアレイと基本ブロックのシーケンスとから構成され得る。オペコードは、構造からなるアレイであってその要素が1オペコードとこのオペコードのデータソースへの参照とからなる、構造からなるアレイに読込まれ得る。CFG表現における各々の基本ブロックは、以下に示すような構造内に記憶され得る。
或るブロックについてデータフローグラフが構築されると、そのノードは基本ブロック構造の「プール」フィールドの中で割付けられ得る。データフローノード構造の一例を以下に示す。
一実施例では、出力として2つのファイルが書込まれ得る。すなわちデータフローグラフファイルとエミュレートロジックファイルとである。これらのファイルの例として以下の単純なCソース関数があり得る。
以下のコードの例は、C関数の例がコンパイルされると生成され得るデータフローグラフファイルを示す。
上記のデータフローグラフの例は2つのセクションを有する。その第1はパラメータおよびローカル変数のリストであり、名前、タイプおよび種類(パラメータまたはローカル
)による。第2のセクションはコードブロックをリストにしたものである。この例においては、コードブロックはマージされていない。各々のブロックは一義的なID数および1組のデータフローノードを有する。各ブロックはいずれも、その始まりのノードおよび終わりのノードとしてSRC^INITIATE(開始)ノードおよびSRC^OUTPUT(出力)ノードを有する。各々のノードにつき以下の情報がある。すなわち、その機能、その入力および出力カウント、各々の入力のビット幅、入力が定数として指定される入力についての定数値、各々の出力のビット幅、各々の出力の目標リスト(すなわち他のノード入力ポートのうちどれがこの出力によって供給がなされるのか)、である。入力および出力ポートはまた括弧の中に一義的な擬似レジスタIDを有し得る。
)による。第2のセクションはコードブロックをリストにしたものである。この例においては、コードブロックはマージされていない。各々のブロックは一義的なID数および1組のデータフローノードを有する。各ブロックはいずれも、その始まりのノードおよび終わりのノードとしてSRC^INITIATE(開始)ノードおよびSRC^OUTPUT(出力)ノードを有する。各々のノードにつき以下の情報がある。すなわち、その機能、その入力および出力カウント、各々の入力のビット幅、入力が定数として指定される入力についての定数値、各々の出力のビット幅、各々の出力の目標リスト(すなわち他のノード入力ポートのうちどれがこの出力によって供給がなされるのか)、である。入力および出力ポートはまた括弧の中に一義的な擬似レジスタIDを有し得る。
各々のブロックの終りは、ブロックから出るときに制御フローがどこへ行くのかを指定し得る。ブロックが条件文で終わるときには2つの目標ブロックかTRUEおよびFALSE目標として指定され得る。他では、1つのブロックが指定され得るか、または、ブロックが関数の終了であればEXITが指定され得る。図13はこのコードブロック組を図示するものである。
データフローグラフファイルとともにエミュレートロジックファイルもまた書込まれ得る。これはスレッドとして実行され得る単純なCルーチンであって、プログラムの再構成可能ロジック部分をエミュレートするものであり得る。C関数の例についてのエミュレートロジックファイルの一例を以下に示す。
上記のエミュレートロジックファイルの例では、無限ループがFPGAとして働き得る。したがってこれは同じプロトコルに従ってもよく、この例では開始および終了ハンドシェイクとしてそれぞれフラグレジスタFR2およびFR4を用いる。開始信号がFR2か
ら受取られると、エミュレートルーチンはユーザサブルーチンのパラメータについての初期値をロードし得る。次にdfg_simulateがコールされて、実行されるべきDFGファイルの名前が中へ通され得る。データフローシミュレータはトークン駆動シミュレーションを行ないEXITコードブロックの完了時に戻り得る。それからパラメータの終値が返されてこれにFR4ハンドシェイクが続き得る。次にルーチンはループの最上部へ戻って、実行すべき次の信号を待つことができる。
ら受取られると、エミュレートルーチンはユーザサブルーチンのパラメータについての初期値をロードし得る。次にdfg_simulateがコールされて、実行されるべきDFGファイルの名前が中へ通され得る。データフローシミュレータはトークン駆動シミュレーションを行ないEXITコードブロックの完了時に戻り得る。それからパラメータの終値が返されてこれにFR4ハンドシェイクが続き得る。次にルーチンはループの最上部へ戻って、実行すべき次の信号を待つことができる。
次に、CFGにおける基本ブロックの、DFGにおけるコードブロックへの変換についての別の実施例について説明する。この実施例においては、ロード/記憶は、スカラ参照であるかアレイ参照であるかに依存して2つの異なる仕方で扱われ得る。スカラ参照はDFG辺に変換され得るが、ここで単一のロードがブロックの開始部にあり、単一の記憶が終了部にある。アレイ参照はオンボードメモリ(OBM)参照へと変換され得る。
参照渡し(pass-by-reference)パラメータについてのスカラ変数参照はローカル変数参照とは異なり得る。コンパイラのフロントエンドのCFG出力はこれを反映し得る。すなわち、或るレベルの間接をこのようなパラメータ参照の中に置くことがあり得る。図14はこの区別を例示する。
別の例として以下の演算の組について検討する。
図15に示すように、フロントエンドはそのCFG出力において1組のオペコードを生成し得る。これはFortranソースであったため、スカラは参照によって持ち込まれ得て、LDA(ロードアドレス)ノードは、これに入力され得るアドレスからアドレスをフェッチすることで間接ステップを実行することができる。
グラフ共有は共通の部分式を表わさないこともあることに注目されたい。たとえば、ノードの出力は2つの場所に行ってコードにおいて変数‘c’についての2つの読取値を表わす場合がある。しかし、これら2つの読取値は同じ値を生成しないことがあるが、それはその間に介在する記憶があり得るからである。
一実施例において、基本ブロックの処理における最初のステップは、オペコードからデータフローグラフフラグメントを構築することであり得る。これは、各々のアンカー(最下部)オペコードで開始しその上に再帰的に木を構築するルーチンによって行なわれ得る。フラグメント間での共有はあり得ないため、このルーチンの結果は図16に示すフラグメントを構築することであり得る。
一実施例において、DFGフラグメントの構築後、スカラ参照渡しパラメータを担うACON(アドレス定数)の下からLDAノードがなくされ得る。これが反映しているのは、MAPコンパイラ(すなわちシステムのうち、再構成可能ハードウェアへHLLソースコードの一部をコンパイルする部分)がこれを参照によるのではなくコピー・アンド・リストアとして扱い得る、という事実である。これに伴い、DFGフラグメントは図17に示すようなものとなり得る。
次に、アンカーから始まって上方を向いてACONを見つけることにより、参照される
変数すべてのリストが作成され得る。DFGのヘッドとしてINITIATEノードが作成され、スカラの初期値を持ち込むためのLD_SCALARノードの層が作成され得る。データ構造の一時アレイが各々の変数のソースについての参照として作成され得る。この構造の一例を以下に示す。
変数すべてのリストが作成され得る。DFGのヘッドとしてINITIATEノードが作成され、スカラの初期値を持ち込むためのLD_SCALARノードの層が作成され得る。データ構造の一時アレイが各々の変数のソースについての参照として作成され得る。この構造の一例を以下に示す。
このアレイを初期化してそのLD_SCALARノードに変数すべてを参照させることができる。サブルーチンおよび関数コールが処理されてからDFGフラグメントがDFGへ変換され得る。
一実施例において、CFGからDFGへの変換は、各々のDFGフラグメントの最下部で開始して以下のことを行なうルーチンであり得る。すなわち、上方へスキャンしてロードノードを見つける。各々のロードにつき、その上にあるACONを見てどの変数がロードされているかを決定する。ロードノードをなくしてから目標となっているノードを配線し直し、この変数の現在のソースによって供給がなされるようにする。アンカーがスカラの記憶であれば、右側の入力を見てどの変数が記憶されているかを判断する。次に、記憶ノードがなくされてノードの左のソースがその変数についての新たなソースとして記録され得る。
この例においては、最初のアンカーが処理されると、値‘b’および‘c’についてのLDKRノードを見つけることができる。これらはなくすことができ、これらが供給をするノードを配線し直してDFGの最上部にあるLD_SCALARノードから供給がなされるようにできる。次に、STKRノードをなくしてKADDノードを一時アレイにおいて変数‘a’の新たなソースであるとして示すことができる。次のアンカーが処理されると、その2つのLDKRノードを見つけることができる。‘b’値のソースはなおそのLD_SCALARノードであり得るが、‘a’値のソースはKADDであり得る。LDKRノードをなくしてその目標を適当なソースへ配線することができる。次にSTKRノードをなくしてKSUBノードを変数‘c’の新たなソースとして示すことができる。3番目のアンカーが処理されると、そのLDKRをなくしてその目標をKSUBの出力へ配線し直すことができる。次に、STKRをなくしてKMULを変数‘a’の新たなソースとして示すことができる。
アンカーがすべて処理された後、ST_SCALARノードの層を作成することで、スカラの終値を、これら変数の最後のソースを参照することで記憶させることができる。ST_SCALARはLATCH_ANDノードへと集められ得るトリガ出力を有し、このノードはDFGの最下部にあるOUTPUTノードの供給をすることができる。出力が未使用であるLD_SCALARノードはいずれも用済みコード除去パス(pass)によってなくされ得る。コンパイラはまた、この変数のLD_SCALARノードから来る値を記憶しているST_SCALARノードを探すことができ、これらについての値は変化していないのでこれらをなくすことができる。図18は、この例についての結果のDFGコードブロックの一例を示す。
一実施例において、DFG生成部は、スカラ変数のロード/記憶とアレイ要素のロード
/記憶とを区別し得る。DFG発生器はロードまたは記憶ノード(たとえばLDKRまたはSTKR)を見ると、そのアドレス入力を見ることでロード/記憶の種類を決定することができる。図14に示す形での何かを見ると、ACONノードを用いて変数の名前を見つけることができ、内部「変数」データ構造を調べてこれがスカラ変数であるかどうかを判断することができる。
/記憶とを区別し得る。DFG発生器はロードまたは記憶ノード(たとえばLDKRまたはSTKR)を見ると、そのアドレス入力を見ることでロード/記憶の種類を決定することができる。図14に示す形での何かを見ると、ACONノードを用いて変数の名前を見つけることができ、内部「変数」データ構造を調べてこれがスカラ変数であるかどうかを判断することができる。
図19はアレイ参照の一例を示す。ハードコードされた「1」索引のこの例においては、参照は構造的にスカラローカル変数参照と同じように現われ、「変数」構造を調べることでこれがアレイであり得ると知られ得ることに注目されたい。また、ACONノードが変数名および定数オフセットを有し得ることに注目されたい。図19における2番目の例では、参照が基底アドレスから6要素離れておりかつ各々の要素のサイズは8バイトであるという事実から48のオフセットが導き出される。3番目の形では、アドレスは表現木によって供給がなされる。ここでは‘BB’についてのACONノードには−8のオフセットが与えられ、アレイの索引が1で始まるという事実を補償している。アドレスはバイト指向であるためIMULノードは8倍し得る。
アレイ参照についてのロードおよび記憶ノードを定位置に残しておくこともできるが、各々の記憶ノードには追加のイネーブル入力を与えることもできる。基本ブロックの場合、このイネーブル入力はブロックのINITIATEノードによって供給がなされ得る。
もう1つの、ブロックのCFGがDFGに変換される実施例においては、アンカーは記憶でなくサブルーチンコールであり得る。以下のコードフラグメントを検討する。
このコードについてのフロントエンド出力を図20の左に示す。これはARGARノードについてのリンクされたリストによって供給がなされて、各々が1つの引き数をコールへ持ち込むことがあり得る。DFG生成部がオペコードからDFGフラグメントを構築した後、サブルーチンコールアンカーを見つけるルーチンがコールされ得る。これは各々1つにつきARGARノードについてのリンクされたリストをなくすことができ、複数のコールノードに、それらが配線されている、引き数を有する多重入力を与える。これにはサブルーチンについての知見が必要であるが、これは‘info’ファイルから引出され得る。状態を持つノードについては、イネーブル信号への接続のために付加的な入力が作成され得る。外部ノードについては、トリガおよび完了(done)信号のために付加的な入力および付加的な出力が与えられ得る(このステップが実行されているときにまでにはスカラパラメータのための付加的な間接は既になくされている場合もあることに注目されたい)。
infoファイルは各々の引き数につきそれが値であるかアドレスであるかを指定し得る。さらに、どれが入力でどれが出力かを指定し得る。入力引き数が値である(しかし定数ではない)場合、適当なロードノードが作成され得る。アドレスである場合には変化のないまま残され得る。この例の場合、これが2入力、1出力のサブルーチンであると仮定する。図20の中央において、コールがDFGJSRに変換されてLDKRノードが2つの入力について追加された後におけるサブルーチンコールについてのDFGコードフラグメントが示される。
サブルーチンコール処理中でその後に、DFGJSRノードはinfoファイルがもう1回
調べられることを引き起こし得る。2つの入力は他のノードへの入力と同じ仕方で扱われ得る。すなわち、変数のソースが示され、LDKRノードがなくされ、そして入力がソースへ直接配線されるということがあり得る。出力については、入来する辺がなくされ、ACONノードを調べてどの変数が出力値を受取っているかが判断され、そしてこの出力をその変数の新たなソースとして示すということがあり得る。図20の右側においてDFGへの変換後の完全なコードブロックが示される。
調べられることを引き起こし得る。2つの入力は他のノードへの入力と同じ仕方で扱われ得る。すなわち、変数のソースが示され、LDKRノードがなくされ、そして入力がソースへ直接配線されるということがあり得る。出力については、入来する辺がなくされ、ACONノードを調べてどの変数が出力値を受取っているかが判断され、そしてこの出力をその変数の新たなソースとして示すということがあり得る。図20の右側においてDFGへの変換後の完全なコードブロックが示される。
組込関数へのコールはCFG出力において非アンカーJSRおよびQJSRノードとして現われ得る。サブルーチンコールに対処がなされた後、残っているJSRおよびQJSRノードは関数コールであり得る。
このような関数コールの一例を以下に示す。
この関数コールのもたらすCFGは、その2番目の割当てが図21に示されるものである場合がある。サブルーチンコールについてと同様、これの引き数はリンクされたリストを形成する。この図の中央に示すように、引き数は多数の入力へと平らにされ得る。この点から、DFGの構築は一般的な仕方で行なうことができ、その結果図21の右側に示すグラフが得られる。
基本ブロックは条件文で終わることがある。この場合、OUTPUTノードへの2番目の入力は比較の結果によって供給がなされ得る。一例として以下のコードを検討する。
“a=a+1”文は基本ブロックの一部ではないことに注目されたい。このブロックは条件検査で終わる。最後のアンカーはICJMPZノードであり、その上の構造を図22の左側に示す。QJSR、DFRIRおよびICJMPZノードはKCJMPで取って代わられる。この後、KCJMPがKCMP_leにされ得る。右側にコードブロックについてのDFGを示し、ここではKCMP_leノードは‘a’の終値によって供給がなされ得てその出力はOUTPUTの2番目の入力へ行く。
図9および図10に示したように、基本ブロックは単一の大きなコードブロックへとマージされ得る。このプロセスは、コードブロックの内部の条件文に対処するために、すべての経路を計算し、SELECTOR(セレクタ)ノードと呼ばれるマルチプレクサを用いて適当な値を選択するステップを含み得る。一例として以下のコードを検討する。
この例においては、aa+1およびaa−1両方の式は各々の反復において計算され、‘BL’アレイに割当てられた‘bb’値はSELECTORによって供給がなされる。マージされたコードブロックをさまざまな基本ブロックから構築するジョブは、個々のブロックについてDFGセグメントを構築するステップと、条件文の述語表現から導き出された制御信号およびセレクタを用いてこれらを配線し合わせるステップとを含み得る。
一実施例において、マージされたコードブロックの作成における最初のステップは、マージされた基本ブロックを位相的にソートするステップを含み得る。ブロックが処理される際、所与のブロックに制御を供給するブロックはそのブロックの変換前に変換され得る。処理における早いステップにおいて、各々のブロックは個々のブロックに類似のDFGに変換され得る。LD_SCALARノードはDFGの最上部に構築され得る。次に、コードブロックが変換され得る。マージされたコードブロックと個々の基本ブロックとの異なりは、ブール制御信号およびセクタノードフックアップ(selector node hookup)を含み得る。
一例として、マージされるべき1組のブロックにおける恣意的なブロック‘B’であって、3つのブロックが制御を‘B’に送ることができ、‘B’が制御をその終了時に2つのブロックのうちの1つに送る、ブロック‘B’について検討する(制御をブロックに送ることができるブロックの数は任意であるが、所与のブロックは2つのブロックに制御を送ることに注目されたい)。図23の左側ににこれを示す。制御をブロック‘B’に転送していればハイである入来するブロックの各々からの1ビット信号があると仮定する。ブロック‘B’のアクティブ信号は、入来する信号のORをとることで計算される。次に、ブロック‘B’は、自らが起動し得る2つのブロックについて起動信号を計算し得る。‘B’は、2つのブロックを起動できるので条件文で終わる。この条件文の述語とブロックの起動信号とのANDをとることにより、「真」の信号についての起動信号をもたらし、反対の述語とブロックの起動信号とのANDをとることにより「偽」の信号についての起動信号をもたらす。図23の右側に、‘B’においてこれら信号を計算するノードを示す。
基本ブロックデータ構造は、以下のものを含み得る制御情報を記憶するフィードを有する。すなわち、「入来」フィールドは、現在のブロックへ制御フロー辺を有するブロックのすべてについてのリンクされたリストである。「アクティブ」フィールドは、ノードであってその出力が現在のブロックのアクティブな信号すなわちORノードシーケンスの出力を表わすノード、のIDである。“src_true”フィールドは、「真」の出力制御信号を計算するノードのIDである。“src_false”フィールドは、「偽」の出力制御信号を計算するノードのIDである。
制御信号の構築後、セレクタは入来するデータ値についてインストールされる。図23は、図24の例に追加されたセレクタノードを変数‘x’について示す。ORチェーンからの出力はこれらセレクタの供給し得る。ループ内の各々の変数につき1組のセレクタが作成され得る。
内部ループの、パイプライン化されたDFGへの変換は、上述の変換技術に基づき得る。以下に示すループの例を検討する。
このループは単一の基本ブロックであり、それ自身への条件分岐を伴っている。図25A,25Bはアンカーについてのコードフラグメントを示す。その1番目のものは‘AL(i)’を読込んでこれを‘aa’に記憶する。2番目のものはサブルーチン‘xyz’をコールする。3番目のものは‘bb’を“BL(i)”に記憶する。4番目のものは‘i’を増分する。5番目のものは‘.Y0001’を減分する。6番目のものは‘.Y0001’を検査し、これがゼロよりも大きい場合にこのブロックへ分岐して戻る。
このループのコードブロックは基本ブロックの手法を用いて変換され得る。ブロックが発火(fire)されるたびに、これはそのロードを行ない、その値を計算し、その記憶を行なうことになる。次に、それは制御を自分自身に渡して次の反復について繰返す。この実行にはいくらかの命令レベル並列性があり得る。別の実施例において、アレイ値が読込まれて各々すべてのクロックで書込まれ、種々の機能ユニットについてのパイプライン化された実現を利用する。
パイプライン化された実行を達成するために、ループ「生成部」を作成することができ、これは指定された間隔で反復を発火することによりループを制御する。このノードはLOOP_DRIVERと呼ばれ得る。これはコードブロックのヘッドでINITIATEノードによりトリガされ得て1列のパルスの放出を開始し得る。各々のパルスはループの1反復の発火を合図し得る。LOOP_DRIVERノードはループが終了したときを決定しない場合がある。データフローグラフにおける他の部分が終了条件について検査し得る。反復は、各々のクロックの刻みごとに発火され得るか、またはループキャリー依存性もしくは多数のOBMアクセスに対応できるように遅くされ得る。LOOP_DRIVERノードへの入力はその「デューティサイクル」(すなわち反復の発火同士の間に生じるべきクロックの刻みの数)を指定し得る。
ループキャリースカラ依存性は、パイプライン化されたループでこれらを管理するための機構があることができるように存在し得る。CIRCULATEノード(32または64ビット形式)はスカラ変数の現在の値を保持するために存在し、LOOP_DRIVERノードの出力に接続され得る。CIRCULATEは、その1番目の入力がハイになるのを見ると、ループがスタートアップしつつあることを知る。その2番目の入力から初期値を取り込み得て、その後これに続いて、LOOP_DRIVERが反復を発火するたびごとにその3番目の入力から新たな値を取込む。この3番目の入力はその「循環させられた」値である。スカラ変数がループ内でその値を変化させない場合、CIRCULATEノードの出力はそれ自身の3番目の入力に直接接続され得る。
一実施例において、ループ終了はループ本体におけるどこかで条件検査により決定され得る。ループはパイプライン化され得るため、終了条件が検出されるときまでには既にいくつかの追加の反復が行なわれている場合がある。これらオーバーフローの反復は、値をOBMに書込まないようにされている限り有害ではない。したがって終了検出はループ内でOBM記憶へイネーブル信号をゲーティングし得る。またTERMINATION(終了)ノードをトリガすることがあり、これはST_SCALARノードに合図してスカラ変数の現在の値を取込ませる。
図26は、図25A,25BのループについてのDFGの一実施例を示す。LD_SCALARノードの最上層およびST_SCALARノードの最下層は単純な基本ブロックDFGにおけるのと同じであり得る。網掛けを付した区域はグラフのループ固有の部分を示す。変数‘al’、‘bl’、‘.Y0001’および‘i’についてCIRCULATEノードがある。これらのうち最初の2つは、変化しない基底アドレスであり得る。最後の2つはそれぞれダウンカウンタおよびアップカウンタである。LOOP_DRIVERはループの制御部である。その2番目の入力にあるゼロは、それがループ反復同士の間にクロックの刻みを挿入する必要がないことを示している。CIRCULATEノードは、LOOP_DRIVERの出力信号を監視するものであり、これが新たなループ反復を示すたびごとに上記ノードはその循環する入力値を取込む。ループ終了は、ダウンカウンタをゼロと比較するIGTノードにより検出され得る。IGTの出力が偽になると、LOOP_VALIDはこれを検出してLDKRおよびSTKRノードをディセーブルし、TERMINATIONノードを合図する。そしてTERMINATIONノードはST_SCALARをトリガし、これがCIRCULATEノードから終値を取込めるようにする。
一実施例において、各々の機能ユニット内のパイプライン化されたロジックは各々のクロックの刻みごとにアクティブになり得る。所与の機能ユニットの入力ポートに現われる値につき適当な「マッチング」が行なわれ得る。図27の左側に、ノードの隣にいくらかの待ち時間をもって式C=A−(A+B)*Bを計算するDFGフラグメントを示す。その下は、各々のクロックの刻みにおける信号の値を示すチャートである。ノードの待ち時間のため、乗算および除算ノードのポートに現われる値は適切に整列されないことがある。右側に示すように、固定長のFIFO待ち行列であるDELAY(遅延)ノードが挿入され得る。この挿入は、DFG内の各々すべてのノードにつき、その入力すべてへの経路長が等しくなるように行なわれる。
DFGの構築後には種々の最適化が実行され得る。たとえば、制御データフローグラフコードブロックの作成後、グラフ内のいくつかのSELECTORノードは、同じソースから供給された両方の値入力を有し得る。このようなノードはなくしてもよいが、それは供給をする述語値にかかわらず同じ値が選択されているからである。この状況は、基本ブロックがマージされて1つのより大きなコードブロックを形成する際にしばしば生じる。図28は、以下のコードフラグメントがそのブロックをマージされたときに生じるコードブロックの一部を示す。
この例では、最も右側のSELECTORにおける2つの値入力は同じソースから供給されるが、それは、‘c’は条件文についてのいずれかの分岐において割当てられていないからである。このSELECTORはなくしてもよい。
別の例では、マージされたコードブロックはしばしば、ブール演算式の簡略化のための機会を示す。図28は一例を示す。ORノードの出力はブール演算式‘ex+ex’であり、これはeへと簡略化する。ORノードはなくされ得る。入れ子にされた条件文がマージされるときには上記に似たもっと顕著な機会が生じる。また、パイプライン化されたループコードブロックがヒューズ(fuse)されることもあり、これにより1つのループから出力値を直接別のループに供給する。
区分化部
次に図29を参照して、本発明の区分化部要素の一実施例を示す。一実施例において、区分化部要素は、アルゴリズムの一部が実行されることになるところを決定でき、したがってコンパイルプロセスの目標を決定できる。区分化部は、制御データフローグラフに対して、コンパイルされているアルゴリズムを定義するHLLの内部表現を演算し得る。区分化部により取られる制御データフローグラフは、CFGからCFG−DFGへのコンバータにより生成されるCFG−DFGであり得る。CFG−DFGは、コンパイルされているファイルの中に見つかり得る1組の関数のグラフである。決定プロセスの結果、命令プロセッサのための命令を目標としたコードのうちの部分と、多数の再構成可能プロセッサの中に入っている多数の再構成可能チップ内のロジックのうちの部分がもたらされる。
次に図29を参照して、本発明の区分化部要素の一実施例を示す。一実施例において、区分化部要素は、アルゴリズムの一部が実行されることになるところを決定でき、したがってコンパイルプロセスの目標を決定できる。区分化部は、制御データフローグラフに対して、コンパイルされているアルゴリズムを定義するHLLの内部表現を演算し得る。区分化部により取られる制御データフローグラフは、CFGからCFG−DFGへのコンバータにより生成されるCFG−DFGであり得る。CFG−DFGは、コンパイルされているファイルの中に見つかり得る1組の関数のグラフである。決定プロセスの結果、命令プロセッサのための命令を目標としたコードのうちの部分と、多数の再構成可能プロセッサの中に入っている多数の再構成可能チップ内のロジックのうちの部分がもたらされる。
区分化プロセスは、入力として単一の制御データフローグラフを取って1組の出力制御データフローグラフを生成することがあり得る。その各々は特定の目標化した実現による。出力CFG−DFGは、元のもののサブグラフである区分ブロックと、区分化されたコード間の接続を表わす辺とから構成され得る。
区分化部の決定は以下を含むいくつかの要因に基づく。すなわち、入力制御データフローグラフの性質、利用可能なハードウェアリソース、およびハードウェアリソースのサイズと性能特性、等の要因である。
多数の区分化アルゴリズムを考案可能であり、代替的なアルゴリズムを呼出して決定プロセスで評価することができる。各々のこのような区分化プロセスは、最適化戦略に従うハードウェアリソースの目標化を目的とする。入力制御データフローグラフは、1組の最適化基準を満たしながらハイブリッド計算プラットフォームの利用可能なリソース内に合う1組の接続されたサブグラフを作成し得ることとする。最適化基準はたとえば、再構成可能リソースの使用を最大化する、再構成可能チップの数を最小化する、相互接続を最小化する、または全体の性能を最大化する、等であり得る。
初期制御データフローグラフから、区分ブロックおよび辺から構成され得る新たなグラフが作成される。各々の区分ブロックは、元の制御データフローグラフ(すなわちCFG−DFG)のサブグラフと、再構成可能チップまたは命令プロセッサへの割当とを含む。この新たなグラフにおける各々の辺は、割当てられたリソース間の物理的な接続を表わし得る。
次に、区分化のタスクは、最適化基準やサイズ制限を満たし区分ブロックを作成するタスクとなる他の区分ブロックに無理なく接続され得る。以下にハイブリッドシステムにわたり最適な性能を達成するためのそのような区分化手法の1つについて説明する。
一実施例において、区分化ステップは、入力制御データフローグラフにおいて注釈とし
て区分化部に渡されたCプラグマまたはコンパイラ指示子といったプログラマ供給の区分化構文または指示子に基づき区分ブロックに対するサブグラフの割当として定義され得る。
て区分化部に渡されたCプラグマまたはコンパイラ指示子といったプログラマ供給の区分化構文または指示子に基づき区分ブロックに対するサブグラフの割当として定義され得る。
区分化の際にプログラマ供給の区分化構文指示に対して働いた後にCFG−DFGサブグラフがいくらかでも残っている場合、コンパイラ開始の区分化が以下のように進行し得る。すなわち、残ったCFG−DFGのサブグラフすべてを候補の区分ブロックとして列挙する;命令プロセッサプロファイラからのプロファイリングデータと、DFGエミュレートプロファイリングと、並列性の程度に基づく性能推定と、ブロックについての各々の動作のためのハードウェアロジックモジュール情報ファイルの中に見つかる性能情報と、候補の区分ブロックおよび隣接するブロック間にあるデータフローの性能と、を含む情報を用いて、候補の区分ブロックを潜在的可能性の順序で順序付ける;再構成可能ロジック対命令プロセッサコードとしての区分ブロックの推定性能を比較する;比較に基づき候補の区分ブロックをチップまたは命令プロセッサに割当てる;すべての候補ブロックを通じて進行する;推定された性能により候補の区分ブロックを順序付ける;そして、区分ブロックを含むCFG−DFG構成体出力CFG−DFGを完全にカバーする最終候補ブロックを選択する。
これが完了すると、区分ブロックの組は、実行場所と、上記リソースにロードされる制御データフローグラフとを定義し得る。区分ブロックはHLLコンバータに渡される。命令プロセッサで実行されることを意図されたブロックは、コンパイルプロセスをコード生成およびオブジェクトファイル生成へと継続し得る。再構成可能チップを目標としたブロックはHLLコンバータに渡されてMAPプロキシコードを生成でき、それからCFG−DFGをCGFからCFG−DFGへのコンバータに渡してロジック生成プロセスを継続できる。最終的には、区分ブロックはコンパイルプロセスをCFG−DFGからHDLへのコンバータまで継続し、そして最終的に、統一された実行可能要素に含められるべきビットストリームの生成に至る。
HDL変換のための準備
CFGからCFG−DFGへのコンバータの出力の1つは、コンパイルされているプロシージャについての変換されたデータフローグラフを表わすASCIIテキストファイルである。コンパイルにおける次のステップは、コンパイルにおける、CFG−DFGからHDLへのコンバータのVerilogコード生成段階により利用可能なフォーマットへと上記ファイル(すなわち.dfgファイル)を翻訳するステップである。MAPコンパイラは、CFG−DFGからHDLへのコンバータ「タプル」フォーマットでコンパイルされているプロシージャを表わす、CFG−DFGからHDLへのコンバータの内部フォーマット化テーブルへASCII.dfgファイルを翻訳する論理命令を含むソフトウェアモジュールを実現する。翻訳されたテーブルは、CFG−DFGからHDLへのコンバータへの入力の1つであるバイナリフォーマット化ファイル(.grfファイル)に書込まれ得る。
CFGからCFG−DFGへのコンバータの出力の1つは、コンパイルされているプロシージャについての変換されたデータフローグラフを表わすASCIIテキストファイルである。コンパイルにおける次のステップは、コンパイルにおける、CFG−DFGからHDLへのコンバータのVerilogコード生成段階により利用可能なフォーマットへと上記ファイル(すなわち.dfgファイル)を翻訳するステップである。MAPコンパイラは、CFG−DFGからHDLへのコンバータ「タプル」フォーマットでコンパイルされているプロシージャを表わす、CFG−DFGからHDLへのコンバータの内部フォーマット化テーブルへASCII.dfgファイルを翻訳する論理命令を含むソフトウェアモジュールを実現する。翻訳されたテーブルは、CFG−DFGからHDLへのコンバータへの入力の1つであるバイナリフォーマット化ファイル(.grfファイル)に書込まれ得る。
トランスレータの一実施例は以下のステップを有し得る。すなわち、最初のステップでは、コマンドラインがパーズされ得る。ソフトウェアモジュールは、入力ファイル名(すなわち.dfgファイル)である1つの任意でない引き数を有する。入力ファイル引き数が指定されれば、ファイル名は保存されファイルは開かれる。入力ファイルが開けられ得ない場合は処理は終了する。
変換における次のステップは入力ファイルの読込およびパーズである。パーズはフレックス(flex)(スキャナ生成部)およびバイソン(bison)(パーサ生成)により生成されたルーチンをコールすることにより実行され得る。ファイルがパーズされると、ソフト
ウェアモジュールは内部データ構造を構築してデータフローグラフを表現する。グラフの表現に用いられる内部データ構造は、CFGからCFG−DFGへのコンバータにより用いられるのと同じ構造である。上記2つの一次構造は、プロシージャ変数を表現する構造のアレイと、コンパイルされているプロシージャの実行可能部分を含む基本コードブロックを表現する構造のアレイとである。
ウェアモジュールは内部データ構造を構築してデータフローグラフを表現する。グラフの表現に用いられる内部データ構造は、CFGからCFG−DFGへのコンバータにより用いられるのと同じ構造である。上記2つの一次構造は、プロシージャ変数を表現する構造のアレイと、コンパイルされているプロシージャの実行可能部分を含む基本コードブロックを表現する構造のアレイとである。
次に、ソフトウェアモジュールは、CFG−DFGからHDLへのコンバータテーブルの組立てを開始し得る。一実施例において、このステップは、データフローグラフについての内部構造の構築後に実行される。出力ファイル名は入力ファイル名から、たとえば.dfgサフィックスを.grfサフィックスと置き換えることで組立てられ得る。入力ファイル名はCFG−DFGからHDLコンバータのFILENAMEテーブルに入れられ、出力ファイル名はCFG−DFGからHDLコンバータのOUTPUT_FILESテーブルへと入れられるということがあり得る。
次に、シンボルテーブルは、CFG−DFGからHDLへのコンバータのSCALARSテーブルへ翻訳され得る。一実施例において、このステップは、CFG−DFGからHDLへのコンバータテーブルの初期化後に行なわれる。コンパイルされているプロシージャに対する仮パラメータは、習慣上、CFG−DFGからHDLへのコンバータのSCALARSテーブルにおける最初のエントリである。データフローグラフの変数アレイを通じてパス(pass)が行なわれて仮パラメータを抽出する。各々のパラメータにつき、SCALARSテーブルにおいてフラグが設定されてこれがプロシージャに対する仮パラメータであることを示し得る。2つの他のフラグのうち1つが各々のエントリにおいて設定されて当該パラメータがスカラ変数であるかアレイであるかを示し得る。スカラまたは単一のアレイ要素についての.dfgメモリ記憶サイズはそのビット長である。これはバイト長へ変換されて各々のパラメータにつきSCALARSテーブルエントリに挿入され得る。最後に、パラメータの名前がSCALARSテーブルエントリに挿入され、エントリ完了パラメータエントリがSCALARSテーブルに挿入される。
すべての仮パラメータが処理された後、データフローグラフシンボルテーブルを通じて2番目のパス(pass)が行なわれ得て、当該のプロシージャに対する仮パラメータでない変数についての残りのエントリが処理され得る。この処理は仮パラメータについて説明したのと同様に実行され得るが、SCALARSテーブルエントリは、エントリが仮パラメータについてであることを示すフラグの代わりに、ローカル変数フラグが中に設定される。
データフローグラフ基本コードブロックの翻訳はシンボルテーブルの翻訳に従う。データフローグラフの中の1ブロックはノードの順次のリストである。ノードは、1つ以上の出力を伴う1つ以上の入力オペランドに対して実行される演算である。この演算はASCIIストリングオペコードとして表現される。オペランドは、入力または出力値を含む擬似レジスタ数を表わす整数として表現される。これに代えて、入力オペランドは定数であり得る。データフローグラフブロックの翻訳において、4つのCFG−DFGからHDLへのコンバータVerilog生成部テーブルが構築される。コードブロックのリストであるBLOCKSテーブルがある。RAW_NODESテーブルは、ブロック内に入っているノードの順次のリストである。PRSテーブルは、定義される擬似レジスタと、定数と、各々のノードで参照される擬似レジスタとのリストである。CONSTANTSテーブルは、コンパイルされているプロシージャで使用されるあらゆる定数値を含む。
トランスレータは、一度に1ブロックを処理しながらデータフローグラフのブロックアレイを通じてパス(pass)する。各々の新たなブロックはCFG−DFGからHDLへのコンバータBLOCKSテーブルの中にエントリを得る。CFG−DFGからHDLへの
コンバータのBLOCKSテーブルエントリは、以下に記載するブロック内のノードについての最初および最後のCFG−DFGからHDLへのコンバータのRAW_NODESテーブルエントリに対する索引を含む。ブロックが終了ブロックであり、すなわちコンパイルされているプロシージャからの戻りを含むブロックであることを意味している場合、BLOCKSテーブルエントリにはこれ以上の情報は入れられない。ブロックがドロップスルーブロックであり、条件分岐で終わらないことを意味している場合、後継のブロックのためのBLOCKSテーブルエントリに対する索引が現在のブロックのBLOCKSテーブルエントリに入れられる。他ではブロックは条件分岐で終わることになる。この場合、2つのあり得る後継のブロック(分岐の真のブロックおよび分岐の偽ブロック)のBLOCKSテーブル索引が現在のブロックBLOCKSテーブルエントリに入れられる。
コンバータのBLOCKSテーブルエントリは、以下に記載するブロック内のノードについての最初および最後のCFG−DFGからHDLへのコンバータのRAW_NODESテーブルエントリに対する索引を含む。ブロックが終了ブロックであり、すなわちコンパイルされているプロシージャからの戻りを含むブロックであることを意味している場合、BLOCKSテーブルエントリにはこれ以上の情報は入れられない。ブロックがドロップスルーブロックであり、条件分岐で終わらないことを意味している場合、後継のブロックのためのBLOCKSテーブルエントリに対する索引が現在のブロックのBLOCKSテーブルエントリに入れられる。他ではブロックは条件分岐で終わることになる。この場合、2つのあり得る後継のブロック(分岐の真のブロックおよび分岐の偽ブロック)のBLOCKSテーブル索引が現在のブロックBLOCKSテーブルエントリに入れられる。
RAW_NODESテーブルエントリはトランスレータがブロック内の各々のノードを通じてパス(pass)することにより組立てられる。ノードの処理は以下のように進行する。各々の出力擬似レジスタがPRSテーブルに入れられる。これは出力であり、したがってノードの動作により定義されるので、PRSテーブルエントリにはフラグが設定されてこれがそのノードにより定義されることを示す。また、擬似レジスタ数がPRSテーブルエントリに挿入されるとともに親ノードRAW_NODESテーブルエントリの索引が各々のPRSテーブルエントリに挿入される。出力擬似レジスタがノードについて処理された後、入力が処理される。入力擬似レジスタは、定義されたフラグがそのエントリで設定されないことを除き出力と同じ仕方でPRSテーブルに入れられる。定数であるノードへの入力もまたPRSテーブルエントリを得る。定数の入力が現われると、CFG−DFGからHDLへのコンバータのCONSTANTSテーブルにおいて、現在の定数と一致するエントリが探される。一致が見つかれば一致の索引が用いられ、そうでなければ新たなCONSTANTSテーブルエントリが作られて新たなエントリの索引が用いられる。定数についてのPRSテーブルエントリにはCONSTANTSテーブルエントリが挿入され、フラグが設定されてこれが定数であり擬似レジスタ参照エントリでないことを示し、親ノードのRAW_NODESテーブル索引がその中に挿入される。
ノードについてのすべての入力および出力が処理されると、ノードについてRAW_NODESテーブルエントリが作られる。RAW_NODESテーブルエントリには、ノードのオペコードと、ノードと関連付けられた最初および最後のPRSテーブルエントリのPRSテーブル索引とが入っている。
すべてのノードが翻訳されると、トランスレータは.grf出力ファイルへデータフローグラフが翻訳されることで構築されたCFG−DFGからHDLへのコンバータテーブルを書き出し、そして処理は完了する。
CFG−DFGからHDLへの変換
再構成可能FPGAチップについてのコンパイルシステムの一構成要素について説明する。このコンパイルシステムは、CやFortranのようなより高級な言語を、より大きな実行フレームワーク内で動作するFPGAのための構成ビットストリームにコンパイルする能力を有する。
再構成可能FPGAチップについてのコンパイルシステムの一構成要素について説明する。このコンパイルシステムは、CやFortranのようなより高級な言語を、より大きな実行フレームワーク内で動作するFPGAのための構成ビットストリームにコンパイルする能力を有する。
このより大きな実行フレームワークはSRC MAP製品の設計に特有である。理論的には、このコンパイルシステムはこのような任意の環境に容易に適合可能である。
ここに記載する構成要素は「CFG−DFGからHDLへのコンバータ」である。CFG−DFGからHDLへのコンバータの目的は、「CFGからCFG−DFGへのコンバータ」の出力をVerilog言語に変換することである。Verilogは、FPGAチップの製造業者によって提供される標準的なツールセットへの入力として用いられ得るHDL(hardwa
re description language)である。
re description language)である。
CFGからCFG−DFGへのコンバータはコンパイルシステムの別の構成要素である。このCFGからCFG−DFGへのコンバータの目的は、伝統的な高級言語コンパイラのオペコードを処理して、MAP/FPGAシステムでのパイプライン化された実行のためにより適した形にすることである。
CFGからCFG−DFGへのコンバータ出力は、実質的に、伝統的なコンパイラ出力から作成されたデータフローグラフ(DFG)からなり、これはむしろ制御フローグラフ(CFG)の形を取る。CFG−DFGからHDLへのコンバータは、その機能を実行するためにDFGの形を必要としない。それはCFGスタイルの入力で容易に働くことができる。しかしながら、MAP/FPGAにおける効率的な実行にはDFGの形が必要となる。
全体的なコンパイル戦略としては、伝統的なコンパイラ/CFGからCFG−DFGへのコンバータ/CFG−DFGからHDLへのコンバータの組合せにより作成されたVerilog言語を手引きとして用いることにより、ユーザコードのFPGA/MAPに対する効率的な表現を達成するために予め定められた「ハードウェア」モジュールを相互に接続する仕方を導き出す。したがって、CFG−DFGからHDLへのコンバータは、Verilog言語へのオペコード構成体の「合成」を行なわない。CFG−DFGからHDLへのコンバータは単に、知られている予め定められた1組のハードウェアモジュールから、特定のオペコードノードが必要とする機能に一致するモジュールを選択し、その間の相互接続をもたらす。予め定められたハードウェアモジュールの作成、維持および管理は、全体的なコンパイル作業の主な構成要素であり、オペコードノードと予め定められたハードウェアモジュールとの間の関係をどのように管理するかについての議論を除いてはここでは論じない。
CFG−DFGからHDLへのコンバータは、そのタスクを実行する間、処理に必要な情報のさまざまな部分を表現する1組の内部テーブルを管理する。最終的に、これらテーブルはユーザコードのVerilog表現が出力され得るのに十分な情報を有する。CFG−DFGからHDLへのコンバータについての入力ファイルは単純なファイルフォーマットから構成され、これは、CFG−DFGからHDLへのコンバータテーブルフォーマットへ既に予め処理されているいくらかの情報を含む。
CFG−DFGからHDLへのコンバータは単一のテーブルフォーマットのみを有することに注目されたい。テーブル管理は、テーブルエントリの削除ではなく追加のみを可能とすることにより単純化される。エントリはフラグにより無効であるとマークされ得て、単にテーブル展開におけるさらなる段階へコピーされない。また、テーブルエントリは固定サイズであり、テーブル探索を速やかにする。
CFG−DFGからHDLへのコンバータの入力は、コマンドラインスイッチと2つのタイプの入力ファイルとから構成される。コマンドラインスイッチは、入力ファイルの名前を指定する、およびCFG−DFGからHDLへのコンバータの処理の厳密な詳細を制御するために用いられる。この文献の目的にとっては、上記スイッチにより制御されるCFG−DFGからHDLへのコンバータ処理の詳細は重要ではない。したがって、ここで述べる2つのタイプの入力ファイルのみが重要な入力である。
入力オペコードファイルは“−f”スイッチで指定される。ただ1つのオペコードファイルが入力され得る。このファイルは、上述の“dfg2grf”と呼ばれるトランスレータユーティリティにより、CFG−DFGからHDLコンバータファイルフォーマット
へと変換されたCFGからCFG−DFGコンバータのデータフローグラフ出力からなる。
へと変換されたCFGからCFG−DFGコンバータのデータフローグラフ出力からなる。
オペコードノード:オペコードノードは、ノードの名前と、入力および出力擬似レジスタのリストとから構成される。擬似レジスタは単に或る数であり、ノード間のデータの流れを相関付けるために用いられる。
ブロック情報。オペコードがどのように基本ブロックに分割されるかを示す。基本ブロックは、伝統的なコンパイラにおけるのと同じ定義を有する。すなわち、単一の入口点および単一の出口点を有する命令シーケンスである。
定数情報。オペコードノードは、擬似レジスタの代わりに入力として定数値を参照し得る。
「スカラ」情報。コンパイルされたサブルーチン関数に渡される引き数についての情報である。
ファイル名情報。生成されるVerilogファイルの出力ファイル名を生成するために用いられる。
任意の数の「CFG−DFGからHDLへのコンバータinfo」ファイルは、“−a”スイッチの使用により入力され得る。「CFG−DFGからHDLへのコンバータinfo」ファイルは、“info2grf”ユーティリティによりCFG−DFGからHDLへのコンバータファイル/テーブルフォーマットに変換された“info”ファイル情報から構成される。“info2grf”への入力はアスキーテキスト“info”ファイルからなり、開発者/ユーザにより編集および維持されることを意図したものである。
“info”ファイルは、オペコードノード名と、Verilog言語ファイルで出力される結果としてのモジュール名との間の関連付けを、CFG−DFGからHDLへのコンバータが行なうための機構である。また、これを用いてユーザ定義のオペコード/モジュール関係についての情報を入力することができる。
入力CFG−DFGからHDLへのコンバータハードウェアロジックモジュール情報ファイル”info”ファイルに入っている情報の中には、全体としてコンパイルシステムにより用いられるモジュールについての情報すべてが入っている。ここではCFG−DFGからHDLへのコンバータにより用いられる情報のみについて述べる。CFG−DFGからHDLへのコンバータにより用いられる情報は以下のものである。
オペコードノードの名前。オペコードノードに対応するモジュールの名前。入力と対応の出力との間の時間のクロックにおける待ち時間。入力、そのビット幅およびその名前のリスト(擬似レジスタがオペコードノード内でCFGからCFG−DFGへのコンバータ出力フローグラフにおいて現われる順序にある)。出力、そのビット幅およびその名前のリスト(擬似レジスタがオペコードノード内でCFGからCFG−DFGへのコンバータ出力フローグラフにおいて現われる順序にある)。実行のために必要とされるがフローグラフには現われないハードウェア関係のモジュールI/O接続についての名前、ビット幅およびそれらが接続する外部信号名(これはたとえば、ブロック内で所与のノードの常駐場所のコンテキストにおいて暗黙であり得るイネーブル/リセット信号またはCLOCK信号が含まれる)。
CFG−DFGからHDLへのコンバータ出力:CFG−DFGからHDLへのコンバ
ータ出力は、アスキーテキストであるVerilog言語ファイルから構成される。ファイル名はオペコード入力ファイルに担われる情報から生成される。一般的に、ファイル名は“.v”をサフィックスとする高級言語ファイルの「基底名」である。たとえば、“toto.c”と名付けられた高級言語ファイルは、結果として“toto.v”と名付けられたVerilog言語ファイルをもたらす。
ータ出力は、アスキーテキストであるVerilog言語ファイルから構成される。ファイル名はオペコード入力ファイルに担われる情報から生成される。一般的に、ファイル名は“.v”をサフィックスとする高級言語ファイルの「基底名」である。たとえば、“toto.c”と名付けられた高級言語ファイルは、結果として“toto.v”と名付けられたVerilog言語ファイルをもたらす。
Verilog言語ファイルは、“PREAMBLE.v”、“AMBLE.v”、および“POSTAMBLE.v”“OBM_DR_SET.v”および“FR_SET.v”を参照する3つの“include”文を有する。これら3つのinclude文は、生成されたVerilogコードの宣言およびインスタンスのセクションを括弧でくくって分割する。これらによって、includeを解くための異なるファイルをもたらすことによりさまざまな実行およびシミュレーションの環境において変更なしに、生成されたVerilogコードを使用することが可能となる。
CFG−DFGからHDLへのコンバータ処理フロー:初期化:CFG−DFGからHDLへのコンバータの初期化処理は、コマンドラインスイッチの妥当性検証と入力ファイルの読込とからなる。入力ファイル内のデータは内部のCFG−DFGからHDLへのコンバータテーブルへ直接読込まれる。
主な機能の1つは、CFG−DFGからHDLへのコンバータ処理を通じて使用されるべき情報を含む多数の内部テーブルの作成である。作成される2つの最も主なテーブルはEQUIV_INおよびEQUIV_OUTテーブルである。これらのテーブルには、“info”ファイルに入っている情報の最も重要な部分が入っている。これら2つのテーブル内のエントリは1対1対応関係を有しており、CFG−DFGからHDLへのコンバータに指示することにより、入力フローグラフにおける所与の名前のオペコードノードを、出力Verilogファイルにおける予め定められたハードウェアモジュールの所与のインスタンス化に変換させる。MODEULESテーブルもまた作成され、これはEQUIV_OUTにより索引付けされるモジュールについてのモジュール接続の詳細を有する。
初期化においては、特別な目的の処理のためのさまざまなテーブルもまた作成される。これにより、目標のハードウェア特定の処理のための情報をソースコードの1区域に収容することが可能となる。目標のハードウェア環境に対して特定的な特別目的処理のすべてはたとえば、この初期化段階に生成される種々のフラグおよびテーブル設定により制御され得る。したがって、CFG−DFGからHDLへのコンバータの処理を別のプラットフォームに目標付け直すことが可能であり、これをするために、まず他のところで必要とされるだけこのような機能を追加し、それからこれを可能にするために生じるであろう初期化処理を選択する。理論的には、コマンドラインスイッチの単純な使用により、異なる実行環境がサポートされ得る。
このような特殊な場合の目標ハードウェア特定の処理は、以下へのサポートを含む。すなわち、モジュールの非擬似レジスタ関係の接続が接続するであろうグローバル信号のリスト。メモリバンクと、メモリ関係のオペコードノードが接続される仕方とに関する情報。“MIRROR”モジュールに関する情報(これは、コンパイルされたサブルーチンへのパラメータ入力をFPGAインスタンス化設計に接続し、場合により更新値を返すためのSRC機構である)。“code_block_reset”への接続は実際、所与のモジュールについての常駐場所の現在のブロックの“block_reset”信号に接続されることになる。
内部テーブルへの生の入力を処理:オペコードフローグラフノードの入力テーブルはNODEテーブルに読込まれ、オペコードノードの名前がEQUIV_INテーブルにおい
て探索される。見つかれば、対応のEQUIV_OUTテーブルエントリは、予め定められたハードウェアモジュールのMODULE索引を与える。このモジュール情報への索引はNODEテーブルに置かれる。
て探索される。見つかれば、対応のEQUIV_OUTテーブルエントリは、予め定められたハードウェアモジュールのMODULE索引を与える。このモジュール情報への索引はNODEテーブルに置かれる。
オペコードノード間のビット幅の一貫性を検証:ここで、NODESテーブル内のすべてのオペコードノードは割当てられたハードウェアモジュールを有する。ここですべての擬似レジスタを調べ、1モジュールにおいて別のモジュールの入力へ行く出力をマークする擬似レジスタについての一貫したビット幅の一致があるかどうかを検証する。この作業が実行される間、擬似レジスタ情報を含むテーブルが構築される。
CFG−DFGからHDLへのコンバータは、モジュール間に流れるデータの「タイプ」についての情報またはこれの必要性を有さないことに注目されたい。ビット幅のみが重要である。
「インライン化」のためのいくつかのシフト関数をマーク:NODESテーブルが調べられ、「シフト」演算を表現するいくつかのモジュールが処理される。モジュールの名前の慣用により、シフトが一定の量によるものか、そしてどれほどのものかが示される。モジュールがそのようなシフトであれば、この事実とシフトの方向とが、フラグによりNODESテーブルエントリ内でマークされる。モジュールについてのシフトカウントもまた抽出されてNODESテーブルエントリ内のフィールドに置かれる。この情報は、「インライン化」するために生成されたVerilogコードの出力中に使用されるか、または、実際にモジュールをインスタンス化することなくモジュールの機能をVerilogコード構文で直接表現する。
オペコードノードの依存性を分析:ここで、NODESテーブルおよびそれに関連付けられた擬似レジスタを調べてノード依存性のテーブル(NODE_DEPS)を作成する。このNODE_DEPSテーブルは、NODESテーブル内のどのオペコードノードが他のオペコードノードの前提条件である(すなわち擬似レジスタを介して直接流れるデータを有する)かを示す。
オペコードノードは以下のように発行される。すなわち、NODE_DEPSテーブルが調べられ、所与のNODEエントリについての先行要素の数の総カウントが作成されてNODEテーブルエントリに記憶される。各々すべてのNODEテーブルエントリ内の「クロックカウンタ」がゼロにされる。ゼロの先行要素カウントを有する各々すべてのNODEエントリのリストを有するテーブル(PICT_NODES)が作成される。
以下のようにオペコードノードを発行:PICT_NODESテーブル内におけるNODESテーブルエントリの索引の配置は、オペコードノードが「発行された」ことの基本的な指示である。PICT_NODEエントリが作られると、モジュールの特定のインスタンスをリスト化するテーブル内にエントリが作られる(INSTANCESテーブル)。同じモジュールタイプについて多くのインスタンスがあり得るので、所与のモジュールタイプにおける各々のインスタンスについて一意の名前が生成されるのはINSTANCESテーブルを通じてである。
上述の初期化段階の後、オペコードノードの発行プロセスは以下のように継続する。すなわち、PICT_NODESテーブル内のすべての新たなエントリにつきNODE_DEPSテーブルを調べて、発行されたオペコードノードを先行要素として有するNODEテーブルエントリ内の先行要素カウントを減分する。先行要素であったモジュールの待ち時間によって影響を受ける各々のNODEテーブルエントリのクロックカウントを調整する。新たにPICT_NODESテーブルに追加される各々のノードにつき、関連付けら
れたINSTANCESテーブルエントリを作成する。
れたINSTANCESテーブルエントリを作成する。
WIRINGテーブル内に情報を構築することにより、新たに作成されたINSTANCESテーブルエントリに先行要素INSTANCESテーブルエントリの出力の「配線」を実行する。WIRINGテーブルは、ソースおよび宛先のINSTANCESテーブル索引に関する情報および引き数またはパラメータ数を有する。
ここで、新たに先行要素カウントがゼロになったオペコードノードについてのNODESテーブルを調べる。これらエントリをPICT_NODESテーブルに追加して上述のように継続する。このプロセスを、すべてのオペコードノードが発行されてしまうまで継続する。
HDLファイルを出力:このときまでに処理は、HDLファイルの出力が開始できる点まで展開している。このプロセス中に行なわれる処理がなおいくらかあり、これにはすべての「配線」接続について宣言文を発することと、基本ブロックを互いに接続するよう配線することとが含まれる。
INSTANCESテーブル内のすべてのエントリにつき、「インライン化」されたかどうかをまず調べる。そうであれば、適当なHDL構文を出力する。そうでなければ、WIRINGテーブルに記述されているように、適当なモジュール、および種々のワイヤへのモジュールのI/Oピンの接続等、のインスタンス宣言を出力する。
ビットストリーム構成
コンパイルシステムの1構成要素であって、ユーザの実行可能要素へと最終的に統合されることになるコンパイル可能C構造へザイリンクス(Xilinx)ツールから作成されるビットストリームファイルを含める作業を行なう。この構成要素は、プログラミングデータのみを含むバイナリファイルの中にある1または2のFPGAビットストリームファイルを入力として取る。このコンパイル段階の結果は、一方が各々のFPGAビットストリームについてある2つの構造を含むCコードである。各々の構造は、下記のように、アレイの中に入ったFPGAビットストリームについてのパックされた表現;ビットストリームについての内部場所を指すポインタ;このビットストリームが表現するFPGAの数、ビットストリームアレイの長さ;ビットストリームアレイの始まりのアドレス;および、エミュレートに用いられるMAPルーチンのCバージョンを指すポインタ、を含む。
コンパイルシステムの1構成要素であって、ユーザの実行可能要素へと最終的に統合されることになるコンパイル可能C構造へザイリンクス(Xilinx)ツールから作成されるビットストリームファイルを含める作業を行なう。この構成要素は、プログラミングデータのみを含むバイナリファイルの中にある1または2のFPGAビットストリームファイルを入力として取る。このコンパイル段階の結果は、一方が各々のFPGAビットストリームについてある2つの構造を含むCコードである。各々の構造は、下記のように、アレイの中に入ったFPGAビットストリームについてのパックされた表現;ビットストリームについての内部場所を指すポインタ;このビットストリームが表現するFPGAの数、ビットストリームアレイの長さ;ビットストリームアレイの始まりのアドレス;および、エミュレートに用いられるMAPルーチンのCバージョンを指すポインタ、を含む。
FPGAビットストリームファイルは4096バイト量としてバッファに読込まれる。次にこのバッファは64ビットワードへパックされ、適当なビットストリームの構造の中に入ったビットストリームアレイへ書き出される。ビットストリームファイルから読込まれた最後の量は完全な64ビットワードとなるようにパディングされ、これらのワードもまたアレイに書き出される。ビットストリームファイル全体の完了後、最後のワードがキャッシュラインにおける最後のワードであるかどうかを判断するための検査が行なわれる。もしそうでなければ、より多くのパディングを行なって、最後のアレイワードが、マイクロプロセッサシステムにおける4ワードキャッシュラインを完全に満たすことを確実にする。
ビットストリームファイルの翻訳の完了後、残る情報およびポインタは最初のFPGAビットストリームを表わす構造に挿入される。同じプロセスが再び行なわれて2番目のFPGAビットストリームが読込まれて翻訳される。これらビットストリームのうち一方が存在するか、またはいずれもこのコンパイル段階では存在しないかのいずれかである。ビットストリーム構成部は、ヌルまたは存在するFPGAビットストリームファイルについてのすべての場合に対処し、これを反映するために適当なデータ構造を構築する。
統一された実行可能要素への統合
異なりしたがって一様でないプラットフォームに対して実行されるであろうオブジェクトファイルを作成した結果として、コンパイルプロセスにおける次のステップは、これらさまざまな構成要素を、「統一された実行可能要素」と称されるものを構築するようにまとめなければならない。次に、統一された実行可能要素は、命令プロセッサで実行されるマシンコードと、ハードウェアロジックプロセッサで実行されるマシンコードとの両方を含む。
異なりしたがって一様でないプラットフォームに対して実行されるであろうオブジェクトファイルを作成した結果として、コンパイルプロセスにおける次のステップは、これらさまざまな構成要素を、「統一された実行可能要素」と称されるものを構築するようにまとめなければならない。次に、統一された実行可能要素は、命令プロセッサで実行されるマシンコードと、ハードウェアロジックプロセッサで実行されるマシンコードとの両方を含む。
上記統一された実行可能要素は、その実行中には命令プロセッサのアドレス空間に常駐するので、統一された実行可能要素のフォーマットは、命令プロセッサの受入れるアプリケーションインターフェイスに対応したものでなければならない。統一された実行可能要素内にFPGAビットストリームが存在できるようにするために、ビットストリームデータを受入れ可能なフォーマットにカプセル化するための方法が開発された。
コンパイルプロセスによりビットストリームが生成された後、これらはC構造に読込まれ、ここで、このプログラム内でアクセスされる各々のビットストリームにつき1つのC構造が作成される。これらC構造は各々のビットストリームに対して一意である。C構造は、制御フロー情報ファイル生成段階中に作成された内部名に一致するように名付けられているからである。別個の制御フロー情報ファイルに一意の名前をタグ付けることによって、結果としてのビットストリームもまた、C構造に構築されると一意の識別子を有することができる。ビットストリーム構成が別のコンパイルプロセスで用いられることを意図されている場合、C構造はこの時点でバイナリファイルとして保存され得る。
ビットストリームC構造は、統一された実行可能要素内に常駐するか、またはマイクロプロセッサにおいて、実行中に利用可能とされた場所に常駐するかのいずれかであり得る。コンパイルプロセス中に作成されたビットストリームは、統一された実行にデフォルトで埋込まれ、したがって実行の時点ではアドレス空間の中にある。特定の実行可能要素のために構成されたビットストリーム構造が多数ある場合、統一された実行可能要素内に埋込まれるビットストリームC構造はそのいくつかだけであることも、または全くないこともあり得る。ビットストリーム構造のうちすべてが実行の時点で実行可能要素のアドレス空間内に常駐しない場合、ランタイム環境は、このビットストリームについてのハードウェアロジック構成が呼出される点で適当なビットストリーム構造を読込む必要がある。
ビットストリームC構造を統一された実行可能要素内に含めるかどうかを判断した後、マイクロプロセッサにある利用可能な標準のリンカーを用いてこれをオブジェクトファイルから作成することができる。すべてのオブジェクトファイルは適当なバイナリインターフェイスのものであるため、マイクロプロセッサのマシンコードおよびハードウェアロジックのマシンコード両方を含むことを可能にするには特別なことをしなくてもよい。
以下の図に示すように、実行の時点で実行されるべきハードウェアロジック構成を表現するビットストリームは図30に示す2つの場所のうち1つに存在し得る。
ランタイム環境
統一されたバイナリが実行されるランタイム環境は、命令プロセッサバイナリが実行されるランタイム環境を超えて拡張され得る。MAPライブラリは、データフローグラフのエミュレートおよびシミュレーションのためのサポートルーチンを含み得る。ユーザの観点からは、ランタイム環境にはルーチンについて3つのカテゴリがある。すなわちメモリ管理、MAPリソース管理、およびMAP実行である。
統一されたバイナリが実行されるランタイム環境は、命令プロセッサバイナリが実行されるランタイム環境を超えて拡張され得る。MAPライブラリは、データフローグラフのエミュレートおよびシミュレーションのためのサポートルーチンを含み得る。ユーザの観点からは、ランタイム環境にはルーチンについて3つのカテゴリがある。すなわちメモリ管理、MAPリソース管理、およびMAP実行である。
メモリ管理:ハードウェアの制限により、命令プロセッサ環境と再構成可能プロセッサ環境との間で転送されるメモリのブロックはキャッシュの境界で開始することが必要な場合がある。このようなハードウェア制限が存在する場合でのキャッシュ整列を支援するための2つの関数が設けられる。
第1の関数であるaddr32(またはこれに代えてFortranについてはIADDR32)は、恣意的なメモリアドレスを受入れて、入力アドレス引き数以上のメモリの1番目のキャッシュ整列ワードのアドレスを返すための論理命令を含むソフトウェアモジュールである。整列されるべきアレイは、キャッシュラインのメモリに近づくアレイの始まりおよび終わりにてパディングで宣言され得る。キャッシュ整列アレイを指し示すためのポインタが宣言され得る。パディングされたアレイはaddr32へ引き数として渡され得て、ポインタはこの関数の結果に設定され得る。整列されたアレイへの参照はポインタを通じて行なわれ得る。
第2の関数であるキャッシュ整列割付け(またはこれに代えてFortranについてはCACHE_ALIGNED_ALLOCATE)は、単一の整数の引き数を受取り、キャッシュ整列境界で始まる割付けられた空間へのポインタを生成するための論理命令を含むソフトウェアモジュールである。引き数はバイトでのメモリ割付け要求のサイズであり得る。この関数はポインタを宣言するために使用され得る。これに加え、ユーザはこの関数をコールしてアレイのために必要な空間を割付け、ポインタをこの関数の結果に設定することができる。このアレイへの参照はポインタを通じて行なわれ得る。
MAPリソース管理:ランタイム環境に対して動的に変更を加えることが可能であり、これを行なうためにジョブに再構成可能ハードウェアリソースを追加または削除する。命令プロセッサで実行される間、MAPリソースは必要とされない。MAPプロシージャを実行するのに先立ち、再構成可能ハードウェアリソースはジョブに割付けられなければならない。これはジョブのスタートアップ時に行なわれても、またはMAP実行に先立ついずれのときに行なわれてもよい。MAPプロシージャの実行後、統一されたバイナリの実行はしばらくの間MAPリソースを必要としない場合があるため、これらは再び必要とされるまで1つ以上のMAPプロセッサを解放することが望ましい場合がある。同様に、別のMAPプロシージャを実行するのに先立ち追加のMAPリソースを追加することが必要である場合がある。MAPリソースの管理に2つの関数が設けられる。
第1の関数であるmap_allocate(FortranについてはMAP_ALLOCATE(N,STAT))は、割付けられるべきMAPリソースの数を示す単一の入力引き数を受取るソフトウェアモジュールである。ゼロの結果値(FortranではSTAT)は、割付けが成功したことを示す。ゼロでない結果(STAT)は、要求が首尾よく満足されなかったことを示す。
第2の関数であるmap_free(FortranについてはMAP_FREE(N,STAT))は、ジョブから解放されるべきMAPリソースの数を示す単一の入力引き数を有するソフトウェアモジュールである。ゼロの戻り値(FortranについてはSTAT)は、リソースがジョブから首尾よく解放されたことを示す。ゼロでない戻り値(STAT)は、リソースの解放を試みた際にエラーが生じたことを示す。
MAPリソースはMAP ID数によって識別される。ジョブに割付けられた1番目のMAPは0のMAP IDを有する。任意の時点でn個のリソースがジョブに割付けられていれば、これらは0,1,…n−1として識別される。最大の値のMAP ID数を有するMAPリソースは最初に割付けを解除される。たとえば、7個のMAPリソースがジョブに割付けられている場合、これらは整数0〜6で識別される。3つが割付け解除され
れば、MAP ID0〜3はジョブに割付けられたままである。そして、2つが割付けられれば、最も最近に割付けられたMAP IDは4および5である。
れば、MAP ID0〜3はジョブに割付けられたままである。そして、2つが割付けられれば、最も最近に割付けられたMAP IDは4および5である。
MAP実行:ロジックビットストリームで再構成可能ハードウェアを構成する詳細、および再構成可能ハードウェアへ、そして命令プロセッサへの制御の転送の詳細は、ランタイム環境においてユーザから隠される。HLLコンバータにより生成されるMAPプロキシコードがこれらのタスクを実行する。このプロキシコードによりコールされたルーチンMAP_Executeについてここで論じる。
MAP_Executeおよびそのさまざまなランタイム入口点は以下の機能を実行する。最初に、MAPプロキシコードは、MAPプロシージャの実行のためにどのMAPリソースが使用されるべきかを示している。MAP_Executeはリソースをロックすることにより、MAPプロシージャの実行中に他の実行スレッド(またはユーザジョブ)がリソースにアクセスすることを防ぐ。使用されるべきリソースが、実行されるべきMAPプロシージャのためにユーザロジックで正しく構成されているかを調べる。もしそうでなければ、適当なロジックビットストリームの場所を突止めてMAPリソースを構成する。再構成可能ハードウェアにおける実行が開始される。MAP_Executeは実行が完了するのを待ち、リソースをアンロックし、それから命令プロセッサに対して完了を合図するかまたは制御を転送して返す。
ランタイム環境におけるエミュレーション
エミュレートは極めて有用なデバッグツールであるとともに、データフローグラフレベルでの性能プロファイリングを可能にするツールである。エミュレーションの能力は、MAPコンパイルシステムにより構築される実行可能要素のランタイム環境の中に構築される。
エミュレートは極めて有用なデバッグツールであるとともに、データフローグラフレベルでの性能プロファイリングを可能にするツールである。エミュレーションの能力は、MAPコンパイルシステムにより構築される実行可能要素のランタイム環境の中に構築される。
ランタイムライブラリは3つの別個の環境をサポートする。すなわち、1)MAPハードウェアでの実行、2)エミュレートされるMAPおよびデータフローグラフエミュレーションでの実行、3)エミュレートされるMAPおよびシミュレートされるユーザロジックでの実行、である。特定の環境の選択は環境変数設定に基づきランタイムで行なわれる。
エミュレーションモードが使用される場合、追加の環境変数により、MAPについてのロジックがどのように扱われるかが決定される。
MAPHW=EMUIIIが設定されると、MAPを管理するランタイムのライブラリルーチンは、MAPハードウェアサポートルーチンの代わりにMAPエミュレートルーチンをコールする。各々すべての実行可能要素はハードウェアにおいてまたはエミュレート
で実行可能である。MAPエミュレータはMAP制御プロセッサおよびそのリソースの代わりとなる。すなわち、通信リンク、オンボードメモリ、データレジスタ、およびフラグレジスタであり、これらリソースのソフトウェアエミュレートバージョンをもたらす。図31および図32はMAPエミュレータの構造を示す。
で実行可能である。MAPエミュレータはMAP制御プロセッサおよびそのリソースの代わりとなる。すなわち、通信リンク、オンボードメモリ、データレジスタ、およびフラグレジスタであり、これらリソースのソフトウェアエミュレートバージョンをもたらす。図31および図32はMAPエミュレータの構造を示す。
MAPエミュレータは、命令プロセッサアプリケーションコードおよびプロセスから別個のpスレッド(pthread)として実行される。エミュレータスレッドは、MAPハードウェアモードでなくエミュレーションモードが選択されたとランタイムルーチンが検出したときに開始される。MAPハードウェアが命令プロセッサに対して非同期的に実行されるのと同様、エミュレータもまた非同期的に実行される。
MAPエミュレータの機能は、命令プロセッサベースのアプリケーションへの通信および制御リンクをエミュレートし、データフローエミュレーションで、またはVerilogシミュレーションとして実行されるユーザロジックへのインターフェイスをもたらすことである。
また、データフローのエミュレートは、フラグレジスタ、データレジスタおよびオンボードメモリを読込むまたは書込むために用いられるインターフェイスルーチンを通じてMAPエミュレータへのインターフェイスを取る別個のpスレッドとして実行される。
MAPコンパイラにより生成されたユーザロジックがVerilogとして作成された場合、Verilogシミュレータを用いてMAPエミュレータとともにユーザロジックを実行することができる。Verilogシミュレーションは、共有メモリセグメントを通じてMAPエミュレータと通信する別個の実行可能要素として実行される。この場合、シミュレータは、オンボードメモリ、データレジスタおよびフラグレジスタをもたらし、一方でMAPエミュレータはMAP制御プロセッサをもたらす。
図31は、DFGエミュレーションとともにMAPエミュレータを示し、図32はVerilogシミュレータとMAPエミュレータを示す。
別の実施例においては、データフローグラフエミュレートは以下のように行なわれ得る。すなわち、MAPコンパイラの、CFGからCFG−DFGへのコンバータステップにおいて、2つのファイル、すなわちユーザのサブルーチンのデータフローグラフ(テキスト形式)とエミュレートロジックファイルとが作成される。データフローグラフファイルの目的は2つあり得る。すなわち、CFG−DFGからHDLへのコンバータによって使用されてサブルーチンのVerilog翻訳を生成でき、さらには、ソースコードを妥当性確認するまたは性能データを収集するためにエミュレートが用られているときにエミュレート論理ルーチンによって読込まれ得る。
一実施例において、データフローグラフはノードおよび指示された辺を含むことができ、ここでノードは機能ユニットであることができ、辺は、1つのノードからの出力値を他のノードの入力へ運ぶデータ接続である。データフローグラフを用いてデータフローシミュレータを実行することが可能であり得る。シミュレーションは以下のことに有用であり得る。すなわち、1)ソースコードと、そのデータフロー形式への翻訳とをともに妥当性確認する、2)デバッグのためのトレース情報をプリントする、そして3)性能推定を収集する、といった機能である。
一実施例において、データシミュレーションは「トークン駆動(token driven)」シミュレーションモードで行なうことができ、これは、緩く結合された非同期的なシミュレーションであってシーケンス付けは有効であり得るが時間は考慮されないものであり得る。
このモードにおいては、物事が「同時に」起こるという概念は存在しない。いずれのノードも、その入力に利用可能な値がある限り任意の時点で実行され得る。データ値は「トークン」と呼ばれ、トークンはノードの入力ポートで待ち行列を作ることができる。別の実施例においては、「クロック正確性(clock accurate)」シミュレーションが、システムクロックと機能ユニットの実行待ち時間とを考慮する。この場合、「同時」という語は意味を有する。
このモードにおいては、物事が「同時に」起こるという概念は存在しない。いずれのノードも、その入力に利用可能な値がある限り任意の時点で実行され得る。データ値は「トークン」と呼ばれ、トークンはノードの入力ポートで待ち行列を作ることができる。別の実施例においては、「クロック正確性(clock accurate)」シミュレーションが、システムクロックと機能ユニットの実行待ち時間とを考慮する。この場合、「同時」という語は意味を有する。
図33は、トークン駆動データフローシミュレータの一実施例のフローチャートを示す。一実施例の一例においては、ルーチン“dfg_simulate”がエミュレートロジックファイルからコールされてシミュレータを開始させ得る。この例においては、シミュレータはまずDFGファイルを読込んで内部表現を構築することができる。そして、シミュレーションを開始し、ブロックゼロ(定義においては入口のブロック)で始まる。コードブロックをシミュレートするたびごとに、まず待ち行列およびノード状態をクリアして、それから、ブロックの最上部にあるINITIATEノードに単一のトークンを送ることでブロックの実行をトリガする。それからループして、発火できるノードを探す。この例においては、ほとんどのノードについての「発火規則」は、ノードはその入力のうちの各々1つに利用可能なトークンがあれば発火できるというものである。「発火」は、各々の入力待ち行列からトークンを取るステップと、これらの値を用いてノードの特定の機能を実行するステップとからなる。この機能から1つ以上の出力値が得られ、これらはトークンとしてノードの出力で送り出される。出力が多数のノードに広がるときには、値トークンが目標のノードの待ち行列の各々に届けられ得る。
図34は、一実施例に従うDFGフラグメントの一例を示し、ここではフラグメントはシミュレータの内部ループの反復のたびに段階的に実行される。開始時には3つの値が入力待ち行列で待っている。最上部にある2つのノードは発火可能であるとマークされる。これらは各々の待ち行列から1つのトークンを消費し、結果のトークンを、その出力により供給がなされるノードの待ち行列に送る。t=1において、最下部にあるノードはその右側の入力に値を有するがその左側の入力には値を有さないので発火できないことに注目されたい。t=2では、最下部のノードにおける右側の入力の待ち行列には2つのトークンがある。シミュレータの内部ループの5パス(pass)の後、このフラグメントには処理され得る値がもはやなくなる。
一般的に、データフローグラフには正しい発火順序が多数ある。上述の例においては、上の方のノードを3回発火させてからその他のノードのいずれかを発火させることもまた等しく有効であったであろう。トークンが順序に従って待ち行列に到着するという事実により、各々のノードの出力にある対応の値は正しく「マッチアップ」することが確実となる。シミュレータにおけるノード入力待ち行列は、必要に応じて拡張できるように設計される。すなわち、値が待ち行列に送られその待ち行列が一杯であるときはいつでも、待ち行列のサイズを増大させて新たな値に対応できるようにする。フローチャートに示した処理順序においては、ノードにわたる各々の掃引においてノードは処理できたであろう値をより多く持っていたとしても一度しか発火しないが、この処理順序は、必要な待ち行列の長さを最小化するために選択され得る。
非同期的データフローシミュレーション中に生じ得るさまざまなノード発火順序は、データフローノードが「純粋に機能的である」、すなわち各々のノードの出力トークンが、出力を計算するためにフェッチされた入力トークンに依存し得るときに、等価の結果を生成する。すべてのノードが純粋に機能的であるとは限らない。いくつかのノードは「状態」を有する、すなわち以前に行なったことについての記憶をいくらか有している場合がある。このようなノードは「状態を持つ」と呼ばれ得る。いくつかのノードはこれを取囲むハードウェアと対話する、すなわちフラグレジスタ、データレジスタまたはオンボードメ
モリに読み書きをする場合がある。データフローシミュレータは、適当なMAPエミュレータ関数へのコールを行なうことによりこれらノードを実行し得る。
モリに読み書きをする場合がある。データフローシミュレータは、適当なMAPエミュレータ関数へのコールを行なうことによりこれらノードを実行し得る。
別の実施例においては、データフローシミュレーションは、再構成可能ハードウェアに起こることをより近く真似るモードで行なわれ得る。クロック正確性シミュレーションはシステムクロックが存在することを仮定し、機能ユニットは同期してクロックにより連携させられながら実行される。ハードウェアでは、各々すべての機能ユニットは、その入力に有効なデータがあるか否かにかかわらず、各々すべてのクロックサイクルにおいて演算を実行し得る。データフローグラフと、グラフから生成された論理回路とは、機能ユニットからの「ジャンク」データが無視されるように生成され得る。
クロック正確性シミュレーションは、各々すべてのクロックサイクルにおいてグラフでの各々のノードが計算をするモードで動作する場合には、計算時間を極めて無駄に費やす場合がある。一実施例では、トークン駆動シミュレーションと同様にデータフローノードにより有効な計算が実行され、「タイムスタンプ」をトークンに取付けることによりシステムの同期的な様相が取込まれるというモードで、シミュレーションをすることが可能である。このシミュレーションにおいては、入力にてトークンが待ち行列をなし、ノードの発火および実行は、そのタイムスタンプにより待ち行列における値をマッチアップし得る。
クロック正確性シミュレーションは非同期的なトークン駆動シミュレーションよりも複雑であり得るが、再構成可能ハードウェアで起こる動作および同期化をより忠実に反映し得る。したがって、クロック正確性シミュレーションは以下の利点を有する。すなわち、1)クロック正確性シミュレーションにおいては、不正確に置かれた遅延ノードはエラー指示を生成する。これに対してこれらは非同期的なシミュレーションでは正しく実行されているように見える。2)クロック正確性シミュレーションはシステムクロックをシミュレートするため、正確な実行時間予測値を与えることが可能である。3)同じメモリバンクへの読み書きが非同期的シミュレーションで起こるとき、これが起こる順序は指定されていない場合があるため、再構成可能ハードウェアで起こるであろう同じ順序で起こらない場合がある。しかし、クロック正確性シミュレーションによると、ハードウェアでおきることに一致するよう保証された実行順序をもたらすことができる。
別の実施例においては、MAPコンパイラにより生成されるデータフローグラフのシミュレーションに関係した問題への対処がなされる。これには以下のものが含まれる。
状態を持つノードの問題:状態を持つノードは、そのノード構造の中に、過去に生じたことについての或る様相を追跡するために用いる1つ以上の内部フィールドを有する。状態を持つノードの一例として、その入力にあるトークンストリームの値を合計するアキュムレータが挙げられる。アキュムレータノードはそのノード構造の中に、累算する合計の現在の値を保持するための場所を必要とする。その他のノードのタイプではより複雑な状態が必要とされる場合がある。データフローノード構造は、タイプ“NodeState”のフィールドを有する。これは以下のstructで定義される。
一実施例において、コードブロックが入れられるときは必ず、その状態を持つノードの「初期化された」フィールドが「偽」に設定される。状態を持つノードについてのノード実行ルーチンはこのフィールドを調べて、偽であれば初期化を実行することができる。これは典型的に、ノードタイプの状態のために適当なデータ構造を割付けて、これを指し示すように「状態」ポインタを設定することによって行なわれる。また、この構造のフィールドが適当な開始状態に設定される。それから、「初期化された」フィールドが「真」に設定され、こうしてノードにおける後続の発火が再初期化を試みないようにする。
発火規則および実行規則:一実施例において、データフローグラフにおける各々のノードタイプには、それに関連付けられた2つの機能、すなわち「発火規則」および「実行規則」がある。ほとんどのノードについての発火規則は単純なものであり得る。すなわち、ノードは、その入力のいずれにもデータ値があり得るときに発火できるという規則である。これには、ループデータフローグラフについてのパイプライン化された挙動を管理するループ制御ノードの場合にいくつかの例外があり得る。ノードについての実行規則は、その入力値をどのように用いて出力値を生成するかについての仕様であり、すなわち実行規則はノードの関数であり得る。シミュレータがデータフローグラフファイルを読込み、内部ノード構造を構築するとき、各々のノードは、このノードについての発火および実行関数を指し示すために用いられ得る2つの関数ポインタを有する。
ユーザマクロ:一実施例において、MAPコンパイラにより、ユーザはコードの再構成可能ハードウェアへのコンパイル時に自分自身のハードウェア論理ユニットを参照することができる。コンパイルされたコードのデータフローシミュレーションを行なうために、ユーザは参照されている各々のユニットにつき実行関数を与える。これはこのノードについての「実行規則」である。ユーザマクロの場合、これは「通常の」発火規則に従う、すなわちノードは各々すべての出力に値があるときに発火できると仮定される。ユーザマクロについてのデータフローシミュレーションルーチンは、“info”ファイルから読込まれて、それからSRC組込マクロが扱われるのと同じ仕方で内部的に扱われる。すなわち、ユーザのシミュレーション関数がコンパイルされ得て、関連付けられたデータフローノードにはこの関数へのポインタが与えられる。
或る程度の具体性をもって本発明を記載および例示したが、この開示は単に例としてなされたものであって、先に請求された本発明の意味および範囲から逸脱することなく当業者は構成要素の組合せおよび配置において数多くの変更に頼ることが可能であることが理解される。
この明細書および前掲の特許請求の範囲で使用される「備える」「備えた」「含む」および「含んだ」という用語は、記載される特徴、完全体、構成要素またはステップの存在を特定することを目的としたものであるが、その他1つ以上の特徴、完全体、構成要素、ステップまたは群の存在または追加を除外するものではない。
Claims (20)
- 制御データフローグラフ表現を区分化する方法であって、
前記制御データフローグラフを2つ以上の区分ブロックに分割するステップと、
再構成可能ロジック対命令プロセッサコードとしての前記区分ブロックのうちの少なくとも1つについての推定性能を比較するステップと、
前記比較するステップに基づいて前記区分ブロックのうちの前記少なくとも1つを再構成可能ハードウェアまたは命令プロセッサに割当てるステップとを備える、方法。 - プログラマから入力された区分化構文に基づいて前記区分ブロックのうちの少なくとも1つを前記再構成可能ハードウェアに割当てるステップを含む、請求項1に記載の方法。
- プログラマ命令に基づいて、前記再構成可能ハードウェアに割当てられていない前記制御データフローグラフのサブグラフからの候補区分ブロックを列挙するステップを含む、請求項1に記載の方法。
- マイクロプロセッサプロファイラからのプロファイリングデータに基づいて前記区分ブロックを順序付けるステップを含む、請求項1に記載の方法。
- データフローグラフエミュレーションプロファイリングからのプロファイリングデータに基づいて前記区分ブロックを順序付けるステップを含む、請求項1に記載の方法。
- 前記区分ブロックの各々における並列性の程度に基づいて前記区分ブロックを順序付けるステップを含む、請求項1に記載の方法。
- 候補区分ブロックと、隣接する区分ブロックとの間でデータフローを測定するステップを含む、請求項1に記載の方法。
- 前記区分ブロックのうちの前記少なくとも1つを再構成可能ハードウェアまたは命令プロセッサに割当てる前記ステップは、前記再構成可能ハードウェアまたは命令プロセッサにおける前記区分ブロックについての実行場所を定義するステップを含む、請求項1に記載の方法。
- 前記再構成可能ハードウェアに割当てられた前記区分ブロックから出力制御データフローグラフを形成するステップを含む、請求項1に記載の方法。
- 前記出力制御データフローグラフは少なくとも1つの辺を含み、前記辺は割当てられたリソース間の物理的な接続を表わす、請求項9に記載の方法。
- 制御データフローグラフ表現を区分化する方法であって、
制御データフローグラフのサブグラフを区分ブロックに区分化するステップと、
命令プロセッサコードまたは再構成可能ハードウェアロジックとしての潜在的可能性の順序に基づいて前記区分ブロックを順序付けるステップと、
前記再構成可能ハードウェアロジック対前記命令プロセッサコードとしての各々の区分ブロックについての推定性能を比較するステップと、
前記比較するステップに基づいて再構成可能ハードウェアまたは命令プロセッサに前記区分ブロックを割当てるステップとを備える、方法。 - プログラマから入力された区分化構文に基づいて前記サブグラフのうちの少なくとも1つを区分ブロックに割当てるステップを含む、請求項11に記載の方法。
- プログラマから入力された前記区分化構文はプラグマを含む、請求項12に記載の方法。
- プログラマから入力された前記区分化構文は指示子を含む、請求項12に記載の方法。
- プログラマから入力された前記区分化構文はアサートを含む、請求項12に記載の方法。
- 前記再構成可能ハードウェアに割当てられた前記区分ブロックから出力制御データフローグラフを形成するステップを含む、請求項11に記載の方法。
- 前記出力制御データフローグラフは少なくとも1つの辺を含み、前記辺は割当てられたリソース間の物理的な接続を表わす、請求項16に記載の方法。
- コンピュータプログラム製品であって、
制御データフローグラフの区分化を引起すためのコンピュータ読取可能プログラムコードが中に実現されたコンピュータ利用可能媒体を備え、前記コンピュータ読取可能プログラムコードは、
コンピュータに、前記制御データフローグラフを2つ以上の区分ブロックに分割させるためのコンピュータ読取可能プログラムコードと、
前記コンピュータに、再構成可能ロジック対命令プロセッサコードとしての前記区分ブロックのうちの少なくとも1つについての推定性能を比較させるためのコンピュータ読取可能プログラムコードと、
前記コンピュータに、前記比較するステップに基づいて前記区分ブロックのうちの前記少なくとも1つを再構成可能ハードウェアまたは命令プロセッサに割当てさせるためのコンピュータ読取可能プログラムコードとを含む、コンピュータプログラム製品。 - 前記再構成可能ハードウェアはフィールド・プログラマブル・ゲートアレイを含む、請求項18に記載のコンピュータプログラム製品。
- 前記命令プロセッサはマイクロプロセッサを含む、請求項18に記載のコンピュータプログラム製品。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/285,298 US6964029B2 (en) | 2002-10-31 | 2002-10-31 | System and method for partitioning control-dataflow graph representations |
PCT/US2003/031585 WO2004042498A2 (en) | 2002-10-31 | 2003-10-02 | System and method for partitioning control-dataflow graph representations |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2006505057A true JP2006505057A (ja) | 2006-02-09 |
Family
ID=32175149
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004549997A Pending JP2006505057A (ja) | 2002-10-31 | 2003-10-02 | 制御データフローグラフ表現を区分化するためのシステムおよび方法 |
Country Status (6)
Country | Link |
---|---|
US (1) | US6964029B2 (ja) |
EP (1) | EP1559040A4 (ja) |
JP (1) | JP2006505057A (ja) |
AU (1) | AU2003275446A1 (ja) |
CA (1) | CA2494688A1 (ja) |
WO (1) | WO2004042498A2 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008130078A (ja) * | 2006-11-17 | 2008-06-05 | Samsung Electronics Co Ltd | プロセッサ構造および応用の最適化のためのプロファイラ |
JP2012133756A (ja) * | 2010-11-10 | 2012-07-12 | Src Computers Inc | ヘテロジニアス黙示的及び明示的プロセッシング要素の計算の一体化のためのシステム及び方法 |
Families Citing this family (71)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7155602B2 (en) * | 2001-04-30 | 2006-12-26 | Src Computers, Inc. | Interface for integrating reconfigurable processors into a general purpose computing system |
WO2004038620A1 (ja) * | 2002-10-28 | 2004-05-06 | Renesas Technology Corp. | システム開発方法及びデータ処理システム |
US6986110B1 (en) * | 2003-01-02 | 2006-01-10 | Hewlett-Packard Development Company, L.P. | Automated method and system for backtracing of instruction parameters from specified instruction in test cases |
US7895584B1 (en) * | 2003-03-14 | 2011-02-22 | Xilinx, Inc. | Translation of a program in a dynamically-typed language to a program in a hardware description language |
JP4204039B2 (ja) * | 2003-04-24 | 2009-01-07 | シャープ株式会社 | 動作合成システム、動作合成方法、制御プログラム、可読記録媒体、論理回路の製造方法および論理回路 |
US7398492B2 (en) * | 2004-06-03 | 2008-07-08 | Lsi Corporation | Rules and directives for validating correct data used in the design of semiconductor products |
US7404156B2 (en) * | 2004-06-03 | 2008-07-22 | Lsi Corporation | Language and templates for use in the design of semiconductor products |
JP4275013B2 (ja) * | 2004-06-21 | 2009-06-10 | 三洋電機株式会社 | データフローグラフ処理装置、処理装置、リコンフィギュラブル回路。 |
US7464375B2 (en) * | 2004-06-24 | 2008-12-09 | International Business Machines Corporation | Method for flattening hierarchically structured flows |
US7278122B2 (en) * | 2004-06-24 | 2007-10-02 | Ftl Systems, Inc. | Hardware/software design tool and language specification mechanism enabling efficient technology retargeting and optimization |
JP2006011840A (ja) * | 2004-06-25 | 2006-01-12 | Mitsubishi Electric Corp | 組み込みシステム |
DE102004033339A1 (de) * | 2004-07-09 | 2006-02-02 | Infineon Technologies Ag | Verfahren und Vorrichtung zum Auffinden von Schaltungsabweichungen |
US7941794B2 (en) * | 2004-08-30 | 2011-05-10 | Sanyo Electric Co., Ltd. | Data flow graph processing method and processing apparatus provided with reconfigurable circuit |
US7334203B2 (en) * | 2004-10-01 | 2008-02-19 | Dynetix Design Solutions, Inc. | RaceCheck: a race logic analyzer program for digital integrated circuits |
US7530044B2 (en) * | 2004-11-04 | 2009-05-05 | Tabula, Inc. | Method for manufacturing a programmable system in package |
US7301242B2 (en) | 2004-11-04 | 2007-11-27 | Tabula, Inc. | Programmable system in package |
US7315993B2 (en) * | 2004-11-30 | 2008-01-01 | Lsi Logic Corporation | Verification of RRAM tiling netlist |
US7509599B1 (en) * | 2004-12-10 | 2009-03-24 | Synopsys, Inc | Method and apparatus for performing formal verification using data-flow graphs |
US7373621B1 (en) * | 2005-02-01 | 2008-05-13 | Altera Corporation | Constraint-driven test generation for programmable logic device integrated circuits |
US8201124B1 (en) | 2005-03-15 | 2012-06-12 | Tabula, Inc. | System in package and method of creating system in package |
US7509619B1 (en) * | 2005-06-22 | 2009-03-24 | Xilinx, Inc. | Auto generation of a multi-staged processing pipeline hardware implementation for designs captured in high level languages |
US8566298B1 (en) * | 2005-07-28 | 2013-10-22 | Symantec Operating Corporation | Method and apparatus for sharing resource locks amongst applications |
TW200725414A (en) * | 2005-12-30 | 2007-07-01 | Tatung Co Ltd | Method for converting hardware component graph to hardware description language |
US7949907B2 (en) * | 2006-10-03 | 2011-05-24 | Wipro Limited | Method and device for data communication |
US8863067B1 (en) | 2008-02-06 | 2014-10-14 | Tabula, Inc. | Sequential delay analysis by placement engines |
US8484623B2 (en) * | 2008-03-26 | 2013-07-09 | Avaya, Inc. | Efficient program instrumentation |
US8291399B2 (en) * | 2008-03-26 | 2012-10-16 | Avaya Inc. | Off-line program analysis and run-time instrumentation |
US8739145B2 (en) * | 2008-03-26 | 2014-05-27 | Avaya Inc. | Super nested block method to minimize coverage testing overhead |
US8752007B2 (en) * | 2008-03-26 | 2014-06-10 | Avaya Inc. | Automatic generation of run-time instrumenter |
EP2304622A1 (en) * | 2008-05-15 | 2011-04-06 | Universiteit Gent | Parameterized configuration for a programmable logic device |
US8555218B2 (en) | 2008-05-24 | 2013-10-08 | Tabula, Inc. | Decision modules |
JP4635082B2 (ja) * | 2008-09-30 | 2011-02-16 | 株式会社東芝 | マルチプロセッサシステム及びグルーピング方法 |
KR101553652B1 (ko) * | 2009-02-18 | 2015-09-16 | 삼성전자 주식회사 | 이종 프로세서에 대한 명령어 컴파일링 장치 및 방법 |
US9778921B2 (en) * | 2009-06-02 | 2017-10-03 | Apple Inc. | Method for creating, exporting, sharing, and installing graphics functional blocks |
US9336023B2 (en) * | 2009-12-18 | 2016-05-10 | Sybase, Inc. | Visual generation of mobile applications based on data models |
US9043769B2 (en) * | 2009-12-28 | 2015-05-26 | Hyperion Core Inc. | Optimization of loops and data flow sections in multi-core processor environment |
US8912820B2 (en) | 2010-04-02 | 2014-12-16 | Tabula, Inc. | System and method for reducing reconfiguration power |
US8458630B1 (en) * | 2010-06-26 | 2013-06-04 | Cadence Design Systems, Inc. | Supporting dynamic aspects of polymorphism in high-level synthesis of integrated circuit designs |
WO2012154596A1 (en) | 2011-05-06 | 2012-11-15 | Xcelemor, Inc. | Computing system with data and control planes and method of operation thereof |
US9335977B2 (en) * | 2011-07-28 | 2016-05-10 | National Instruments Corporation | Optimization of a data flow program based on access pattern information |
US20130046912A1 (en) * | 2011-08-18 | 2013-02-21 | Maxeler Technologies, Ltd. | Methods of monitoring operation of programmable logic |
EP2754041B1 (en) | 2011-09-07 | 2020-06-24 | Imagine Communications Corp. | Systems and methods for developing component-based computing applications |
US8984464B1 (en) | 2011-11-21 | 2015-03-17 | Tabula, Inc. | Detailed placement with search and repair |
US20130157639A1 (en) | 2011-12-16 | 2013-06-20 | SRC Computers, LLC | Mobile electronic devices utilizing reconfigurable processing techniques to enable higher speed applications with lowered power consumption |
US9361079B2 (en) * | 2012-01-30 | 2016-06-07 | Nvidia Corporation | Method for compiling a parallel thread execution program for general execution |
US9052956B2 (en) | 2012-08-30 | 2015-06-09 | Hewlett-Packard Development Company, L.P. | Selecting execution environments |
US8887154B2 (en) | 2012-09-06 | 2014-11-11 | Imagine Communications Corp. | Systems and methods for partitioning computing applications to optimize deployment resources |
US8789001B1 (en) | 2013-02-20 | 2014-07-22 | Tabula, Inc. | System and method for using fabric-graph flow to determine resource costs |
US10741226B2 (en) | 2013-05-28 | 2020-08-11 | Fg Src Llc | Multi-processor computer architecture incorporating distributed multi-ported common memory modules |
US8806403B1 (en) * | 2013-06-21 | 2014-08-12 | Altera Corporation | Efficient configuration of an integrated circuit device using high-level language |
US10223486B2 (en) | 2013-11-13 | 2019-03-05 | Nxp Usa, Inc. | Static modelling of an electronic device |
US9104826B2 (en) * | 2013-11-13 | 2015-08-11 | Freescale Semiconductor, Inc. | Monitoring coverage for static modelling of an electronic device |
US9235392B2 (en) * | 2014-01-22 | 2016-01-12 | Nvidia Corporation | System, method, and computer program product for improved power efficiency during program code execution |
US9477477B2 (en) | 2014-01-22 | 2016-10-25 | Nvidia Corporation | System, method, and computer program product for executing casting-arithmetic instructions |
US9153311B1 (en) | 2014-05-27 | 2015-10-06 | SRC Computers, LLC | System and method for retaining DRAM data when reprogramming reconfigurable devices with DRAM memory controllers |
US9530483B2 (en) | 2014-05-27 | 2016-12-27 | Src Labs, Llc | System and method for retaining dram data when reprogramming reconfigurable devices with DRAM memory controllers incorporating a data maintenance block colocated with a memory module or subsystem |
US9529587B2 (en) * | 2014-12-19 | 2016-12-27 | Intel Corporation | Refactoring data flow applications without source code changes or recompilation |
US9411528B1 (en) | 2015-04-22 | 2016-08-09 | Ryft Systems, Inc. | Storage management systems and methods |
US9411613B1 (en) | 2015-04-22 | 2016-08-09 | Ryft Systems, Inc. | Systems and methods for managing execution of specialized processors |
US9542244B2 (en) | 2015-04-22 | 2017-01-10 | Ryft Systems, Inc. | Systems and methods for performing primitive tasks using specialized processors |
US9690894B1 (en) | 2015-11-02 | 2017-06-27 | Altera Corporation | Safety features for high level design |
JP6801460B2 (ja) * | 2017-01-11 | 2020-12-16 | 富士通株式会社 | 情報処理装置、プログラム、および情報処理方法 |
CN107239315B (zh) * | 2017-04-11 | 2019-11-15 | 赛灵思公司 | 面向神经网络异构计算平台的编程模型 |
CN107168698B (zh) | 2017-04-24 | 2020-11-24 | 华南理工大学 | 图形化编程的自动编译方法 |
US11675948B2 (en) * | 2017-09-29 | 2023-06-13 | Intel Corporation | Methods and apparatus for profile-guided optimization of integrated circuits |
US10534885B1 (en) * | 2018-03-21 | 2020-01-14 | Xilinx, Inc. | Modifying data flow graphs using range information |
US10740074B2 (en) * | 2018-11-30 | 2020-08-11 | Advanced Micro Devices, Inc. | Conditional construct splitting for latency hiding |
US11080227B2 (en) * | 2019-08-08 | 2021-08-03 | SambaNova Systems, Inc. | Compiler flow logic for reconfigurable architectures |
US11809908B2 (en) | 2020-07-07 | 2023-11-07 | SambaNova Systems, Inc. | Runtime virtualization of reconfigurable data flow resources |
CN112070202B (zh) * | 2020-07-09 | 2021-09-03 | 安徽寒武纪信息科技有限公司 | 一种融合图的生成方法、生成装置和计算机可读存储介质 |
US11782729B2 (en) | 2020-08-18 | 2023-10-10 | SambaNova Systems, Inc. | Runtime patching of configuration files |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE68920388T2 (de) | 1988-09-19 | 1995-05-11 | Fujitsu Ltd | Paralleles Rechnersystem mit Verwendung eines SIMD-Verfahrens. |
US5802290A (en) | 1992-07-29 | 1998-09-01 | Virtual Computer Corporation | Computer network of distributed virtual computers which are EAC reconfigurable in response to instruction to be executed |
US6052773A (en) | 1995-02-10 | 2000-04-18 | Massachusetts Institute Of Technology | DPGA-coupled microprocessors |
US5570040A (en) | 1995-03-22 | 1996-10-29 | Altera Corporation | Programmable logic array integrated circuit incorporating a first-in first-out memory |
US5903771A (en) | 1996-01-16 | 1999-05-11 | Alacron, Inc. | Scalable multi-processor architecture for SIMD and MIMD operations |
US5737766A (en) | 1996-02-14 | 1998-04-07 | Hewlett Packard Company | Programmable gate array configuration memory which allows sharing with user memory |
US5892962A (en) | 1996-11-12 | 1999-04-06 | Lucent Technologies Inc. | FPGA-based processor |
US6226776B1 (en) | 1997-09-16 | 2001-05-01 | Synetry Corporation | System for converting hardware designs in high-level programming language to hardware implementations |
US6076152A (en) | 1997-12-17 | 2000-06-13 | Src Computers, Inc. | Multiprocessor computer architecture incorporating a plurality of memory algorithm processors in the memory subsystem |
US6192439B1 (en) | 1998-08-11 | 2001-02-20 | Hewlett-Packard Company | PCI-compliant interrupt steering architecture |
GB9828381D0 (en) * | 1998-12-22 | 1999-02-17 | Isis Innovation | Hardware/software codesign system |
US6546477B1 (en) * | 1999-09-20 | 2003-04-08 | Texas Instruments Incorporated | Memory management in embedded systems with dynamic object instantiation |
-
2002
- 2002-10-31 US US10/285,298 patent/US6964029B2/en not_active Expired - Lifetime
-
2003
- 2003-10-02 WO PCT/US2003/031585 patent/WO2004042498A2/en active Application Filing
- 2003-10-02 JP JP2004549997A patent/JP2006505057A/ja active Pending
- 2003-10-02 AU AU2003275446A patent/AU2003275446A1/en not_active Abandoned
- 2003-10-02 CA CA002494688A patent/CA2494688A1/en not_active Abandoned
- 2003-10-02 EP EP03759724A patent/EP1559040A4/en not_active Withdrawn
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008130078A (ja) * | 2006-11-17 | 2008-06-05 | Samsung Electronics Co Ltd | プロセッサ構造および応用の最適化のためのプロファイラ |
JP4489102B2 (ja) * | 2006-11-17 | 2010-06-23 | 三星電子株式会社 | プロセッサ構造および応用の最適化のためのプロファイラ |
US8490066B2 (en) | 2006-11-17 | 2013-07-16 | Samsung Electronics Co., Ltd. | Profiler for optimizing processor architecture and application |
JP2012133756A (ja) * | 2010-11-10 | 2012-07-12 | Src Computers Inc | ヘテロジニアス黙示的及び明示的プロセッシング要素の計算の一体化のためのシステム及び方法 |
Also Published As
Publication number | Publication date |
---|---|
US20040088666A1 (en) | 2004-05-06 |
US6964029B2 (en) | 2005-11-08 |
EP1559040A4 (en) | 2008-04-09 |
WO2004042498A3 (en) | 2004-09-30 |
WO2004042498A2 (en) | 2004-05-21 |
EP1559040A2 (en) | 2005-08-03 |
AU2003275446A1 (en) | 2004-06-07 |
CA2494688A1 (en) | 2004-05-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4482454B2 (ja) | 高級プログラミング言語におけるプログラムをハイブリッド計算プラットフォームの統一された実行可能要素に変換するためのプロセス | |
JP4403080B2 (ja) | 再構成可能なハードウェアエミュレーションによる制御データフローグラフを用いたデバッグ | |
US6964029B2 (en) | System and method for partitioning control-dataflow graph representations | |
US7299458B2 (en) | System and method for converting control flow graph representations to control-dataflow graph representations | |
WO2000046704A2 (en) | Automated processor generation system and method for designing a configurable processor | |
Rohou et al. | Salto: System for assembly-language transformation and optimization | |
Qin et al. | Architecture Description Languages for Retargetable Compilation. | |
US7702499B1 (en) | Systems and methods for performing software performance estimations | |
Wirthlin et al. | Synthesizing RTL hardware from Java byte codes | |
JP2009015867A (ja) | 構成可能なプロセッサを設計するための自動プロセッサ生成システム及び生成方法 | |
Poulsen et al. | EPG source code instrumentation tools-user manual | |
Wahlen | C Compiler Aided Design of Application-Specific Instruction-Set Processors Using the Machine Description Language LISA | |
Janssen | Enhancing the Move framework | |
SVOBODA | ARCHITECTURE INFORMATION FOR LLVM COMPILER OPTIMIZATIONS | |
Chang | High-level cycle-accurate specification of microprocessors |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060925 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090818 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091030 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20091222 |