JP2007250010A - 構成可能なプロセッサを設計するための自動プロセッサ生成システム及び生成方法 - Google Patents

Abstract

【課題】構成可能なプロセッサを設計するための自動プロセッサ生成システム及び生成方法
【解決手段】構成可能なＲＩＳＣプロセッサは、高性能固定及び可変長符号化を有するユーザ定義の命令を実行する。新しい命令セットを規定する処理は、ユーザが新しい命令を付加し、敏速に評価し、複数の命令セットを保有し、容易に切換えることができるツールによってサポートされる。標準化言語は、ターゲット命令セットの構成可能な定義、命令セットを実行するのに必要なハードウェアのＨＤＬ記述、及び検証及びアプリケーション開発のための開発ツールを開発するために使用されるので、設計処理の高度の自動化を可能にする。
【選択図】 図６

Description

本発明は、マイクロプロセッサシステムに向けられ、より詳細には、本発明は、このシステムのプロセッサは、特定のアプリケーションに対するプロセッサの適性を改善するためにプロセッサの設計時点で構成され、機能強化される、１つあるいはそれ以上のプロセッサを含むアプリケーションソリューションの設計に向けられる。本発明は、アプリケーション開発者がユーザ定義のプロセッサ状態を操作し、アプリケーション実行時間およびプロセッササイクル時間までの拡張の影響を直ちに評価する新しい命令を含む、既存の命令セットアーキテクチャまでの新しい命令のような命令拡張を迅速に開発できるシステムに向けられている。

プロセッサは、従来は設計し、変更するのが困難であった。この理由で、プロセッサを含む大部分システムは、汎用使用のために一度設計され、検証され、次に時間にわたる複数のアプリケーションによって使用されたプロセッサを使用する。それ自体、特定のアプリケーションに対するプロセッサの適性は常に理想的でない。特定のアプリケーションのコードを有益に実行するためにプロセッサを変更する（例えば、より速く実行する、より少ない電力を消費する、より少ないコストを要する）ことはしばしば適切である。しかしながら、既存のプロセッサ設計を変更する困難、したがって時間、コストおよびリスクさえ高く、これは一般的には行われない。

従来のプロセッサを構成可能にする際の困難をより良く理解するために、このプロセッサの開発を考察する。先ず第一に、命令セットアーキテクチャ（ＩＳＡ）が開発される。これは、本来は１回行われ、多数のシステムによって１０年間使用された対策である。例えば、インテルペンティウム（登録商標）プロセッサは、セットされたプロセッサの命令のレガシーを１９７０年代の中頃に導入された８００８マイクロプロセッサおよび８０８０マイクロプロセッサにまで溯ることができる。この変遷において、所定のＩＳＡ設計基準に基づいて、ＩＳＡ命令、シンタックス等が開発され、アセンブラ、デバッガ、コンパイラ等のようなこのＩＳＡのためのソフトウエア開発ツールが開発されている。次に、この特定のＩＳＡのためのシミュレータが開発され、様々なベンチマークは、ＩＳＡの効率を評価するために実行され、ＩＳＡは評価の結果に従って改訂される。ある点では、ＩＳＡは申し分なく考察され、ＩＳＡ処理は、例えば、アセンブラ、デバッガ、コンパイラ等を含む十分に開発されたＩＳＡ使用、ＩＳＡシミュレータ、ＩＳＡ検証スイートおよび開発スイートで終了する。

次に、プロセッサ設計は開始する。プロセッサは多数の年数の有用な寿命を有することができ、この変遷もかなりたまに行われ、一般的には、プロセッサは１回設計され、数年間いくつかのシステムによって使用される。ＩＳＡ、ＩＳＡの検証スイートおよびシミュレータならびに様々なプロセッサ開発目標を与えられると、プロセッサのマイクロアーキテクチャが、設計され、シミュレートされ、改訂される。一旦マイクロアーキテクチャが完成されると、マイクロアーキテクチャはハードウエア記述言語（ＨＤＬ）で実行され、マイクロアーキテクチャ検証スイートが開発され、ＨＤＬインプリメンテーション（この後でより多く）を検証するために使用される。次に、この点まで記載されるマニュアル処理とは著しく違って、自動設計ツールは、ＨＤＬ記述に基づいて回路を統合し、回路の構成要素を配置し、経路選択してもよい。したがって、このレイアウトは、チップ領域使用およびタイミングを最適化するために改訂される。それとは別に、付加マニュアル処理は、ＨＤＬ記述に基づいてフロアプランを形成し、ＨＤＬを回路に変換し、それから回路を手動および自動の両方で検証し、レイアウトしてもよい。最後に、このレイアウトは、自動ツールを使用してこの回路に一致することが確実であることを検証され、この回路はレイアウトパラメータに従って検証される。

プロセッサ開発が完了した後、全システムは設計される。ＩＳＡおよびプロセッサの設計とは違って、システム設計（現在プロセッサを含むチップの設計を含んでもよい）は、全く一般的であり、システムは一般的には連続して設計される。各システムは、特定のアプリケーションによって比較的短い時間（１年あるいは２年）使用される。コスト、性能、電力および機能性のような所定のシステム目的、予め存在しているプロセッサの仕様、チップファンドリ（通常プロセッサベンダーと密接に結合されている）の仕様に基づいて、全システムアーキテクチャは設計され、プロセッサは設計目的に合わせるように選択され、チップファンドリは、選択される（これはプロセッサ選択に密接に結合される）。

次に、選択プロセッサ、ＩＳＡおよびファンドリならびにシミュレーション、検証および予め開発された開発ツール（ならびに選択されたファンドリのための標準セルライブラリ）が与えられると、システムのＨＤＬインプリメンテーションは設計され、検証スイートは、システムＨＤＬインプリメンテーションために開発され、このインプリメンテーションが検証される。次に、システム開発は統合され、回路板上に配置され、経路選択され、レイアウトおよびタイミングは再最適化される。最後に、この回路板は設計され、レイアウトされ、このチップは製造され、この回路板は組み立てられる。

任意の所与のアプリケーションだけが特定の機能のセットを必要とし、アプリケーションによって必要とされない機能を有するプロセッサは、非常に高価で、より多くの電力を消費し、製造することはより困難であるために、従来のプロセッサ設計に関する他の困難は、全アプリケーションをカバーするためにより多くの機能を有する従来のプロセッサを単に設計することは適切でないという事実から生じる。さらに、プロセッサが最初に設計される場合、アプリケーションの目標の全てを知ることはできない。プロセッサ変更処理が自動化され、信頼性があるようにすることができる場合、アプリケーションソリューションを形成するシステム設計者の能力は著しく高められる。

一例として、複雑なプロトコルを使用してチャネルを介してデータを送受信するように設計される装置を考察する。プロトコルは複雑であるために、処理は、完全にハードワイヤドで、例えば、組合せ、ロジックで適度に行うことができなく、その代わりにプログラマブルプロセッサはプロトコル処理のためにシステムに導入される。プログラム可能性は、バグ固定も可能にし、後で命令メモリを新しいソフトウエアでロードすることによって行われるプロトコルまでアップグレードする。しかしながら、従来のプロセッサは、おそらくこの特定のアプリケーションのために設計されなかった（アプリケーションは、プロセッサが設計された場合、存在さえしなくてもよい）、実行する必要があり、付加プロセッサロジックに対する１つあるいはわずかな命令で行うことができる、実行するのに多数の命令を必要とする操作があり得る。

プロセッサは容易に機能強化できないために、多数のシステム設計者は、このように機能強化をしようと試みなくて、その代わりに、使用可能な汎用プロセッサで役に立たない純ソフトウエアソリューションを実行することを選択する。非能率は、より遅くてもよいし、あるいはより多くの電力を必要としてもよいし、あるいはより高価であってもよいソリューションを生じる（例えば、このソリューションは、十分な速度でプログラムを実行するためにより大きく、より強力なプロセッサを必要とし得る）。他の設計者は、コプロセッサのようなアプリケーションのために設計する専用ハードウエアの処理要求のいくつかを提供するように選択し、次にプログラムの様々な点で専用ハードウエアに対するプログラマコードアップアクセスを有する。しかしながら、かなり大きな作業ユニットだけが十分スピードアップできるので、専用ハードウエアを使用することによって保存される時間は、データを専用ハードウエアへおよび専用ハードウエアから転送するのに必要とされる付加時間よりも大きいために、プロセッサとこのような専用ハードウエアとの間でデータを転送する時間はシステムに対するこの方式のユーティリティを制限する。

通信チャネルアプリケーション例では、プロトコルは、暗号化、エラー訂正、あるいは圧縮／伸長を必要としてもよい。この処理は、しばしばプロセッサのより大きいワードよりもむしろ個別のビットで作動する。計算のための回路は、むしろ普通であってもよいが、各ビットを抽出するプロセッサに対する要求は、逐次各ビットを処理し、次にビット加算のかなりのオーバーヘッドを再パックする。非常に特有な例として、表１に示された規則を使用するハフマン復号化を考察する（同様な符号化はＭＰＥＧ圧縮規格で使用される）。値および長さの両方が計算されねばならないので、長さのビットは、ストリームで復号化される次の要素の始めを探すためにシフトオフできる。

従来の命令セットのためのこれを符号化する多数の方法があるが、この方法の全ては、行われる多数のテストがあるために、多数の命令を要し、組合せロジックのための単一のゲート遅延とは著しく違って、各ソフトウエアインプリメンテーションは複数のプロセッササイクルを要する。例えば、ＭＩＰＳ命令セットを使用する有効な従来のインプリメンテーションは、６つの論理演算、６つの条件付分岐、算術演算、および関連レジスタロードを必要とし得る。有利に設計された命令セットを使用して、符号化は、いっそうよいが、時間すなわち１つの論理演算、６つの条件付分岐、算術演算および関連レジスタロードに関して高価である。

プロセッサ資源に関して、これは非常に高価であるので、２５６エントリルックアップテーブルは、一般的には一連のビット毎の比較として処理を符号化する代わりに使用される。しかしながら、２５６エントリルックアップテーブルは、著しいペースをとり、アクセスするのにはまた数サイクルであり得る。より長いハフマン符号化の場合、テーブルサイズは法外になり、より複雑で、遅いコードをもたらす。

プロセッサの特有のアプリケーション要求を受け入れる問題の可能な解決策は、命令セットおよびプロセッサの機能性を高め、この機能性をカストマイズするために容易に変更し、拡張できるアーキテクチャを有する構成可能なプロセッサを使用することにある。最も簡単な種類の構成可能性は２進選択である。すなわち、機能が有るか無しかのいずれかである。例えば、プロセッサは浮動小数点ハードウエアを有しているか有していないかのいずれかで提供されてもよい。

汎用性は、より細かい等級づけを有する構成選択によって改良されてもよい。例えば、このプロセッサによって、システム設計者は、レジスタファイルのレジスタ数、メモリ幅、キャッシュサイズ、キャッシュ関連性等を指定できる。しかしながら、これらのオプションは、システム設計者によってカスタム化可能性のレベルになお達しない。例えば、上記のハフマン符号化例において、従来技術において公知でないけれども、システム設計者は、特有の命令を含み、例えば、ｈｕｆｆ８ｔ１，ｔ０を復号化を実行することを好んでもよい。

ここで、この結果の最上位の８ビットは復号化値であり、最下位の８ビットは長さである。前述されたソフトウエアインプリメンテーションとは著しく違って、ハフマン復号化の直接ハードウエアインプリメンテーションは全く簡単であり、命令を復号化するロジックは、命令復号化をまさに相容れない組合せロジック機能等に対して約３０のゲート、あるいは典型的なプロセッサのゲート総数の０．１％未満を示し、専用プロセッサ命令によって単一サイクルで計算できるので、汎用命令だけを使用することに関して４〜２０の改善率を示す。

構成可能なプロセッサ生成の従来の試みは、一般に２つのカテゴリーに属する。すなわち、パラメータ化ハードウエア記述と併用されたロジック統合および抽象マシン記述からのコンパイラおよびアセンブラの自動再ターゲットである。第１のカテゴリーには、ＳｙｎｏｐｓｙｓＤＷ８０５１プロセッサ、ＡＲＭ／ＳｙｎｏｐｓｙｓＡＲＭ７−Ｓ、ＬｅｘｒａＬＸ−４０８０、ＡＲＣ構成可能ＲＩＳＣコアおよびある程度までＳｙｎｏｐｓｙｓ統合可能／構成可能なＰＣＩバスインタフェースのような統合可能なプロセッサハードウエア設計が属する。

上記の中で、ＳｙｎｏｐｓｙｓＤＷ８０５１は、既存のプロセッサアーキテクチャの２進コンパチブルインプリメンテーション、少数の統合パラメータ、例えば、１２８あるいは２５６バイトの内部ＲＡＭ、パラメータｒｏｍ ａｄｄｒ ｓｉｚｅによって決定されたＲＯＭアドレス範囲、オプショナル内部タイマ、可変数（０〜２）の直列ポート、および６個あるいは１３個のソースのいずれかをサポートする割り込み装置を含んでいる。ＤＷ８０５１アーキテクチャは幾分変更できるけれども、ＤＷ８０５１の命令セットアーキテクチャの変更は全然できない。

ＡＲＭ／ＳｙｎｏｐｓｙｓＡＲＭ７−Ｓプロセッサは、既存のアーキテクチャおよびマイクロアーキテクチャの２進コンパチブルインプリメンテーションを含む。このプロセッサは、２つの構成可能なパラメータ、すなわち、高性能あるいは低性能の乗算器およびデバッグおよび回路内エミュレーションロジックの包含を有する。ＡＲＭ７−Ｓの命令セットアーキテクチャの変更は可能であるけれども、この変更は、既存の非構成可能なプロセッサインプリメンテーションのサブセットであるので、新しいソフトウエアは全然必要とされない。

ＬｅｘｒａＬＸ−４０８０プロセッサは、標準ＭＩＰＳアーキテクチャの構成可能な変形を有し、命令セット拡張に対してソフトウエアサポートを全然有しない。このプロセッサのオプションは、特定用途用演算に対してＭＩＰＳ ＡＬＵ操作符号の拡張を可能にするカスタムエンジンインタフェースと、レジスタソースおよびレジスタあるいは１６ビット幅即値ソースならびにディスティネーション信号およびをストール信号含む内部ハードウエアインタフェースと、簡単なメモリ管理装置オプションと、３ＭＩＰＳコプロセッサインタフェースと、キャッシュ、スクラッチパッドＲＡＭあるいはＲＯＭへのフレキシブルローカルメモリインタフェースと、周辺機能およびメモリをプロセッサ専用のローカルバスを接続するバスコントローラと、構成可能な深さの書き込みバッファとを含んでいる。

ＡＲＣ構成可能なＲＩＳＣコアは、ターゲット技術およびクロック速度に基づいたオンザフライゲート総数概算、命令キャッシュ構成、命令セット拡張、タイマオプション、スクラッチパッドメモリオプション、およびメモリコントローラオプションに対するユーザインタフェースと、メモリへのブロック移動を有するローカルスクラッチパッドＲＡＭ、専用レジスタ、最高１６の余分の条件付コード選択、３２×３２ビットスコアボード乗算ブロック、単一サイクル３２ビットバレルシフタ／ローテトブロック、正規化（第１のビットを探す）命令、結果の（レジスタファイルでなく）コマンドバッファへの直接書き込み、１６ビットＭＵＬ／ＭＡＣブロックおよび３６ビットアキュムレータ、および線形算術を使用するローカルＳＲＡＭへのスライドポインタアクセスのような選択可能なオプションを命令セットと、ＶＨＤＬソースコードの手動編集によって規定されたユーザ命令とを有する。ＡＲＣ設計は、命令セット記述言語を実行する機能を全然有しもしないしまた構成プロセッサに特有のソフトウエアツールも生成しない。

Ｓｙｎｏｐｓｙｓ構成可能なＰＣＩインタフェースは、設置、構成および統合の活動のためのＧＵＩあるいはコマンドラインインタフェースと、前以て必要なユーザ活動が各ステップで行われることの検査と、構成に基づいた選択設計ファイル（Ｖｅｒｉｌｏｇ対ＶＨＤＬ）の設置と、組合せ有効性の検査に対する構成値のためのユーザのパラメータ設定およびプロンプトおよびＨＤＬソースコードのユーザ更新およびＨＤＬソースファイルの無編集に対するＨＤＬ生成のような選択構成と、Ｉ／Ｏパッド、技術に左右されない制約および統合スクリプト、パッド挿入を選択するために技術ライブラリを解析し、技術専用パッドおよび技術に左右されない式の技術に依存するスクリプトへの変換のためにプロンプトするユーザインタフェースのような統合機能とを含んでいる。構成可能なＰＣＩバスインタフェースは、パラメータの一貫性の検査、構成に基づいた設置、ＨＤＬファイルの自動変更を実行するために重要である。

さらに、従来の統合技術は、ユーザ目的仕様に基づいて異なるマッピングを選択し、マッピングが速度、電力、領域、目標構成要素に対して最適化することができる。この点で、従来技術では、全マッピング処理によってこの設計を行わないで、プロセッサをこれらの方法で再構成する効果のフィードバックを得ることができない。このようなフィードバックは、システム設計目的が達成されるまで、プロセッサの更なる再構成を行うために使用できる。

構成可能なプロセッサ生成の分野の従来技術の研究の第２のカテゴリー、すなわちコンパイラおよびアセンブラの自動目標は、大学の研究の恵まれている分野を包含する。例えば、Ｈａｎｏｎｏらの「ＡＶＩＶ再目標可能なコード生成器の命令選択、資源割当ておよびスケジューリング」（コード生成器の自動作成のために使用される機械命令の表示）；Ｆａｕｔｈらの「ｎＭＬを使用する命令セットプロセッサを述べる」；Ｒａｍｓｅｙらの「埋め込まれたシステムのためのツールを形成するマシン記述」；Ａｈｏらの「ツリーマッチングおよびダイナミックプログラミングを使用するコード生成」（各機械命令に関連した変換を組合わせるアルゴリズム、例えば、加算、ロード、ストア、ブランチ等、一連のプログラム操作は、パターンマッチングのような方法を使用するある機械に左右されない中間形式によって示される；およびＣａｔｔｅｌｌの「コード生成器の形式化および自動導出」（コンパイラ研究のために使用されるマシンアーキテクチャの抽象記述）を参照せよ。

一旦プロセッサが設計されたとすると、プロセッサの作動が検証されねばならない。すなわち、プロセッサは、通常、命令実行の１つのフェーズに適する各段を有するパイプラインを使用して記憶プログラムから命令を実行する。したがって、命令を変えるかあるいは加算するかもしくは構成を変えることはプロセッサロジックの広範囲に及ぶ変化を必要とし得るので、複数のパイプライン段は各々のこのような命令の適切な動作を実行できる。プロセッサの構成は、プロセッサが再検証されるべきであり、この検証が変更および加算に適応することを要求する。これは簡単な仕事ではない。プロセッサは、広範囲にわたる内部および制御状態を有する複雑なロジック装置であり、制御およびデータならびにプログラムの連結解析は検証を要求の厳しい技術にする。プロセッサ検証の困難に付け加えることは適切な検証ツールを開発する際の困難である。検証は従来技術で自動化されないので、検証の汎用性、速度および信頼性はあまり最適でない。

さらに、一旦プロセッサが設計され、検証されると、プロセッサが容易にプログラム化できない場合、プロセッサは特に役に立たない。プロセッサは、通常、コンパイラ、アセンブラ、リンカ、デバッガ、シミュレータおよびプロフィーラを含む広範囲に及ぶソフトウエアツールを使ってプログラム化される。プロセッサが変わる場合、ソフトウエアツールもまた変更されねばならない。この命令がコンパイルし、アセンブルし、シミュレートあるいはデバッグすることができない場合、命令を付加することは全然役に立たない。プロセッサ修正および機能強化に関連するソフトウエア変更のコストは従来技術の汎用プロセッサ設計の主要な障害であった。

したがって、従来のプロセッサ設計は、プロセッサが通常特定用途のために一般的には設計あるいは変更されない困難のレベルのものであることが分かる。さらに、プロセッサが特定用途のために構成あるいは拡張できる場合、システム効率のかなりの改善は可能であることが分かる。さらに、万一プロセッサ設計を改良する際に電力消費、速度等のようなインプリメンテーション特性のフィードバックを使用できる場合、設計処理の効率および有効性を高めることができる。さらに、従来技術では、一旦プロセッサが変更されると、多くの努力が変更後プロセッサの正確な動作を検証するために必要である。最後に、従来技術は限られたプロセッサ構成可能性のために提供しているけれども、この技術は、構成プロセッサと併用するために合わせられたソフトウエア開発ツールの生成のために提供できない。

上記の基準に合うシステムは確かに従来技術に対する改善であるが、改善を行うことができ、例えば、特殊レジスタに記憶された情報、すなわち得ることができる命令の範囲を著しく制限するプロセッサ状態をアクセスあるいは変更、したがって達成可能な性能改善量を制限する命令を有するプロセッサシステムに対する要求がある。

さらに、新しい特定用途用命令を発明することは、サイクル総数削減、付加ハードウエア資源およびＣＰＵサイクル時間影響間の複雑なトレードオフを必要とする。他の挑戦は、高性能マイクロプロセッサインプリメンテーションのしばしば扱いにくい詳細にアプリケーション開発者を従事させないで新しい命令に対する有効なハードウエアインプリメンテーションを得ることにある。

上記のシステムは、ユーザのアプリケーションに最適なプロセッサを設計する融通性をユーザに与える。この問題をより十分に理解するために、多数のソフトウエア設計者のソフトウエアプリケーションの性能に合わせるように多数のソフトウエア設計者によって使用された典型的な方式を考察する。多数のソフトウエア設計者は、一般的には、可能性のある改善のことを考え、この可能性のある改善を用いるためにこの設計者のソフトウエアを変更し、この設計者のソフトウエアソースを再コンパイルし、この可能性のある改善を含む実行可能なアプリケーションを生成し、次にこの可能性のある改善を評価する。この評価の結果に応じて、多数のソフトウエア設計者はこの可能性ある改善を保持あるいは捨ててもよい。一般的には、全処理は２、３分だけで完了できる。これによって、ユーザは、自由に実験し、アイディアを迅速に試用し、保持あるいは捨てることができる。いくつかの場合、可能性のあるアイディアを厳密に評価することは複雑である。ユーザは、非常に多様な状況でアイディアを試したいかもしれない。このような場合、ユーザは、コンパイルされたアプリケーションの多数のバージョン、すなわち一方の元のバージョンおよび可能性のある改善を含む他方のバージョンを所有する。いくつかの場合、可能性のある改善は互いに影響し合うかもしれなく、ユーザはアプリケーションの２つ以上のコピーを所有してもよく、各々のコピーは異なるサブセットの可能性のある改善を使用する。多数のバージョンを保持することによって、ユーザは異なる環境の下で異なるバージョンを繰り返して容易にテストできる。

構成可能なプロセッサは、ソフトウエア開発者が従来のプロセッサのソフトウエアを解決する方法と同様にハードウエアおよびソフトウエアを共同で対話して開発することを望む。カスタム命令を構成可能なプロセッサに付加するユーザの場合を考察する。ユーザは、対話して可能性のある命令を自分のプロセッサに加え、自分の特定のアプリケーションでこれらの命令をテストし、評価することを望む。従来のシステムの場合、これは３つの理由のために困難である。

先ず第一に、可能性のある命令を提案した後、ユーザは、命令を利用できるコンパイラおよびシミュレータを得る前に一時間あるいはそれ以上待たなければならない。

第二に、ユーザが多数の可能性のある命令で実験したい場合、ユーザは、各々の命令に対してソフトウエア開発システムを形成し、保持しなければならない。ソフトウエア開発システムは非常に大きくてもよい。多数のバージョンを保持することは管理できなくなり得る。

最後に、ソフトウエア開発システムは全プロセッサのために構成される。これは、異なる技術者の中で開発処理を分離することを困難にする。２人の開発者が特定のアプリケーションで作業する例を考察する。一方の開発者は、プロセッサのキャッシュ特性を決定する責任を負うべきであり、他方の開発者はカストマイズされた命令を付加する責任を負うべきであり得る。２人の開発者の作業は関連しているが、各作業は十分分離可能であるので、各開発者は隔離して自分の仕事を作業できる。キャッシュ開発者は特定の構成を最初に提案し得る。他方の開発者は、この構成で開始し、いくつかの命令を試用し、各可能性のある命令に対するソフトウエア開発システムを形成する。次に、キャッシュ開発者は提案されたキャッシュ構成を変更する。開発者の構成の各々は最初のキャッシュ構成をとるので、他方の開発者は開発者の構成の中のあらゆる構成を再形成しなければならない。プロジェクトで作業する多数の開発者に関して、異なる構成を編成することは直ぐに管理できないことになり得る。

本発明は、従来技術のこれらの問題を解決し、プロセッサのハードウエアインプリメンテーションの記述および同じ構成仕様からプロセッサをプログラミングするソフトウエア開発ツールのセットの両方を生成することによってプロセッサを自動的に構成できるシステムを提供する目的を有する。

本発明の他の目的は、ハードウエアインプリメンテーションおよび様々な性能基準のためのソフトウエアツールを最適化できるこのようなシステムを提供することにある。

本発明のもう一つの目的は、伸長性、２進選択およびパラメータ変更を含む、プロセッサのための様々な種類の構成可能性を可能にするこのようなシステムを提供することにある。

本発明のもう一つの目的は、ハードウエアで容易に実行できる言語でプロセッサの命令セットアーキテクチャを示すことができるこのようなシステムを提供することにある。

本発明の他の目的は、プロセッサ状態を変更する命令セット拡張を開発し、実行するシステムおよび方法を提供することにある。

本発明の他の目的は、プロセッサレジスタを変更する命令セット拡張を開発し、実行するシステムおよび方法を提供することにある。

本発明のもう一つの目的は、ユーザが新しい命令をこの特性を評価できる数分内に付加することによってプロセッサ構成をカストマイズすることができることにある。

上記の目的は、カストマイズされたプロセッサ命令セットオプションおよび標準化言語の拡張の記述を使用し、ターゲット命令セットの構成定義、命令セットを実行するのに必要な回路のハードウエア記述言語記述、およびプロセッサのためのソフトウエアを生成し、プロセッサを検証するために使用できるコンパイラ、アセンブラ、デバッガおよびシミュレータのような開発ツールを開発する自動プロセッサ生成システムを提供することによって達成される。プロセッサ回路のインプリメンテーションは、領域、電力消費および速度のような様々な基準に対して最適化できる。一旦プロセッサ構成が開発されると、プロセッサ構成は、試験でき、プロセッサインプリメンテーションを繰り返して最適化するように変更されるシステムに対して入力する。

本発明による自動プロセッサ生成システムを開発するために、命令セットアーキテクチャ記述言語が定義され、アセンブラ、リンカ、コンパイラおよびデバッガのような構成可能なプロセッサ／システム構成ツールおよび開発ツールが開発される。このことは、大部分のツールは標準であるけれども、ＩＳＡ記述から自動的に構成されるようにされなければならないために開発処理の一部である。この設計処理の一部は、一般的には自動プロセッサ設計ツールそのものの設計者あるいは製造者によって行われる。

本発明による自動プロセッサ生成システムは下記のように作動する。ユーザ、例えばシステム設計者は構成命令セットアーキテクチャを開発する。すなわち、ＩＳＡ定義および予め開発されたツールを使用して、所定のＩＳＡ設計目的に従う構成可能な命令セットアーキテクチャが開発される。次に、開発ツールおよびシミュレータはこの命令セットアーキテクチャのために構成される。構成されるシミュレータを使用して、ベンチマークは、構成可能な命令セットアーキテクチャの効率を評価するために実行され、この中心部は評価結果に基づいて改訂される。一旦、構成可能な命令セットアーキテクチャは満足な状態であると、検証スイートはそのために開発される。

