(57)【要約】多数の異なるプロセッサ、たとえば、汎用プロセッサ（ＧＰ）および少なくとも１台のコプロセッサ（ＣＯＰ）、或いは、２台以上のコプロセッサ（ＣＯＰＡ，ＣＯＰＢ，ＣＯＰＣ）を組み合わせるターゲットシステムは、関数の組の実行のためのフレキシビリティとスピードを組み合わせることが可能である。このようなターゲットシステムの設計は、仕様を汎用プロセッサによって実現されるべき部分とコプロセッサによって実現されるべき部分とに分割する必要があり、または、異なるコプロセッサによって実現されるべき複数の部分に分割する必要がある。本発明はソースコードにおける仕様を分割する方法を説明する。第１のステップで、仕様３０１は複数の抽象構文木１０１に変換される。第２のステップで、複数の抽象構文木１０１は少なくとも第１の組２０１および第２の組２０３に分割される。第１の抽象構文木の組２０１は第１のプロセッサ（ＧＰ，ＣＯＰＡ）によって実現されるべきであり、第２の抽象構文木の組２０３は第２のプロセッサ（ＣＯＰ，ＣＯＰＢ）によって実現されるべきである。抽象構文木の第１の組２０１および第２の組２０３は両方ともに、原ソースコード言語３０９および３１１のそれぞれで仕様に翻訳され、ユーザは仕様３０９および３１１にマニュアル変更３０５および３０７を加えることが可能である。さらに、専用コンパイラツールは専用設計ツールと共に、仕様３０９および３１１を、たとえば、対応した実行可能なマシンコード３１５およびコプロセッサの仕様３１９に変換するため使用可能である。
2005534114.tif 000002
【特許請求の範囲】
【請求項１】
ソースコードにおける仕様を分割する方法であって、
仕様を複数の抽象構文木に変換するステップと、
前記複数の抽象構文木を第１のプロセッサによって実現されるべき第１の抽象構文木の組と第２のプロセッサによって実現されるべき第２の抽象構文木の組に分割するステップと、
を備えたことを特徴とする方法。
【請求項２】
前記第２のプロセッサがコプロセッサである、請求項１に記載のソースコードにおける仕様を分割する方法。
【請求項３】
前記第１のプロセッサが汎用プロセッサである、請求項２に記載のソースコードにおける仕様を分割する方法。
【請求項４】
前記第１の抽象構文木の組を前記ソースコードによる第１の部分仕様に変換し、前記第２の抽象構文木の組を前記ソースコードによる第２の部分仕様に変換するステップをさらに含む、請求項１に記載のソースコードにおける仕様を分割する方法。
【請求項５】
前記複数の抽象構文木を第１の抽象構文木の組と第２の抽象構文木の組に分割するステップが、プロファイルデータに基づいて少なくとも一つの抽象構文木をアウトライン化するステップを含む、請求項１に記載のソースコードにおける仕様を分割する方法。
【請求項６】
前記複数の抽象構文木を第１の抽象構文木の組と第２の抽象構文木の組に分割するステップが、プログラマによって与えられた情報に基づいて少なくとも一つの抽象構文木をアウトライン化するステップを含む、請求項１に記載のソースコードにおける仕様を分割する方法。
【請求項７】
ターゲットシステムを生成する協調設計方法であって、
前記ターゲットシステムは、第１のプロセッサと少なくとも第２のプロセッサとを具備し、
請求項１に記載のソースコードにおける仕様を分割する方法を含む、
協調設計方法。
【請求項８】
ソースコードにおける仕様を分割する方法が、前記第１の抽象構文木の組を前記ソースコードによる第１の部分仕様に変換し、前記第２の抽象構文木の組を前記ソースコードによる第２の部分仕様に変換するステップをさらに含む、
請求項７に記載のターゲットシステムを生成する協調設計方法。
【請求項９】
前記第２のプロセッサがコプロセッサであり、前記第２の部分仕様が前記コプロセッサの仕様に変換される、請求項８に記載のターゲットシステムを生成する協調設計方法。
【請求項１０】
前記第１のプロセッサが汎用プロセッサであり、前記第１の部分仕様がコンパイラを用いてオブジェクトコードに変換される、請求項９に記載のターゲットシステムを生成する協調設計方法。
【請求項１１】
前記汎用プロセッサと前記コプロセッサとの間にインタフェースを定義するステップをさらに含む、請求項１０に記載のターゲットシステムを生成する協調設計方法。
【請求項１２】
前記コプロセッサの仕様がＡＳＩＣの仕様を含む、請求項９に記載の協調設計方法。
【請求項１３】
前記コプロセッサの仕様がプログラマブルプロセッサの仕様を含む、請求項９に記載の協調設計方法。
【請求項１４】
前記コプロセッサの仕様が再構成可能なプロセッサの仕様を含む、請求項９に記載の協調設計方法。
【請求項１５】
前記汎用プロセッサと前記コプロセッサとの間の前記インタフェースがリモート関数呼び出しを含み、
前記リモート関数呼び出しがパラメータの組を有し、
前記パラメータの組が、呼び出し先関数の識別子と、呼び出し先関数の入力データを指示する少なくとも一つの参照と、呼び出し先関数の結果データを指示する少なくとも一つの参照とを含む、
請求項１１に記載の協調設計方法。
【請求項１６】
前記リモート関数呼び出しのパラメータの組が、呼び出し先関数のリターン状態に関する情報を格納するため使用される記憶場所への参照をさらに含む、請求項１５に記載の協調設計方法。
【請求項１７】
前記ターゲットシステムがシステムメモリおよびシステムバスをさらに含み、
前記システムメモリ、前記第１のプロセッサおよび前記第２のプロセッサが前記バスシステムによって接続される、
請求項７に記載の協調設計方法。
【請求項１８】
前記汎用プロセッサがデジタル信号プロセッサである、請求項１０に記載の協調設計方法。
【請求項１９】
分割コンパイラプログラムがコンピュータシステム上で動かされるとき、請求項１に記載のソースコードにおける仕様を分割する方法のすべてのステップを実施する分割コンパイラプログラムプロダクト。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はソースコードにおける仕様を分割する方法に関する。
【０００２】
本発明はまた第１のプロセッサと少なくとも第２のプロセッサとを含むターゲットシステムを生成する協調設計方法に係わり、この協調設計方法はソースコードにおける仕様を分割する前記方法を含む。
【０００３】
本発明は、さらにコンピュータシステム上で動かされたときにソースコードにおける仕様を分割する前記方法のすべてのステップを実施する分割コンパイラプログラムプロダクトに関する。
【背景技術】
【０００４】
２台以上のプロセッサを含むターゲットシステムは関数の組の実行のためのフレキシビリティとスピードを組み合わせることを可能にさせる。このようなターゲットシステムの一例は制御プロセッサの制御下でアプリケーションを実行する２台以上のコプロセッサを有するシステムである。別の例はアプリケーションの一部を共に実行する汎用プロセッサおよびコプロセッサを有するシステムである。汎用プロセッサはソフトウェア制御され、適当なソフトウェアを用いることにより多種多様な希望の目的に適合させられ、大きなフレキシビリティを実現する。しかし、ある種の関数に対して、ソフトウェア制御プロセッサは、一般にその関数に専用のコプロセッサよりも速度が遅い。コプロセッサの例は、固定式ハードウェアアクセラレータ、パラメータ化可能なハードウェアアクセラレータ、再構成可能なハードウェア、特定用途向け命令セットプロセッサ、および、アクセラレータとして使用される専門化されたプログラム可能なプロセッサである。コプロセッサを使用するとき、演算の速度はフレキシビリティを犠牲にして高められる。さらに、コプロセッサの使用はターゲットシステムの電力効率を高める。コプロセッサは設計対象のタスクに適切であるが、しかし、そのタスクの変更版には適切でない。しかし、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）のような再構成可能な回路にコプロセッサを定義することは、ハードウェアのフレキシビリティを高めることができる。このような論理回路は様々な様式で繰り返し構成され得る。
【０００５】
汎用プロセッサとコプロセッサの両方を含むターゲットシステムの場合、コプロセッサは特定の関数、たとえば、スピードを要求する関数を実行するため使用され、汎用プロセッサはソフトウェアの制御下で残りの関数を実行可能である。このようなターゲットシステムの設計はハードウェア／ソフトウェア協調設計として知られている。設計プロセス内で、希望の機能を備えたターゲットシステムのため、どの関数をコプロセッサで実行し、どの関数をソフトウェアで実行すべきであるかを決定しなければならない。これはハードウェア／ソフトウェア分割として知られている。希望の機能の仕様をソフトウェアで実現されるべき部分とコプロセッサによって実現されるべき部分とに分割した後、実際の組み込みを行わなければならない。コンパイラは、ソフトウェアで実現されるべき部分を汎用プロセッサによって実行されるべきマシンコードに変換し、たとえば、ハードウェア合成ツールは、仕様のその部分によって規定されるように、ハードウェアを構成するか、または、ネットリストを発生する。
【０００６】
制御プロセッサと２台以上のコプロセッサを含むその他のターゲットシステムの場合、コプロセッサはアプリケーションを実行するため使用され、制御プロセッサはターゲットシステムを制御し、たとえば、オペレーティングシステムおよびユーザインタフェースを取り扱う。コプロセッサは特定の関数の組を効率的に取り扱うための専用のものでもよい。このようなターゲットシステムを設計するとき、どの関数が特定のコプロセッサによって実行されるかを決定するため協調設計方法も適用される。仕様は少なくとも第１のコプロセッサによって実現されるべき部分と第２のコプロセッサによって実現されるべき部分とに分割される。
【０００７】
国際公開第００／３８０８７号は、コプロセッサとソフトウェア制御リソースを共に含む電子回路を製作する協調設計システムを記載する。この協調設計システムは、ターゲット電子システムの振舞いの記述を受け取り、必要な機能をハードウェアとソフトウェアの間で自動的に分割する。パーティショナは抽象構文木から制御／データフロー図を作る。パーティショナは、次に、ユーザが未だリソースに割り当てていない記述の部分に作用する。
【０００８】
従来の協調設計方法の不都合な点は、一旦仕様の分割が行われてしまうと、ハードウェア部分および／またはソフトウェア部分を仕様の原ソースコードへ逆変換し得ないことである。このため、二つの重大な欠点が生じる。第１の欠点は、分割後に、ユーザが分割された仕様にマニュアル変更を加えることが実際上不可能であることである。このマニュアル変更は、たとえば、補助的な機能を特定のコプロセッサへ手動で移すことによってターゲットシステムの性能を改良するため実際的に非常に有用である。第２の欠点は、ハードウェア／ソフトウェア協調設計の場合に、ソフトウェアコンパイルおよびハードウェア合成が、獲得された制御／データフロー図表現上で実行されるべきであり、すなわち、これらのステップがハードウェア／ソフトウェア分割のため使用されたツールと同じツールによって実行される必要があることである。実際には、このツールは最も効率的なマシンコードおよび／またはハードウェアコンフィギュレーションを生み出さない。汎用プロセッサ向けのコンパイラと、コプロセッサ向けの設計ツールおよび／又コンパイラの使用は、ターゲットシステムの最適性能の獲得を可能にさせる。同様の問題は、制御プロセッサとアプリケーションを実行する２台以上のコプロセッサとを有するシステムの協調設計中にも生じる。この場合に、コプロセッサを設計する専用ツールの使用はターゲットシステムの最適設計を行うことも同様に可能にさせる。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、分割後に、第１のプロセッサによって実現されるべき部分をソースコード言語による仕様へ変換すること、および、第２のプロセッサによって実現されるべき部分をソースコード言語による仕様へ変換することの両方の変換を可能にさせる仕様の分割方法を提供することである。
【課題を解決するための手段】
【００１０】
上記目的は、仕様を複数の抽象構文木に変換するステップと、複数の抽象構文木を少なくとも第１のプロセッサによって実現されるべき第１の抽象構文木の組と第２のプロセッサによって実現されるべき第２の抽象構文木の組に分割するステップと、を含むことを特徴とする、ソースコードにおける仕様を分割する方法を用いて達成される。
【００１１】
この分割する方法はソースプログラムを表す複数の抽象構文木に作用する。抽象構文木の形式で表現された仕様は、ソースコード言語による仕様に逆変換可能である。したがって、分割後に、このような変換が第１のプロセッサによって実現されるべき部分並びに第２のプロセッサによって実現されるべき部分に対して行える。
【００１２】
本発明の一実施形態は、この分割する方法が、第１の抽象構文木の組をソースコードによる第１の部分仕様に変換し、第２の抽象構文木の組をソースコードによる第２の部分仕様に変換するステップをさらに含むことを特徴とする。この実施形態の効果は、ユーザが第１の部分仕様および第２の部分仕様にマニュアル変更を加えることを著しく容易にさせることである。この実施形態のもう一つの効果は、特定のコンパイラおよび特定の設計ツールが、第１のプロセッサによって第１の仕様を実現し、第２のプロセッサによって第２の部分仕様を実現するため使用可能なことである。
【００１３】
本発明の一実施形態は、複数の抽象構文木を第１の抽象構文木の組と第２の抽象構文木の組に分割するステップが、プロファイルデータに基づいて少なくとも一つの抽象構文木をアウトライン化するステップを含むことを特徴とする。この実施形態の効果は、このクリティカルな部分を認識する情報を与えることによって、仕様のクリティカル部分をコプロセッサによって実行されるべき部分に移すことを可能にさせることである。さらに、分割コンパイラプログラム用の入力データとしてプロファイルデータを使用することによって、ハードウェア／ソフトウェア分割を自動化することができる。
【００１４】
本発明の一実施形態は、第１のプロセッサと少なくとも第２のプロセッサとを含むターゲットシステムを生成する協調設計方法を提供し、この協調設計方法は、請求項１に記載された分割する方法を含む。この実施形態の効果は、分割された仕様を原ソースコード言語に変換可能であるため、この分割された仕様へのマニュアル変更が容易に行えることである。たとえば、第１のプロセッサによって実現されるべき部分から第２のプロセッサによって実現されるべき部分へ、または、その逆向きに、付加的な機能を手動で移す。さらに、ターゲットシステムを設計するとき、汎用プロセッサ向けのコンパイラプログラムと、コプロセッサ向きの設計ツールおよび／またはコンパイラが共に使用可能である。その結果として、ターゲットシステムのための最適性能が得られる。
【００１５】
本発明の一実施形態は、第２のプロセッサがコプロセッサであり、第２の部分仕様がコプロセッサの仕様に変換されることを特徴とする。本発明の一実施形態は、第１のプロセッサが汎用プロセッサであり、第１の部分仕様がコンパイラを用いてオブジェクトコードに変換されることを特徴とする。汎用プロセッサとコプロセッサを含むターゲットシステムは、汎用プロセッサのフレキシビリティとコプロセッサの高い性能を組み合わせることが可能である。
【００１６】
本発明の一実施形態は、協調設計方法が汎用プロセッサとコプロセッサとの間にインタフェースを定義するステップをさらに含むことを特徴とする。本実施形態の効果は、汎用プロセッサとコプロセッサとの間で、たとえば、同期のための情報交換、または、データを読み書きするための参照交換が可能になることである。
【００１７】
本発明の一実施形態は、汎用プロセッサとコプロセッサとの間のインタフェースがリモート関数呼び出しを含み、リモート関数呼び出しがパラメータの組を有し、パラメータの組が、呼び出し先関数の識別子と、呼び出し先関数の入力データを指示する少なくとも一つの参照と、呼び出し先関数の結果データを指示する少なくとも一つの参照と、を含むことを特徴とする。この実施形態の効果は、リモート関数呼び出しが汎用プロセッサとコプロセッサを同期させ、入力データのための参照と共に結果データのための参照を引き渡すことを可能にさせることである。
【００１８】
本発明の一実施形態は、リモート関数呼び出しのパラメータの組が呼び出し先関数のリターン状態に関する情報を格納するため使用される記憶場所への参照をさらに含むことを特徴とする。コプロセッサによって実行される関数が２箇所以上の終了ポイントを有する場合に、実際の終了ポイントに関する情報は、汎用プロセッサがソフトウェアのどのポイントでその実行を再開するかを決めるために利用できなければならない。コプロセッサによって実行された関数のリターン状態に関する情報を格納するため使用される記憶場所への参照を使用することにより、汎用プロセッサはこの情報にアクセスする。
【００１９】
一実施形態は、汎用プロセッサがデジタル信号プロセッサであることを特徴とする。デジタル信号プロセッサは、典型的に、仕様の比較的小さい部分が全体的な実行時間を決めるアプリケーションを処理する。コプロセッサを使用してアプリケーションのこの部分を実行することにより、全体的な性能を高めることが可能である。
【００２０】
本発明によれば、分割コンパイラプログラムプロダクトは、前記分割コンパイラプログラムがコンピュータシステム上で動かされるとき、請求項１に記載された分割する方法のすべてのステップを実施する。このプロダクトの効果は、分割を自動化することができ、これにより、効率を高めることである。
【発明を実施するための最良の形態】
【００２１】
上に記載された実施形態の特徴は添付図面を参照してさらに解明され説明される。
【００２２】
本発明による分割方法の第１実施形態において、ユーザはソースコード言語としてＣ言語でプログラムを記述し、そのプログラムが汎用プロセッサによって実現される第１の部分とコプロセッサによって実現される第２の部分に分割される。一例として、Ｃ言語プログラムのソースコードの断片は３個の関数ｆ、ｇおよびｈにより構成され、各関数は入力パラメータとして１個の整数を有し、実行されるべき２個の任意のステートメントを有する。
f (int x)
{
s1;
s2;
}
g (int y)
{
s3;
s4;
}
h (int z)
{
s5;
s6;
}
【００２３】
分割方法は上記のソースコード断片を使用して説明される。第１ステップにおいて、ソースコードは複数の抽象構文木（ＡＳＴ）に翻訳される。複数の抽象構文木は、データ構造として木構造を使用することにより、抽象構文のソースコードの内部構造を表現する。ＡＳＴは、プロダクション名でラベル付けされたノードと、文法の終端を表すリーフとを有する。ソースコードの複数の抽象構文木への翻訳はパーサーを用いて実行可能であり、パーサーはその入力をスキャナーから獲得し、次に、複数の抽象構文木を構築する。ソースコードの走査とその後に続く構文解析の技術は両方とも、コンパイラテクノロジーの分野でよく知られた原理である。関数ｆ、ｇおよびｈを含むソースコード断片の得られた複数の抽象構文木１０１は図１に示される。図１では、３個の抽象構文木は、ソースコード断片の関数ｆ、ｇおよびｈをそれぞれに参照するノードＦＤ１、ＦＤ２およびＦＤ３によって表されている。略語ＦＤは関数定義を表し、ＦＨは関数ヘッダを表し、ＦＢは関数本体を表し、ＰＬはパラメータリストを表す。これらの略語の後には参照番号が続く。パラメータリストＰＬ１、ＰＬ２およびＰＬ３についてはこれ以上明記されない。
【００２４】
第２のステップにおいて、複数の抽象構文木１０１は第１および第２の組に分割される。第１の抽象構文木の組は汎用プロセッサによって実現され、第２の抽象構文木の組はコプロセッサによって実現されるべきである。コプロセッサによって実現されるべき抽象構文木は第２の抽象構文木の組へ移すために選択される。選択された抽象構文木は、関数ｆ、ｇおよびｈを含むソースコード断片内の特定の関数または特定のステートメントに対応する。特定の抽象構文木を複数の抽象構文木１０１から第２の抽象構文木の組へ移すプロセスはアウトライン化と呼ばれる。別の関数によって呼び出されるステートメント及び関数のいずれかに対応した抽象構文木をアウトライン化するとき、その抽象構文木は移されたステートメント及び関数のいずれかを呼び出す関数に対応した第１の組内の新しい抽象構文木によって置換される。移されたステートメントまたは関数が変数を有する場合に、これらの変数は移されたステートメントまたは関数に引数として渡される。
【００２５】
図１を参照すると、ソースコード断片内の関数ｈに対応し、ノードＦＤ３およびそのブランチを含む抽象構文木は、第２の抽象構文木の組へ移すため選択される。さらに、ソースコード断片内の関数ｇのステートメントｓ４に対応し、リーフｓ４だけを含む抽象構文木は、第２の抽象構文木の組へ移すため選択される。ステートメントｓ４は、ソースコード断片に表されていない変数ｙを使用する。抽象構文木のアウトライン化と置換によって、複数の抽象構文木１０１は第１の抽象構文木の組２０１と第２の抽象構文木の組２０３に分割される。
【００２６】
図２を参照すると、複数の抽象構文木１０１の分割後に得られた抽象構文木の第１の組２０１および第２の組２０３が表される。複数の抽象構文木１０１の抽象構文木ｓ４のアウトライン化は、ノードＦＤ７およびそのブランチを含む抽象構文木に対応した関数を第２の抽象構文木の組２０３に作成することにより実現される。複数の抽象構文木１０１の抽象構文木ｓ４のアウトライン化の後に続いて、抽象構文木ｓ４は、第２の抽象構文木の組２０３内の抽象構文木ＦＤ７として存在する関数ｋへの関数呼び出しによって置換される。変数ｙは第２の抽象構文木の組２０３に作成された新しい関数ｋへ引数として渡される。第１の抽象構文木の組２０１は、ソースコード断片内の関数ｆに対応し、ノードＦＤ４およびそのブランチを具備した抽象構文木を含む。第１の組はノードＦＤ５を具備した抽象構文木をさらに含み、ノードＦＤ５のブランチのうちの一つに抽象構文木ｋがある。第２の抽象構文木の組２０３は、ソースコード断片内の関数ｈに対応し、ノードＦＤ６およびそのブランチを具備した抽象構文木を含む。第２の組は、ソースコード断片内の関数ｇのステートメントｓ４に対応し、ノードＦＤ７およびそのブランチを具備した抽象構文木をさらに含む。
【００２７】
第２の抽象構文木の組２０３に移されるべき抽象構文木は、ソースコード断片内の対応した関数またはステートメントを手動でマーキングすることにより選択可能である。ユーザはコプロセッサへ移されるべき機能を選択しなければならない。この情報はソースコード断片を複数の抽象構文木へ変換するときに複数の抽象構文木に付加され、この情報は続いて分割のため使用される。抽象構文木の第１の組２０１および第２の組２０３はソースコード言語の使用に逆変換可能である。ソースコードのすべての必要な内部情報は、このような変換を可能にさせるため、抽象構文木表現に存在したままである。
【００２８】
一部の実施形態では、仕様は３組以上の抽象構文木に、たとえば、３組の抽象構文木に分割される。第１の組は汎用プロセッサによって実現され、第２の組および第３の組はそれぞれ第１のコプロセッサおよび第２のコプロセッサによって実現される。本実施形態の効果は、それぞれが仕様の特定の部分を実行するために専用の多数のコプロセッサを定義できることである。
【００２９】
さらに別の実施形態において、仕様は少なくとも２組の抽象構文木の組に分割される。少なくとも２組のうちのそれぞれの組はコプロセッサによって実現される。その結果として、アプリケーションを効率的に実行するコプロセッサの組が定義できる。
【００３０】
有利な一実施形態において、第１の抽象構文木の組２０１はソースコード言語の第１の部分仕様に変換され、第２の抽象構文木の組２０３はソースコード言語の第２の仕様に変換される。第１の抽象構文木の組２０１を変換するとき、以下の第１の部分仕様が得られる。
f (int x)
{
s1;
s2;
}
g (int y)
{
s3;
k(y);
}
【００３１】
第２の抽象構文木の組２０３を変換するとき、以下の第２の部分仕様が得られる。
h (int z)
{
s5;
s6;
}
k (int y)
{
s4;
}
【００３２】
ユーザは第１および第２の部分仕様にマニュアル変更を加えるかもしれない。汎用プロセッサで第１の部分仕様を実現し、コプロセッサで第２の部分仕様を実現することは、特定のコンパイラ、および、特定の設計ツールおよび／またはコンパイラを用いて行われる。
【００３３】
別の実施形態において、複数の抽象構文木１０１を第１の抽象構文木の組２０１と第２の抽象構文木の組２０３に分割するステップは、プロファイルデータに基づいて少なくとも一つの抽象構文木をアウトライン化するステップを含む。仕様のクリティカルな部分がコプロセッサによって実行されるべきであることは最も明白である。典型的な入力データを使用して仕様によって定義されるようなアプリケーションを動かすことにより、プロファイルデータが獲得できる。関連したプロファイルデータのタイプは、特に、コプロセッサの特性に依存する。たとえば、コプロセッサが演算を並列に高速実行する能力を備えているならば、プロファイルデータは、演算が実行される回数と、コプロセッサが処理する並列化の量に重点が置かれる。プロファイルデータは、仕様中のクリティカルな演算を選択するため使用されるので、対応した抽象構文木は第２の抽象構文木の組２０３へ移される。その結果として、コプロセッサは仕様のクリティカルな部分を実現する。さらに、プロファイルデータの使用は、仕様の第１および第２の部分仕様への自動分割を可能にさせる。
【００３４】
図３を参照すると、ターゲットシステムを生成する協調設計方法が概略的に表されている。ターゲットシステムは、汎用プロセッサとコプロセッサを含む。第１のステップ３０３において、ソースコード言語Ｃによる仕様３０１は、汎用プロセッサによって実現されるべきＣ言語による第１の部分仕様３０９と、コプロセッサによって実現されるべきＣ言語による第２の部分仕様３１１と、に分割される。このステップ３０３は、上記の実施形態に基づいて、ソースコードで仕様を分割する方法を含み、
−ソースコード言語Ｃ言語による仕様３０１をスキャナーおよびパーサーを用いて複数の抽象構文ツリーへ変換し、
−コプロセッサによって実現されるべきクリティカルな演算を識別するプロファイルデータを使用して、複数の抽象構文木を第１の抽象構文木の組と第２の抽象構文木の組に分割し、
−第１の抽象構文木の組をＣ言語による第１の部分仕様３０９に翻訳し、第２の抽象構文木の組をＣ言語による第２の部分仕様３１１に変換する。
【００３５】
次のステップでは、ユーザは、第１の部分仕様３０９および第２の部分仕様３１１にそれぞれマニュアル変更３０５および３０７を加える。たとえば、必要に応じて、機能が第１の部分仕様から第２の部分仕様へ移される。これらの仕様が原ソースコードであるため、ユーザによるあらゆるマニュアル変更は著しく容易になる。
【００３６】
次のステップ３１３において、Ｃ言語による第１の部分仕様３０９は、汎用プロセッサのための特定のコンパイラを使用して実行可能マシンコード３１５に変換される。ステップ３１３と並列に実行できるステップ３１７において、第２の部分仕様３１１は特定の設計ツールおよび／またはコンパイラを使用してコプロセッサの仕様３１９に変換される。一部の実施形態では、コプロセッサの仕様は、たとえば、ネットリストの形式であり、特定用途向けＩＣ（ＡＳＩＣ）を設計するハードウェア仕様である。他の実施形態では、コプロセッサ仕様は、構成可能なプロセッサのためのハードウェア設計およびコンフィギュレーション仕様であり、または、既存の構成可能なプロセッサが使用されるならば、コンフィギュレーション仕様だけである。一部のさらなる実施形態では、コプロセッサ仕様は、プログラマブルプロセッサのためのハードウェア設計と、たとえばマイクロコード若しくは実行可能マシンコードの形式のソフトウェア仕様とであり、既存のプログラマブルプロセッサが使用されるならばソフトウェア仕様だけである。
【００３７】
別の実施形態では、ターゲットシステムは、制御プロセッサ、並びに、第１および第２のコプロセッサを含む。仕様３０１はこれらのコプロセッサにマップされる。第１の部分仕様３０９は、特定の設計ツールおよび／またはコンパイラを使用して第１のコプロセッサの仕様に変換される。第２の部分仕様３１１は、同様に特定の設計ツールおよび／またはコンパイラを使用して第２のコプロセッサの仕様に変換される。
【００３８】
異なる実施形態において、協調設計の第１のステップ３０３中に、インタフェースが汎用プロセッサとコプロセッサとの間に定義される。このインタフェースは、第１の部分仕様３０９および第２の部分仕様３１１における分割後に定義可能である。インタフェースは、データの読み書き、並びに、汎用プロセッサとコプロセッサとの間の同期のために必要な制御情報の読み書きのためのメモリアドレスにより構成してもよい。
【００３９】
有利な一実施形態では、汎用プロセッサとコプロセッサとの間のインタフェースはリモート関数呼び出しを含む。リモート関数呼び出しを用いて、汎用プロセッサはコプロセッサによって実現される関数を呼び出し、コプロセッサが特定の関数を実行し終えた瞬間に実行を再開する。或いは、汎用プロセッサは、当面の間は異なったタスクに切り替わってもよい。リモート関数呼び出しを使用することにより、汎用プロセッサとコプロセッサとの間の同期が暗に存在する。リモート関数呼び出しを実行するとき、コプロセッサによって実行されるべき関数の識別子がパラメータとして渡される。さらに、入力データを獲得するためのメモリアドレス、並びに、特定の関数の結果データを書き込むためのメモリアドレスがリモート関数呼び出しのパラメータとして渡される。コプロセッサはシステムメモリから入力データを読み出し、システムメモリへ出力データを書き込むことが可能である。
【００４０】
一部の実施形態では、また、コプロセッサによって実行された関数のリターン状態に関する情報を格納するため使用されるメモリ参照がリモート関数呼び出しのパラメータとして渡される。特定の関数が２箇所以上の終了ポイントを有し、その関数の実行後に制御が汎用プロセッサに戻される場合には、汎用プロセッサは、ソフトウェア上のどのポイントでその実行を再開すべきであるかに関する情報にアクセスしなければならない。このメモリ参照を介して、汎用プロセッサは特定の関数のリターン状態を取り出すことが可能である。
【００４１】
一部の実施形態では、協調設計方法の第１のステップ３０３中に、第２の抽象構文木の組に移された機能は第１の抽象構文木の組に複製される。図４を参照すると、仕様の一部を通る関数呼び出しのフローが概略的に表されている。実行のポイントで、関数呼び出しＦＣがステートメントＳ１に対して行われ、このステートメントは「ｉｆ  ｔｈｅｎ  −  ｅｌｓｅ」構造を含んでいる。ステートメントＳ１の後には、「ｉｆ  ｔｈｅｎ  −  ｅｌｓｅ」構造のガード節の評価結果に依存して、ステートメントＳ４またはステートメントＳ２が続く。ステートメントＳ４を実行した後、ステートメントＳ２が実行される。ステートメントＳ２の実行の後にステートメントＳ３の実行が続く。次に、ステートメントＳ３は制御を返す。クリティカルパスＣＰはステートメントＳ１、Ｓ２およびＳ３を含み、これらは、第２の抽象構文木の組に移された対応した抽象構文木の形式である。ステートメントＳ１の対応した抽象構文木は、第１の抽象構文木の組において、アウトライン化されたステートメントＳ１、Ｓ２およびＳ３への関数呼び出しを行う新しい抽象構文木によって置換される。実行中に、ステートメントＳ１、Ｓ２およびＳ３はコプロセッサによって実行される。しかし、ステートメントＳ１の後にステートメントＳ４が続く場合には、制御が汎用プロセッサに戻される。汎用プロセッサとコプロセッサとの間の関数呼び出しにより生じるオーバーヘッドを減少させるため、ステートメントＳ２およびＳ３は、それらの対応した抽象構文木を追加することにより、第１の抽象構文木の組に複製される。これにより得られたステートメント実行のフローは図５に示されている。同図を参照すると、複製されたステートメントは、それぞれ、ステートメントＳ２’およびステートメントＳ３’として表されている。コプロセッサは５０１によって示されたステートメントを実行し、汎用プロセッサは５０３によって示されたステートメントを実行する。ステートメントＳ３とステートメントＳ３’は両方とも、それらの実行の完了後に、同じ復帰のポイントを有する。偶然にステートメントＳ２’およびＳ３’が汎用プロセッサによって実行されるべき場合には、性能の損失よりもオーバーヘッドの低下によって得られる利益の方が上回る。
【００４２】
図６を参照すると、本発明の一実施形態による協調設計方法を用いて設計されたターゲットシステム６０１が表されている。ターゲットシステムは、システムメモリＳＭ、汎用プロセッサＧＰ、コプロセッサＣＯＰおよびシステムバスＳＢを含む。システムメモリＳＭ、汎用プロセッサＧＰおよびコプロセッサＣＯＰは、システムバスＳＢを介して接続される。別の実施形態では、コプロセッサＣＯＰおよびシステムメモリＳＭは直接的に接続される。さらに別の実施形態では、汎用プロセッサＧＰおよびコプロセッサＣＯＰは直接的に接続される。システムメモリＳＭは複数のメモリレジスタ６０３を含む。汎用プロセッサＧＰはレジスタファイル６０５を含む。コプロセッサＣＯＰは、レジスタファイル６０７、コンフィギュレーションメモリＣＭ、制御ロジックＣＬおよびプログラムカウンタＰＣを含む。仕様を分割した後、多数の関数がコプロセッサＣＯＰによって実現される。コプロセッサＣＯＰはこれらの関数を実行するためコンフィギュレーションメモリＣＭによって構成される。本実施形態においてコプロセッサによって実現される機能はベクトル加算：
Ｃ［ｉ］＝Ａ［ｉ］＋Ｂ［ｉ］
であり、ここで、Ａ、ＢおよびＣは関連した３個のベクトルを表し、ｉは配列添字を表す。
【００４３】
本実施形態において、コプロセッサは再構成可能なプロセッサであり、たとえば、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）である。他の実施形態では、コプロセッサは、プログラマブルプロセッサ、たとえば、超長命令語（ＶＬＩＷ）プロセッサ若しくは特定用途向け集積プロセッサ（ＡＳＩＰ）であり、または、コプロセッサは特定用途向けＩＣ（ＡＳＩＣ）を含む。
【００４４】
汎用プロセッサＧＰはアプリケーションの実行を開始する。汎用プロセッサが制御をコプロセッサＣＯＰに切り替えようとする瞬間に、汎用プロセッサはリモート関数呼び出しを行う。たとえば、ベクトル加算プログラムが実行されるべき場合である。リモート関数呼び出しの間に、以下のパラメータがコプロセッサＣＯＰに渡される。
ｆｕｎｃ＿ｉｄ：コプロセッサＣＯＰ内のベクトル加算関数の識別子
＆Ａ，＆Ｂ，＆Ｃ：計算に関わる３個のベクトルのシステムメモリＳＭにおけるアドレス
＆ｒｅｔ＿ｓｔａｔ：コプロセッサＣＯＰによって実行された関数のリターン状態を格納する変数のシステムメモリＳＭにおけるアドレス
【００４５】
リモート関数呼び出しの前に、すべてのパラメータは汎用プロセッサＧＰのレジスタファイル６０５に格納される。リモート関数呼び出し中に、これらのパラメータはコプロセッサＣＯＰに渡される。本実施形態において、これらのパラメータは、図６に示されていない汎用プロセッサＧＰとコプロセッサＣＯＰのポートとの間の直接的な接続を介してレジスタファイル６０７に書き込まれる。一部の実施形態では、コプロセッサＣＯＰはこれらのパラメータをメモリから所定の仮想レジスタファイルへ読み出し可能である。他の実施形態では、汎用プロセッサＧＰは、これらのパラメータをメモリマップドＩ／Ｏを介してレジスタファイル６０７へ直接的に書き込み可能である。
【００４６】
コプロセッサＣＯＰのレジスタファイル６０７に格納されたｆｕｎｃ＿ｉｄパラメータは、制御ロジックＣＬによって読み出され、コンフィギュレーションメモリＣＭ内のベクトル加算プログラムの第１のコンフィギュレーションを指示するプログラムカウンタＰＣに翻訳される。ベクトル加算が単一コンフィギュレーションに適合しない場合、より大規模の計算はランタイムに変更される多数のコンフィギュレーションを必要とする。この場合、プログラムカウンタＰＣは組の中の第１のコンフィギュレーションを指示する。
【００４７】
コプロセッサＣＯＰは、システムバスＳＢを介して、汎用プロセッサＧＰとは無関係にシステムメモリＳＭにアクセスする。ベクトルＡおよびＢの値はシステムメモリＳＭの複数のメモリレジスタ６０３の中の対応したレジスタから読み出される。ベクトル加算プログラムは、ＡおよびＢの値を使用して、コプロセッサＣＯＰによって実行される。実行後、Ｃの計算値が、システムバスＳＢを介して、コプロセッサＣＯＰによって複数のメモリレジスタ６０３の中の対応したレジスタへ書き込まれる。変数ｒｅｔ＿ｓｔａｔの値は、また、レジスタファイル６０７に格納された変数ｒｅｔ＿ｓｔａｔのアドレスを使用して、コプロセッサＣＯＰによって複数のメモリレジスタ６０３の中の対応したメモリレジスタへ書き込まれる。図６に示されていない同期手段が設けられるので、コプロセッサＣＯＰは、たとえば、割り込みを用いて、タスクの終了を汎用プロセッサＧＰに通知可能である。続いて、汎用プロセッサＧＰは、システムバスＳＢを介して、システムメモリＳＭの複数のメモリレジスタ６０３の中対応したメモリレジスタからパラメータｒｅｔ＿ｓｔａｔの値を読み出し可能である。ｒｅｔ＿ｓｔａｔの値を使用して、汎用プロセッサＧＰは、その実行を開始すべきポイントを決定し、実際にアプリケーションまたはタスクを再開可能である。
【００４８】
図７を参照すると、本発明の一実施形態による協調設計方法を用いて設計されたターゲットシステム７０１が表されている。ターゲットシステムは、システムメモリＳＭ、制御プロセッサＣＴＲ、コプロセッサＣＯＰＡ、ＣＯＰＢおよびＣＯＰＣ、システムバスＳＢ、入力／出力（ＩＯ）モジュールＩＯＭ、並びに、ローカルメモリＬＭ、ＬＭ１およびＬＭ２を含む。システムメモリＳＭ、コプロセッサＣＯＰＡ、ＣＯＰＢおよびＣＯＰＣ、制御プロセッサＣＴＲ、並びに、入力／出力モジュールＩＯＭは、システムバスＳＢによって接続される。別の実施形態では、ターゲットシステムの様々な部分の間に通信は、ブロッキング先入れ先出し（ＦＩＦＯ）バッファに基づくデータ駆動型の通信ネットワークによって行われる。コプロセッサＣＯＰＡはローカルメモリＬＭに接続され、コプロセッサＣＯＰＢはローカルメモリＬＭ１およびＬＭ２に接続される。オペレーティングシステム、割り込み、並びに、ユーザインタフェースのハンドリングのような標準的なシステム制御タスクは、制御プロセッサＣＴＲにマップされる。非常に高い性能を要求するアプリケーション、たとえば、ＭＰＥＧ若しくはＭＰ３のようなメディア符号化／復号化アプリケーションは、コプロセッサＣＯＰＡ、ＣＯＰＢおよびＣＯＰＣにマップされる。コプロセッサＣＯＰＡ、ＣＯＰＢおよびＣＯＰＣは、多数の演算を並列に実行する能力を備えたプロセッサ、たとえば、超長命令語（ＶＬＩＷ）プロセッサまたはスーパースカラプロセッサである。これらのタイプのプロセッサは多数の発行スロットを含み、各発行スロットは１台以上の機能ユニットに対応する。データパスは制御語の組によって制御される。各制御語はデータパスの部分を制御し、これらの部分は、数値演算ユニットまたはその他の機能ユニットのためのレジスタアドレスおよびオペレーションコードを含む。命令の各組は、一般に命令のバイナリフォーマットを対応した制御語に翻訳する命令デコーダを用いて、または、超小型記憶装置、すなわち、制御語をそのまま収容するメモリを用いて、制御語の新しい組を発生する。典型的に、制御語は、オペレーションコードと、２個のオペランドレジスタインデックスと、結果レジスタインデックスとを含むＲＩＳＣのようなオペレーションを表現する。オペランドレジスタインデックスおよび結果レジスタインデックスはレジスタファイル内のレジスタを指示する。ＶＬＩＷプロセッサの場合に、多数の命令が一つの長い命令、いわゆるＶＬＩＷ命令に詰め込まれる。ＶＬＩＷプロセッサは、これらの多数の命令を並列に実行するため多数の独立した機能ユニットを使用する。プロセッサは、プログラムにおいて命令レベルの並列化を利用可能にさせ、これにより、２個以上の命令を同時に実行する。本実施形態において、コプロセッサＣＯＰＡ、ＣＯＰＢおよびＣＯＰＣは、異なる個数の発行スロットを含み、すなわち、コプロセッサＣＯＰＡは５個の発行スロットを含み、コプロセッサＣＯＰＢは１５個の発行スロットを含み、コプロセッサＣＯＰＣは８個の発行スロットを含む。したがって、これらのコプロセッサは、異なるレベルの命令レベル並列化によって関数を取り扱う能力を備えている。一例として、ＭＰＥＧ符号化／復号化アプリケーションがコプロセッサＣＯＰＡ、ＣＯＰＢおよびＣＯＰＣにマップされる。ＭＰＥＧアプリケーションは、数種類の関数、すなわち、離散コサイン変換（ＤＣＴ）関数、量子化関数および動き推定関数で作られる。ＭＰＥＧアプリケーションは、本発明による仕様を分割する方法を使用して、コプロセッサＣＯＰＡ、ＣＯＰＢおよびＣＯＰＣの全体に分割される。動き推定関数はコプロセッサＣＯＰＢにマップされるが、その理由はこの関数が本来的に大規模の命令レベル並列化を含むからである。動き推定はビデオシーケンスの少なくとも二つの異なるフレームを通して行われ、これらの二つのフレームがローカルメモリＬＭ１およびＬＭ２にそれぞれ格納される。ＤＣＴ関数は、本来的な命令レベル並列化を有し、小規模のローカルメモリ記憶を必要とするので、コプロセッサＣＯＰＣにマップされる。量子化関数は、本来的に逐次的な関数であり、すなわち、命令レベルの並列化がない。量子化関数は、ローカルメモリに格納することが最適であるルックアップテーブルを必要とせず、システムバスのトランザクションの回数を減少させる。したがって、量子化関数はコプロセッサＣＯＰＡにマップするのが最適である。ＭＰＥＧアプリケーションを分割した後、それぞれの特定のプロセッサにマップされた部分は、専用ツールを使用して、そのプロセッサの仕様へ別々に変換可能である。その結果として、ＭＰＥＧアプリケーションを取り扱うターゲットシステム７０１の最適設計が得られる。
【００４９】
上記の実施形態は本発明の限定ではなく本発明の例示であり、当業者は請求項に記載された事項の範囲から逸脱することなく多数の代替的な実施形態を設計し得ることに注意すべきである。請求項中、括弧内に記載された参照符号は請求項を限定する事項として解釈されるべきではない。用語「含む、具備する（ｃｏｍｐｒｉｓｉｎｇ）」は請求項に列挙されていない要素またはステップの存在を除外するものではない。要素の前に置かれた冠詞「ａ」や「ａｎ」はそれらの要素が複数個であることを除外するものではない。本発明は複数の別個の要素を含むハードウェアを用いて、並びに、適切にプログラムされたコンピュータを用いて実施可能である。複数の手段を列挙する装置請求項において、これらの手段の幾つかは全く同一のハードウェアによって具現化できる。単にある特定の手段が相互に異なる従属請求項に記載されていることは、これらの手段の組み合わせを有利になるように使用できないことを示すものではない。
【図面の簡単な説明】
【００５０】
【図１】ソースコード断片を走査し構文解析した後に得られた複数の抽象構文木を表す図である。
【図２】図１に表された複数の抽象構文木を分割した後に得られた第１および第２の抽象構文木の組を表す図である。
【図３】ターゲットシステムを生成する本発明による協調設計方法を表す図である。
【図４】分割前に仕様の一部を通るステートメント実行のフローを表す図である。
【図５】分割後のステートメント実行のフローを表す図である。
【図６】本発明による協調設計方法によって生成された第１のターゲットシステムを表す図である。
【図７】本発明による協調設計方法によって生成された第２のターゲットシステムを表す図である。
【図１】
2005534114.tif 000003
【図２】
2005534114.tif 000004
【図３】
2005534114.tif 000005
【図４】
2005534114.tif 000006
【図５】
2005534114.tif 000007
【図６】
2005534114.tif 000008
【図７】
2005534114.tif 000009
【国際調査報告】
2005534114.tif 000010
2005534114.tif 000011
2005534114.tif 000012