JP2011503695A - プロセッサを設計するための方法と装置 - Google Patents

Abstract

プロセッサを設計する方法であって、リソースパラメータを用いて複数のリソースを特定する、プロセッサの初期モデルを提供するステップと、選択されたアプリケーションで使用が必要なリソースを示す統計的確率を提供するステップと、この統計的確率に基づいて、少なくとも１つのリソースパラメータの緩和、および／または初期仕様で特定されたリソースの量の制限を行うステップとを含む。

Description

本発明はプロセッサの設計方法に関する。
本発明はプロセッサの設計装置に関する。

ＡＳＩＰ（Application specific instruction set processor）は特定のアプリケーション領域に設計されたプロセッサである。このプロセッサ設計は、複数のリソースを備え、これらのリソースは、機能的に結合することができる。リソースとは、プロセッサでタスクを実行するのに用いられる全ての装置であり、演算リソースのようなものである。例えば低レベル演算リソースは乗算器、加算器のようなものであり、高レベル演算リソースは、フィルターや変換器であり、記憶リソースは、レジスタファイルやメモリ装置のようなものであり、通信リソースはポート、バス、ポイント間リンク、ネットワークのようなものであり、これらにおけるルーティングリソースは、マルチプレクサのようなものである。

このプロセッサのリソースの量、タイプおよび大きさ（レジスタファイル、命令セット、並列度、相互接続）はそのアプリケーション領域毎に調整される。このようなＡＳＩＰの開発で設計者をサポートする、ＡＲＭ社のＯｐｔｉｍｏｄｅのような自動設計ツールが提供されている。自動設計ツールについては、例えばＣｏＷａｒｅ（登録商標）社の国際出願公開公報ＷＯ２００４０１７２３２に記載されている。設計者は、ＬＩＳＡ２．０のような設計言語を用いて動作、命令セットコーディングおよびシンタックスを含むプロセッサのアーキテクチャの様々な仕様を記述できる。目標システムの全てのコンポーネントは、Ｃ／Ｃ＋＋プログラミング言語の拡張であるシンタックスを用いた統一された方法で記述することができる。ＬＩＳＡ２．０による記述は、プロセッサの設計者、ソフトウェア設計ツール、およびハードウェア／ソフトウェアシステムの設計者の間で交換できる、曖昧さの無い仕様である。更に、階層的モデリング様式がサポートされ、コードの構造化と容易なメンテナンスを可能としている。従って、設計者は、既存のモジュールである、加算器、乗算器および更に複雑なプロセシング素子のようなプロセシング装置、メモリ、キャッシュおよびレジスタファイルのような記憶装置、バス、ネットワークおよび他の装置とのダイレクトリンクのような相互接続装置を再利用することができる。もう１つの高級言語はターゲット・コンパイラ・テクノロジ社のｎＭＬである。

ＡＳＩＰは通常、汎用プロセッサ（general purpose processor, ＧＰＰ）またはデジタルシグナルプロセッサ（ＤＳＰ）が充分な性能をもたらすことができない場合、そして配線接続されたブロックが充分な柔軟性を持たない場合に、埋め込みシステムで適用される。

このような埋め込みシステムでは、ＡＳＩＰは普通は、ＲＯＭにエンコードすることもできる１個のアプリケーションを実行するが、これにより設計時のプログラミング可能性が制限されている。

ＲＯＭのプログラムは、プロセッサの提供する全てのリソースを必要としなくともよい。従って、特定のプログラムでは、プロセッサは使用しないリソースを持っていてよい。使用されない場合でも、これらのリソースは、依然としてシリコン面積を占め、電力を消費するという好ましくない結果をもたらす。不使用のリソースはまた、プロセッサを低速にする。例えば、アドレスのデコーディングに必要な時間は一般的にアドレス空間に比例する。従って、プロセッサが、不使用のキャッシュのリソースを備えている場合、アドレスのデコーディング時間は、必要以上に長くなる。自動設計ツールを使用できるにも拘わらず、前記のアプリケーションでは、過剰なリソースのない新たなＡＳＩＰの開発には依然としてコストがかかっている。

本発明の目的は、上記の欠点を少なくとも部分的に克服することである。

以下のステップを備えたプロセッサの設計方法が提供される。
・リソースパラメータを用いて複数のリソースを特定する、プロセッサの初期モデルを提供するステップ。
・選択されたアプリケーションで用いられる必要なリソースを示す統計的確率を提供するステップ。
・少なくとも１つのリソースパラメータの緩和、および／または初期仕様で特定されたリソースの量の、統計的確率に基づいた制限を提供するステップ。

統計的確率は各々のリソースに対し、その使用が必要かどうかを示す。これらのリソースで使用の必要がないものは、プロセッサの仕様から除去される。例えばプロセッサのレジスタファイルの仕様は、その使用が必要なレジスタまで切り詰められる。この手順では、このリソースが実際どの程度の頻度で使用されるかについては考慮されない。従って、この統計的確率は、各々のリソースに対しその使用が必要かどうかということを２値的に示す。本発明の方法の１つの実施形態では、選択されたアプリケーションで使用が必要なことを示す統計的確率は、選択されたアプリケーションで使用されるソフトウェアをコンパイルするコンパイラにより提供される。この実施形態は、コンパイラは、このコンパイラが生成しなければならない実行ファイルにおいて、リソースのスケジュールを行う必要があるということに有利さを持つ。従って、このコンパイラは、各々のリソースまたはその素子がスケジュールされるかどうかということを示す統計的情報を提供することに適している。この目的のためにはリソースがこのアプリケーションによって割り当てられるかどうかを知るということで充分であり、このリソースが使用のために実際にスケジュールされるときは知る必要がないので、全コンパイルは不要である。