この処理のこれらのソフトウエア態様とともに、このシステムは、構成可能なプロセッサを開発することによってハードウエア態様に付随する。したがって、コスト、性能、電力および機能性のようなシステム目的および使用可能なプロセッサ製作の情報を使用して、このシステムは、構成可能なＩＳＡオプション、拡張およびプロセッサ機能選択を考慮する全システムアーキテクチャを設計する。全システムアーキテクチャ、開発ソフトウエア、シミュレータ、構成可能な命令セットアーキテクチャおよびプロセッサＨＤＬインプリメンテーションを使用して、プロセッサＩＳＡ、ＨＤＬインプリメンテーション、ソフトウエアおよびシミュレータは、システムによって構成され、システムＨＤＬはシステムオンアチップ設計のために設計される。さらに、システムアーキテクチャおよびチップファンドリーの仕様に基づいて、チップファンドリーは、システムＨＤＬ（従来技術のようにプロセッサ選択に関連しない）に関するファンドリー機能の評価に基づいて選択される。最後に、ファンドリーの標準電池ライブラリを使用して、構成システムは、回路を統合し、この回路を配置し、経路選択し、レイアウトおよびタイミングを再最適化する能力を与える。したがって、この設計が単一チップ型のものでない場合、回路板レイアウトは設計され、チップが製造され、回路板が組み立てられる。

上記で分かるように、いくつかの技術がプロセッサ設計処理の広範囲に及ぶ自動化を容易にするために使用される。これらの問題を取り組むために使用される第１の技術は、任意の変更あるいは拡張ほど柔軟でなく、それにもかかわらず著しい機能性改善を可能にする特定の機構を設計し、実現することにある。変更の任意性を抑制することによって、それに関連した問題が抑制される。

第２の技術は、変更のただ一つの記述を行い、全ての影響を及ぼされた構成要素の変更および拡張を自動的に生成することにある。手動で１回何かを行うことは、ツールを記述し、このツールを自動的に行い、このツールを１回使用することよりもしばしば安価であるために、従来技術で設計されたプロセッサはこれを行わなかった。タスクが数回繰り返される場合、自動化の長所を用いる。

使用される第３の技術は、その後のユーザ評価のための推定および自動構成を補助するためにデータベースを形成することにある。

最後に、第４の技術は、構成に役に立つ形式でハードウエアおよびソフトウエアを提供することにある。本発明の実施例では、ハードウエアおよびソフトウエアのいくつかは標準ハードウエアおよびソフトウエア言語で直接記述されないで、構成データベースの照会および置換、条件付、複製および他の修正を有する標準ハードウエアおよびソフトウエア言語コードの生成を可能にするプリプロセッサの付加によって強化された言語で記述される。したがってコアプロセッサ設計は、強化がリンクインできるフックで行われる。

これらの技術を示すために、特定用途用命令の付加を考察する。この方法をレジスタおよび一定のオペランドを有し、レジスタ結果を生じる命令に抑制することによって、命令の操作は組合せ（無状態、自由フィードバック）ロジックだけで指定できる。この入力は、操作符号割当、命令名、アセンブラシンタックスおよび命令のための組合せロジックを指定する。この命令からツールは、・ プロセッサが新しい操作符号を認識する命令復号化ロジック；
・ レジスタオペランドで組合せロジック機能を実行する機能ユニットの付加；
・ そのオペランドが有効である場合だけ命令発行を確認するプロセッサの命令スケジューリングロジックの入力；
・ 新しい操作符号およびそのオペランドを受け取り、正しいマシンコードを生成するアセンブラ変更；
・ 新しい命令をアクセスする新しい固有の機能を付加するコンパイラ変更；
・ マシンコードを新しい命令として受け取り、指定ロジック機能を実行するシミュレータ変更；および・ 付加命令の結果を含み、この結果を検査する直接コードシーケンスおよびランダムコードシーケンスの両方を生成する診断生成器を生成する。

上記の技術の全ては特定用途用命令を付加するために使用される。入力は、入力オペランドおよび出力オペランドおよびこれらのオペランドを評価するロジックに抑制される。この変更は１つの場所に記述され、全ハードウエア変更およびソフトウエア変更はこの記述から得られる。この機能は、いかに単一入力が複数の構成要素を高めるために使用できることを示している。

プロセッサとシステムロジックの他の部分との間のトレードオフは設計処理で非常に遅れて行うことができるために、この処理の結果は、システムのアプリケーション要求をかなえることで従来の技術よりも非常に優れたシステムである。このシステムは、システムの構成は多数のより多くの表示形式に適用されてもよい点で前述の従来の方式の多くより優れている。単一ソースは、全ＩＳＡ符号化ために使用されてもよく、ソフトウエアツールおよび高レベルシミュレーションは構成可能パッケージに含められてもよく、流れは、構成値の最適結合を探すために反復のために設計されてもよい。さらに、前述の方法は、制御のための単一ユーザインタフェースあるいはユーザ向けの再定義のための測定システムなしだけでハードウエア構成あるいはソフトウエア構成だけに焦点を合わせていたが、本発明は、プロセッサハードウエアおよびソフトウエアの構成のための流れを完成することに寄与し、最適構成の選択を助けるハードウエア設計結果およびソフトウエア性能からフィードバックを含む。

これらの目的は、カストマイズされたプロセッサ命令セット拡張の記述を標準化言語で使用し、ターゲット命令セットの構成可能な定義、命令セットを実行するのに必要な回路のハードウエア記述言語、およびプロセッサのためのアプリケーションを開発し、検証するために使用できるコンパイラ、アセンブラ、デバッガおよびシミュレータのような開発ツールを開発する自動プロセッサ設計を提供することによって本発明の態様により達成される。標準化言語は、プロセッサ状態を変更するかあるいは構成可能なプロセッサを使用する命令セット拡張を処理できる。拡張および最適化の抑制領域を与えることによって、処理は高度まで自動化でき、それによって高速で、信頼性のある開発を容易にする。

上記の目的は、さらにユーザが複数の可能性のある命令のセットあるいは状態（以下、可能性のある構成可能な命令あるいは状態の組合せは、ひとまとめにして「プロセッサエンハンスメント」と呼ばれる）を保持し、プロセッサエンハンスメントのアプリケーションを評価できる場合、プロセッサエンハンスメント間で容易に切り換えることができるシステムを提供する本発明の他の態様により達成される。

ユーザは、ここに示された方法を使用してベースプロセッサ構成を選択し、形成する。ユーザは、新しいセットのユーザ定義のプロセッサエンハンスメントを形成し、このプロセッサエンハンスメントをファイルディレクトリに入れる。次に、ユーザは、ユーザエンハンスメントを処理し、ベースソフトウエア開発ツールによって使用可能な形式に変換するツールを呼び出す。この変換は、ユーザ定義のエンハンスメントだけを含み、全ソフトウエアシステムを形成しないので、非常に速い。次にユーザは、ベースソフトウエア開発ツールを呼び出し、新しいディレクトリで形成されたプロセッサエンハンスメントを動的に使用することをツールに知らせる。好ましくは、ディレクトリの位置は、コマンドラインオプションあるいは環境のいずれかによってツールに与えられる。処理をさらに簡単にするために、ユーザは標準ソフトウエアメークファイルを使用できる。これらによって、ユーザは、そのプロセッサ命令を変更し、次に単一のメークコマンドによってエンハンスメントを処理し、新しいプロセッサエンハンスメントに関してそのアプリケーションを再形成し、評価するためにベースソフトウエア開発システムを使用できる。

本発明は、従来の方式の３つの制限を克服する。新しいセットの可能性のあるエンハンスメントを与えると、ユーザは瞬間の問題で新しいエンハンスメントを評価できる。ユーザは、各セットに対する新しいディレクトリを形成することによって可能性のあるエンハンスメントの多数のバージョンを保持できる。ディレクトリは新しいエンハンスメントの記述を含むだけで全ソフトウエアシステムを含まないので、必要とされる記憶空間は最少である。最後に、新しいエンハンスメントは構成の他の部分から切り離される。一旦ユーザが可能性のあるセットの新しいエンハンスメントを有するディレクトリで作成したとすると、ユーザは、このディレクトリを任意のベース構成と併用できる。

一般に、自動プロセッサ生成処理は、構成可能なプロセッサ定義およびそれのユーザ指定変更、ならびにプロセッサが構成されるべきユーザ指定アプリケーションで始まる。この情報は、ユーザ変更を考慮する構成済プロセッサを生成し、ソフトウエア開発ツール、例えば、このツールのためのコンパイラ、シミュレータ、アセンブラ、逆アセンブラ等を生成するために使用される。さらに、このアプリケーションは、新しいソフトウエア開発ツールを使用して再コンパイルされる。再コンパイル済アプリケーションは、アプリケーションを実行する構成済プロセッサの性能を記述するソフトウエアプロフィールを生成するためにシミュレータを使用してシミュレートされ、構成済プロセッサは、プロセッサ回路インプリメンテーションを特徴とするハードウエアプロフィールを生成するためにシリコンチップエリア使用、電力消費、速度等に対して評価される。ソフトウエアおよびハードウエアプロフィールはフィードバックされ、プロセッサがこの特定のアプリケーションのために最適化できるように他の反復構成を可能にするようにユーザに供給される。

本発明の好ましい実施例による自動プロセッサ生成システム１０は、図１に示されるように４つの主要構成要素を有する。すなわち、４つの主要構成要素は、プロセッサを設計することを望むユーザがユーザの構成可能性および伸長性オプションおよび他の設計抑制を入力するユーザ構成インタフェース２０と、ユーザによって選択された基準のために設計されたプロセッサのためにカストマイズすることができる一連のソフトウエア開発ツール３０と、プロセッサ４０のハードウエアインプリメンテーションのパラメータ化伸長記述と、および入力データをユーザインタフェースから受信し、要求されたプロセッサのカストマイズされた統合可能なハードウエア記述を生成し、ソフトウエア開発ツールを変更し、選択された設計を受け入れる形成システム５０である。好ましくは、形成システム５０は、さらに診断ツールを生成し、ハードウエアおよびソフトウエア設計および推定器を検証し、ハードウエアおよびソフトウエア特性を推定する。

ここで使用され、かつ添付された特許請求の範囲に使用されるような「ハードウエアインプリメンテーション記述」は、プロセッサ設計の物理的インプリメンテーションの態様を記述し、１つあるいはそれ以上の他の記述だけあるいはこの記述とともにこの設計に従ってチップの製造を容易にする１つあるいはそれ以上の記述を意味する。したがって、ハードウエアインプリメンテーション記述の構成要素は、記述をマスクするネットリストおよびマイクロコーティングによるハードウエア記述言語のような比較的高レベルから変化する抽象概念のレベルにあってもよい。しかしながら、本実施例では、ハードウエアインプリメンテーション記述の主構成要素は、ＨＤＬ、ネットリストおよびスクリプトで記述される。

さらに、ここで使用され、添付された特許請求の範囲で使用されるようなＨＤＬは、マイクロアーキテクチャ等を記述するために使用される一般クラスのハードウエア記述言語を示すことを意図し、このＨＤＬはこのような言語の任意の特定の例を示すことを示すことを意図する。

この実施例では、プロセッサ構成のための基本は図２に示されたアーキテクチャ６０である。多数のアーキテクチャの要素は、ユーザによって直接変更できない基本機能である。これらは、プロセッサ制御部６２と、整列・復号化部６４（ただし、この部分の一部はユーザ指定構成に基づいている）と、ＡＬＵ・アドレス生成部６６と、ブランチロジック・命令フェッチ６８と、プロセッサインタフェース７０とを含む。他の装置は、基本プロセッサの一部であるが、ユーザ構成可能可能である。これらは、割り込み制御部７２と、データおよび命令アドレス監視部７４および７６と、ウィンドウレジスタファイル７８と、データおよび命令キャッシュおよびタグ部８０と、書き込みバッファ８２と、タイマ８４とを含む。図２に示された残りの部分は任意にはユーザによって含まれる。

プロセッサ構成システム１０の中央構成要素はユーザ構成インタフェース２０である。これは、好ましくはコンパイラの再構成およびアセンブラ、逆アセンブラおよび命令セットシミュレータ（ＩＳＳ）の再生と、全プロセッサ統合、配置およびルーチングを始める入力の作成を含むプロセッサ機能性を選択できるグラフィックユーザインタフェース（ＧＵＩ）をユーザに提供するモジュールである。それによって、ユーザも、プロセッサエリア、電力消費、サイクル時間、アプリケーション性能およびプロセッサ構成の他の反復およびエンハンスメントのためのコードサイズの迅速な推定を利用できる。好ましくは、ＧＵＩも、構成データベースにアクセスし、デフォルト値を得て、ユーザ入力のエラーチェックを行う。

プロセッサ６０を設計するために本実施例による自動プロセッサ生成システム１０を使用するために、ユーザは、設計パラメータをユーザ構成インタフェース２０に入力する。自動プロセッサ生成システム１０は、ユーザの制御の下でコンピュータシステムで実行するスタンドアロンシステムであってもよい。すなわち、しかしながら、このシステム１０は、好ましくは自動プロセッサ生成システム１０の製造の制御の下で主にシステムで実行する。次に、ユーザアクセスは、通信ネットワークを介して提供されてもよい。例えば、ＧＵＩは、ＨＴＭＬおよびジャバで記述されているデータ入力スクリーンを有するウェバブラウザを使用して提供されてもよい。これは、任意の所有権を主張できるバックエンドソフトウエアの機密性を保有し、保守を簡単にし、バックエンドソフトウエア等を更新するようないくつかの長所を有する。この場合、ＧＵＩにアクセスするために、ユーザは、自分のＩＤを証明するためにシステム１０に最初のログオンをしてもよい。

一旦ユーザがアクセス権を有すると、システムは図３に示されるように構成マネージャスクリーン８６を表示する。構成マネージャ８６は、ユーザによってアクセスできる構成の全てをリストするディレクトリである。図３の構成マネージャ８６は、ユーザが２つの構成、「ｊｕｓｔ ｉｎｔｒ」および「ｈｉｇｈ ｐｒｉｏ」、を有し、最初のものは既に形成された、すなわち製造のために終了され、第２番目のものは依然として形成されるべきであることを示している。このスクリーン８６から、ユーザは選択構成を形成し、削除し、編集し、どの構成および拡張がこの構成のために選択されるかあるいは新しい構成を形成するかを指定するリポートを生成してもよい。「ｊｕｓｔ ｉｎｔｒ」のような形成されたこれらの構成の場合、それのためにカストマイズされた一連のソフトウエア開発ツール３０はダウンロードできる。

新しい構成を作成するかあるいは既存の構成を編集することは、図４に示された構成エディタ８８を持ち出す。構成エディタ８８は、構成および拡張できるプロセッサ６０の様々な一般的な態様を示す左側に「オプション」セクションメニューを有する。オプションセクションが選択される場合、このセクションのための構成セクションを有するスクリーンが右側に表示され、これらのオプションは、当該技術分野で公知であるようにプルダウンメニュー、メモメニュー、メモボックス、チェックボックス、ラジオボタン等でセットできる。ユーザは、オプションを選択し、データをランダムに入力できるけれども、好ましくは、セクション間に論理従属関係があるので、データは各々に逐次入力される。例えば、「割り込み」セクションにオプションを適切に表示するために割り込み数は「ＩＳＡ Ｏｐｔｉｏｎｓ」セクションで選択されねばならない。

本実施例では、下記の構成オプションは各セクションに対して使用可能である。

目的
推定のための技術
ターゲットＡＳＩＣ技術：．１８，．２５．．３５ミクロン
ターゲット作動状態：典型的な、最悪の場合
インプリメンテーション目標
ターゲット速度：任意 ゲート総数：任意
ターゲット電力：任意
目的優先化：速度、領域電力、速度、電力、領域
ＩＳＡオプション
数値オプション
４０ビットアキュムレータを有するＭＡＣ１６：イエス、ノー
１６ビット乗算器：イエス、ノー
例外オプション
割り込み数：０〜３２
高優先順位割り込みレベル：０〜１４
イネーブルデバッギング：イエス、ノー
タイマ数：０〜３
その他
バイト配列：リトル・エンディアン、ビッグ・エンディアン
ウィンドウズ（登録商標）を呼び出すために使用可能なレジスタ数：３２、６４
プロセッサキャッシュ＆メモリ
プロセッサインタフェース読み出し幅（ビット）：３２、６４、１２８
書き込みバッファエントリ（アドレス／値対）：４、８、１６、３２
プロセッサキャッシュ
命令／データキャッシュサイズ（ｋＢ）：１、２、４、８、１６
命令／データキャッシュラインサイズ（ｋＢ）：１６、３２、６４
周辺構成要素
タイマ
タイマ割り込み数
タイマ割り込みレベル
デバッギングサポート
命令アドレスブレークポイントレジスタ数：０〜２
データアドレスブレークポイントレジスタ数：０〜２
デバッグ割り込みレベル
トレースポート：イエス、ノー
オンチップデバッグモジュール：イエス、ノー
全走査：イエス、ノー
割り込み
ソース：外部、ソフトウエア
優先順位レベル
システムメモリアドレス
ベクトルおよびアドレス計算法：ＸＴＯＳ、マニュアル
構成パラメータ
ＲＡＭサイズ、開始アドレス：任意
ＲＯＭサイズ、開始アドレス：任意
ＸＴＯＳ：任意
構成特定アドレス
ユーザ例外ベクトル：任意
カーネル例外ベクトル：任意
レジスタウィンドウオーバーフロー／アンダーフローベクトルベース： 任意
リセットベクトル：任意
ＸＴＯＳ開始アドレス：任意
アプリケーション開始アドレス：任意
ＴＩＥ命令
（ＩＳＡ拡張を規定する）
ターゲットＣＡＤ環境
シミュレーション Ｖｅｒｉｌｏｇ（登録商標）：イエス、ノー
統合
Ｄｅｓｉｇｎ Ｃｏｍｐｉｌｅｒ（登録商標）：イエス、ノー
場所＆ルート
Ａｐｏｌｌｏ（登録商標）：イエス、ノー
さらに、システム１０は、３２ビット整数乗算／除算装置あるいは浮動小数点演算装置、メモリ管理装置、オンチップＲＡＭおよびＲＯＭオプション、キャッシュ連想性、機能拡張ＤＳＰおよびコプロセッサ命令セット、ライトバックキャッシュ、マルチプロセッサ同期化、コンパイラ指向推測、および付加ＣＡＤパッケージのためのサポートのような他の付加装置を追加するためのオプションを提供する。たとえどんな構成オプションが所与の構成プロセッサのために使用可能であっても、この構成オプションは好ましくは、一旦ユーザが適切なオプションを選択したとしてもシステム１０がシンタックスチェック等のために使用する定義ファイル（例えば、付録Ａに示された定義ファイル）に列挙される。

前述から、自動プロセッサ構成システム１０は、図５に示されるようにユーザに２つの一般的な種類の構成性３００、すなわちユーザがスクラッチからの任意の機能および構造を規定できる伸長性３０２およびユーザが所定の制約されたオプションのセットから選択できる変更可能性３０４を提供する。変更可能性内で、システムは、所定の機能、例えばＭＡＣ１６あるいはＤＳＰが、プロセッサ６０に付加されるべきであるかどうかおよび他のプロセッサの機能、例えば割り込み数およびキャッシュサイズのパラメータ仕様３０８の２進選択３０６を可能にする。

上記の構成オプションの多くは当業者にはよく知られている。しかしながら、他のものは特別の注意に値する。例えば、ＲＡＭおよびＲＯＭオプションによって、設計者は、プロセッサ１０そのものにスクラッチパッドあるいはファームウエアを含めることができる。プロセッサ１０は、命令を取り出し、これらのメモリからのデータを読み出し、書き込む。メモリのサイズおよび配置は構成可能である。この実施例では、これらのメモリの各々は、セットアソシアティブキャッシュの付加セットとしてアクセスされる。メモリのヒットは単一のタグメモリと比較することによって検出できる。

システム１０は、割り込みのための別個の構成オプション（レベル１割り込みを実行する）および高優先順位割り込みオプション（レベル２〜１５の割り込みおよびノンマスカブル割り込みを実行する）を行う。何故ならば、各高優先順位割り込みレベルは３つの特別レジスタを必要とするので、これらのレジスタはより高価であるためである。

４０ビットアキュームレータオプションを有するＭＡＣ１６（図２の９０に示されている）は、４０ビットアキュームレータを有する１６ビット乗算器／加算機能、８つの１６ビットオペランドレジスタおよび乗算、累算、オペランドロードおよびアドレス更新の命令を結合する複合命令のセットを付加する。オペランドレジスタには、乗算／累算演算と並列にメモリから１６ビット値の対がロードできる。この装置は、サイクル毎の２つのロードおよび乗算／累算を有するアルゴリズムを持続できる。

オンチップデバッグモジュール（図２の９２に示されている）は、ＪＴＡＧポート９４を介してプロセッサ６０の内部ソフトウエアビジブルステートをアクセスするために使用される。モジュール９２は、プロセッサ６０をデバッグモードにする例外生成のためのサポート、全プロセッサビジブルレジスタあるいはメモリロケーションへのアクセス、プロセッサ６０が実行するために構成される任意の命令の実行、コードの所望の位置にジャンプするＰＣの変更、およびＪＴＡＧポート９４を介するプロセッサ６０の外部から作動される通常の動作モードに戻ることができるユーティリティ、を行う。

一旦プロセッサ１０がデバッグモードに入ると、プロセッサ１０は、有効命令がＪＴＡＧポート９４を介してスキャンインされたことの外部領域からの指示を待つ。次に、このプロセッサは、この命令を実行し、次の有効命令を待つ。一旦プロセッサ１０のハードウエアインプリメンテーションが製造されたとすると、このモジュール９２はシステムをデバッグするために使用できる。プロセッサ１０の実行は、遠隔ホストで実行するデバッガを介して制御できる。このデバッガは、ＪＴＡＧポート９４を介してプロセッサとインタフェースし、オンチップデバッグモジュール９２の機能を使用し、命令の実行を制御するのと同様にプロセッサ１０の状態を決定し、制御する。

最高３２ビットのカウンタ／タイマ８４が構成されてもよい。これは、割り込み機能および同様な機能と併用するために、（各構成タイマに対して）比較レジスタおよび比較レジスタ内容と現クロックレジスタカウントとを比較する比較器と同様に各クロックサイクルを増分する３２ビットのレジスタの使用を必要とする。このカウンタ／タイマはエッジトリガされるものとして構成でき、通常あるいは高優先順位の内部割り込みを発生できる。

推測オプションは、ロードが必ずしも実行されない場合、ロードがフローを制御するために推測して移動できることによってより大きいコンパイラスケジューリング融通性を提供する。ロードは例外を生じてもよいために、このロード移動は、例外を最初に生じなかった有効プログラムに導入できる。ロードが実行されない場合、推測ロードは、これらの例外が生じることを防止するが、このデータが必要とされる場合、例外を与える。ロードエラーに対する例外を生じる代わりに、推測ロードは、ディスティネーションレジスタの有効ビットをリセットする（このオプションに関連した新しいプロセッサ状態）。

複数のプロセッサがシステムで使用される場合、コアプロセッサ６０は好ましくは若干の基本パイプライン同期機能を有するけれども、プロセッサ間のある種の通信および同期が必要である。いくつかの場合、入出力待ち行列のような自己同期通信技術が使用される。他の場合、共有メモリモデルは通信のために使用され、共有メモリは必要とされるセマンティックスを提供するために、同期のための命令セットサポートを行うことが必要である。例えば、セマンティックスを得て、解除する場合の付加ロード命令およびストア命令を付加できる。これらは、同期基準間の正確な配列が保持されなければならないようにメモリロケーションが同期およびデータのために使用されてもよいマイクロプロセッサシステムでメモリ参照の配列を制御するために役に立つ。

いくつかの場合、共有メモリモデルは通信のために使用され、共有メモリは必要とされるセマンティックスを提供しないために同期に対する命令セットサポートを行う必要がある。これはマイクロプロセッサ同期オプションによって行われる。

おそらく構成オプションの中で最も顕著なものは、設計者定義の命令実行装置９６が形成されるＴＩＥ命令定義である。カリフォルニア州のサンタクララ市のテンシリカ社によって開発されたＴＩＥ（登録商標）（Tensilica Instruction Set Extensions）言語によって、ユーザは、拡張および新しい命令の形でアプリケーションのためのカスタム機能を記述し、ベースＩＳＡを拡張できる。さらに、ＴＩＥの汎用性のために、ＴＩＥは、ユーザによって変更できないＩＳＡの部分を記述するために使用されてもよい。このように、全ＩＳＡは、ソフトウエア開発ツール３０およびハードウエアインプリメンテーション記述４０を均一に生成するために使用できる。ＴＩＥ技術は、多数の形成ブロックを使用し、下記のように新しい命令の属性を記述する。

‥命令フィールド ‥命令クラス
‥命令操作符号 ‥命令セマンティックス
‥命令オペランド ‥一定テーブル
命令フィールドステートメントｆｉｅｌｄは、ＴＩＥコードの可読性を改善するために使用される。フィールドは、一緒にグループ化され、名前によって参照される他のフィールドの連結のサブセットである。命令のビットの全セットは、最高レベルスパーセットフィールドｉｎｓｔであり、このフィールドはより小さいフィールドに分割できる。例えば、

は、２つの４ビットフィールドを規定し、ｘおよびｙは、最高レベルフィールドｉｎｓｔのサブフィールド（ビット８〜１１および１２〜１５のそれぞれ）として、８ビットフィールドｘｙはｘフィールドおよびｙフィールドの連結として規定する。

ステートメント操作符号は特定のフィールドを符号化する操作符号を規定する。このように規定された操作符号によって使用されるオペランド、例えば、レジスタあるいは即値定数を指定することを目的とする命令フィールドは、最初にフィールドステートメントで規定され、次にオペランドステートメントで規定されねばならない。

例えば、

は、予め規定された操作符号ＣＵＳＴＯ（４，ｂ｜００００は４ビットの長さの２進定数００００を示す）に基づいて２つの新しい操作符号、ａｃｓおよびａｄｓｅｌを規定する。好ましいコアＩＳＡのＴＩＥ仕様はそのベース定義の一部として下記のステートメントを有する。

したがって、ａｃｓおよびａｄｓｅｌの定義によって、ＴＩＥコンパイラは、下記によってそれぞれ示される命令復号化ロジックを生成する。

命令オペランドステートメントオペランドは、レジスタおよび即値定数を識別する。しかしながら、フィールドをオペランドとして規定する前に、このオペランドは前述のようなフィールドとして予め規定されねばならかった。オペランドが即値定数である場合、定数の値はオペランドから生成できるかあるいは定数の値は後述されるように規定された予め規定された定数テーブルからとることができる。例えば、即値オペランドを符号化するために、下記のＴＩＥコードは、

符号付数字およびオフセットフィールドに記憶された数の４倍であるオペランドｏｆｆｓｅｔ４を保有する１８ビットフィールド名オフセットを規定する。オペランドステートメントの最後の部分は、当業者に明らかであるように、組合せ回路を記述するＶｅｒｉｌｏｇ（登録商標）ＨＤＬのサブセットの計算を実行するために使用される回路を実際に記述する。

