JP2004500650A - デジタル信号処理の設計、モデル化あるいは実行を行うためのソフトウェア - Google Patents
デジタル信号処理の設計、モデル化あるいは実行を行うためのソフトウェア Download PDFInfo
- Publication number
- JP2004500650A JP2004500650A JP2001554160A JP2001554160A JP2004500650A JP 2004500650 A JP2004500650 A JP 2004500650A JP 2001554160 A JP2001554160 A JP 2001554160A JP 2001554160 A JP2001554160 A JP 2001554160A JP 2004500650 A JP2004500650 A JP 2004500650A
- Authority
- JP
- Japan
- Prior art keywords
- software
- mips
- virtual machine
- cvm
- dsp
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Complex Calculations (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
【課題】デジタル信号処理の設計、モデリングまたは実行を行うためのソフトウェアが通信用ＤＳＰとして最適化されたバーチャル・マシン層を有する。
【解決手段】上記バーチャル・マシン層によって、低ＭＩＰＳ複素コードが、上記バーチャル・マシン層により示されるＡＰＩを用いて高ＭＩＰＳプロセスとインターフェースすることが可能となる。本発明によって、専用ＤＳＰにではなく、バーチャル・マシンにソフトウェアの書込みを行うことが可能となり、製造のいずれか１つのソースから生じるＤＳＰのアーキテクチャに起因する制約から技術者を切り離すことが可能になる。
【選択図】図４Ｂ
【解決手段】上記バーチャル・マシン層によって、低ＭＩＰＳ複素コードが、上記バーチャル・マシン層により示されるＡＰＩを用いて高ＭＩＰＳプロセスとインターフェースすることが可能となる。本発明によって、専用ＤＳＰにではなく、バーチャル・マシンにソフトウェアの書込みを行うことが可能となり、製造のいずれか１つのソースから生じるＤＳＰのアーキテクチャに起因する制約から技術者を切り離すことが可能になる。
【選択図】図４Ｂ
Description
【０００１】
【発明の属する技術分野】
本発明は、デジタル信号処理の設計、モデル化あるいは実行を行うためのソフトウェアに関する。本発明は、特に、通信用ベースバンド・スタックを用いて機能するデジタル信号プロセッサに関係する。通信用ベースバンド・スタックが通信用デバイスのデジタル信号処理に使用される。
【０００２】
【従来の技術】
技術背景：デジタル信号処理（ＤＳＰ）及びベースバンド・スタック
デジタル信号処理とは、アナログ及び／又はデジタル量のデジタル表現を操作する処理であり、チャネルを介して伝播される有用な情報の伝送または回収を目的とするものである。高速で、高精度の数値計算の利用により、デジタル信号プロセッサによるデジタル信号処理が実行されるが、一般に、これらのデジタル信号プロセッサは高速の、リアルタイムのデータ操作用として最適化された集積回路として形成される。デジタル信号プロセッサは、音声、通信、ビデオなどの多くのデータ収集、処理及び制御環境で使用される。デジタル信号プロセッサは、集積回路に加えて別の方法で実現が可能である。例えば、デジタル信号プロセッサは、マイクロプロセッサ、及び、プログラムされたコンピュータにより実現が可能である。本明細書で用いる用語‘ＤＳＰ’は、任意のデバイスあるいはシステムもカバーするものであり、デジタル信号処理の実行が可能なソフトウェアまたはハードウェアあるいはこの２つの組合せのいずれでもよい。したがって用語‘ＤＳＰ’は、１以上のデジタル信号プロセッサ・チップをカバーし、さらに以下のものをカバーするものである。すなわち：ＦＰＧＡ（フィールド・プログラマブル・ゲート・アレイ）やデジタル信号処理を実行するようにプログラムされたＡＳＩＣ、並びに、以上のいずれかの任意のチューリングデハイス類などのような１以上の外部協働用プロセッサと協働する１以上のデジタル信号プロセッサ・チップをカバーするものである。
【０００３】
通信セクタでは、ＤＳＰでベースバンド・スタックを実行するとき、ＤＳＰはベースバンド・スタック用の非常に重要なエレメントとなる。ＤＳＰと共にスタックによりデジタル信号処理が実行される。本明細書で使用する用語‘ベースバンド・スタック’とは、１組の処理ステップ（またはこれらのステップを実行する構造）を意味し、これらの処理ステップには以下のステップ、すなわち：ソース符号化、チャネル符号化、変調の各ステップ、あるいはそれらの逆、すなわちソース復号化、チャネル復号化及び復調の各ステップが含まれる。さらに、用語‘ベースバンド・スタック’は、いかなる形のダウンコンバージョンも行わずに、デジタル信号を処理できる構造を含むものとして解釈することが望ましい。ソフトウェア無線装置にはこのようなベースバンド・スタックが含まれることになろう。当業者であれば理解できるように、ソース符号化は、ビットレートを下げるための信号（原信号）圧縮に利用される。チャネル符号化によって、復号器能力の改善を図るための構造化された冗長性が付加され、誤り発生の可能性がある受信信号から情報が取り出される。変調により、伝播対象情報に応じてアナログ波形の変更が行われる。
【０００４】
ベースバンド・スタックは、移動電話（ＧＳＭスタックやＵＭＴＳスタックなど）あるいはデジタル無線受信機（ＤＡＢスタックなど）の中でのみならずその他の１方向及び２方向デジタル通信用デバイスの中でも使用される。本明細書で使用する用語‘通信’とは、１方向乃至２方向、あるいは、１対１の通信と放送及び１対多の通信と放送のすべての形態をカバーするものである。用語‘設計’と‘モデル化’には、一般に、１以上のエミュレーション処理、資源計算、診断的分析、ハードウェア・サイジング、デバッギング、パフォーマンス評価が含まれる。
【０００５】
通信システムの増大する複雑さに起因して、ベースバンド・スタックの開発に対して激しい圧力がかけられている。通信システムの複雑さはほぼ毎日のように増大しつつある。この複雑さには、いくつかの促進要因が存在する：インターネット上のトラフィックは毎年１０００％で増加している。このデータ（主として群発性のもの）の多くは、無線キャリアへ移動するが、このようなサービスを提供する利用可能なスペクトルがだんだん少なくなっている。これらの事実は、できるだけ多くのデータを圧搾して最小の使用可能帯域の中へ入れることを目的とするさらに複雑な信号処理アルゴリズムの利用へとつながる。実際、これらのアルゴリズムの複雑さは、ムーアの法則（計算機の能力は１８ヶ月ごとに２倍になる）よりも速く増加し続けている。その結果、従来のＤＳＰの能力では不十分になりつつある。したがって、複雑な端末用として、非常に大きな並列処理ロードの処理が可能なＡＳＩＣを形成する必要がある。しかし、実際には問題はここから始まる。なぜならば、使用されるアルゴリズムが信号処理フロントで複雑であるばかりでなく、主として音声トラフィックから主としてインターネット関連トラフィックへの移行により要請されるところの、バースティな、可変ＱｏＳでのしばしばの暫定転送用トランスポート・チャネルの利用は、（ハードウェアによるリアルタイム・コードが要求される）層１において、さらに優れた制御プレーン・ソフトウェアを必要とするからである。従来のＤＳＰツールセットでは、この問題を処理する適切なメカニズムが提供されていない。その結果、現在の多くの設計は‘現実の世界’のデータ・アプリケーションの処理をするための調整を行うことができない。
【０００６】
しかし、最新の通信システムの高度のＭＩＰＳ要件は、この話のほんの一部を表すものであるにすぎない。単一のＳｏＣ（チップ・オン・システム）内で多数の規格（ＧＳＭ、ＩＳ−１３６、ＵＭＴＳ、ＩＳ−９５など）を利用する必要がある場合に別の問題が生じる。複数の規格をサポートするＳｏＣデバイスは、様々な国々の様々なマーケットを効率的に利用しようと努めているデバイスのベンダにとってますます魅力的なものになるであろう。また、次世代ＵＭＴＳ電話は、ＧＳＭ（すなわち現在の世代）の能力を持つだけでなく、ＤＡＢ（デジタル無線放送）受信機のような付加機能も持つようになることが予想される。そのため、ＵＭＴＳ、ＧＳＭ及びＤＡＢ用のベースバンド・スタックが必要となる。通信用プロトコルの複雑さのために、現在では、上記問題のすべてに対するソリューションの提供を期待できる企業は１つとして存在しないような状態になっている。しかし、（上記リストした３つの異なるベースバンド・スタックのＩＰなどの）ＩＰを統合化して、だんだん短くなる時間スケールで単一の統合化されたパッケージの中へ一緒に入れるＳｏＣの構築という深刻な問題が複数のベンダのＩＰから生じる。複数のベンダのＩＰの相互接続を可能にする商用システムは現在マーケットには存在しない。層２と層３のソフトウェア（一般的には、ソフトによるリアルタイム・コード）の方が単純である。なぜならば、ＤＳＰまたは別の汎用プロセッサの多くのソフトウェアの中の１つの処理としてこのソフトウェアを単純に実行することができるからである。しかし、（ハードによるリアルタイムの、しばしば並列処理が行われる）層１のＩＰアルゴリズムはさらに困難な問題を提起する。というのは、必要なハードウェアによる加速処理が、層全体のアーキテクチャを左右して、非移植性の、ぜい弱な、ソリューション特有のＩＰを提供することが多いからである。
【０００７】
ベースバンド・スタック開発の現在のモデルにおける欠陥の概観
過去において、ベースバンド・スタックは比較的単純で、求められる高ＭＩＰＳ機能性の量は比較的小さく、マルチ規格の、マルチベンダの統合化が行われてきた。しかし、上述したように、現在では上記の事実はいずれも当てはまらない：すなわち：（ａ）ハードウェアの使用を必要とする、さらに複雑なアルゴリズム（ターボ復号化、ＭＵＤ、ＲＡＫＥなど）が採用される帯域圧縮手段、（ｂ）さらに多くのデータ発生／消滅イベント（ｂｉｒｔｈ／ｄｅａｔｈ ｅｖｅｎｔ）と再構成をハードウェア上のアルタイムで処理する必要があるので、パケット・データ・トラフィックの増加が層１制御プレーンの複雑さを増大させる。（ｃ）研究開発から製品化までの期間や、規格の多様化さらには差別化圧力のために、ベンダは、ますます複雑化する機能性（３Ｇ、ブルートゥース、８０２．１１など）を単一デバイスとしてレコード時間内で統合化する傾向があるが、これは特定のアプリケーション用ＳｏＣ（システム・オン・チップ）を形成する層１のＩＰの使用許諾を必要とする。
【０００８】
現在、この問題の適切な解決方法は存在しない。ＶＨＤＬツールセット・プロバイダ（ＣａｄｅｎｃｅやＳｙｎｏｐｓｉｓなど）は‘ボトムアップ’からこの問題にアプローチしている。プロバイダのツールは機能の個々の高ＭＩＰＳユニット（ビタビ・アクセラレータなど）の製造については有効であるが、層１フレームワークや制御コードのためのツールや統合化を与えるものではない。ＤＳＰのベンダ（ＴＩ社、アナログ・デバイシズ（Ａｎａｌｏｇ Ｄｅｖｉｃｅｓ）社など）は、ソフトウェア開発用ツールを確かに供給しているが、これらの会社のリアルタイム・モデルはスタティックで（そのためパケット・データのバースト性にうまく対処していない）、これらの会社のＤＳＰは、ＤＳＰの有用性にブレーキとして働くムーアの法則によって制限を受ける。さらに、通信用スタック・ソフトウェアはステート状態マシンとして最適にモデル化されているが、このステート状態マシンにとってＣまたはＣ＋＋（ＤＳＰベンダにより通常サポートされている言語である）は適していない代用言語である。
【０００９】
ベースバンド・スタック開発の現在のモデルにおける欠陥の詳細な分析
従来、デジタル通信のためのベースバンド・スタック開発は細分化され、高度に専門化されている。例えば、ベースバンド・スタックの中核である信号処理アルゴリズムの初期開発は数学モデリング環境（Ｍａｔｌａｂなど）で一般に行われるが、その際、従来方式のスプレッドシートプログラムを用いて精巧な評価がなされていたＤＳＰの最終ターゲットに対して見合うように、特定メモリやＭＩＰＳ（毎秒１００万命令）の総量が設定されている。いったん、このモデル化処理が良好に実行されると、コード・モジュールと、スタック用のインフラ・ストラクチャ・ソフトウェアとが書き込まれ、可能な場合には既存ライブラリが適合化される（またおそらくＲＴＯＳ（リアルタイム・オペレーティング・システム）が書き込まれる）。次いで、任意の必要なハードウェアによる加速処理が、可能な場合にはＰＬＤ（プログラマブル論理素子）上にプロトタイプ化される‘リアルタイム’のプロトタイプ・ハードウェア・システム（‘ＲＡＣＫ’と呼ばれる場合もある）が構築される。これは、ネットワークとの接続なしでテストされ、コードに対する必要な変更が行われる。いったん満足のゆくものになると、このスタックは固定化され、（オンチップ周辺機器としてハードウェアの加速用モジュールが組み込まれる）最終的ＡＳＩＣ（特定用途向け集積回路）が形成される。この結果つくられたベースバンドＤＳＰまたはＤＳＰコンポーネントが検査され、次いで、出荷される。
【００１０】
この‘従来の’アプローチに関していくつかの問題が存在する。これらの問題の中でより重要なものとして以下のことが挙げられる：
＊ 結果として生じるこれらのスタックにはその構造の中に多くのアーキテクチャの独自性が含まれる傾向があり、そのため別のハードウェアのプラットフォーム（別のメーカー製のＤＳＰなど）への‘移植’処理は時間のかかるものになる。
＊ また上記スタックは、修正が困難で、ぜい弱なものとなる傾向もあるため、インハウス（ｉｎ−ｈｏｕｓｅ）での変更の実施（バグの修正や、規格の中に導入された新しい特性の調整など）と、スタックのわずかな変更を望む他の人々へスタックの使用許諾を効果的に与えることとの双方を困難なものにしている。
＊ ＭＭＩ（マン・マシーン・インターフェース）との統合化が貧弱なものになる傾向があり、このことは、一般に、このＭＭＩの機能用の別個のマイクロ・コントローラをターゲットのデバイス内で使用することを意味する。このためチップ個数とチップ・コストとが増加することになる。
＊ 処理がきわめて低速であり、ＤＡＢ（デジタル・オーディオ放送）などの著しく複雑なシステム用ベースバンド・プロセッサの形成に最低約１年の経過時間を伴う。
＊ この処理は、バッファの割り振り、ダウンコンバージョンの管理、デジタル・フィルタの挿入、好適なチャネル・モデルの作成等々を行うための全体的最善の方法を決定する技術当局者（いわゆる‘グル（ｇｕｒｕ）’）に大きなストレスをかけるものとなっている。以上の点は一般に不利な点である。というのは、これによって、非常に重要なパスとメイン・スタッフへの依存がスタック製造プロジェクトに付加され、製造のタイム・ラインを長引かせることになるからである。この結果得られる製品は、適切な現在の技術のすべてを必ずしも含むとは限らないことが大いに予想される。その理由として、支配的な最善の実施技術のすべてにわたって完全に熟練している個人がいないこと、また、グルあるいはグルのチームが可能な技術革新のすべてを（たとえ彼らがその技術革新について知っていたとしても）スタック製造プロジェクトの中に組み込むだけの時間的余裕が必ずしもあるわけではないということが挙げられる。
＊ ＭＩＰＳの手動計算及びメモリ要件への依存、並びに、スタック用のＤＳＰモジュール及びインフラ・ストラクチャ・コードのカスタムメイド的性質は、製品の中に欠陥が生じる大きな確率があることを意味する。
＊ １つの関連する問題点として、一般に、‘ＲＡＣＫ’が組み立てられるまでは、スタックのリアルタイムでのプロトタイピングは可能ではない点が挙げられる。その点でも、利用可能な視認性の高いデバッガの不足は、最終スタックと資源の‘拘束解除’が不必要に遅滞することでと、ハードウェア製造のタイム・スケールが超過することを意味する。視認性の高いデバッガは、利用可能であれば、非常に有用なものとなるであろう。というのは、Ｃ＋＋のような高水準言語で開発されている場合、デバッガは、コードの中にブレイク・ポイントを入れ、そのポイントにおける処理を停止し、メモリ内容をチェックし、単一ステップ命令の効果を調べるために単一ステップを実行する開発用ツールの能力を与えるからである。またその場合、特定の条件が生じたとき、実行を停止させ、デバッガを起動させるトリガーをコードの中に入れることもできる。これらはアプリケーション・ソフトウェアを開発するとき非常に強力なツールとなる。‘ロック・オフ’とは、プロジェクトの１つの段階が完了したとき、開発が次の段階へ進むことができるということを意味する。ハードウェアの開発では、各反復試行が費用や時間のかかる製造を必要とするので、ソフトウェアの場合のように容易に反復試行を行うことはできない。
＊ 製造中のスタック用の低レベル・モジュールあるいはハードウェアによる加速処理用‘コントローラ’を開発しなければならないため、開発者はターゲット・プロセッサのアセンブリ言語に熟知している必要があり、また、彼らは当該プロセッサ用として与えられる開発用ツールに依存することになる。
＊ インフラ・ストラクチャ・コードが再使用されないという事実に伴うモジュール性の不足は、次のデジタル放送スタック用としてほとんど同じ作業を再び行う必要があることを意味する。
【００１１】
スタック開発へのこのタイプのアプローチから生じる、関連するセットとなる‘戦略的’問題が上記の困難な問題と結びつき、このタイプのアプローチでは、スタックは必然的に特定のハードウェア環境と強く結びつくものとなる。
＊ スタック・メーカの視点から見ると、選択されたＤＳＰのハードウェア・プラットフォームと接近しすぎる近い関係が存在する。錯誤に起因して、コストのかかる（また時間のかかる）移植処理が必要となるため、このＤＳＰハードウェア・プラットフォームの注意深い選択を行う必要があるだけでなく、開発用ツール、低水準アセンブリ言語、テスト用‘ラック’のハードウェアの開発及び最終的プラットフォームＡＳＩＣの製造がすべてそのアーキテクチャ独自のものとなる。別のハードウェア・プラットフォームでスタックを使用する機会が生じた場合、まずそのスタックを移植しなければならないが、これにはきわめて長い時間がかかり、多重コード・ベースが導入される（また、これによりプラットフォーム固有のバグという大きなリスクが伴うことになる）。コード・ベースとはプロジェクトの基礎を成すソースコードのことである。理想的には、ソフトウェアの開発の際、ソースコードと機能との間の１対１の対応付けが行われることになる。そのため、ある特定の機能を必要とする場合、いくつかのプロジェクトがすべて同じ実施構成を共有することになる。したがって、この実施構成が改善されれば、すべてのプロジェクトがその利益を享受することになる。しかし、起こりがちなこととして、個々のプロジェクトがコードの個々のコピーを持ち、実施構成が（自然界における遺伝子にいくぶん類似して）時間中分岐するということが挙げられる。プロジェクトが、従来方式の開発パラダイムの下で異なるハードウェアを使用する場合、同じコードの使用が不可能となる場合が時として生じることがある。さらに、たとえ同じハードウェア・プラットフォームがグレードアップされた仕様により利用可能になったとしても、コードは依然‘ミニ移植’を受け、それらの付加特性（例えば、より多くのオンボード・メモリや別のＭＡＣ（積和演算）ユニットなど）を利用できるようにする必要がある。
＊ ハードウェア・メーカの視点から見ると、ソフトウェア・スタックとの接近しすぎる近い関係が存在する。ハードウェア・メーカは、（概して）スタック製造ビジネスの専業になることを望まない。それにもかかわらず、このような（そのデバイスを有用な製品に変える）スタックがなければハードウェア・メーカはユニットの販売を行うことはできない。マーケット用として、利用可能な‘ソフトウェア・ベース’という表現は、ハードウェア・メーカの製品がもっと適切に競合の対象とすべきその他の特性（利用可能なＭＩＰＳ、電力消費量、利用可能なハードウェアのＩＰなど）を不明瞭にする可能性がある。
＊ （シンビアン社のような）オペレーティング・システムのプロバイダは、彼らのＯＳをベースバンド通信スタックとインターフェースすることを非常に重要であると考えている。実際問題として、従来方式のスタックにおけるモノリシックで、電力消費の大きい点や、リアルタイム要件に起因して、このベースバンド通信スタックとのインターフェースは達成が非常に困難となる可能性がある。
【００１２】
テキサス・インスツルメント社による「ｅＸｐｒｅｓｓＤＳＰ（ｅＸｐｒｅｓｓＤＳＰ）リアルタイム・ソフトウェア技術」を参考として考えることができる。この製品セットによって、ＤＳＰ用ソフトウェアの開発時間と統合化時間の削減が可能になる。しかし、この製品セットは従来方式の設計アプローチの欠点を例示するものである。なぜならこのセットは、専用セットとして、テキサス・インスツルメント社製ＤＳＰプラットフォームと結びついているからである。「ｅＸｐｒｅｓｓＤＳＰ（ｅＸｐｒｅｓｓＤＳＰ）リアルタイム・ソフトウェア技術」よりも優れた本発明の１つの実施構成のさらに詳細な相違について、以下本発明の詳細に要約する。
【００１３】
【発明が解決しようとする課題】
本発明の第１の態様によれば、デジタル信号処理の設計、モデル化、あるいは実行のためのソフトウェアが提供され、該ソフトウェアは、通信用ＤＳＰ用として最適化されたバーチャル・マシン層を含むものとなる。
【００１４】
‘バーチャル・マシン’とは、一般に、本発明に関連するタイプのアプリケーションを実現するための理想的マシンの機能とインターフェースとを定義するものである。このマシンは、一般に、進行中のタスク用として最適化された理想的マシンを使用アプリケーションに対して提示し、実際のハードウェアの不良動作と欠陥とを隠すようにするものである。また、通信処理をモデル化したり、通信処理を表示したりする１以上のステートマシンの管理及び／又は維持を行うことも可能である。その場合‘バーチャル・マシン層’は、現実のマシンをこの理想的マシンのように見えるようにするソフトウェアである。この層は、一般に、すべての現実のマシン・タイプについてそれぞれ異なるものとなる。‘バーチャル・マシン層’とは、一般に、ソフトウェアから成る層を意味し、この層は、何らかのタスクまたは１組のタスク（デジタル信号処理など）を実行する１組の１以上のＡＰＩ（アプリケーション・プログラム・インターフェース）を提供し、使用プログラム間で割り当てられ、共有する必要のある非常に重要な資源（メモリやＣＰＵのような資源など）を享有している。
【００１５】
好適には、資源を割り当て、共有し、切り替えられるように、バーチャル・マシン層を最適化して、デジタル信号処理を行うために最善となるようにすることが望ましい。これと対照的に、典型的なオペレーティング・システムは、ワード・プロセッサのような一般的ユーザ・インターフェースプログラム用として最適化されている。したがって、例えば、上記ケースの資源切替えアルゴリズムは、一般に、エンドユーザのオペレーティング・システムの時間増分値よりもはるかに小さな時間増分値で機能し、並列処理の制御を行うことを可能とするものでもある。
【００１６】
通信用ＤＳＰ用として最適化されたバーチャル・マシン層では、処理を実行しなければならないハードウェアからのソフトウェア・ベースバンド・スタックの切り離しが図られる。このため、ベースバンド・スタックを非常に移植し易いものにすることが可能となる。それは、基底を成すハードウェアの変化からのこれらのベースバンド・スタックの切り離しがバーチャル・マシン層により可能となることに起因する。また、上記バーチャル・マシン層では（各々が様々な機能を実行する）様々な接続モジュール間でのフロー制御の管理を行うことも可能であり、この管理を同時ベースで行うことも可能である。さらに上記バーチャル・マシン層では、信号処理用の共通データ構造の定義を行うことも可能である。これについて以下さらに詳述する。
【００１７】
本発明のソフトウェアは、（ベースバンド・スタック、または、特に、様々なベンダからのいくつかのベースバンド・スタックや、移動電話のような最終製品を含むＳｏＣ全体などの）通信用デバイスをモデル化し、開発し、実際にベースバンド処理の実行を可能にする開発環境において利用が可能である。
【００１８】
‘バーチャル・マシン層’というコンセプトを通信用ＤＳＰの領域に対して適用する利点は、非アナログ分野からの一例を通じてもっとも良く理解することが可能となる。ＰＣソフトウェアの分野では、（システムＢＩＯＳの上位に在る）マイクロソフトのウィンドウズＴＭオペレーティング・システムは、使用中の実際のマシンから、及び、そのマシンと接続されたデバイスの細部からソフトウェア開発者を切り離している。換言すれば、マイクロソフトのウィンドウＴＭオペレーティング・システムは、コードが実行可能な‘バーチャル・マシン層’を提供している。これが図１に概略的に例示されている。このバーチャル・マシン層に起因して、ワード・プロセッサを使ってものを書いている人が、例えば、彼らのコードを実行するのがデルのマシンかコンパックのマシンかどうかとかということや、ユーザが、（いずれかのプリンタが）接続している場合そのプリンタがどのような種類のものであるかなどということは知る必要はない。さらに、このオペレーティング・システムによって、１組の共有のコンポーネント（ファイル・ダイアログ・ボックス、メモリ割付けメカニズム及びスレッド管理ＡＰＩのような）機能とサービスとが提供される。‘共通コード’が１回しか書き込まれないため、各アプリケーションが‘共通コード’を何度も再実行しなければならなかった場合に比べて、このような‘共通コード’の厳密性、範囲及び信頼性が大幅に上昇する。さらに、ＰＣハードウェアのメーカーはソフトウェア開発の複雑さから保護され、適切なウィンドウズのＡＰＩから得られるＢＩＯＳとドライバを提供するだけで、当該プラットフォーム用の膨大な範囲の既存ソフトウェアの利用が可能となる。図２に例示されているように、各アプリケーションがそれ自身のカスタムＧＵＩコードを内包していることが多かったプレ・ウィンドウズ状況と、現在の状況とを対比することができる。
【００１９】
ＰＣウィンドウズの‘バーチャル・マシン層’アプローチのための主要なイネイブラ（ｅｎａｂｌｅｒ）として、多数のアプリケーションにより、同じ基底を成す‘バーチャル・マシン’の機能が広く求められることが挙げられる。もしも、ただ１つのアプリケーションが、プリンタを使用する必要があったり、ただ１つのアプリケーションがマルチスレッドを必要としたりするのであれば、上記サービスがウィンドウズの‘バーチャル・マシン層’の一部であることは効率的であるとは言えないであろう。しかし事実はそうではない。なぜなら、（ウィンドウ、アイコン、マウス、ポインタ、プリンタ、ディスク記憶装置などの）類似のＩ／Ｏ要件と、類似の‘共通コード’要件とを持つ多数のアプリケーションが存在して、それがＰＣ‘バーチャル・マシン層’を‘説得力のある提案’としているからである。
【００２０】
しかしながら、本発明に先行して、‘バーチャル・マシン’というコンセプトを通信用ＤＳＰの分野に適用することを考えた者はいままで誰一人としていなかった。このコンセプトを適用することにより本発明によって、専用ＤＳＰにではなく、バーチャル・マシンにソフトウェアの書込みを行うことが可能となり、製造上のいずれか１つのソースから生じるＤＳＰのアーキテクチャに起因する制約から技術者を切り離すことが可能になる。このＤＳＰからの独立という形は、マイクロソフト社のウィンドウズ・オペレーティング・システムにより提供されているところの、ＰＣの世界でのハードウェアの独立性と同様に潜在的に有用なものである。この独立性は図３と４に概略的に例示されている。図３には、適切に実現された場合、アーキテクチャから見て中立であることが望ましいベースバンド・スタックの部分が、実際にはサブストレート・ハードウェアから適切に切り離されていないような従来方式の状況が示されている。図４は本発明のバーチャル・マシン層（通信用マシン層（ＣＶＭ）と呼ばれる）がベースバンド・スタックのこれらの部分の切り離しに成功する方法を描く図である。
【００２１】
したがって、本発明の様々な実現構成にとっていくつかの主要な利点が存在する。
＊ ＤＳＰのアーキテクチャを介して、様々なメディア・アクセス・ハードウェアへに対してベースバンド・スタックを移植すること（例えば９００ＭＨｚで作動するＧＳＭ電話用スタックを１８００ＭＨｚで機能するＧＳＭ電話へ移植するなど）がずっと高速に行われる。なぜならば、本発明によって、アーキテクチャ固有の、あるいは、スペクトル固有のものではないスタックの設計が可能になるからである。研究開発から製品化までの期間のような非常に重大な利点がさらに一段と重要になる。したがって、スタックは、バーチャル・マシン層が移植される相手先の任意のＤＳＰのアーキテクチャで機能することになる。同様に、バーチャル・マシン層が移植される相手先ＤＳＰは、バーチャル・マシン層用として書き込まれたすべてのスタックを実行することになる。
＊ 高ＭＩＰＳコンプレックスコード（ビタビ復号器など）の多くは、各ＤＳＰのアーキテクチャの場合、何回も書き変えられるのとは対照的に、バーチャル・マシン層の場合には１回しか書き込まれない。このため、このコンプレックスコードの品質と信頼性が、軽い経済的負担で改善可能となる。これは、ベースバンド・スタック自身が以前より少ないコードしか必要とされないであろうこと、及び、どのようなスタック・コードが必要であるにせよベースバンドスタック自体は複雑さの少ないものであろうことを意味し、これによってスタック・コードの信頼性が向上する。
＊ このバーチャル・マシン層によって、完全にソフトウェアの中で、あるいは、ソフトウェアと、通常使用されているＤＳＰコンポーネントとの混成物を用いるかのいずれかでプロトタイプの形成能力が与えられ、それによって、開発サイクルにおけるアルゴリズムの欠陥と資源要件との早めの特定が可能となる。
【００２２】
好適には、バーチャル・マシン層が、様々なコア処理及び／又はコア構造及び／又はコア機能及び／又はフロー制御及び／又は状態管理を用いてプログラムされるか、もしくは、様々なコア処理及び／又はコア構造及び／又はコア機能及び／又はフロー制御及び／又は状態管理へのアクセスを可能にすることが望ましい。バーチャル・マシン層がプログラムされる（あるいはバーチャル・マシン層がアクセスを行うことを可能にする対象としての）コア処理には‘１以上の共通エンジン’が含まれる。これらの‘共通エンジン’は、１以上のベースバンド・スタック機能、すなわち、ソース符号化、チャネル符号化、変調及びそれらの逆（ソース復号化、チャネル復号化及び復調）を実行する。これらの‘共通エンジン’には、高速フーリエ変換（ＦＦＴ）、（様々な拘束長、ガロア多項式及びパンクチャリング・ベクトルを持つ）ビタビ復号器、リード・ソロモン（Ｒｅｅｄ Ｓｏｌｏｍｏｎ）エンジン、ＭＰＥＧ復号器用離散余弦変換（ＤＣＴ）、エラー・デコヒーレンス（ｅｒｒｏｒ ｄｅｃｏｈｅｒｅｎｃｅ）のための時間及び周波数ビット毎の再オーダリング、複素ベクトル乗算及びオイラー合成が含まれる。さらに広範囲のリストが添付書類１の中に含まれている。これらのパラメータ化された変換の中の１以上が、通信用ベースバンド・スタックにより共通に求められる。上記従属特性は、ほとんどすべての主要なデジタル放送システムの範囲内に見いだされるという本発明による洞察に基づくものである。一例として、ＧＳＭとＤＡＢとの類似性が挙げられる。例えばＧＳＭとＤＡＢの双方においてインターリービングとビタビ復号化が利用される。したがって、共通の数学的基礎に基づく共通性が断言される．
【００２３】
さらに、‘コア構造’は各ケースの中に存在してもよい。この‘コア構造’は、（当該シンボルの範囲内に保持されているすべての情報が利用可能か否かにかかわらず、フル・シンボルの処理に関係する）シンボル処理部と、関連情報を保持する当該ビットのみの処理が行われるデータ指向処理部とに復号化チェーンを分割することに関与する。各ケースで、これらの処理用モジュールが、中間の、整合メモリ・バッファの割り当て、共有、配置を行い、処理用モジュール間でイベントを渡し、モジュラ型開発を可能にする枠組みの範囲内の存在であることが非常に望ましい。
【００２４】
上記コア機能は、以下の処理のうちの１以上を含む資源割当てとスケジュリング（メモリ割付け、リアルタイムの資源割当て及び同時性管理）に関するものであってもよい。好適には、このソフトウェアは、パフォーマンスと能力の点でＤＳＰ設計用ツールよりもずっと優れた、ＰＣのデバグ用ツールにアクセスが可能であることが望ましい。このソフトウェアは、コンフォーマンスクリプト（ｃｏｎｆｏｒｍａｎｃｅ ｓｃｒｉｐｔｉｎｇ）に従うものであってもよい。このスクリプトについては以下に定義する。さらに、このソフトウェアは、コンポーネントを用いて機能するものであってもよい。このコンポーネントの中で上記ソフトウェアの機能及び／又は別様にコンポーネントのパフォーマンスのモデル化を可能にするために必要な当該情報だけが上記コンポーネントの知的財産の所有者により供給される。このことによって、（内部の詳細事項、設計、操作のような貴重な営業秘密情報である可能性のある）知的財産の所有者がその情報を隠し、サポートされている機能、ＡＰＩに必要なパラメータ、タイミングと資源のインタラクション、特性評価のための予想パフォーマンスなどのようなずっと重要性の少ない情報だけを公開することが可能になる。
【００２５】
本明細書では、本発明に従うソフトウェアの実施例を通信用マシン層（ＣＶＭ）と呼ぶ。ＣＶＭは、上記に導入した着想を一緒に引き出すので、以下のセクションにおいて要約する。
【００２６】
ＣＶＭの実現構成についての要約
ＣＶＭとは、デジタル信号処理製品開発用プラットフォームと、当該製品を実行するためのランタイム（ｒｕｎｔｉｍｅ）との双方を指すものである。ＣＶＭは、基本的に、バーチャル・マシン層と関連する複雑さの管理手法をリアルタイム・デジタル信号処理へもたらすものであるが、この信号処理は、（ｉ）（アーキテクチャ独自の方法で実現可能な）高ＭＩＰＳデジタル信号処理計算をバーチャル・マシン層の一方の側の‘エンジン’の中に配置すること、（ｉｉ）アーキテクチャから見て中立な低ＭＩＰＳコード（様々な低ＭＩＰＳプロセスを定義する層１コードなど）をもう一方の側に配置することにより実行される。さらに具体的には、ＣＶＭは、低ＭＩＰＳ制御プレーンとデータ‘操作及びパラメータ’フローを除くすべての高度の複雑さを、（ビタビ復号化、ＦＦＴ、相関などの）多量の資源を必要とする処理を実行する高ＭＩＰＳ‘エンジン’から切り離すものである。この切り離しによって、‘アーキテクチャから見て中立な’高い移植性を持つ方法で、複雑な通信用ベースバンド・スタックの構築が可能になる。なぜならば、基底を成すハードウェア上ではなく、ＣＶＭ上で実行するベースバンド・スタックの設計が可能となるからである。ＣＶＭは、これらのスタックの高度の複雑さ、低ＭＩＰＳ制御コードに対して均一なセットのＡＰＩを演出し、多くの様々な種類のスタック用として高ＭＩＰＳエンジンの再使用を可能にするものである（例えば、ＧＳＭとＵＭＴＳスタック双方のためのビタビ復号用エンジンの利用が可能となるなど）。
【００２７】
デジタル信号処理製品の開発段階中、（最少の数のプロセッサで実行するなどの）最適のアクセス・コストを示す構成を特定することを目的として、デジタル信号処理製品の様々な設計上のＭＩＰＳ要件の、ＣＶＭによるシミュレーションやモデル化の実施が可能である。確定論的関数とは対照的な、少なくとも１つの確率的統計分布関数を利用する資源割当て処理が利用される。様々なＤＳＰチップとＦＰＧＡとから成る実現構成のシミュレーションが可能である。高ＭＩＰＳの速度と並列処理能力との故に、ＦＰＧＡの中に高ＭＩＰＳ演算処理を配置することが非常に望ましい。
【００２８】
実際の処理中、最適の処理を維持するために、ＣＶＭ内のスケジュラがリアルタイムで知的にタスクの割り当てを行うことが可能である。本明細書ではこのアプローチを‘２段階スケジュリング’と呼ぶ。様々なエンジンの資源要件が、（ｉ）設計時に明示的にモデル化が可能であること、（ｉｉ）ランタイム中、知的に利用が可能であること、という理由により、いくつかの様々なベンダからのエンジンを単一製品の中に混ぜることが可能となる。上述したように、これらのエンジンは、層１と直接の接続を行うのではなく、代わりにＣＶＭバーチャル・マシン層の中継を介して制御コードを層１と接続する。さらに、ＤＳＰとＦＰＧＡとの組合せを利用する非リアルタイム・プロトタイプから実行時プロトタイプへの移行、次いで、カスタムＡＳＩＣ上への効率のよい移行がＣＶＭを用いることにより可能となる。
【００２９】
ＣＶＭでは以下の３つの主な特長が実現される：
＊ 同時スケジュリングのためのサポートを備えた、ダイナミック、マルチ・メモリ空間用マルチプロセッサ分散型スケジュラ
＊ アーキテクチャ固有の実現構成を備えた、デジタル放送及び通信用として共用される高ＭＩＰＳ演算処理用ＡＰＩ
＊ 資源管理及び正常化層（ｎｏｒｍａｌｉｚａｔｉｏｎ ｌａｙｅｒ）（固有のＲＴＯＳを介して供給される）
【００３０】
ＣＶＭは‘パイプライン’という形で存在することが可能である。‘パイプライン’とは、ある構造または１組の相互作動するハードウェア・デバイスまたはソフトウェア・デバイス、及び、１つのデバイスまたは処理から別のデバイスまたは処理へ情報を渡すルーチンである。ＤＳＰ環境では、このような複数の情報は‘シンボル’と呼ばれることが多い。パイプラインは、データ・フローアーキテクチャとして、並びに、従来の手続き用コードとして実現が可能であり、このような変形例のすべては本発明の範囲内に属するものである。また、ＣＶＭは、ステートマシンとして、または、手続き用コードとして概念化し、実現することも可能であり、再言するが、このような変形例のすべては本発明の範囲内に属するものである。
【００３１】
【課題を解決するための手段】
ＣＶＭの１つの例には、解釈されたパイプライン・マネージャが含まれ、このパイプライン・マネージャにはＣＶＭコアのランタイムバージョンが組み込まれる。‘解釈された’という用語が意味するものとして、そのパイプラインの仕様が基底を成すマシンコードにまだ翻訳されていず、ベーシック言語のような解釈された言語の場合と全く同じように、プログラムの実行につれて繰り返し再翻訳が行われることが挙げられる。
【００３２】
別の例として、ＣＶＭコアのラタイムバージョンが組み込まれた、計装化された解釈パイプライン・マネージャ（Ｉｎｓｔｒｕｍｅｎｔｅｄ Ｉｎｔｅｒｐｒｅｔｅｄ Ｐｉｐｅｌｉｎｅ Ｍａｎａｇｅｒ）がある。この計装化された解釈パイプライン・マネージャは、解釈されたパイプライン・マネージャと同じように機能するが、開発者に役立つメトリックと計測値も生成する。解釈された非計装化（ｎｏｎ−ｉｎｓｔｒｕｍｅｎｔｅｄ）バージョンもまた開発とデバッギング用として有用であり、コンパイルされ、計装化された（ｉｎｓｔｒｕｍｅｎｔｅｄ）バージョンもまた有用である。後者のバージョンは開発とデバッギング用の最適ツールとなる場合もある。
【００３３】
ＣＶＭの別のバージョンはパイプライン・ビルダ（Ｐｉｐｅｌｉｎｅ Ｂｕｉｌｄｅｒ）である。プログラム実行の代わりに、パイプライン・ビルダは、Ｃ言語のようなコンピュータ・ソースコードを出力し、このソースコードをコンパイルして、パイプラインの実現構成を形成することができる。この理由のため、パイプライン・ビルダはＣＶＭライブラリを利用できなければならない。パイプライン・ビルダは、コンパイルされた非計装の変形例と考えることもできる。
【００３４】
ＣＶＭ装置は、通信用コンポーネントの特性（非インターフェースの振舞いを含む）の標準化された記述を含むか、この記述に関するものであるようにして、シミュレータがコンポーネントを利用する上でのシステムの資源要件の正確な推定ができるようにする。ＣＶＭ装置で時間及び同時性制限条件のモデル化を行って、リアルタイムＯＳ上への対応付けを可能にし、並列処理を実行できる可能性を持たせるようにすることも可能である。
【００３５】
本発明の別の特性と態様は本明細書の請求項において定義される。添付図面を参照しながら本発明について以下説明する。
【００３６】
【発明の実施の形態】
ＲａｄｉｏＳｃａｐｅ社（英国、ロンドン）のＣＶＭの実現構成に関連して本発明を説明する。
【００３７】
ＣＶＭの概観
ＣＶＭとは、デジタル信号処理製品開発用プラットフォームと、当該製品を実行するためのランタイム（ｒｕｎｔｉｍｅ）との双方を指すものである。ＣＶＭは、基本的に、バーチャル・マシン層と関連する複雑さの管理手法をリアルタイム・デジタル信号処理へもたらすものであるが、この信号処理は、（ｉ）（アーキテクチャ独自の方法で実現可能な）高ＭＩＰＳデジタル信号処理計算をバーチャル・マシン層の一方の側の‘エンジン’の中に配置すること、（ｉｉ）アーキテクチャから見て中立な低ＭＩＰＳコード（様々な低ＭＩＰＳプロセスを定義する層１コードなど）をもう一方の側に配置することにより実行される。さらに具体的には、ＣＶＭは、低ＭＩＰＳ制御プレーンとデータ‘操作及びパラメータ’フローを除くすべての高度の複雑さを、（ビタビ復号化、ＦＦＴ、相関などの）多量の資源を必要とする処理を実行する高ＭＩＰＳ‘エンジン’から切り離すものである。この切り離しによって、‘アーキテクチャから見て中立な’高い移植性を持つ方法で、複雑な通信用ベースバンド・スタックの構築が可能になる。なぜならば、基底を成すハードウェア上ではなく、ＣＶＭ上で実行するベースバンド・スタックの設計が可能となるからである。ＣＶＭは、これらのスタックの高度の複雑さ、低ＭＩＰＳ制御コードに対して均一なセットのＡＰＩを演出し、多くの様々な種類のスタック用として高ＭＩＰＳエンジンの再使用を可能にするものである（例えば、ＧＳＭとＵＭＴＳスタック双方のためのビタビ復号用エンジンの利用が可能となるなど）。
【００３８】
バーチャル・マシン層は、いくつかの様々なベースバンド処理用アルゴリズムに共通の基底を成す高ＭＩＰＳアルゴリズムをサポートし、これらのアルゴリズムを、高水準の、アーキテクチャから見て中立な、スケジュラ・インターフェースの中を通る、潜在的に高度の複雑さをもつ低ＭＩＰＳ制御フローにアクセス可能にし、このアクセスによって、ランタイム、メモリ、相互接続帯域のうちの１以上に応じて、１組の資源制約包絡面と共に、制御フローによるアルゴリズムの実行指定が可能になる。上記資源制約包絡の内側で起呼音は処理の実行が行われることを望む。
【００３９】
デジタル信号処理製品の開発段階中、（最少の数のプロセッサで実行するなどの）最適のアクセス・コストを示す構成を特定することを目的として、デジタル信号処理製品の様々な設計上のＭＩＰＳ要件の、ＣＶＭによるシミュレーションやモデル化の実施が可能である。決定論的関数とは対照的な、少なくとも１つの確率論的統計分布関数（及び／又は統計的測定関数）を利用するモデル化を行うための資源割当て処理が利用される。様々なＤＳＰチップとＦＰＧＡとから成る実現構成のシミュレーションが可能である。高ＭＩＰＳの速度と並列処理能力とに起因して、ＦＰＧＡの中に高ＭＩＰＳ演算処理を配置することが非常に望ましい。
【００４０】
実際の演算処理中、最適の演算処理を維持するために、ＣＶＭ内のスケジュラがリアルタイムで知的にタスクの割り当てを行うことが可能となる。本明細書ではこのアプローチを‘２段階スケジュリング’と呼ぶ。様々なエンジンの資源要件が、（ｉ）設計時に明示的にモデル化が可能であること、（ｉｉ）ランタイム中、知的に利用が可能であること、という理由により、いくつかの様々なベンダからのエンジンを単一製品の中に混ぜることが可能となる。上述したように、これらのエンジンは、層１と直接の接続を行うのではなく、代わりにＣＶＭバーチャル・マシン層の中継を介して制御コードを層１と接続する。さらに、ＤＳＰとＦＰＧＡとの組合せを利用するＰＣＴ非リアルタイム・プロトタイプからランタイムプロトタイプへの移行、次いで、カスタムＡＳＩＣ上への効率のよい移動がＣＶＭを用いることにより可能となる。
【００４１】
ＣＶＭでは以下の３つの主な特長が実現される：
＊ 同時スケジュリングのためのサポートを備えた、ダイナミック、マルチ・メモリ空間用マルチプロセッサ分散型スケジュラ
＊ アーキテクチャ固有の実現構成を備えた、デジタル放送及び通信用として共用される高ＭＩＰＳ演算処理用ＡＰＩ
＊ （固有のＲＴＯＳを介して供給される）資源管理及び正常化層（ｎｏｒｍａｌｉｚａｔｉｏｎ ｌａｙｅｒ）
【００４２】
ＣＶＭとは設計フロー・ソリューション並びにランタイムである。
ＣＶＭは、ランタイムを補う完全な設計フローを提供するものである。このＣＶＭによって、完全に統合化された数学モデルと、（群発性のデータに関する演算処理に必須の）統計的シミュレーション・ツールと、（データ・パスがハードウェアの中へ入るべきか、ＤＳＰコア上のソフトウェアの中で実行すべきかを決定するための）序列的分画シミュレーション・ツールが技術者に与えられる。数学モデリング用ツール（Ｍａｔｌａｂ／Ｓｉｍｕｌｉｎｋなど）のカスタム・ライブラリの利用によって、ＣＶＭは、様々なデータ・パスがどれだけのビット数の幅を持つ必要があるかなどを前もって決定するために、詳細に、かつ、ビットレベルの（ｂｉｔ−ｅｘａｃｔ）精度で、高ＭＩＰＳエンジンの機能のモデル化を行うことができる。しかしながら、このシステムは、統計的シミュレーションが行われる制御プレーンからＸＭＬコマンドを受け入れることもでき、これにより、データ発生／消滅イベント（ｂｉｒｔｈ／ｄｅａｔｈ ｅｖｅｎｔ）と群発性とをモデルのコンテキスト内で取り扱うことができるようになる。さらに、スケジュラの間接インターフェースを介してシミュレーション・エンジンにまでもアクセスが行われるので、実際のハードウェアなどの実現構成に対してプラグ・インコールを行って、シミュレーションの実行速度を上げることが可能となる。
【００４３】
また、重要なことは、様々なシステム分画の決定により資源ローディングのシミュレーションの実行が可能なことである。様々な統計的ロードの下で十分にカバーするためには、特定のアルゴリズム‘エンジン’（ビタビ復号器、レイク受信デバイス・エレメント、ブロックＦＦＴの演算処理など）のインスタンスがいくつ必要なのか？データ・パスがバスのような遅延を生じ、及び／又は同時争奪を生じる資源にわたって移動する場合、何が起こるのか？データ・パスがソフトウェアではなくハードウェアの中で実現される場合何が起こるのか？これらの問題の解決のすべては非常に重要であるが、既存のツールセットではこれらの解決はまだ行われていない。さらに、複数のサード・パーティのＩＰエンジンまたはエンジン（下記を参照）に関して、分画問題の解決を行うとき、これは２重の意味で真である。ＣＶＭ設計フローによって、これらの種類の設計上の問題解決に対する回答を与えることが可能となることは明らかである。さらに、初期の分画情報は、設計用ツールセットから‘順方向に’転送されてランタイムスケジュラの中に入り、これによって、システムが実際の動的ロードを行っているときに、このランタイムスケジュラが、好適な実行エンジン・インスタンスに向けて要求を導くことが可能となる。
【００４４】
‘ボトムアップ’から見ると、このソフトウェアを実質的に２次的重要性をもつものとして扱うことは、もはや販売のための製品開発を行う方法ではない。このようなやり方では単に長い時間がかかりすぎるだけで、あまりにもアーキテクチャ固有の結果が生じ、基底を成す領域の並列状態マシンの性質にとって不都合な‘マッチング’が生じることになる。‘トップ・ダウン’から見ると、ＣＶＭが利用するパラダイムにより、はるかにずっと強力で拡張可能なソリューションが得られる。
【００４５】
ＣＶＭに関する最終ポイントとして、基底を成すエンジンから制御フロー・コードを切り離すことにより、実際の組み込まれたターゲットと矛盾することなく、従来の（ＰＣなどの）プラットフォーム上で多くの開発作業の実行が可能になることが挙げられる。これによって、特定のベンダの最終ターゲットの開発用プラットフォームを利用する場合に比べて設計上ずっと早い方向転換が可能になる。
【００４６】
例：ＣＶＭとは、３Ｇシステム用ＳｏＣのような、ハードウェアによるリアルタイムの、マルチベンダの、マルチプロトコル環境に対する設計上のソリューションである。
ＣＶＭのコア・エレメントの中の１つとして、ハードウェアによるリアルタイムの、マルチベンダの、マルチプロトコル環境における（潜在的に衝突する）サード・パーティのソフトウェア／ハードウェアの資源要件を処理する能力がある。この能力はＣＶＭの主要な利点であり、システム・オン・チップ（ＳｏＣ）の設計の際、特別な重要性を持つものである。これを理解するために、３Ｇ携帯電話マーケット向けのベースバンド・チップの将来のプロバイダが直面する問題点について考えることにする。第１に、層１の必要となる処理の複雑さに起因して、在庫のＤＳＰ用として単純にコードを書き込むことはオプションではない。ＡＳＩＣでは、複雑な拡張やターボ復号化などの処理を行うことが求められる。第２に、ＵＭＴＳは少数の地下鉄の場所に当初導入されるにすぎないため、チップにはＧＳＭのサポートも可能である必要がある。ベースバンド・チップメーカがこれら双方の分野で広範囲の技術を持っていることはありそうもなく、したがって、ＩＰの使用許諾を受ける必要が生じる。この点は、絶えず長引くことになる、研究開発から製品化までの期間という圧力を考慮すると技術会社にとって特に関係の深い事柄である。しかし、一部はハードウェア、一部はソフトウェアから成るＩＰエンジンの使用許諾を層１の複数のベンダから得ることは１つの現実的な問題を現出することになる。第１に、上記方法での‘互換性対非互換性’（ｍｉｘ ａｎｄ ｍａｔｃｈ）ＩＰについての共通の単純な基準は現在存在していない。必要とされること、及び、ＣＶＭ設計フローが提示することとして、静的及び動的双方のサード・パーティのＩＰブロックの資源要件を特徴づける１つの方法がある。この方法によって、潜在的に、全く異なるサプライヤからの別のＩＰエンジンを用いてリアルタイムで当該サード・パーティのＩＰブロックを同時スケジュール化し、次いで、より高いレベルの層１制御コードとの透過的な接続が可能となる。さらに、ＣＶＭの性質として、（ＡＮＳＩＣへコンパイルされたＳＤＬなどの）アーキテクチャから見て中立な言語でこれら高レベルの呼構造及び制御プレーン全体の形成が可能であるということが挙げられる。その場合、低いレベルで、高ＭＩＰＳ部分だけがアーキテクチャ独自の形式で直接実現されることになる。
【００４７】
上述したように、エンジン内に内包される高ＭＩＰＳ機能は、完全な処理ルーチンを表すものである。これらのエンジンは、ハードウェアまたはソフトウェア、あるいは両者の何らかの組合せで実現可能であるが、このことは高水準の‘起呼’コードという観点から見ると重要な問題ではない。高レベルのＩＰは、ＣＶＭスケジュラ起呼を介して基底を成すエンジンと交信を行い、この起呼により、ハードウェアにおけるリアルタイムの動的資源制約条件の指定が可能になる。次いで、スケジュラは、適切なデータ・パスにこの要求の実行指令を出す。この実行指令にはＤＳＰの関数呼出しや、ＦＰＧＡまたはＡＳＩＣへのデータの受渡しが含まれる場合もある。重要なことは、このスケジュラが複数のハードウェアのデータ・パスを処理することができるという点である。これらのデータ・パスは様々なアクセス用プロファイルと実行用プロファイル（例えばオンバス・ビタビ復号器、オンチップ・ソフトウェアベースの復号器、及び、外部ＤＭＡを介してアクセスされるオフチップ専用ＡＳＩＣなど）を持つことが可能であり、さらに、起呼用の高レベルのコードから完全に独立した適切なユニットに特定の要求を渡すことが可能である。
【００４８】
また、このことは、２つの異なる通信スタックがいくつかの共通の高ＭＩＰＳエンジンを必要とする場合、適切な（プラットフォーム固有の）エンジンの実現構成（この実現構成がハードウェア、ソフトウェアまたはその双方の何らかの組合せのいずれで設計されているかにかかわらず）のベンダが、上記２つの異なる通信スタックのマーケットへ販売を行うことができることを意味し、さらに、単一のＳｏＣ上に２つの規格が実装されている場合、双方のスタックが同じアクセラレータを潜在的に共有できることを意味する。加えて、１組の１００以上のコア・オペレーションが指定され、これらのコア・オペレーションを考慮に入れると、デジタル放送用プロトコル及び通信用プロトコルの膨大な部分の中で得られる高ＭＩＰＳ機能の８０％近くがこのＣＶＭにより提供されることになる。
また、ＣＶＭランタイムは基底を成すＲＴＯＳにラップアラウンド処理を施し、（スレッド、メモリ、外部アクセスを含む）資源管理のための規格に準拠したインターフェース絡みの高レベルのコードを提示するものである。
【００４９】
ＣＶＭを用いることにより、通信ＳｏＣ製品用の統合化された開発用プラットフォームの構築が可能となる。その場合、いくつかのサード・パーティのベンダは、高レベルのアーキテクチャから見て中立なＳＤＬあるいはＣ＋＋コンポーネントもしくはアーキテクチャに固有の、資源プロファイル化されたエンジン（ハードウェア、ソフトウェア、またはその双方の組合せであってもよい）のいずれかとして、彼らのＩＰを公開することができる。統合化された設計フローによって、ＳｏＣの設計者は、（特定のベンダから選択された）適切なエンジンを含むシステム全体を形成し、ＣＶＭの両側またはいずれかの側に自分のＩＰを付加し、次いで、（アクセラレータと共にいくつかのＶＨＤＬで定義されたコアとして）利用可能なハードウェア仕様とソフトウェア・コンポーネントの双方を作成することが可能になる。数学モデリングと、確立論的序列的分画シミュレーションと、プロトコル検定とによって、完全なフローを提供するツールセットを構築し、好適なメカニズムを提供することで、設計の範囲内で‘パッケージ化された’ＩＰライブラリの特徴づけ、公開、列挙及び利用が可能となる。
【００５０】
このシステムは、ＳｏＣの設計者用の主要ワークベンチになる潜在的可能性を有する。ＳｏＣの設計者は、高ＭＩＰＳエンジンの開発を行うために、層１制御構造（ｆａｂｒｉｃ）の中のいずれにも入らず、ＶＨＤＬツールの中へ入るだけでよくなるからである。
【００５１】
ＣＶＭにより設計層１内でのＳＤＬの利用が可能となる。
上述したように、ＡＮＳＩ Ｃ＋＋または好適にはＳＤＬ（このＳＤＬはその後ＡＮＳＩ Ｃへコンパイルしてもよい）のいずれかを用いて、アーキテクチャから見て中立な方法で低ＭＩＰＳコードを書き込むことがＣＶＭにより可能となる。ＳＤＬとは、層２及び層３スタックを表現するために電気通信業界内で広く使用されている言語であり、状態マシン・フォーマットで最も経済的に表現されるシステムにとって特に好適な言語である。従来の方式で使用するには、ＳＤＬは層２（‘ソフトによるリアルタイム’領域の端）より下位で使用するのに適切なものではない。ＳＤＬコードは様々なアーキテクチャ間での完全な移植が可能であり、ＴＴＣＮなどのようなツールを用いて通常の方法でテストを行うことも可能である。開発時のコードとサブストレートの相互接続とから成る様々な部分に（動的資源の天井などのような）システム上の制約を設けることが可能であり、次いで現実の負荷モデルを用いてシミュレーションを行って、ハードウェアとソフトウェアへのデータ・パスの予行分画を行うことが可能となる。重要なことは、ＣＶＭスケジュールが、開発プロセスの１回の設計時間部分中に行われたデータ・パス分画決定を認識しているということである。ツールフローは、Ｍａｔｌａｂ及びＳｉｍｕｌｉｎｋと完全に統合化され、高ＭＩＰＳ機能のビットレベルでのテストが可能となる。層１の範囲内での高レベルの論理フロー用推奨言語としてＳＤＬの使用は偶発的なものではない。ＳＤＬは、ＧＳＭのような通信スタック層２と３内で広く使用されてきたが、この２つの層の深い溝（ｃｈａｓｍ）の間をかけ渡してハードウェアによるリアルタイム領域の中へ入ってきたことは従来なかったことである。これと対照的に、ＣＶＭでは、ＳＤＬ制御フローからの並列の、ハードウェアによるリアルタイムの実行指令の呼出しが可能となり、それによってＳＤＬの非常に強力で、かつ、自然な、ステートマシンの表現性を利用して、高水準の層１アルゴリズムの作成が可能になる。これらのアルゴリズムは、低ＭＩＰＳを有しているにもかかわらず、ほんの２、３の名前を挙げるだけでも、群発性のレート・マッチング、ユーザ・トランスポート・チャネルのデータ発生／消滅イベント（ｂｉｒｔｈ／ｄｅａｔｈ ｅｖｅｎｔ）、複数の規格間のハンドオーバ、負荷によるＱｏＳと結びついたグレースフル・デグラデーションのような問題を処理しなければならないので、ますます極度に複雑になっている。リアルタイムの処理用としては設計されていない他の言語（Ｃ＋＋やＪａｖａなど）もＳＤＬの代替言語として設計層１での使用が可能である。
【００５２】
ＣＶＭに対する理論的背景
現在のデジタル通信システムは、チャネルに起因するきわめて厳しい影響に直面する中で信頼性の高い、情報の無線による最善の伝送方法についての、最近の１５年かそこらで出現した実質的に共通のコンセンサスに基づいて構築されている。２方向システムは、（例えば、輻輳状態のスペクトル帯域に直面してグレースフル・デグラデーションを生じるＣＤＭＡを利用し、いくつかの‘ハードウェアによる’リアルタイム要件を含むような）放送型システムとは多少異なるチャネル要件と変調要件とを持っているが、全体として多くの共通性が存在する。
【００５３】
例えば、（１方向の）放送システムの特定のケースでは、復号器と符号器は単に並列の‘プロトコル・スタック’と考えることができよう。ほとんどの放送送信システムは、（ビットレートを落とすために入力信号を圧縮するＭＰＥＧのような）ソース符号化から始まり、その後（信号破損にもかかわらず情報を取り出すようにした受信機能力の向上のための構造化された冗長性を付加する畳み込み符号化とリード・ソロモン（Ｒｅｅｄ−Ｓｏｌｏｍｏｎ）符号化のような）チャネル符号化が後続し、その後、（この時点で、複数の副搬送波が（周波数または位相の）角度や振幅の何らかの組合せで修正され、情報が保持される）変調が後続する。次いで、図５の線図を（１つのレベルで）生み出す逆の処理が受信機で実行される。したがって、ほとんどすべての主要なデジタル放送システムの中で１組の共通の処理用エンジンが見いだされ、各ケースで共通の処理構造の適用が可能となる。
【００５４】
ＣＶＭの実施例は、上記の事実を以下のように利用するものである。すなわち、共通エンジン（または関数やライブラリ）には、１以上のステップ（ソース符号化、チャネル符号化、変調の各ステップ）、あるいはそれらの逆のステップ（ソース復号化、チャネル復号化及び復調の各ステップ）を実行するアルゴリズムが含まれる。これらのアルゴリズムには、例えば、高速フーリエ変換（ＦＦＴ）、（様々な拘束長、ガロア多項式及びパンクチャリング・ベクトルを備えた）ビタビ復号器、リード・ソロモン（Ｒｅｅｄ Ｓｏｌｏｍｏｎ）エンジン、ＭＰＥＧ復号器用離散余弦変換（ＤＣＴ）、エラー・デコヒーレンス（ｅｒｒｏｒ ｄｅｃｏｈｅｒｅｎｃｅ）のための時間及び周波数ビット毎の再オーダリング、複素ベクトル乗算及びオイラー合成などが含まれる。さらに広範囲のリストが添付書類１の中に含まれている。上記アルゴリズムは高ＭＩＰＳルーチンであり、したがって、理想的にはアーキテクチャに固有の方法で（アセンブリ・コードまたはハードウェアによる加速処理のいずれかを介して）ＣＶＭの中で実現される。上記の事実にかかわらず、共通の高水準ＡＰＩを通じてＣＶＭ内のこれらのアルゴリズムのアクセスすることができる。これらのパラメータ化された変換の各々は、この各変換について設けられる並列的数学モデリング・ブロックが含まれる。
【００５５】
この共通構造は、（当該シンボルの範囲内に保持されているすべての情報が利用できるか否かにかかわらず、フル・シンボルの処理に関係する）シンボル処理部と、関連情報を保持する当該ビットのみを処理するデータ指示型処理との復号化チェーンへの分割に関与するものである。各ケースで、これらの処理用モジュールが、中間の整合メモリ・バッファの割り当て、共有、配置を行い、処理用モジュール間でイベントを渡し、モジュラ型開発を可能にする枠組みの範囲内に存在できるようにすることが非常に重要である。この共通構造は、数学モデリング環境の適切な場所に並列化され、グラフ記述言語（ＧＤＬ）を介して記述される。図６は、ＣＶＭで利用されるこの共通ブロック及び共通構造によるアプローチを概略的に描くものである。
【００５６】
追加のＣＣＳ（同時システムの微積分法）要件と資源割当て問題が存在するという点と、処理用エンジンの必要な‘臨界容量’がわずかに異なるという点とを除いて、２方向システムについても同様の分析を行うこともできる。
【００５７】
現在の世代のサード・パーティ・アプリケーションの開発用ツールと、ハードウェア配置用プラットフォーム（ＤＳＰ及びＤＳＰコア）とが、上述の構造的現実を反映していないこと、及び、（概して）通信ベースバンド・アプリケーションに合わせて仕立てられたハードウェアによる加速処理を行わないこと、また、２段階スケジューリング・アプローチ（下記を参照のこと）も行わないことは興味深いことである。また、現在の組み込まれたオペレーティング・システムでも系統的なあるいは統合化された方法での上記処理やアプローチのサポートは行われていない。
【００５８】
しかし、デジタル通信システムの数は急速に増加しつつあり、ベースバンド・スタックの研究開発から製品化までの短い期間内の市場への投入に対する要望が生まれている。以上説明したように、本発明の中核を成す革新的アプローチは、ソフトウェアにより提供された‘バーチャル・マシン層’（ＣＶＭの実施例により例示される）を提供し、これらの能力とソフトウェア構造とを具体化することにより、基底を成す共通性とこのようなシステム要件とを利用することである。１つの主要な市販アプリケーションは、（上述したような）ＳｏＣなどのハードによるリアルタイムの、マルチベンダの、マルチプロトコル環境に対する設計上のソリューションのようなものである。
【００５９】
ＣＶＭ開発方法論
ＣＶＭで用いられる開発方法論は、層化された開発と層化された配置を用いる方法論から出発し、この方法論を利用するものである。これらのコンセプトについて最初に解説する：層化された開発とは、（必要に応じて）数学モデルから、Ｃ＋＋またはＳＤＬコードを通じて、ターゲット・アセンブラの実現構成へ進むプロセスを意味する。このプロセスを通じてずっと、当該モジュールの各々は、必要なレベル（例えば、並列的数学モデル、Ｃ＋＋実現構成、ＳＩＭＤモデル及び様々なターゲット言語によるアセンブラの実現構成として畳み込み復号器が存在する）の各々に維持される。
【００６０】
層化された配置とは、受信機のスタックが実際に実現されたとき、基底を成すハードウェア及びホストのオペレーティング・システムから可能な限りコードを切り離すためにライブラリを利用することを意味する。したがって、可能な限り多くのコード（高度の複雑さと共に低ＭＩＰＳ要件）が、一般的ＳＤＬまたはＡＮＳＩ対応Ｃ＋＋（これはその後、ターゲット・プラットフォーム用として単純に再コンパイルされる）として保持される。例えば、単純なＩ／Ｏ、メモリ・バッファの割当てなどのようなプラットフォームに依存する機能を提供するためにライブラリが利用される。（ＦＦＴ、ビタビ復号器などのような）反復して使用される回数の多いルーチンをアーキテクチャ独自の方法で提供するために別のライブラリが利用される。このアーキテクチャ独自の方法には、好適に設計されたアセンブラル・ルーチンの利用や、特定用途のハードウェアによる加速処理用エンジンに対するコールスルー（ｃａｌｌｔｈｒｏｕｇｈ）の利用までも含むこともできる。
【００６１】
上記２つのライブラリは、基底を成すハードウェア及びオペレーティング・システムのサブストレートの如何に関らず、移植中修正を行う必要がない‘コア’コードとの共通のＡＰＩとして明白なものである。修正すべき唯一のコード、すなわちライブラリの実現構成の内容は、意味のあるカプセル化と数学モデルから生成される多種多様のテスト・ベクトルから利益を得る。その理由として、スタックの移植を高速に行うことが可能なアーキテクチャ内の接続ポイント（ｐｏｉｎｔ ｏｆ ａｒｔｉｃｕｌａｔｉｏｎ）が、上述のアプローチを用いて適切に配置されているということが挙げられる。
【００６２】
さらに、開発用プラットフォームとして、上記アプローチには、数学モデルを実行するのではなく、逆に完全なリアルタイム送受信装置を実行する１つのアーキテクチャ（インテルのプラットフォームなど）上で開発を行い、次いで、単純にライブラリのスワップを行い、ターゲットのアーキテクチャで再コンパイルを行うことが可能であるという大きな利点がある。これは、等化器モジュールの同調などを試みる際非常に有用なものとなる。
【００６３】
ＣＶＭによるアプローチは上記のような作業方法を利用するものである。しかし、これに加えて、すべてのデジタル通信用ベースバンド処理作業にとって有用な主要サービス及び機能と共に、可能な限り多くの共通の機能が分離されて‘バーチャル・マシン’のハードウェアの分離層の中へ入れられる。
【００６４】
以下の図７は、上記のことがアーキテクチャのレベルで機能する方法を示すものである。プラットフォームＡ用とプラットフォームＢ用の異なるライブラリの実現構成を備えて与えられるスタックを出荷する代わりに、ＣＶＭの中に、プラットフォームＡとプラットフォームＢの各々のための共通の‘ベースバンド・オペレーティング・システム’層が存在し、共通のＡＰＩが与えられる。この共通のＡＰＩの上で（再コンパイルを除いて）変らない状態のままさらに高いレベルのコードの実行が可能となる。
【００６５】
さらに、シンボル指向型の処理のためのシンボル・サブスクライバ（ｓｙｍｂｏｌ ｓｕｂｓｃｒｉｂｅｒ）アーキテクチャやデータ指示型処理のためのパイプライン・アーキテクチャのような、別様の場合、Ｃ＋＋コアの範囲内に存在するような機能の多くをこの層の中へ組み込むことが可能である。
【００６６】
具体的なＣＶＭ開発方法論：２段階スケジュリング
段階Ｉ
ベースバンド通信システムを構築する際の１つの重要な側面として、アプリケーションが実行される、ハードウェアとソフトウェアのプラットフォームとの要件の定量化がある。アプリケーションが要求するＭＩＰＳ（１００万命令毎秒）の回数のベースライン計算は比較的簡単であり、単に、１つの処理を実行するための、各コンポーネントの要求条件を計算し、処理回数を乗算し、それらすべてを一緒に加算するだけのものにすぎない。しかし、上記の中には並列要因のような側面は考慮されていない。２×５００ＭＩＰＳのプロセッサは理論的には１０００ＭＩＰＳの処理パワーを転送するとはいえ、別のチップでの処理の完了を待機している場合、アルゴリズムがこのパワーを利用できない場合もある。また、スケジュラの特別の処理要件、及び、考慮すべきデータ転送オーバーヘッドも存在する。２つのプロセッサが同じボード上に存在する場合、データ転送ペナルティはおそらく小さなものであるが、２つのプロセッサが１つの外部バスの中へプラグ・インされた別個の独立のボード上に存在する場合には、データ転送ペナルティはさらに大きなものとなる。バスの競合（２以上のプロセッサが同時にデータの転送を望むこと）によっても能率全体が低下する可能性がある。ＣＶＭによって、この種の分散型環境におけるシステムの実現を容易にするいくつかの方法が提供される。
【００６７】
最初に、付属説明１に記載されている信号処理用の関数などの個々の計算用コンポーネント要件、及び、付属説明１に記載されている信号処理機能に基づいて組み立てられるさらにアプリケーションに固有のエンジン要件の定量化が可能である。３Ｇ移動通信のような環境では、１つのブロックの内を通過するデータ量は時間中変動するため、１回のデータ転送速度で１つのブロックの要件を計算するだけでは十分ではない。その代わりに、プロファイルは潜在的入力ベクトル・サイズの範囲にわたって組み立てられる。
【００６８】
ＣＶＭによって、一方の端でデータを注入し、もう一方の端で消費するデータ・フロー（パイプライン）のコレクションとしてシステムを定義することが可能となる。これらのパイプラインのエンジンは、入力ベクトル・サイズの関数としてエンジンがどれだけ多くの処理を必要とするかという点から特徴づけられる。ＭＩＰＳの使用計算の第１のパスとして、このパイプラインに沿う、変動するサイズのエンジンの通過シミュレーションと、入力ブロック・サイズの関数としての上記使用合計の計算とが行われる。これにより、単一のプロセッサにおいて完了まで連続して実行したと仮定した場合のエンジンのＭＩＰＳ要件の合計が計算される。
【００６９】
さらに優れたモデルによってプロセッサを切り離すためにエンジンが割り当てられ、真のパイプライン接続が可能になる。このアーキテクチャに基づくソリューションは、シングルスレッドのソリューションよりもさらに多くのＭＩＰＳを必要とすることになるが、いったんパイプラインがロードされると、より短い経過時間でデータ・エンジンを処理できる可能性が生じることになる。Ｎをプロセッサの数、Ｅ（Ｎ）をプロセッサの利用効率（１＝１００％、０＝ゼロ）、Ｍｐを単一プロセッサのＭＩＰＳの定格、Ｍを当該ＭＩＰＳ要件の合計とすると、１秒のデータ処理時間Ｔは、下式で表される：
Ｔ＝Ｍ／（Ｅ（Ｎ）×Ｎ×Ｍｐ）
【００７０】
上式の目的はＮの最小値を見つけることである。但しＴは“ゆとりのある（ｃｏｍｆｏｒｔａｂｌｅ）”マージンの１未満の数とする。Ｅ（Ｎ）は、単一のボードの場合１に接近し、（スケジュリングとデータ転送により導入されるオーバーヘッドに起因して）ボード数の増加に伴い低下する。Ｅ（Ｎ）は、処理用エンジンがボード間でどのように分散されるかによっても変動する（この変動は、変動するデータ転送要件と、不規則な負荷バランスがプロセッサをしばらくの間アイドル状態に放置する可能性とに起因する）。
【００７１】
スケジュリング処理と、バスの特性と、エンジンの特性とに関する情報を持っているＣＶＭシミュレータは、様々な数のボードとエンジン構成についてＥ（Ｎ）したがってＴの計算を行うことができる。また若干のエンジンの“ダブルアップ（ｄｏｕｂｌｉｎｇ ｕｐ）”（２以上のボード上で同じ機能を持つこと）の影響を調査することも可能となる。
【００７２】
あるタスクのために必要な一続きのエンジンをいったん認知すると、ＣＶＭがセットされ、エンジンとボードの構成を介して最適解を探す探索が可能となる。ボードの個々のＭｐ値を出し（Ｎ×Ｍｐをこの個々のＭｐの和で置き換える）、特定のエンジンを特定のボードに結びつけることも可能となる。例えば、ビタビ復号器はＤＳＰよりも高いＭＩＰＳ定格を持つＦＰＧＡ上で常に実行する。多数のエンジンについての網羅的探索は実行不可能となるため技術者からの何らかの助けが必要となる。
【００７３】
段階ＩＩ
いったんエンジンとボードの受け入れ可能な構成が得られると、“本気で実行する”スケジュリング処理の段階ＩＩへ進むことができる。段階Ｉでは、正しいボード上へのエンジンのロードに使用することはできないシステム構成を生成したことになる。メインボードのスケジュラもこの情報を利用することが可能となる。いったんシステムが実行されると、データ・エンジンはスケジュラから、データに対して機能するエンジンへ流れる。ほとんどの時間、このスケジュラは単に、処理を必要とする順にデータを先へ送るにすぎないが、より多くの知能的処理の適用が可能となる場合が生じてくる。同等の優先順位を持つ複数のエンジンが存在する場合、スケジュラは、作業ロードが最少となるようにスケジュリングを行うことにより、すべてのボード上でキュー・サイズのバランスをとることを試みる。２以上のボード上に同じ機能が存在する場合、スケジュラはスケジュリングを行うための最適ボードを再び探索する。同じボード上の２つのエンジン間でエンジンのルート選定を行う際にメインのスケジュラの関与が不要となるように、すべてのボードにはローカルなスケジュラが設けられる。スケジュラは、作業を送るボード選択権がある場合、可能であれば自分のボードを常に選択する。またスケジュラは、ログ・メッセージのルート選定やモニタ用コンソールへの情報のモニタ・バックなどのような緊急性の少ない活動のスケジュリングが可能な場合には、処理時の潜在的小休止状態（ｌｕｌｌ）を探索することにより、最も緊急を要するエンジンの絶対的緊急性をモニタする必要がある。
【００７４】
さらなるＣＶＭ開発方法論：ＵＭＴＳでの実現構成で使用されるようなＭＩＰＳカウンタ
上述したように、ＣＶＭは、ＣＶＭスケジュラによって接続され、制御される複数の分散型エンジンから構成される。これらのエンジンは同じハードウェア上に位置するものであってもよいが、異なるハードウェア（ＣＰＵ、ＤＳＰまたはＦＰＧＡ）上に位置することも可能である。ＣＶＭのＵＭＴＳでの実現構成の場合、障害を特定し、エンジン／ブロックの連続化を助けるシステムが開発されている。まずデータ・ブロック用の処理ルートが与えられているものと仮定する。例えば、ＵＭＴＳ規格２５．２１２と２５．２２２、にはＴｒＣＨ段階でのブロックの多重化方法が提案されている。その場合、ＢＥＲのような何らかの客観的判断基準に応じてルート間で処理の若干を切り替えてもよい。しかし、必要なエンジンについては認知されている。次いで、データ・サイズとユーザの数という点からエンジンのサイズを決定しなければならない。例えば、ベクトルが長さｎで、かつ、エンジンが以下、
ｆｏｒ （ｉｎｔ ｉ＝０， ｉ ＜ ｎ， ｉ＋＋）
｛
ｆｏｒ （ｉｎｔ ｊ＝Ｏ， ｊ ＜ ｎ， ｊ＋＋）
｛
／／ Ｄｏ ｓｏｍｅｔｈｉｎｇ．．．
｝
｝
から構成されている場合、この処理はｎ２またはＯ（ｎ２）の次数であるということができる。次に、基本命令（（／／Ｄｏ ｓｏｍｅｔｈｉｎｇ’）内の‘＋’，‘−’，．．．）の数をカウントすることができる。例えば、ＦＦＴによってｎＬｏｇ（ｎ）回の演算処理が行われることになる。次いで、この演算回数に１基本命令当たりのデバイスの実行命令の回数を乗算し、次いで、これをＭＩＰＳの回数で除して、タスクの実行にデバイスが要する時間を得ることができる。或いは、単に相対時間を設定してもよい。
【００７５】
ユーザの数（Ｋ）について同じ処理を繰り返すことができる。例えばＭＵは２Ｋのような数になる場合もある。最終的に、各ブロックはビットレートの変更を行ってもよいし、行わなくてもよい。ターボ符号化によってビットレートは３倍だけ増え、ＣＲＣの使用により１２ビットが加算される。（バスの待ち時間、スケジュラ、並列化／連続化はすべてエンジンと考えることができることに留意されたい）
【００７６】
重要な点は当該データ転送速度がわかっているという点である。上記処理により解答が得られる問題として、エンジン（エンジンのＭＩＰＳ予算など）をどのように配分してその調整を行うようにすることができるかということが挙げられる。
【００７７】
トップ・ダウン方式による設計
状態制御とデータ制御とを必要とする場合、処理用チェーンの走査はきわめて複雑となる。この処理手順を用いて、標準的アダプタを介してＲＳの中にＣ＋＋ブロックが結びつけられ、Ｓｉｍｕｌｉｎｋとの統合化が行われる。基本的に、上記処理の意図は階層の中を移動することである。層を上位へ移動するほど抽象のレベルがだんだん高くなる。その意図は、３つのサービスについて‘ユーザ’が作成するデータのラウンド・トリップを行うことである。ＵＥによって、ある一定のプロパティを持つ物理チャネルを介してＢＳへのデータの送信が行われる。ＢＳは上記データを受信し、復号化する。この場合、ＢＳは簡単なバックホールを持ち、物理チャネルを介してデータを再転送して元のＵＥへ戻し、このＵＥで上記データは入力データと比較される。このシステムによってエンジンの入替えが可能になり、種々のチャネルにおけるＢＥＲと時間という点からパフォーマンスの改善が図られる。
【００７８】
ＣＶＭの特性
ＣＶＭは、ベースバンド処理スタックが必要とする種類の機能を提供する最低限のＯＳと考えることもできる（また、上述したように、これらのスタックはＧＳＭやブルートゥースのような２方向スタックであってもよい）。したがって、ＣＶＭは、マイクロソフト社のウィンドウズＣＥやシンビアン社のＥＰＯＣのような、本格的な内蔵型オペレーティング・システムと相補うものである。
【００７９】
ＣＶＭでは、（特に）下記の機能が提供される：
＊ ＦＦＴフィルタ、ＦＩＲフィルタ、ＩＩＲフィルタ及びウェーブ・ディジタル・フィルタ、及び、デシメーション、相関、複素乗算などのようなオペレーションをカバーする広範囲のセットのベクトル処理用プリミティブ（さらに多くのプリミティブが付属説明１に完全にリストされている）上記オペレーションは、基底を成すハードウェアで加速処理が利用可能なハードウェアによる加速処理を利用することが望ましく、さらにこれらのオペレーションは、ライブラリの拡張バージョンを並列化する１組のライブラリ呼出しを介してアクセスされることになる。ある意味では、ＣＶＭのこの側面は、デジタル通信を行うための理想化されたデジタル信号処理用エンジンのソフトウェアまたはＡＰＩの抽象的な形を表すものである。
＊ 整列バッファの割当てと、メモリ‘ハンドシェーキング’（ピンポン・バッファ）とのサポート
＊ 単純な種類のプリエンプティブ・マルチスレッドのオプションを備えた高度スケジュリング管理ハードウェアによるリアルタイム・パフォーマンス（すなわち、ある特定の時点に１つのコードが処理を実行する）がアーキテクチャの主要なコンポーネントとしてサポートされる。プロセス間通信構造（少なくとも共有メモリ）とスレッド同期ファシリティとが提供される。主要な特長として、確率的並列スケジュラがあり、このスケジュラは計算用異種サブストレートの両端にわたるＣＶＭエンジンに対する設計時間の分割の決定を認識するものである。
＊ シンボル指向型及びデータ指向型処理についての概念の明示的サポート、これは、シンボル・サブスクライバ（ｓｙｍｂｏｌ ｓｕｂｓｃｒｉｂｅｒ）とパイプライン段階とを構造の中へ付加してモジュラ型の開発を可能にする能力を直接サポートするものである。
＊ シリアルポート、パラレルポート及び表示制御装置を含む主要なＩ／Ｏ周辺機器のサポート
＊ 特に、モジュラ型Ｉ／ＯサポートのＯ／Ｓの範囲の拡大を可能にする拡張性
＊ 数学モデルとリアルタイム・プロトタイプとが、ターゲット・サブストレートと相互接続とのパフォーマンスのシミュレーションを高度の正確さで行うことを可能にする特定の実現構成についての特性ライブラリ
＊ リアルタイム・プロトタイプの製造を可能にするＰＣバージョン
＊ ホスト（アプリケーション）のＯＳとの通信のサポート：この通信はコールバック等々を可能にする双方向通信となる。２進‘グルー’を行うためにコンポーネント相互通信技術（ＣＯＭなど）を利用してもよい。好適なアプリケーション用ＯＳとしては、例えばＥＰＯＣ３２やウィンドウズＣＥであってもよい。なぜなら、これらのＯＳは、より一般的なユーザ・レベルのＩ／Ｏと、構造化された記憶管理とを実行するように設計されたＯＳであるからである。
＊ 最小の（したがって最終的にはチップ面積の）ＲＯＭの利用を保証するために組立てタイム（ｂｕｉｌｄ ｔｉｍｅ）においてＣＶＭのＲＯＭ画像を‘削減する（ｐａｒｅ ｄｏｗｎ）’能力 これはＣＶＭの最低限の実現構成を利用するものである。
＊ ステートマシンの機能管理（ＳＤＬとの潜在的統合化を含む）
＊ データ構造のサポート
＊ （固定小数点や浮動小数点などのような）異なる表現間の変換
【００８０】
ＣＶＭの目標は、開発段階での多数のアプリケーションを用いて、特定アプリケーションの高速な利用を特定のターゲット上で可能にすることである。従来のＯＳは、ＯＳがロードされたとき実質的に未知の種々のアプリケーションの実行時サポート用として設計されているが、一般にＣＶＭについては事実はそうではない。さらに、ＣＶＭは、‘ホスト’のＯＳが提供するポータルを介するプレゼンテーション・ストリームのサポートによる処理を除いて、ユーザとのインタラクション処理を必要としない。
【００８１】
ＣＶＭは、インフラ・ストラクチャ・レベル（シンボル指示型及びデータ指示型処理の開発のための適切なモジュラ型構造など）の中へＤＡＢスタックの高レベルのＣ＋＋コードの中に現在存在するいくつかの特性を組み込んでおり、単なる‘ライブラリ・ラッパ’ではない。
【００８２】
ＣＶＭというコンセプトは、共通機能の分離と、（重要なことであるが）最新のデジタル放送及び通信規格によって求められる処理構造の分離とが可能であり、系統的に層化された開発環境と結合された適切なソフトウェア分離層を介して、これらの分離のエレガントな達成が可能であるという着想（様々な規格のレビューによってしか達成できないドメイン情報と、実際のスタックの構築処理とに大きく依存する）に基づくものである。
【００８３】
ＣＶＭの利点
ＣＶＭでは、スタックの開発者たちは使用中の特定のハードウェアから切り離される。ＣＶＭとは、（シンボル指示型及びデータ指示型パイプライン及びステートマシンなどの）構造と、（メモリ割付け、リアルタイム資源、同時性管理など）機能と、デジタル通信用ベースバンド・スタックにより求められる（ＦＦＴ、ビタビ、畳み込みなどの）ライブラリとをサポートし、それによって、高水準言語（ＳＤＬ、ＡＮＳＩＣ／Ｃ＋＋またはＪａｖａ）によるコードの１回の書込みと、単なる再コンパイル（必要な場合には、Ｊａｖａを用いてコードの再コンパイルを行わずに、ＣＯＭまたはコンポーネントの相互通信技術の何らかの別の形により‘２進レベルの’グルーを行ってモジュールを一緒にリンクすることも可能である）とが可能になるようにして、特定のプラットフォーム上で実行し、それによってＣＶＭ層により供給されるハードウェア分離層を介して呼出しを行うようにするものである。
【００８４】
ＣＶＭを用いるプロトタイピングは非常に高速なものとなり、ＤＳＰモジュールの各々は数学モデルにより並列に設けられる。メモリ割付けと分割は、推測作業に依拠するのではなく、（所望のターゲット・ハードウェアによりパラメータ化された）自動化されたツールセットによりサポートされる。いったん処理用チェーンがモデルに対して設定され（この設定は、符号化の代わりにこのグラフィック構成とパラメータ化とによりオプションとして実行される）、作業が首尾よく行われていると、リアルタイムのＰＣベースのバージョンの実行が可能になる（ＲａｄｉｏＳｃａｐｅ社の汎用ベースバンド・プロセッサ・モジュールを備えたＣＶＭのＩｎｔｅｌ ＭＭＸ／ＳＩＭＤバージョンが用いられる）。（カスタム等化器などの）標準的コードに対する任意の変更をモジュラ型増分方法で統合化することが可能であり、さらに（ＰＣベースの）符号化／テスト／編集サイクルはすべての最新のＰＣ開発用ツールを利用することもでき、非常に高速なものとすることも可能となる。ターゲット・プラットフォームでのハードウェア加速処理の利用がＣＶＭによりカバーされている（これは、デジタル通信のベースバンド処理のための、多くのサイクルを要する所要の特性がＣＶＭ ＡＰＩでのライブラリ呼出しとして提供されるためである）。好適に適合された基底を成すハードウェア・ユニットによって、所望の機能のほとんどのためのターゲットとする加速が与えられることは明らかである。多くのアプリケーションの場合、軽量のプリエンプティブ・マルチスレッドと、ＣＶＭ自体でのその他の低レベルの機能とをサポートすることにより、何らかの別のＲＴＯＳの利用は不要となるが、（ウィンドウズＣＥやシンビアンのＥＰＯＣなどのような）ユーザのＯＳとのインタラクションは上述のＡＰＩを介してサポートされ、単純になる。
【００８５】
このアプローチでは、いったん書き込まれたＣＶＭ互換スタックは、特別の作業を伴うことなく、ＣＶＭ自身が移植されたハードウェアのプラットフォームのいずれへも瞬時に移植可能となる（言うまでもなく、リアルタイムで所望のスタックを実行するための十分な資源（ＭＩＰＳ、メモリ、帯域）がターゲット・マシンに常に存在するものと仮定する）。こののことは、（多くのタイプのハードウェアで使用できる適正なＣＶＭのプラットフォームが市場に浸透すると仮定すると）スタック・ベンダにとって実質的な販売の機会が生じることを表すものである。というのは、これはハードウェアの特殊性からスタック・ベンダの開発を実質的に切り離すものであるからである。また、マルチベンダＳｏＣ製品を設計するための特にめざましいビジネス・チャンスも生じる。
【００８６】
ハードウェア・ベンダの視点から見ると、ＣＶＭの利点として、ＣＶＭがいったん所定のプロセッサ用として移植されると、当該プロセッサが、（資源が許せば）ＣＶＭ ＡＰＩに対して書き込まれたすべてのスタックを自動的にサポートするということが挙げられる。言うまでもなく、このことによって、ハードウェア・プロバイダはアプリケーション・ビジネスの中へ入ってゆくことが不要になる。彼らはＣＶＭを移植するだけで十分となる。またこのことは、（少なくともデジタル通信マーケット向けの）スタック・ベンダが、その場合、ＡＮＳＩ Ｃ／Ｃ＋＋またはＪａｖａで純粋にコードを開発することができるので、完全仕様の開発環境とツールセットを形成しサポートする必要性が少なくなることも意味する。ＣＶＭというコンセプトは、例えば、自動車用ブレーキ・システムで使用されるＰＩＤコントローラを作るというような、すべてのデジタル信号処理タスクに適用されるというわけではないことに留意されたい。ＣＶＭのコンセプトがデジタル通信用ベースバンドの処理用として機能する理由として、上記に説明したように、利用が可能なこのようなシステムの中に共通性を示す広いプールが存在することが挙げられる。しかし、ＣＶＭは、別のデジタル信号処理タスクに必要とされるようなすべてのツール、構造あるいは機能を必ずしも提供するものではない。言うまでもなく、共通の機能を示す別のそのような‘島（ｉｓｌａｎｄ）’を特定し、それらの‘島’のニーズをカバーするＣＶＭのイディオム（ｉｄｉｏｍ）の拡張を行うことは潜在的には可能であろう。しかし、本願出願人は本明細書においてベースバンドの側面に焦点を絞っている。なぜなら、ベースバンドの側面が現在非常に求められており、さらに必要な共通性が強く示されているからである。ＣＶＭによるアプローチは、ハードウェア・ベンダが、既存のアプリケーション・セットではなく、代わりに、それらのハードウェアの長所（ＭＩＰＳ、ターゲットの加速、メモリ、電力消費量など）に関して自由に競争ができるようにするものである。
【００８７】
ＣＶＭ開発サイクル
実際にＣＶＭを利用してベースバンド・スタックを開発するプロセスについて以下説明する。本明細書の目的として、デバイスが、デジタル無線装置などのような開発中の目標であることが挙げられる。ソフトウェア、ハードウェアあるいはその双方のいずれかであるコンポーネントは上記デバイスの特定可能な或る特定の一部である。‘解釈される’という表現は、実行時に構成を読み込む（おそらくコンパイルされた）コードを意味する。
【００８８】
開発サイクルは‘コンポーネント定義言語’から始まる。この言語によって、コンポーネントの完全な外部からの可視属性の特定並びにその振舞いが可能になる。その意図として、メーカーがこの可視属性を書き込むことが可能であること、あるいは（後程見るように）計装化ＣＶＭの試運転によりこの可視属性の生成が可能であることが挙げられる。
【００８９】
プラグ・インを介して、業界でポピュラーなＭａｔｌａｂやＭｔｈｅｍａｔｉｃａのような数学モデリング用ツールに１組のコンポーネント定義言語を読み込むことができる。モデリング用ツールを用いて、デバイスで使用するすべてのコンポーネントの理論上の振舞いが利用され、理解される。
【００９０】
上記調査の結果は、開発される別のプラグ・インを介して、‘デバイス定義言語’の中へ転記または出力のいずれかが行われる。ちょうどコンポーネント定義言語がコンポーネントを定義するように、この‘デバイス定義言語’は、構築されているターゲット・デバイスを定義し、さらに、どのコンポーネントが使用されているかというような要素を含むことになる。
【００９１】
言い替えれば、デバイス定義言語は、開発中の通信用‘パイプライン’を定義するものである。ほとんどの通信用デバイスは、パイプラインを介して情報を動かし、その途中で変換を実行するプロセスであると考えることができるので、このパイプラインというコンセプトは重要である。このパイプラインは実際には電子的なアセンブリ・ラインであるが、自動車の部品で機能するようなものではなく、一般に‘シンボル’と呼ばれるデータ項目に対して機能するものである。このようにして、無線信号が最終的にオーディオ信号へ変換されることになる。言うまでもなく、‘現実の’デバイスは単純なパイプラインよりも複雑であることが多く、２以上のパイプライン、ブランチまたはループを備えている場合もある。完全なハードウェア・バージョンを組み立てる前に、このＣＶＭ開発プロセスによりパイプライン設計のテストを行うことが可能となる。これは開発期間の短縮につながるものとなる。
【００９２】
ターゲット・デバイスまたはパイプラインを完全に定義するためにはさらに多くの情報が必要となる。また、本発明のターゲットで利用可能な（ＣＰＵの速度などのような）資源についての説明も必要であり、これは‘適合性記述用言語’と相互接続とで定義される。また各コンポーネント（物理的及びソフトウェアの双方のＡＰＩ）がどのように使用されるかを知っている必要がある。これはコンポーネントＡＰＩ仕様を用いて達成される。
【００９３】
これらの３つの資源：デバイス定義言語、適合性記述用言語及びコンポーネントＡＰＩ仕様はいくつかの可能なＣＶＭの中の１つの範囲内で使用される。第１のＣＶＭは‘計装化され解釈された’パイプライン・マネージャ（あるいは、好適には、計装化され解釈されたバージョンよりもさらに高速に作動する計装化されコンパイルされたＣＶＭのほうが望ましい）である。このパイプライン・マネージャは、ソフトウェアＩＣＥとの或る類似性を有するものである。このマネージャは上記３つの資源を読み出し、パイプラインのエミュレーション（エミュレーションはリアルタイムであってもよい）を行う。したがって、このマネージャはターゲットが無線装置である場合、無線装置として実行する。適合性記述用言語に起因して、このマネージャはターゲット・デバイス上に存在するいずれの障害または資源の限界のシミュレーションをも行うことができ、また、開発とデバッギングとを行うために有用なものである。実行に加えて、計装化され解釈された／または計装化されコンパイルされたパイプライン・マネージャは、各デバイス内コンポーネント定義言語のための診断情報も出力する。この診断情報は重要である。というのは、この情報を今度は開発サイクルの中へフィードバックし、元のコンポーネント定義言語による記述とマージして、その記述の微調整を行うことができるからである。したがって、何らかのハードウェアの組立てを行う前に設計者が実際のパフォーマンスに関する情報を利用することが可能となり、これによって（実質的に）開発の節減が行われる。これによって開発サイクルの内部ループが閉じられる。計装化され解釈された、あるいは、計装化されコンパイルされたパイプライン・マネージャにより、ＣＶＭコアの実行時バージョンが組み込まれる。計装化され解釈された、あるいは、計装化されコンパイルされたパイプライン・マネージャのソフトウェア・エレメントをハードウェアのバージョンと交換する（バグが生じたときバグの検出が可能となるように理想的には１回一度）ことが可能である。この交換されたエレメントは別の開発プロセスのための改善となる。この改善は、計算用サブストレートの両端にわたるエンジンの設計時間段階のスケジュリング処理（上記を参照されたい）に対応するものである。
【００９４】
第２のＣＶＭは‘解釈されたパイプライン・マネージャ’である。この第２のＣＶＭは計装化されたものではないが、別の点では第１のＣＶＭと同一のものである。この第２のＣＶＭは開発とデバッギング時に利用することができ、また、メーカーが完成製品を製造するために利用することができる。このＣＶＭには、通信用デバイスの書込み時の作業の多くを予め行うという第３の利点がある。このＣＶＭにもやはりＣＶＭコアの実行時バージョンが組み込まれている。
【００９５】
第３のＣＶＭは‘パイプライン・ビルダ’である。この第３のＣＶＭはコンパイルされた非計装化変形例と考えることができる。他の２つのＣＶＭのように、この第３のＣＶＭも３つの資源を読み出すが、実行する代わりに、Ｃ言語のようなコンピュータ・ソースコードを出力し、このコードをコンパイルしてパイプラインの実現構成の形成が可能となる。この理由のため、パイプライン・ビルダは、ＣＶＭライブラリを利用できなければならない。利用できるか否かをチェックすることにより開発サイクルの外側のループが閉じられる。ＣＶＭ開発サイクルのアプローチ全体が図８と９に概略的に示されている。
【００９６】
本明細書の従来技術についてのセクションで、テキサス・インスツルメント社から出ている「ｅＸｐｒｅｓｓＤＳＰ（ｅＸｐｒｅｓｓＤＳＰ）リアルタイム・ソフトウェア技術」の存在が認められた。ＣＶＭが有する主要な進歩は当業者には明らかであろう。この進歩の中には以下のことが含まれる：
＊ ｅＸｐｒｅｓｓＤＳＰそれ自体はバーチャル・マシン層ではない。
＊ ＣＶＭによって、単にバーチャル・マシンの移植により様々なＤＳＰプラットフォーム間の移植性が可能になる。ＣＶＭは（ＴＩ社のシステムのように）１つのプラットフォームにのみ結びつけられているものではない。
＊ ＣＶＭには数学モデリングルとの統合化が含まれる。
＊ ＣＶＭによって、ＤＳＰベースのツールの能力に劣らないＰＣベースのツールを利用するスタック開発が可能になる。
＊ ＣＶＭには、ＰＣ上での‘リアルタイム’のプロトタイプを形成して、ターゲット環境上へ１つずつモジュールを移動させる能力が含まれる。
＊ ＣＶＭには、標準的コード・セットの実行により資源タイミングを生成し、次いで、この資源タイミングから‘アーキテクチャ記述プロファイル’を生成する能力が含まれる。
＊ ‘高いサイクル’のルーチンのほとんどは、一般的‘リアルタイムのソフトウェア基盤’の代わりにベースバンド通信エンジンの信号処理要件の方へ方向づけられているＣＶＭ‘環境の中に’予め存在するので、ＣＶＭによって高水準言語を用いる開発が可能になる。
＊ またＣＶＭでは、ベースバンドＤＳＰに共通して必要とされる、データの種類と、動的資源と、バッファ管理とが含まれる。
＊ ＣＶＭでは演繹的資源予測と同時性分析とが行われる。
＊ ＣＶＭには単に機能エレメント（ＡＰＩ）が含まれるだけではなく、起呼構造（ＤＳＰコードがどのように動的に機能するか）並びに（ＰＣベースのプロトタイピングと、最終的エンド・ターゲットを通じての数学モデリング、資源モデリングによる）全体的な開発パラダイムの支援も含まれる。
＊ ＣＶＭによって、所望の場合サード・パーティのＲＴＯＳの利用が可能になり、さらに、所望の場合ＲＴＯＳなしの機能も可能である。
＊ ＣＶＭは２段階スケジュリングを提供する。
＊ ＣＶＭにより、ＡＳＩＣとＳｏＣへ移行する利点が可能になる。
＊ ＣＶＭによって、完全に統合化され、しかも、プラットフォームから独立したランタイムと設計用ツールとが提供される。
―附属説明―
コア処理の例
信号変換と周波数領域分析
＊ 信号フローグラフ（ＳＦＧ）離散周波数ＤＦＴ
＊ ウィンドウ操作（ハミング、ハニングなど）
デジタル・フィルタリング
＊ デジタルＦＩＲフィルタ
＊ インパルス応答
＊ 周波数応答
＊ ＦＩＲ低域デジタル・フィルタ
＊ 無限インパルス応答デジタル・フィルタ
適応信号処理
＊ 適応型デジタル・フィルタを含む適応信号処理用コンポーネント
＊ チャネル識別
＊ エコー・キャンセレーション
＊ 音響エコー・キャンセレーション
＊ 暗騒音抑制
＊ チャネル等化
＊ 適応型ライン拡張機能（ＡＬＥ）
＊ 以下を含む適応型アルゴリズム：
＊ 平均２乗誤差の最少化
＊ ＦＩＲフィルタ用適応型アルゴリズム
＊ 平均２乗誤差
＊ 最小平均２乗誤差の解
＊ ウィーナ／ホップ（Ｗｉｅｎｅｒ−Ｈｏｐｆ）解
＊ 傾度法１
＊ 傾度法２
＊ ＬＭＳアルゴリズム
＊ 再帰的最小２乗法
＊ 適応型ＩＩＲフィルタリング
＊ 勾配ＩＩＲフィルタリング技術
＊ ＦｅｉｎｔｕｃｈのＩＩＲ ＬＭＳ
＊ 等式誤差ＬＭＳアルゴリズム
＊ 直接モード（ＤＤＭ）
＊ サブバンド適応型フィルタ（ＳＡＦ）構造
マルチレート信号処理
＊ アップサンプリング＆ダウンサンプリング
＊ 内挿ローパス・フィルタ
＊ オーバーサンプリングと再構成
＊ シグマ／デルタ処理アーキテクチャ
＊ サブバンド処理
＊ 反復によるＭチャネル・フィルタ・バンク
＊ 変調フィルタ・バンク
＊ 多相フィルタ・バンク
＊ ＱＭＦフィルタ・バンク
オーディオ信号ソース符号化
＊ 無損失ハフマン（Ｈｕｆｆｍａｎ）符号化／復号化
＊ 線形ＰＣＭ
＊ 圧伸
＊ 適応型量子化ツール
＊ 線形予測符号化
＊ 長期予測
＊ デルタ変調（ＤＭ）
＊ 差分パルス符号変調
＊ 適応型ＤＰＣＭ（ＡＤＰＣＭ）ＬＰＣボコーダ
＊ 符号励振線形予測（ＣＥＬＰ）
＊ 代数的ＣＥＬＰ（ＡＣＥＬＰ）
＊ サブバンド符号化
＊ 精神聴覚学用ツール
＊ スペクトル・マスキング
＊ 時間マスキング
＊ 精度適応型サブバンド符号化及びビット割当て及びビット・ストリーム・フォーマッティング・ツール
デジタル変調
＊ ＸＯＲ長短コード拡散／逆拡散
＊ 振幅変調
＊ 直角振幅変調（ＱＡＭ）
＊ 直角位相復調
＊ 複雑な直角位相変調
＊ 複雑な直角位相復調
＊ ＱＰＳＫ
＊ ｎ−ＰＳＫ
＊ Ｍ−ａｒｙ振幅偏移キーイング
＊ π／ｎＱＰＳＫ
＊ ユニポーラＲＺ及びＮＲＺシグナリング
＊ 極座標及びバイポーラＲＺ及びＮＲＺシグナリング
＊ 以下を含む帯域通過偏移キーイング
＊ 振幅（ＯＮ−ＯＦＦ）偏移キーイング
＊ ２進位相偏移キーイング（ＢＰＳＫ）
＊ 以下を含む周波数偏移キーイング
＊ ＢＰＳＫ用帯域フィルタリング
＊ 以下を含むパルス成形
＊ ナイキスト・パルス成形
＊ ２乗余弦パルス成形
＊ 平方根２乗余弦パルス成形
拡散スペクトル・ツール
＊ 擬似乱数コード生成
＊ 黄金シーケンス
＊ カサミ・シーケンス
＊ 直交拡散符号
＊ 可変長ＯＣ生成
＊ 直交ウォルシュ・コード
＊ コード検出
＊ レイク受信装置実装
＊ 以下を含むＮＢＩ拒絶技術
＊ 予測フィルタ
＊ 変換領域におけるＮＢＩ拒絶
＊ 決定フィードバックＮＢＩ拒絶
多元接続＆検出管理用ツール
＊ 以下を含むＴＤＭＡ
＊ ＴＤＭＡフレーム
＊ ＦＤＭＡと合成されたＴＤＭＡ
＊ 以下を含むＣＤＭＡ
＊ 直接シーケンス（ＤＳ）ＣＤＭＡ
＊ 電力制御
＊ ビーム成形用ツール
＊ 周波数ホッピングＣＤＭＡ
＊ マルチユーザ検出（ＭＵＤ）
＊ 多元接続干渉抑制
＊ 非相関性
＊ 干渉キャンセラ
＊ 適応型ＭＭＳＥ
＊ ＭＭＳＥ受信機トレーニング
＊ 適応型ＭＭＳＥ受信機ＤＤＭ
移動チャネル
＊ レイリー・フェージング抑制メカニズム（ガウス、Ｒｉｃｅｉａｎ）
＊ 以下を含むモデリング及び抑制用ツール：
＊ タイム・スプレディング
＊ タイム・スプレディング：コヒーレンス帯域
＊ タイム・スプレディング：平坦フェージング
＊ タイム・スプレディング：Ｆｒｅｑ選択フェージング
＊ チャネルのタイム変形振舞い
＊ ドップラ効果
チャネル符号化
＊ 巡回符号器
＊ リード・ソロモン（Ｒｅｅｄ Ｓｏｌｏｍｏｎ）符号器
＊ 畳み込み符号器
＊ ＣＥパンクチャリング
＊ インターリービング
＊ 畳み込み復号器
＊ ビタビ復号器（ハード及びソフト決定）
＊ ターボ・コード
＊ ターボ符号化
＊ ターボ復号化
等化
＊ 適応型チャネル等化
＊ ＦＩＲ等化器
＊ 決定フィードバック等化器
＊ 直接変換ツールキット
＊ ＱＡＭアナログＲＦ／ＩＦアーキテクチャ
＊ ＱＡＭ ＩＦダウンコンバージョン・サポート
＊ 帯域通過シグマ・デルタサポート
＊ ベースバンド・サポートへの帯域通過シグマ・デルタ
＊ 帯域通過及びｆｓ／４システム
信号処理ライブラリ関数
このセクションはＣＶＭで利用可能な信号処理関数の若干について説明する。
＊ ベクトル操作関数
ＡｕｔｏＣｏｒｒｅｌａｔｅ 入力ベクトルの通常の、バイアスをかけたあるいはバイアスをかけていない自己相関を推定し、その結果を第２のベクトルに格納する
Ｃｏｎｊｕｇａｔｅ （ｖｅｃｔｏｒ） ベクトルの複素共役を計算し、その結果を対応する当該レジスタ又は別のベクトルに返すことが可能である。
Ｃｏｎｊｕｇａｔｅ （ｖａｌｕｅ） 複素数値の共役を返す。
Ｅｘｔｅｎｄｅｄ Ｃｏｎｊｕｇａｔｅ 対応する当該レジスタ又は新しいベクトルでベクトルの共役／対称拡張を計算する。
Ｅｘｐ 各エレメントが、入力ベクトル内の対応するエレメントのパワーに対してｅであるベクトルを計算する。この結果は対応する当該レジスタ又は別のベクトルに返すことができる。
ＩｎｖｅｒｓｅＴｈｒｅｓｈｏｌｄ 閾値を用いてベクトルの逆エレメントを計算する。この結果は対応する当該レジスタ又は別のベクトルに返すことができる。
Ｔｈｒｅｓｈｏｌｄ ベクトルで閾値演算処理を実行する。この結果は対応する当該レジスタ又は別のベクトルに返すことができる。
ＣｒｏｓｓＣｏｒｒｅｌａｔｅ ２つのベクトルの相互相関を推定し、第３のベクトルにその結果を格納すする。
ＤｏｔＰｒｏｄｕｃｔ ２つのベクトルに対してＥｘｔｅｎｄｅｄＣｏｎｊｕｃａｔｅ演算を適用後、２つのベクトルの点乗積を計算する
ＥｘｔｅｎｄｅｄＤｏｔＰｒｏｄ ２つの共役シンメトリック拡張ベクトルの点乗積を計算する
ｄｏｗｎｓａｍｐｌｅ 或る信号をダウンサンプルし、概念的に或る整数係数分だけそのサンプリング速度を落とす。第２のベクトルにその結果を返す。
Ｍａｘ ベクトルで最大値を返す。
Ｍｅａｎ ベクトルでエレメントの平均値を計算する。
Ｍｉｎ ベクトルで最小値を返す。
ｕｐｓａｍｐｌｅ 或る信号をアップサンプルし、概念的に或る整数係数分だけそのサンプリング速度を上げる。第２のベクトルにその結果を返す。
ＰｏｗｅｒＳｐｅｃｔｒｕｍ （１） 第２のベクトルで複素ベクトルのパワー・スペクトルを返す
ＰｏｗｅｒＳｐｅｃｔｒｕｍ （２） 実数成分と虚数成分が２つのベクトルで表される複素ベクトルのパワー・スペクトルを計算する。第３のベクトルにその結果を格納する。
Ａｄｄ ２つのベクトルを加算し、第３のベクトルにその結果を格納する。
Ｓｕｂｔｒａｃｔ １つのベクトルを別のベクトルから減じ、第３のベクトルにその結果を格納する。
Ｍｕｌｔｉｐｌｙ ２つのベクトルを乗算し、第３のベクトルにその結果を格納する。
Ｄｉｖｉｄｅ １つのベクトルを別のベクトルで除し、第３のベクトルにその結果を格納する。
＊ 複素ベクトル演算
ＩｍａｇｉｎａｒｙＰａｒｔ 第２のベクトルで複素ベクトルの虚数部分を返す。
ＲｅａｌＰａｒｔ 第２のベクトルで複素ベクトルの実数部分を返す。
Ｍａｇｎｉｔｕｄｅ （１） 複素ベクトルの要素の振幅を計算し、第２のベクトルにその結果を格納する。
Ｍａｇｎｉｔｕｄｅ （２） この第２のバージョンは、個々の実ベクトルで指定された実数成分と虚数成分を持つ複素ベクトルの要素の振幅を計算し、第３のベクトルにその結果を格納する。
Ｐｈａｓｅ （１） 第２のベクトルで複素ベクトルの要素の位相角を返す
Ｐｈａｓｅ （２） それぞれ実ベクトルと、虚ベクトルで指定される実数成分と虚数成分とを持つ複素入力ベクトルの要素の位相角を計算する。この関数は、第３のベクトルに結果として生じる位相角を格納する。
ＣｏｍｐｌｅｘＴｏＰｏｌａｒ 個々の入力ベクトルの実数／虚数（デカルト座標Ｘ／Ｙ）の対を極座標形式に変換する。１つのバージョンは、１つのベクトルに各要素の成分の振幅（半径）を格納し、別のベクトルに各要素の位相（角）成分を格納する。
ＣｏｍｐｌｅｘＴｏＰｏｌａｒ 第２のバージョンは、単一ベクトルで（振幅、位相の）対として極座標を返す。
ＰｏｌａｒＴｏＣｏｍｐｌｅｘ ベクトルに格納される極形式（振幅、位相）の対を複素ベクトルに変換する。この結果を第２のベクトルで返す。
ＰｏｌａｒＴｏＣｏｍｐｌｅｘ 個々のベクトルに格納された極形式の振幅／位相の対を複素ベクトルに変換する。この関数は第３のベクトルにその結果の実数成分を格納し、第４のベクトルに虚数成分を格納する。
ＰｏｌａｒＴｏＣｏｍｐｌｅｘ ２つの個々のベクトルに格納された極形式の振幅／位相の対を複素ベクトルに変換する。この関数は、第３のベクトルにその結果の実数成分を格納し、第４のベクトルに虚数成分を格納する。
＊ サンプル量子化
これらの方法は線形と非線形量子化方式との間での変換を行う。使用ビット数と、使用非線形パラメータとは変更してもよい。
ＡｌａｗｔｏＬｉｎｅａｒ Ａ−ｌａｗ符号化サンプルのベクトルを線形サンプルへ変換する。この結果は対応する当該レジスタ又は別のベクトルに返すことができる。
ＬｉｎｅａｒＴｏＡＬａｗ 線形サンプルベクトルを符号化する。この結果は、Ａ−ｌａｗフォーマットを用いて、対応する当該レジスタ又は別のベクトルに返すことができる。
ＬｉｎｅａｒＴｏＭｕＬａｗ ｐｔ−ｌａｗを用いてベクトルで線形サンプルを符号化する。この結果は対応する当該レジスタ又は別のベクトルに返すことができる。
ＭｕｌａｗＴｏｌｉｎｅａｒ ８ビットｋｔ−ｌａｗの符号化されたサンプルのベクトルを線形フォーマットに変換する。この結果は対応する当該レジスタ又は別のベクトルに返すことができる。
＊ サンプル生成関数
ＲａｎｄｏｍＧａｕｓｓｉａｎ ガウス分布を用いて疑似ランダム・サンプルのベクトルを計算する。
ＩｎｉｔｉａｌｉｓｅＴｏｎｅ 所定の周波数、位相及び振幅を用いて正弦波発生装置を初期化する。
ＮｅｘｔＴｏｎｅ ＩｎｉｔｉａｌｉｓｅＴｏｎｅを用いて指定された周波数、位相、振幅の正弦波の次のサンプルを生成する。
ＩｎｉｔｉａｌｉｓｅＴｒｉａｎｇｌｅ 所定の周波数、位相及び振幅を用いて三角波発生装置を初期化する。
ＮｅｘｔＴｒｉａｎｇｌｅ ＩｎｉｔｉａｌｉｓｅＴｒｉａｎｇｌｅのパラメータを用いて生成された三角形波の次のサンプルを生成する。
＊ ウィンドウ関数
ｂａｒｔｌｅｔｔｗｉｎｄｏｗ ベクトルにＢａｒｄｅｎｔウィンドウ関数を乗算する。その結果は第２のベクトルで返される。
ＢｌａｃｋｍａｎＷｉｎｄｏｗ ユーザ指定パラメータを用いてベクトルにＢｌａｃｋｍａｎウィンドウ関数を乗算する。その結果は第２のベクトルで返される。
ＨａｍｍｉｎｇＷｉｎｄｏｗ ベクトルにＨａｍｍｉｎｇウィンドウ関数を乗算する。その結果は第２のベクトルで返される。
ＨａｎｎＷｉｎｄｏｗ ベクトルにＨａｎｎウィンドウ関数を乗算する。その結果は第２のベクトルで返される。
ＫａｉｓｅｒＷｉｎｄｏｗ ベクトルにＫａｉｓｅｒウィンドウ関数を乗算する。その結果は第２のベクトルで返される。
＊ 畳み込み関数
Ｃｏｎｖｏｌｖｅ ２つのシーケンスの有限、線形畳み込みを実行する。
Ｃｏｎｖｏｌｖｅ２Ｄ ２つの２次元信号の有限、線形畳み込みを実行する。
Ｆｉｌｔｅｒ２Ｄ Ｃｏｎｖｏｌｖｅと類似の２次元信号をフィルタする。但し、同じサイズの入出力配列を用いる。
＊ フーリエ変換関数
これらの方法のバージョンは、複数の異なるデータ格納（固定型、浮動型、整数型）フォーマット用のものが存在する。
ＤｉｓｃｒｅｔｅＦＴ 対応する当該レジスタ又は別のベクトルで離散フーリエ変換を計算する。
ＩｎｉｔｉａｌｉｓｅＧｏｅｒｔｚ Ｇｏｅｒｔｚｅｌ関数により使用されるデータを初期化する。
ＲｅｓｅｔＧｏｅｒｔｚ Ｇｏｅｒｔｚｅｌ関数により使用される内部遅延ラインをリセットする。
ＧｏｅｒｔｚＦＴ（１） 単一信号カウント用の所定の周波数についてＤＦＴを計算する。
ＧｏｅｒｔｚＦＴ（２） 連続する信号カウント・ブロック用の所定の周波数についてＤＦＴを計算する。
ＦＦＴ （１） 対応する当該レジスタ又は別のベクトルのいずれかでベクトルの複素高速フーリエ変換を計算する。
ＦＦＴ （２） 対応する当該レジスタ又は別のベクトルのいずれかで２つの共役左右対称信号の順方向高速フーリエ変換を計算する。
ＦＦＴ （３） 対応する当該レジスタ又は別のベクトルのいずれかで１つの共役左右対称信号の順方向高速フーリエ変換を計算する。
ＦＦＴ （４） 複素ベクトルの高速フーリエ変換を計算し、その結果を２つの別々の（実数と虚数）ベクトルで返す。
ＦＦＴ （５） ２つの別々の（実数と虚数）ベクトルとして与えられた複素ベクトルの高速フーリエ変換を計算し、その結果を２つの別々の（実数と虚数）ベクトルで返す。
ＩＦＦＴ （１） 対応する当該レジスタ又は別のベクトルのいずれかでベクトルの逆高速フーリエ変換を計算する。
ＩＦＦＴ （２） 対応する当該レジスタ又は別のベクトルのいずれかで２つの共役左右対称信号の逆高速フーリエ変換を計算する。
ＩＦＦＴ （３） 対応する当該レジスタ又は別のベクトルのいずれかで共役左右対称信号の逆高速フーリエ変換を計算する。
＊ 有限のインパルス応答フィルタ関数
ＩｎｉｔｉａｌｉｓｅＦＩＲ １セットの；１組の遅延ライン値とタップとを用いて低レベル、単一レート有限インパルス応答フィルタを初期化する。
ＦＩＲ ＩｎｉｔｉａｌｉｓｅＦＩＲを用いて前に構成された低レベル、有限インパルス応答フィルタを介して単一サンプルをフィルタする。
ＢｌｏｃｋＦＩＲ 低レベル有限インパルス応答フィルタを介してサンプルのブロックをフィルタする。
ＧｅｔＦｉｒＤｅｌａｙｓ 低レベル有限インパルス応答フィルタのための遅延ライン値をゲットする。
ＧｅｔＦＩＲＴａｐｓ 低レベル有限インパルス応答フィルタのためのタップ係数をゲットする。
ＳｅｔＦＩＲＤｅｌａｙｓ 低レベル有限インパルス応答フィルタのための遅延ライン値を変更する。
ＳｅｔＦＩＲＴａｐｓ 低レベル有限インパルス応答フィルタのためのタップ係数を変更する。
Ｉｎｉｔｉａｌｉｓｅｍｕｌｔｉｆｉｒ 低レベル・マルチレート有限インパルス応答フィルタを初期化する。
Ｍｕｌｔｉｆｉｒ ＩｎｉｔｉｓｌｉｓｅＭｕｌｔｉＦｉｒを用いて前に構成された低レベル・マルチレート有限インパルス応答フィルタを介して単一サンプルをフィルタする。
ＢｌｏｃｋＭｕｌｔｉＦＩＲ ＩｎｉｔｉｓｌｉｓｅＭｕｌｔｉＦＩＲを用いて前に構成された低レベル・マルチレート有限インパルス応答フィルタを介してサンプル・ブロックをフィルタする。
＊ 最小乗平均適合化フィルタ関数
ＩｎｉｔｉａｌｉｓｅＳＡＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レート適応型ＦＩＲフィルタを初期化する。
ＩｎｉｔｉａｌｉｓｅＭＡＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マルチレート適応型ＦＩＲフィルタを初期化する。
ＩｎｉｔＡＬＦＤｅｌａｙ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用遅延ラインを初期化する。
ＳＡＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レート適応型ＦＩＲフィルタを介してサンプルをフィルタする。
ＭＡＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マルチレート適応型ＦＩＲフィルタを介してサンプルをフィルタする。
ＳＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レート適応型ＦＩＲフィルタを介してサンプルをフィルタするが、２次信号用としてフィルタの適合は行わない。
ＭＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マルチレート適応型ＦＩＲフィルタを介してサンプルをフィルタするが、２次信号用としてフィルタの適合は行わない。
ＥｎｇｉｎｅｓＡＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レート適応型ＦＩＲフィルタを介してサンプルのブロックをフィルタする。
ＢｌｏｃｋＭＡＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マルチレート適応型ＦＩＲフィルタを介してサンプルのブロックをフィルタする。
ＥｎｇｉｎｅｓＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レート適応型ＦＩＲフィルタを介してサンプルのブロックをフィルタするが、２次信号用としてフィルタの適合は行わない。
ＢｌｏｃｋＭＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マルチレート適応型ＦＩＲフィルタを介してサンプルのブロックをフィルタするが、２次信号用としてフィルタの適合は行わない。
ＳｅｔＡＬＦＤｅｌａｙｓ 低レベル適応型最小２乗平均（ＬＭＳ）アルゴリズムを用いるＦＩＲフィルタ用として遅延ライン値をセットする。
ＳｅｔＡＬＦＬｅａｋｓ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用として漏れ値をセットする。
ＳｅｔＡＬＦＳｔｅｐｓ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用ステップ値をセットする。
ＳｅｔＡＬＦＴａｐｓ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用としてタップ係数をセットする。
ＧｅｔＡＬＦＤｅｌａｙｓ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用として遅延ライン値をゲットする。
ＧｅｔＡＬＦＬｅａｋｓ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用として漏れ値をゲットする。
ＧｅｔＡＬＦＳｔｅｐｓ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用としてステップ値をゲットする。
ＧｅｔＡＬＦＴａｐｓ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用としてタップ係数をゲットする。
＊ 無限インパルス応答フィルタ関数
ＩｎｉｔｉａｌｉｓｅＩＩＲ 指定されたオーダーの低レベル無限インパルス応答フィルタを初期化する。
ＩｎｉｔｉａｌｉｓｅＢｉｑｕａｄＩＩＲ 低レベル無限インパルス応答（ＩＩＲ）フィルタをｂｉｑｕａｄｓ（二次オーダーＩＩＲセクション）のカスケード基準信号に初期化する。
ＩｎｉｔｉａｌｉｓｅＩＩＲＤｅｌａｙ 低レベル無限インパルス応答（ＩＩＲ）フィルタ用として遅延ラインを初期化する。
ＩＩＲ 低レベル無限インパルス応答フィルタを介して単一サンプルをフィルタする。
ＢｌｏｃｋＩＩＲ 低レベル無限のインパルス応答フィルタを介してサンプルのブロックをフィルタする。
＊ ウェーブレット関数
ＤｅｃｏｍｐｏｓｅＷａｖｅｌｅｔ 信号をウェーブレット連続に分解する。
ＲｅｃｏｎｓｔｒｕｃｔＷａｖｅｌｅｔ ウェーブレット分解から信号を再構成する。
＊ 離散余弦変換関数
ＤＣＴ 離散余弦変換（ＤＣＴ）を実行する。
ベクトル・データ変換関数
このセクションで記述したすべての関数は、（様々な整数長、異なる浮動小数点フォーマット及び浮動小数点数の固定小数点表示のような）複数の様々なデータ・フォーマットでの機能が可能である。この信号処理ライブラリには、サポートされているフォーマットのすべての対の間で単一値とベクトルとを変換する方法が含まれる。
【図面の簡単な説明】
【図１】
マイクロソフト社のウィンドウズを利用している場合のハードウェアとアプリケーション・ソフトウェアとの間の関係を示す概略図である。
【図２】
ハードウェアとアプリケーション・ソフトウェアとの間のマイクロソフト社のウィンドウズ以前の関係を示す概略図である。
【図３】
ベースバンド・スタックのアーキテクチャ上仮定的に中立な部分を切り離すことができない従来の方式に起因する障害を示す概略図である。
【図４Ａ】〜
【図４Ｂ】
本発明におけるベースバンド・スタックのアーキテクチャから見て中立な部分の切り離しの成功を示す概略図である。
【図５】
ベースバンド通信スタック内の構造を示す概略図である。
【図６】
本発明の実施例での共通のエンジンと構造とを示す概略図である。
【図７】
本発明のＣＶＭと、ハードウェアとスタックとの間の関係を示す概略図である。
【図８】〜
【図９】
本発明を利用する開発サイクルでのステップを示す概略図である。
【用語の説明】
Ａｒｃｈｉｔｅｃｔｕｒｅ Ｎｅｕｔｒａｌ Ｌａｙｅｒ １ Ｃｏｄｅ ｉｎ ＳＤＬ ＳＤＬで書かれたアーキテクチャから見て中立な層１コード
ＲａｄｉｏＳｃａｐｅ ＣＶＭ ＲａｄｉｏＳｃａｐｅ社製ＣＶＭ
Ａｒｃｈｉｔｅｃｔｕｒｅ Ｓｐｅｃｉｆｉｃ Ｈｉｇｈ ＭＩＰＳ Ｄａｔａ ｐａｔｈｓ アーキテクチャ独自の高ＭＩＰＳデータ・パス
Ｅｎｇｉｎｅ エンジン
【図１】
１：アプリケーション・ソフトウェア１
２：アプリケーション・ソフトウェア２
３：ウィンドウズ・バーチャルマシン
４：プリンタ・ドライバ（共有）
５：ＤＯＳ Ｂ／Ｓ
６：ハードウェア
【図２】
１：アプリケーション・ソフトウェア１
２：カスタム・プリンタ・ドライバ
３：カスタムＧＵＩコード
４：アプリケーション・ソフトウェア２
５：カスタム・プリンタ・ドライバ
６：カスタムＧＵＩコード
７：ＤＯＳ Ｂ／Ｓ
８：ハードウェア
【図３】
１：スタックのアーキテクチャから見て中立な部分（正しく切り離されていない）
２：通信用マシン層
３：アセンブラ・コードされたベクトル関数
４：共通のＤＳＰフロー制御構造
５：ハードウェア加速ドライバ
６：ＤＭＡ ＣＣＳ及び資源管理
７：オプションのＲＴＯＳ
８：ハードウェア２
【図４Ａ】
１：スタックのアーキテクチャから見て中立な部分（ハードウェアから切り離されている）
２：通信用マシン層
３：アセンブラ・コードされたベクトル関数
４：共通のＤＳＰフロー制御構造
５：ハードウェア加速ドライバ
６：ＤＭＡ ＣＣＳ及び資源管理
７：オプションのＲＴＯＳ
８：ハードウェア２
【図４Ｂ】
１：ＳＤＬで書かれたアーキテクチャから見て中立な層１コード
２：ＲａｄｉｏＳｃａｐｅ社製ＣＶＭ
３：アーキテクチャ独自の高ＭＩＰＳデータ・パス
４：エンジン
【図５】
１：コンテンツ生成
２：ソース符号化
３：チャネル符号化
４：変調
５：復調
６：チャネル復号化
７：ソース復号化
８：コンテンツ・プレゼンテーションＡｐｐ
【図６】
１：Ｉ／Ｏ
２：ＡＥＣ
３：ＦＦＴ
４：Ｃｈａｎ Ｐｒｏｃ
５：Ｄｅｍｏｄ
６：ＭＭＩコード
７：パイプライン段階
８：シンボル指示型処理
９：データ指示型処理
【図７】
１：スタック境界
２：Ｃ＋＋コア・コード
３：ＣＶＭ Ａ
４：ハードウェア＋Ｏ／Ｓ Ａ
５：スタック境界
６：Ｃ＋＋コア・コード
７：ＣＶＭ Ｂ
８：ハードウェア＋Ｏ／Ｓ Ｂ
【図８】
１：初期アーキテクチャ仕様書
２：数学モデリング用ツール（Ｍａｒｌａｂ）
３：グラフ記述言語（ＧＤＬ）
４：ＰＣ開発環境（ＭＳ Ｄｅｖ．Ｓｔｕｄｉｏ，Ｔａｕ）
５：アーキテクチャから見て中立な通信スタック（Ｃ＋＋／ＳＤＬ）
６：ＲａｄｉｏＳｃａｐｅプラグ・イン拡張
７：ＲａｄｉｏＳｃａｐｅライブラリ
８：ＲａｄｉｏＳｃａｐｅターゲット内蔵ＣＶＭ環境
９：ＲａｄｉｏＳｃａｐｅ Ｉｎｔｅｌ ＭＭＸ／ＳＩＭＤ ＣＶＭ環境
１０：プラグ・イン内蔵コンパイラ
１１：アーキテクチャ・レポート（ＭＩＰＳ、メモリ、ＣＣＳ）
１２：ＲａｄｉｏＳｃａｐｅアーキテクチャ解析ツール
１３：ＲａｄｉｏＳｃａｐｅＰＣ内ＲＦプロトタイピング用ＰＣＩボード
１４：ＦＰＧＡ／ＤＳＰ処理用ボード
【図９】
１：ＣＶＭ開発サイクル
２：モデリング用ツール（Ｍａｔｌａｂ数学など）
３：パイプライン
４：プラグ・イン（ＲＳ）
５：ＴＢＡ
６：手で
７：定義する
８：コンポーネント定義言語
９：コンポーネントＡＰＩ
１０：コンポーネントの振舞い
１１：デバイス定義言語
１２：適合性記述用言語
１３：コンポーネント“ＡＰＩ”仕様
１４：計装化
１５：解釈された
１６：パイプライン・マネージャ
１７：実行＆ログ
１８：実行
１９：コンポーネント定義言語
２０：ソースコード
２１：パイプライン・ビルダ
２２：ＶＭライブラリ
２３：コンポーネント・ライブラリ
２４：コンパイル
２５：パイプライン
整理番号 ８８４
【発明の属する技術分野】
本発明は、デジタル信号処理の設計、モデル化あるいは実行を行うためのソフトウェアに関する。本発明は、特に、通信用ベースバンド・スタックを用いて機能するデジタル信号プロセッサに関係する。通信用ベースバンド・スタックが通信用デバイスのデジタル信号処理に使用される。
【０００２】
【従来の技術】
技術背景：デジタル信号処理（ＤＳＰ）及びベースバンド・スタック
デジタル信号処理とは、アナログ及び／又はデジタル量のデジタル表現を操作する処理であり、チャネルを介して伝播される有用な情報の伝送または回収を目的とするものである。高速で、高精度の数値計算の利用により、デジタル信号プロセッサによるデジタル信号処理が実行されるが、一般に、これらのデジタル信号プロセッサは高速の、リアルタイムのデータ操作用として最適化された集積回路として形成される。デジタル信号プロセッサは、音声、通信、ビデオなどの多くのデータ収集、処理及び制御環境で使用される。デジタル信号プロセッサは、集積回路に加えて別の方法で実現が可能である。例えば、デジタル信号プロセッサは、マイクロプロセッサ、及び、プログラムされたコンピュータにより実現が可能である。本明細書で用いる用語‘ＤＳＰ’は、任意のデバイスあるいはシステムもカバーするものであり、デジタル信号処理の実行が可能なソフトウェアまたはハードウェアあるいはこの２つの組合せのいずれでもよい。したがって用語‘ＤＳＰ’は、１以上のデジタル信号プロセッサ・チップをカバーし、さらに以下のものをカバーするものである。すなわち：ＦＰＧＡ（フィールド・プログラマブル・ゲート・アレイ）やデジタル信号処理を実行するようにプログラムされたＡＳＩＣ、並びに、以上のいずれかの任意のチューリングデハイス類などのような１以上の外部協働用プロセッサと協働する１以上のデジタル信号プロセッサ・チップをカバーするものである。
【０００３】
通信セクタでは、ＤＳＰでベースバンド・スタックを実行するとき、ＤＳＰはベースバンド・スタック用の非常に重要なエレメントとなる。ＤＳＰと共にスタックによりデジタル信号処理が実行される。本明細書で使用する用語‘ベースバンド・スタック’とは、１組の処理ステップ（またはこれらのステップを実行する構造）を意味し、これらの処理ステップには以下のステップ、すなわち：ソース符号化、チャネル符号化、変調の各ステップ、あるいはそれらの逆、すなわちソース復号化、チャネル復号化及び復調の各ステップが含まれる。さらに、用語‘ベースバンド・スタック’は、いかなる形のダウンコンバージョンも行わずに、デジタル信号を処理できる構造を含むものとして解釈することが望ましい。ソフトウェア無線装置にはこのようなベースバンド・スタックが含まれることになろう。当業者であれば理解できるように、ソース符号化は、ビットレートを下げるための信号（原信号）圧縮に利用される。チャネル符号化によって、復号器能力の改善を図るための構造化された冗長性が付加され、誤り発生の可能性がある受信信号から情報が取り出される。変調により、伝播対象情報に応じてアナログ波形の変更が行われる。
【０００４】
ベースバンド・スタックは、移動電話（ＧＳＭスタックやＵＭＴＳスタックなど）あるいはデジタル無線受信機（ＤＡＢスタックなど）の中でのみならずその他の１方向及び２方向デジタル通信用デバイスの中でも使用される。本明細書で使用する用語‘通信’とは、１方向乃至２方向、あるいは、１対１の通信と放送及び１対多の通信と放送のすべての形態をカバーするものである。用語‘設計’と‘モデル化’には、一般に、１以上のエミュレーション処理、資源計算、診断的分析、ハードウェア・サイジング、デバッギング、パフォーマンス評価が含まれる。
【０００５】
通信システムの増大する複雑さに起因して、ベースバンド・スタックの開発に対して激しい圧力がかけられている。通信システムの複雑さはほぼ毎日のように増大しつつある。この複雑さには、いくつかの促進要因が存在する：インターネット上のトラフィックは毎年１０００％で増加している。このデータ（主として群発性のもの）の多くは、無線キャリアへ移動するが、このようなサービスを提供する利用可能なスペクトルがだんだん少なくなっている。これらの事実は、できるだけ多くのデータを圧搾して最小の使用可能帯域の中へ入れることを目的とするさらに複雑な信号処理アルゴリズムの利用へとつながる。実際、これらのアルゴリズムの複雑さは、ムーアの法則（計算機の能力は１８ヶ月ごとに２倍になる）よりも速く増加し続けている。その結果、従来のＤＳＰの能力では不十分になりつつある。したがって、複雑な端末用として、非常に大きな並列処理ロードの処理が可能なＡＳＩＣを形成する必要がある。しかし、実際には問題はここから始まる。なぜならば、使用されるアルゴリズムが信号処理フロントで複雑であるばかりでなく、主として音声トラフィックから主としてインターネット関連トラフィックへの移行により要請されるところの、バースティな、可変ＱｏＳでのしばしばの暫定転送用トランスポート・チャネルの利用は、（ハードウェアによるリアルタイム・コードが要求される）層１において、さらに優れた制御プレーン・ソフトウェアを必要とするからである。従来のＤＳＰツールセットでは、この問題を処理する適切なメカニズムが提供されていない。その結果、現在の多くの設計は‘現実の世界’のデータ・アプリケーションの処理をするための調整を行うことができない。
【０００６】
しかし、最新の通信システムの高度のＭＩＰＳ要件は、この話のほんの一部を表すものであるにすぎない。単一のＳｏＣ（チップ・オン・システム）内で多数の規格（ＧＳＭ、ＩＳ−１３６、ＵＭＴＳ、ＩＳ−９５など）を利用する必要がある場合に別の問題が生じる。複数の規格をサポートするＳｏＣデバイスは、様々な国々の様々なマーケットを効率的に利用しようと努めているデバイスのベンダにとってますます魅力的なものになるであろう。また、次世代ＵＭＴＳ電話は、ＧＳＭ（すなわち現在の世代）の能力を持つだけでなく、ＤＡＢ（デジタル無線放送）受信機のような付加機能も持つようになることが予想される。そのため、ＵＭＴＳ、ＧＳＭ及びＤＡＢ用のベースバンド・スタックが必要となる。通信用プロトコルの複雑さのために、現在では、上記問題のすべてに対するソリューションの提供を期待できる企業は１つとして存在しないような状態になっている。しかし、（上記リストした３つの異なるベースバンド・スタックのＩＰなどの）ＩＰを統合化して、だんだん短くなる時間スケールで単一の統合化されたパッケージの中へ一緒に入れるＳｏＣの構築という深刻な問題が複数のベンダのＩＰから生じる。複数のベンダのＩＰの相互接続を可能にする商用システムは現在マーケットには存在しない。層２と層３のソフトウェア（一般的には、ソフトによるリアルタイム・コード）の方が単純である。なぜならば、ＤＳＰまたは別の汎用プロセッサの多くのソフトウェアの中の１つの処理としてこのソフトウェアを単純に実行することができるからである。しかし、（ハードによるリアルタイムの、しばしば並列処理が行われる）層１のＩＰアルゴリズムはさらに困難な問題を提起する。というのは、必要なハードウェアによる加速処理が、層全体のアーキテクチャを左右して、非移植性の、ぜい弱な、ソリューション特有のＩＰを提供することが多いからである。
【０００７】
ベースバンド・スタック開発の現在のモデルにおける欠陥の概観
過去において、ベースバンド・スタックは比較的単純で、求められる高ＭＩＰＳ機能性の量は比較的小さく、マルチ規格の、マルチベンダの統合化が行われてきた。しかし、上述したように、現在では上記の事実はいずれも当てはまらない：すなわち：（ａ）ハードウェアの使用を必要とする、さらに複雑なアルゴリズム（ターボ復号化、ＭＵＤ、ＲＡＫＥなど）が採用される帯域圧縮手段、（ｂ）さらに多くのデータ発生／消滅イベント（ｂｉｒｔｈ／ｄｅａｔｈ ｅｖｅｎｔ）と再構成をハードウェア上のアルタイムで処理する必要があるので、パケット・データ・トラフィックの増加が層１制御プレーンの複雑さを増大させる。（ｃ）研究開発から製品化までの期間や、規格の多様化さらには差別化圧力のために、ベンダは、ますます複雑化する機能性（３Ｇ、ブルートゥース、８０２．１１など）を単一デバイスとしてレコード時間内で統合化する傾向があるが、これは特定のアプリケーション用ＳｏＣ（システム・オン・チップ）を形成する層１のＩＰの使用許諾を必要とする。
【０００８】
現在、この問題の適切な解決方法は存在しない。ＶＨＤＬツールセット・プロバイダ（ＣａｄｅｎｃｅやＳｙｎｏｐｓｉｓなど）は‘ボトムアップ’からこの問題にアプローチしている。プロバイダのツールは機能の個々の高ＭＩＰＳユニット（ビタビ・アクセラレータなど）の製造については有効であるが、層１フレームワークや制御コードのためのツールや統合化を与えるものではない。ＤＳＰのベンダ（ＴＩ社、アナログ・デバイシズ（Ａｎａｌｏｇ Ｄｅｖｉｃｅｓ）社など）は、ソフトウェア開発用ツールを確かに供給しているが、これらの会社のリアルタイム・モデルはスタティックで（そのためパケット・データのバースト性にうまく対処していない）、これらの会社のＤＳＰは、ＤＳＰの有用性にブレーキとして働くムーアの法則によって制限を受ける。さらに、通信用スタック・ソフトウェアはステート状態マシンとして最適にモデル化されているが、このステート状態マシンにとってＣまたはＣ＋＋（ＤＳＰベンダにより通常サポートされている言語である）は適していない代用言語である。
【０００９】
ベースバンド・スタック開発の現在のモデルにおける欠陥の詳細な分析
従来、デジタル通信のためのベースバンド・スタック開発は細分化され、高度に専門化されている。例えば、ベースバンド・スタックの中核である信号処理アルゴリズムの初期開発は数学モデリング環境（Ｍａｔｌａｂなど）で一般に行われるが、その際、従来方式のスプレッドシートプログラムを用いて精巧な評価がなされていたＤＳＰの最終ターゲットに対して見合うように、特定メモリやＭＩＰＳ（毎秒１００万命令）の総量が設定されている。いったん、このモデル化処理が良好に実行されると、コード・モジュールと、スタック用のインフラ・ストラクチャ・ソフトウェアとが書き込まれ、可能な場合には既存ライブラリが適合化される（またおそらくＲＴＯＳ（リアルタイム・オペレーティング・システム）が書き込まれる）。次いで、任意の必要なハードウェアによる加速処理が、可能な場合にはＰＬＤ（プログラマブル論理素子）上にプロトタイプ化される‘リアルタイム’のプロトタイプ・ハードウェア・システム（‘ＲＡＣＫ’と呼ばれる場合もある）が構築される。これは、ネットワークとの接続なしでテストされ、コードに対する必要な変更が行われる。いったん満足のゆくものになると、このスタックは固定化され、（オンチップ周辺機器としてハードウェアの加速用モジュールが組み込まれる）最終的ＡＳＩＣ（特定用途向け集積回路）が形成される。この結果つくられたベースバンドＤＳＰまたはＤＳＰコンポーネントが検査され、次いで、出荷される。
【００１０】
この‘従来の’アプローチに関していくつかの問題が存在する。これらの問題の中でより重要なものとして以下のことが挙げられる：
＊ 結果として生じるこれらのスタックにはその構造の中に多くのアーキテクチャの独自性が含まれる傾向があり、そのため別のハードウェアのプラットフォーム（別のメーカー製のＤＳＰなど）への‘移植’処理は時間のかかるものになる。
＊ また上記スタックは、修正が困難で、ぜい弱なものとなる傾向もあるため、インハウス（ｉｎ−ｈｏｕｓｅ）での変更の実施（バグの修正や、規格の中に導入された新しい特性の調整など）と、スタックのわずかな変更を望む他の人々へスタックの使用許諾を効果的に与えることとの双方を困難なものにしている。
＊ ＭＭＩ（マン・マシーン・インターフェース）との統合化が貧弱なものになる傾向があり、このことは、一般に、このＭＭＩの機能用の別個のマイクロ・コントローラをターゲットのデバイス内で使用することを意味する。このためチップ個数とチップ・コストとが増加することになる。
＊ 処理がきわめて低速であり、ＤＡＢ（デジタル・オーディオ放送）などの著しく複雑なシステム用ベースバンド・プロセッサの形成に最低約１年の経過時間を伴う。
＊ この処理は、バッファの割り振り、ダウンコンバージョンの管理、デジタル・フィルタの挿入、好適なチャネル・モデルの作成等々を行うための全体的最善の方法を決定する技術当局者（いわゆる‘グル（ｇｕｒｕ）’）に大きなストレスをかけるものとなっている。以上の点は一般に不利な点である。というのは、これによって、非常に重要なパスとメイン・スタッフへの依存がスタック製造プロジェクトに付加され、製造のタイム・ラインを長引かせることになるからである。この結果得られる製品は、適切な現在の技術のすべてを必ずしも含むとは限らないことが大いに予想される。その理由として、支配的な最善の実施技術のすべてにわたって完全に熟練している個人がいないこと、また、グルあるいはグルのチームが可能な技術革新のすべてを（たとえ彼らがその技術革新について知っていたとしても）スタック製造プロジェクトの中に組み込むだけの時間的余裕が必ずしもあるわけではないということが挙げられる。
＊ ＭＩＰＳの手動計算及びメモリ要件への依存、並びに、スタック用のＤＳＰモジュール及びインフラ・ストラクチャ・コードのカスタムメイド的性質は、製品の中に欠陥が生じる大きな確率があることを意味する。
＊ １つの関連する問題点として、一般に、‘ＲＡＣＫ’が組み立てられるまでは、スタックのリアルタイムでのプロトタイピングは可能ではない点が挙げられる。その点でも、利用可能な視認性の高いデバッガの不足は、最終スタックと資源の‘拘束解除’が不必要に遅滞することでと、ハードウェア製造のタイム・スケールが超過することを意味する。視認性の高いデバッガは、利用可能であれば、非常に有用なものとなるであろう。というのは、Ｃ＋＋のような高水準言語で開発されている場合、デバッガは、コードの中にブレイク・ポイントを入れ、そのポイントにおける処理を停止し、メモリ内容をチェックし、単一ステップ命令の効果を調べるために単一ステップを実行する開発用ツールの能力を与えるからである。またその場合、特定の条件が生じたとき、実行を停止させ、デバッガを起動させるトリガーをコードの中に入れることもできる。これらはアプリケーション・ソフトウェアを開発するとき非常に強力なツールとなる。‘ロック・オフ’とは、プロジェクトの１つの段階が完了したとき、開発が次の段階へ進むことができるということを意味する。ハードウェアの開発では、各反復試行が費用や時間のかかる製造を必要とするので、ソフトウェアの場合のように容易に反復試行を行うことはできない。
＊ 製造中のスタック用の低レベル・モジュールあるいはハードウェアによる加速処理用‘コントローラ’を開発しなければならないため、開発者はターゲット・プロセッサのアセンブリ言語に熟知している必要があり、また、彼らは当該プロセッサ用として与えられる開発用ツールに依存することになる。
＊ インフラ・ストラクチャ・コードが再使用されないという事実に伴うモジュール性の不足は、次のデジタル放送スタック用としてほとんど同じ作業を再び行う必要があることを意味する。
【００１１】
スタック開発へのこのタイプのアプローチから生じる、関連するセットとなる‘戦略的’問題が上記の困難な問題と結びつき、このタイプのアプローチでは、スタックは必然的に特定のハードウェア環境と強く結びつくものとなる。
＊ スタック・メーカの視点から見ると、選択されたＤＳＰのハードウェア・プラットフォームと接近しすぎる近い関係が存在する。錯誤に起因して、コストのかかる（また時間のかかる）移植処理が必要となるため、このＤＳＰハードウェア・プラットフォームの注意深い選択を行う必要があるだけでなく、開発用ツール、低水準アセンブリ言語、テスト用‘ラック’のハードウェアの開発及び最終的プラットフォームＡＳＩＣの製造がすべてそのアーキテクチャ独自のものとなる。別のハードウェア・プラットフォームでスタックを使用する機会が生じた場合、まずそのスタックを移植しなければならないが、これにはきわめて長い時間がかかり、多重コード・ベースが導入される（また、これによりプラットフォーム固有のバグという大きなリスクが伴うことになる）。コード・ベースとはプロジェクトの基礎を成すソースコードのことである。理想的には、ソフトウェアの開発の際、ソースコードと機能との間の１対１の対応付けが行われることになる。そのため、ある特定の機能を必要とする場合、いくつかのプロジェクトがすべて同じ実施構成を共有することになる。したがって、この実施構成が改善されれば、すべてのプロジェクトがその利益を享受することになる。しかし、起こりがちなこととして、個々のプロジェクトがコードの個々のコピーを持ち、実施構成が（自然界における遺伝子にいくぶん類似して）時間中分岐するということが挙げられる。プロジェクトが、従来方式の開発パラダイムの下で異なるハードウェアを使用する場合、同じコードの使用が不可能となる場合が時として生じることがある。さらに、たとえ同じハードウェア・プラットフォームがグレードアップされた仕様により利用可能になったとしても、コードは依然‘ミニ移植’を受け、それらの付加特性（例えば、より多くのオンボード・メモリや別のＭＡＣ（積和演算）ユニットなど）を利用できるようにする必要がある。
＊ ハードウェア・メーカの視点から見ると、ソフトウェア・スタックとの接近しすぎる近い関係が存在する。ハードウェア・メーカは、（概して）スタック製造ビジネスの専業になることを望まない。それにもかかわらず、このような（そのデバイスを有用な製品に変える）スタックがなければハードウェア・メーカはユニットの販売を行うことはできない。マーケット用として、利用可能な‘ソフトウェア・ベース’という表現は、ハードウェア・メーカの製品がもっと適切に競合の対象とすべきその他の特性（利用可能なＭＩＰＳ、電力消費量、利用可能なハードウェアのＩＰなど）を不明瞭にする可能性がある。
＊ （シンビアン社のような）オペレーティング・システムのプロバイダは、彼らのＯＳをベースバンド通信スタックとインターフェースすることを非常に重要であると考えている。実際問題として、従来方式のスタックにおけるモノリシックで、電力消費の大きい点や、リアルタイム要件に起因して、このベースバンド通信スタックとのインターフェースは達成が非常に困難となる可能性がある。
【００１２】
テキサス・インスツルメント社による「ｅＸｐｒｅｓｓＤＳＰ（ｅＸｐｒｅｓｓＤＳＰ）リアルタイム・ソフトウェア技術」を参考として考えることができる。この製品セットによって、ＤＳＰ用ソフトウェアの開発時間と統合化時間の削減が可能になる。しかし、この製品セットは従来方式の設計アプローチの欠点を例示するものである。なぜならこのセットは、専用セットとして、テキサス・インスツルメント社製ＤＳＰプラットフォームと結びついているからである。「ｅＸｐｒｅｓｓＤＳＰ（ｅＸｐｒｅｓｓＤＳＰ）リアルタイム・ソフトウェア技術」よりも優れた本発明の１つの実施構成のさらに詳細な相違について、以下本発明の詳細に要約する。
【００１３】
【発明が解決しようとする課題】
本発明の第１の態様によれば、デジタル信号処理の設計、モデル化、あるいは実行のためのソフトウェアが提供され、該ソフトウェアは、通信用ＤＳＰ用として最適化されたバーチャル・マシン層を含むものとなる。
【００１４】
‘バーチャル・マシン’とは、一般に、本発明に関連するタイプのアプリケーションを実現するための理想的マシンの機能とインターフェースとを定義するものである。このマシンは、一般に、進行中のタスク用として最適化された理想的マシンを使用アプリケーションに対して提示し、実際のハードウェアの不良動作と欠陥とを隠すようにするものである。また、通信処理をモデル化したり、通信処理を表示したりする１以上のステートマシンの管理及び／又は維持を行うことも可能である。その場合‘バーチャル・マシン層’は、現実のマシンをこの理想的マシンのように見えるようにするソフトウェアである。この層は、一般に、すべての現実のマシン・タイプについてそれぞれ異なるものとなる。‘バーチャル・マシン層’とは、一般に、ソフトウェアから成る層を意味し、この層は、何らかのタスクまたは１組のタスク（デジタル信号処理など）を実行する１組の１以上のＡＰＩ（アプリケーション・プログラム・インターフェース）を提供し、使用プログラム間で割り当てられ、共有する必要のある非常に重要な資源（メモリやＣＰＵのような資源など）を享有している。
【００１５】
好適には、資源を割り当て、共有し、切り替えられるように、バーチャル・マシン層を最適化して、デジタル信号処理を行うために最善となるようにすることが望ましい。これと対照的に、典型的なオペレーティング・システムは、ワード・プロセッサのような一般的ユーザ・インターフェースプログラム用として最適化されている。したがって、例えば、上記ケースの資源切替えアルゴリズムは、一般に、エンドユーザのオペレーティング・システムの時間増分値よりもはるかに小さな時間増分値で機能し、並列処理の制御を行うことを可能とするものでもある。
【００１６】
通信用ＤＳＰ用として最適化されたバーチャル・マシン層では、処理を実行しなければならないハードウェアからのソフトウェア・ベースバンド・スタックの切り離しが図られる。このため、ベースバンド・スタックを非常に移植し易いものにすることが可能となる。それは、基底を成すハードウェアの変化からのこれらのベースバンド・スタックの切り離しがバーチャル・マシン層により可能となることに起因する。また、上記バーチャル・マシン層では（各々が様々な機能を実行する）様々な接続モジュール間でのフロー制御の管理を行うことも可能であり、この管理を同時ベースで行うことも可能である。さらに上記バーチャル・マシン層では、信号処理用の共通データ構造の定義を行うことも可能である。これについて以下さらに詳述する。
【００１７】
本発明のソフトウェアは、（ベースバンド・スタック、または、特に、様々なベンダからのいくつかのベースバンド・スタックや、移動電話のような最終製品を含むＳｏＣ全体などの）通信用デバイスをモデル化し、開発し、実際にベースバンド処理の実行を可能にする開発環境において利用が可能である。
【００１８】
‘バーチャル・マシン層’というコンセプトを通信用ＤＳＰの領域に対して適用する利点は、非アナログ分野からの一例を通じてもっとも良く理解することが可能となる。ＰＣソフトウェアの分野では、（システムＢＩＯＳの上位に在る）マイクロソフトのウィンドウズＴＭオペレーティング・システムは、使用中の実際のマシンから、及び、そのマシンと接続されたデバイスの細部からソフトウェア開発者を切り離している。換言すれば、マイクロソフトのウィンドウＴＭオペレーティング・システムは、コードが実行可能な‘バーチャル・マシン層’を提供している。これが図１に概略的に例示されている。このバーチャル・マシン層に起因して、ワード・プロセッサを使ってものを書いている人が、例えば、彼らのコードを実行するのがデルのマシンかコンパックのマシンかどうかとかということや、ユーザが、（いずれかのプリンタが）接続している場合そのプリンタがどのような種類のものであるかなどということは知る必要はない。さらに、このオペレーティング・システムによって、１組の共有のコンポーネント（ファイル・ダイアログ・ボックス、メモリ割付けメカニズム及びスレッド管理ＡＰＩのような）機能とサービスとが提供される。‘共通コード’が１回しか書き込まれないため、各アプリケーションが‘共通コード’を何度も再実行しなければならなかった場合に比べて、このような‘共通コード’の厳密性、範囲及び信頼性が大幅に上昇する。さらに、ＰＣハードウェアのメーカーはソフトウェア開発の複雑さから保護され、適切なウィンドウズのＡＰＩから得られるＢＩＯＳとドライバを提供するだけで、当該プラットフォーム用の膨大な範囲の既存ソフトウェアの利用が可能となる。図２に例示されているように、各アプリケーションがそれ自身のカスタムＧＵＩコードを内包していることが多かったプレ・ウィンドウズ状況と、現在の状況とを対比することができる。
【００１９】
ＰＣウィンドウズの‘バーチャル・マシン層’アプローチのための主要なイネイブラ（ｅｎａｂｌｅｒ）として、多数のアプリケーションにより、同じ基底を成す‘バーチャル・マシン’の機能が広く求められることが挙げられる。もしも、ただ１つのアプリケーションが、プリンタを使用する必要があったり、ただ１つのアプリケーションがマルチスレッドを必要としたりするのであれば、上記サービスがウィンドウズの‘バーチャル・マシン層’の一部であることは効率的であるとは言えないであろう。しかし事実はそうではない。なぜなら、（ウィンドウ、アイコン、マウス、ポインタ、プリンタ、ディスク記憶装置などの）類似のＩ／Ｏ要件と、類似の‘共通コード’要件とを持つ多数のアプリケーションが存在して、それがＰＣ‘バーチャル・マシン層’を‘説得力のある提案’としているからである。
【００２０】
しかしながら、本発明に先行して、‘バーチャル・マシン’というコンセプトを通信用ＤＳＰの分野に適用することを考えた者はいままで誰一人としていなかった。このコンセプトを適用することにより本発明によって、専用ＤＳＰにではなく、バーチャル・マシンにソフトウェアの書込みを行うことが可能となり、製造上のいずれか１つのソースから生じるＤＳＰのアーキテクチャに起因する制約から技術者を切り離すことが可能になる。このＤＳＰからの独立という形は、マイクロソフト社のウィンドウズ・オペレーティング・システムにより提供されているところの、ＰＣの世界でのハードウェアの独立性と同様に潜在的に有用なものである。この独立性は図３と４に概略的に例示されている。図３には、適切に実現された場合、アーキテクチャから見て中立であることが望ましいベースバンド・スタックの部分が、実際にはサブストレート・ハードウェアから適切に切り離されていないような従来方式の状況が示されている。図４は本発明のバーチャル・マシン層（通信用マシン層（ＣＶＭ）と呼ばれる）がベースバンド・スタックのこれらの部分の切り離しに成功する方法を描く図である。
【００２１】
したがって、本発明の様々な実現構成にとっていくつかの主要な利点が存在する。
＊ ＤＳＰのアーキテクチャを介して、様々なメディア・アクセス・ハードウェアへに対してベースバンド・スタックを移植すること（例えば９００ＭＨｚで作動するＧＳＭ電話用スタックを１８００ＭＨｚで機能するＧＳＭ電話へ移植するなど）がずっと高速に行われる。なぜならば、本発明によって、アーキテクチャ固有の、あるいは、スペクトル固有のものではないスタックの設計が可能になるからである。研究開発から製品化までの期間のような非常に重大な利点がさらに一段と重要になる。したがって、スタックは、バーチャル・マシン層が移植される相手先の任意のＤＳＰのアーキテクチャで機能することになる。同様に、バーチャル・マシン層が移植される相手先ＤＳＰは、バーチャル・マシン層用として書き込まれたすべてのスタックを実行することになる。
＊ 高ＭＩＰＳコンプレックスコード（ビタビ復号器など）の多くは、各ＤＳＰのアーキテクチャの場合、何回も書き変えられるのとは対照的に、バーチャル・マシン層の場合には１回しか書き込まれない。このため、このコンプレックスコードの品質と信頼性が、軽い経済的負担で改善可能となる。これは、ベースバンド・スタック自身が以前より少ないコードしか必要とされないであろうこと、及び、どのようなスタック・コードが必要であるにせよベースバンドスタック自体は複雑さの少ないものであろうことを意味し、これによってスタック・コードの信頼性が向上する。
＊ このバーチャル・マシン層によって、完全にソフトウェアの中で、あるいは、ソフトウェアと、通常使用されているＤＳＰコンポーネントとの混成物を用いるかのいずれかでプロトタイプの形成能力が与えられ、それによって、開発サイクルにおけるアルゴリズムの欠陥と資源要件との早めの特定が可能となる。
【００２２】
好適には、バーチャル・マシン層が、様々なコア処理及び／又はコア構造及び／又はコア機能及び／又はフロー制御及び／又は状態管理を用いてプログラムされるか、もしくは、様々なコア処理及び／又はコア構造及び／又はコア機能及び／又はフロー制御及び／又は状態管理へのアクセスを可能にすることが望ましい。バーチャル・マシン層がプログラムされる（あるいはバーチャル・マシン層がアクセスを行うことを可能にする対象としての）コア処理には‘１以上の共通エンジン’が含まれる。これらの‘共通エンジン’は、１以上のベースバンド・スタック機能、すなわち、ソース符号化、チャネル符号化、変調及びそれらの逆（ソース復号化、チャネル復号化及び復調）を実行する。これらの‘共通エンジン’には、高速フーリエ変換（ＦＦＴ）、（様々な拘束長、ガロア多項式及びパンクチャリング・ベクトルを持つ）ビタビ復号器、リード・ソロモン（Ｒｅｅｄ Ｓｏｌｏｍｏｎ）エンジン、ＭＰＥＧ復号器用離散余弦変換（ＤＣＴ）、エラー・デコヒーレンス（ｅｒｒｏｒ ｄｅｃｏｈｅｒｅｎｃｅ）のための時間及び周波数ビット毎の再オーダリング、複素ベクトル乗算及びオイラー合成が含まれる。さらに広範囲のリストが添付書類１の中に含まれている。これらのパラメータ化された変換の中の１以上が、通信用ベースバンド・スタックにより共通に求められる。上記従属特性は、ほとんどすべての主要なデジタル放送システムの範囲内に見いだされるという本発明による洞察に基づくものである。一例として、ＧＳＭとＤＡＢとの類似性が挙げられる。例えばＧＳＭとＤＡＢの双方においてインターリービングとビタビ復号化が利用される。したがって、共通の数学的基礎に基づく共通性が断言される．
【００２３】
さらに、‘コア構造’は各ケースの中に存在してもよい。この‘コア構造’は、（当該シンボルの範囲内に保持されているすべての情報が利用可能か否かにかかわらず、フル・シンボルの処理に関係する）シンボル処理部と、関連情報を保持する当該ビットのみの処理が行われるデータ指向処理部とに復号化チェーンを分割することに関与する。各ケースで、これらの処理用モジュールが、中間の、整合メモリ・バッファの割り当て、共有、配置を行い、処理用モジュール間でイベントを渡し、モジュラ型開発を可能にする枠組みの範囲内の存在であることが非常に望ましい。
【００２４】
上記コア機能は、以下の処理のうちの１以上を含む資源割当てとスケジュリング（メモリ割付け、リアルタイムの資源割当て及び同時性管理）に関するものであってもよい。好適には、このソフトウェアは、パフォーマンスと能力の点でＤＳＰ設計用ツールよりもずっと優れた、ＰＣのデバグ用ツールにアクセスが可能であることが望ましい。このソフトウェアは、コンフォーマンスクリプト（ｃｏｎｆｏｒｍａｎｃｅ ｓｃｒｉｐｔｉｎｇ）に従うものであってもよい。このスクリプトについては以下に定義する。さらに、このソフトウェアは、コンポーネントを用いて機能するものであってもよい。このコンポーネントの中で上記ソフトウェアの機能及び／又は別様にコンポーネントのパフォーマンスのモデル化を可能にするために必要な当該情報だけが上記コンポーネントの知的財産の所有者により供給される。このことによって、（内部の詳細事項、設計、操作のような貴重な営業秘密情報である可能性のある）知的財産の所有者がその情報を隠し、サポートされている機能、ＡＰＩに必要なパラメータ、タイミングと資源のインタラクション、特性評価のための予想パフォーマンスなどのようなずっと重要性の少ない情報だけを公開することが可能になる。
【００２５】
本明細書では、本発明に従うソフトウェアの実施例を通信用マシン層（ＣＶＭ）と呼ぶ。ＣＶＭは、上記に導入した着想を一緒に引き出すので、以下のセクションにおいて要約する。
【００２６】
ＣＶＭの実現構成についての要約
ＣＶＭとは、デジタル信号処理製品開発用プラットフォームと、当該製品を実行するためのランタイム（ｒｕｎｔｉｍｅ）との双方を指すものである。ＣＶＭは、基本的に、バーチャル・マシン層と関連する複雑さの管理手法をリアルタイム・デジタル信号処理へもたらすものであるが、この信号処理は、（ｉ）（アーキテクチャ独自の方法で実現可能な）高ＭＩＰＳデジタル信号処理計算をバーチャル・マシン層の一方の側の‘エンジン’の中に配置すること、（ｉｉ）アーキテクチャから見て中立な低ＭＩＰＳコード（様々な低ＭＩＰＳプロセスを定義する層１コードなど）をもう一方の側に配置することにより実行される。さらに具体的には、ＣＶＭは、低ＭＩＰＳ制御プレーンとデータ‘操作及びパラメータ’フローを除くすべての高度の複雑さを、（ビタビ復号化、ＦＦＴ、相関などの）多量の資源を必要とする処理を実行する高ＭＩＰＳ‘エンジン’から切り離すものである。この切り離しによって、‘アーキテクチャから見て中立な’高い移植性を持つ方法で、複雑な通信用ベースバンド・スタックの構築が可能になる。なぜならば、基底を成すハードウェア上ではなく、ＣＶＭ上で実行するベースバンド・スタックの設計が可能となるからである。ＣＶＭは、これらのスタックの高度の複雑さ、低ＭＩＰＳ制御コードに対して均一なセットのＡＰＩを演出し、多くの様々な種類のスタック用として高ＭＩＰＳエンジンの再使用を可能にするものである（例えば、ＧＳＭとＵＭＴＳスタック双方のためのビタビ復号用エンジンの利用が可能となるなど）。
【００２７】
デジタル信号処理製品の開発段階中、（最少の数のプロセッサで実行するなどの）最適のアクセス・コストを示す構成を特定することを目的として、デジタル信号処理製品の様々な設計上のＭＩＰＳ要件の、ＣＶＭによるシミュレーションやモデル化の実施が可能である。確定論的関数とは対照的な、少なくとも１つの確率的統計分布関数を利用する資源割当て処理が利用される。様々なＤＳＰチップとＦＰＧＡとから成る実現構成のシミュレーションが可能である。高ＭＩＰＳの速度と並列処理能力との故に、ＦＰＧＡの中に高ＭＩＰＳ演算処理を配置することが非常に望ましい。
【００２８】
実際の処理中、最適の処理を維持するために、ＣＶＭ内のスケジュラがリアルタイムで知的にタスクの割り当てを行うことが可能である。本明細書ではこのアプローチを‘２段階スケジュリング’と呼ぶ。様々なエンジンの資源要件が、（ｉ）設計時に明示的にモデル化が可能であること、（ｉｉ）ランタイム中、知的に利用が可能であること、という理由により、いくつかの様々なベンダからのエンジンを単一製品の中に混ぜることが可能となる。上述したように、これらのエンジンは、層１と直接の接続を行うのではなく、代わりにＣＶＭバーチャル・マシン層の中継を介して制御コードを層１と接続する。さらに、ＤＳＰとＦＰＧＡとの組合せを利用する非リアルタイム・プロトタイプから実行時プロトタイプへの移行、次いで、カスタムＡＳＩＣ上への効率のよい移行がＣＶＭを用いることにより可能となる。
【００２９】
ＣＶＭでは以下の３つの主な特長が実現される：
＊ 同時スケジュリングのためのサポートを備えた、ダイナミック、マルチ・メモリ空間用マルチプロセッサ分散型スケジュラ
＊ アーキテクチャ固有の実現構成を備えた、デジタル放送及び通信用として共用される高ＭＩＰＳ演算処理用ＡＰＩ
＊ 資源管理及び正常化層（ｎｏｒｍａｌｉｚａｔｉｏｎ ｌａｙｅｒ）（固有のＲＴＯＳを介して供給される）
【００３０】
ＣＶＭは‘パイプライン’という形で存在することが可能である。‘パイプライン’とは、ある構造または１組の相互作動するハードウェア・デバイスまたはソフトウェア・デバイス、及び、１つのデバイスまたは処理から別のデバイスまたは処理へ情報を渡すルーチンである。ＤＳＰ環境では、このような複数の情報は‘シンボル’と呼ばれることが多い。パイプラインは、データ・フローアーキテクチャとして、並びに、従来の手続き用コードとして実現が可能であり、このような変形例のすべては本発明の範囲内に属するものである。また、ＣＶＭは、ステートマシンとして、または、手続き用コードとして概念化し、実現することも可能であり、再言するが、このような変形例のすべては本発明の範囲内に属するものである。
【００３１】
【課題を解決するための手段】
ＣＶＭの１つの例には、解釈されたパイプライン・マネージャが含まれ、このパイプライン・マネージャにはＣＶＭコアのランタイムバージョンが組み込まれる。‘解釈された’という用語が意味するものとして、そのパイプラインの仕様が基底を成すマシンコードにまだ翻訳されていず、ベーシック言語のような解釈された言語の場合と全く同じように、プログラムの実行につれて繰り返し再翻訳が行われることが挙げられる。
【００３２】
別の例として、ＣＶＭコアのラタイムバージョンが組み込まれた、計装化された解釈パイプライン・マネージャ（Ｉｎｓｔｒｕｍｅｎｔｅｄ Ｉｎｔｅｒｐｒｅｔｅｄ Ｐｉｐｅｌｉｎｅ Ｍａｎａｇｅｒ）がある。この計装化された解釈パイプライン・マネージャは、解釈されたパイプライン・マネージャと同じように機能するが、開発者に役立つメトリックと計測値も生成する。解釈された非計装化（ｎｏｎ−ｉｎｓｔｒｕｍｅｎｔｅｄ）バージョンもまた開発とデバッギング用として有用であり、コンパイルされ、計装化された（ｉｎｓｔｒｕｍｅｎｔｅｄ）バージョンもまた有用である。後者のバージョンは開発とデバッギング用の最適ツールとなる場合もある。
【００３３】
ＣＶＭの別のバージョンはパイプライン・ビルダ（Ｐｉｐｅｌｉｎｅ Ｂｕｉｌｄｅｒ）である。プログラム実行の代わりに、パイプライン・ビルダは、Ｃ言語のようなコンピュータ・ソースコードを出力し、このソースコードをコンパイルして、パイプラインの実現構成を形成することができる。この理由のため、パイプライン・ビルダはＣＶＭライブラリを利用できなければならない。パイプライン・ビルダは、コンパイルされた非計装の変形例と考えることもできる。
【００３４】
ＣＶＭ装置は、通信用コンポーネントの特性（非インターフェースの振舞いを含む）の標準化された記述を含むか、この記述に関するものであるようにして、シミュレータがコンポーネントを利用する上でのシステムの資源要件の正確な推定ができるようにする。ＣＶＭ装置で時間及び同時性制限条件のモデル化を行って、リアルタイムＯＳ上への対応付けを可能にし、並列処理を実行できる可能性を持たせるようにすることも可能である。
【００３５】
本発明の別の特性と態様は本明細書の請求項において定義される。添付図面を参照しながら本発明について以下説明する。
【００３６】
【発明の実施の形態】
ＲａｄｉｏＳｃａｐｅ社（英国、ロンドン）のＣＶＭの実現構成に関連して本発明を説明する。
【００３７】
ＣＶＭの概観
ＣＶＭとは、デジタル信号処理製品開発用プラットフォームと、当該製品を実行するためのランタイム（ｒｕｎｔｉｍｅ）との双方を指すものである。ＣＶＭは、基本的に、バーチャル・マシン層と関連する複雑さの管理手法をリアルタイム・デジタル信号処理へもたらすものであるが、この信号処理は、（ｉ）（アーキテクチャ独自の方法で実現可能な）高ＭＩＰＳデジタル信号処理計算をバーチャル・マシン層の一方の側の‘エンジン’の中に配置すること、（ｉｉ）アーキテクチャから見て中立な低ＭＩＰＳコード（様々な低ＭＩＰＳプロセスを定義する層１コードなど）をもう一方の側に配置することにより実行される。さらに具体的には、ＣＶＭは、低ＭＩＰＳ制御プレーンとデータ‘操作及びパラメータ’フローを除くすべての高度の複雑さを、（ビタビ復号化、ＦＦＴ、相関などの）多量の資源を必要とする処理を実行する高ＭＩＰＳ‘エンジン’から切り離すものである。この切り離しによって、‘アーキテクチャから見て中立な’高い移植性を持つ方法で、複雑な通信用ベースバンド・スタックの構築が可能になる。なぜならば、基底を成すハードウェア上ではなく、ＣＶＭ上で実行するベースバンド・スタックの設計が可能となるからである。ＣＶＭは、これらのスタックの高度の複雑さ、低ＭＩＰＳ制御コードに対して均一なセットのＡＰＩを演出し、多くの様々な種類のスタック用として高ＭＩＰＳエンジンの再使用を可能にするものである（例えば、ＧＳＭとＵＭＴＳスタック双方のためのビタビ復号用エンジンの利用が可能となるなど）。
【００３８】
バーチャル・マシン層は、いくつかの様々なベースバンド処理用アルゴリズムに共通の基底を成す高ＭＩＰＳアルゴリズムをサポートし、これらのアルゴリズムを、高水準の、アーキテクチャから見て中立な、スケジュラ・インターフェースの中を通る、潜在的に高度の複雑さをもつ低ＭＩＰＳ制御フローにアクセス可能にし、このアクセスによって、ランタイム、メモリ、相互接続帯域のうちの１以上に応じて、１組の資源制約包絡面と共に、制御フローによるアルゴリズムの実行指定が可能になる。上記資源制約包絡の内側で起呼音は処理の実行が行われることを望む。
【００３９】
デジタル信号処理製品の開発段階中、（最少の数のプロセッサで実行するなどの）最適のアクセス・コストを示す構成を特定することを目的として、デジタル信号処理製品の様々な設計上のＭＩＰＳ要件の、ＣＶＭによるシミュレーションやモデル化の実施が可能である。決定論的関数とは対照的な、少なくとも１つの確率論的統計分布関数（及び／又は統計的測定関数）を利用するモデル化を行うための資源割当て処理が利用される。様々なＤＳＰチップとＦＰＧＡとから成る実現構成のシミュレーションが可能である。高ＭＩＰＳの速度と並列処理能力とに起因して、ＦＰＧＡの中に高ＭＩＰＳ演算処理を配置することが非常に望ましい。
【００４０】
実際の演算処理中、最適の演算処理を維持するために、ＣＶＭ内のスケジュラがリアルタイムで知的にタスクの割り当てを行うことが可能となる。本明細書ではこのアプローチを‘２段階スケジュリング’と呼ぶ。様々なエンジンの資源要件が、（ｉ）設計時に明示的にモデル化が可能であること、（ｉｉ）ランタイム中、知的に利用が可能であること、という理由により、いくつかの様々なベンダからのエンジンを単一製品の中に混ぜることが可能となる。上述したように、これらのエンジンは、層１と直接の接続を行うのではなく、代わりにＣＶＭバーチャル・マシン層の中継を介して制御コードを層１と接続する。さらに、ＤＳＰとＦＰＧＡとの組合せを利用するＰＣＴ非リアルタイム・プロトタイプからランタイムプロトタイプへの移行、次いで、カスタムＡＳＩＣ上への効率のよい移動がＣＶＭを用いることにより可能となる。
【００４１】
ＣＶＭでは以下の３つの主な特長が実現される：
＊ 同時スケジュリングのためのサポートを備えた、ダイナミック、マルチ・メモリ空間用マルチプロセッサ分散型スケジュラ
＊ アーキテクチャ固有の実現構成を備えた、デジタル放送及び通信用として共用される高ＭＩＰＳ演算処理用ＡＰＩ
＊ （固有のＲＴＯＳを介して供給される）資源管理及び正常化層（ｎｏｒｍａｌｉｚａｔｉｏｎ ｌａｙｅｒ）
【００４２】
ＣＶＭとは設計フロー・ソリューション並びにランタイムである。
ＣＶＭは、ランタイムを補う完全な設計フローを提供するものである。このＣＶＭによって、完全に統合化された数学モデルと、（群発性のデータに関する演算処理に必須の）統計的シミュレーション・ツールと、（データ・パスがハードウェアの中へ入るべきか、ＤＳＰコア上のソフトウェアの中で実行すべきかを決定するための）序列的分画シミュレーション・ツールが技術者に与えられる。数学モデリング用ツール（Ｍａｔｌａｂ／Ｓｉｍｕｌｉｎｋなど）のカスタム・ライブラリの利用によって、ＣＶＭは、様々なデータ・パスがどれだけのビット数の幅を持つ必要があるかなどを前もって決定するために、詳細に、かつ、ビットレベルの（ｂｉｔ−ｅｘａｃｔ）精度で、高ＭＩＰＳエンジンの機能のモデル化を行うことができる。しかしながら、このシステムは、統計的シミュレーションが行われる制御プレーンからＸＭＬコマンドを受け入れることもでき、これにより、データ発生／消滅イベント（ｂｉｒｔｈ／ｄｅａｔｈ ｅｖｅｎｔ）と群発性とをモデルのコンテキスト内で取り扱うことができるようになる。さらに、スケジュラの間接インターフェースを介してシミュレーション・エンジンにまでもアクセスが行われるので、実際のハードウェアなどの実現構成に対してプラグ・インコールを行って、シミュレーションの実行速度を上げることが可能となる。
【００４３】
また、重要なことは、様々なシステム分画の決定により資源ローディングのシミュレーションの実行が可能なことである。様々な統計的ロードの下で十分にカバーするためには、特定のアルゴリズム‘エンジン’（ビタビ復号器、レイク受信デバイス・エレメント、ブロックＦＦＴの演算処理など）のインスタンスがいくつ必要なのか？データ・パスがバスのような遅延を生じ、及び／又は同時争奪を生じる資源にわたって移動する場合、何が起こるのか？データ・パスがソフトウェアではなくハードウェアの中で実現される場合何が起こるのか？これらの問題の解決のすべては非常に重要であるが、既存のツールセットではこれらの解決はまだ行われていない。さらに、複数のサード・パーティのＩＰエンジンまたはエンジン（下記を参照）に関して、分画問題の解決を行うとき、これは２重の意味で真である。ＣＶＭ設計フローによって、これらの種類の設計上の問題解決に対する回答を与えることが可能となることは明らかである。さらに、初期の分画情報は、設計用ツールセットから‘順方向に’転送されてランタイムスケジュラの中に入り、これによって、システムが実際の動的ロードを行っているときに、このランタイムスケジュラが、好適な実行エンジン・インスタンスに向けて要求を導くことが可能となる。
【００４４】
‘ボトムアップ’から見ると、このソフトウェアを実質的に２次的重要性をもつものとして扱うことは、もはや販売のための製品開発を行う方法ではない。このようなやり方では単に長い時間がかかりすぎるだけで、あまりにもアーキテクチャ固有の結果が生じ、基底を成す領域の並列状態マシンの性質にとって不都合な‘マッチング’が生じることになる。‘トップ・ダウン’から見ると、ＣＶＭが利用するパラダイムにより、はるかにずっと強力で拡張可能なソリューションが得られる。
【００４５】
ＣＶＭに関する最終ポイントとして、基底を成すエンジンから制御フロー・コードを切り離すことにより、実際の組み込まれたターゲットと矛盾することなく、従来の（ＰＣなどの）プラットフォーム上で多くの開発作業の実行が可能になることが挙げられる。これによって、特定のベンダの最終ターゲットの開発用プラットフォームを利用する場合に比べて設計上ずっと早い方向転換が可能になる。
【００４６】
例：ＣＶＭとは、３Ｇシステム用ＳｏＣのような、ハードウェアによるリアルタイムの、マルチベンダの、マルチプロトコル環境に対する設計上のソリューションである。
ＣＶＭのコア・エレメントの中の１つとして、ハードウェアによるリアルタイムの、マルチベンダの、マルチプロトコル環境における（潜在的に衝突する）サード・パーティのソフトウェア／ハードウェアの資源要件を処理する能力がある。この能力はＣＶＭの主要な利点であり、システム・オン・チップ（ＳｏＣ）の設計の際、特別な重要性を持つものである。これを理解するために、３Ｇ携帯電話マーケット向けのベースバンド・チップの将来のプロバイダが直面する問題点について考えることにする。第１に、層１の必要となる処理の複雑さに起因して、在庫のＤＳＰ用として単純にコードを書き込むことはオプションではない。ＡＳＩＣでは、複雑な拡張やターボ復号化などの処理を行うことが求められる。第２に、ＵＭＴＳは少数の地下鉄の場所に当初導入されるにすぎないため、チップにはＧＳＭのサポートも可能である必要がある。ベースバンド・チップメーカがこれら双方の分野で広範囲の技術を持っていることはありそうもなく、したがって、ＩＰの使用許諾を受ける必要が生じる。この点は、絶えず長引くことになる、研究開発から製品化までの期間という圧力を考慮すると技術会社にとって特に関係の深い事柄である。しかし、一部はハードウェア、一部はソフトウェアから成るＩＰエンジンの使用許諾を層１の複数のベンダから得ることは１つの現実的な問題を現出することになる。第１に、上記方法での‘互換性対非互換性’（ｍｉｘ ａｎｄ ｍａｔｃｈ）ＩＰについての共通の単純な基準は現在存在していない。必要とされること、及び、ＣＶＭ設計フローが提示することとして、静的及び動的双方のサード・パーティのＩＰブロックの資源要件を特徴づける１つの方法がある。この方法によって、潜在的に、全く異なるサプライヤからの別のＩＰエンジンを用いてリアルタイムで当該サード・パーティのＩＰブロックを同時スケジュール化し、次いで、より高いレベルの層１制御コードとの透過的な接続が可能となる。さらに、ＣＶＭの性質として、（ＡＮＳＩＣへコンパイルされたＳＤＬなどの）アーキテクチャから見て中立な言語でこれら高レベルの呼構造及び制御プレーン全体の形成が可能であるということが挙げられる。その場合、低いレベルで、高ＭＩＰＳ部分だけがアーキテクチャ独自の形式で直接実現されることになる。
【００４７】
上述したように、エンジン内に内包される高ＭＩＰＳ機能は、完全な処理ルーチンを表すものである。これらのエンジンは、ハードウェアまたはソフトウェア、あるいは両者の何らかの組合せで実現可能であるが、このことは高水準の‘起呼’コードという観点から見ると重要な問題ではない。高レベルのＩＰは、ＣＶＭスケジュラ起呼を介して基底を成すエンジンと交信を行い、この起呼により、ハードウェアにおけるリアルタイムの動的資源制約条件の指定が可能になる。次いで、スケジュラは、適切なデータ・パスにこの要求の実行指令を出す。この実行指令にはＤＳＰの関数呼出しや、ＦＰＧＡまたはＡＳＩＣへのデータの受渡しが含まれる場合もある。重要なことは、このスケジュラが複数のハードウェアのデータ・パスを処理することができるという点である。これらのデータ・パスは様々なアクセス用プロファイルと実行用プロファイル（例えばオンバス・ビタビ復号器、オンチップ・ソフトウェアベースの復号器、及び、外部ＤＭＡを介してアクセスされるオフチップ専用ＡＳＩＣなど）を持つことが可能であり、さらに、起呼用の高レベルのコードから完全に独立した適切なユニットに特定の要求を渡すことが可能である。
【００４８】
また、このことは、２つの異なる通信スタックがいくつかの共通の高ＭＩＰＳエンジンを必要とする場合、適切な（プラットフォーム固有の）エンジンの実現構成（この実現構成がハードウェア、ソフトウェアまたはその双方の何らかの組合せのいずれで設計されているかにかかわらず）のベンダが、上記２つの異なる通信スタックのマーケットへ販売を行うことができることを意味し、さらに、単一のＳｏＣ上に２つの規格が実装されている場合、双方のスタックが同じアクセラレータを潜在的に共有できることを意味する。加えて、１組の１００以上のコア・オペレーションが指定され、これらのコア・オペレーションを考慮に入れると、デジタル放送用プロトコル及び通信用プロトコルの膨大な部分の中で得られる高ＭＩＰＳ機能の８０％近くがこのＣＶＭにより提供されることになる。
また、ＣＶＭランタイムは基底を成すＲＴＯＳにラップアラウンド処理を施し、（スレッド、メモリ、外部アクセスを含む）資源管理のための規格に準拠したインターフェース絡みの高レベルのコードを提示するものである。
【００４９】
ＣＶＭを用いることにより、通信ＳｏＣ製品用の統合化された開発用プラットフォームの構築が可能となる。その場合、いくつかのサード・パーティのベンダは、高レベルのアーキテクチャから見て中立なＳＤＬあるいはＣ＋＋コンポーネントもしくはアーキテクチャに固有の、資源プロファイル化されたエンジン（ハードウェア、ソフトウェア、またはその双方の組合せであってもよい）のいずれかとして、彼らのＩＰを公開することができる。統合化された設計フローによって、ＳｏＣの設計者は、（特定のベンダから選択された）適切なエンジンを含むシステム全体を形成し、ＣＶＭの両側またはいずれかの側に自分のＩＰを付加し、次いで、（アクセラレータと共にいくつかのＶＨＤＬで定義されたコアとして）利用可能なハードウェア仕様とソフトウェア・コンポーネントの双方を作成することが可能になる。数学モデリングと、確立論的序列的分画シミュレーションと、プロトコル検定とによって、完全なフローを提供するツールセットを構築し、好適なメカニズムを提供することで、設計の範囲内で‘パッケージ化された’ＩＰライブラリの特徴づけ、公開、列挙及び利用が可能となる。
【００５０】
このシステムは、ＳｏＣの設計者用の主要ワークベンチになる潜在的可能性を有する。ＳｏＣの設計者は、高ＭＩＰＳエンジンの開発を行うために、層１制御構造（ｆａｂｒｉｃ）の中のいずれにも入らず、ＶＨＤＬツールの中へ入るだけでよくなるからである。
【００５１】
ＣＶＭにより設計層１内でのＳＤＬの利用が可能となる。
上述したように、ＡＮＳＩ Ｃ＋＋または好適にはＳＤＬ（このＳＤＬはその後ＡＮＳＩ Ｃへコンパイルしてもよい）のいずれかを用いて、アーキテクチャから見て中立な方法で低ＭＩＰＳコードを書き込むことがＣＶＭにより可能となる。ＳＤＬとは、層２及び層３スタックを表現するために電気通信業界内で広く使用されている言語であり、状態マシン・フォーマットで最も経済的に表現されるシステムにとって特に好適な言語である。従来の方式で使用するには、ＳＤＬは層２（‘ソフトによるリアルタイム’領域の端）より下位で使用するのに適切なものではない。ＳＤＬコードは様々なアーキテクチャ間での完全な移植が可能であり、ＴＴＣＮなどのようなツールを用いて通常の方法でテストを行うことも可能である。開発時のコードとサブストレートの相互接続とから成る様々な部分に（動的資源の天井などのような）システム上の制約を設けることが可能であり、次いで現実の負荷モデルを用いてシミュレーションを行って、ハードウェアとソフトウェアへのデータ・パスの予行分画を行うことが可能となる。重要なことは、ＣＶＭスケジュールが、開発プロセスの１回の設計時間部分中に行われたデータ・パス分画決定を認識しているということである。ツールフローは、Ｍａｔｌａｂ及びＳｉｍｕｌｉｎｋと完全に統合化され、高ＭＩＰＳ機能のビットレベルでのテストが可能となる。層１の範囲内での高レベルの論理フロー用推奨言語としてＳＤＬの使用は偶発的なものではない。ＳＤＬは、ＧＳＭのような通信スタック層２と３内で広く使用されてきたが、この２つの層の深い溝（ｃｈａｓｍ）の間をかけ渡してハードウェアによるリアルタイム領域の中へ入ってきたことは従来なかったことである。これと対照的に、ＣＶＭでは、ＳＤＬ制御フローからの並列の、ハードウェアによるリアルタイムの実行指令の呼出しが可能となり、それによってＳＤＬの非常に強力で、かつ、自然な、ステートマシンの表現性を利用して、高水準の層１アルゴリズムの作成が可能になる。これらのアルゴリズムは、低ＭＩＰＳを有しているにもかかわらず、ほんの２、３の名前を挙げるだけでも、群発性のレート・マッチング、ユーザ・トランスポート・チャネルのデータ発生／消滅イベント（ｂｉｒｔｈ／ｄｅａｔｈ ｅｖｅｎｔ）、複数の規格間のハンドオーバ、負荷によるＱｏＳと結びついたグレースフル・デグラデーションのような問題を処理しなければならないので、ますます極度に複雑になっている。リアルタイムの処理用としては設計されていない他の言語（Ｃ＋＋やＪａｖａなど）もＳＤＬの代替言語として設計層１での使用が可能である。
【００５２】
ＣＶＭに対する理論的背景
現在のデジタル通信システムは、チャネルに起因するきわめて厳しい影響に直面する中で信頼性の高い、情報の無線による最善の伝送方法についての、最近の１５年かそこらで出現した実質的に共通のコンセンサスに基づいて構築されている。２方向システムは、（例えば、輻輳状態のスペクトル帯域に直面してグレースフル・デグラデーションを生じるＣＤＭＡを利用し、いくつかの‘ハードウェアによる’リアルタイム要件を含むような）放送型システムとは多少異なるチャネル要件と変調要件とを持っているが、全体として多くの共通性が存在する。
【００５３】
例えば、（１方向の）放送システムの特定のケースでは、復号器と符号器は単に並列の‘プロトコル・スタック’と考えることができよう。ほとんどの放送送信システムは、（ビットレートを落とすために入力信号を圧縮するＭＰＥＧのような）ソース符号化から始まり、その後（信号破損にもかかわらず情報を取り出すようにした受信機能力の向上のための構造化された冗長性を付加する畳み込み符号化とリード・ソロモン（Ｒｅｅｄ−Ｓｏｌｏｍｏｎ）符号化のような）チャネル符号化が後続し、その後、（この時点で、複数の副搬送波が（周波数または位相の）角度や振幅の何らかの組合せで修正され、情報が保持される）変調が後続する。次いで、図５の線図を（１つのレベルで）生み出す逆の処理が受信機で実行される。したがって、ほとんどすべての主要なデジタル放送システムの中で１組の共通の処理用エンジンが見いだされ、各ケースで共通の処理構造の適用が可能となる。
【００５４】
ＣＶＭの実施例は、上記の事実を以下のように利用するものである。すなわち、共通エンジン（または関数やライブラリ）には、１以上のステップ（ソース符号化、チャネル符号化、変調の各ステップ）、あるいはそれらの逆のステップ（ソース復号化、チャネル復号化及び復調の各ステップ）を実行するアルゴリズムが含まれる。これらのアルゴリズムには、例えば、高速フーリエ変換（ＦＦＴ）、（様々な拘束長、ガロア多項式及びパンクチャリング・ベクトルを備えた）ビタビ復号器、リード・ソロモン（Ｒｅｅｄ Ｓｏｌｏｍｏｎ）エンジン、ＭＰＥＧ復号器用離散余弦変換（ＤＣＴ）、エラー・デコヒーレンス（ｅｒｒｏｒ ｄｅｃｏｈｅｒｅｎｃｅ）のための時間及び周波数ビット毎の再オーダリング、複素ベクトル乗算及びオイラー合成などが含まれる。さらに広範囲のリストが添付書類１の中に含まれている。上記アルゴリズムは高ＭＩＰＳルーチンであり、したがって、理想的にはアーキテクチャに固有の方法で（アセンブリ・コードまたはハードウェアによる加速処理のいずれかを介して）ＣＶＭの中で実現される。上記の事実にかかわらず、共通の高水準ＡＰＩを通じてＣＶＭ内のこれらのアルゴリズムのアクセスすることができる。これらのパラメータ化された変換の各々は、この各変換について設けられる並列的数学モデリング・ブロックが含まれる。
【００５５】
この共通構造は、（当該シンボルの範囲内に保持されているすべての情報が利用できるか否かにかかわらず、フル・シンボルの処理に関係する）シンボル処理部と、関連情報を保持する当該ビットのみを処理するデータ指示型処理との復号化チェーンへの分割に関与するものである。各ケースで、これらの処理用モジュールが、中間の整合メモリ・バッファの割り当て、共有、配置を行い、処理用モジュール間でイベントを渡し、モジュラ型開発を可能にする枠組みの範囲内に存在できるようにすることが非常に重要である。この共通構造は、数学モデリング環境の適切な場所に並列化され、グラフ記述言語（ＧＤＬ）を介して記述される。図６は、ＣＶＭで利用されるこの共通ブロック及び共通構造によるアプローチを概略的に描くものである。
【００５６】
追加のＣＣＳ（同時システムの微積分法）要件と資源割当て問題が存在するという点と、処理用エンジンの必要な‘臨界容量’がわずかに異なるという点とを除いて、２方向システムについても同様の分析を行うこともできる。
【００５７】
現在の世代のサード・パーティ・アプリケーションの開発用ツールと、ハードウェア配置用プラットフォーム（ＤＳＰ及びＤＳＰコア）とが、上述の構造的現実を反映していないこと、及び、（概して）通信ベースバンド・アプリケーションに合わせて仕立てられたハードウェアによる加速処理を行わないこと、また、２段階スケジューリング・アプローチ（下記を参照のこと）も行わないことは興味深いことである。また、現在の組み込まれたオペレーティング・システムでも系統的なあるいは統合化された方法での上記処理やアプローチのサポートは行われていない。
【００５８】
しかし、デジタル通信システムの数は急速に増加しつつあり、ベースバンド・スタックの研究開発から製品化までの短い期間内の市場への投入に対する要望が生まれている。以上説明したように、本発明の中核を成す革新的アプローチは、ソフトウェアにより提供された‘バーチャル・マシン層’（ＣＶＭの実施例により例示される）を提供し、これらの能力とソフトウェア構造とを具体化することにより、基底を成す共通性とこのようなシステム要件とを利用することである。１つの主要な市販アプリケーションは、（上述したような）ＳｏＣなどのハードによるリアルタイムの、マルチベンダの、マルチプロトコル環境に対する設計上のソリューションのようなものである。
【００５９】
ＣＶＭ開発方法論
ＣＶＭで用いられる開発方法論は、層化された開発と層化された配置を用いる方法論から出発し、この方法論を利用するものである。これらのコンセプトについて最初に解説する：層化された開発とは、（必要に応じて）数学モデルから、Ｃ＋＋またはＳＤＬコードを通じて、ターゲット・アセンブラの実現構成へ進むプロセスを意味する。このプロセスを通じてずっと、当該モジュールの各々は、必要なレベル（例えば、並列的数学モデル、Ｃ＋＋実現構成、ＳＩＭＤモデル及び様々なターゲット言語によるアセンブラの実現構成として畳み込み復号器が存在する）の各々に維持される。
【００６０】
層化された配置とは、受信機のスタックが実際に実現されたとき、基底を成すハードウェア及びホストのオペレーティング・システムから可能な限りコードを切り離すためにライブラリを利用することを意味する。したがって、可能な限り多くのコード（高度の複雑さと共に低ＭＩＰＳ要件）が、一般的ＳＤＬまたはＡＮＳＩ対応Ｃ＋＋（これはその後、ターゲット・プラットフォーム用として単純に再コンパイルされる）として保持される。例えば、単純なＩ／Ｏ、メモリ・バッファの割当てなどのようなプラットフォームに依存する機能を提供するためにライブラリが利用される。（ＦＦＴ、ビタビ復号器などのような）反復して使用される回数の多いルーチンをアーキテクチャ独自の方法で提供するために別のライブラリが利用される。このアーキテクチャ独自の方法には、好適に設計されたアセンブラル・ルーチンの利用や、特定用途のハードウェアによる加速処理用エンジンに対するコールスルー（ｃａｌｌｔｈｒｏｕｇｈ）の利用までも含むこともできる。
【００６１】
上記２つのライブラリは、基底を成すハードウェア及びオペレーティング・システムのサブストレートの如何に関らず、移植中修正を行う必要がない‘コア’コードとの共通のＡＰＩとして明白なものである。修正すべき唯一のコード、すなわちライブラリの実現構成の内容は、意味のあるカプセル化と数学モデルから生成される多種多様のテスト・ベクトルから利益を得る。その理由として、スタックの移植を高速に行うことが可能なアーキテクチャ内の接続ポイント（ｐｏｉｎｔ ｏｆ ａｒｔｉｃｕｌａｔｉｏｎ）が、上述のアプローチを用いて適切に配置されているということが挙げられる。
【００６２】
さらに、開発用プラットフォームとして、上記アプローチには、数学モデルを実行するのではなく、逆に完全なリアルタイム送受信装置を実行する１つのアーキテクチャ（インテルのプラットフォームなど）上で開発を行い、次いで、単純にライブラリのスワップを行い、ターゲットのアーキテクチャで再コンパイルを行うことが可能であるという大きな利点がある。これは、等化器モジュールの同調などを試みる際非常に有用なものとなる。
【００６３】
ＣＶＭによるアプローチは上記のような作業方法を利用するものである。しかし、これに加えて、すべてのデジタル通信用ベースバンド処理作業にとって有用な主要サービス及び機能と共に、可能な限り多くの共通の機能が分離されて‘バーチャル・マシン’のハードウェアの分離層の中へ入れられる。
【００６４】
以下の図７は、上記のことがアーキテクチャのレベルで機能する方法を示すものである。プラットフォームＡ用とプラットフォームＢ用の異なるライブラリの実現構成を備えて与えられるスタックを出荷する代わりに、ＣＶＭの中に、プラットフォームＡとプラットフォームＢの各々のための共通の‘ベースバンド・オペレーティング・システム’層が存在し、共通のＡＰＩが与えられる。この共通のＡＰＩの上で（再コンパイルを除いて）変らない状態のままさらに高いレベルのコードの実行が可能となる。
【００６５】
さらに、シンボル指向型の処理のためのシンボル・サブスクライバ（ｓｙｍｂｏｌ ｓｕｂｓｃｒｉｂｅｒ）アーキテクチャやデータ指示型処理のためのパイプライン・アーキテクチャのような、別様の場合、Ｃ＋＋コアの範囲内に存在するような機能の多くをこの層の中へ組み込むことが可能である。
【００６６】
具体的なＣＶＭ開発方法論：２段階スケジュリング
段階Ｉ
ベースバンド通信システムを構築する際の１つの重要な側面として、アプリケーションが実行される、ハードウェアとソフトウェアのプラットフォームとの要件の定量化がある。アプリケーションが要求するＭＩＰＳ（１００万命令毎秒）の回数のベースライン計算は比較的簡単であり、単に、１つの処理を実行するための、各コンポーネントの要求条件を計算し、処理回数を乗算し、それらすべてを一緒に加算するだけのものにすぎない。しかし、上記の中には並列要因のような側面は考慮されていない。２×５００ＭＩＰＳのプロセッサは理論的には１０００ＭＩＰＳの処理パワーを転送するとはいえ、別のチップでの処理の完了を待機している場合、アルゴリズムがこのパワーを利用できない場合もある。また、スケジュラの特別の処理要件、及び、考慮すべきデータ転送オーバーヘッドも存在する。２つのプロセッサが同じボード上に存在する場合、データ転送ペナルティはおそらく小さなものであるが、２つのプロセッサが１つの外部バスの中へプラグ・インされた別個の独立のボード上に存在する場合には、データ転送ペナルティはさらに大きなものとなる。バスの競合（２以上のプロセッサが同時にデータの転送を望むこと）によっても能率全体が低下する可能性がある。ＣＶＭによって、この種の分散型環境におけるシステムの実現を容易にするいくつかの方法が提供される。
【００６７】
最初に、付属説明１に記載されている信号処理用の関数などの個々の計算用コンポーネント要件、及び、付属説明１に記載されている信号処理機能に基づいて組み立てられるさらにアプリケーションに固有のエンジン要件の定量化が可能である。３Ｇ移動通信のような環境では、１つのブロックの内を通過するデータ量は時間中変動するため、１回のデータ転送速度で１つのブロックの要件を計算するだけでは十分ではない。その代わりに、プロファイルは潜在的入力ベクトル・サイズの範囲にわたって組み立てられる。
【００６８】
ＣＶＭによって、一方の端でデータを注入し、もう一方の端で消費するデータ・フロー（パイプライン）のコレクションとしてシステムを定義することが可能となる。これらのパイプラインのエンジンは、入力ベクトル・サイズの関数としてエンジンがどれだけ多くの処理を必要とするかという点から特徴づけられる。ＭＩＰＳの使用計算の第１のパスとして、このパイプラインに沿う、変動するサイズのエンジンの通過シミュレーションと、入力ブロック・サイズの関数としての上記使用合計の計算とが行われる。これにより、単一のプロセッサにおいて完了まで連続して実行したと仮定した場合のエンジンのＭＩＰＳ要件の合計が計算される。
【００６９】
さらに優れたモデルによってプロセッサを切り離すためにエンジンが割り当てられ、真のパイプライン接続が可能になる。このアーキテクチャに基づくソリューションは、シングルスレッドのソリューションよりもさらに多くのＭＩＰＳを必要とすることになるが、いったんパイプラインがロードされると、より短い経過時間でデータ・エンジンを処理できる可能性が生じることになる。Ｎをプロセッサの数、Ｅ（Ｎ）をプロセッサの利用効率（１＝１００％、０＝ゼロ）、Ｍｐを単一プロセッサのＭＩＰＳの定格、Ｍを当該ＭＩＰＳ要件の合計とすると、１秒のデータ処理時間Ｔは、下式で表される：
Ｔ＝Ｍ／（Ｅ（Ｎ）×Ｎ×Ｍｐ）
【００７０】
上式の目的はＮの最小値を見つけることである。但しＴは“ゆとりのある（ｃｏｍｆｏｒｔａｂｌｅ）”マージンの１未満の数とする。Ｅ（Ｎ）は、単一のボードの場合１に接近し、（スケジュリングとデータ転送により導入されるオーバーヘッドに起因して）ボード数の増加に伴い低下する。Ｅ（Ｎ）は、処理用エンジンがボード間でどのように分散されるかによっても変動する（この変動は、変動するデータ転送要件と、不規則な負荷バランスがプロセッサをしばらくの間アイドル状態に放置する可能性とに起因する）。
【００７１】
スケジュリング処理と、バスの特性と、エンジンの特性とに関する情報を持っているＣＶＭシミュレータは、様々な数のボードとエンジン構成についてＥ（Ｎ）したがってＴの計算を行うことができる。また若干のエンジンの“ダブルアップ（ｄｏｕｂｌｉｎｇ ｕｐ）”（２以上のボード上で同じ機能を持つこと）の影響を調査することも可能となる。
【００７２】
あるタスクのために必要な一続きのエンジンをいったん認知すると、ＣＶＭがセットされ、エンジンとボードの構成を介して最適解を探す探索が可能となる。ボードの個々のＭｐ値を出し（Ｎ×Ｍｐをこの個々のＭｐの和で置き換える）、特定のエンジンを特定のボードに結びつけることも可能となる。例えば、ビタビ復号器はＤＳＰよりも高いＭＩＰＳ定格を持つＦＰＧＡ上で常に実行する。多数のエンジンについての網羅的探索は実行不可能となるため技術者からの何らかの助けが必要となる。
【００７３】
段階ＩＩ
いったんエンジンとボードの受け入れ可能な構成が得られると、“本気で実行する”スケジュリング処理の段階ＩＩへ進むことができる。段階Ｉでは、正しいボード上へのエンジンのロードに使用することはできないシステム構成を生成したことになる。メインボードのスケジュラもこの情報を利用することが可能となる。いったんシステムが実行されると、データ・エンジンはスケジュラから、データに対して機能するエンジンへ流れる。ほとんどの時間、このスケジュラは単に、処理を必要とする順にデータを先へ送るにすぎないが、より多くの知能的処理の適用が可能となる場合が生じてくる。同等の優先順位を持つ複数のエンジンが存在する場合、スケジュラは、作業ロードが最少となるようにスケジュリングを行うことにより、すべてのボード上でキュー・サイズのバランスをとることを試みる。２以上のボード上に同じ機能が存在する場合、スケジュラはスケジュリングを行うための最適ボードを再び探索する。同じボード上の２つのエンジン間でエンジンのルート選定を行う際にメインのスケジュラの関与が不要となるように、すべてのボードにはローカルなスケジュラが設けられる。スケジュラは、作業を送るボード選択権がある場合、可能であれば自分のボードを常に選択する。またスケジュラは、ログ・メッセージのルート選定やモニタ用コンソールへの情報のモニタ・バックなどのような緊急性の少ない活動のスケジュリングが可能な場合には、処理時の潜在的小休止状態（ｌｕｌｌ）を探索することにより、最も緊急を要するエンジンの絶対的緊急性をモニタする必要がある。
【００７４】
さらなるＣＶＭ開発方法論：ＵＭＴＳでの実現構成で使用されるようなＭＩＰＳカウンタ
上述したように、ＣＶＭは、ＣＶＭスケジュラによって接続され、制御される複数の分散型エンジンから構成される。これらのエンジンは同じハードウェア上に位置するものであってもよいが、異なるハードウェア（ＣＰＵ、ＤＳＰまたはＦＰＧＡ）上に位置することも可能である。ＣＶＭのＵＭＴＳでの実現構成の場合、障害を特定し、エンジン／ブロックの連続化を助けるシステムが開発されている。まずデータ・ブロック用の処理ルートが与えられているものと仮定する。例えば、ＵＭＴＳ規格２５．２１２と２５．２２２、にはＴｒＣＨ段階でのブロックの多重化方法が提案されている。その場合、ＢＥＲのような何らかの客観的判断基準に応じてルート間で処理の若干を切り替えてもよい。しかし、必要なエンジンについては認知されている。次いで、データ・サイズとユーザの数という点からエンジンのサイズを決定しなければならない。例えば、ベクトルが長さｎで、かつ、エンジンが以下、
ｆｏｒ （ｉｎｔ ｉ＝０， ｉ ＜ ｎ， ｉ＋＋）
｛
ｆｏｒ （ｉｎｔ ｊ＝Ｏ， ｊ ＜ ｎ， ｊ＋＋）
｛
／／ Ｄｏ ｓｏｍｅｔｈｉｎｇ．．．
｝
｝
から構成されている場合、この処理はｎ２またはＯ（ｎ２）の次数であるということができる。次に、基本命令（（／／Ｄｏ ｓｏｍｅｔｈｉｎｇ’）内の‘＋’，‘−’，．．．）の数をカウントすることができる。例えば、ＦＦＴによってｎＬｏｇ（ｎ）回の演算処理が行われることになる。次いで、この演算回数に１基本命令当たりのデバイスの実行命令の回数を乗算し、次いで、これをＭＩＰＳの回数で除して、タスクの実行にデバイスが要する時間を得ることができる。或いは、単に相対時間を設定してもよい。
【００７５】
ユーザの数（Ｋ）について同じ処理を繰り返すことができる。例えばＭＵは２Ｋのような数になる場合もある。最終的に、各ブロックはビットレートの変更を行ってもよいし、行わなくてもよい。ターボ符号化によってビットレートは３倍だけ増え、ＣＲＣの使用により１２ビットが加算される。（バスの待ち時間、スケジュラ、並列化／連続化はすべてエンジンと考えることができることに留意されたい）
【００７６】
重要な点は当該データ転送速度がわかっているという点である。上記処理により解答が得られる問題として、エンジン（エンジンのＭＩＰＳ予算など）をどのように配分してその調整を行うようにすることができるかということが挙げられる。
【００７７】
トップ・ダウン方式による設計
状態制御とデータ制御とを必要とする場合、処理用チェーンの走査はきわめて複雑となる。この処理手順を用いて、標準的アダプタを介してＲＳの中にＣ＋＋ブロックが結びつけられ、Ｓｉｍｕｌｉｎｋとの統合化が行われる。基本的に、上記処理の意図は階層の中を移動することである。層を上位へ移動するほど抽象のレベルがだんだん高くなる。その意図は、３つのサービスについて‘ユーザ’が作成するデータのラウンド・トリップを行うことである。ＵＥによって、ある一定のプロパティを持つ物理チャネルを介してＢＳへのデータの送信が行われる。ＢＳは上記データを受信し、復号化する。この場合、ＢＳは簡単なバックホールを持ち、物理チャネルを介してデータを再転送して元のＵＥへ戻し、このＵＥで上記データは入力データと比較される。このシステムによってエンジンの入替えが可能になり、種々のチャネルにおけるＢＥＲと時間という点からパフォーマンスの改善が図られる。
【００７８】
ＣＶＭの特性
ＣＶＭは、ベースバンド処理スタックが必要とする種類の機能を提供する最低限のＯＳと考えることもできる（また、上述したように、これらのスタックはＧＳＭやブルートゥースのような２方向スタックであってもよい）。したがって、ＣＶＭは、マイクロソフト社のウィンドウズＣＥやシンビアン社のＥＰＯＣのような、本格的な内蔵型オペレーティング・システムと相補うものである。
【００７９】
ＣＶＭでは、（特に）下記の機能が提供される：
＊ ＦＦＴフィルタ、ＦＩＲフィルタ、ＩＩＲフィルタ及びウェーブ・ディジタル・フィルタ、及び、デシメーション、相関、複素乗算などのようなオペレーションをカバーする広範囲のセットのベクトル処理用プリミティブ（さらに多くのプリミティブが付属説明１に完全にリストされている）上記オペレーションは、基底を成すハードウェアで加速処理が利用可能なハードウェアによる加速処理を利用することが望ましく、さらにこれらのオペレーションは、ライブラリの拡張バージョンを並列化する１組のライブラリ呼出しを介してアクセスされることになる。ある意味では、ＣＶＭのこの側面は、デジタル通信を行うための理想化されたデジタル信号処理用エンジンのソフトウェアまたはＡＰＩの抽象的な形を表すものである。
＊ 整列バッファの割当てと、メモリ‘ハンドシェーキング’（ピンポン・バッファ）とのサポート
＊ 単純な種類のプリエンプティブ・マルチスレッドのオプションを備えた高度スケジュリング管理ハードウェアによるリアルタイム・パフォーマンス（すなわち、ある特定の時点に１つのコードが処理を実行する）がアーキテクチャの主要なコンポーネントとしてサポートされる。プロセス間通信構造（少なくとも共有メモリ）とスレッド同期ファシリティとが提供される。主要な特長として、確率的並列スケジュラがあり、このスケジュラは計算用異種サブストレートの両端にわたるＣＶＭエンジンに対する設計時間の分割の決定を認識するものである。
＊ シンボル指向型及びデータ指向型処理についての概念の明示的サポート、これは、シンボル・サブスクライバ（ｓｙｍｂｏｌ ｓｕｂｓｃｒｉｂｅｒ）とパイプライン段階とを構造の中へ付加してモジュラ型の開発を可能にする能力を直接サポートするものである。
＊ シリアルポート、パラレルポート及び表示制御装置を含む主要なＩ／Ｏ周辺機器のサポート
＊ 特に、モジュラ型Ｉ／ＯサポートのＯ／Ｓの範囲の拡大を可能にする拡張性
＊ 数学モデルとリアルタイム・プロトタイプとが、ターゲット・サブストレートと相互接続とのパフォーマンスのシミュレーションを高度の正確さで行うことを可能にする特定の実現構成についての特性ライブラリ
＊ リアルタイム・プロトタイプの製造を可能にするＰＣバージョン
＊ ホスト（アプリケーション）のＯＳとの通信のサポート：この通信はコールバック等々を可能にする双方向通信となる。２進‘グルー’を行うためにコンポーネント相互通信技術（ＣＯＭなど）を利用してもよい。好適なアプリケーション用ＯＳとしては、例えばＥＰＯＣ３２やウィンドウズＣＥであってもよい。なぜなら、これらのＯＳは、より一般的なユーザ・レベルのＩ／Ｏと、構造化された記憶管理とを実行するように設計されたＯＳであるからである。
＊ 最小の（したがって最終的にはチップ面積の）ＲＯＭの利用を保証するために組立てタイム（ｂｕｉｌｄ ｔｉｍｅ）においてＣＶＭのＲＯＭ画像を‘削減する（ｐａｒｅ ｄｏｗｎ）’能力 これはＣＶＭの最低限の実現構成を利用するものである。
＊ ステートマシンの機能管理（ＳＤＬとの潜在的統合化を含む）
＊ データ構造のサポート
＊ （固定小数点や浮動小数点などのような）異なる表現間の変換
【００８０】
ＣＶＭの目標は、開発段階での多数のアプリケーションを用いて、特定アプリケーションの高速な利用を特定のターゲット上で可能にすることである。従来のＯＳは、ＯＳがロードされたとき実質的に未知の種々のアプリケーションの実行時サポート用として設計されているが、一般にＣＶＭについては事実はそうではない。さらに、ＣＶＭは、‘ホスト’のＯＳが提供するポータルを介するプレゼンテーション・ストリームのサポートによる処理を除いて、ユーザとのインタラクション処理を必要としない。
【００８１】
ＣＶＭは、インフラ・ストラクチャ・レベル（シンボル指示型及びデータ指示型処理の開発のための適切なモジュラ型構造など）の中へＤＡＢスタックの高レベルのＣ＋＋コードの中に現在存在するいくつかの特性を組み込んでおり、単なる‘ライブラリ・ラッパ’ではない。
【００８２】
ＣＶＭというコンセプトは、共通機能の分離と、（重要なことであるが）最新のデジタル放送及び通信規格によって求められる処理構造の分離とが可能であり、系統的に層化された開発環境と結合された適切なソフトウェア分離層を介して、これらの分離のエレガントな達成が可能であるという着想（様々な規格のレビューによってしか達成できないドメイン情報と、実際のスタックの構築処理とに大きく依存する）に基づくものである。
【００８３】
ＣＶＭの利点
ＣＶＭでは、スタックの開発者たちは使用中の特定のハードウェアから切り離される。ＣＶＭとは、（シンボル指示型及びデータ指示型パイプライン及びステートマシンなどの）構造と、（メモリ割付け、リアルタイム資源、同時性管理など）機能と、デジタル通信用ベースバンド・スタックにより求められる（ＦＦＴ、ビタビ、畳み込みなどの）ライブラリとをサポートし、それによって、高水準言語（ＳＤＬ、ＡＮＳＩＣ／Ｃ＋＋またはＪａｖａ）によるコードの１回の書込みと、単なる再コンパイル（必要な場合には、Ｊａｖａを用いてコードの再コンパイルを行わずに、ＣＯＭまたはコンポーネントの相互通信技術の何らかの別の形により‘２進レベルの’グルーを行ってモジュールを一緒にリンクすることも可能である）とが可能になるようにして、特定のプラットフォーム上で実行し、それによってＣＶＭ層により供給されるハードウェア分離層を介して呼出しを行うようにするものである。
【００８４】
ＣＶＭを用いるプロトタイピングは非常に高速なものとなり、ＤＳＰモジュールの各々は数学モデルにより並列に設けられる。メモリ割付けと分割は、推測作業に依拠するのではなく、（所望のターゲット・ハードウェアによりパラメータ化された）自動化されたツールセットによりサポートされる。いったん処理用チェーンがモデルに対して設定され（この設定は、符号化の代わりにこのグラフィック構成とパラメータ化とによりオプションとして実行される）、作業が首尾よく行われていると、リアルタイムのＰＣベースのバージョンの実行が可能になる（ＲａｄｉｏＳｃａｐｅ社の汎用ベースバンド・プロセッサ・モジュールを備えたＣＶＭのＩｎｔｅｌ ＭＭＸ／ＳＩＭＤバージョンが用いられる）。（カスタム等化器などの）標準的コードに対する任意の変更をモジュラ型増分方法で統合化することが可能であり、さらに（ＰＣベースの）符号化／テスト／編集サイクルはすべての最新のＰＣ開発用ツールを利用することもでき、非常に高速なものとすることも可能となる。ターゲット・プラットフォームでのハードウェア加速処理の利用がＣＶＭによりカバーされている（これは、デジタル通信のベースバンド処理のための、多くのサイクルを要する所要の特性がＣＶＭ ＡＰＩでのライブラリ呼出しとして提供されるためである）。好適に適合された基底を成すハードウェア・ユニットによって、所望の機能のほとんどのためのターゲットとする加速が与えられることは明らかである。多くのアプリケーションの場合、軽量のプリエンプティブ・マルチスレッドと、ＣＶＭ自体でのその他の低レベルの機能とをサポートすることにより、何らかの別のＲＴＯＳの利用は不要となるが、（ウィンドウズＣＥやシンビアンのＥＰＯＣなどのような）ユーザのＯＳとのインタラクションは上述のＡＰＩを介してサポートされ、単純になる。
【００８５】
このアプローチでは、いったん書き込まれたＣＶＭ互換スタックは、特別の作業を伴うことなく、ＣＶＭ自身が移植されたハードウェアのプラットフォームのいずれへも瞬時に移植可能となる（言うまでもなく、リアルタイムで所望のスタックを実行するための十分な資源（ＭＩＰＳ、メモリ、帯域）がターゲット・マシンに常に存在するものと仮定する）。こののことは、（多くのタイプのハードウェアで使用できる適正なＣＶＭのプラットフォームが市場に浸透すると仮定すると）スタック・ベンダにとって実質的な販売の機会が生じることを表すものである。というのは、これはハードウェアの特殊性からスタック・ベンダの開発を実質的に切り離すものであるからである。また、マルチベンダＳｏＣ製品を設計するための特にめざましいビジネス・チャンスも生じる。
【００８６】
ハードウェア・ベンダの視点から見ると、ＣＶＭの利点として、ＣＶＭがいったん所定のプロセッサ用として移植されると、当該プロセッサが、（資源が許せば）ＣＶＭ ＡＰＩに対して書き込まれたすべてのスタックを自動的にサポートするということが挙げられる。言うまでもなく、このことによって、ハードウェア・プロバイダはアプリケーション・ビジネスの中へ入ってゆくことが不要になる。彼らはＣＶＭを移植するだけで十分となる。またこのことは、（少なくともデジタル通信マーケット向けの）スタック・ベンダが、その場合、ＡＮＳＩ Ｃ／Ｃ＋＋またはＪａｖａで純粋にコードを開発することができるので、完全仕様の開発環境とツールセットを形成しサポートする必要性が少なくなることも意味する。ＣＶＭというコンセプトは、例えば、自動車用ブレーキ・システムで使用されるＰＩＤコントローラを作るというような、すべてのデジタル信号処理タスクに適用されるというわけではないことに留意されたい。ＣＶＭのコンセプトがデジタル通信用ベースバンドの処理用として機能する理由として、上記に説明したように、利用が可能なこのようなシステムの中に共通性を示す広いプールが存在することが挙げられる。しかし、ＣＶＭは、別のデジタル信号処理タスクに必要とされるようなすべてのツール、構造あるいは機能を必ずしも提供するものではない。言うまでもなく、共通の機能を示す別のそのような‘島（ｉｓｌａｎｄ）’を特定し、それらの‘島’のニーズをカバーするＣＶＭのイディオム（ｉｄｉｏｍ）の拡張を行うことは潜在的には可能であろう。しかし、本願出願人は本明細書においてベースバンドの側面に焦点を絞っている。なぜなら、ベースバンドの側面が現在非常に求められており、さらに必要な共通性が強く示されているからである。ＣＶＭによるアプローチは、ハードウェア・ベンダが、既存のアプリケーション・セットではなく、代わりに、それらのハードウェアの長所（ＭＩＰＳ、ターゲットの加速、メモリ、電力消費量など）に関して自由に競争ができるようにするものである。
【００８７】
ＣＶＭ開発サイクル
実際にＣＶＭを利用してベースバンド・スタックを開発するプロセスについて以下説明する。本明細書の目的として、デバイスが、デジタル無線装置などのような開発中の目標であることが挙げられる。ソフトウェア、ハードウェアあるいはその双方のいずれかであるコンポーネントは上記デバイスの特定可能な或る特定の一部である。‘解釈される’という表現は、実行時に構成を読み込む（おそらくコンパイルされた）コードを意味する。
【００８８】
開発サイクルは‘コンポーネント定義言語’から始まる。この言語によって、コンポーネントの完全な外部からの可視属性の特定並びにその振舞いが可能になる。その意図として、メーカーがこの可視属性を書き込むことが可能であること、あるいは（後程見るように）計装化ＣＶＭの試運転によりこの可視属性の生成が可能であることが挙げられる。
【００８９】
プラグ・インを介して、業界でポピュラーなＭａｔｌａｂやＭｔｈｅｍａｔｉｃａのような数学モデリング用ツールに１組のコンポーネント定義言語を読み込むことができる。モデリング用ツールを用いて、デバイスで使用するすべてのコンポーネントの理論上の振舞いが利用され、理解される。
【００９０】
上記調査の結果は、開発される別のプラグ・インを介して、‘デバイス定義言語’の中へ転記または出力のいずれかが行われる。ちょうどコンポーネント定義言語がコンポーネントを定義するように、この‘デバイス定義言語’は、構築されているターゲット・デバイスを定義し、さらに、どのコンポーネントが使用されているかというような要素を含むことになる。
【００９１】
言い替えれば、デバイス定義言語は、開発中の通信用‘パイプライン’を定義するものである。ほとんどの通信用デバイスは、パイプラインを介して情報を動かし、その途中で変換を実行するプロセスであると考えることができるので、このパイプラインというコンセプトは重要である。このパイプラインは実際には電子的なアセンブリ・ラインであるが、自動車の部品で機能するようなものではなく、一般に‘シンボル’と呼ばれるデータ項目に対して機能するものである。このようにして、無線信号が最終的にオーディオ信号へ変換されることになる。言うまでもなく、‘現実の’デバイスは単純なパイプラインよりも複雑であることが多く、２以上のパイプライン、ブランチまたはループを備えている場合もある。完全なハードウェア・バージョンを組み立てる前に、このＣＶＭ開発プロセスによりパイプライン設計のテストを行うことが可能となる。これは開発期間の短縮につながるものとなる。
【００９２】
ターゲット・デバイスまたはパイプラインを完全に定義するためにはさらに多くの情報が必要となる。また、本発明のターゲットで利用可能な（ＣＰＵの速度などのような）資源についての説明も必要であり、これは‘適合性記述用言語’と相互接続とで定義される。また各コンポーネント（物理的及びソフトウェアの双方のＡＰＩ）がどのように使用されるかを知っている必要がある。これはコンポーネントＡＰＩ仕様を用いて達成される。
【００９３】
これらの３つの資源：デバイス定義言語、適合性記述用言語及びコンポーネントＡＰＩ仕様はいくつかの可能なＣＶＭの中の１つの範囲内で使用される。第１のＣＶＭは‘計装化され解釈された’パイプライン・マネージャ（あるいは、好適には、計装化され解釈されたバージョンよりもさらに高速に作動する計装化されコンパイルされたＣＶＭのほうが望ましい）である。このパイプライン・マネージャは、ソフトウェアＩＣＥとの或る類似性を有するものである。このマネージャは上記３つの資源を読み出し、パイプラインのエミュレーション（エミュレーションはリアルタイムであってもよい）を行う。したがって、このマネージャはターゲットが無線装置である場合、無線装置として実行する。適合性記述用言語に起因して、このマネージャはターゲット・デバイス上に存在するいずれの障害または資源の限界のシミュレーションをも行うことができ、また、開発とデバッギングとを行うために有用なものである。実行に加えて、計装化され解釈された／または計装化されコンパイルされたパイプライン・マネージャは、各デバイス内コンポーネント定義言語のための診断情報も出力する。この診断情報は重要である。というのは、この情報を今度は開発サイクルの中へフィードバックし、元のコンポーネント定義言語による記述とマージして、その記述の微調整を行うことができるからである。したがって、何らかのハードウェアの組立てを行う前に設計者が実際のパフォーマンスに関する情報を利用することが可能となり、これによって（実質的に）開発の節減が行われる。これによって開発サイクルの内部ループが閉じられる。計装化され解釈された、あるいは、計装化されコンパイルされたパイプライン・マネージャにより、ＣＶＭコアの実行時バージョンが組み込まれる。計装化され解釈された、あるいは、計装化されコンパイルされたパイプライン・マネージャのソフトウェア・エレメントをハードウェアのバージョンと交換する（バグが生じたときバグの検出が可能となるように理想的には１回一度）ことが可能である。この交換されたエレメントは別の開発プロセスのための改善となる。この改善は、計算用サブストレートの両端にわたるエンジンの設計時間段階のスケジュリング処理（上記を参照されたい）に対応するものである。
【００９４】
第２のＣＶＭは‘解釈されたパイプライン・マネージャ’である。この第２のＣＶＭは計装化されたものではないが、別の点では第１のＣＶＭと同一のものである。この第２のＣＶＭは開発とデバッギング時に利用することができ、また、メーカーが完成製品を製造するために利用することができる。このＣＶＭには、通信用デバイスの書込み時の作業の多くを予め行うという第３の利点がある。このＣＶＭにもやはりＣＶＭコアの実行時バージョンが組み込まれている。
【００９５】
第３のＣＶＭは‘パイプライン・ビルダ’である。この第３のＣＶＭはコンパイルされた非計装化変形例と考えることができる。他の２つのＣＶＭのように、この第３のＣＶＭも３つの資源を読み出すが、実行する代わりに、Ｃ言語のようなコンピュータ・ソースコードを出力し、このコードをコンパイルしてパイプラインの実現構成の形成が可能となる。この理由のため、パイプライン・ビルダは、ＣＶＭライブラリを利用できなければならない。利用できるか否かをチェックすることにより開発サイクルの外側のループが閉じられる。ＣＶＭ開発サイクルのアプローチ全体が図８と９に概略的に示されている。
【００９６】
本明細書の従来技術についてのセクションで、テキサス・インスツルメント社から出ている「ｅＸｐｒｅｓｓＤＳＰ（ｅＸｐｒｅｓｓＤＳＰ）リアルタイム・ソフトウェア技術」の存在が認められた。ＣＶＭが有する主要な進歩は当業者には明らかであろう。この進歩の中には以下のことが含まれる：
＊ ｅＸｐｒｅｓｓＤＳＰそれ自体はバーチャル・マシン層ではない。
＊ ＣＶＭによって、単にバーチャル・マシンの移植により様々なＤＳＰプラットフォーム間の移植性が可能になる。ＣＶＭは（ＴＩ社のシステムのように）１つのプラットフォームにのみ結びつけられているものではない。
＊ ＣＶＭには数学モデリングルとの統合化が含まれる。
＊ ＣＶＭによって、ＤＳＰベースのツールの能力に劣らないＰＣベースのツールを利用するスタック開発が可能になる。
＊ ＣＶＭには、ＰＣ上での‘リアルタイム’のプロトタイプを形成して、ターゲット環境上へ１つずつモジュールを移動させる能力が含まれる。
＊ ＣＶＭには、標準的コード・セットの実行により資源タイミングを生成し、次いで、この資源タイミングから‘アーキテクチャ記述プロファイル’を生成する能力が含まれる。
＊ ‘高いサイクル’のルーチンのほとんどは、一般的‘リアルタイムのソフトウェア基盤’の代わりにベースバンド通信エンジンの信号処理要件の方へ方向づけられているＣＶＭ‘環境の中に’予め存在するので、ＣＶＭによって高水準言語を用いる開発が可能になる。
＊ またＣＶＭでは、ベースバンドＤＳＰに共通して必要とされる、データの種類と、動的資源と、バッファ管理とが含まれる。
＊ ＣＶＭでは演繹的資源予測と同時性分析とが行われる。
＊ ＣＶＭには単に機能エレメント（ＡＰＩ）が含まれるだけではなく、起呼構造（ＤＳＰコードがどのように動的に機能するか）並びに（ＰＣベースのプロトタイピングと、最終的エンド・ターゲットを通じての数学モデリング、資源モデリングによる）全体的な開発パラダイムの支援も含まれる。
＊ ＣＶＭによって、所望の場合サード・パーティのＲＴＯＳの利用が可能になり、さらに、所望の場合ＲＴＯＳなしの機能も可能である。
＊ ＣＶＭは２段階スケジュリングを提供する。
＊ ＣＶＭにより、ＡＳＩＣとＳｏＣへ移行する利点が可能になる。
＊ ＣＶＭによって、完全に統合化され、しかも、プラットフォームから独立したランタイムと設計用ツールとが提供される。
―附属説明―
コア処理の例
信号変換と周波数領域分析
＊ 信号フローグラフ（ＳＦＧ）離散周波数ＤＦＴ
＊ ウィンドウ操作（ハミング、ハニングなど）
デジタル・フィルタリング
＊ デジタルＦＩＲフィルタ
＊ インパルス応答
＊ 周波数応答
＊ ＦＩＲ低域デジタル・フィルタ
＊ 無限インパルス応答デジタル・フィルタ
適応信号処理
＊ 適応型デジタル・フィルタを含む適応信号処理用コンポーネント
＊ チャネル識別
＊ エコー・キャンセレーション
＊ 音響エコー・キャンセレーション
＊ 暗騒音抑制
＊ チャネル等化
＊ 適応型ライン拡張機能（ＡＬＥ）
＊ 以下を含む適応型アルゴリズム：
＊ 平均２乗誤差の最少化
＊ ＦＩＲフィルタ用適応型アルゴリズム
＊ 平均２乗誤差
＊ 最小平均２乗誤差の解
＊ ウィーナ／ホップ（Ｗｉｅｎｅｒ−Ｈｏｐｆ）解
＊ 傾度法１
＊ 傾度法２
＊ ＬＭＳアルゴリズム
＊ 再帰的最小２乗法
＊ 適応型ＩＩＲフィルタリング
＊ 勾配ＩＩＲフィルタリング技術
＊ ＦｅｉｎｔｕｃｈのＩＩＲ ＬＭＳ
＊ 等式誤差ＬＭＳアルゴリズム
＊ 直接モード（ＤＤＭ）
＊ サブバンド適応型フィルタ（ＳＡＦ）構造
マルチレート信号処理
＊ アップサンプリング＆ダウンサンプリング
＊ 内挿ローパス・フィルタ
＊ オーバーサンプリングと再構成
＊ シグマ／デルタ処理アーキテクチャ
＊ サブバンド処理
＊ 反復によるＭチャネル・フィルタ・バンク
＊ 変調フィルタ・バンク
＊ 多相フィルタ・バンク
＊ ＱＭＦフィルタ・バンク
オーディオ信号ソース符号化
＊ 無損失ハフマン（Ｈｕｆｆｍａｎ）符号化／復号化
＊ 線形ＰＣＭ
＊ 圧伸
＊ 適応型量子化ツール
＊ 線形予測符号化
＊ 長期予測
＊ デルタ変調（ＤＭ）
＊ 差分パルス符号変調
＊ 適応型ＤＰＣＭ（ＡＤＰＣＭ）ＬＰＣボコーダ
＊ 符号励振線形予測（ＣＥＬＰ）
＊ 代数的ＣＥＬＰ（ＡＣＥＬＰ）
＊ サブバンド符号化
＊ 精神聴覚学用ツール
＊ スペクトル・マスキング
＊ 時間マスキング
＊ 精度適応型サブバンド符号化及びビット割当て及びビット・ストリーム・フォーマッティング・ツール
デジタル変調
＊ ＸＯＲ長短コード拡散／逆拡散
＊ 振幅変調
＊ 直角振幅変調（ＱＡＭ）
＊ 直角位相復調
＊ 複雑な直角位相変調
＊ 複雑な直角位相復調
＊ ＱＰＳＫ
＊ ｎ−ＰＳＫ
＊ Ｍ−ａｒｙ振幅偏移キーイング
＊ π／ｎＱＰＳＫ
＊ ユニポーラＲＺ及びＮＲＺシグナリング
＊ 極座標及びバイポーラＲＺ及びＮＲＺシグナリング
＊ 以下を含む帯域通過偏移キーイング
＊ 振幅（ＯＮ−ＯＦＦ）偏移キーイング
＊ ２進位相偏移キーイング（ＢＰＳＫ）
＊ 以下を含む周波数偏移キーイング
＊ ＢＰＳＫ用帯域フィルタリング
＊ 以下を含むパルス成形
＊ ナイキスト・パルス成形
＊ ２乗余弦パルス成形
＊ 平方根２乗余弦パルス成形
拡散スペクトル・ツール
＊ 擬似乱数コード生成
＊ 黄金シーケンス
＊ カサミ・シーケンス
＊ 直交拡散符号
＊ 可変長ＯＣ生成
＊ 直交ウォルシュ・コード
＊ コード検出
＊ レイク受信装置実装
＊ 以下を含むＮＢＩ拒絶技術
＊ 予測フィルタ
＊ 変換領域におけるＮＢＩ拒絶
＊ 決定フィードバックＮＢＩ拒絶
多元接続＆検出管理用ツール
＊ 以下を含むＴＤＭＡ
＊ ＴＤＭＡフレーム
＊ ＦＤＭＡと合成されたＴＤＭＡ
＊ 以下を含むＣＤＭＡ
＊ 直接シーケンス（ＤＳ）ＣＤＭＡ
＊ 電力制御
＊ ビーム成形用ツール
＊ 周波数ホッピングＣＤＭＡ
＊ マルチユーザ検出（ＭＵＤ）
＊ 多元接続干渉抑制
＊ 非相関性
＊ 干渉キャンセラ
＊ 適応型ＭＭＳＥ
＊ ＭＭＳＥ受信機トレーニング
＊ 適応型ＭＭＳＥ受信機ＤＤＭ
移動チャネル
＊ レイリー・フェージング抑制メカニズム（ガウス、Ｒｉｃｅｉａｎ）
＊ 以下を含むモデリング及び抑制用ツール：
＊ タイム・スプレディング
＊ タイム・スプレディング：コヒーレンス帯域
＊ タイム・スプレディング：平坦フェージング
＊ タイム・スプレディング：Ｆｒｅｑ選択フェージング
＊ チャネルのタイム変形振舞い
＊ ドップラ効果
チャネル符号化
＊ 巡回符号器
＊ リード・ソロモン（Ｒｅｅｄ Ｓｏｌｏｍｏｎ）符号器
＊ 畳み込み符号器
＊ ＣＥパンクチャリング
＊ インターリービング
＊ 畳み込み復号器
＊ ビタビ復号器（ハード及びソフト決定）
＊ ターボ・コード
＊ ターボ符号化
＊ ターボ復号化
等化
＊ 適応型チャネル等化
＊ ＦＩＲ等化器
＊ 決定フィードバック等化器
＊ 直接変換ツールキット
＊ ＱＡＭアナログＲＦ／ＩＦアーキテクチャ
＊ ＱＡＭ ＩＦダウンコンバージョン・サポート
＊ 帯域通過シグマ・デルタサポート
＊ ベースバンド・サポートへの帯域通過シグマ・デルタ
＊ 帯域通過及びｆｓ／４システム
信号処理ライブラリ関数
このセクションはＣＶＭで利用可能な信号処理関数の若干について説明する。
＊ ベクトル操作関数
ＡｕｔｏＣｏｒｒｅｌａｔｅ 入力ベクトルの通常の、バイアスをかけたあるいはバイアスをかけていない自己相関を推定し、その結果を第２のベクトルに格納する
Ｃｏｎｊｕｇａｔｅ （ｖｅｃｔｏｒ） ベクトルの複素共役を計算し、その結果を対応する当該レジスタ又は別のベクトルに返すことが可能である。
Ｃｏｎｊｕｇａｔｅ （ｖａｌｕｅ） 複素数値の共役を返す。
Ｅｘｔｅｎｄｅｄ Ｃｏｎｊｕｇａｔｅ 対応する当該レジスタ又は新しいベクトルでベクトルの共役／対称拡張を計算する。
Ｅｘｐ 各エレメントが、入力ベクトル内の対応するエレメントのパワーに対してｅであるベクトルを計算する。この結果は対応する当該レジスタ又は別のベクトルに返すことができる。
ＩｎｖｅｒｓｅＴｈｒｅｓｈｏｌｄ 閾値を用いてベクトルの逆エレメントを計算する。この結果は対応する当該レジスタ又は別のベクトルに返すことができる。
Ｔｈｒｅｓｈｏｌｄ ベクトルで閾値演算処理を実行する。この結果は対応する当該レジスタ又は別のベクトルに返すことができる。
ＣｒｏｓｓＣｏｒｒｅｌａｔｅ ２つのベクトルの相互相関を推定し、第３のベクトルにその結果を格納すする。
ＤｏｔＰｒｏｄｕｃｔ ２つのベクトルに対してＥｘｔｅｎｄｅｄＣｏｎｊｕｃａｔｅ演算を適用後、２つのベクトルの点乗積を計算する
ＥｘｔｅｎｄｅｄＤｏｔＰｒｏｄ ２つの共役シンメトリック拡張ベクトルの点乗積を計算する
ｄｏｗｎｓａｍｐｌｅ 或る信号をダウンサンプルし、概念的に或る整数係数分だけそのサンプリング速度を落とす。第２のベクトルにその結果を返す。
Ｍａｘ ベクトルで最大値を返す。
Ｍｅａｎ ベクトルでエレメントの平均値を計算する。
Ｍｉｎ ベクトルで最小値を返す。
ｕｐｓａｍｐｌｅ 或る信号をアップサンプルし、概念的に或る整数係数分だけそのサンプリング速度を上げる。第２のベクトルにその結果を返す。
ＰｏｗｅｒＳｐｅｃｔｒｕｍ （１） 第２のベクトルで複素ベクトルのパワー・スペクトルを返す
ＰｏｗｅｒＳｐｅｃｔｒｕｍ （２） 実数成分と虚数成分が２つのベクトルで表される複素ベクトルのパワー・スペクトルを計算する。第３のベクトルにその結果を格納する。
Ａｄｄ ２つのベクトルを加算し、第３のベクトルにその結果を格納する。
Ｓｕｂｔｒａｃｔ １つのベクトルを別のベクトルから減じ、第３のベクトルにその結果を格納する。
Ｍｕｌｔｉｐｌｙ ２つのベクトルを乗算し、第３のベクトルにその結果を格納する。
Ｄｉｖｉｄｅ １つのベクトルを別のベクトルで除し、第３のベクトルにその結果を格納する。
＊ 複素ベクトル演算
ＩｍａｇｉｎａｒｙＰａｒｔ 第２のベクトルで複素ベクトルの虚数部分を返す。
ＲｅａｌＰａｒｔ 第２のベクトルで複素ベクトルの実数部分を返す。
Ｍａｇｎｉｔｕｄｅ （１） 複素ベクトルの要素の振幅を計算し、第２のベクトルにその結果を格納する。
Ｍａｇｎｉｔｕｄｅ （２） この第２のバージョンは、個々の実ベクトルで指定された実数成分と虚数成分を持つ複素ベクトルの要素の振幅を計算し、第３のベクトルにその結果を格納する。
Ｐｈａｓｅ （１） 第２のベクトルで複素ベクトルの要素の位相角を返す
Ｐｈａｓｅ （２） それぞれ実ベクトルと、虚ベクトルで指定される実数成分と虚数成分とを持つ複素入力ベクトルの要素の位相角を計算する。この関数は、第３のベクトルに結果として生じる位相角を格納する。
ＣｏｍｐｌｅｘＴｏＰｏｌａｒ 個々の入力ベクトルの実数／虚数（デカルト座標Ｘ／Ｙ）の対を極座標形式に変換する。１つのバージョンは、１つのベクトルに各要素の成分の振幅（半径）を格納し、別のベクトルに各要素の位相（角）成分を格納する。
ＣｏｍｐｌｅｘＴｏＰｏｌａｒ 第２のバージョンは、単一ベクトルで（振幅、位相の）対として極座標を返す。
ＰｏｌａｒＴｏＣｏｍｐｌｅｘ ベクトルに格納される極形式（振幅、位相）の対を複素ベクトルに変換する。この結果を第２のベクトルで返す。
ＰｏｌａｒＴｏＣｏｍｐｌｅｘ 個々のベクトルに格納された極形式の振幅／位相の対を複素ベクトルに変換する。この関数は第３のベクトルにその結果の実数成分を格納し、第４のベクトルに虚数成分を格納する。
ＰｏｌａｒＴｏＣｏｍｐｌｅｘ ２つの個々のベクトルに格納された極形式の振幅／位相の対を複素ベクトルに変換する。この関数は、第３のベクトルにその結果の実数成分を格納し、第４のベクトルに虚数成分を格納する。
＊ サンプル量子化
これらの方法は線形と非線形量子化方式との間での変換を行う。使用ビット数と、使用非線形パラメータとは変更してもよい。
ＡｌａｗｔｏＬｉｎｅａｒ Ａ−ｌａｗ符号化サンプルのベクトルを線形サンプルへ変換する。この結果は対応する当該レジスタ又は別のベクトルに返すことができる。
ＬｉｎｅａｒＴｏＡＬａｗ 線形サンプルベクトルを符号化する。この結果は、Ａ−ｌａｗフォーマットを用いて、対応する当該レジスタ又は別のベクトルに返すことができる。
ＬｉｎｅａｒＴｏＭｕＬａｗ ｐｔ−ｌａｗを用いてベクトルで線形サンプルを符号化する。この結果は対応する当該レジスタ又は別のベクトルに返すことができる。
ＭｕｌａｗＴｏｌｉｎｅａｒ ８ビットｋｔ−ｌａｗの符号化されたサンプルのベクトルを線形フォーマットに変換する。この結果は対応する当該レジスタ又は別のベクトルに返すことができる。
＊ サンプル生成関数
ＲａｎｄｏｍＧａｕｓｓｉａｎ ガウス分布を用いて疑似ランダム・サンプルのベクトルを計算する。
ＩｎｉｔｉａｌｉｓｅＴｏｎｅ 所定の周波数、位相及び振幅を用いて正弦波発生装置を初期化する。
ＮｅｘｔＴｏｎｅ ＩｎｉｔｉａｌｉｓｅＴｏｎｅを用いて指定された周波数、位相、振幅の正弦波の次のサンプルを生成する。
ＩｎｉｔｉａｌｉｓｅＴｒｉａｎｇｌｅ 所定の周波数、位相及び振幅を用いて三角波発生装置を初期化する。
ＮｅｘｔＴｒｉａｎｇｌｅ ＩｎｉｔｉａｌｉｓｅＴｒｉａｎｇｌｅのパラメータを用いて生成された三角形波の次のサンプルを生成する。
＊ ウィンドウ関数
ｂａｒｔｌｅｔｔｗｉｎｄｏｗ ベクトルにＢａｒｄｅｎｔウィンドウ関数を乗算する。その結果は第２のベクトルで返される。
ＢｌａｃｋｍａｎＷｉｎｄｏｗ ユーザ指定パラメータを用いてベクトルにＢｌａｃｋｍａｎウィンドウ関数を乗算する。その結果は第２のベクトルで返される。
ＨａｍｍｉｎｇＷｉｎｄｏｗ ベクトルにＨａｍｍｉｎｇウィンドウ関数を乗算する。その結果は第２のベクトルで返される。
ＨａｎｎＷｉｎｄｏｗ ベクトルにＨａｎｎウィンドウ関数を乗算する。その結果は第２のベクトルで返される。
ＫａｉｓｅｒＷｉｎｄｏｗ ベクトルにＫａｉｓｅｒウィンドウ関数を乗算する。その結果は第２のベクトルで返される。
＊ 畳み込み関数
Ｃｏｎｖｏｌｖｅ ２つのシーケンスの有限、線形畳み込みを実行する。
Ｃｏｎｖｏｌｖｅ２Ｄ ２つの２次元信号の有限、線形畳み込みを実行する。
Ｆｉｌｔｅｒ２Ｄ Ｃｏｎｖｏｌｖｅと類似の２次元信号をフィルタする。但し、同じサイズの入出力配列を用いる。
＊ フーリエ変換関数
これらの方法のバージョンは、複数の異なるデータ格納（固定型、浮動型、整数型）フォーマット用のものが存在する。
ＤｉｓｃｒｅｔｅＦＴ 対応する当該レジスタ又は別のベクトルで離散フーリエ変換を計算する。
ＩｎｉｔｉａｌｉｓｅＧｏｅｒｔｚ Ｇｏｅｒｔｚｅｌ関数により使用されるデータを初期化する。
ＲｅｓｅｔＧｏｅｒｔｚ Ｇｏｅｒｔｚｅｌ関数により使用される内部遅延ラインをリセットする。
ＧｏｅｒｔｚＦＴ（１） 単一信号カウント用の所定の周波数についてＤＦＴを計算する。
ＧｏｅｒｔｚＦＴ（２） 連続する信号カウント・ブロック用の所定の周波数についてＤＦＴを計算する。
ＦＦＴ （１） 対応する当該レジスタ又は別のベクトルのいずれかでベクトルの複素高速フーリエ変換を計算する。
ＦＦＴ （２） 対応する当該レジスタ又は別のベクトルのいずれかで２つの共役左右対称信号の順方向高速フーリエ変換を計算する。
ＦＦＴ （３） 対応する当該レジスタ又は別のベクトルのいずれかで１つの共役左右対称信号の順方向高速フーリエ変換を計算する。
ＦＦＴ （４） 複素ベクトルの高速フーリエ変換を計算し、その結果を２つの別々の（実数と虚数）ベクトルで返す。
ＦＦＴ （５） ２つの別々の（実数と虚数）ベクトルとして与えられた複素ベクトルの高速フーリエ変換を計算し、その結果を２つの別々の（実数と虚数）ベクトルで返す。
ＩＦＦＴ （１） 対応する当該レジスタ又は別のベクトルのいずれかでベクトルの逆高速フーリエ変換を計算する。
ＩＦＦＴ （２） 対応する当該レジスタ又は別のベクトルのいずれかで２つの共役左右対称信号の逆高速フーリエ変換を計算する。
ＩＦＦＴ （３） 対応する当該レジスタ又は別のベクトルのいずれかで共役左右対称信号の逆高速フーリエ変換を計算する。
＊ 有限のインパルス応答フィルタ関数
ＩｎｉｔｉａｌｉｓｅＦＩＲ １セットの；１組の遅延ライン値とタップとを用いて低レベル、単一レート有限インパルス応答フィルタを初期化する。
ＦＩＲ ＩｎｉｔｉａｌｉｓｅＦＩＲを用いて前に構成された低レベル、有限インパルス応答フィルタを介して単一サンプルをフィルタする。
ＢｌｏｃｋＦＩＲ 低レベル有限インパルス応答フィルタを介してサンプルのブロックをフィルタする。
ＧｅｔＦｉｒＤｅｌａｙｓ 低レベル有限インパルス応答フィルタのための遅延ライン値をゲットする。
ＧｅｔＦＩＲＴａｐｓ 低レベル有限インパルス応答フィルタのためのタップ係数をゲットする。
ＳｅｔＦＩＲＤｅｌａｙｓ 低レベル有限インパルス応答フィルタのための遅延ライン値を変更する。
ＳｅｔＦＩＲＴａｐｓ 低レベル有限インパルス応答フィルタのためのタップ係数を変更する。
Ｉｎｉｔｉａｌｉｓｅｍｕｌｔｉｆｉｒ 低レベル・マルチレート有限インパルス応答フィルタを初期化する。
Ｍｕｌｔｉｆｉｒ ＩｎｉｔｉｓｌｉｓｅＭｕｌｔｉＦｉｒを用いて前に構成された低レベル・マルチレート有限インパルス応答フィルタを介して単一サンプルをフィルタする。
ＢｌｏｃｋＭｕｌｔｉＦＩＲ ＩｎｉｔｉｓｌｉｓｅＭｕｌｔｉＦＩＲを用いて前に構成された低レベル・マルチレート有限インパルス応答フィルタを介してサンプル・ブロックをフィルタする。
＊ 最小乗平均適合化フィルタ関数
ＩｎｉｔｉａｌｉｓｅＳＡＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レート適応型ＦＩＲフィルタを初期化する。
ＩｎｉｔｉａｌｉｓｅＭＡＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マルチレート適応型ＦＩＲフィルタを初期化する。
ＩｎｉｔＡＬＦＤｅｌａｙ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用遅延ラインを初期化する。
ＳＡＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レート適応型ＦＩＲフィルタを介してサンプルをフィルタする。
ＭＡＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マルチレート適応型ＦＩＲフィルタを介してサンプルをフィルタする。
ＳＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レート適応型ＦＩＲフィルタを介してサンプルをフィルタするが、２次信号用としてフィルタの適合は行わない。
ＭＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マルチレート適応型ＦＩＲフィルタを介してサンプルをフィルタするが、２次信号用としてフィルタの適合は行わない。
ＥｎｇｉｎｅｓＡＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レート適応型ＦＩＲフィルタを介してサンプルのブロックをフィルタする。
ＢｌｏｃｋＭＡＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マルチレート適応型ＦＩＲフィルタを介してサンプルのブロックをフィルタする。
ＥｎｇｉｎｅｓＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レート適応型ＦＩＲフィルタを介してサンプルのブロックをフィルタするが、２次信号用としてフィルタの適合は行わない。
ＢｌｏｃｋＭＬＦ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マルチレート適応型ＦＩＲフィルタを介してサンプルのブロックをフィルタするが、２次信号用としてフィルタの適合は行わない。
ＳｅｔＡＬＦＤｅｌａｙｓ 低レベル適応型最小２乗平均（ＬＭＳ）アルゴリズムを用いるＦＩＲフィルタ用として遅延ライン値をセットする。
ＳｅｔＡＬＦＬｅａｋｓ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用として漏れ値をセットする。
ＳｅｔＡＬＦＳｔｅｐｓ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用ステップ値をセットする。
ＳｅｔＡＬＦＴａｐｓ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用としてタップ係数をセットする。
ＧｅｔＡＬＦＤｅｌａｙｓ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用として遅延ライン値をゲットする。
ＧｅｔＡＬＦＬｅａｋｓ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用として漏れ値をゲットする。
ＧｅｔＡＬＦＳｔｅｐｓ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用としてステップ値をゲットする。
ＧｅｔＡＬＦＴａｐｓ 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩＲフィルタ用としてタップ係数をゲットする。
＊ 無限インパルス応答フィルタ関数
ＩｎｉｔｉａｌｉｓｅＩＩＲ 指定されたオーダーの低レベル無限インパルス応答フィルタを初期化する。
ＩｎｉｔｉａｌｉｓｅＢｉｑｕａｄＩＩＲ 低レベル無限インパルス応答（ＩＩＲ）フィルタをｂｉｑｕａｄｓ（二次オーダーＩＩＲセクション）のカスケード基準信号に初期化する。
ＩｎｉｔｉａｌｉｓｅＩＩＲＤｅｌａｙ 低レベル無限インパルス応答（ＩＩＲ）フィルタ用として遅延ラインを初期化する。
ＩＩＲ 低レベル無限インパルス応答フィルタを介して単一サンプルをフィルタする。
ＢｌｏｃｋＩＩＲ 低レベル無限のインパルス応答フィルタを介してサンプルのブロックをフィルタする。
＊ ウェーブレット関数
ＤｅｃｏｍｐｏｓｅＷａｖｅｌｅｔ 信号をウェーブレット連続に分解する。
ＲｅｃｏｎｓｔｒｕｃｔＷａｖｅｌｅｔ ウェーブレット分解から信号を再構成する。
＊ 離散余弦変換関数
ＤＣＴ 離散余弦変換（ＤＣＴ）を実行する。
ベクトル・データ変換関数
このセクションで記述したすべての関数は、（様々な整数長、異なる浮動小数点フォーマット及び浮動小数点数の固定小数点表示のような）複数の様々なデータ・フォーマットでの機能が可能である。この信号処理ライブラリには、サポートされているフォーマットのすべての対の間で単一値とベクトルとを変換する方法が含まれる。
【図面の簡単な説明】
【図１】
マイクロソフト社のウィンドウズを利用している場合のハードウェアとアプリケーション・ソフトウェアとの間の関係を示す概略図である。
【図２】
ハードウェアとアプリケーション・ソフトウェアとの間のマイクロソフト社のウィンドウズ以前の関係を示す概略図である。
【図３】
ベースバンド・スタックのアーキテクチャ上仮定的に中立な部分を切り離すことができない従来の方式に起因する障害を示す概略図である。
【図４Ａ】〜
【図４Ｂ】
本発明におけるベースバンド・スタックのアーキテクチャから見て中立な部分の切り離しの成功を示す概略図である。
【図５】
ベースバンド通信スタック内の構造を示す概略図である。
【図６】
本発明の実施例での共通のエンジンと構造とを示す概略図である。
【図７】
本発明のＣＶＭと、ハードウェアとスタックとの間の関係を示す概略図である。
【図８】〜
【図９】
本発明を利用する開発サイクルでのステップを示す概略図である。
【用語の説明】
Ａｒｃｈｉｔｅｃｔｕｒｅ Ｎｅｕｔｒａｌ Ｌａｙｅｒ １ Ｃｏｄｅ ｉｎ ＳＤＬ ＳＤＬで書かれたアーキテクチャから見て中立な層１コード
ＲａｄｉｏＳｃａｐｅ ＣＶＭ ＲａｄｉｏＳｃａｐｅ社製ＣＶＭ
Ａｒｃｈｉｔｅｃｔｕｒｅ Ｓｐｅｃｉｆｉｃ Ｈｉｇｈ ＭＩＰＳ Ｄａｔａ ｐａｔｈｓ アーキテクチャ独自の高ＭＩＰＳデータ・パス
Ｅｎｇｉｎｅ エンジン
【図１】
１：アプリケーション・ソフトウェア１
２：アプリケーション・ソフトウェア２
３：ウィンドウズ・バーチャルマシン
４：プリンタ・ドライバ（共有）
５：ＤＯＳ Ｂ／Ｓ
６：ハードウェア
【図２】
１：アプリケーション・ソフトウェア１
２：カスタム・プリンタ・ドライバ
３：カスタムＧＵＩコード
４：アプリケーション・ソフトウェア２
５：カスタム・プリンタ・ドライバ
６：カスタムＧＵＩコード
７：ＤＯＳ Ｂ／Ｓ
８：ハードウェア
【図３】
１：スタックのアーキテクチャから見て中立な部分（正しく切り離されていない）
２：通信用マシン層
３：アセンブラ・コードされたベクトル関数
４：共通のＤＳＰフロー制御構造
５：ハードウェア加速ドライバ
６：ＤＭＡ ＣＣＳ及び資源管理
７：オプションのＲＴＯＳ
８：ハードウェア２
【図４Ａ】
１：スタックのアーキテクチャから見て中立な部分（ハードウェアから切り離されている）
２：通信用マシン層
３：アセンブラ・コードされたベクトル関数
４：共通のＤＳＰフロー制御構造
５：ハードウェア加速ドライバ
６：ＤＭＡ ＣＣＳ及び資源管理
７：オプションのＲＴＯＳ
８：ハードウェア２
【図４Ｂ】
１：ＳＤＬで書かれたアーキテクチャから見て中立な層１コード
２：ＲａｄｉｏＳｃａｐｅ社製ＣＶＭ
３：アーキテクチャ独自の高ＭＩＰＳデータ・パス
４：エンジン
【図５】
１：コンテンツ生成
２：ソース符号化
３：チャネル符号化
４：変調
５：復調
６：チャネル復号化
７：ソース復号化
８：コンテンツ・プレゼンテーションＡｐｐ
【図６】
１：Ｉ／Ｏ
２：ＡＥＣ
３：ＦＦＴ
４：Ｃｈａｎ Ｐｒｏｃ
５：Ｄｅｍｏｄ
６：ＭＭＩコード
７：パイプライン段階
８：シンボル指示型処理
９：データ指示型処理
【図７】
１：スタック境界
２：Ｃ＋＋コア・コード
３：ＣＶＭ Ａ
４：ハードウェア＋Ｏ／Ｓ Ａ
５：スタック境界
６：Ｃ＋＋コア・コード
７：ＣＶＭ Ｂ
８：ハードウェア＋Ｏ／Ｓ Ｂ
【図８】
１：初期アーキテクチャ仕様書
２：数学モデリング用ツール（Ｍａｒｌａｂ）
３：グラフ記述言語（ＧＤＬ）
４：ＰＣ開発環境（ＭＳ Ｄｅｖ．Ｓｔｕｄｉｏ，Ｔａｕ）
５：アーキテクチャから見て中立な通信スタック（Ｃ＋＋／ＳＤＬ）
６：ＲａｄｉｏＳｃａｐｅプラグ・イン拡張
７：ＲａｄｉｏＳｃａｐｅライブラリ
８：ＲａｄｉｏＳｃａｐｅターゲット内蔵ＣＶＭ環境
９：ＲａｄｉｏＳｃａｐｅ Ｉｎｔｅｌ ＭＭＸ／ＳＩＭＤ ＣＶＭ環境
１０：プラグ・イン内蔵コンパイラ
１１：アーキテクチャ・レポート（ＭＩＰＳ、メモリ、ＣＣＳ）
１２：ＲａｄｉｏＳｃａｐｅアーキテクチャ解析ツール
１３：ＲａｄｉｏＳｃａｐｅＰＣ内ＲＦプロトタイピング用ＰＣＩボード
１４：ＦＰＧＡ／ＤＳＰ処理用ボード
【図９】
１：ＣＶＭ開発サイクル
２：モデリング用ツール（Ｍａｔｌａｂ数学など）
３：パイプライン
４：プラグ・イン（ＲＳ）
５：ＴＢＡ
６：手で
７：定義する
８：コンポーネント定義言語
９：コンポーネントＡＰＩ
１０：コンポーネントの振舞い
１１：デバイス定義言語
１２：適合性記述用言語
１３：コンポーネント“ＡＰＩ”仕様
１４：計装化
１５：解釈された
１６：パイプライン・マネージャ
１７：実行＆ログ
１８：実行
１９：コンポーネント定義言語
２０：ソースコード
２１：パイプライン・ビルダ
２２：ＶＭライブラリ
２３：コンポーネント・ライブラリ
２４：コンパイル
２５：パイプライン
整理番号 ８８４
Claims (44)
- デジタル信号処理の設計、モデリングまたは実行を行うためのソフトウェアにおいて、通信用ＤＳＰとして最適化されたバーチャル・マシン層を含むことを特徴とするソフトウェア。
- 請求項１に記載のソフトウェアにおいて、上記バーチャル・マシン層により表されるＡＰＩを用いることにより、低ＭＩＰＳコードが、上記バーチャル・マシン層によって高ＭＩＰＳプロセスとインターフェースすることを可能にすることを特徴とするソフトウェア。
- 請求項２に記載のソフトウェアにおいて、上記高ＭＩＰＳプロセスが抽象的なプロセスの実現構成であり、上記ＭＩＰＳプロセスは、アクセス・コストを最適化するように、ランタイム環境下で組織化されていることを特徴とするソフトウェア。
- 請求項３に記載のソフトウェアであって、上記高ＭＩＰＳプロセスをエンジンで実行し、（ｉ）上記設計及びモデリング段階と、（ｉｉ）上記ランタイムとのいずれかあるいは双方の時間中、最適の資源利用を行うために、異なるエンジン間での処理の同時スケジュリングを行うようにスケジュラをプログラムするソフトウェアにおいて、上記資源割当てが以下の、（ａ）統計関数を用いる測定と、（ｂ）統計分布関数を用いるモデリングのステップのうちの一方または双方のステップを含むことを特徴とするソフトウェア。
- 請求項４に記載のソフトウェアであって、上記バーチャル・マシン層が、いくつかの異るベースバンド処理用アルゴリズムに共通の基底を成す高ＭＩＰＳアルゴリズムをサポートし、さらに、スケジュラ・インターフェースを介して、高水準の、アーキテクチャから見て中立な、潜在的に高度の複雑さを持ちながら、しかも低ＭＩＰＳの制御フローに上記アルゴリズムがアクセスすることを可能にするソフトウェアにおいて、上記スケジュラ・インターフェースは、（ｉ）ランタイム、（ｉｉ）メモリ、（ｉｉｉ）起呼発信者が実行命令の実行を望む帯域のいずれかあるいはすべての内側に在る相互接続帯域、のうちの１以上に関連する１組の資源制約包絡線と共に、上記制御フローが実行すべきアルゴリズムを指定することを可能にすることを特徴とするソフトウェア。
- 請求項４に記載のソフトウェアにおいて、設計またはモデリング中、異なるエンジンにわたる高ＭＩＰＳプロセスのデータ・パスの分画を可能にするのに適合するることを特徴とするソフトウェア。
- 請求項６に記載のソフトウェアにおいて、上記スケジュラが、異なるエンジンにわたって行われる上記データ・パス分画決定をランタイム中に認知していることを特徴とするソフトウェア。
- 請求項２に記載のソフトウェアにおいて、上記低ＭＩＰＳコードの少なくとも一部が、リアルタイムのオペレーション用として設計されていない言語で表現されることを特徴とするソフトウェア。
- 請求項８に記載のソフトウェアにおいて、上記言語がＳＤＬであることを特徴とするソフトウェア。
- 請求項２に記載のソフトウェアにおいて、アーキテクチャから見て中立な方法で上記低ＭＩＰＳコードを表すことを可能にすることを特徴とするソフトウェア。
- 請求項２に記載のソフトウェアであって、アーキテクチャから見て中立な低ＭＩＰＳ制御コードを用いてベースバンド・スタックを組み立てることを可能にするソフトウェアにおいて、上記制御コードが、エンジンに設けられたアーキテクチャ固有の高ＭＩＰＳプロセスにアクセスするために、上記バーチャル・マシン層により指定される、１組のアーキテクチャから見て中立なＡＰＩを使用することを特徴とするソフトウェア。
- 請求項１１に記載のソフトウェアにおいて、少なくとも１つの高ＭＩＰＳエンジンがいくつかの様々な種類のベースバンド・スタックのために資源を供給することを特徴とするソフトウェア。
- 請求項２に記載のソフトウェアにおいて、リアルタイムで別の処理との同時スケジュリングを行うことが可能となるように、様々な処理の静的及び動的資源要件を特徴づけるようにプログラムされることを特徴とするソフトウェア。
- 請求項１３に記載のソフトウェアにおいて、完全に統合化された数学モデルと、統計的シミュレーション・ツールと、序列的分画用シミュレーション・ツールとをさらに有することを特徴とするソフトウェア。
- 請求項１乃至１４のいずれかのソフトウェアにおいて、チップ上のシステム用の設計プラットフォームまたはモデリング・プラットフォームとして機能することを特徴とするソフトウェア。
- 請求項１５に記載のソフトウェアにおいて、各々がいくつかの異なるベンダから得られる知的財産ブロックを、上記ソフトウェアによってモデル化される各ブロックの上記静的及び動的資源要件によって、上記システムにおいてチップ上で組み合わせることができ、それによって、複数のブロックが、リアルタイムで同時スケジュリングを行うことができるようにすることを特徴とするソフトウェア。
- 請求項１６に記載のソフトウェアにおいて、上記ブロックが高ＭＩＰＳの処理を実行することを特徴とするソフトウェア。
- 請求項１６に記載のソフトウェアにおいて、上記ブロックが低ＭＩＰＳ制御処理を実行することを特徴とするソフトウェア。
- 請求項１に記載のソフトウェアにおいて、（ａ）非リアルタイム設計とモデリングのためのＰＣプロトタイプから、（ｂ）ランタイムのための１以上の外部ＦＰＧＡを備えた１以上のＤＳＰチップへ、デジタル信号処理が実行されるような上記サブストレートを移行させる過程で利用されることを特徴とするソフトウェア。
- 請求項１９に記載のソフトウェアにおいて、上記サブストレートが次にカスタムＡＳＩＣへ移行されることを特徴とするソフトウェア。
- 請求項１に記載のソフトウェアにおいて、上記バーチャル・マシン層が、以下の（ａ）から（ｅ）を用いてプログラムされること、あるいは、以下の（ａ）から（ｅ）へのアクセスを可能にすることを特徴とするソフトウェア。
（ａ）コア処理
（ｂ）コア構造
（ｃ）コア機能
（ｄ）フロー制御
（ｅ）状態管理 - 請求項２１に記載のソフトウェアにおいて、上記コア処理が、１以上の以下のステップ、すなわちソース符号化、チャネル符号化、変調、または、それらの逆のステップ、すなわちソース復号化、チャネル復号化及び復調ステップを実行するアルゴリズムを含むことを特徴とするソフトウェア。
- 請求項２１に記載のソフトウェアにおいて、上記コア構造が（当該シンボルの範囲内に保持されているすべての情報が利用できるか否かにかかわらず、フル・シンボル処理と関係する）シンボル処理部と、関連情報を保持する当該ビットのみを処理するデータ指向型処理部とを有することを特徴とするソフトウェア。
- 請求項２３に記載のソフトウェアにおいて、上記コア構造が、中間の整合メモリ・バッファを割り振り、共有し、配置するように作動可能な処理用モジュールから構成され、さらに、該モジュール間でイベントを渡すようにすることを特徴とするソフトウェア。
- 請求項２１に記載のソフトウェアにおいて、上記コア機能が、１以上の以下のステップ、すなわち、メモリ割付け、リアルタイム資源割当て及び同時性管理を含む資源割当てとスケジュリングを含むことを特徴とするソフトウェア。
- 請求項２１に記載のソフトウェアにおいて、ＰＣ用デバッグ・ツールにアクセスするように作動可能であることを特徴とするソフトウェア。
- 請求項２１に記載のソフトウェアにおいて、上記コンポーネントのパフォーマンスを用いる上記ソフトウェアの動作及び／又は上記コンポーネントのパフォーマンスの別様のモデル化を可能にするために必要な当該情報だけが、上記コンポーネント内の知的財産の所有者により供給されるように成されるコンポーネントを用いて機能することが可能であることを特徴とするソフトウェア。
- 請求項２１に記載のソフトウェアにおいて、シミュレータ、エミュレータあるいはモデリング用ツールが、通信コンポーネントを用いてシステムの上記資源要件を正確に推定することを可能にする当該通信コンポーネントの（インターフェースの振舞い及び非インターフェースの振舞いを含む）特性に関する標準化された記述を用いて作動可能であることを特徴とするソフトウェア。
- 請求項２１に記載のソフトウェアにおいて、時間、ＣＰＵ、メモリ、相互接続スケジュリング及び同時性制限をモデル化するように作動可能で、リアルタイムＯＳ、非リアルタイムＯＳ、バーチャル・マシンあるいはハードウェア上へのマッピングを可能にすることを特徴とするソフトウェア。
- ソフトウェアまたはハードウェアであって、低ＭＩＰＳ制御機能を与え、バーチャル・マシン層により与えられるＡＰＩを使用するのに適合するソフトウェアまたはハードウェアにおいて、上記バーチャル・マシン層が（ｉ）通信用ＤＳＰとして最適化され、（ｉｉ）上記請求項１乃至２９のいずれかに記載のソフトウェアの一部を形成することを特徴とするソフトウェアまたはハードウェア。
- ソフトウェアまたはハードウェアであって、バーチャル・マシン層のための高ＭＩＰＳプロセスを行うのに適合するソフトウェアまたはハードウェアにおいて、上記バーチャル・マシン層が（ｉ）通信用ＤＳＰとして最適化され、（ｉｉ）上記請求項１乃至２９のいずれかに記載のソフトウェアの一部を形成することを特徴とするソフトウェアまたはハードウェア。
- バーチャル・マシン層を有するチップ上のシステムにおいて、上記バーチャル・マシン層が（ｉ）通信用ＤＳＰとして最適化され、（ｉｉ）上記請求項１乃至２９のいずれかに記載のソフトウェアの一部を形成することを特徴とするシステム。
- バーチャル・マシン層を有するＤＳＰプロセッサにおいて、上記バーチャル・マシン層が（ｉ）通信用ＤＳＰとして最適化され、（ｉｉ）上記請求項１乃至２９のいずれかに記載のソフトウェアの一部を形成することを特徴とするＤＳＰプロセッサ。
- 請求項１乃至２９に確定されるようなソフトウェアを含むことを特徴とする通信用デバイス。
- 上記請求項１乃至２９のいずれかに確定されるようなソフトェアを介してＤＳＰと交信する通信用デバイスのためのオペレーティング・システム。
- 上記請求項１乃至２９のいずれかに確定されるようなソフトウェアにより、ＤＳＰ機能の若干あるいはすべてが処理されることを特徴とする信号処理用アプリケーション。
- 上記請求項１乃至２９のいずれかに確定されるようなソフトウェアと関連して機能するのに適合するベースバンド・スタック。
- 現実のまたはシミュレーションされるコンポーネントが、データ自体による、パイプラインの管理の決定を可能にするような、いくつかの標準的接続タイプ及び同期方法を用いてパイプラインで一体的にリンクされているベースバンド・スタック。
- 請求項３８に記載のベースバンド・スタックにおいて、上記パイプラインが、上記請求項１乃至２９のいずれかに確定されるようなソフトウェアを含むことを特徴とするベースバンド・スタック。
- 上記請求項３８に記載のベースバンド・スタックにおいて、請求項１乃至２９のいずれかに記載されているようなソフトウェアの最低限の実現構成を含むことを特徴とするベースバンド・スタック。
- ベースバンド・スタックをシミュレートするための設計用ツールにおいて、上記パイプラインによって処理されるデータによる、パイプラインの管理の決定を可能にする、いくつかの標準的接続タイプ及び同期方法を用いて、ソフトウェア・コンポーネント及びハードウェア・コンポーネントと一体的にリンクすることが可能であることを特徴とする設計用ツール。
- 請求項４１に記載の設計用ツールにおいて、上記スタックが、請求項１乃至２９のいずれかに記載のようなソフトウェアを有することを特徴とする設計用ツール。
- 請求項１乃至２９のいずれかに確定されるソフトウェアを用いてプログラムされた搬送媒体。
- 請求項１乃至２９のいずれかに記載のソフトウェアのステップが行われることを特徴とする通信用デバイスの一部またはすべての設計方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GBGB0001577.6A GB0001577D0 (en) | 2000-01-24 | 2000-01-24 | Software for designing modelling or performing digital signal processing |
| PCT/GB2001/000273 WO2001053932A2 (en) | 2000-01-24 | 2001-01-24 | Software for designing, modelling or performing digital signal processing |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004500650A true JP2004500650A (ja) | 2004-01-08 |
Family
ID=9884226
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001554160A Withdrawn JP2004500650A (ja) | 2000-01-24 | 2001-01-24 | デジタル信号処理の設計、モデル化あるいは実行を行うためのソフトウェア |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US20030014611A1 (ja) |
| EP (1) | EP1259878A2 (ja) |
| JP (1) | JP2004500650A (ja) |
| GB (3) | GB0001577D0 (ja) |
| WO (1) | WO2001053932A2 (ja) |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8010703B2 (en) * | 2000-03-30 | 2011-08-30 | Prashtama Wireless Llc | Data conversion services and associated distributed processing system |
| US6691050B2 (en) * | 2001-03-14 | 2004-02-10 | Agilent Technologies, Inc. | Data acquisition instrument architecture with flexible data acquisition, processing and display |
| US20030023660A1 (en) * | 2001-06-01 | 2003-01-30 | Bogdan Kosanovic | Real-time embedded resource management system |
| JP2003330732A (ja) * | 2002-05-17 | 2003-11-21 | Canon Inc | 画像形成装置、制御方法、制御プログラム |
| AU2003242831A1 (en) * | 2002-05-27 | 2003-12-12 | Radioscape Limited | Method of testing components designed to perform real-time, high resource functions |
| US20040139411A1 (en) * | 2003-01-13 | 2004-07-15 | Smith Winthrop W. | Heterogenous design process and apparatus for systems employing static design components and programmable gate array sub-array areas |
| US8521708B2 (en) * | 2003-01-22 | 2013-08-27 | Siemens Industry, Inc. | System and method for developing and processing building system control solutions |
| US8639487B1 (en) * | 2003-03-25 | 2014-01-28 | Cadence Design Systems, Inc. | Method for multiple processor system-on-a-chip hardware and software cogeneration |
| US7474638B2 (en) * | 2003-12-15 | 2009-01-06 | Agilent Technologies, Inc. | Method and system for distributed baseband measurements |
| EP1596533B1 (de) * | 2004-05-11 | 2007-10-10 | Tektronix International Sales GmbH | Protokolltester zur Durchführung und Verfahren zur Implementierung einer Testaufgabe |
| US7158814B2 (en) | 2004-06-10 | 2007-01-02 | Interdigital Technology Corporation | Method and system for utilizing smart antennas establishing a backhaul network |
| GB2420908B (en) | 2004-12-03 | 2008-01-23 | Toshiba Res Europ Ltd | Photon source |
| GB2440850B (en) * | 2004-12-03 | 2008-08-20 | Toshiba Res Europ Ltd | Method of operating a photon source |
| US20060236303A1 (en) * | 2005-03-29 | 2006-10-19 | Wilson Thomas G Jr | Dynamically adjustable simulator, such as an electric circuit simulator |
| DE102005025933B3 (de) * | 2005-06-06 | 2006-07-13 | Centrotherm Photovoltaics Gmbh + Co. Kg | Dotiergermisch für die Dotierung von Halbleitern |
| US20070025394A1 (en) * | 2005-08-01 | 2007-02-01 | Interdigital Technology Corporation | Layer one control architecture |
| JP2007286671A (ja) * | 2006-04-12 | 2007-11-01 | Fujitsu Ltd | ソフトウェア／ハードウェア分割プログラム、および分割方法。 |
| US8255890B2 (en) * | 2007-02-14 | 2012-08-28 | The Mathworks, Inc. | Media for performing parallel processing of distributed arrays |
| US7975001B1 (en) * | 2007-02-14 | 2011-07-05 | The Mathworks, Inc. | Bi-directional communication in a parallel processing environment |
| US8255889B2 (en) * | 2007-02-14 | 2012-08-28 | The Mathworks, Inc. | Method of using parallel processing constructs and dynamically allocating program portions |
| US8239844B2 (en) * | 2007-02-14 | 2012-08-07 | The Mathworks, Inc. | Method of using parallel processing constructs and dynamically allocating program portions |
| US8250550B2 (en) * | 2007-02-14 | 2012-08-21 | The Mathworks, Inc. | Parallel processing of distributed arrays and optimum data distribution |
| US8239845B2 (en) * | 2007-02-14 | 2012-08-07 | The Mathworks, Inc. | Media for using parallel processing constructs |
| US8010954B2 (en) | 2007-02-14 | 2011-08-30 | The Mathworks, Inc. | Parallel programming interface to dynamically allocate program portions |
| US8239846B2 (en) * | 2007-02-14 | 2012-08-07 | The Mathworks, Inc. | Device for performing parallel processing of distributed arrays |
| DE102010039519A1 (de) * | 2010-08-19 | 2012-02-23 | Siemens Aktiengesellschaft | System mit einem Produktivsystem und einem Prototypsystem, sowie ein Verfahren hierzu |
| CN102750143B (zh) * | 2012-05-31 | 2015-09-16 | 武汉邮电科学研究院 | 基于matlab com组件调用的dsp开发方法 |
| US10783316B2 (en) | 2018-02-26 | 2020-09-22 | Servicenow, Inc. | Bundled scripts for web content delivery |
| US10824948B2 (en) * | 2018-09-17 | 2020-11-03 | Servicenow, Inc. | Decision tables and flow engine for building automated flows within a cloud based development platform |
| US11502715B2 (en) | 2020-04-29 | 2022-11-15 | Eagle Technology, Llc | Radio frequency (RF) system including programmable processing circuit performing block coding computations and related methods |
| US11411593B2 (en) | 2020-04-29 | 2022-08-09 | Eagle Technology, Llc | Radio frequency (RF) system including programmable processing circuit performing butterfly computations and related methods |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5257369A (en) * | 1990-10-22 | 1993-10-26 | Skeen Marion D | Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes |
| US5497498A (en) * | 1992-11-05 | 1996-03-05 | Giga Operations Corporation | Video processing module using a second programmable logic device which reconfigures a first programmable logic device for data transformation |
| US5432804A (en) * | 1993-11-16 | 1995-07-11 | At&T Corp. | Digital processor and viterbi decoder having shared memory |
| ATE257611T1 (de) * | 1995-10-23 | 2004-01-15 | Imec Inter Uni Micro Electr | Entwurfssystem und -verfahren zum kombinierten entwurf von hardware und software |
| EP0867820A3 (en) * | 1997-03-14 | 2000-08-16 | Interuniversitair Micro-Elektronica Centrum Vzw | A design environment and a method for generating an implementable description of a digital system |
| US5909559A (en) * | 1997-04-04 | 1999-06-01 | Texas Instruments Incorporated | Bus bridge device including data bus of first width for a first processor, memory controller, arbiter circuit and second processor having a different second data width |
-
2000
- 2000-01-24 GB GBGB0001577.6A patent/GB0001577D0/en not_active Ceased
- 2000-12-15 GB GBGB0030698.5A patent/GB0030698D0/en not_active Ceased
-
2001
- 2001-01-24 US US10/182,222 patent/US20030014611A1/en not_active Abandoned
- 2001-01-24 EP EP01942734A patent/EP1259878A2/en not_active Withdrawn
- 2001-01-24 GB GB0101827A patent/GB2367390B/en not_active Expired - Fee Related
- 2001-01-24 JP JP2001554160A patent/JP2004500650A/ja not_active Withdrawn
- 2001-01-24 WO PCT/GB2001/000273 patent/WO2001053932A2/en not_active Application Discontinuation
Also Published As
| Publication number | Publication date |
|---|---|
| WO2001053932A2 (en) | 2001-07-26 |
| EP1259878A2 (en) | 2002-11-27 |
| GB0030698D0 (en) | 2001-01-31 |
| WO2001053932A3 (en) | 2002-09-12 |
| US20030014611A1 (en) | 2003-01-16 |
| GB2367390A (en) | 2002-04-03 |
| GB0001577D0 (en) | 2000-03-15 |
| GB0101827D0 (en) | 2001-03-07 |
| GB2367390B (en) | 2003-06-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004500650A (ja) | デジタル信号処理の設計、モデル化あるいは実行を行うためのソフトウェア | |
| JP2004500652A (ja) | 通信用ベースバンド・スタックの設計、モデル化または組立て方法 | |
| JP2003520551A (ja) | デジタル無線基地局 | |
| Mitola | Software radio architecture: a mathematical perspective | |
| Panesar et al. | Deterministic parallel processing | |
| US20050223191A1 (en) | Device comprising a communications stack with a scheduler | |
| Oshana | DSP for Embedded and Real-time Systems | |
| US20060058976A1 (en) | Method of testing components designed to perform real-time, high resource functions | |
| Castrillon et al. | Component-based waveform development: The nucleus tool flow for efficient and portable software defined radio | |
| Gerstlauer | Host-compiled simulation of multi-core platforms | |
| US20110066416A1 (en) | Method and system for simulation and verification of communication devices | |
| Schirner et al. | Result-oriented modeling—A novel technique for fast and accurate TLM | |
| Fayez | Designing a software defined radio to run on a heterogeneous processor | |
| Chandraiah et al. | Specification and design of a MP3 audio decoder | |
| GB2382702A (en) | Software for designing,modelling or performing digitalsignal processing | |
| Zitouni et al. | Hardware-Software Codesign for Software Defined Radio: IEEE 802.11 p receiver case study | |
| Panesar et al. | Multi-Core System-on-Chip in Real World Products | |
| Sirpatil | Software Synthesis of SystemC Models | |
| Latif | Continuous Integration for Fast SoC Algorithm Development | |
| Musasa Mutombo | Evaluation of embedded processors for next generation asic: Evaluation of open source Risc-V processors and tools ability to perform packet processing operations compared to Arm Cortex M7 processors | |
| Forsberg et al. | Customized Processor Design for 5G Data Link Layer Processing | |
| Evans | Real-Time Digital Signal Processing Laboratory | |
| Vasconcellos | Parallel signal-processing for everyone | |
| ZafarUllahh et al. | A Theoretical Evaluation of Commercially Available Tool Chain for Rapid Prototyping of Wireless Communication Systems | |
| Kärnhall | Decoding Ogg Vorbis Audio with The C6416 DSP, using a custom made MDCT core on FPGA |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20080401 |