この方法は、プロセッサをより効率化する。不使用のリソースの除去によりシリコン面積が削減される。この除去により、また使用電力が削減される。本発明の実施形態では、例えばデコーディング時間の短縮により、プロセッサ速度が増大する。この結果得られるプロセッサは、柔軟性が減少し、例えばそのアプリケーションがＲＯＭに保存される場合には、もはやプログラミング不可能とさえなる可能性がある。しかしながら、これは統計的確率が与えられているアプリケーションを実行するだけであるので、不利ということではない。

なお、国際出願公開公報ＷＯ２００４／０１７２３２は、シミュレータで得られるチップサイズ、クロックスピードおよび電力消費を用いて目標アーキテクチャを変更することができることに言及している。しかしながら、この資料は、素子の使用が決定され、そしてこの情報が、不使用のリソースを除去することによって、アーキテクチャを自動的に変更するために用いられるということは開示していない。

なお、更にヴァーレン氏等（Wahlen et al）は、論文「アプリケーションに特定したコンパイラ／アーキテクチャのコード設計」（“Application Specific Compiler/Architecture Codesign”、SIGPLAN NOTICES ACM USA, Vol.37, No.7, July 2002, 00185-193）に、アプリケーションに特定した命令セットのプロセッサ（ASIPs, application specific instruction set processors）用のアーキテクチャ探索方法で、ＣコンパイラおよびＶＨＤＬモデルをこの探索ループに含むものを記載している。あるアプリケーションに対して、目標とするアーキテクチャはスケーラブルなＡＬＩＣＥ ＶＬＩＷのインスタンスであることがこの論文に記載されている。ヴァーレン氏等の論文の図１は提唱された探索方法を概略的に示している。ＡＬＩＣＥプロセッサモデルからスタートして、コンパイラが生成される。このコンパイラを用いて、シミュレータに投入されるアプリケーションソースコードからオブジェクトコードが生成され、このシミュレータは、実行サイクルの数と全ての機能ユニット（ヴァーレン氏の論文の段落６．２参照）の起動の数とをカウンティングすることを含む実行統計的確率（execution statistics）を計算する。これらの統計的確率を用いて、設計者はプロセッサモデルを変更することができ、この変更されたプロセッサモデルに基づいて、新しいコンパイラが生成される。

類似の設計方法が以下の文献に記載されている。
− ポットラパリ氏等（Potlapally et al）の論文「埋め込みプロセッサでのＩＰＳｅｃプロトコル実行のコンフィギュラビリティと拡張性の影響」（“Impact of configurability and extensibility on IPSec Protocol Execution on Embedded Processors”, VLSI design 2006, 5th international conference on embedded systems and designとの共催、19th international conference, Hyderabad, India, 03-07 Jan 2006, pp.299-304）。
− ＵＳ出願公開公報２００３／０１７１９０７Ａ１
− ロイパース氏等（Leupers et al）の論文「埋め込みプロセッサのための目標再設定可能なコンパイラおよびアーキテクチャ探索」（IEE proceedings:computers and digital techniques, IEE, GB, Vol.152, No.2, 4 March 2005, pp.216-217）。
− ハランビ氏等（Halambi et al）の論文「ＥＸＰＲＥＳＳＩＯＮ（登録商標）：コンピュータ／シミュレータの目標再設定性によるアーキテクチャ探索のための言語」（“EXPRESSION:a language for architecture exploration through computer/simulator retargetability”, Design Automation and Test in Europe conference and exhibition 1999. Proceedings Munich, Germany 9-12, March 1999, Los Alatimos, CA, USA, IEEE Comput. Soc., US, 9 March 1999, pp.485-490）。

ポットラパリ氏等の論文は、コンフィギュラブルで拡張可能なプロセッサに基づいて設計された、アプリケーションに特定した命令セットのプロセッサを用いた埋め込みシステムにおける性能を向上するためのアプローチを記載している。この論文は最先端のコンフィギュラブルで拡張可能な埋め込みプロセッサ（テンシリカ（登録商標）社（Tensilica, Inc.）のＸｔｅｎｓａ（登録商標）)におけるＩＰＳｅｃプロトコルの性能分析を記載している。暗号化およびプロトコル処理を含め、処理レーテンシに影響する種々の要因が分析されている。命令およびデータキャッシュサイズ、プロセッサ−メモリインタフェース幅、書き込みバッファ等の構造パラメータを相乗的に構成することによる、埋め込みプロセッサのカストマイジングの影響が研究されている。