ここで、ｗｉｒｅステートメントは、ｔの名前の３２ビット幅の論理ワイヤのセットを規定する。ｗｉｒｅステートメント後の最初のａｓｓｉｇｎステートメントは、論理ワイヤを駆動する論理信号は右にシフトされたｏｆｆｓｅｔ４定数であることを指定し、第２番目のａｓｓｉｇｎステートメントは、ｔの下部１８ビットがｏｆｆｓｅｔフィールドに入れられることを指定する。まさしく最初のａｓｓｉｇｎステートメントは、ｏｆｆｓｅｔ４オペランドの値をｏｆｆｓｅｔの連結および２ビットの左シフトが続くその符号ビット（ビット１７）の１４の複製として直接指定する。

定数テーブルオペランドに関しては、ＴＩＥコード

は、テーブルステートメントの使用を行い、定数のアレイプライム（テーブル名に続く数はテーブルの要素の数である）を規定し、オペランドをインデックスとして使用し、テーブルプライムとし、オペランドｐｒｉｍｅ ｓのための値を符号化する（インデクシングを規定する際のＶｅｒｉｌｏｇ（登録商標）ステートメントの使用を注目せよ）。

命令クラスステートメントｉｃｌａｓｓは、操作符号を共通フォーマットのオペランドに関連付ける。ｉｃｌａｓｓステートメントで規定された全命令は、同じフォーマットおよびオペランド使用を有する。命令クラスを規定する前に、その構成要素は、最初にフィールドとして、次に操作符号およびオペランドとして規定されねばならない。例えば、オペランドａｃｓおよびａｄｓｅｌを規定する前述の例で使用されるコードで形成すると、下記の付加ステートメント

は、３つのレジスタオペランドａｒｔ、ａｒｓおよびａｒｒを規定するためにオペランドステートメントを使用する（定義のＶｅｒｉｌｏｇ（登録商標）ステートメントの使用を再び注目せよ）。したがって、ｉｃｌａｓｓステートメント

は、オペランドａｄｓｅｌおよびａｃｓが２つのレジスタオペランドａｒｔおよびａｒｓを入力として扱う普通のクラスの命令ｖｉｔｅｒｂｉに属することを指定し、出力をレジスタオペランドａｒｒに書き込む。

命令セマンティックステートメントｓｅｍａｎｔｉｃは、オペランドを符号化するために使用される同じサブセットのＶｅｒｉｌｏｇ（登録商標）を使用して１つあるいはそれ以上の命令の働きを記述する。単一セマンティックステートメントで複数命令を規定することによって、いくつかの共通式が共有でき、ハードウエアインプリメンテーションはより有効にされることができる。セマンティックステートメントで許可された変数は、ステートメントの操作符号リストに規定された操作符号のためのオペランドおよび操作符号リストで指定された各操作符号のための単一ビット変数である。この変数は操作符号と同じ名前を有し、操作符号が検出される場合、１に対する数値を求める。この変数は、対応する命令の存在を示すために計算部（Ｖｅｒｉｌｏｇ（登録商標）サブセットセクション）で使用される。

例えば、他の３２ビットワードのそれぞれの８ビットオペランドとともに３２ビットワードの４つの８ビットオペランドの加算を実行する新しい命令ＡＤＤ８ ４および３２ビットワードの２つの１６ビットオペランドと他の３２ビットワードのそれぞれの１６ビットオペランドとの間で最少値選択を実行する新しい命令ＭＩＮ１６ ２を規定するＴＩＥコードは、下記を読み取ってもよい。

ここで、ｏｐ２、ＣＵＳＴＯ、ａｒｒ、ａｒｔおよびａｒｓは、前述のような予め規定されたオペランドおよび前述のようなｏｐｃｏｄｅおよびｉｃｌａｓｓステートメント関数である。

セマンティックステートメントは、新しい命令によって実行される計算を指定する。当業者に容易に明らかであるように、セマンティックステートメント内の第２行は、新しいＡＤＤ８ ４命令によって実行された計算を指定し、その中の第３行および第４行は、新しいＭＩＮ１６ ２命令によって実行された計算を指定し、このセクション内の最後の行はａｒｒレジスタに書き込まれた結果を指定する。

ユーザ入力インタフェース２０の議論に戻ると、一旦ユーザが望む構成および拡張オプションの全てを入力したとすると、形成システム５０が引き継ぐ。図５に示されるように、形成システム５０は、ユーザによってセットされたパラメータによって構成された構成仕様およびユーザによって設計された伸長機能を受け取り、これらをコアプロセッサアーキテクチャを規定する付加パラメータ、例えば、ユーザによって変更可能な機能と結合し、全プロセッサを記述する単一構成仕様１００を形成する。例えば、ユーザによって選択された構成設定に加えて、形成システム５０は、プロセッサの物理的アドレス空間のための物理アドレスビット数を指定するパラメータ、リセット後のプロセッサ６０によって実行される第１の命令の位置等を加算してもよい。

テンシリカ社によるＸｔｅｎｓａ（登録商標）命令セットアーキテクチャ（ＩＳＡ）基準マニュアル改訂１．０は、構成可能なプロセッサ内でコア命令として実行できる命令および構成オプションの選択によって使用可能である命令の例を示す目的のために参照してここに組み込まれている。

構成仕様１００は、ベースＩＳＡを指定するＴＩＥ言語ステートメントを含むＩＳＡパッケージ、コプロセッサパッケージ９６（図２を参照）あるいはＤＳＰパッケージのようなユーザによって選択された任意の付加パッケージ、およびユーザによって供給された任意のＴＩＥ拡張も含む。さらに、構成仕様１００は、所定の構造機能がプロセッサ６０に含まれるべきであるかどうかを示すフラグをセットする多数のステートメントを有してもよい。例えば、

は、プロセッサが、オンチップデバッギングモジュール９２、割り込み機能７２および例外処理を含むが、高優先順位割り込み機能を含まないことを示す。

構成仕様１００を使用すると、下記は、後記に示されるように自動的に生成できる。

・ プロセッサ６０の命令復号化ロジック
・ プロセッサ６０のための不正命令検出ロジック
・ アセンブラ１１０の特定ＩＳＡ用部分
・ コンパイラ１０８のための特定ＩＳＡ用サポートルーチン
・ 逆アセンブラ１００（デバッガによって使用される）の特定ＩＳＡ用部分
・ シミュレータ１１２の特定ＩＳＡ用部分
重要な構成機能は命令のパッケージの包含を指定することにあるために、これらのことを自動的に生成することは有用である。いくつかのことに関して、命令が構成された場合、これをツールの各々において条件付コードで実行し、命令を処理することができるが、これは扱いにくい。より重要なことには、命令によってシステム設計者は設計者のシステムのための命令を容易に加えることができる。

構成仕様１００を設計者からの入力として扱うことに加えて、目標を受け入れ、形成システム５０を有し、構成を自動的に決定することもできる。設計者はプロセッサ６０のための目標を指定できる。例えば、クロック速度、面積、コスト、典型的な電力消費、および最大電力消費は目標であってもよい。目標のいくつかは競合するので（例えば、しばしば性能は、面積あるいは電力消費あるいは両方を増加させることによってのみ増加させることができる）、形成システム５０は、目標に対する優先順位配列も行う。次に、形成システム５０は、サーチエンジン１０６を調べ、利用可能な構成オプションのセットを決定し、入力目標を同時に実行しようと試みるアルゴリズムから各オプションをいかにセットするかを決定する。

サーチエンジン１０６は、いろいろの距離に与える効果を記述するエントリを有するデータベースを含む。エントリは、特定の構成設定が距離に加法的、乗法的、あるいは制限する効果がある。エントリは、前提条件として他の構成オプションを必要とするものとしてあるいは他のオプションと互換性がないものとしても示すことができる。例えば、簡単なブランチ予測オプションは、命令毎のサイクル（ＣＰＩ‥性能の決定要素）にある乗法あるいは加法の効果、クロック速度への制限、面積への加法効果、および電力への加法効果を指定できる。このオプションは、より手の込んだブランチ予測子と一致しないものとして示すことができ、命令フェッチ待ち行列サイズを少なくとも２つのエントリに設定することに左右される。これらの効果の値は、ブランチ予測テーブルサイズのようなパラメータの関数であってもよい。一般に、データエントリは数値を求められる関数として示すことができる。

いろいろのアルゴリズムは、入力目標を達成することに最も接近する構成設定を探すために可能である。例えば、簡単なナップザックパッキングアルゴリズムは、コストで割られた値の分類配列の各オプションを考察し、コストを特定の制限内に保持している間、値を増加させる任意のオプション仕様を受け入れる。それで、例えば、電力を指定値以下に保持している間に性能を最少にするために、このオプションは、電力で割られた性能によって分類され、電力制限を超えないで構成できる性能を増加させる各オプションが受け入れられ。より込み入ったナップザックアルゴリズムは若干のバックトラッキング量を提供する。

目標および設計データベースから構成を決定する非常に異なる種類のアルゴリズムはシミュレートアニーリングに基づいている。ランダム初期セットのパラメータは、開始点として使用され、次に個別パラメータの変更は、グローバルユーティリティ関数の数値を求めることによって受け入れられるかあるいは拒否される。ユーティリティ関数の改良は常に、マイナスの変更は最適化が進行するときに低下する閾値に確率的に基づいて受け入れられている間に常に受け入れられる。このシステムでは、ユーティリティ関数は入力目標から構成される。例えば、目標性能＞２００、電力＜１００、面積＜４が与えられる、電力、面積および性能の優先順位に関して、電力消費が１００以下で、次にニュートラルになるまで、電力消費の減少に報い、面積が４以下で、次にニュートラルになるまで、面積の減少に報い、性能が２００以上で、次にニュートラルになるまで、性能の増加に報いる下記のユーティリティ関数が使用できる。

電力が仕様外面積使用を減少させ、電力あるいは面積が仕様外である場合性能使用を減少させる構成要素もある。

これらのアルゴリズムおよび他のアルゴリズムは、指定された目標を満たす構成を探すために使用できる。重要なことは、構成可能なプロセッサ設計が前提条件、非互換性オプション仕様およびいろいろの距離に及ぼす構成オプションの影響を有する設計データベースに記述されていることである。

我々が示した例は、一般的であり、プロセッサ６０で実行された特定のアルゴリズムに左右されないハードウエア目標を使用した。記述されているアルゴリズムは、特定のユーザプログラムに最適の構成を選択するために使用することもできる。例えば、ユーザプログラムは、異なるサイズ、異なるラインサイズおよび異なるセットアソシアティブのような異なる特性を有する、異なる種類のキャッシュに対するキャッシュミス数を測定するためにキャッシュの正確なシミュレータで実行できる。これらのシミュレーションの結果は、ハードウエアインプリメンテーション記述４０を選択するのに役立つように記述された検索アルゴリズム１０６によって使用されるデータベースに付加できる。

同様に、ユーザアルゴリズムは、ハードウエアで任意に実現できる所定の命令の存在に対してプロフィールできる。例えば、ユーザアルゴリズムが乗算を行うかなりの時間を行う。サーチエンジン１０６は、ハードウエア乗算器を含むことを自動的に示唆し得る。このようなアルゴリズムは１つのユーザアルゴリズムを考察することに限定する必要がない。ユーザは、アルゴリズムのセットをシステムに供給することができ、サーチエンジン１０６は、平均してユーザプログラムのセットに役に立つ構成を選択できる。

プロセッサ６０の予め構成された特性を選択することに加えて、サーチアルゴリズムは、ユーザ可能ＴＩＥ拡張を自動的に選択するかあるいはユーザ可能ＴＩＥ拡張に示唆するためにも使用できる。入力目標が与えられ、多分Ｃプログラミング言語で記述されたユーザプログラムの例が与えられると、これらのアルゴリズムは可能性があるＴＩＥ拡張を示唆する。状態がないＴＩＥ拡張の場合、コンパイラのようなツールはパターン一致器で具体化される。これらのパターン一致器は、単一命令と取り換えることができる複数の命令パターンを検索するボトムアップ方法で式のノードを移動する。例えば、ユーザＣプログラムが下記のステートメントを含むことを示す。

ｘ＝（ｙ＋ｚ）＜＜２；
ｘ２＝（ｙ２＋ｚ２）＜＜２；
パターン一致器は、２つの異なる位置のユーザが２つの数を加算し、この結果を２ビットを左にシフトすることを見つける。このシステムは、２つの数を加算し、この結果を２ビットを左にシフトするＴＩＥ命令を生成する可能性をデータベースに加える。

形成システム５０は、ＴＩＥ命令が何回現れるかのカウントとともに多数の可能性のあるＴＩＥ命令について常に知っている。プロフィリングツールを使用すると、システム５０は、どのくらい頻繁に各命令がアルゴリズムの全実行中実行されるかについても常に知っている。ハードウエア推定器を使用すると、システム５０は、各可能性のあるＴＩＥ命令を実行するべきであるハードウエアでどれほど高価であるかについても常に知っている。これらの数は、入力目標、すなわち性能、コードサイズ、ハードウエア複雑さ等のような目標を最大にする可能性のあるＴＩＥ命令のセットを選択するために発見的探索アルゴリズムに供給される。

同じであるが、より強力なアルゴリズムは状態を有する可能性のあるＴＩＥ命令を見つけるために使用される。いくつかの異なるアルゴリズムは異なる種類の好機を検出するために使用される。１つのアルゴリズムは、コンパイラのようなツールを使用し、ユーザプログラムを走査し、ユーザプログラムがハードウエアで使用可能であるよりも多くのレジスタを必要とするかどうかを検出する。当該技術の専門家に公知であるように、これは、レジスタスピルの数をカウントすることによって検出でき、ユーザコードのコンパイルバージョンに再記憶する。コンパイルのようなツールは、付加ハードウエアレジスタ９８を有するコプロセッサをサーチエンジンに示唆するが、多数のスピルを有し、再記憶するユーザのコードの一部で使用される演算だけをサポートする。このツールは、ユーザのアルゴリズムがいかに改善されたかの推定と同様にコプロセッサのハードウエアコストの推定のサーチエンジン１０６によって使用されるデータベースを知らせる責任を負う。前述のように、本サーチエンジン１０６は、示唆されたコプロセッサ９８が十分な構成をもたらすか否かのグローバルに決定を行う。

それとは別にあるいはそれとともに、ユーザプログラムが、コンパイルのようなツールは、ユーザプログラムが所定の変数が所定の制限よりも決して大きくないことを保証するためにビットマスク演算を使用するかどうかを検査する。この状況では、このツールは、ユーザ制限に合致するデータタイプ（例えば、１２ビットあるいは２０ビットもしくは任意の他の大きさの整数）を使用するコプロセッサ９８をサーチエンジン１０６に示唆する。Ｃ＋＋におけるユーザプログラムために使用される他の実施例で使用される第３のアルゴリズムでは、コンパイルのようなツールは、ユーザ定義の抽象データタイプで演算するのに多くの時間が費やされることが分かる。データタイプの全演算がＴＩＥに適しているけれども、アルゴリズムは、ＴＩＥコプロセッサによってデータタイプの全演算を実行することをサーチエンジン１０６に示唆する。

プロセッサ６０の命令復号化ロジックを生成するために、１つの信号が構成仕様で規定された各操作符号のために発生される。このコードは宣言

をＨＤＬステートメント

に、および

を

に単に再書き込みすることにより発生される。

レジスタインターロックおよびパイプラインストールの信号の発生も自動化される。このロジックは構成仕様の情報に基づいても生成される。現命令のソースオペランドが完了しなかった前の命令のディスティネーションオペランドによって決まる場合、命令のｉｃｌａｓｓステートメントおよび待ち時間に含まれるレジスタ使用情報に基づいて、生成されたロジックはストール（あるいはバブル）を挿入する。このストール機能性を実行する機構はコアハードウエアの一部として実現される。

不正命令検出ロジックは、命令信号のフィールド制限とＡＮＤをとられた個別の生成された命令信号と一緒にＮＯＲをとることにより生成される。

命令復号化信号および不正命令信号は、復号化モジュールの出力としておよび手で書かれたプロセッサロジックの入力として使用可能である。

他のプロセッサ機能を生成するために、本実施例は、ペリベースプリプロセッサ言語で機能強化された構成可能なプロセッサ６０のＶｅｒｉｌｏｇ（登録商標）記述を使用する。ペリは、複合制御構造、サブルーチンおよびＩ／Ｏ機能を含む全機能言語である。本発明の実施例では、ＴＰＰ（付録Ｂに列挙するソースに示されているように、ＴＰＰはペリプログラムそのものである）と呼ばれるプリプロセッサは、その入力を走査し、プリプロセッサ言語（ＴＰＰの場合はペリ）で記述されたプリプロセッサコードとしての所定の行（これらの行は、ＴＰＰの場合、セミコロンでプリフィックスされる）を識別し、抽出された行およびステートメントからなるプログラムを構成し、他の行のテキストを生成する。非プリプロセッサ行は、その場所でＴＰＰ処理の結果として生成される式が代入され、埋め込まれた式を有する。したがって、結果として生じるプログラムは、ソースコード、すなわち詳細プロセッサロジック４０を記述するＶｅｒｉｌｏｇ（登録商標）コード（下記で分かるように、ＴＰＰもソフトウエア開発ツール３０を構成するために使用される）を生成するように実行される。

このコンテキストで使用される場合、ＴＰＰは、前述のようにＶｅｒｉｌｏｇ（登録商標）コードの構成仕様１００によって決まり埋め込まれた式を実行するのと同様に構成仕様照会、条件付式およびＶｅｒｉｌｏｇ（登録商標）コードの反復構造のような構成子の包含を可能にするために、強力な前処理言語である。例えば、データベース照会に基づいたＴＰＰ割当は下記のようになりそうである。

ここで、ｃｏｎｆｉｇ ｇｅｔ ｖａｌｕｅは、構成仕様１００を照会するために使用されるＴＰＰ関数であり、ＩｓａＭｅｍｏｒｙＯｒｄｅｒは、構成仕様１００でセットされたフラグであり、Ｓｅｎｄｉａｎは、Ｖｅｒｉｌｏｇ（登録商標）コードを生成する際に後で使用されるべきＴＰＰ変数である。

ＴＰＰ条件付式は、

であってもよい。

反復ループは、下記のようなＴＰＰ構成子によって実行できる。

ここで、Ｓｉは、ＴＰＰループインデックス変数であり、Ｓｎｉｎｔｅｒｒｕｐｔｓは、プロセッサ６０のために指定された割り込み数である（ｃｏｎｆｉｇ ｇｅｔ Ｖａｌｕｅを使用して構成仕様１００から得られる）。

最後に、ＴＰＰコードは、下記のようなＶｅｒｉｌｏｇ（登録商標）式に埋め込むことができる。

ここで、Ｓｎｉｎｔｅｒｒｕｐｔｓは、割り込み数を規定し、ｘｔｓｃｅｎｆｌｏｐモジュール（フリップフロッププリミティブモジュール）の幅（ビットに関する）を決定する。

ｓｒＩｎｔｅｒｒｕｐｔＥｎは、適切なビット数のワイヤであると規定されるフリップフロップの出力である。

ｓｒＤａｔａＩｎ Ｗは、フリップフロップの入力であるが、関連ビットだけが割り込み数に基づいて入力される。

ｓｒＩｎｔｅｒｒｕｐｔＥｎＷＥｎは、フリップフロップの書き込みイネーブルである。

ｃＲｅｓｅｔは、フリップフロップのクリア入力である。

ＣＬＫは、フリップフロップの入力クロックである。

例えば、下記の入力をＴＰＰ

および宣言

に与える。

ＴＰＰは下記を生成する。

このように生成されたＨＤＬ記述１１４は、ブロック１２２で例えばＳｙｎｏｐｓｙｓ社によって製造されたデザインコンパイラ（登録商標）を使用してプロセッサインプリメンテーションのためのハードウエアを統合するために使用される。一旦構成要素が経路選択されると、この結果は、例えばＳｙｎｏｐｓｙｓ社によるプライムタイム（登録商標）を使用してブロック１３２でワイヤ逆注釈およびタイミング検証のために使用できる。この処理の成果物は、他の構成反復のため構成獲得ルーチン２０に他の入力を供給するようにユーザによって使用できるハードウエアプロファイルである。

ロジック統合部１２２に関して述べられているように、プロセッサ６０を構成する結果の１つは、特定のゲートレベルインプリメンテーションが多数の商用統合ツールのいずれかを使用することによって得ることができるカスタマイズされたＨＤＬファイルのセットである。１つのこのようなツールは、Ｓｙｎｏｐｓｙｓ社からのデザインコンパイラ（登録商標）である。正確な、高性能なゲートレベルインプリメンテーションを保証するために、本実施例は、顧客の環境において統合処理を自動化するのに必要なスクリプトを提供する。このようなスクリプトを提供する際の要求は、いろいろのユーザの統合方法論および異なるインプリメンテーション目的をサポートすることにある。第１の要求を取り扱うために、この実施例は、このスクリプトをより小さいスクリプトおよび機能的に完全にスクリプトに分解する。１つのこのような例は、特定プロセッサ構成６０に関連する全ＨＤＬファイルを読み出すことができる読み出しスクリプト、プロセッサ６０に固有のタイミング要求をセットするタイミング抑制スクリプト、およびゲートレベルネットリストの配置および経路選択のために使用できる方法で統合結果を詳しく書くスクリプトを提供することにある。第２の要求を取り扱うために、本実施例は各インプリメンテーション目的のためのスクリプトを提供する。１つのこのような例は、より速いサイクルタイムを達成するスクリプト、最少シリコン領域を達成するスクリプト、および最少電力消費を達成するスクリプトを提供することにある。

スクリプトは、他のフェーズのプロセッサ構成でもまた使用される。例えば、一旦プロセッサ６０のＨＤＬが記述されたとすると、シミュレータは、ブロック１３２に関して前述されたようにプロセッサ６０の正しい動作を検証するために使用できる。これは、シミュレートされたプロセッサ６０で、多数のテストプログラム、あるいは診断を実行することによってしばしば達成される。シミュレートプロセッサ６０でテストプログラムを実行することは、テストプログラムの実行可能な画像を生成し、シミュレータ１１２によって読み出すことができるこの実行可能な画像の表示を生成し、シミュレーションの結果が将来の解析のために収集できるこの実行可能な画像の表示を形成し、このシミュレーションの結果等を解析するような多数のステップを必要とし得る。従来技術では、これは、多数の廃棄スクリプトで行われた。これらのスクリプトは、どのＨＤＬファイルが含まれるべきであるか、これらのファイルのどの場所がディレクトリ構造にあり得るか、どのファイルがテストベンチのために必要とされるか等のようなシミュレーション環境の若干の組み込み知識を有した。最新の設計では、好ましい実施例は、パラメータ置換によって構成されるスクリプトテンプレートを記述することにある。構成機構は、シミュレーションのために必要であるファイルのリストを生成するためにＴＰＰも使用する。

さらに、ブロック１３２の検証処理では、設計者が一連のテストプログラムを実行できる他のスクリプトを記述することがしばしば必要である。これは、ＨＤＬモデルの所与の変更が新しいバグを導入しないという信用を設計者に与える回帰スイートを実行するためにしばしば使用される。これらの回帰スクリプトも、ファイル名、ロケーション等についての多数の組み込み前提を有するようにしばしば廃棄された。単一のテストプログラムに対する実行スクリプトの形成に対して前述されるように、回帰スクリプトはテンプレートとして記述される。このテンプレートは、構成時パラメータを実際の値の代わりにすることによって構成される。

ＲＴＬ記述をハードウエアインプリメンテーションに変換する処理の最終ステップは、抽象ネットリストを幾何学的表示に変換するために場所およびルート（Ｐ＆Ｒ）ソフトウエアを使用することにある。Ｐ＆Ｒソフトウエアは、ネットリストの結合性を解析し、セルの配置を決定する。次に、このソフトウエアは、全セル間の接続の線を描くことを試みる。クロックネットは、通常特別の注意に値し、最後のステップとして経路選択される。この処理は、両方とも、どのセルが一緒に接近していると予想されるか（ソフトグルーピングとして公知である）、セルの相対配置、どのネットがわずかな伝播遅延等を有すると予想されるかのような若干の情報をツールに提供することによって促進できる。

この処理を容易にするためにおよび所望の性能目標、すなわちサイクル時間、面積、電力消費が達成されることを保証するために、構成機構は、Ｐ＆Ｒソフトウエアのためのスクリプトのセットあるいは入力ファイルを生成する。これらのスクリプトは、セルのための相対配置のような前述されたような情報を含む。このスクリプトは、どれくらいの数の電源接続およびアース接続が必要であるか、いかにこれらが境界等に沿って分布されるべきであるかのような情報も含む。このスクリプトは、どれくらいの数のソフトグループを形成するかおよびどんなセルがソフトグループに含まれるべきであるかおよびどのネットが重要なタイミングであるかの情報を含むデータベースを照会することによって生成される。このパラメータは、どのオプションが選択されたかに基づいて変わる。これらのスクリプトは、場所およびルートを変えるために使用されるツールに応じて構成可能でなければならない。

任意には、構成機構は、ユーザからより多くの情報を要求し、Ｐ＆Ｒスクリプトに送ることができる。例えば、インタフェースは、ユーザに最終のレイアウトの所望のアスペクト比、どれくらいの数のバッファリングのレベルがクロックツリーに挿入されるべきであるか、どの側面に入出力ピンがこれらのピンの相対あるいは絶対の配置、電源およびアースのストラップ等にあるべきであるかを尋ねることができる。次に、これらのパラメータはＰ＆Ｒスクリプトに送られ、所望のレイアウトを生成する。

例えばより込み入ったクロックツリーを可能にするより込み入ったスクリプトさえ使用できる。電力消費を減らすために行われた１つの共通最適化はクロック信号をゲートすることにある。しかしながら、全ブランチの遅延をバランスさせることは非常に困難であるので、これは、クロックツリー統合を非常に困難にする。構成インタフェースは、ユーザに、正しいセルがクロックツリーのために使用し、クロックツリー統合の一部あるいは全部を実行することを尋ねることができる。構成インタフェースは、どこのゲートクロックがこの設計にあるかの若干の知識を有し、対象となるゲートからフリップフロップのクロック入力までの遅延を推定することによってこれを行う。したがって、このインタフェースは、クロックバッファの遅延をゲートセルの遅延と一致させるためにクロックツリー統合ツールに抑制を与える。最新のインプリメンテーションでは、これは汎用ペリスクリプトによって行われる。このスクリプトは、どのオプションが選択されるかに基づいて構成エージェントによって発生されたゲートクロック情報を読み出す。一旦設計が配置され、経路選択されたとするが、最終クロックツリー統合が行われる前に、ペリスクリプトが実行される。

更なる改善が前述されたプロフィール処理に対して行うことができる。特に、我々は、ユーザがこれらのＣＡＤツールを実行する時間を費やさないで殆ど同時に同様なハードウエアプロフィール情報を得ることができる処理を記述する。この処理はいくつかのステップを有する。

この処理の第１のステップは、ハードウエアプロフィールのグループのオプションの効果が任意の他のグループのオプションとは無関係であるように全構成オプションのセットを直交オプションのグループに分離することにある。例えば、ハードウエアプロフィールに対するＭＡＣ１６装置のインパクトは任意の他のオプションとは無関係である。それで、ＭＡＣオプションだけを有するオプショングループが形成される。より複雑な例は、ハードウエアプロフィールに対するインパクトはこれらのオプションの特定の組合せによって決定されるので、割り込みオプション、高レベル割り込みオプションおよびタイマオプションを含むオプショングループである。

第２のステップは、各オプショングループのハードウエアプロフィールのインパクトを特徴とすることにある。特徴付けは、グループのいろいろのオプションの組合せに対するハードウエアプロフィールのインパクトを得ることによって行われる。各組合せに関して、このプロフィールは、実際のインプリメンテーションが得られ、そのハードウエアプロフィールが測定される予め記述された処理を使用して得られる。このような情報は推定データベースに記憶されている。

最後のステップは、曲線取り付けおよび補間技術を使用してオプショングループのオプションの特定組合せによってハードウエアプロフィールを計算する特定の式を得ることにある。オプションの名前に応じて、異なる式が使用される。例えば、各付加割り込みベクトルは同じロジックについてハードウエアに加えるので、我々は、線形関数を使用し、そのハードウエアインパクトをモデル化する。他の例では、タイマ装置を有することは高優先順位割り込みオプションを必要とするので、タイマオプションのハードウエアのインパクトのための式は多数のオプションを含む条件付式である。

いかにアーキテクチャ選択がアプリケーションの実行時間性能およびコードサイズに影響を及ぼすかもしれないかの迅速フィードバックを提供することは役に立つ。複数のアプリケーション領域からのいくつかのセットのベンチマークプログラムがいくつかのセットが選択される。各領域に関して、いかに異なるアーキテクチャ設計決定が領域内のアプリケーションの実行時間性能およびコードサイズに影響を及ぼすかを推定するデータベースは、予め形成される。ユーザはアーキテクチャ設計を変えるので、データベースは、ユーザにあるいは複数の領域のために興味を引き起こさせるアプリケーション領域のために照会される。評価の結果はユーザに提示されるので、ユーザは、ソフトウエアの長所とハードウエアのコストとの間のトレードオフの推定を得る。

迅速な評価システムは、プロセッサをさらに最適化するためにいかに構成を変更するかの示唆をユーザに与えるために容易に拡張できる。１つのこのような例は、各構成オプションを面積、遅延および電力のようないろいろのコスト距離のオプションの増分インパクトを示す一組の数と関連付けることにある。所与のオプションのための増分コスト影響を計算することは迅速な評価システムで容易に行われる。それは、オプションの有無の評価システムに対する２つの呼び出しを単に必要とする。２つの評価に対するコストの差はオプションの増分インパクトを示す。例えば、ＭＡＣ１６オプションの増分領域インパクトは、ＭＡＣ１６のオプションの有無で２つの構成の領域コストを評価することによって計算される。次に、この差異は、対話構成システムのＭＡＣ１６オプションで表示される。このようなシステムは、一連の単一ステップ改善によって最適解決策の方へユーザを誘導できる。

自動プロセッサ構成処理のソフトウエア側に移ると、本発明の本実施例は、ソフトウエア開発ツール３０がプロセッサに固有であるようにソフトウエア開発ツール３０を構成する。構成処理は、いろいろの異なるシステムおよび命令セットアーキテクチャに移植できるソフトウエアツール３０で始める。このような目標を変えることができるツールは、幅広く研究され、周知である。本実施例は、フリーソフトウエアであり、例えば、ＧＮＵ Ｃコンパイラ、ＧＮＵアセンブラ、ＧＮＵリンカ、ＧＮＵプロファイラ、およびいろいろのユーティリティプログラムを含むＧＮＵファミリーのツールを使用する。次に、これらのツール３０は、ＩＳＡ記述からソフトウエアの一部を直接生成し、手で記述されたソフトウエアの一部を変更するためにＴＰＰを使用することによって自動的に構成される。

ＧＮＵ Ｃコンパイラはいくつかの異なる方法で構成される。コアＩＳＡ記述が与えられると、コンパイラの機械依存ロジックの多くが手で記述できる。コンパイラのこの一部は構成可能なプロセッサ命令セットの全構成に共通であり、手で目標を変更することは最善結果を得るための細かい調整を可能にする。しかしながら、コンパイラのこの手で符号された部分の場合さえ、若干のコードはＩＳＡ記述から自動的に生成される。特に、ＩＳＡ記述は、いろいろの命令の即値フィールドに使用できる一定値のセットを規定する。各即値フィールドの場合、述語関数は、特定の定数値がフィールドで符号化できるかどうかを試験するために生成される。コンパイラは、プロセッサ６０のためのコードを生成する場合、これらの述語関数を使用する。コンパイラ構成のこのアスペクトを自動化することは、ＩＳＡ記述とコンパイラとの間の不一致に対する機会を取り除き、それは、最少の努力でＩＳＡの定数を変えることを可能にする。

コンパイラのいくつかのアスペクトはＴＰＰで前処理を介して構成される。パラメータ選択によって制御された構成オプションの場合、コンパイラの対応するパラメータはＴＰＰによってセットされる。例えば、コンパイラは、ターゲットプロセッサ６０がビッグエンディアンあるいはリトルエンディアンバイト配列を使用し、この変数は、構成仕様１００からエンディアンネスを読み出すＴＰＰコマンドを自動的に使用してセットされる。ＴＰＰは、対応するパッケージが構成仕様１００で使用可能であるかどうかに基づいて任意のＩＳＡパッケージのためのコードを生成するコンパイラの手で符号化された部分を条件付で使用可能あるいは使用禁止するためにも使用できる。例えば、乗算／累算命令を生成するコードは、構成仕様がＭＡＣ１６オプション９０を含む場合、コンパイラにだけ含まれる。

コンパイラは、ＴＩＥ言語によって指定された設計者定義の命令をサポートするようにも構成される。このサポートには２つのレベルがある。最低レベルで、設計者定義の命令は、コンパイルされるコードのマクロ関数、組込み関数、あるいはインライン（外部）関数として利用可能である。本発明の本実施例は、「インラインアセンブリ」コードのようなインライン関数を規定するＣヘッダ（ＧＮＵ Ｃコンパイラの標準機能）を生成する。設計者定義の操作符号および操作符号の対応するオペランドが与えられると、このヘッダファイルを生成することは、ＧＮＵ Ｃコンパイラのインラインアセンブリシンタックスに変換する簡単な処理である。他のインプリメンテーションは、インラインアセンブリ命令を指定するＣプリプロセッサマクロを含むヘッダファイルを形成する。さらにもう一つの代替は、組込み関数をコンパイラの中に加えるためにＴＰＰを使用する。

設計者定義の命令に対する第２のレベルのサポートは、命令を使用する機会をコンパイラに自動的に認識させることによって提供される。これらの命令は、構成処理中ユーザによって直接規定あるいは自動的に形成できる。ユーザアプリケーションをコンパイルするより前に、ＴＩＥコードは、自動的に検査され、Ｃに等しい機能に変換される。これはＴＩＥ命令の高速シミュレーションを可能にするために使用できる同じステップである。Ｃに等しい機能は、コンパイラによって使用されるツリーベース中間表示に部分的にコンパイルされる。各ＴＩＥ命令に対するこの表示はデータベースに記憶される。ユーザアプリケーションがコンパイルされる場合、コンパイル処理の一部はパターン一致器である。ユーザアプリケーションはツリーベース表示にコンパイルされる。パターン一致器は、ユーザプログラムのツリー毎にボトムアップで移動する。移動の各ステップで、パターン一致器は、現ポイントにルートされた中間表示がデータベースのＴＩＥ命令のいずれかに一致しているかどうかを検査する。一致がある場合、一致が示される。各ツリーを移動することを完了した後、最大のサイズにされた一致のセットは選択される。ツリーの各最大一致は、等価のＴＩＥ命令と取り換えられる。

前述のアルゴリズムは、無状態ＴＩＥ命令を使用する機会を自動的に認識する。付加方式は、状態を有するＴＩＥ命令を使用する機会を自動的に認識するためにも使用できる。前述の節は、状態を有する可能性のあるＴＩＥ命令を自動的に選択するアルゴリズムを記載した。同じアルゴリズムは、ＣあるいはＣ＋＋アプリケーションのＴＩＥ命令を自動的に使用するために使用される。ＴＩＥコプロセッサがより多くのレジスタであるが限られた演算のセットを有するように規定された場合、コードの領域は、レジスタスピリングを受けるかどうかおよびこれらのレジスタが使用可能な演算のセットを使用するだけであるかどうかを調べるために走査される。このような領域が見つかった場合、これらの領域のコードは、コプロセッサ命令およびレジスタ９８を使用するために自動的に変更される。変換動作は、データをコプロセッサ９８の内外へ移動させるように領域の境界で発生される。同様に、ＴＩＥコプロセッサが異なる大きさの整数で作動するように規定された場合、コードの領域は、この領域の全データがあたかも異なる大きさであるかのようにアクセスされるかどうかを調べるように検査される。一致領域に関しては、このコードが変更され、グルーコードは境界に付加される。同様に、ＴＩＥコプロセッサ９８がＣ＋＋抽象データタイプを実行するために規定される場合、このデータタイプの全演算は、ＴＩＥコプロセッサ命令と取り換えられる。

ＴＩＥ命令を自動的に暗示することおよびＴＩＥ命令を自動的に使用することの両方とも個別に役立つことを注目せよ。暗示されたＴＩＥ命令は、組込み機構を介してユーザによっても手動で使用でき、アルゴリズムを利用することは手動で設計されたＴＩＥ命令あるいはコプロセッサ９８に加えることができる。

いかに設計者定義の命令がインライン関数あるいは自動認識のいずれかによって生成されたかにかかわらず、コンパイラは、これらの命令を最適化し、スケジュールできるように設計者定義の命令の可能性のある副作用を知る必要がある。性能を改良するために、従来のコンパイラは、実行時間性能、コードサイズあるいは電力消費のような所望の特性を最大にするためにユーザコードを最適化する。当該技術分野で十分熟練した人に公知であるように、このような最適化は、命令を再配置するかあるいは所定の命令を他の意味論的に等価な命令と取り換えるようなものを含む。最適化を十分実行するために、コンパイラは、いかにあらゆる命令がマシンの異なる部分に影響を及ぼすかを知らなければならない。マシン状態の異なる部分を読み書きする２つの命令が自由に再配列できる。従来のプロセッサの場合、異なる命令によって読み出しおよび／または書き込みされる状態は、時々テーブルによってコンパイラの中にハードワイヤードされる。本発明の一実施例では、ＴＩＥ命令は、内輪に見積もってもプロセッサ６０の状態全てを読み書きするものと仮定される。これによって、コンパイラは、正しいコードを生成するがコンパイラの能力を制限し、ＴＩＥ命令がある場合のコードを最適化できる。本発明の他の実施例では、ツールは、ＴＩＥ定義を自動的に読み出し、各ＴＩＥ命令に対してどの状態が前記命令によって読み出しあるいは書き込みされるかを見つける。次に、このツールは、コンパイラの最適化器によって使用されるテーブルを変更し、各ＴＩＥ命令の効果を正確にモデル化する。

コンパイラのように、アセンブラ１１０の機械依存部は、自動的に生成された部分およびＴＰＰで構成された手で符号化された部分の両方とも含む。全構成に共通の機能のいくつかは、手で記述されたコードでサポートされる。しかしながら、アセンブラ１１０の主要タスクは、機械命令を符号化することであり、命令符号化および復号化ソフトウエアはＩＳＡ記述から自動的に生成できる。

命令符号化および復号化は異なるソフトウエアツールで有用であるために、本発明の本実施例は、ソフトウエアをグループ化し、これらのタスクを実行し、別個のソフトウエアライブラリにする。このライブラリは、ＩＳＡ記述の情報を使用して自動的に生成される。このライブラリは、操作符号の一覧表、すなわち操作符号ニーモニックのためのストリングを一覧表のメンバー上に効率的にマッピングする関数（stringToOpcode）および各操作符号に対して命令長（instructionLength）、オペランド数（numberOfOperand）、オペランドフィールド、オペランドタイプ（すなわち、レジスタあるいは即値）（operandType）、２進符号化（encodeOpcode）およびニーモニックストリング（opcodeName）を指定するテーブルを規定する。各オペランドフィールドに関しては、ライブラリは、命令ワードの対応するビットを符号化するアクセスサ関数（fieldSetFunction）および復号化するアクセスサ関数（fieldGetSetFunction）を提供する。この情報の全部は、ＩＳＡ記述で容易に利用可能である。すなわち、ライブラリソフトウエアを生成することは、単にこの情報を実行可能なＣコードに変換する問題である。例えば、各エントリが各操作符号フィールドをＩＳＡ記述のこの命令に対して指定された値に設定することによって生成された特定の命令に対する符号化である場合、命令符号化は、Ｃアレイ変数に記録される。ｅｎｃｏｄｅＯｐｅｃｏｄｅ関数は、単に所与の操作符号に対してアレイ値に戻る。

ライブラリも、２進命令（decodeInstruction）の操作符号を復号化する関数を提供する。この関数は、最も外側のスイッチが操作符号階層の上部でサブ操作符号をテストする一連のネストスイッチステートメントとして生成され、ネストされたスイッチステートメントは操作符号階層の徐々により低いサブ操作符号をテストする。したがって、この関数に対して生成されたコードは、操作符号そのものと同じ構造を有する。

命令を符号化および復号化するこのライブラリが与えられると、アセンブラ１１０は容易に実行される。例えば、アセンブラの命令符号化ロジックは全く簡単である。すなわち

２進命令をアセンブリコードに非常に類似している可読形式に変換する逆アセンブラ１１０を実行することは同様に簡単である。

この逆アセンブラアルゴリズムはスタンドアロン逆アセンブラツールにおいて使用され、またマシーンコードのデバッギングをサポートするためにデバッガ１３０においても使用される。

リンカはコンパイラやアセンブラ１１０程機器構成に対してあまり敏感ではない。リンカの多くは標準型であり、機械依存部分でさえ主としてコアＩＳＡ記述に依存しており、特定のコアＩＳＡに対して手動で符号化することができる。ｅｎｄｉａｎｎｅｓｓ等のパラメータはＴＰＰを使用して構成仕様書１００から設定される。ターゲットプロセッサ６０のメモリマップはリンカが必要とする構成の他の１つの局面である。このように、メモリマップを指定するパラメータは、ＴＰＰを使用してリンカに挿入される。本発明のこの実施形態では、ＧＮＵリンカが一組のリンカスクリプトによって駆動され、それはメモリマップ情報を含むこれらのリンカスクリプトである。このアプローチの利点は、ターゲットシステムのメモリマップが、プロセッサ６０を構成した時に指定されたメモリマップと異なっている場合、プロセッサ６０を再構成することなく、またリンカを再構築することなく、付加的なリンカスクリプトを後で発生させることができることである。このように、この実施形態は、異なるメモリマップパラメータを備えた新しいリンカスクリプトを構成するツールを含んでいる。

一度に１つの命令の実行をシングルステップ化し、ブレークポイントを導入し、また他の標準デバッギングタスクを遂行するために、デバッガ１３０はプログラムを実施するにつれてのプログラムの状態を観察するための機構を提供する。デバッギングされるプログラムは、構成されたプロセッサのハードウエアインプリメンテーション、あるいはＩＳＳ１２６のいずれに対しても実施することができる。デバッガはいずれの場合にもユーザに対して同じインターフェイスを呈する。ハードウエアインプリメンテーションに対してプログラムを実施する場合、ユーザのプログラム実行を制御し、シリアルポートを介してデバッガと通信するために、小さなモニタプログラムがターゲットシステムに含まれる。シミュレータ１２６に対してプログラムを実施する場合、シミュレータ１２６自体がこれらの機能を果たす。デバッガ１３０は幾つかの方法でこの構成に依存している。デバッガ１３０内からの分解機コードをサポートする為に、デバッガ１３０は上述の命令符号化・復号化ライブラリと接続される。どのレジスタがプロセッサ６０に存在するかを見出すために、ＩＳＡ記述をスキャンすることによってプロセッサのレジスタ状態を表示するデバッガ１３０の部分、及びデバッガ１３０に対して情報を提供するデバッグモニタプログラムとＩＳＳ１２６の部分が生成される。

他のソフトウエア開発ツール３０は標準型であり、各プロセッサ構成のために変更する必要はない。プロファイルビューア及び様々なユティリティプログラムがこのカテゴリに含まれる。プロセッサ６０の全ての機器構成が共有するバイナリフォーマットでのファイルに対して作動するために、これらのツールをもう一度目標とすることが必要であるかもしれないが、これらのツールはＩＳＡ記述あるいは構成仕様書１００内の他のパラメータのいずれにも依存しない。

構成仕様書はまた、図１３に示すＩＳＳ１２６と呼ばれるシミュレータを構成するためにも使用される。ＩＳＳ１２６は構成可能なプロセッサ命令セットの機能的な行動をモデル化するソフトウエアアプリケーションである。Ｓｙｎｏｐｓｙｓ ＶＣＳやＣａｄｅｎｃｅ Ｖｅｒｉｌｏｇ ＸＬやＮＣシミュレータ等のその対応するプロセッサハードウエアモデルシミュレータとは異なり、ＩＳＳ ＨＤＬモデルはその命令実行中はＣＰＵの抽象化である。ＩＳＳ１２６は各ゲートに対して各信号の推移をモデル化する必要がなく、また完全なプロセッサ設計に登録する必要もないので、ハードウエアシミュレーションよりはるかに早く実行する。

ＩＳＳ１２６はホストコンピュータに対して実行すべき、構成されたプロセッサ６０のためにプログラムを生成できるようにする。ＩＳＳ１２６はプロセッサのリセットを正確に再生し、デバイスドライバ等の低レベルのプログラムや初期化コードを展開させる行動を遮る。固有のコードを埋め込まれたアプリケーションに接続する場合に、これは特に有用である。

実際の埋め込まれたターゲットにコードをダウンロードする必要なしに、構造上の仮定やメモリオーダリング上の問題点等の潜在的な問題を特定するためにＩＳＳ１２６を使用することができる。

この実施形態では、ＩＳＳセマンティクスは、命令を機能に変えるＣオペレータ構築ブロックを構築するために、Ｃのような言語を原文通りに使用するものとして表される。例えば、割込みレジスタやビット設定・割込みレベル・ベクトル等の割込みに関する初歩の機能性は、この言語を使用してモデル化される。

構成可能なＩＳＳ１２６は、システム設計及び確証プロセスの一部として、以下の４つの目的または目標のために使用される：
- ハードウエアが利用できるようになる前にソフトウエアアプリケーションをデバッギングすること；
- システムソフトウエア（例えば、コンパイラ及びオペレーティングシステム成分）のデバッギング；
- ハードウエア設計検証のためにＨＤＬシミュレーションと比較すること。ＩＳＳはＩＳＡのリファレンスインプリメンテーションとして作用し、ＩＳＳ及びプロセッサＨＤＬは共に、プロセッサ設計検証中に診断法及びアプリケーションのために実行され、両者からのトレースが比較される；及び- ソフトウエアアプリケーション性能の分析（これは構成プロセスの一部であってもよいし、あるいはプロセッサ構成が選択された後で同調する更なるアプリケーションのために使用されてもよい）。

全ての目標にとって、構成可能なアッセンブラ１１０及びリンカを備えて作り出されるプログラムをＩＳＳ１２６がロード・デコードできることが必要である。また命令のＩＳＳ実行が、対応するハードウエア実行及びコンパイラの予測に対して意味論的に同等であることも必要である。これらの理由のために、ＩＳＳ１２６は、ハードウエア及びシステムソフトウエアを定義するために使用される同じＩＳＡファイルから、そのデコード・実行行為を引き出す。

上記した最初と最後の目標にとって、ＩＳＳ１２６が可及的に速く必要な精度に達することが重要である。従って、ＩＳＳ１２６はシミュレーションの詳細レベルの動的制御を可能にする。例えば、キャッシュの詳細は必要とされない限りモデル化されず、キャッシュモデリングを動的にオン・オフに切り替えることができる。更に、実行時間にＩＳＳ１２６がほとんど構成に依存した所作選択をしないようにＩＳＳ１２６をコンパイルする前に、ＩＳＳ１２６の部分（例えば、キャッシュ及びパイプラインモデル）が構成される。

上記した最初と最後の目標にとって、設計（ターゲット）下で、システムにとってオペレーティングシステムサービスがＯＳから利用できない場合、ＩＳＳ１２６がアプリケーションに対してこれらのサービスを提供することが重要である。また、それがデバッギングプロセスの関連する部分である場合、これらのサービスがターゲットＯＳによって提供されることが重要である。この方法で、システムはＩＳＳホストとシミュレーションターゲット間でこれらのサービスを柔軟に動かすための設計を提供する。現在の設計はＩＳＳ動的制御（ＳＹＳＣＡＬＬ命令のトラッピングはオン・オフを切り替えてもよい）と、ホストＯＳサービスを要求するための特別なＳＩＭＣＡＬＬ命令の使用との組み合わせに頼っている。

最後の目標は、ＩＳＳ１２６がＩＳＡによって指定されるレベル以下であるプロセッサとシステムの行動のうち、一部の局面をモデル化することを必要とする。特に、ＩＳＳキャッシュモデルは、機器構成データベース１００からパラメータを抽出するパール（Ｐｅｒｌ）スクリプトからのモデルのためにＣコードを発生させることによって構成される。更に、命令のパイプライン行動の詳細（例えば、レジスタの使用及び機能ユニットの利用可能性要件に基づくインタロック）も、機器構成データベース１００から引き出される。現在のインプリメンテーションでは、特殊なパイプライン記述ファイルがリスプ状のシンタックス内のこの情報を指定する。

三番目の目標は割込み行動の正確な制御を必要とする。この目的のために、ＩＳＳ１２６内の特殊な非構造的レジスタを使用して、割込み可能を抑制する。

ＩＳＳ１２６はその使用のために異なる目標をサポートするために幾つかのインターフェイスを提供する。

- バッチまたはコマンドラインモード（一般的に最初と最後の目標との関連で使用される）；
- コマンドループモード、これは非象徴的なデバッグ能力、例えば、ブレークポイント・ウォッチポイント・ステップ等、４つ全ての目標のために頻繁に使用されるデバッグ能力を提供する；及び
- 実行バックエンドとして、ＩＳＳ１２６がソフトウエアデバッガにより使用されるようにするソケットインターフェイス（これは特定の選択された構成のためにレジスタ状態を読み取り、書き込むように構成されなければならない）；
- 非常に詳細なデバッギング及び性能分析を可能にするスクリプタブルインターフェイス。特に、このインターフェイスは異なる構成に対してアプリケーション行動を比較するために使用されてもよい。例えば、どのブレークポイントにおいても、１つの構成に対するランからの状態を別の構成に対するランからの状態と比較してもよいし、あるいは１つの構成に対するランからの状態を別の構成に対するランからの状態に移行させてもよい。

またシミュレータ１２６は手動でコード化され、自動発生された部分を有している。ＩＳＡ記述言語から発生されるテーブルから作成される命令デコード及び実行を除いて、手動でコード化された部分は従来よりのものである。これらのテーブルは実行すべき命令ワードに見出される一次的操作符号から開始し、その分野の値でテーブルへと索引付けし、一片の操作符号、つまり、他の操作符号の点から定義されていない操作符号が見つかるまで続けることによって、命令を復号化する。次に、テーブルはその命令に対するセマンティクス宣言書において指定されるＴＩＥコードから翻訳されたコードに対するポインタを与える。このコードは命令をシミュレートするために実行される。

ＩＳＳ１２６はシミュレートされているプログラムの実行をプロファイルすることができる。このプロファイリングは業界で公知のプログラムカウンタサンプリング技術を使用する。定期的な間隔で、シミュレータ１２６はシミュレートされているプロセッサのＰＣ（プログラムカウンタ）をサンプリングする。シミュレータ１２６は各コード領域におけるサンプル数でヒストグラムを構築する。またシミュレータ１２６は、１つのコール命令がシミュレートされる度にカウンタを増分することによって、コールグラフ内の各エッジが実行される回数をカウントする。シミュレーションが完了すると、シミュレータ１２６は、標準のプロファイルビューアによって読み出すことができるフォーマットで、ヒストグラム及びコールグラフのエッジカウントの両方を含む出力ファイルを書く。シミュレートされているプログラム１１８は（標準のプロファイリング技術におけるように）計測コードで修正する必要がないので、プロファイリングオーバーヘッドはシミュレーション結果に影響を及ぼさないし、プロファイリングは全く非侵略的である。

システムがハードウエアプロセッサエミュレーション及びソフトウエアプロセッサエミュレーションを利用できるようにすることが好ましい。この目的のために、本実施形態はエミュレーションボードを提供する。図６に示すように、エミュレーションボード２００は、ハードウエア内でプロセッサ構成６０をエミュレートするために、Ａｌｔｅｒａ Ｆｌｅｘ １０Ｋ２００Ｅ等の複合プログラム可能論理装置２０２を使用する。一旦システムにより発生されたプロセッサネットリストでプログラムされると、ＣＰＬＤ装置２０２は機能的に最終的なＡＳＩＣ製品と同等になる。それは他の（ＩＳＳ１２６またはＨＤＬ等の）シミュレーション方法よりはるかに高速で稼動し、周期的に正確である、プロセッサ６０の物理的実用化を利用できるという利点を提供する。しかしながら、それは最終的なＡＳＩＣ装置が達成することができる高周波数ターゲットには達することができない。

このボードはデザイナが様々なプロセッサ構成オプションを評価でき、ソフトウエア展開及びデバッギングを設計サイクルの初期に開始できるようにする。それはまたプロセッサ構成の機能的検証のためにも使用することができる。

平易なソフトウエア展開、デバッギング及び検証を許すために、エミュレーションボード２００はそれに対して利用できる幾つかの資源を有している。これらの資源には、ＣＰＬＤ装置２０２自体、ＥＰＲＯＭ２０４、ＳＲＡＭ２０６、同期ＳＲＡＭ２０８、フラッシュメモリ２１０及び２つのＲＳ２３２シリアルチャネル２１２が含まれる。シリアルチャネル２１２はユーザプログラムをダウンロードしてデバッギングするために、ＵＮＩＸ（登録商標）またはＰＣホストに対する通信リンクを提供する。ＣＰＬＤネットリストを考慮して、装置の機器構成ポート２１４に対する専用シリアルリンクを通して、あるいは専用機器構成ＲＯＭ２１６を通して、プロセッサ６０の構成がＣＰＬＤ２０２へとダウンロードされる。

ボード２００に対して利用できる資源もある程度まで構成可能である。容易に変更可能であるプログラム可能論理装置（ＰＬＤ）２１７を通してマッピングが行われるので、ボード上の様々なメモリ要素のメモリマップを容易に変更することができる。更に、プロセッサコアが利用するキャッシュ２１８及び２２８は、より大きな記憶装置を使用して、キャッシュ２１８及び２２８に接続されるタグバス２２２及び２２４を適当な大きさに分けることによって拡張可能である。

特定のプロセッサ構成をエミュレートするためのボードの使用は幾つかのステップを含む。第１のステップはプロセッサの特定の構成を記述する一組のＲＴＬファイルを入手することである。次のステップは多数の商業的統合ツールを使用して、ＲＴＬ記述からゲートレベルのネットリストを統合することである。１つのこのような例はＳｙｎｏｐｓｙｓからのＦＰＧＡエクスプレスである。次にゲートレベルのネットリストを使用して、業者により典型的に提供されるツールを用いてＣＰＬＤインプリメンテーションを入手できる。このようなツールの１つは、アルテラ社（Altera Corporation）のＭａｘｐｌｕｓ２である。最後のステップは、再びＣＰＬＤ業者により提供されるプログラマを使用して、エミュレーションボードのＣＰＬＤチップ上にインプリメンテーションをダウンロードすることである。