ポットラパリ氏等の論文に記載されている探索プロセスが、ポットラパリ氏等の論文の図４に概略的に示されている。ポットラパリ氏等の論文の段落ＩＩＩＢに記載されているように、彼等の方法論は３つの段階から成っている。（ｉ）データ収集段階で、実世界ＩＰＳｅｃのトレース（traces）を収集すること、（ｉｉ）このトレースを用いて、命令セットのシミュレーションによりＸｔｅｎｓａプロセッサにおけるＩＰＳｅｃの性能を分析すること、(ｉｉｉ）種々の構成パラメータを設定すること、および／またはカスタム命令を選択することによって、性能が最も上がる条件（performance hotspots）を特定し、プロセッサをチューニングすること。

米国出願公開公報ＵＳ２００３／０１７１９０７Ａ１には、アプリケーションの設計とプロセッサの設計とを効果的にマッチングする時に設計者を助けるコンフィギュラブルなプロセッサの最適化を目的とした方法および装置が記載されている。この方法および装置は、シミュレートされたハードウェアアーキテクチャを生成するための特定のプロセッサの１つ以上のアプリケーションをモデリングすることと、コンパイルされたプログラムの１つ以上のプログラムセクションのための１つ以上のリソースパラメータを決定するためのシミュレートされたハードウェアアーキテクチャのためのコンパイルされたプログラムを分析することとを含む。この方法および装置は、１つ以上のアプリケーションに特定されたプロセッサを変更するための１つ以上の提案と、コンパイルされたプログラムおよびハードウェアアーキテクチャの内１つまたは両方を最適化するリソースパラメータに対応したプログラムセクションとを提供する。

ロイパース氏等の論文には、埋め込みプロセッサのための目標再設定可能なコンパイラの最先端技術のレビューが記載されている。本質的なコンパイラの基本に基づいて、いくつかの代表的な、目標再設定可能なコンパイラシステムが説明されており、また反復的な、プロファイリングに基づいたアーキテクチャ探索における、これらのコンパイラの使用の概要が記載されている。ＬＩＳＡＴｅｋ Ｃコンパイラが詳細なケーススタディとして記載されており、将来作業の有力な領域として提案されている。ロイパース氏等の論文の図１３に示されているように、従来の設計方法論は、アプリケーションコードを何回も目標アーキテクチャに再マッピングすることが必要な反復的アプローチである。各々の反復では、通常のソフトウェア開発ツールの連鎖（Ｃコンパイラ、アセンブラ、リンカ）はこのマッピングのために用いられる。探索は、このアーキテクチャのビジュアルなプロトタイプで行われるので、命令セットシミュレータは、プロファイラと共に、与えられた（レンジの）アプリケーションに関して、例えば性能および面積への要求の観点から、現状のアーキテクチャの効率とコストを測定するのに用いられる。これに加えて、ＬＩＳＡＴｅｋの設計フローは、ゲートレベルのハードウェア指標のバックアノテーションを可能とする、ＨＤＬモデルを介した合成パスを含む。

ハランビ氏等の論文にはＥＸＰＲＥＳＳＩＯＮ（登録商標）が記載されており、これは埋め込みシステムオンチップ（ＳＯＣ）のためのアーキテクチャ設計空間を探索することと、目標再設定可能なコンパイラ／シミュレータツールキットの自動生成とをサポートする言語である。この論文の図１に概略が示されているＥＸＰＲＥＳＳＩＯＮの設計フローは、探索段階を含む。この探索段階では、システム設計者が (プロセッサライブラリから選択される) 異なる基本プロセッサの候補を探索し、評価する。ここでのゴールは速やかな設計デザイン空間探索を高速なシミュレーションでサポートすることである。探索段階に続く改良段階では、このＥＸＰＲＥＳＳＩＯＮ表現はサイクルアキュレートなシミュレータを生成することと、システム設計者が、メモリサブシステムを階層的にチューニングすると共に、この基本プロセッサの特性をチューニングすることを可能とするＩＬＰコンパイラを最適化することに用いられる。

各々のこれらの従来技術の方法では、コンパイルされたコードはシミュレートされる。このシミュレーションから得られる統計的確率のデータは、プロセッサの設計および任意で追加のコンパイラの設計に用いられる。

本発明が提供する方法は、とりわけＶＬＩＷプロセッサでの使用に適しているが、これはここでイシュースロット（issue slot）となるスロットが他のスロットから比較的に独立して動作するからである。従って、このタイプのプロセッサでは、どのイシュースロットが用いられ、どれが用いられないかを比較的簡単に決定することができる。このアプリケーションのソフトウェアで用いられない、このようなイシュースロットは容易に確認できる。これはコンパイルされたコードにおいて、これらのスロットがＮＯＰ命令だけを含んでいるからである。他の方法では、イシュースロットのレベルでリソースを除去する代わりに、更に細かく分割したレベル、例えば特定の機能ユニットで更に多くのリソースを除去してよく、および／または特定の演算を実行する能力を除去してもよい。

プログラミング可能なプロセッサでは、２つのタイプの命令符号化、データ固定符号化（data stationary encoding）と時間固定符号化（time stationary encoding）が考えられる。データ固定符号化は最も一般的なタイプであり、ここでは１個のデータ案件の全ての処理形態（フェッチ、デコード、計算、書き込み）に関連した全ての情報が、処理が行われる実際の時刻と関係なく、同一の命令に符号化される。このため、データ固定プロセッサ（data stationary processor）は、これらの処理形態を実行するのに必要な全ての内部プロセッサリソースが適切な制御情報を適切な時間タイミングで受け取るように、自分で命令情報を遅延させなければならない。プロセッサのパイプラインは、プログラムでは直接視認することができない。これは時間固定符号化では異なっている。これらのプロセッサでは、命令は、これらの命令がプロセッサが動作を実行する時のある瞬間に必要な全ての情報を含むように、符号化される。パイプラインプロセッサの場合では、これはこのプロセッサに適用されるプログラムでこのパイプラインが視認できることを意味する。２つのタイプの符号化は、それぞれの利点と不利点を持つ。データ固定符号化は、普通はより小さなコードサイズを可能とするが、命令にエンコードされた制御信号を遅延させるのに追加のハードウェアが必要となるという負担がある。時間固定符号化は、遅延ハードウェアのオーバヘッドを削減することに用いることができるが、コードサイズが大きくなるという負担がある。このため、時間固定符号化は主にアプリケーション（領域）特定のプロセッサで用いられ、このプロセッサは比較的小さなプログラムを実行する。遅延ハードウェアを必要としないということは、時間固定符号化を、高度に並列なＶＬＩＷコアにとりわけ適合したものとする。さもなければこのＶＬＩＷはコアは大量の遅延ハードウェアを必要とする。時間固定符号化では、１個の演算に関連した情報は通常異なるサイクルで発生された数個の命令に渡って分散しており、これは１個の演算に対応したＮＯＰ情報が複数の命令に分散していることを意味する。

時間固定符合化においては命令が直接機能ユニット、レジスタファイルおよびバスマルチプレクサを制御するので、プロセッサが時間固定プロセッサ（time stationary processor）の場合は、本発明が提供する方法は更に容易に実行できる。命令によって何のリソースが制御されるか決定するプロセッサモデルが得られるならば、とにかく本方法はデータ固定プロセッサにも適用可能である。

プロセッサがマイクロコード化したプロセッサである場合、本発明が提供する方法は更に容易に実行できる。マイクロコードはどのリソースが用いられ、どのリソースが用いられないか詳細に指定する。とにかく本方法は、プロセッサがどのようにして高級命令コードをプロセッサのリソースを制御するマイクロコードにデコードするか、というモデルが得られるならば、プロセッサが高級命令コードによって制御される場合にも適用可能である。

本発明が提供する方法は、プロセッサを設計する設計システムに実装することができる。

本発明の上記および他の態様を以下の図面を参照してもっと詳細に説明する。
図１はプロセッサのアーキテクチャの例を示す。 図２は本発明による方法を概略的に示す。 図３は本方法が適用されるプロセッサアーキテクチャを説明する一部分を概略的に示す。 図４はもう１つのプロセッサアーキテクチャの例を示す。 図５は本方法が適用される前記のもう１つのプロセッサアーキテクチャを説明する一部分を概略的に示す。 図６は本発明の第１の実施形態である、プロセッサを設計する設計システムを示す。 図７は本発明の第２の実施形態である、プロセッサを設計する設計システムを示す。

以下の詳細な説明では、本発明の充分な理解のために、多くの詳細な内容が記載されている。なお、しかしながら当業者はこれらの詳細な説明無しに本発明を実施できるであろう。その他、本発明の特徴を不明瞭にしないように、良く知られた方法、手順および要素については詳細には説明されていない。

例として、本発明による方法の１つの実施形態を、図１に示すようなプロセッサアーキテクチャを参照して説明する。図１に示すプロセッサは、データをレジスタファイル（ＲＦ１、．．．ＲＦｎ）にレジスタファイル書き込みポートを通して格納する。レジスタファイルは、レジスタファイルにおけるレジスタの数である、特定の容量を持つ。レジスタファイルにおけるデータはレジスタファイル読み込みポート（ｒｐ）を通して読み込まれ、イシュースロット入力ポート（is-ip）を経由して機能ユニット入力ポート（fu-ip）に供給される。この機能ユニットは、機能ユニット出力ポート（fu-op）における出力値を生成する前記データでの演算を実行し、この出力値はイシュースロット出力ポート（is-op）に転送される。ここから、バス入力ポート（bus-ip）を介して、この値は１つ以上のバスに送られる。次に、この値はバス出力ポート（bus-op）から１つ以上のレジスタファイル書き込みポート（wp）に送られる。

図示されているプロセッサは時間固定でエンコードされている。これらのプロセッサでは、命令は、プロセッサがこれらの命令の動作を実行するある瞬間に必要な全ての情報を含むようにエンコードされる。パイプラインプロセッサの場合、これはプロセッサに適用されたプログラムにおいて、パイプラインが確認できることを意味する。

上記に斜体で示す、プロセッサのリソースの各々はあるプログラムセットで用いられても用いられなくともよい。プログラムを解析すると、このようなリソースが明らかになり、プログラムで使用されるプロセッサリソースのリストが得られる。この解析は、時間固定エンコーディングされたプロセッサではとりわけ分かり易い。このリソースのリストは、プロセッサから全ての不使用のリソースを取り除くことに用いられる。これは各レジスタファイルのレジスタファイル容量を削減し、命令セットを制限し、特定のポートおよび特定のバスを取り除く。これはレジスタファイル、機能的ユニットまたはイシュースロットを完全に取り除くことさえ行う。

このように縮小されたプロセッサは、元々のプロセッサよりプログラムがもっと容易でないが、少なくともこのプロセッサが構成されたプログラムをサポートするであろう。また面積、速度、電力およびコードサイズに関して、元々のプロセッサよりもずっと効率的であろう。

改良されたコードサイズを採用するためには、プログラムは縮小されたプロセッサ用に再コンパイルされる必要がある。本発明による方法は、他にデータ固定符号化のプロセッサに適用してもよい。最も一般的なタイプである、データ固定符号化においては、１個のデータ案件の処理に関連した全ての情報が同一の命令にエンコードされる。例えば、データ固定形式で２つの値の加算をエンコードするには、命令コード‘add’、引数アドレス‘a’および‘b’、そして結果アドレス‘c’が同一の命令（すなわちc=add(a,b)）に全てエンコードされる。この仕様は、プロセッサの可能な内部パイプライン化に拘わり無く同様である。これより、データ固定プロセッサは自分自身が、全ての内部プロセッサリソースが適切な制御情報を適切な時間タイミングで、命令情報を遅延しなければならない。プロセッサのパイプラインはプログラムにおいては直接視認可能ではない。２つのタイプの符号化は、それぞれの利点と不利点を持つ。データ固定符号化は、普通はより小さなコードサイズを可能とするが、命令にエンコードされた制御情報を遅延するのに追加のハードウェアが必要となるという負担がある。

時間固定符号化は、遅延ハードウェアのオーバヘッドを削減するために用いることができるが、コードサイズが大きくなるという負担がある。このため、時間固定符号化は主にアプリケーション（領域）特定のプロセッサで用いられ、このプロセッサは、比較的小さなプログラムを実行する。遅延ハードウェアを必要としないということは、時間固定符号化を、高度に並列なＶＬＩＷコアにとりわけ適合したものとする。さもなければこのＶＬＩＷコアは大量の遅延ハードウェアを必要とする。

時間固定符号化では、１個の演算に関連した情報は通常異なるサイクルで発生された数個の命令に渡って分散しており、これは１個の演算に対応したＮＯＰ情報が複数の命令に分散していることを意味する。更に、時間固定プロセッサの命令は、しばしば演算を最小の個体としてエンコードしない。この代わりに、これらの命令は、機能ユニット、レジスタファイルおよびバスマルチプレクサなどのリソースを直接制御する、制御情報をエンコードする。この、実際のリソース制御からの‘抽象的’演算の分離は、１個のプロセッササイクルにおける、１個の演算の結果を複数のレジスタファイルに任意に書き込みできるマルチキャスティングのような技術を可能とする。この分離の結果、時間固定命令の同一のフィールド（例えばレジスタ書き込みインデクスフィールド）は、異なるクロックサイクルで、異なるイシュースロットにおいて実行される演算に対応した情報を持つことができる。

図２は、プロセッサ設計のための、本発明による方法の１つの実施形態を概略的に示す。
最初のステップで、プロセッサの初期モデルが提供され、ここで加算器、乗算器およびもっと複雑な処理素子などの処理装置、そしてメモリ、キャッシュおよびレジスタファイルなどの記憶装置、そしてバス、ネットワークおよび他の装置とのダイレクトリンクなどの相互接続装置が指定される。このモデルは通常、ＬＩＳＡまたはｎＭＬのような高級言語２の、機械読み込み可能な表現となっている。機械読み込み可能な表現とは、例えば抽象構文木（abstract syntax tree）表現の形態であり、普通は高級言語の仕様による専用のコンパイラによって自動的に（Ｓ１）生成される。米国出願公開公報ＵＳ２００５−０２４６６８０Ａ１は、このような抽象構文木表現の生成を更に詳細に記載している。

例として、図３にリソースの表を示す。これらは図１のプロセッサに示されている、レジスタファイルＲＦ１、．．．ＲＦｎ、ＢＵＳ１、．．．ＢＵＳｋおよびイシュースロットＩＳ１、．．．ＩＳｍである。この表に示されているように、いくつかのリソース、ここではイシュースロットは、機能ユニットＦＵ１、ＦＵ２．．をサブリソースとして持つ。図１および図３に示す実施形態では、第１のイシュースロットは第１の機能ユニットとして加算器を持ち、第２の機能ユニットとして乗算器を持つ。リソースの各々は、１つ以上のパラメータでパラメータ化されている。例えば、レジスタファイルは、それらのポート数、容量、幅およびレーテンシでパラメータ化され、各パラメータには値が示されている。

好ましくは、プロセッサの整合性はプロセッサモデルから検査される。このモデルで使用されたリソースはスクラッチから生成されてもよいが、好ましくは、一般的な構成ブロックとしてライブラリ３で得られる。そのような構成ブロックはリソースを一般的な方法で記述するが、これは例えばレジスタファイルに対して、容量、幅およびレーテンシが未だ決定されていないということを意味する。そのような構成ブロックのパラメータは、マシンモデル１から抽出された実際の値で埋められる。この全てのプロセスは、手書きのパラメータ化した構成ブロックによるマシン全体をモデル化することになる。

次のステップＳ２では、統計的確率４が提供され、これは選択されたアプリケーションによるリソースが使用を必要とすることを示唆する。好ましくは、これらの統計的確率は、使用されるアプリケーションの一部となるソフトウェア５のコンパイルにより提供される。コンパイラは、これが生成する実行ファイルでリソースをスケジュールしなければならないので、このような情報をステップＳ２で提供することができる。コンパイラは、どのリソースが初期プロセッサモデルでスケジュールされるかそしてどの程度スケジュールされるか、そしてどれがスケジュールされないかを決定する。コンパイラは、初期プロセッサモデル１から自動的に生成されるか、またはこの初期プロセッサモデル１を用いてテンプレートから構築されるが、他の方法として手で書いてもよい。コンパイラは、更に実行可能なコード６を提供する。コーウェア（CoWare、登録商標）社のプロセッサデザイナー（Processor Designer）は自動コンパイラ生成のための装置を提供する。自動コンパイラ生成はまた、ホーエナウアー氏等の論文「ＡＤＬプロセッサモデルによるＣコンパイラ生成に適した方法論およびツール」に記載されている（論文‘A methodology and tool suite for C compiler generation from ADL processor’, by Hoheneuer, M.;Scharwaechter, H.;Karuri, K.;Wahlen,O.;Kogel, T.;Leupers, R.;Ascheid, G.;Meyr, H.;Braun, G.;van Someren, H., Design, Automation and Test in Europe Cinference and Exhibition, 2004. Proceedings Volume 2, Issue, 16-20 Feb.2004 Page(s):1276-1281 Vol.2）。

従って、このステップ以降は、図３に示す表は、目的とするアプリケーションでどの程度実際に使用されるかを示す情報で完成される。例えば、ステップＳ２でコンパイラは、このアプリケーションが容量ＵＣＲ１のみを使用することを決定する。必要な使用を示す統計的確率を決定するために、コンパイラを用いる代わりに、これらの統計的確率は、専用のプログラムにより得られてもよい。この専用のプログラムは、単に統計的確率を提供するだけで、実行ファイルを生成しない。

次のステップＳ３は、リソースパラメータを緩和し、および／または統計的確率に基づいて初期仕様で特定されたリソースの量を制限することを含む。

統計的確率が、リソースが使用されないことを示す場合は、これらのリソースは、ステップＳ３でマシンモデルから除去される。この統計的確率がリソースの特定の量のみの使用を示す場合、例えば使用される容量ＵＣＲ１が指定の幅ＵＲ１より小さい場合は、これよりこのリソースの容量は縮小され、好ましくは、使用される容量ＵＣＲ１まで縮小される。統計的確率が、バスが指定のレーテンシＬＢ１より長い、最大のレーテンシＵＬＢ１をもつことのみを必要とすることを示す場合は、バスに対してはレーテンシへの必要条件がＬＢ１以上の値に緩和され、好ましくは、ＵＬＢ１とすることで満足される。

実行ファイルコード６の実行は、ステップＳ４でシミュレートされる。ログファイル７は結果として提供される。実行は、抽象的プロセッサモデル１に基づいて、またはＲＴＬ記述８に基づいて、またはブロックＳ４への点線の矢印で示されるように、ネットリスト９を用いてシミュレートされる。

得られたマシンモデルは、ＲＴＬ形式８、例えばＶＨＤＬまたはＶｅｒｉｌｏｇ（登録商標）に変換され（Ｓ５）、またはＲＴＬ記述８はこのマシンモデルおよび追加の情報から生成される。これに続いてＲＴＬ記述８はステップＳ６で、従来の合成ツールによってゲートレベル記述９に合成される。そのようなツールは、例えばシノプシス（Ｓｙｎｏｐｓｙｓ、登録商標）社とケーデンス（Ｃａｄｅｎｃｅ、登録商標）社から供給されている。

他のもう１つのマシンモデルを図４に示す。この場合プロセッサは、ＭＩＰＳで設計され、http://mi.eng.cam.ac.uk/~ahg/proj1_07.htmlで公開されているような、データ固定ＲＩＳＣプロセッサである。このプロセッサは従来の５段のパイプライン構造を持ち、命令フェッチ段１００、命令デコード／レジスタフェッチ段１１０、実行／アドレス計算段１２０、メモリアクセス段１３０およびライトバック段１４０を備える。各々の連続した２つの段の間には、それぞれレジスタ１０９、１１９、１２９、１３９があり、それぞれの段のパイプライン演算を可能としている。

図５の表は、初期プロセッサモデルのリソースをまとめたものである。命令フェッチ段１００は、プログラムカウンタ１０１、このプログラムカウンタによりアドレス指定される命令メモリ１０２、およびプログラムカウンタを１つづつインクレメントするための加算器１０３を備える。命令フェッチ段１００は、パイプラインレジスタ１０９を介して命令デコード／レジスタフェッチ段１１０に接続されている。命令デコード／レジスタフェッチ段１１０は、レジスタファイル１１１、符号拡張ユニット１１２、制御ユニット１１３、およびこの命令デコード／レジスタフェッチ段１１０を実行／アドレス計算段１２０に接続する、パイプラインレジスタを備える。実行／アドレス計算段１２０は、加算器１２１、左シフトユニット１２２、ＡＬＵ１２３、このＡＬＵ１２５の制御器、およびマルチプレクサ１２４と１２６を備える。この実行／アドレス計算段は、パイプラインレジスタ１２９を介してメモリアクセス段１３０に接続されている。メモリアクセス段１３０にはデータメモリ１３２およびゲート１３１が設けられている。ゲート１３１は、マルチプレクサ１０４を制御し、プログラムカウンタ値を１つづつ増加するように選択するか、または目標値にジャンプするように選択する。メモリアクセス段１３０は、パイプラインレジスタ１３９によってライトバック段１４０に接続されている。このライトバック段１４０はマルチプレクサ１４１を備える。

図１に示す初期プロセッサ構造の場合に類似して、リソースは１つ以上のパラメータで特徴付けられる。例として、それらのリソースのいくつかに対するパラメータが図５に示されている。例えば、プログラムカウンタ１０１は、カウンタのカウント範囲を示すパラメータｎ−ｐｃを持つ。このカウンタ１０１は初期（デフォールト）範囲ＮＰＣ１を持っていてもよい。このプロセッサ構造で使用されているメモリ１０２、１３２はアドレス範囲でパラメータ化される。例えば、命令メモリ１０２は、初期値がＮＩＭ１のアドレス範囲ｎ−ａｄｄｒを持ち、データメモリ１３２は、初期値がＮＤＭ１のアドレス範囲ｎ−ａｄｄｒを持つ。

他のリソースは所定の大きさを持つが、これらのリソースは、プロセッサ構造に存在するかどうかを示すパラメータを伴っていてよい。例えば、加算器１２１は、パラメータ‘ｎ−ａｄｄ’を伴う。ＮＡＤＤ１＝１（ｄｅｆａｕｌｔ）の値はこの加算器がこのプロセッサ構造に存在することを示している。ＮＡＤＤ１＝０は、この加算器が存在しないことを示している。更に、他のリソースは、それらの機能性が存在することを示す複数のパラメータを持っていてよい。例えば、ＡＬＵ１２３は、それが加算能力を持っているかどうかを示す第１のパラメータ‘ｎ−ａｄｄ’および乗算能力をもっているかどうかを示す第２のパラメータｎ−ｍｕｌをもっている。ｎ−ａｄｄのデフォールト値ＮＡＤＤ２＝１は、加算能力が存在することを示し、ｎ−ｍｕｌのデフォールト値ＮＭＵＬ１＝１は、乗算能力が存在することを示す。

このプロセッサ構造では、プログラムカウンタ１０１をインクレメントする加算器１０３のように、他のリソースは必須である。この加算器の幅は、プログラムカウンタ１０１のサイズに合わせて自動的に伸縮されてよい。代替としてこの加算器は、固定の幅を持っていてもよい。

図１を参照して説明した初期プロセッサ構造の場合に類似して、図２を参照して説明する方法が適用される。本方法のステップＳ２は、初期プロセッサ構造において説明された種々のリソースの使用を示す統計的確率４を提供した。この提供された統計的確率は、例えば、図５の表の「使用／非使用」の列に示されている。そこでは、例えば、ＵＮＰＣ１の値はカウンタ１０１の実際に使用されるカウント範囲を示す。このプロセッサ構造で使用されるメモリ１０２、１３２はあるアドレス範囲でパラメータ化される。ＵＮＩＭ１およびＵＮＤＭ２の値は、それぞれ命令メモリ１０２およびデータメモリ１３２に使用されるアドレス範囲を示す。ＵＮＡＤＤ２の値は、加算器１２１がこのアプリケーションで使用されるかどうかを示す。ＵＮＡＤＤ＝１、０はそれぞれ、この加算器が使用されるかされないかを示す。ＵＮＡＤＤ３の値は、ＡＬＵ１２３の加算能力がこのアプリケーションで使用されるかどうか（１＝ｙｅｓ、０＝ｎｏ）を示し、ＵＮＭＵＬ１は、ＡＬＵ１２３の乗算能力が使用されるかどうか（１＝ｙｅｓ、０＝ｎｏ）を示す。

図１のプロセッサ構造に類似して、統計的確率情報４が、リソースパラメータを緩和するため、および／またはこの統計的確率に基づいて、初期仕様１で指定されたリソースの量を制限するために、ステップＳ３で用いられる。プロセッサの仕様１は、このように補正され、ステップＳ５でＲＴＬ仕様に変換され、そしてステップＳ６でネットリストに合成される。

図６は、プロセッサを設計するための設計システムを示す。この設計システム１０は、プロセッサの初期モデル２０を受け取るための装置１１を備え、この初期モデルはリソースパラメータおよびそれらの相互関係に関連して、複数のリソースを指定する。この装置１１は、例えば初期モデルを格納する記憶ユニットに結合されるデータリンクである。この設計装置は、選択されたアプリケーション２２で使用が必要なリソースを示す統計的確率を提供する装置１２を更に備える。この装置１２は、例えば、図２を参照して説明されたステップＳ２を実行するプロセッサである。この設計システムは、更に、統計的確率に基づいて、少なくとも１つのパラメータを緩和するための、および／または初期仕様で指定されたリソースの量を制限するための装置１３を備える。この装置１３は、図２を用いて説明されたステップＳ３のプロセスを実行するプロセッサであってもよい。装置１３によってモジュールのライブラリを用いて得られた最終仕様からのＲＴＬ記述を生成するため、そしてゲートレベル記述２４を合成するために、装置１４が更にもうけられる。この装置１４は、ステップＳ５およびステップＳ６を実行するプロセッサであってよい。装置１２、１３および１４は、代替として１つのプロセッサに実装されてよい。これらの装置を実装するための１つ以上のプロセッサは、専用のハードウェアの形態であってよいが、他にも、適合したソフトウェアを実行する汎用プロセッサの形態であってよい。

この設計システムの全ての素子が同じ場所にある必要はない。１つの実施形態では、素子は、例えばインターネットのようなデータ接続を介して結合されてよい。この設計システムは、例えば、図７の代替実施形態に示すように、サーバＳおよびクライアントステーションＣを備えてよい。ここでは、このクライアントステーションＣは、選択されたアプリケーション２２で使用が必要なリソースを示す統計的確率を提供する装置１２と、この統計的確率に基づいて、少なくとも１つのパラメータを緩和するための、および／または初期仕様で指定されたリソースの量を制限するための装置１３とを持つ。サーバステーションは、プロセッサの初期モデルを受け取るための装置１１と、モジュールのライブラリ２５を用いて装置１３によって得られる最終仕様からのＲＴＬ記述を生成するための装置１４とを持ってよい。サーバステーションＳは、好ましくは、初期プロセッサモデル２０およびモジュールのライブラリ２５を格納し、一方ではクライアントステーションは、アプリケーション２２、および最終結果である、ＲＴＬ記述および／またはこの記述から合成されるゲートレベル記述２４、についての情報を格納する。

請求項においては、「備える（comprising）」は、他の素子またはステップを除外せず、不定冠詞“ａ”または“ａｎ”は複数を除外しない。単一のデバイス（ｅｌｅｍｅｎｔ）または他のユニットは請求項で列挙された数個の機能を充足してもよい。特定の複数の方法が、互いに異なる請求項で列挙されているということは、これらの方法の組み合わせが、有利となるように用いられないということを意味しない。請求項における参照番号は本発明の範囲を限定するために解釈されるものではない。

Claims (9)

1. プロセッサを設計する方法であって、
   リソースパラメータを用いて複数のリソースを特定する、前記プロセッサの初期モデルを提供するステップと、
   選択されたアプリケーションで使用が必要なリソースを示す統計的確率を提供するステップと、
   統計的確率に基づいて、少なくとも１つのリソースパラメータの緩和、および／または初期仕様で特定されたリソースの量の制限を行うステップとを含むことを特徴とする方法。
2. 請求項１に記載の方法において、
   前記リソースは複数の処理リソース、複数の記憶リソースおよび複数の通信リソースの少なくとも１つを備えることを特徴とする方法。
3. 請求項１に記載の方法において、
   前記プロセッサはＶＬＩＷプロセッサであることを特徴とする方法。
4. 請求項１に記載の方法において、
   前記プロセッサは時間固定プロセッサであることを特徴とする方法。
5. 請求項１に記載の方法において、
   前記プロセッサはデータ固定プロセッサであることを特徴とする方法。
6. 請求項１乃至５のいずれか１項に記載の方法において、
   前記プロセッサはマイクロコード化したプロセッサであることを特徴とする方法。
7. 請求項１に記載の方法において、
   選択されたアプリケーションで前記の使用が必要とされる前記リソースを示す前記統計的確率が、前記選択されたアプリケーションで用いられるソフトウェアをコンパイルするコンパイラによって提供されることを特徴とする方法。
8. プロセッサを設計する設計システムであって、
   前記プロセッサの初期モデル（２０）を受け取るための装置（１１）を備え、前記初期モデルはリソースパラメータおよびそれらの相互関係に関連して、複数のリソースを指定し、
   更に、選択されたアプリケーション（２２）で使用が必要な前記リソースを示す統計的確率を提供する装置（１２）と、
   更に、前記統計的確率に基づいて、少なくとも１つのパラメータを緩和するための、および／または前記初期仕様で指定されたリソースの量を制限するための装置（１３）とを備えることを特徴とする設計システム。
9. 請求項８に記載の設計システムにおいて、
   サーバステーション（Ｓ）と、クライアントステーション（Ｃ）とを備え、
   前記クライアントステーション（Ｃ）は、選択されたアプリケーション２２に前記使用が必要なリソースを示す統計的確率を提供する前記装置（１２）と、前記統計的確率に基づいて、少なくとも１つのパラメータを緩和するための、および／または前記初期仕様で指定されたリソースの量を制限するための前記装置（１３）とを有し、
   前記サーバステーション（Ｓ）は、前記プロセッサの前記初期モデルを受け取るための前記装置（１１）を有することを特徴とする設計システム。

Images