エミュレーションボードの目的の１つはデバッギング目的のために迅速なプロトタイプ実用化をサポートすることであるので、前のパラグラフにおいて概説されたＣＰＬＤ実用化プロセスが自動的であることが重要である。この目的を達成するために、１つのディレクトリに全ての関連ファイルをグループ分けすることによって、ユーザに配送されるファイルがカストマイズされる。そして、完全にカストマイズされた統合スクリプトが提供され、顧客が選択した特定のＦＰＧＡ装置に特定のプロセッサ構成を統合することができる。業者ツールによって使用される完全にカストマイズされた実用化スクリプトも発生される。このような統合及び実用化スクリプトは、最適の性能で機能的に正しい実用化を保証する。特定のプロセッサ構成に関連する全てのＲＴＬファイルを読み込むために、スクリプト内に適切なコマンドを含むことにより、またプロセッサ構成内のＩ／Ｏ信号に基づいてチップピンの位置を割り当てるための適当なコマンドを含むことにより、またゲート型クロックにおけるようなプロセッサ論理のある重大な部分のために特定の論理実用化を入手するためのコマンドを含むことにより、機能的な正確さが達成される。更に、このスクリプトは、全てのプロセッサＩ／Ｏ信号に詳細なタイミング制限を割り当てることにより、またある重大な信号の特殊処理により、実用化の性能を改善する。タイミング制限の１つの例は、ボード上の１つの信号の遅延を考慮することによって、その信号に対して特定の入力遅延を割り当てることである。重大な信号処理の例は、ＣＰＬＤチップに対して低クロックスキューを達成するために、専用グローバルワイヤに対してクロック信号を割り当てることである。

好ましくは、該システムは構成されたプロセッサ６０用の検証スイートも構成する。マイクロプロセッサのような複雑な設計の検証のほとんどは以下のような流れで構成される：
━ 設計を刺激し、テストベンチ内で、またはＩＳＳ１２６のような外部モデルを使用して出力を比較するために、テストベンチを構築する；
━ 刺激を発生させるための診断法を書き込む；
━ 制限された状態の機械カバレッジＨＤＬのラインカバレッジ、下降するバッグ率、設計上移動するベクトルの数等のスキームを使用して、検証カバレッジを測定する；そして
━ そのカバレッジが充分でなければ、更に診断法を書き込み、おそらく診断法を発生させるためのツールを使用して、更に設計を実行する。

本発明は幾分似たような流れを使用するが、設計の構成可能性を説明するために、この流れの全ての成分を修正する。この方法論は以下のステップより成る：
━ 特定の構成用のテストベンチを構築する。テストベンチの構成はＨＤＬのために記述したのと同様のアプローチを使用し、その中で支持される全てのオプション及び拡張、つまり、キャッシュサイズ、バスインターフェイス、クロッキング、及び割込み発生等をサポートする；
━ ＨＤＬの特定の構成に対してセルフチェッキング診断法を実行する。診断法自体は特定のハードウエア部品に適応するように構成できる。どの診断法を実行するかの選択も構成に応じて行う。

━ 擬似乱数的に発生された診断法を実行し、ＩＳＳ１２６に対する各々の命令実行後のプロセッサ状態を比較する；そして
━ 機能的カバレッジと共にラインカバレッジを測定するカバレッジツールを使用した、検証カバレッジの測定。更に、非合法的な状態を探すために、その診断法に沿ってモニタ及びチェッカを動かす。これらは全て、特定の構成仕様用に構成可能である。

全ての検証成分が構成可能である。構成可能性はＴＰＰを使用して実用化される。

テストベンチは、構成されたプロセッサ６０が置かれるシステムのＶｅｒｉｌｏｇ（登録商標）モデルである。本発明の場合、これらのテストベンチは以下のものを含む：
━ キャッシュ、バスインターフェイス及び外部メモリ；
━ 外部割込み機構及びバスエラー発生；
━ クロック発生。

上記特徴のほとんど全てが構成可能であるので、テストベンチ自体は構成可能性をサポートする必要がある。そこで、例えば、キャッシュサイズ及び外部割込み機構の数は構成に基づいて自動的に調節される。

テストベンチはテスト中の装置、プロセッサ６０に刺激を提供する。それはメモリ内に予めロードされるアッセンブリレベルの命令を（診断法から）提供することによって行われる。更にテストベンチはプロセッサ６０の行動、例えば割込み、を制御する信号を発生させる。また、これらの外部信号の周波数及びタイミングは制御可能であり、テストベンチによって自動的に発生される。

診断法には２つのタイプの構成可能性がある。まず第一に、診断法はＴＰＰを使用して何をテストするかを決定する。例えば、ソフトウエア割込みをテストするために１つの診断法が書かれている。この診断法は正しいアセンブリコードを発生させるために、幾つのソフトウエア割り込みがあるかを知っている必要がある。

第二に、プロセッサ構成システム１０はこの構成にとってどの診断法が適しているかを決定しなければならない。例えば、ＭＡＣユニットをテストするために書かれた診断法は、このユニットを含んでいないプロセッサ６０に対しては適用できない。本実施形態では、これは各診断法についての情報を含むデータベースの使用を通して実施される。データベースは各診断法に対して、以下の情報を含んでいてよい：
━ 或るオプションが選択された場合、その診断法を使用する；
━ その診断法は割込みがあれば実行できないかどうか；
━ その診断法は実行するのに特別なライブラリまたはハンドラを必要とするか否か；及び
━ ＩＳＳ１２６とのコシミュレーションがあればその診断法を実行できないかどうか。

好ましくは、プロセッサハードウエア記述は３つのタイプのテストツール：テスト発生器ツール、モニタ及びカバレッジツール（またはチェッカ）及びコシミュレーション機構を含む。テスト発生器ツールとは、知的方法で一連のプロセッサ命令を作り出すツールである。これらのツールは擬似乱数的なテスト発生器のシーケンスである。本実施形態は内部的に２つのタイプ：特別に展開されたＲＴＰＧと呼ばれるものと、ＶＥＲＡ（ＶＳＧ）と呼ばれる外部ツールに基づくものを使用する。両者共そのまわりに作られる構成可能性を有する。１つの構成に対する有効な命令に基づいて、それらは一連の命令を発生させる。これらのツールはＴＩＥから新たに定義された命令を処理することができ、これらの新たに定義された命令がテスト用に無作為に発生される。本実施形態は設計検証のカバレッジを測定するモニタ及びチェッカを含む。

モニタ及びカバレッジツールは、リグレッションランと並んで動かされるツールである。カバレッジツールは診断法が何をしているか、それが働かせているＨＤＬの機能及び論理をモニタする。この情報の全てがリグレッションランを通して集められ、後で分析されて、論理のどの部分が更にテストを必要としているかに関するヒントを得る。本実施形態は構成可能である幾つかの機能的カバレッジツールを使用する。例えば、特定の制限された状態の機械にとって、構成に応じて必ずしも全ての状態が含まれているとは限らない。従って、その構成に対して、機能的カバレッジツールはこれらの状態または遷移をチェックしようとしてはならない。これはＴＰＰを通してツールを構成可能にすることによって達成される。

同様に、ＨＤＬシミュレーション内で発生する非合法的な条件をチェックするモニタがある。これらの非合法的状態はバグとして現れ得る。例えば３状態バス上で、２つのドライバが同時にオンになるべきではない。これらのモニタは構成可能であり、その構成のために特定の論理が含まれているか否かに基づいてチェックを追加または除去する。

コシミュレーション機構はＨＤＬをＩＳＳ１２６に接続する。命令の終りにプロセッサ状態がＨＤＬ及びＩＳＳ１２６において同じであることをチェックするために、このコシミュレーション機構が使用される。更に、各構成にどのような特徴が含まれているか、また比較のためにどのような状態が必要であるかを知る程度まで、このコシミュレーション機構は構成可能である。従って、例えば、データブレークポイント特徴が特殊なレジスタを追加する。この機構はこの新しい特殊なレジスタを比較するために知っていることが必要である。

ＩＳＳ１２６において使用するために、またテスト及び検証のために使用するためのシステムデザイナのために、ＴＩＥを介して指定される命令セマンティクスを機能的に同等のＣ関数に翻訳することができる。機器構成データベース１０６内の命令セマンティクスは、標準のパーサツールを使用してパーサツリーを作るツールによってＣ関数に翻訳され、次にそのツリーを歩き、Ｃ言語で対応する表現を出力するコードに翻訳される。その翻訳は全ての表現にビット幅を指定し、構文解析木を書き直して一部の翻訳を簡略化するためにプレパスを必要とする。これらの翻訳機構は、ＨＤＬからＣへの、あるいはＣからアッセンブリ言語コンパイラへの他の翻訳機構に比べて比較的簡単であり、ＴＩＥ及びＣ言語仕様書から始めて、当業者により書き換えることができる。

機器構成ファイル１００及びアッセンブラ／逆アセンブラ１００を用いて構成されるコンパイラを使用して、ベンチマークアプリケーションソースコード１１８が編纂されて組み付けられ、サンプルデータセット１２４を使用してシミュレートされてソフトウエアプロファイル１３０を入手し、このソフトウエアプロファイル１３０はユーザへのフィードバックのためにユーザ構成捕捉ルーチンにも設けられる。

どの構成パラメータ選択に対してもハードウエア及びソフトウエア両方のコスト／利益特性記述を得る能力を有することで、デザイナによるシステムの更なる最適化の新たな機会が開かれる。特に、これはデザイナが最適の構成パラメータを選択できるようにし、最適の構成パラメータはある長所の形式に従ってシステム全体を最適化する。１つの可能なプロセスは、構成パラメータを繰り返し選択する、あるいは選択を解除することによる貪欲な戦略に基づいている。各ステップにおいて、システム全体の性能及びコストに最良の影響を有するパラメータが選択される。システムの性能及びコストを改良するために１つのパラメータも変更できなくなるまでこのステップが繰り返される。他の拡張は、一度に一群の構成パラメータを見ること、あるいはより洗練されたサーチアルゴリズムを使用することを含む。

最適の構成パラメータ選択を得ることに加えて、このプロセスは最適のプロセッサ拡張を構成するためにも使用することができる。プロセッサ拡張における多数の可能性のために、拡張候補数を制限することが重要である。１つの技術は、アプリケーションソフトウエアを分析し、システム性能またはコストを改善することができる命令拡張だけを見ることである。

本実施形態による自動化されたプロセッサ構成システムの操作をカバーしてきたので、次にプロセッサマイクロアーキテクチャ構成に対するシステムのアプリケーションの例について説明する。最初の例は画像圧縮に適用された場合の本発明の利点を示している。

モーション評価は、ＭＰＥＧビデオ及びＨ２６３会議用アプリケーションを含む多くの画像圧縮アルゴリズムの重要な成分である。ビデオ画像圧縮は、各フレームのために必要な記憶量を減少させるために、１つのフレームから次のフレームへの類似性を使用しようとする。最も簡単な場合、圧縮すべき画像の各ブロックを基準画像（圧縮される画像のすぐ前または後の画像）の対応するブロック（同じＸ、Ｙ位置）と比較することができる。フレーム間の画像差の圧縮は、個々の画像の圧縮より概してビット効率的である。ビデオシーケンスにおいて、明確な画像特徴はしばしばフレームからフレームへと移動するので、異なるフレーム間の最も近い対応関係はしばしば正確に同じＸ、Ｙ位置にはなく、幾分オフセットしている。画像の重大な部分がフレーム間で移動している場合、その差を計算する前に、その動きを特定し補償することが必要であるかもしれない。この事実は、はっきりした差異のある特徴に対しては、計算された差において使用されるサブ画像内のＸ、Ｙオフセットを含む、連続画像間の差を符号化することによって最も濃厚な表示を達成できることを意味する。画像差を計算するために使用される位置でのオフセットはモーションベクトルと称される。

この種の画像圧縮において最も計算上集中的なタスクは、各ブロックに対して最も適切なモーションベクトルの決定である。モーションベクトルを選択することに対する共通の距離は、圧縮される画像の各ブロックと、前の画像の一組の候補ブロック間のピクセル毎の最も低い平均差を備えたベクトルを見出すためである。候補ブロックは圧縮されるブロックの位置近傍にある全てのブロックのセットである。画像のサイズやブロックのサイズ及び近傍のサイズ全てがモーション推定アルゴリズムの実行時間に影響を及ぼす。

単純なブロックベースのモーション推定は、圧縮すべき画像の各サブ画像を基準画像と比較する。基準画像はビデオシーケンスにおいて被写体像の前にあるか、または後に続いているものであってよい。いずれの場合にも、被写体像がデコンプレッションされる前に、減圧システムにとって基準画像を利用可能であることが知られている。圧縮下の画像の一ブロックを基準画像の候補ブロックと比較することについて下記に説明する。

被写体像内の各ブロックに対して、基準画像内の対応する位置付近でサーチを実施する。通常、画像の各カラー成分（例えばＹＵＶ）が別々に分析される。時には、モーション推定が１つの成分、特に輝度についてのみ実施される。ピクセルごとの平均差はその被写体像と、基準画像のサーチゾーン内にある全ての可能なブロック間で計算される。その差はピクセル値の大きさの差の絶対値である。その平均は一対のブロックにおけるＮ^２のピクセル（Ｎはブロックの寸法）全体の合計に比例する。最も小さい平均ピクセル差を作り出す基準画像のブロックが、被写体像のそのブロックに対するモーションベクトルを限定する。

以下の例は簡単な形態のモーション推定アルゴリズムを示しており、小さな特定用途の機能単位のためにＴＩＥを使用するアルゴリズムを最適化する。この最適化は１０の因数より大きなスピードアップを生じさせ、多くのビデオ用途のためにプロセッサベースの圧縮を実現可能にする。それは高レベル言語でのプログラミングの容易さと、特殊目的のハードウエアの効率とを組み合わせた構成可能なプロセッサの能力を示している。

この例は、古い画像と新しい画像を各々表すために、２つのマトリックス、ＯｌｄＢとＮｅｗＢを使用する。画像のサイズはＮＸとＮＹによって決定される。ブロックサイズはＢＬＯＣＫＸとＢＬＯＣＫＹによって決定される。従って、画像はＮＸ／ＢＬＯＣＫＸ×ＮＹ／ＢＬＯＣＫＹブロックで構成される。１つのブロックのサーチ領域はＳＥＡＲＣＨＸとＳＥＡＲＣＨＹによって決定される。最良のモーションベクトル及び値がＶｅｃｔＸ、ＶｅｃｔＹ及びＶｅｃｔＢに格納される。ベース（基準）のインプリメンテーションによって計算される最良のモーションベクトル及び値がＢａｓｅＸ、ＢａｓｅＹ及びＢａｓｅＢに格納される。これらの値は命令拡張を使用するインプリメンテーションによって計算されるベクトルをチェックするために使用される。これらの基本的な定義は以下のＣコードセグメントにおいてデータ捕捉される。

モーション推定アルゴリズムは３つの入れ子構造のループで構成される。

１．古い画像内の各ソースブロックに対して。

２．ソースブロックの周囲領域内の新しい画像の各目的ブロックに対して。

３．各ピクセルペア間の絶対差を計算する。

このアルゴリズムに対する完全なコードを下記に記す。

基準ソフトウエアインプリメンテーション

基本的なインプリメンテーションが単純である一方、それはこのブロック対ブロック比較の本質的な平行関係の多くを利用し損ねている。構成可能なプロセッサアーキテクチャは、このアプリケーションのかなりのスピードアップを許容するために２つの主なツールを提供する。

第一に、命令セットアーキテクチャはメモリ内の未整列フィールドの急速抽出を可能にするために、強力な漏斗状シフティング基関数を含む。これはピクセル比較の内部ループがメモリから効率的に隣接するピクセル群をフェッチできるようにする。このループは同時に４つのピクセル（バイト）を操作するために書き換えることができる。特に、この例の目的のために、一度に４つのピクセルペアの絶対差を計算するために新しい命令を定義することが望ましい。しかしながら、この新しい命令を定義する前に、このような命令を利用できるようにアルゴリズムを再実用化することが必要である。

この命令の存在が、ループ展開が同様に魅力的になるような内部ループピクセル差計算の改善を許容する。新しい絶対差合計命令と効率的なシフティングを利用するために、内部ループに対するＣコードが書き直される。基準画像の４つの重なり合うブロックの部分を同じループにおいて比較することができる。ＳＡＤ（ｘ、ｙ）は付加された命令に対応する新しい組込み関数である。ＳＲＣ（ｘ、ｙ）は、ＳＡＲレジスタに格納されているシフト量分だけ、ｘとｙの連結状態の右シフトを実施する。

ＳＡＤ命令を使用するモーション推定の高速バージョン

このインプリメンテーションは最後の新規命令をエミュレートするために以下のＳＡＤ関数を使用する。

４バイトの絶対差の合計

この新規インプリメンテーションをデバッグするために、以下のテストプログラムを使用して、モーションベクトルと、新規インプリメンテーションとベースインプリメンテーションによって計算された値とを比較する。

主テスト

この簡単なテストプログラムは開発プロセスを通して使用される。ここで従わなければならない１つの重要な慣例は、エラーが検出された場合、主プログラムが０に復帰しなければならず、その他の場合は１に復帰しなければならないことである。

ＴＩＥの使用が新規命令の急速な特定化を可能にする。構成可能なプロセッサ発生器は、ハードウエアインプリメンテーション及びソフトウエア開発ツールの両方においてこれらの命令を完全に実行することができる。ハードウエア統合は新しい関数のハードウエアデータパスへの最適の統合化を生じさせる。Ｃ及びＣ＋＋コンパイラ、アッセンブラ、象徴的デバッガ、プロファイラ及び正確なサイクルの命令セットシミュレータにおいて、構成可能なプロセッサソフトウエア環境が新しい命令を完全にサポートする。ハードウエアとソフトウエアの急速な再生が、特定用途の命令をアプリケーション加速用の素早く確実なツールにする。

本例は簡単な命令を実行して、４つのピクセルに対して、ピクセル区別化、絶対値及び累算を平行して実施するためにＴＩＥを使用する。この簡単な命令は１１の基本的な操作（従来のプロセスでは、別々の命令を必要とするかもしれない）を１つの原子操作として実施する。以下はその完全な説明である。

この説明は新規命令を定義するのに必要な最低のステップを表している。まず第一に、その命令のために新しい操作符号を定義する必要がある。この場合、新しい操作符号ＳＡＤは、ＣＵＳＴ０のサブ操作符号として定義される。上記のように、ＣＵＳＴ０は以下のように予め定義されている。

ＯＲＳＴはトップレベルの操作符号であり、ＣＵＳＴ０はＯＲＳＴのサブ操作符号であり、次にＳＡＤはＣＵＳＴ０のサブ操作符号であることが容易に解る。この操作符号の階層組織が操作符号スペースの論理的グループ化と管理を許容する。覚えておかなければならない１つの重要な事は、ＣＵＳＴ０（及びＣＵＳＴ１）はユーザが新規命令を付加するために取って置かれる操作符号スペースとして定義されることである。ユーザはＴＩＥ記述の将来の再利用可能性を保証するために、この割り当てられた操作符号スペース内に留まることが好ましい。

このＴＩＥ記述における第２のステップは、新規命令ＳＡＤを含む新規命令クラスを定義することである。これはＳＡＤ命令のオペランドが定義される場合である。この場合、ＳＡＤは３つのレジスタオペランドと、送出先レジスタａｒｒと、ソースレジスタａｒｓ及びａｒｔよりなる。前述のように、ａｒｒは命令のｒフィールドによって索引付けられたレジスタとして定義され、ａｒｓ及びａｒｔは命令のｓ及びｔフィールドによって索引付けられたレジスタとして定義される。

この記述における最後のブロックは、ＳＡＤ命令用の正式の意味論的定義を与える。この記述は組み合わせ論理を説明するために、Ｖｅｒｉｌｏｇ ＨＤＬのサブセットを使用している。ＩＳＳが如何にしてＳＡＤ命令をシミュレートし、如何にして付加的な回路が統合され、構成可能なプロセッサハードウエアに付加されて、新規命令をサポートするかを正確に定義するのがこのブロックである。

次に、ＴＩＥ記述がデバッギングされて、前述のツールを用いて検証される。ＴＩＥ記述の正確さを確証した後、次のステップはハードウエアサイズ及び性能に対する新規命令の影響力を推定することである。上記のように、これは、例えば、Ｄｅｓｉｇｎ Ｃｏｍｐｉｌｅｒ（登録商標）を使用して実施できる。Ｄｅｓｉｇｎ Ｃｏｍｐｉｌｅｒ（登録商標）が完了すると、ユーザは詳細な面積及び速度に関するレポートの出力を見ることができる。

ＴＩＥ記述が正しく効率的であることを確証した後、新しいＳＡＤ命令をサポートする構成可能なプロセッサを構成し組み立てる時である。これは上述のようにＧＵＩを使用して実施される。

次に、モーション推定コードが構成可能なプロセッサ用のコードに編集され、そのプロセッサはそのプログラムの正確さを確証するために、またより重要なことには、その性能を測定するために、命令セットシミュレータを使用する。これは３つのステップ：シミュレータを使用してテストプログラムを実行する、ベースインプリメンテーションだけを実行して命令カウントを得る、そして新しいインプリメンテーションだけを実行して命令カウントを得る、ステップにおいて行われる。

以下は第２のステップのシミュレーション出力である。

以下は最後のステップのシミュレーション出力である。

２つのレポートから、約４倍のスピードアップが発生したことが解る。構成可能なプロセッサの命令セットシミュレータは他の多くの有用な情報を提供できることに注意されたい。

プログラムの正確さ及び性能を確証した後、次のステップは上述のようにＶｅｒｉｌｏｇシミュレータを使用してテストプログラムを実行することである。当業者なら、アペンディクスＣのメイクファイル（アペンディクスＣに関連ファイルも示されている）からこのプロセスの詳細を収集することができるであろう。このシミュレーションの目的は、新しいインプリメンテーションの正確さを更に確証し、またより重要なことは、このテストプログラムをこの構成されたプロセッサ用のリグレッションテストの一部とすることである。

最後に、プロセッサ論理は、例えば、Ｄｅｓｉｇｎ Ｃｏｍｐｉｌｅｒ（登録商標）を使用して統合し、例えばＡｐｏｌｌｏ（登録商標）使用して配置及び経路選択することができる。

本例は、説明を明確かつ簡略にするために、ビデオ圧縮及びモーション推定の簡略化された図を例に取ってきた。実際には、標準の圧縮アルゴリズムには多くの付加的なニュアンスがある。例えば、ＭＰＥＧ２は典型的にモーション推定を行い、サブピクセルの解像度で補正を実施する。ピクセルの２つの隣接した列または縦列を平均化して、その２つの隣接した列または行間の中間の仮想位置に対して補間された一組のピクセルを作り出すことができる。並列したピクセル平均化命令はＴＩＥコードの３つまたは４つのラインで容易に実用化されるので、構成可能プロセッサのユーザが定義する命令はここでも有用である。１つの列内にあるピクセル間の平均化はプロセッサの標準命令セットの効率的な配列操作を使用する。

このように、簡単な絶対差合計命令の組込みは数百ゲートを付加するが、１０因数より大きくモーション推定性能を改善する。この加速は最終的なシステムのコスト及び電力効率におけるかなりの改善を表す。更に、新しいモーション推定命令を含むためのソフトウエア開発ツールの縫い目なしの拡張は、急速なプロトタイピング及び性能分析及び完全なソフトウエアアプリケーション解決法のリリースを許す。本発明の解決法は特定用途のプロセッサ構成を簡単な、確実な、そして完全なものにし、最終的なシステム製品のコスト、性能、機能性及び電力効率の劇的なエンハンスメントを提供する。

機能的なハードウエアユニットの付加に焦点を当てた例として、図６に示した基本的な構成を考えてみよう。この構成はプロセッサ制御機能と、プログラムカウンタ（ＰＣ）と、ブランチセレクションと、命令メモリまたはキャッシュ及び命令デコーダと、主レジスタファイル、バイパスマルチプレクサ、パイプラインレジスタ、ＡＬＵ、アドレス発生器及びキャッシュ用データメモリを含む基本的な整数データパスとを含んでいる。

倍率器論理の存在が「倍率器」パラメータが設定されていることを条件として、ＨＤＬが書き込まれ、図７に示すように、新しいパイプライン段階として倍率器装置が付加される（正確な特例をサポートすべきである場合、特例処理に対する変更が必要であるかもしれない）。もちろん、倍率器を利用するための命令は好ましくは新しいユニットに付随して付加される。

第２の例として、積算・累算ユニット等のデジタル信号プロセッサのために、完全なコプロセッサを図８に示した基本的な構成に付加してもよい。これは、拡張された命令からのレジスタソース及び送出先の復号化と、制御信号に対する適切なパイプライン遅延の付加と、レジスタ送出先論理の拡張と、累積レジスタからの動きに対するレジスタバイパスマルチプレクサ用の制御の追加と、命令結果用の可能なソースとして積算・累算ユニットの包含とを含む、積算・累算演算用の復号化制御信号の追加等のプロセッサ制御の変化を必然的に伴う。それに加えて、それは付加的なアキュムレータレジスタと、積算・累算アレイと、主レジスタソース用のソースセレクトマルチプレクサとを伴う積算・累算ユニットの追加を必要とする。更に、コプロセッサの追加は、累積レジスタからのソースを取り入れるために、累積レジスタからのレジスタバイパスマルチプレクサの延長と、倍率器の結果からのソースを取り入れるために、ロード／アラインメントマルチプレクサの延長とを必然的に必要とする。やはり、システムは好ましくは実際のハードウエアと共に新しい機能ユニットを使用するための命令を付加する。

デジタル信号プロセッサとの関連で特に有用である別のオプションは、浮動小数点ユニットである。例えば、ＩＥＥＥ７５４単精度浮動小数点演算基準を実用化するこのような機能単位を、それにアクセスするための命令と共に付加してもよい。浮動小数点ユニットは、例えば、音声圧縮・減圧等のデジタル信号処理アプリケーションにおいて使用しても良い。

更にシステムのフレキシビリティの別の例として、図９に示した４ｋＢメモリインターフェイスを考えてみよう。本発明の構成可能性を使用して、コプロセッサレジスタ及びデータパスは主整数レジスタファイル及びデータパスより幅広くても狭くても良く、ローカルメモリ幅は、メモリ幅が最も幅広いプロセッサまたはコプロセッサ幅に等しくなるように変化してもよい（読取及び書込みに対するメモリのアドレス指定はそれに従って調節される）。例えば、図１０は同じアレイにアドレス指定するプロセッサ・コプロセッサの組み合わせに対して３２ビットのロード動作と記憶装置をサポートするが、コプロセッサは１２８ビットのロード動作と記憶装置をサポートする、プロセッサ用のローカルメモリシステムを示している。これはＴＰＰコードを使用して実用化できる。

但し、ＳＢｙｔｅｓは、書き込み信号Ｗ１の制御下にデータバスＤ１を用いるバイトアドレスＡ１における幅Ｂ１バイトとして、あるいは対応するパラメータＢ２、Ａ２、Ｄ２、およびＷ２を使用してアクセスされる全メモリサイズである。Ｓｅｌｅｃｔにより定義される一組の信号だけが所定のサイクルにおいて活動している。ＴＰＰコードはメモリバンクのコレクションとしてメモリを実用化する。各バンクの幅は最小のアクセス幅によって与えられ、またバンク数は最大及び最小のアクセス幅の比率によって与えられる。ループ用Ａは各メモリバンク及びその関連する書き込み信号、つまり書き込みイネーブル及び書込みデータを例示するために使用される。ループ用第２は全てのバンクから読み取られたデータを１つのバスに集めるために使用される。

図１１は基本の機器構成にユーザ限定命令を含めた例を示している。この図に示すように、ＡＬＵのものと同様のタイミングとインターフェイスを備えたプロセッサパイプラインに簡単な命令を付加することができる。この方法で付加される命令は如何なる機能停止も特例も発生させてはならず、如何なる状態も含んではならず、２つの正常なソースレジスタ値と命令ワードのみを入力として使用し、１つの出力値だけを発生させなければならない。しかしながら、ＴＩＥ言語がプロセッサ状態を指定する規定を有している場合、このような制限は必要ではない。

図１２はこのシステムの下でのユーザが定義したユニットのインプリメンテーションの別の例を示している。この図に示した機能単位、ＡＬＵの８／１６パラレルデータユニットエクステンション、は以下のＩＳＡコードから発生される。

本発明の別の局面において特に関心のあることは、設計者が定義した命令実行ユニット９６である。なぜなら、これらの修正プロセッサ状態を含むＴＩＥ限定命令が復号化され実行されるのがここにおいてであるからである。本発明のこの局面において、多数の組立てブロックが言語に付加され、新規命令によって読取り・書込みを実施できる付加的なプロセッサ状態を宣言することができる。これらの「状態」ステートメントはプロセッサ状態の付加を宣言するために使用される。宣言はキーワード状態で始まる。状態ステートメントの次のセクションはビット及び状態のサイズと数、及び状態のビットがどのように索引付けられるかを記述する。それに続くセクションは他の記述セクションにおける状態を特定するために使用される状態名である。「状態」ステートメントの最後のセクションはその状態に関連する属性リストである。例えば、

は３つの新しいプロセッサ状態、ＤＡＴＡ、ＫＥＹＣ及びＫＥＹＤを定義する。状態ＤＡＴＡは６４ビット幅であり、ビットは６３から０へと索引付けられる。ＫＥＹＣ及びＫＥＹＤは共に２８ビット状態である。ＤＡＴＡはどのコプロセッサにデータＤＡＴＡが属しているかを指示するコプロセッサ番号属性ｃｐｎを有する。

属性「ａｕｔｏｐａｃｋ」は、ＤＡＴＡの値をソフトウエアツールによって読取り、書き込むことができるように、状態ＤＡＴＡがユーザレジスタファイル内にあるレジスタに自動的に配置されることを示す。

ｕｓｅｒ＿ｒｅｇｉｓｔｅｒセクションは、ユーザレジスタファイル内のレジスタに対する状態のマッピングを示すために定義される。１つのｕｓｅｒ＿ｒｅｇｉｓｔｅｒセクションはキーワードｕｓｅｒ＿ｒｅｇｉｓｔｅｒで始まり、次にレジスタ番号を示す数字が続き、レジスタ上に配置されるべき状態ビットを示す式で終了する。例えば、

は、ＤＡＴＡの下位ワードが第１のユーザレジスタファイルにマッピングされ、上位ワードが第２のユーザレジスタファイルにマッピングされることを明記している。次の２つのユーザレジスタファイルのエントリはＫＥＹＣ及びＫＥＹＤの値を保持するために使用される。明らかに、このセクションにおいて使用される状態情報は、ｓｔａｔｅセクションのものと一致していなければならない。ここで、コンピュータプログラムによって一貫性を自動的にチェックすることができる。

本発明の別の実施形態では、ユーザレジスタファイルエントリに対する状態ビットのこのような割り当ては、ビンパッキングアルゴリズムを使用して自動的に引き出される。更に別の実施形態では、例えば、上向きの互換性を確実にするために、手動及び自動割当の組み合わせを使用することができる。

命令フィールドステートメントｆｉｅｌｄはＴＩＥコードの可読性を改良するために使用される。フィールドは共にグループ分けされ、１つの名前で参照符が付けられる他のフィールドのサブセットまたは連接である。１つの命令における完全なビットセットが最高レベルのスーパーセットフィールドｉｎｓｔであり、このフィールドは更に小さなフィールドに分けることができる。例えば、

は、最高レベルのフィールドｉｎｓｔのサブフィールド（各々ビット８〜１１、１２〜１５）として２つの４ビットフィールド、ｘ及びｙを定義し、ｘ及びｙフィールドの連接として８ビットのフィールドｘｙを定義する。

ステートメントｏｐｃｏｄｅは特殊なフィールドを符号化するための操作符号を定義する。このように定義された操作符号により使用されるオペランド、例えば、レジスタまたは即時定数を指定するための命令フィールドは、まずフィールドステートメントで定義され、次にオペランドステートメントで定義されなければならない。

例えば、

は、前に定義された操作符号ＣＵＳＴ０（４’ｂ０００は４ビット長のバイナリ定数００００を示す）に基づいて、２つの新しい操作符号、ａｃｓ及びａｄｓｅｌを定義する。好ましいコアＩＳＡのＴＩＥ仕様書は、その基本的定義として、以下のステートメントを有する。

このように、ａｃｓ及びａｄｓｅｌの定義は、以下により各々表される命令復号化論理をＴＩＥコンパイラに発生させる。

命令オペランドステートメントｏｐｅｒａｎｄはレジスタ及び即時定数を特定する。しかしながら、オペランドとして１つのフィールドを定義する前に、それは上述のように１つのフィールドとして以前に定義されていなければならない。オペランドが即時定数である場合、その定数の値をオペランドから発生させることができるし、あるいは下記のように定義される、以前に定義された定数表からその定数の値を取り出すことができる。例えば、即時オペランドを符号化するために、ＴＩＥコード

は有符号数字及びオフセットフィールドに格納された数の４倍であるオペランドｏｆｆｓｅｔｓ４を保持する、オフセットという名前の１８ビットフィールドを定義する。ｏｐｅｒａｎｄステートメントの最後の部分は、当業者にとっては自明であるように、組み合せの回路を説明するためのＶｅｒｉｌｏｇ（登録商標）ＨＤＬのサブセットにおける計算を実施するために使用されるサーキットリを実際に説明している。

ここで、ｗｉｒｅステートメントは３２ビット幅のｔという名前の一組の論理回線を定義している。ｗｉｒｅステートメントの後の最初のａｓｓｉｇｎステートメントは、論理回線を駆動する論理信号が右にシフトされたｏｆｆｓｅｔｓ４定数であることを明記しており、第２のａｓｓｉｇｎステートメントはｔの下位１８ビットがｏｆｆｓｅｔフィールドに置かれることを明記している。最初のａｓｓｉｇｎステートメントはｏｆｆｓｅｔの１連接としてｏｆｆｓｅｔｓ４オペランドの値と、そのサインビット（ｂｉｔ１７）の１４の反復及びそれに続く２ビットの左シフトを直接指定している。

１つの定数表オペランドに対して、ＴＩＥコード

は、定数のアレイｐｒｉｍｅを限定するためにｔａｂｌｅステートメントを利用し（テーブル名に続く数字はそのテーブル内の要素の数である）、テーブルｐｒｉｍｅへのインデックスとしてそのオペランドを使用してそのオペランドｐｒｉｍｅ＿ｓを符号化する（索引付けを定義する際にＶｅｒｉｌｏｇ（登録商標）ステートメントを使用することに注意）。

命令クラスステートメントｉｃｌａｓｓは共通のフォーマットでのオペランドに操作符号を関連付ける。ｉｃｌａｓｓステートメントにおいて定義される全ての命令は同じフォーマットとオペランド使用法を有する。命令クラスを定義する前に、その成分を、まずフィールドとして、次に操作符号及びオペランドとして定義しなければならない。例えば、操作符号ａｃｓ及びａｄｓｅｌを定義する前述の例において使用したコード上に構築する際に、付加的なステートメント

は３つのレジスタオペランドａｒｔ・ａｒｓ・ａｒｒ（やはりこの場合も、この定義においてＶｅｒｉｌｏｇ（登録商標）ステートメントを使用することに注意）を定義するためにｏｐｅｒａｎｄステートメントを使用する。次に、ｉｃｌａｓｓステートメント

はオペランドａｄｓｅｌ及びａｃｓが、命令ｖｉｔｅｒｂｉの共通のクラスに属し、それは入力として２つのレジスタオペランドａｒｔ及びａｒｓを取り、レジスタオペランドａｒｒに出力を書き込むことを明記している。

本発明において、命令の状態アクセス情報の指定を許容するために命令クラスステートメント「ｉｃｌａｓｓ」が修正される。それはキーワード「ｉｃｌａｓｓ」で始まり、次に命令クラス名、続いてその命令クラスに属する操作符号のリスト及びオペランドアクセス情報のリストが続き、状態アクセス情報のために新たに定義されたリストで終了する。例えば、

は幾つかの命令クラスと、如何に様々の新規命令がその状態にアクセスするかを定義している。ｉｃｌａｓｓ内の命令によって、その状態が読み取られ、書き込まれ、または修正（読取り及び書込み）されることを示すために、キーワード「ｉｎ」、「ｏｕｔ」及び「ｉｎｏｕｔ」が使用される。この例では、状態「ＤＡＴＡ」は命令「ＬＤＤＡＴＡ」によって読み取られ、状態「ＫＥＹＣ」及び「ＫＥＹＤ」は命令「ＳＴＫＥＹ」によって書き込まれ、「ＫＥＹＣ」と「ＫＥＹＤ」と「ＤＡＴＡ」が命令「ＤＥＳ」によって修正される。

命令セマンティックステートメントｓｅｍａｎｔｉｃはオペランドをコード化するために使用されるＶｅｒｉｌｏｇ（登録商標）の同じサブセットを使用して、１つ以上の命令の所作を説明する。１つのセマンティックステートメントにおいて多数の命令を定義することにより、一部の共通の表現が共有され、ハードウエアインプリメンテーションをより効率的にすることができる。セマンティックステートメントにおいて許容される変数は、ステートメントの操作符号リスト内で定義される操作符号用のオペランドであり、操作符号リスト内で指定される各操作符号用の単ビットの変数である。この変数は操作符号として同じ名前を有し、操作符号が検出された時に１と評価する。それは対応する命令の存在を示すために、計算セクション（Ｖｅｒｉｌｏｇ（登録商標）サブセットセクション）において使用される。

上記コードの第１セクションはＢＹＴＥＳＷＡＰと呼ばれる新しい命令用の操作符号を定義する。

ここで、新しい操作符号ＢＹＴＥＳＷＡＰはＣＵＳＴ０のサブ操作符号として定義される。下記において詳述するＸｔｅｎｓａ（登録商標）の命令セットアーキテクチャ参照マニュアル（Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｒｅｆｅｒｅｎｃｅ Ｍａｎｕａｌ）から、ＣＵＳＴ０が以下のように定義される。

但し、ｏｐ０及びｏｐ２は命令内のフィールドであることが解る。操作符号は典型的に階層的に組織化される。ここで、ＯＲＳＴはトップレベルの操作符号であり、ＣＵＳＴ０はＯＲＳＴのサブ操作符号であり、次にＢＹＴＥＳＷＡＰはＣＵＳＴ０のサブ操作符号である。この操作符号の階層組織は操作符号スペースの論理的グループ分けと管理を許容する。

第２の宣言はＢＹＴＥＳＷＡＰ命令が必要とする付加的なプロセッサ状態を宣言する。

ここで、ＣＯＵＮＴは３２ビット状態として宣言され、ＳＷＡＰは１ビット状態と宣言される。ＴＩＥ言語はＣＯＵＮＴ内のビットが３１から０に索引付けられ、ビット０が最下位ビットであることを明記している。

Ｘｔｅｎｓａ（登録商標） ＩＳＡは、特殊なシステムレジスタをセーブしリストアするために、２つの命令、ＲＳＲとＷＳＲを提供する。同様に、それはＴＩＥ内で宣言される状態をセーブしリストアするために、２つの他の命令、ＲＵＲとＷＵＲ（下記において詳述する）を提供する。ＴＩＥにおいて宣言された状態をセーブ・リストアするために、ＲＵＲとＷＵＲ命令がアクセスすることができるユーザレジスタファイルへのエントリに対して、その状態のマッピングを指定しなければならない。上記コードの以下のセクションがこのマッピングを指定し、

以下の命令がａ２に対するＣＯＵＮＴの値とａ５に対するＳＷＡＰの値をセーブするであろう。

この機構は状態の内容を検証するためにテストプログラムにおいて実際に使用される。Ｃでは、上記２つの命令は以下のように見えるであろう。

ＴＩＥ記述における入れ子セクションは、新規命令ＢＹＴＥＳＷＡＰを含む新規命令クラスの定義である。

但し、ｉｃｌａｓｓはキーワードであり、ｂｓはｉｃｌａｓｓの名前である。次の節はこの命令クラス（ＢＹＴＥＳＷＡＰ）における命令のリストを作成する。ｔｈａｎの後の節はこのクラス内の命令によって使用されるオペランド（この場合、入力オペランドａｒｓと出力オペランドａｒｒ）を指定する。ｉｃｌａｓｓ定義における最後の節は、このクラスにおける命令によってアクセスされる状態を指定する（この場合、命令は状態ＳＷＡＰを読み取り、状態ＣＯＵＮＴを読み取って書き込むであろう）。

上記コードの最後のブロックはＢＹＴＥＳＷＡＰ命令のために正式の意味論的定義を与える。

この記述は組合せ論理を説明するためにＶｅｒｉｌｏｇ ＨＤＬ用のサブセットを使用する。命令セットシミュレータがＢＹＴＥＳＷＡＰ命令をどのようにシミュレートし、付加的なサーキットリがどのように合成されてＸｔｅｎｓａ（登録商標）プロセッサハードウエアに付け加えられ、新しい命令をサポートするかを正確に定義するのがこのブロックである。

本発明において、ユーザ定義状態を実用化する際に、状態に格納されている情報にアクセスするための他の変数と同様に、宣言された状態を使用することができる。式の右手側に現れる状態識別子がその状態からの読取りを示す。状態への書込みは、状態識別子に値または式を割り当てることによって行われる。例えば、以下のセマンティックコードセグメントは命令によって状態がどのようにして読み取られ、書き込まれるかを示している。

コア命令及び構成オプションの選択を介して利用できる命令として、構成可能プロセッサ内で実用化することができる命令の例を説明する目的のために、テンシリカ社（Tensilica、Inc.）のＸｔｅｎｓａ（登録商標）命令セットアーキテクチャ（Instruction Set Architecture）（ＩＳＡ）参照マニュアル、改訂版１．０がここに参照して組み込まれる。更に、このようなユーザ定義命令を実用化するために使用することができるＴＩＥ言語命令の例を示すために、やはりテンシル社の命令エクステンション言語（ＴＩＥ）参照マニュアル、改訂版１．３がここに参照して組み込まれる。

ＴＩＥ記述から、例えば、付属書Ｄに示したものと同じようなプログラムを使用して、命令を実行する新しいハードウエアを発生させることができる。付属書Ｅは組込み関数として新しい命令をサポートするために必要なヘッダファイル用のコードを示している。

構成仕様書を使用して、以下のものを自動的に発生させることができる。

・ プロセッサ６０の命令デコード論理；
・ プロセッサ６０用の非合法的命令検出論理；
・ アッセンブラの特定ＩＳＡ用部分；
・ コンパイラのための特定ＩＳＡ用サポートルーチン；
・ （デバッガにより使用される）デアッセンブラの特定ＩＳＡ用部分；及び・ シミュレータの特定ＩＳＡ用部分。

図１６はこれらのソフトウエアツールの特定ＩＳＡ用部分をどのように発生させるかを示す図である。ユーザが作成したＴＩＥ記述ファイル４００から、ＴＩＥパーサプログラム４１０が幾つかのプログラム用のＣコードを発生させ、ユーザが定義した命令及び状態に関する情報のために、そのプログラムの各々が、ソフトウエア展開ツールの１つ以上によってアクセスされるファイルを作り出す。例えば、プログラムｔｉｅ２ｇｃｃ４２０はｘｔｅｎｓａ−ｔｉｅ．ｈと呼ばれるＣヘッダファイル４７０を発生させ、このファイルは新しい命令用の組込み関数定義を含んでいる。プログラムｔｉｅ２ｉｓａ４３０は動的接続ライブラリ（ＤＬＬ）４８０を発生させ、これはユーザが定義した命令フォーマットに関する情報を含み、（下記に述べるＷｉｌｓｏｎらの出願では、これは効果的にここで論じるエンコード・デコードＤＬＬの組み合わせである）。プログラムｔｉｅ２ｉｓｓ４４０は性能モデル化ルーチンを発生させ、命令セマンティクスを含むＤＬＬ４９０を作り出し、それは、Ｗｉｌｓｏｎらの出願において論じられているように、シミュレータにより使用されるシミュレータＤＬＬを作り出すためにホストコンパイラによって使用される。プログラムｔｉｅ２ｖｅｒ４５０は適切なハードウエア記述言語でユーザが定義した命令に必要な記述５００を作り出す。最後に、プログラムｔｉｅ２ｘｔｏｓ４６０はＲＵＲ及びＷＵＲ命令が使用するセーブ・リストアコード５１０を作り出す。

命令及びそれらがどのようにして状態にアクセスするかについての正確な記述が、既存の高性能マイクロプロセッサ設計にプラグインできる効率的な論理を作り出すことを可能にする。本発明の本実施形態との関連で説明した方法は、特にこれらの新しい命令を処理し、それらは１つ以上の状態レジスタから／へと読み取って、書き込む。特に、本実施形態は文脈上状態レジスタ用のハードウエア論理を如何にして引き出すかを示しており、高性能を達成するための技術として、全てパイプライン方式を使用するマイクロプロセッサインプリメンテーションスタイルのクラス。

図１７に示したようなもの等のパイプライン式インプリメンテーションにおいて、状態レジスタは典型的に何度も重複しており、各々の具体化が特定のパイプライン段階における状態値を表している。本実施形態では、１つの状態が基礎をなすコアプロセッサインプリメンテーションと矛盾しない多数のレジスタのコピーに移される。やはり基礎をなすコアプロセッサインプリメンテーションと矛盾しない方法で、付加的なバイパス及びフォワード論理も発生される。例えば、３つの実行段階よりなるコアプロセッサインプリメンテーションを目標にするために、本実施形態は１つの状態を図１８に示すように接続される３つのレジスタへと移すであろう。このインプリメンテーションでは、各レジスタ６１０〜６３０が３つのパイプライン段階の１つにおける状態値を表す。ｃｔｒｌ−１と、ｃｔｒｌ−２とｃｔｒｌ−３は、対応するフリップフロップ６１０〜６３０においてデータラッチングを可能化するために使用される制御信号である。

基礎をなすプロセッサインプリメンテーションと矛盾なく状態レジスタの多数のコピーを動作させるために、付加的な論理と制御信号が必要である。「矛盾なく」とは、割込みや特例・パイプラインの機能停止などの状態下で、状態が残りのプロセッサと全く同じようにふるまうべきであることを意味する。典型的に、所定のプロセッサインプリメンテーションは様々なパイプライン状態を表す或る信号を限定する。このような信号はパイプライン状態のレジスタを適切に作動させるために必要である。

典型的なパイプライン式インプリメンテーションにおいて、実行ユニットは多数のパイプライン段階よりなる。１つの命令の計算はこのパイプライン内の多数の段階において実施される。命令ストリームは制御論理により方向付けられるようなシーケンスでパイプラインを通って流れる。所定の時間に、パイプラインにおいて実行されるｎ個の命令があってよく、ｎは段階の数である。やはり本発明を使用して実用化できるスーパースカラープロセッサでは、パイプライン内の命令の数はｎ・ｗであってよく、ｗはプロセッサのイシュー幅である。

制御論理の役割は、命令間の依存性に従い、命令間の干渉が散らされることを保証することである。１つの命令が初期の命令により計算されたデータを使用する場合、パイプラインを機能停止させることなく後の命令へとデータを進めるためには特殊なハードウエアが必要である。割込みが発生した場合、パイプライン内の全ての命令を削り、後に再実行することが必要である。１つの命令が必要とするその入力データまたは計算用ハードウエアが利用できないためにその命令を実行できない場合、その命令は機能停止されなければならない。命令を機能停止させる１つの費用効果的な方法は、その第１実行段階でその命令を削り、次のサイクルでその命令を再実行することである。この技術の結果がパイプライン内に無効な段階（バブル）を作り出している。このバブルが他の命令と共にパイプラインを流れる。命令が遂行されるパイプラインの終りで、バブルが捨てられる。

上記の３段階パイプラインの例を使用して、このようなプロセッサ状態の典型的なインプリメンテーションは図１９に示した付加的な論理と接続を必要とする。

正常な状態では、１つの段階で計算された値は、データ依存性により導入されるパイプライン機能停止の数を減少させるために、その値がパイプラインの終りに達するのを待つことなく、直ちに次の命令へと進められるであろう。これは、第１のフリップフロップ６１０の出力を直接セマンティックブロックへと送り、それを次の命令によって直ちに使用できるようにすることによって達成される。割込みや特例等の異常な状態を処理するために、該インプリメンテーションは以下の制御信号、Ｋｉｌｌ＿１、Ｋｉｌｌ＿ａｌｌ、Ｖａｌｉｄ＿３を必要とする。

信号「Ｋｉｌｌ＿１」は、収益のために必要とするデータを有していない等の理由のために、現在第１パイプライン段階１１０にある命令を削らなければならないことを示している。一旦その命令が削られると、次のサイクルにおいて再度試みられるであろう。信号「Ｋｉｌｌ＿ａｌｌ」は、それらの前の命令が特例を発生させたか、または割込みが発生した等の理由のために、現在第１パイプライン段階１１０にある全ての命令を削らなければならないことを示している。信号「Ｖａｌｉｄ＿３」は、現在最後の段階６３０にある命令が有効であるか否かを示している。このような条件は、しばしば第１のパイプライン段階６１０内の命令を削り、パイプラインにバブル（無効な命令）を生じさせた結果である。「Ｖａｌｉｄ＿３」は単に３番目のパイプライン段階における命令が有効であるかバブルであるかを示している。明らかに、有効な命令だけをラッチすべきである。

図２０は状態レジスタを実用化するために必要な付加的な論理及び接続を示している。更に、この状態レジスタインプリメンテーションが上記の要件を満たすように、信号「ｃｔｒｌ−１」、「ｃｔｒｌ−２」、および「ｃｔｒｌ−３」を駆動するための制御論理を如何にして構築するかも示している。以下は図１９に示したような状態レジスタを実用化するために自動的に発生されるサンプルＨＤＬコードである。

上記パイプライン式状態レジスタモデルを使用して、セマンティックブロックがその入力として状態を指定する場合、状態の現在の状態値が入力変数としてセマンティックブロックへと送られる。セマンティックブロックが１つの状態に対する新しい値を発生させるための論理を有している場合、出力信号が作られる。この出力信号はパイプライン式状態レジスタへの次の状態入力として使用される。

本実施形態は多数のセマンティック記述ブロックを許容し、その各々が多数の命令に対する所作を説明する。この無制限の記述スタイルの下で、セマンティックブロックの１つのサブセットだけが所定の状態に対する次の状態出力を作り出すことができる。更に、所定の時間にそれがどの命令を実行しているかに応じて条件付きで、所定のセマンティックブロックが次の状態出力を作り出すこともできる。その結果、全てのセマンティックブロックからの次の状態出力を組み合わせて、パイプライン式状態レジスタに対する入力を形成するために、付加的なハードウエア論理が必要である。本発明の本実施形態では、このブロックがその状態に対する新しい値を作り出したかどうかを示す各セマンティックブロックのために、１つの信号が自動的に引き出される。別の実施形態では、このような信号を、設計者が指定するように残すことができる。

図２０は幾つかのセマンティックブロックｓ１〜ｓｎからの状態の次の状態出力を如何に組み合わせ、状態レジスタに入力するために如何に適切にその１つを選択するかを示している。この図において、ｏｐ１＿１及びｏｐ１＿２は第１のセマンティックブロックに対する操作符号信号であり、ｏｐ２＿１及びｏｐ２＿２は第２のセマンティックブロックに対する操作符号信号である。セマンティックブロックｉの次の状態出力はｓｉである（多数の状態レジスタがある場合、そのブロックに対して多数の次の状態出力がある）。セマンティックブロックｉがその状態に対して１つの新しい値を作り出したことを示す信号がｓｉ＿ｗｅである。信号ｓ＿ｗｅはいずれかのセマンティックブロックがその状態に対して１つの新しい値を作り出すかどうかを示しており、書込みイネーブル信号としてパイプライン式状態レジスタへの入力として使用される。

多数のセマンティックブロックの表現力が１つのセマンティックブロックのものより低くても、それは、典型的に関連する命令を１つのブロックにグループ分けすることにより、より多くの構造化した記述を与える１つの方法を提供する。多数のセマンティックブロックは、命令が実行される更に制限された範囲のために、命令効果のより簡単な分析へと導くことができる。他方、１つのセマンティックブロックが多数の命令の所作を説明することに対して、しばしば多くの理由がある。最も頻繁に、それはこれらの命令のハードウエアインプリメンテーションが共通の論理を共有するからである。多数の命令を１つのセマンティックブロックで説明することは、通常、より効率的なハードウエア設計ハードウエア設計へと導く。

割込み及び特例のために、ソフトウエアが状態の値をデータメモリへとリストアし、データメモリからロードすることが必要である。新しい状態及び新しい命令の正式の記述に基づいて、このようなリストア・ロード命令を自動的に発生させることができる。本発明の本実施形態では、リストア・ロード命令用の論理が２つのセマンティックブロックとして自動的に発生され、それは次に他のブロックと全く同様に、反復的に実際のハードウエアに移すことができる。例えば、以下の状態宣言書から、

以下のセマンティックブロックを発生させて、「ＤＡＴＡ」、「ＫＥＹＣ」、および「ＫＥＹＤ」の値を汎用レジスタに読み込むことができる。

図２１はこの種のセマンティックロジックに対応する論理のブロック線図を示している。入力信号「ｓｔ」を様々な定数と比較して様々な選択信号を形成し、それらはｕｓｅｒ＿ｒｅｇｉｓｔｅｒ仕様書と矛盾しない方法で、状態レジスタから或るビットを選択するために使用される。前の状態宣言書を使用して、ＤＡＴＡのビット３２を第２のユーザレジスタのビット０に配置する。従って、この図においてＭＵＸの第２入力はＤＡＴＡ状態の３２番目のビットに接続されるべきである。

以下のセマンティックブロックを発生させて、状態「ＤＡＴＡ」、「ＫＥＹＣ」、「ＫＥＹＤ」に汎用レジスタからの値を書き込むことができる。

図２２はｉ番目のユーザレジスタのｋ番目のビットに配置される場合の、状態Ｓのｊ番目のビットに対する論理を示している。ＷＵＲ命令内のｕｓｅｒ＿ｒｅｇｉｓｔｅｒ番号「ｓｔ」が「ｉ」である場合、「ａｒｓ」のｋ番目のビットがＳ［ｊ］レジスタ内へとロードされ、他の場合には、Ｓ［ｊ］の元の値が再循環される。更に、状態Ｓのどのビットも再ロードされない場合、信号Ｓ＿ｗｅが可能化される。

ＴＩＥのｕｓｅｒ＿ｒｅｇｉｓｔｅｒ宣言書が、状態宣言書によって定義された付加的なプロセッサ状態から、これらのＲＵＲ及びＷＵＲ命令により使用される識別子へのマッピングを指定して、ＴＩＥ命令とは別個にこの状態を読み取り、書き込む。

付属書ＦはＲＵＲ及びＷＵＲ命令を発生させるコードを示している。

ＲＵＲ及びＷＵＲの主な目的はタスク切替えのためである。多重タスク環境では、或るスケジューリングアルゴリズムに従って、多数のソフトウエアタスクがプロセッサを共有する。活動的である場合、タスクの状態はプロセッサレジスタ内にある。スケジューリングアルゴリズムが別のタスクへの切替えを決定した場合、プロセッサレジスタに保持されている状態がメモリにセーブされ、別のタスクの状態がメモリからプロセッサレジスタへとロードされる。Ｘｔｅｎｓａ（登録商標）命令セットアーキテクチャ（ＩＳＡ）はＩＳＡによって定義される状態を読み取り、書き込むためのＲＳＲ及びＷＳＲ命令を含む。例えば、以下のコードはタスク「メモリにセーブ」の一部である。

また以下のコードはタスク「メモリからリストア」の一部である。

但し、ＳＡＲ、ＬＣＯＵＮＴ、ＬＢＥＧ、ＬＥＮＤはコアＸｔｅｎｓａ（登録商標） ＩＳＡのプロセッサ状態レジスタ部分であり、ＡＣＣＬＯ、ＡＣＣＨＩ、ＭＲ＿０、ＭＲ＿１、ＭＲ＿２、およびＭＲ＿３はＭＡＣ１６ Ｘｔｅｎｓａ（登録商標） ＩＳＡオプションの一部である。（レジスタはパイプラインインターロックを避けるために、ペアでセーブ・リストアされる。）
設計者がＴＩＥで新しい状態を定義する場合、上記の状態と同様に、タスク切替えされなければならない。１つの可能性は、設計者が単にタスクスイッチコード（その一部が上述したものである）の編集に進み、次に上記コードに類似したＲＵＲ／Ｓ３２Ｉ及びＬ３２Ｉ／ＷＵＲ命令を付加することであろう。しかしながら、ソフトウエアが自動的に発生され、構成によって正しい場合、構成可能プロセッサが最も効果的である。このように、本発明は自動的にタスクスイッチコードを増大させる機構を含んでいる。以下のトップラインが上記セーブタスクに付加される。

また以下のラインが上記リストアタスクに付加される。

最後に、メモリ内のタスク状態エリアはユーザレジスタ記憶装置のために割り当てられる付加的なスペースを有していなければならないし、またタスクセーブポインタのベースからのこのスペースのオフセットがアッセンブラ定数ＵＥＸＣＵＲＥＧとして定義される。このセーブエリアは以下のコードによって予め定義されている。

これは次のように変更される。

このコードはユーザレジスタ番号のリストと共に、ｔｐｐ変数＠ｕｓｅｒ＿ｒｅｇｉｓｔｅｒｓがあることに依存する。これは単にあらゆるｕｓｅｒ＿ｒｅｇｉｓｔｅｒステートメントの最初のアーギュメントから作られるリストである。

一部の更に複雑なマイクロプロセッサインプリメンテーションでは、異なるパイプライン状態で１つの状態を計算することができる。これを処理することは、ここで説明するプロセスに幾つかのエクステンション（とはいえ簡単なもの）を必要とする。第１に、セマンティックブロックをパイプライン段階と関連付けることができるようにするために、仕様記述言語を拡張する必要がある。これは幾つかの方法のうちの１つで達成することができる。一実施形態では、関連するパイプライン段階を各セマンティックブロックで明白に指定することができる。別の実施形態では、パイプライン段階の範囲を各セマンティックブロックのために指定することができる。更に別の実施形態では、所定のセマンティックブロック用のパイプライン段階を、必要な計算上の遅延に応じて、自動的に引き出すことができる。

異なるパイプライン段階における状態発生をサポートする際の第２のタスクは、割込み及び特定・機能停止を処理することである。通常これは、パイプライン制御信号の制御下に、適切なバイパス及びフォワードロジックの追加を含む。一実施形態では、状態が発生された時とその状態が使用される時との間の関係を示すために、使用法発生図を発生させることができる。アプリケーション分析に基づいて、適切なフォワードロジックを実用化して、共通の状況を処理することができ、インターロックロジックを発生させて、フォワーディングロジックによって処理されない場合のためにパイプラインを機能停止させることができる。

ベースプロセッサの命令発行論理を修正する方法は、ベースプロセッサにより使用されるアルゴリズムに依存する。しかしながら、概して、ほとんどのプロセッサ用の命令発行論理は、それがシングル・イッシューであろうと、あるいはスーパー・スカラーであろうと、シングルサイクル命令用であろうと、あるいは多重サイクル命令用であろうと、命令が以下の信号を発行するためにテストされることにのみ依存する。

１．命令がその状態をソースとして使用するか否かを各プロセッサ状態成分のために指示する信号；
２．命令がその状態を送出先として使用するか否かを各プロセッサ状態成分のために指示する信号；及び３．命令が機能単位を使用するか否かを各機能単位のために指示する信号。

これらの信号はパイプラインに対する発行及びクロス・イッシューチェックを実施し、パイプライン依存発行論理におけるパイプライン状態を更新するために使用される。ＴＩＥは新しい命令のために信号及びその式を増加させるために全ての必要な情報を含んでいる。

まず第１に、各ＴＩＥ状態宣言書が命令発行論理のために新しい信号が作られるようにする。ｉｃｌａｓｓ宣言に対して第３または第４のアーギュメントに表記される各ｉｎまたはｉｎｏｕｔオペランドまたは状態が、指定されたプロセッサ状態成分に対する第１組の式に対して、第２のアーギュメントに表記される命令に対する命令デコード信号を付加する。

第２に、ｉｃｌａｓｓ宣言に対して第３または第４のアーギュメントに表記される各ｏｕｔまたはｉｎｏｕｔオペランドまたは状態が、指定されたプロセッサ状態成分に対する第２組の式に対して、第２のアーギュメントに表記される命令に対する命令デコード信号を付加する。

第３に、各ＴＩＥセマンティックブロックから作られた論理が新しい機能単位を表し、新しい単位信号が作られ、セマンティックブロックのために指定されたＴＩＥ命令用のデコード信号が共にＯＲされて、第３組の式を形成する。

命令が発せられた時、パイプラインステータスを将来の発行決定のために更新しなければならない。ここでも、ベースプロセッサの命令発行論理を修正する方法は、ベースプロセッサにより使用されるアルゴリズムに依存する。しかしながら、やはり幾つかの一般的な考察が可能である。パイプラインステータスは発行論理に対して以下のステータスを戻さなければならない。

４．各々の発行された命令送出先のために、その結果がバイパスのために利用可能になる時を指示する信号；
５．機能単位が別の命令のために実行可能状態になっていることを、各機能単位のために示す信号。

ここで説明した実施形態は、シングル・イッシュープロセッサであり、設計者が定義する命令が論理計算のシングルサイクルに制限される。この場合、上記のことがかなり簡略化される。機能単位がチェックまたはクロス・イッシューチェックをする必要がなく、如何なるシングルサイクル命令もプロセッサ状態成分を次の命令のためにパイプレディにすることができない。このように、発行式は以下のようになる。

またこの場合、ｓｒｃ［ｉ］ｐｉｐｅｒｅａｄｙ信号が付加的な命令による影響を受けず、またｓｒｃ［ｉ］ｕｓｅが上記において説明したように、記述され修正される第１組の式である。本実施形態では、第４及び第５組の信号を必要としない。マルチサイクルでマルチイッシューである代替実施形態に対しては、各命令が計算をパイプラインで送るサイクル数を与えるために、ＴＩＥ仕様記述を待ち時間仕様記述で増大させるであろう。

第４組の信号は、仕様書に従ってその段階において完了する各命令のために、命令デコード信号を共にＯＲすることによって、各セマンティックブロックパイプ段階において発生されるであろう。

デフォルトによって、発生された論理が完全にパイプライン化され、ＴＩＥ発生機能単位が、１つの命令を受け入れてから１サイクル後に、常にレディになっているであろう。この場合、ＴＩＥセマンティックブロック用の第５組の信号が常に主張される。多数のサイクルに亘ってセマンティックブロック内の論理を再使用する必要がある場合、機能単位がこのような命令によって如何に多くのサイクルで使用されるかを更なる仕様記述が指定するであろう。この場合、その段階において指定されたサイクルカウントで終了する各命令のために、命令デコード信号を共にＯＲすることによって、各セマンティックブロックパイプ段階において第５組の信号が発生されるであろう。

あるいは、更に異なる実施形態において、設計者が結果レディ信号及び機能単位レディ信号を指定するように、それはＴＩＥに対するエクステンションとして残されてもよい。

本実施形態により処理されたコードの例が添付付属書に示されている。簡潔さのために、これらについて詳細に説明しないが、上述の参照マニュアルを再検討すれば、当業者によって容易に理解されるであろう。付属書ＧはＴＩＥ言語を用いた命令の実行例であり、付属書Ｈはこれらのコードを使用するコンパイラのためにＴＩＥコンパイラが発生させるものを示している。同様に、付属書ＩはシミュレータのためにＴＩＥコンパイラが発生させるものを示しており、付属書ＪはユーザアプリケーションにおけるＴＩＥ命令を拡大するマクロのためにＴＩＥコンパイラが発生させるものを示しており、付属書ＫはネイティブモードにおいてＴＩＥ命令をシミュレートするためにＴＩＥコンパイラが発生させるものを示しており、付属書Ｌは付加的なハードウエアのためのＶｅｒｉｌｏｇ ＨＤＬ記述としてＴＩＥコンパイラが発生させるものを示している。また、付属書Ｍは上記のＶｅｒｉｌｏｇ ＨＤＬ記述を最適化して、ＣＰＵ全体のサイズ及び性能に対するＴＩＥ命令のエリア及び速度の影響を推定するために、設計コンパイラスクリプトとしてＴＩＥコンパイラが発生させるものを示している。

上記のように、プロセッサ構成手順を始めるために、ユーザは上述のＧＵＩを介してベースプロセッサ構成を選択することによって開始する。プロセスの一部として、ソフトウエア展開システム３０が組み立てられ、図１に示すようにユーザに送られる。ソフトウエア展開システム３０は、図６において詳細に示される、本発明の別の局面に関する４つの主な成分、つまり、コンパイラ１０８と、アッセンブラ１１０と、命令セットシミュレータ１１２とデバッガ１３０とを含んでいる。

当業者に公知であるように、コンパイラはＣまたはＣ＋＋等の高レベルプログラミング言語で書かれたユーザアプリケーションを特定用途用アッセンブリ言語に変換する。ＣまたはＣ＋＋等の高レベルプログラミング言語はアプリケーションライタが正確に記載するのが容易なフォームでそれらのアプリケーションを記載できるようにするために設計されている。これらはプロセッサによって理解される言語ではない。アプリケーションライタは必ずしも使用されるプロセッサの特殊な特徴について心配する必要はない。多くの異なるタイプのプロセッサに対して、典型的に同じＣまたはＣ＋＋プログラムをほとんど修正なしに使用することができる。

コンパイラはＣまたはＣ＋＋プログラムをアッセンブリ言語に翻訳する。アッセンブリ言語は機械言語により近く、プロセッサによって直接サポートされる。異なるタイプのプロセッサはそれ自体のアッセンブリ言語を有するであろう。各アッセンブリ命令はしばしば１つの機械命令を表すが、その両者は必ずしも同じでなくてもよい。アッセンブリ命令は人間が読むことのできる文字列であるように設計されている。各命令及びオペランドは意味のある名前または簡略記憶であり、人間がアッセンブリ命令を読み、機械によってどの操作が行われるかを容易に理解できるようにする。アッセンブラはアッセンブリ言語から機械言語へと変換する。各アッセンブリ命令文字列はアッセンブラによって１つ以上の機械命令へと効率的に符号化され、機械命令はプロセッサによって直接かつ効率的に実行され得る。

機械コードはプロセッサ上で直接実行することができるが、物理的なプロセッサは常に直ちに利用できるとは限らない。物理的プロセッサの組立ては時間のかかる高価なプロセスである。可能性のあるプロセッサ構成を選択する場合、ユーザは各々の可能性のある選択のために物理的プロセッサを組み立てることができない。その代わりに、ユーザにはシミュレータと呼ばれるソフトウエアプログラムが提供される。シミュレータ、つまり汎用体コンピュータで実行されるプログラム、はユーザが構成したプロセッサでユーザアプリケーションを実行する効果をシミュレートすることができる。シミュレータはシミュレートされたプロセッサのセマンティクスを真似ることができ、また実際のプロセッサが如何に速くユーザのアプリケーションを実行することができるかをユーザに告げることができる。

デバッガはユーザがソフトウエアと対話形式で問題を見出すことができるようにするツールである。デバッガはユーザが対話形式でそのプログラムを実行することができるようにする。ユーザはいつでもプログラムの実行を停止して、そのＣソースコードまたは結果的に生じるアッセンブリコードまたは機械コードを見ることができる。また、ユーザはブレークポイントにおいて、変数またはハードウエアレジスタのどの値も、あるいは全ての値を調べ、または修正することができる。次に、ユーザは実行を、おそらく一度に１つのステートメント、おそらく一度に１つの機械命令を、新しいユーザが選択したおそらく１つのブレークポイントまで続けることができる。

４つ全ての成分１０８、１１０、１１２、および１３０はユーザが定義した命令７５０（図３を参照）を知っている必要があり、またシミュレータ１１２及びデバッガ１３０も付加的にユーザが定義した状態７５２を知っていなければならない。システムは、ユーザのＣ及びＣ＋＋アプリケーションに付加されるイントリンシックを介して、ユーザが定義した命令７５０にユーザがアクセスできるようにする。コンパイラ１０８はユーザが定義した命令７５０のためにイントリンシックコールをアッセンブリ言語命令７３８に翻訳しなければならない。ユーザによって直接書かれたか、またはコンパイラ１０８によって翻訳された時はいつでも、アッセンブラ１１０は新しいアッセンブリ言語命令７３８を取り入れ、それらをユーザが定義した命令７５０に対応する機械命令７４０に符号化しなければならない。シミュレータ１１２はユーザが定義した機械命令７４０をデコードしなければならない。シミュレータ１１２はその命令のセマンティクスをモデル化し、構成されたプロセッサ上での命令の性能をモデル化しなければならない。シミュレータ１１２はユーザが定義した状態の値及び性能の含意をモデル化しなければならない。デバッガ１３０はユーザが定義した命令７５０を含むアッセンブリ言語命令７３８をユーザが印刷できるようにしなければならない。またデバッガ１３０はユーザが定義した状態の値をユーザが調べて修正できるようにしなければならない。

本発明のこの局面では、ユーザはツール、つまりＴＩＥコンパイラ７０２を呼出して、現在可能性のあるユーザが定義したエンハンスメント７３６を処理する。ＴＩＥコンパイラ７０２はユーザアプリケーションをアッセンブリ言語７３８に翻訳するコンパイラ７０８とは異なっている。ＴＩＥコンパイラ７０２は既に組み立てられているベースソフトウエアシステム３０（コンパイラ７０８、アッセンブリ７１０、シミュレータ７１２及びデバッガ７３０）を可能化して、その新しいユーザが定義したエンハンスメント７３６を使用できるようにする成分を組み立てる。ソフトウエアシステム３０の各要素は幾分異なる成分セットを使用する。

図２４はこれらのソフトウエアツールの特定ＴＩＥ部分が如何に発生されるかを示す図である。ユーザが定義したエクステンションファイル７３６から、ＴＩＥコンパイラ７０２は幾つかのプログラム用のＣコードを発生させ、その各々が、ユーザが定義した命令及び状態に関する情報のために、１つ以上のソフトウエア展開ツールによってアクセスされるファイルを作り出す。例えば、プログラムｔｉｅ２ｇｃｃ８００は、ｘｔｅｎｓａ−ｔｉｅ．ｈと呼ばれるＣヘッダファイル８４２（下記に詳述する）を発生させ、それは新しい命令に対する組込み関数定義を含んでいる。プログラムｔｉｅ２ｉｓａ８１０は、動的接続ライブラリ（ＤＬＬ）８４４／８４８を発生させ、これらはユーザが定義した命令フォーマットに関する情報（下記に詳述するエンコードＤＬＬ８４４とデコードＤＬＬ８４８の組み合わせ）を含む。プログラムｔｉｅ２ｉｓｓ８４０は性能モデル化及び命令セマンティクス用のＣコード８７０を発生させ、それは、後述するように、ホストコンパイラ８４６によって使用され、下記に詳述するように、シミュレータ７１２により使用されるシミュレータＤＬＬ８４９を作り出す。プログラムｔｉｅ２ｖｅｒ８５０は適切なハードウエア記述言語でユーザが定義した命令に必要な記述８５０を作り出す。最後に、プログラムｔｉｅ２ｘｔｏｓ８６０は、文脈切替えのために、ユーザが定義した状態をセーブ・リストアするためのセーブ・リストアコード８１０を作り出す。ユーザが定義した状態のインプリメンテーションについての付加的な情報は、前述のＷａｎｇらの出願に見ることができる。

コンパイラ７０８
本実施形態では、コンパイラ７０８はユーザが定義したエンハンスメント７３６のために、ユーザのアプリケーション内のイントリンシックコールをアッセンブリ言語命令７３８に翻訳する。コンパイラ７０８はＧＮＵコンパイラ等の標準コンパイラに見出されるマクロ及びインラインアッセンブリ機構の上で、この機構を実行する。これらの機構に関する更に詳しい情報については、ＧＮＵ Ｃ及びＣ＋＋コンパイラユーザガイド、ＥＧＣＳバージョン１．０．３を参照。

２台のレジスタで操作し、結果を第３のレジスタに戻す新しい命令ｆｏｏを作りたいと望むユーザを考えてみよう。ユーザは特別なディレクトリ内のユーザが定義した命令ファイル７５０に命令記述を置き、ＴＩＥコンパイラ７０２を呼出す。ＴＩＥコンパイラ７０２はｘｔｅｎｓａ−ｔｉｅ．ｈ等の標準の名前を付けたファイルを作り出す。このファイルはｆｏｏについての以下の定義を含んでいる。

ユーザがそのアプリケーションでコンパイラ７０８を呼出した時、ユーザは、コマンドラインオプションを介して、あるいは環境変数を介して、ユーザが定義したエンハンスメント７３６を備えたディレクトリの名前をコンパイラ７０８に告げる。そのディレクトリはｘｔｅｎｓａ−ｔｉｅ．ｈファイル７４２も含んでいる。コンパイラ７０８は、あたかもユーザ自身でｆｏｏの定義を書いたかのように編集されているユーザのＣまたはＣ＋＋アプリケーションプログラム内に、ファイルｘｔｅｎｓａ−ｔｉｅ．ｈを自動的に含める。ユーザはイントリンシックコールをユーザアプリケーション内の命令ｆｏｏに含んでいる。この含まれている定義のために、コンパイラ７０８はこれらのイントリンシックコールを含まれた定義に対する呼出しとして処理する。コンパイラ７０８により提供される標準のマクロ機構に基づいて、コンパイラ７０８は、あたかもユーザがマクロコールではなく、アッセンブリ言語ステートメント７３８を直接書いたかのように、そのマクロｆｏｏに対する呼出しを処理する。つまり、標準のインラインアッセンブリ機構に基づいて、コンパイラ７０８はその呼出しを１つのアッセンブリ命令ｆｏｏに翻訳する。例えば、ユーザはイントリンシックｆｏｏに対する呼出しを含む関数を有しているかもしれない。

コンパイラはユーザが定義したイントリンシックｆｏｏを使用して、その関数を以下のアッセンブリ言語サブルーチンに翻訳する。

ユーザが新しいユーザ定義エンハンスメント７３６のセットを作成する場合、新しいコンパイラを再構築する必要はない。ＴＩＥコンパイラ７０２が単にファイルｘｔｅｎｓａ−ｔｉｅ．ｈ７４２を作成し、それは予め構築されているコンパイラ７８によって、ユーザのアプリケーション内に自動的に包含される。

アッセンブラ７１０
本実施形態では、アッセンブラ７１０がエンコードライブラリ７４４を使用して、アッセンブリ命令７５０を符号化する。このライブラリ７４４に対するインターフェイスは以下の機能を含む：
・ 操作符号の簡略記憶文字列を内部操作符号表現に翻訳する；
・ 機械命令７４０内の操作符号フィールド用の各操作符号のために発生すべきビットパターンを提供する；そして
・ 各命令オペランドに対するオペランド値を符号化し、その符号化されたオペランドビットパターンを機械命令７４０のオペランドフィールドに挿入する。

一例として、イントリンシックｆｏｏを呼出すユーザ関数の以前の例を考えてみよう。アッセンブラは「ｆｏｏ ａ２、ａ２、ａ３」命令を取り入れ、それを１６進数０ｘ６２２３０により表される機械命令に変換する。この場合、上位の６と下位の０は共にｆｏｏに対する操作符号を表し、２、２、３は各々３つのレジスタａ２、ａ２、ａ３を表す。

これらの関数の内部インプリメンテーションはテーブルと内部関数の組み合わせに基づいている。テーブルはＴＩＥコンパイラ７０２によって容易に発生されるが、その表現能力は制限される。例えば、オペランド符号化関数を表す時等、更に柔軟性が必要である場合、ＴＩＥコンパイラ７０２はライブラリ７４４に含まれるべき任意のＣコードを発生させることができる。

再び「ｆｏｏ ａ２、ａ２、ａ３」の例を考えてみよう。全てのレジスタフィールドはレジスタ番号で単に符号化される。ＴＩＥコンパイラ７０２は合法的レジスタ値に対してチェックする以下の関数を作り出し、その値がリーガルである場合、そのレジスタ番号を戻す。

全ての符号化が簡単である場合、符号化関数は必要ではないであろう。１つのテーブルで充分であろう。しかしながら、ユーザはもっと複雑な符号化を選ぶことが許される。ＴＩＥ言語で記述された以下の符号化は、１０２４で割られたオペランドの値である数で、全てのオペランドを符号化する。このような符号化は１０２４の倍数であることが必要な値を密集して符号化するのに有用である。

ＴＩＥコンパイラはオペランド符号化記述を以下のＣ関数に変換する。

そのオペランドにとって可能な値の領域が非常に大きいので、このような符号化のために１つのテーブルを使用することができない。１つのテーブルは非常に大きくなければならないであろう。

エンコードライブラリ７４４の実施形態では、１つのテーブルが内部操作符号表示に対して操作符号簡略記憶文字列を配置する。効率のために、このテーブルは分類されてもよいし、あるいはそれはハッシュテーブルまたは効率的なサーチを許容する他のデータ構造であってもよい。別のテーブルが各操作符号を機械命令のテンプレートに配置し、その操作符号フィールドがその操作符号用の適切なビットパターンに初期化される。同じオペランドフィールドとオペランドエンコードを備えた操作符号が共にグループ分けされる。これらのグループの１つにある各操作符号のために、ライブラリはオペランド値をビットパターンに符号化するための関数と、これらのビットを機械命令内の適切なフィールドに挿入するための別の関数とを含んでいる。別の内部テーブルが各命令オペランドをこれらの関数に対して配置する。結果レジスタ番号が命令のビット１２．．１５に符号化された例を考えてみよう。ＴＩＥコンパイラ７０２は以下の関数を発生させ、それは命令のビット１２．．１５に結果レジスタの値（番号）を設定する。

アッセンブラ７１０を再構築することなく、ユーザが定義した命令を変更できるようにするために、エンコードライブラリ７４４は動的に接続されたライブラリ（ＤＬＬ）として実用化される。ＤＬＬはプログラムがその機能性を動的に伸ばすことができるようにする標準的な方法である。ＤＬＬ処理についての詳細は異なるホストオペレーティングシステムに応じて変化するが、基本的なコンセプトは同じである。ＤＬＬはプログラムコードのエクステンションとして実行中のプログラムに動的にロードされる。ランタイムリンカがＤＬＬと主プログラム間、及びＤＬＬと既にロードされている他のＤＬＬ間の象徴的な関係を決定する。エンコードライブラリまたはＤＬＬ７４４の場合、コードのほんの一部がアッセンブラ７１０に静的に結び付けられる。このコードはＤＬＬをロードすること、予め組み立てられている命令セット７４６用の既存のエンコード情報（これは別のＤＬＬからロードされていてもよい）とＤＬＬ内の情報を組み合わせること、また上述のインターフェイス機能を介してその情報をアクセス可能にすることに対して責任がある。

ユーザが新しいエンハンスメント７３６を作り出す場合、ユーザはエンハンスメント７３６の記述に対してＴＩＥコンパイラ７０２を呼出す。ＴＩＥコンパイラ７０２は内部テーブルと、そのエンコードＤＬＬ７４４を実用化する関数とを定義するＣコードを発生させる。次にＴＩＥコンパイラ７０２はホストシステムコンパイラ７４６（これは構成中のプロセッサではなく、むしろホストに対して実行するコードを編集する）を呼出して、ユーザが定義した命令７５０に対して該エンコードＤＬＬ１４４を作成する。ユーザはユーザが定義したエンハンスメント７３６を含むディレクトリを指摘するフラグまたは環境変数を備えたアプリケーションで、予め組み立てられているアッセンブラ７１０を呼出す。予め組み立てられているアッセンブラ７１０はそのディレクトリ内のＤＬＬ７４４を動的に開く。各アッセンブリ命令に対して、予め組み立てられているアッセンブラ７１０は該エンコードＤＬＬ７４４を使用して操作符号簡略記憶を調べ、機械命令内の操作符号フィールドに対するビットパターンを見つけ、各命令オペランドを符号化する。

例えば、アッセンブラ７１０がＴＩＥ命令「ｆｏｏ ａ２、ａ２、ａ３」を参照する場合、アッセンブラ７１０は１つのテーブルから、「ｆｏｏ」操作符号がビット位置１６〜２３において数字６に訳すことを見る。１つのテーブルから、アッセンブラ７１０は各レジスタ用の符号化関数を見つける。それらの関数はａ２を数字２に符号化し、もう１つのａ２を数字２に、またａ３を数字３に符号化する。１つのテーブルから、アッセンブラ７１０は適当な集合関数を見つける。Ｓｅｔ＿ｒ＿ｆｉｅｌｄがその結果値２を命令のビット位置１２．．１５に置く。同様の集合関数が他の２と３を適宜配置する。

シミュレータ７１２
シミュレータ７１２は幾つかの方法でユーザが定義したエンハンスメント７３６と相互作用する。機械命令７４０を仮定すれば、シミュレータ７１２は該命令を復号化、つまり、該命令を成分操作符号とオペランドに分解しなければならない。ユーザが定義したエンハンスメント７３６のデコーディングはデコードＤＬＬ７４８内の関数を介して行われる（エンコードＤＬＬ７４４とデコードＤＬＬ７４８は実際には１台のＤＬＬであることも可能である）。例えば、ユーザが各々命令ビット１６〜２３におけるエンコーディング０ｘ６、０ｘ１６、０ｘ２６及びビット０〜３における０で、３つの操作符号；ｆｏｏ１と、ｆｏｏ２とｆｏｏ３とを定義する場合を考えてみよう。ＴＩＥコンパイラ７０２は以下のデコード関数を発生させ、それはその操作符号を全てのユーザが定義した命令７５０の操作符号と比較する。

ユーザが定義した多数の命令７５０があるので、全ての可能なユーザ定義命令７５０に対して操作符号を比較することはコストがかかり、そこでＴＩＥコンパイラはその代わりにスイッチステートメントの階層的セットを使用することができる。

デコーディング命令操作符号に加えて、デコードＤＬＬ７４８は命令オペランドをデコードするための関数を含んでいる。これはエンコードＤＬＬ７４４におけるオペランドのエンコーディングと同じ方法で行われる。まず第１に、デコードＤＬＬ７４８は機械命令からオペランドフィールドを抽出するための関数を提供する。前の例を続けて、ＴＩＥコンパイラ７０２は１つの命令のビット１２〜１５から値を抽出するために以下の関数を発生させる。

オペランドのＴＩＥ記述はエンコーディング及びデコーディング両方の仕様記述を含むので、エンコードＤＬＬ７４４がオペランドエンコード仕様記述を使用する一方、デコードＤＬＬ７４８がオペランドデコード仕様記述を使用する。例えば、以下のＴＩＥオペランド仕様記述：

は以下のオペランドデコード関数を作り出す：

ユーザがシミュレータ７１２を呼出す場合、ユーザはユーザが定義したエンハンスメント７３６に対するデコードＤＬＬ７４８を含むディレクトリをシミュレータ７１２に告げる。シミュレータ７１２は適切なＤＬＬを開く。シミュレータ７１２が命令をデコードする時はいつでも、その命令が予め組立てられている命令セット用のデコード関数によってうまくデコードされない場合、シミュレータ７１２はＤＬＬ７４８内のデコード関数を呼出す。

デコードされた命令７５０を仮定すると、シミュレータ７１２はその命令７５０のセマンティクスを解釈してモデル化しなければならない。これは機能的に行われる。全ての命令７５０が対応する関数を有しており、それはシミュレータ７１２が該命令７５０のセマンティクスをモデル化できるようにする。シミュレータ７１２はシミュレートされたプロセッサのあらゆる状態のトラックを内部的に保持している。シミュレータ７１２はプロセッサ状態を更新するか、あるいは尋ねるために固定されたインターフェイスを有している。上述のように、ユーザが定義したエンハンスメント７３６は、ＶｅｒｉｌｏｇのサブセットであるＴＩＥハードウエア記述言語で書かれる。新しいエンハンスメント７３６をモデル化するために、ＴＩＥコンパイラ７０２はハードウエア記述を、シミュレータ７１２が使用するＣ関数に変換する。ハードウエア記述言語の演算子は対応するＣ演算子に直接翻訳される。プロセッサ状態を更新するか、あるいは尋ねるために、状態を読み取るか、または状態を書き込む操作がシミュレータインターフェイスに翻訳される。

本実施形態の一例として、ユーザが２つのレジスタに加えるために１つの命令７５０を作成する場合を考えてみよう。簡略化のためにこの例を選んだ。ハードウエア記述言語で、ユーザは以下のように、追加のセマンティクスを記述するかもしれない：

内蔵されている名前ａｒｒによって示される出力レジスタが、内蔵されている名前ａｒｓとａｒｔによって示される２つの入力レジスタの合計に指定される。ＴＩＥコンパイラ７０２はこの記述を認めて、シミュレータ７１２が使用するセマンテック関数を発生させる。

ハードウエア演算子「＋」はＣ演算子「＋」に直接翻訳される。ハードウエアレジスタａｒｓとａｒｔの読取りがシミュレータ７１２関数呼出し「ａｒ」の呼出しに翻訳される。ハードウエアレジスタａｒｒの書込みがシミュレータ７１２関数「ｓｅｔ＿ａｒ」に対する呼出しに翻訳される。あらゆる命令がプログラムカウンタｐｃを命令のサイズ分だけ明白に増分するので、ＴＩＥコンパイラ７０２は、追加（ａｄｄ）命令のサイズである３だけｓｉｍｕｌａｔｅｄｐｃを増分するシミュレータ７１２関数に対する呼出しを発生させる。

ＴＩＥコンパイラ７０２が呼出されると、ＴＩＥコンパイラ７０２は上述のようにあらゆるユーザ定義命令のためにセマンティック関数を作成する。また関連するセマンティック関数に対する全ての操作符号名を配置するテーブルも作成する。該テーブル及び関数は標準のコンパイラ７４６を使用してシミュレータＤＬＬ７４９内に編集される。ユーザがシミュレータ７１２を呼出すと、ユーザはユーザが定義したエンハンスメント７３６を含むディレクトリをシミュレータ７１２に告げる。シミュレータ７１２は適切なＤＬＬを開く。シミュレータ７１２が呼出される時はいつでも、シミュレータ７１２はプログラム内の全ての命令をデコードして、関連するセマンティック関数に対して命令を配置するテーブルを作成する。マッピングを作成する場合、シミュレータ７１２はＤＬＬを開き、適当なセマンティック関数をサーチする。ユーザ定義命令７３６のセマンティクスをシミュレートする場合、シミュレータ７１２はＤＬＬ内の関数を直接呼出す。

シミュレートされたハードウエアでアプリケーションを実行するのにどの位の時間がかかるかをユーザに告げるために、シミュレータ７１２は命令７５０の性能効果をシミュレートすることが必要である。シミュレータ７１２はこの目的のためにパイプラインモデルを使用する。あらゆる命令が幾つかのサイクルに亘って実行する。各サイクルにおいて、命令は機械の異なる資源を使用する。シミュレータ７１２は全ての命令を平行して実行しようとし始める。多数の命令が同じサイクルにおいて同じ資源を使用しようとすれば、遅い方の命令は資源が自由になるのを待って立ち往生する。遅い方の命令が後のサイクルにおいて、早い方の命令によって書かれた状態を読む場合、遅い方の命令は書かれた値を待って立ち往生する。シミュレータ７１２は各命令の性能をモデル化するために機能的インターフェイスを使用する。あらゆるタイプの命令のために１つの関数が作られる。その関数はプロセッサの性能をモデル化するシミュレータのインターフェイスに対する呼出しを含んでいる。

例えば、簡単な３レジスタ命令ｆｏｏを考えてみよう。ＴＩＥコンパイラは以下のシミュレータ関数を作成するかもしれない：

ｐｉｐｅ＿ｕｓｅ＿ｉｆｅｔｃｈに対する呼出しが、命令が３バイトをフェッチすることを必要としていることをシミュレータ７１２に伝える。ｐｉｐｅ＿ｕｓｅに対する２つの呼出しが、２つの入力レジスタがサイクル１において読み取られることをシミュレータ７１２に伝える。ｐｉｐｅ＿ｄｅｆに対する呼出しが、出力レジスタがサイクル２において書き込まれることをシミュレータ７１２に伝える。ｐｉｐｅ＿ｄｅｆ＿ｉｆｅｔｃｈに対する呼出しが、この命令はブランチではなく、従って次の命令を次のサイクルでフェッチできることをシミュレータ７１２に伝える。

これらの関数に対するポインタがセマンテック関数と同じテーブルに置かれる。関数自体はセマンテック関数と同じＤＬＬ７４９内に編集される。シミュレータ７１２が呼出されると、シミュレータ７１２は命令と性能関数間のマッピングを作成する。マッピングを作成する場合、シミュレータ７１２はＤＬＬ７４９を開いて、適当な性能関数をサーチする。ユーザ定義命令７３６の性能をシミュレートする場合、シミュレータ７１２はＤＬＬ７４９内の関数を直接呼出す。

デバッガ７３０
デバッガはユーザが定義したエンハンスメント７５０と２つの方法で相互作用する。これを実施するために、デバッガ７３０は機械命令７４０をアッセンブリ命令７３８にデコードしなければならない。これは命令をデコードするためにシミュレータ７１２が使用するのと同じ機構であり、デバッガ７３０は好ましくはデコーディングを行うためにシミュレータ７１２が使用するのと同じＤＬＬを使用する。命令のデコーディングに加えて、デバッガはデコードされた命令を文字列に変換しなければならない。この目的のために、デコードＤＬＬ７４８は各々の内部操作符号表示を対応する簡略記憶文字列に配置するための関数を含む。これは簡単なテーブルを用いて実行できる。

ユーザはユーザが定義したエンハンスメント７５０を含むディレクトリを指摘するフラグまたは環境変数を備えた予め組み立てられているデバッガを呼出すことができる。予め組み立てられているデバッガは適当なＤＬＬ７４８を動的に開く。

更に、デバッガ７３０はユーザが定義した状態７５２とも相互作用する。デバッガ７３０はその状態７５２を読み取り、修正できなければならない。それを実施するために、デバッガ７３０はシミュレータ７１２と通信する。デバッガ７３０はシミュレータ７１２に対して、該状態がどの程度の大きさであるか、また該状態変数の名前が何であるかを尋ねる。デバッガ７３０が一部のユーザ状態の値を印刷するように求められた時はいつでも、予め定義されている状態について請求するのと同じ方法で、デバッガ７３０はその値をシミュレータ７１２に尋ねる。同様に、ユーザ状態を修正するために、デバッガ７３０は所定の値に状態を設定するようにシミュレータ７１２に伝える。

このように、本発明によるユーザが定義した命令セット及び状態に対するサポートのインプリメンテーションは、コアソフトウエア展開ツールにプラグインされるユーザ機能性を定義するモジュールを用いて達成することができる。このように、ユーザが定義したエンハンスメントの特定セットのためのプラグインモジュールが、組織及び操作の容易さのために、システム内で１つのグループとして維持されるシステムを開発することができる。

更に、コアソフトウエア展開ツールは特定のコア命令セット及びプロセッサ状態にとって特有のものであってよく、ユーザが定義したエンハンスメント用の一組のプラグインモジュールを、システムに存在する多数組のコアソフトウエア展開ツールとの関連で評価してもよい。

本発明の好ましい実施例による命令セットを実行するプロセッサのブロック図である。 本実施例によるプロセッサで使用されるパイプラインのブロック図である。 本実施例によるＧＵＩの構成マネージャを示している。 本実施例によるＧＵＩの構成エディタを示している。 本実施例による異なる種類の構成可能性を示している。 本実施例のプロセッサ構成のフローを示すブロック図である。 本実施例による命令セットシミュレータのブロック図である。 本実施例により構成されたプロセッサと併用するためのエミュレーションボードのブロック図である。 本実施例による構成可能なプロセッサの論理アーキテクチャを示すブロック図である。 図９のアーキテクチャへの乗算器の付加を示すブロック図である。 図９のアーキテクチャへの乗算−累算装置の付加を示すブロック図である。 本実施例のメモリの構成を示す図である。 本実施例のメモリの構成を示す図である。 図８のアーキテクチャのユーザ定義の機能装置の付加を示す図である。 図８のアーキテクチャのユーザ定義の機能装置の付加を示す図である。 他の好ましい実施例のシステム構成要素間の情報のフローを示すブロック図である。 いかにカスタムコードが本実施例のソフトウエア開発ツールのために生成されるかを示すブロック図である。 本発明の他の好ましい実施例で使用されるいろいろのソフトウエアモジュールの生成を示すブロック図である。 本実施例による構成可能なプロセッサのパイプライン構造のブロック図である。 本実施例によるゲートレジスタインプリメンテーションである。 本実施例で状態レジスタインプリメンテーションを実行するのに必要である付加ロジックの図である。 本実施例によるいろいろのセマンティックブロックおよび選択ブロックから状態レジスタの入力への状態の次の状態出力の結合を示す図である。 本実施例によるセマンティックロジックに対応するロジックを示している。 状態のビットが本実施例のユーザレジスタのビットにマッピングされる場合、状態のビットのためのロジックを示している。

Claims (84)

1. 構成可能なプロセッサを設計するシステムであって、
   ユーザ定義可能な部分を有する構成仕様を生成する手段であって、前記構成仕様の前記ユーザ定義可能な部分が、
   ユーザ定義のプロセッサ状態の仕様と、
   少なくとも１つのユーザ定義の命令およびそれに関連したユーザ定義の機能とを含み、前記機能が、前記ユーザ定義のプロセッサ状態からの読み出しおよび前記ユーザ定義のプロセッサ状態への書き込みの少なくとも１つであることと、
   構成仕様に基づいて前記プロセッサのハードウェアインプリメンテーションの記述を生成する手段とを備えているシステム。
2. ソフトウェア開発ツールは、ソフトウェア開発ツールを発生して、プロセッサ上で実行するためのコードを発生するためのものである請求項１のシステム。
3. 前記プロセッサの前記ハードウェアインプリメンテーションが、命令実行パイプラインを記述し、かつ
   前記制御ロジックが、前記命令実行パイプラインの各段に関連した部分を含む請求項２のシステム。
4. 前記ハードウェアインプリメンテーション記述が、命令実行を打ち切る回路の記述を含み、かつ
   前記制御ロジックが、打ち切られた命令によって前記ユーザ定義の状態の変更を防止する回路を含む請求項３のシステム。
5. 前記制御ロジックが、命令発行、オペランドバイパス、および前記少なくとも１つのユーザ定義の命令のためのオペランド書き込みイネーブルの少なくとも１つを実行する回路を含む請求項４のシステム。
6. 前記ハードウェアインプリメンテーション記述が、複数の段の前記命令実行パイプラインで前記ユーザ定義の状態を実行するレジスタを含む請求項３のシステム。
7. 前記ハードウェアインプリメンテーション記述が、出力オペランドが発生されるパイプライン段とは異なるパイプライン段で記述される状態レジスタを含み、かつ
   前記ハードウェアインプリメンテーションが、前記ユーザ定義のプロセッサ状態への書き込みがコミットされる前にこのような書き込みが前記ユーザ定義のプロセッサ状態を参照する次の命令へバイパスされる請求項３のシステム。
8. 前記構成仕様が、前記ユーザ定義の部分に加えて所定の部分を含み、かつ
   前記仕様の所定の部分が、前記ユーザ定義の状態をメモリに保存することを容易にする命令および前記ユーザ定義の状態をメモリから復元することを容易にする命令を含む請求項１のシステム。
9. 前記命令を使用して前記ユーザ定義の状態をコンテキスト切り換えるソフトウェアを生成する手段をさらに含む請求項８のシステム。
10. 命令設定シミュレータはコードのシミュレーションの実行をモデルにして、実行の周期を含むキーパフォーマンス基準を測定することができる請求項９のシステム。
11. ユーザ定義されたプロセッサの状態と少なくとも１つのユーザ定義された命令とをコンパイルするコンパイラを生成する手段をさらに具備する請求項１のシステム。
12. 命令設定シミュレータはプログラムのシミュレーションの実行をプロファイルして、各シミュレーションされた機能で実行される多数の周期を含む標準プロファイリング統計を記録する請求項１０のシステム。
13. ユーザ定義されたプロセッサ状態と少なくとも１つのユーザ定義された命令とをデバッグするデバッガを生成することをさらに具備する請求項１のシステム。
14. 前記ユーザ定義のプロセッサ状態および前記少なくとも１つのユーザ定義の命令をアセンブルするアセンブラ、前記ユーザ定義のプロセッサ状態および前記少なくとも１つのユーザ定義の命令をコンパイルするコンパイラ、前記ユーザ定義のプロセッサ状態および前記少なくとも１つのユーザ定義の命令をシミュレートするシミュレータ、および前記ユーザ定義のプロセッサ状態および前記少なくとも１つのユーザ定義の命令をデバッグするデバッガの少なくとも１つを生成する手段をさらに含む請求項１のシステム。
15. 前記仕様の前記ユーザ定義の一部が、前記ユーザ定義の状態をサイズおよびインデクシングを指定する少なくとも１つのステートメントを含む請求項１のシステム。
16. 前記仕様の前記ユーザ定義の一部が、前記ユーザ定義の状態に関連し、かつプロセッサレジスタの前記ユーザ定義の状態のパッキングを指定する少なくとも１つの属性を含む請求項１５のシステム。
17. 前記仕様の前記ユーザ定義の一部が、プロセッサレジスタへの前記ユーザ定義の状態のマッピングを指定する少なくとも１つのステートメントを含む請求項１のシステム。
18. ハードウェアインプリメンテーション記述を生成する手段はユーザ定義された状態をプロセッサレジスタへ自動的にマッピングする手段を含む請求項１のシステム。
19. 前記仕様の前記ユーザ定義の一部が、ユーザ定義の命令のクラスおよび前記ユーザ定義の状態に対するその効果を指定する少なくとも１つのステートメントを含む請求項１のシステム。
20. 前記仕様の前記ユーザ定義の一部が、ある値を前記ユーザ定義の状態に割当てる少なくとも１つの割当ステートメントを含む請求項１のシステム。
21. プロセッサの命令セットアーキテクチャ仕様に基づいて、プロセッサに対して特に生成されるコアソフトウェアツールと、
    ユーザ定義の命令仕様に基づいて、コアソフトウェアによって使用されるための少なくとも１つのモジュールを生成して、プロセッサによるユーザ定義の命令の仕様を評価するエンハンスメントツールとを具備する、構成可能なプロセッサを設計するシステム。
22. コアソフトウェアツールは、プロセッサ上で実行するコードを生成することができるソフトウェアツールを具備する請求項２１のシステム。
23. 少なくとも１つのモジュールは、動的に結合されたライブラリとして実現される請求項２１のシステム。
24. 少なくとも１つのモジュールはテーブルとして実現される請求項２１のシステム。
25. コアソフトウェアツールは、少なくとも１つのモジュールを使用して、ユーザ定義の命令を使用し、かつプロセッサにより実行可能なコードにアプリケーションをコンパイルするコンパイラを含む請求項２１のシステム。
26. 少なくとも１つのモジュールは、ユーザ定義の命令をコンパイルする際にコンパイラによって使用されるためのモジュールを含む請求項２５のシステム。
27. コアソフトウェアツールは、少なくとも１つのモジュールを使用して、ユーザ定義の命令を使用し、かつプロセッサにより実行可能なコードにアセンブルするアセンブラを含む請求項２１のシステム。
28. 少なくとも１つのモジュールは、アセンブリ言語命令をユーザ定義の命令にマッピングする際にアセンブラによって使用されるためのモジュールを含む請求項２７のシステム。
29. アセンブラによって使用されるためのモジュールは、操作符号簡略記憶文字列を内部操作符号表現に翻訳するためのデータを含む請求項２８のシステム。
30. アセンブラによって使用されるためのモジュールは、ユーザ定義の命令の操作符号フィールド用に発生すべきビットパターンを特定するためのデータを含む請求項２８のシステム。
31. アセンブラによって使用されるためのモジュールは、ユーザ定義の命令に対応するマシン命令のフィールドにオペランド値をエンコードするためのデータを含む請求項２８のシステム。
32. システムは、非ユーザ定義の命令を指定するコア命令セット仕様をさらに含み、
    コア命令セット仕様は、アプリケーションをプロセッサによって実行可能なコードにアセンブルするアセンブラによって使用される請求項２８のシステム。
33. コアソフトウェアツールは、プロセッサにより実行可能なコードをシミュレートする命令セットシミュレータを含む請求項２１のシステム。
34. 少なくとも１つのモジュールはユーザ定義の命令の実行をシミュレートする際にシミュレータによって使用されるためのシミュレータモジュールを含む請求項３３のシステム。
35. シミュレータにより使用されるためのモジュールは、ユーザ定義の命令を復号化するためのデータを含む請求項３４のシステム。
36. シミュレータは、命令が予め定義された命令として復号化できない場合、前記シミュレータモジュールを使用して命令を復号化するモジュールを使用する請求項３５のシステム。
37. シミュレータによって使用されるためのモジュールは、ユーザ定義の命令のセマンティクスを解釈してモデル化するためのデータを含む請求項３４のシステム。
38. シミュレータによって使用されるためのモジュールはシミュレーションの際に使用するためのユーザ定義された状態を記述するデータを含む請求項３４のシステム。
39. シミュレータによって使用されるためのモジュールはユーザ定義の命令の性能を決定するためのデータを含む請求項３４のシステム。
40. コアソフトウェアツールは、ユーザ定義の命令を使用し、かつプロセッサによって実行可能なコードをデバッグするためにユーザ定義のモジュールを使用するデバッガを含む請求項２１のシステム。
41. 少なくとも１つのモジュールは、マシン命令をアセンブリ命令に復号化するためのデバッガによって使用可能なモジュールを含む請求項４０のシステム。
42. 少なくとも１つのモジュールは、アセンブリ命令をストリングに変換するためのデバッガによって使用可能なモジュールを含む請求項４０のシステム。
43. コアソフトウェアツールは、プロセッサによって実行可能なコードをシミュレートする命令セットシミュレータを含み、
    デバッガは、デバッグするためにユーザ定義された状態の情報を得るため、シミュレータと通信するためのものである請求項４０のシステム。
44. 単一のユーザ定義の命令が、異なるコア命令セット仕様に基づいて複数のコアソフトウェアツールによって変更されないで使用可能な請求項２１のシステム。
45. 構成可能なプロセッサを設計するシステムであって、
    プロセッサの命令セットアーキテクチャ仕様に基づいて、プロセッサに対して特に生成されるコアソフトウェアツールと、
    ユーザ定義の命令仕様に基づいて、コアソフトウェアによって使用されるための少なくとも１つのモジュールを生成して、プロセッサによるユーザ定義の命令の仕様を評価するエンハンスメントツールと、
    エンハンスメントツールによって生成したグループを同時に記憶する記憶手段とを具備し、各グループはユーザ定義の命令の異なる組に対応するシステム。
46. 少なくとも１つのモジュールは動的に結合されたライブラリとして実現される請求項４５のシステム。
47. 少なくとも１つのモジュールはテーブルとして実現される請求項４５のシステム。
48. コアソフトウェアツールは、ユーザ定義の命令モジュールを使用して、アプリケーションをユーザ定義の命令を使用し、かつプロセッサによって実行可能なコードにコンパイルするコンパイラを含む請求項４５のシステム。
49. 少なくとも１つのモジュールは、ユーザ定義の命令をコンパイルする際にコンパイラによって使用するためのモジュールを含む請求項４８のシステム。
50. コアソフトウェアツールは、ユーザ定義のモジュールを使用して、アプリケーションをユーザ定義の命令を使用し、かつプロセッサによって実行可能なコードにアセンブルするアセンブラを含む請求項４５のシステム。
51. 少なくとも１つのモジュールが、アセンブリ言語命令をユーザ定義の命令にマッピングする際にアセンブラによって使用するためのモジュールを含む請求項５０のシステム。
52. エンコードモジュールは操作符号簡略記憶文字列を内部符号表現に翻訳するためのデータを含む請求項５１のシステム。
53. アセンブラによって使用されるためのモジュールは、ユーザ定義の命令の操作符号フィールド用に発生すべきビットパターンを特定するためのデータを含む請求項５１のシステム。
54. アセンブラによって使用されるためのモジュールは、ユーザ定義の命令に対応するマシン命令のフィールドにオペランド値をエンコードするためのデータを含む請求項５１のシステム。
55. コアソフトウェアツールは、プロセッサによって実行可能なコードをシミュレートする命令セットシミュレータを含む請求項４５のシステム。
56. 少なくとも１つのモジュールは、ユーザ定義の命令の実行をシミュレートする際にシミュレータによって使用するためのモジュールを含む請求項５５のシステム。
57. シミュレータによって使用するためのモジュールが、ユーザ定義の命令を復号化するデータを含む請求項５６のシステム。
58. シミュレータは、命令が予め定義された命令として復号化できない場合、シミュレータモジュールを使用して命令を復号化するモジュールを使用する請求項５７のシステム。
59. シミュレータによって使用されるためのモジュールは、ユーザ定義の命令のセマンティクスを解釈してモデル化するためのデータを含む請求項５６のシステム。
60. シミュレータによって使用されるためのモジュールはシミュレーションの際に使用するためのユーザ定義された状態を記述するデータを含む請求項５６のシステム。
61. シミュレータによって使用されるためのモジュールはユーザ定義の命令の性能を決定するためのデータを含む請求項５６のシステム。
62. コアソフトウェアツールが、ユーザ定義の命令を使用し、かつプロセッサによって実行可能なコードをデバッグするためにユーザ定義のモジュールを使用するデバッガを含む請求項４５のシステム。
63. 少なくとも１つのモジュールは、マシン命令をアセンブリ命令に復号化するようにデバッガによって使用可能なモジュールを含む請求項６２のシステム。
64. 少なくとも１つのモジュールが、アセンブリ命令をストリングに変換するようにデバッガによって使用可能なモジュールを含む請求項６２のシステム。
65. 各々のグループが、プロセッサの命令セットアーキテクチャ仕様に基づいて、プロセッサのために特に生成されている、コアソフトウェアツールの複数のグループと、
    ユーザ定義の命令仕様に基づいて、コアソフトウェアによって使用されるための少なくとも１つのモジュールを生成して、プロセッサによるユーザ定義の命令の仕様を評価するエンハンスメントツールとを具備する構成可能なプロセッサを設計するシステム。
66. 少なくとも１つのモジュールは、動的に結合されたライブラリとして実現される請求項６５のシステム。
67. 少なくとも１つのモジュールは、テーブルとして実現される請求項６５のシステム。
68. 少なくとも１つのグループのコアソフトウェアツールは、ユーザ定義の命令モジュールを使用して、アプリケーションをユーザ定義の命令を使用し、かつプロセッサによって実行可能なコードにコンパイルするコンパイラを含む請求項６５のシステム。
69. 少なくとも１つのモジュールは、ユーザ定義の命令をコンパイルする際にコンパイラによって使用するためのモジュールを含む請求項６８のシステム。
70. 少なくとも１つのグループのコアソフトウェアツールが、ユーザ定義のモジュールを使用して、アプリケーションをユーザ定義の命令を使用し、かつプロセッサによって実行可能なコードにアセンブルするアセンブラを含む請求項６５のシステム。
71. 少なくとも１つのモジュールが、アセンブリ言語命令をユーザ定義の命令にマッピングする際にアセンブラによって使用するためのモジュールを含む請求項７０のシステム。
72. 少なくとも１つのグループのコアソフトウェアツールが、プロセッサによって実行可能なコードをシミュレートする命令セットシミュレータを含む請求項７１のシステム。
73. 少なくとも１つのモジュールが、ユーザ定義の命令の実行をシミュレートする際にシミュレータによって使用するためのモジュールを含む請求項７１のシステム。
74. シミュレータによって使用するためのモジュールが、ユーザ定義の命令を復号化するデータを含む請求項７１のシステム。
75. コアソフトウェアツールの少なくとも１つのグループはプロセッサによって実行可能なコードをシミュレーションするための命令セットシミュレータを含む請求項６５のシステム。
76. 少なくとも１つのモジュールはユーザ定義された命令の実行をシミュレーションする際にシミュレータによって使用されるためのモジュールを含む請求項７５のシステム。
77. シミュレータによって使用されるためのモジュールはユーザ定義された命令をデコードするためのデータを含む請求項７６のシステム。
78. シミュレータが、命令が予め定義された命令として復号化できない場合、シミュレータモジュールを使用して命令を復号化するモジュールを使用する請求項７７のシステム。
79. シミュレータによって使用されるためのモジュールは、ユーザ定義の命令のセマンティクスを解釈してモデル化するためのデータを含む請求７６のシステム。
80. シミュレータによって使用されるためのモジュールはシミュレーションの際に使用するためのユーザ定義された状態を記述するデータを含む請求項７６のシステム。
81. シミュレータによって使用されるためのモジュールはユーザ定義の命令の性能を決定するためのデータを含む請求項７６のシステム。
82. 少なくとも１つのグループのコアソフトウェアツールが、ユーザ定義の命令を使用し、かつプロセッサによって実行可能なコードをデバッグするためにユーザ定義のモジュールを使用するデバッガを含む請求項６５のシステム。
83. 少なくとも１つのモジュールが、マシン命令をアセンブリ命令に復号化するようにデバッガによって使用可能なモジュールを含む請求項８２のシステム。
84. 少なくとも１つのモジュールが、アセンブリ命令をストリングに変換するようにデバッガによって使用可能なモジュールを含む請求項８２のシステム。

Images