JP2012164316A - ハードウェアストリームプロセッサデザインを生成するための方法、装置およびソフトウェアコード - Google Patents

ハードウェアストリームプロセッサデザインを生成するための方法、装置およびソフトウェアコード Download PDF

Info

Publication number
JP2012164316A
JP2012164316A JP2012024079A JP2012024079A JP2012164316A JP 2012164316 A JP2012164316 A JP 2012164316A JP 2012024079 A JP2012024079 A JP 2012024079A JP 2012024079 A JP2012024079 A JP 2012024079A JP 2012164316 A JP2012164316 A JP 2012164316A
Authority
JP
Japan
Prior art keywords
design
processes
data
optimization
input
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2012024079A
Other languages
English (en)
Inventor
Gwilym Dimond Robert
グウィリム ディモンド ロバート
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Maxeler Technologies Ltd
Original Assignee
Maxeler Technologies Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Maxeler Technologies Ltd filed Critical Maxeler Technologies Ltd
Publication of JP2012164316A publication Critical patent/JP2012164316A/ja
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/30Circuit design
    • G06F30/34Circuit design for reconfigurable circuits, e.g. field programmable gate arrays [FPGA] or programmable logic devices [PLD]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751Error or fault detection not based on redundancy
    • G06F11/0754Error or fault detection not based on redundancy by exceeding limits
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10TTECHNICAL SUBJECTS COVERED BY FORMER US CLASSIFICATION
    • Y10T29/00Metal working
    • Y10T29/49Method of mechanical manufacture
    • Y10T29/49002Electrical device making

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Logic Circuits (AREA)
  • Design And Manufacture Of Integrated Circuits (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【課題】ハードウエア条件を最小にしながら、複数の異なるプロセスの間でのデータ転送をストリーミングするためのハードウエアを最適にすること
【解決手段】本発明は、複数のプロセスと、これら複数のプロセスの間でデータパスを提供するための、前記プロセス間の相互接続とを備えたハードウェアストリームプロセッサデザインを自動的に生成するための方法を提供するものであり、この方法は、前記ストリームプロセッサによって実行すべきプロセスを指定する入力を提供するステップと、前記入力デザイン内のプロセス間の前記相互接続に関連したパラメータを自動的に最適化し、必要な機能を提供しながらハードウェア条件を最小にするステップと、前記最適化に従って最適化された出力デザインを生成するステップとを含む。
【選択図】図8

Description

本発明は、ハードウェアストリームプロセッサデザインを生成するための方法および装置に関する。実施形態では、本発明は相互接続されたプロセス間のデータ転送をストリーミングするためのハードウェア実現例を最適化する方法も含む。
実施形態では、本発明は、単一方向のFIFO(先入れ先出し)データストリームを使用するハードウェアプロセス通信を使ってコンピューティングすることに関する。各ハードウェアプロセスは、データをシンク化/ソース化するゼロまたはそれ以上の数の入出力ポートを有する。あるプロセスの入力ポートと別のプロセス(このプロセスは同じプロセスでよい)の出力ポートとの間でFIFOデータストリームが接続される。オプションとして、FIFOストリームをI/Oデバイス(入出力デバイス)、例えば、ソフトウェアまたはメモリデバイスとの相互対話のためのプロセッサバスに接続してもよい。
一般に、フィールドプログラマブルゲートアレイ(FPGA)によって提供できるようなハードウェアプロセスは、非同期及びパラレルに作動し、プロセス入力からデータアイテムを読み出し、プロセス出力でデータを生成する。このFPGAは、一般に、ホストコンピュータと共に使用するためのアクセレレータの一部を形成でき、このアクセレレータでは、FPGAは、製造後、顧客または設計者によりコンフィギュアされ、その指定されたタスクおよびプロセスを実行するようになっている。
例えば、FPGAでプロセスを伝送する同様なネットワークは、文献ではカーンプロセスネットワーク(KPN)として知られており、このKPNは宛て先のないFIFOチャンネルを通して確定的なシーケンシャルプロセスのグループが通信を行う計算の分散モデルを提供している。高性能の計算をするために、ハードウェア、例えばFPGAまたはその他のプログラマブル論理デバイス内でプロセスネットワークを実現するための方法および装置が必要である。
FPGAは、一般にルックアップテーブル(LUT)およびフリップフロップ(これらの双方は、演算計算に使用される)と、バッファリングに使用されるブロックランダムアクセスメモリ(BRAM)とを含む、限られたリソースを有することが知られている。FPGAは、リコンフィギュア可能な相互接続も提供し、これら相互接続は限られたリソースを互いに接続できるようにし、データ通過中に全体に所望する機能またはプロセスを提供する。所定のプロセスまたはプロセスのネットワーク内でプロセス間のFIFOストリームを実施するための相互接続のためのハードウェア要件を最小化するか、またはリソース利用効率を最適にすることにより、大きな利点を得ることができる。最適化の利点は、計算のためにより多くのリソースを利用できることであり、このことによって性能をより高くすることができる。FPGAのコンフィギュレーションは、ハードウェア記述言語(HDL)を使って一般に指定され、ASICが実行できる任意の論理機能を実施するために、デバイスを使用できることが判っている。
一般的にFPGA内のプロセスは、複雑な演算、例えば多次元のたたみ込みを計算するパイプライン状のハードウェアデータパスとなっていることが多い。これらプロセスを本願では「カーネル」と称す。換言すれば、カーネルとは、特定のクロックレートでアプリケーション固有のパターンに従ってデータを生成/消費する、同期式のパイプライン状データパスのことである。例えば、たたみ込みカーネルは、100MHzで作動でき、2×32ビットの入力データポイントを消費し、サイクル(10ns)ごとに1×32ビットの出力データポイントを生成する。
データパスまたは計算に加え(またはその代わりに)、カーネルは、データフローの基本的制御も行うことができる。2つの共通する例として、マルチプレックスカーネルとデマルチプレックスカーネル(それぞれMuxおよびDemuxと表示)とがある。Muxは多数の入力ポートと単一の出力ポートとを有し、実行時間を選択できる単一の入力ポートを出力ポートに接続する。Demuxは、単一の入力ポートと多数の出力ポートとを有し、実行時間を選択できる単一の出力ポートを入力ポートに接続する。
図1は、「カーネルA」および「カーネルB」と表示される2つのカーネル4および6を含むネットワーク2の略図を示す。カーネル4は、2つの入力ポートPおよびQと、2つの出力ポートXおよびYとを有する。FIFOバッファ8は、カーネルAの出力ポートXおよびYの各々からデータを受信し、データを宛て先値にフォワードルーティングする前に記憶するようになっている。この場合、ポートXから出力されたデータは、カーネルB 6の入力ポートRへルーティングされ、カーネルAのポートYから出力されたデータはカーネルAの入力ポートQへルーティングバックされる。図示されている例では、出力ポートXおよびYは、最も一般的な意味ではカーネルA 4からネットワークを通して転送されるデータのソースであるので、データソースと見なされる。(カーネルA 4の)入力ポートQおよび(カーネルB 6の)Rは、最も一般的な意味において、それぞれソースXおよびYから受信されるデータに対するシンクであるので、データシンクと見なされる。
後述されるように、かかるネットワーク内のカーネルの各々に関連する変数は、多数存在することが理解できよう。例えばポートまたはFIFOバッファにおける記憶容量が不十分なことに起因し、カーネルの間でデータが失われないこと、または過度に長く待機し、不要な遅延が生じることによる、データの喪失がないことを保証するような、フロー制御の何らかの手段が必要である。これを達成するために、FPGAまたは他のプログラマブルロジックのようなハードウェアでは、データストリームは、一般にデータ自体とネットワーク上のノード間、すなわちポート間でのデータの転送を仲裁する目的のための、フロー制御信号との双方を一般に含む。一般に使用される周知のフロー制御スキームとして次の3つがある。
1.EMPTY/READ
2.VALID/STALL;および
3.SOURCE READY/SINK READY
EMPTY/READフロー制御スキームでは、2つのフロー制御信号EMPTYおよびREADが使用される。データソースが読み出しに利用できるデータを有するとき、データソースから出力されたEMPTY信号は、デアサートされる。次に、接続されたデータシンクは、データのアイテムを転送するためにREAD信号をアサートする。
VALID/STALLフロー制御スキームでは、再び2つのフロー制御信号(このときはVALIDおよびSTALL)が使用される。データシンクがデータを受信するREADY状態になったことを表示するために、データシンクによってSTALL信号出力がデアサートされる。次に、データソースは、データをシンクに転送するために、VALIDをアサートする。
最後に、SOURCE READY/SINK READYフロー制御方式は、フロー制御信号SOURCE READY/SINK READYを使用する。SOURCE READYおよびSINK READYの双方がアサートされる任意のサイクルにおいて、ソースからシンクへデータが転送される。
従来はハードウェア設計者は、一般にハードウェアデザイン内で使用するための特定のフロー制御スキームを選択し、デザイン内で使用されるすべてのカーネルをそのスキームに対してデザインまたは適合させていた。一部のケースでは、これによって最適化が欠如することになった。その理由は、1つのカーネルが実行するプロセスのタイプによっては、一方または他方のフロー制御方式のほうが良好に作動し得るからである。
相互接続されたプロセスによるシステムのデザインにおいて、設計者はシステム内のデータのフローをダイナミックに管理するために、フロー制御の機構に関して標準化を行うことが一般的である。フロー制御は、接続されたソースとシンクプロセスの双方がデータを転送するのにレディー状態となった場合にしかデータが転送されないことを保証するものである。フロー制御がない場合、シンクがレディー状態でないときにデータが送られる(オーバーフロー)ことに起因してデータが失われたり、ソースがレディー状態でないときにデータが受信される(アンダーフロー)ことに起因してデータにエラーが生じたりする。
単一フロー制御機構を標準化する上での問題として、異なるプロセスに対してフロー制御の機構のタイプが異なると、実行の効率が高くなったり低くなったりすること、および最適なデザインが、異なるタイプのフロー制御を多数含み得ることが挙げられる。例えば計算パイプラインは当然、入力にはPULLタイプのインターフェースを有し、出力にはPUSHタイプのインターフェースを有することになる。このことは、入力バッファが空であるか、リクエスト時にデータを転送しないか、出力バッファがフルでないかを見ること、およびリクエスト時にバッファ内にデータをプッシュすることを容易に可能にするためである。バッファ化またはロジックを使って異なるフロー制御タイプの間の変換をすることが常に可能であるが、この結果、ハードウェアにコストがかかることになる。かかる目的のために使用されるハードウェアを、FPGAの主な処理機能には使用することはできない。
図2は、入力データおよび出力データのために簡単な外部フロー制御方式を使用する計算パイプライン10の略図である。このフロー制御方式は、1ビットのVALID信号とSTALL信号とから成る。パイプライン10を通過するようにデータ12が流れ、パイプライン10内の計算ロジック14のロジックに従ってデータ12が処理される。
パイプライン制御ロジックは、内部でデータアイテムを利用できるかをチェックし、次に読み出し信号16を使ってデータの転送を制御しなければならない。入力データインターフェース20と出力データインターフェース22の双方で同じフロー制御方式を維持するために、バッファ18が挿入されている。換言すれば、バッファ18を挿入することにより、全体にパイプライン10に進入したり離間したりするデータのために使用されるフロー制御方式は、すべてVALID/STALL信号でセットできる。しかしながら、計算パイプラインのために使用されるデータソース(例えばFIFOまたはSRAMインターフェース)が計算パイプライン10のREAD/EMPTYのセマンティクスをネイティブにサポートしている場合、バッファ18は無駄とある。
クロック周波数およびスループットを最大にするための制御ロジックのパイプライン化により、バッファリング/ロジックを挿入する必要性も生じる。信号のレイテンシーを高めることによって、信号(STALL)を生成するロジックと信号を解読するロジックとの間にパイプラインレジスタを挿入することが可能となる。周知のように、かかるパイプラインレジスタは、単一クロック時間内でのロジック/ルーティング遅延時間を短縮することにより、デザインの有効最大クロックレートを高める。例えば図2内の計算パイプラインは、出力でアサートされるSTALL信号24と、デアサートされるVALID信号26との間に、あるレイテンシーを有することができる。フロー制御がVALID信号の迅速なデアサートを必要とする場合、別の(可能な場合には冗長な)バッファ(図示せず)を挿入しなければならない。
フロー制御をマニュアルで最適化すること、すなわちデザイン時のどのポイントにおいても異なるスキームを選択することには、時間がかかり、エラーが生じやすく、ロジックブロックを効率的に再使用することが阻害される。各ブロックを使用し、別個のバージョンを維持するような各状況およびどの状況においても、各ブロックを最適にしなければならない。
FPGAのためのロジックのデザインにおいて生じる別の問題は、異なるクロックレートで、および/または異なるデータ幅で、異なるカーネルを作動できることに関連している。デザイン内の多数のカーネルは、異なるクロックレートで作動し得る。これを解決するために、クロックドメインの間に、明瞭にデータを変化させるためのロジックを挿入し、よってデータにエラーが生じることを防止できる。異なるアスペクト(ビット/幅)を有するカーネル入力/出力ポートを接続できる。この問題を解決するために、データをバッファ化/シフトし、サイクルごとに異なる下図のビットを生成/受け入れるポート間で、遷移を管理するためのロジックを挿入できる。
図3は、2つのカーネル30 Aと、カーネル32 Bとを含むネットワーク28の略図を示す。これら2つのカーネル30および32は、自らの独立したクロック34および36でそれぞれ作動している。クロックA 32で作動中のカーネルA 30およびクロックB 36で作動中のカーネルB 32からのデータ転送が必要とされる。これを達成するために、クロスクロックの移行を可能にするクロスクロックロジック38が設けられている。デジタルロジック回路内の異なるクロックドメイン間でデータを転送するのにクロスクロックロジックが必要である。クロスクロックロジックの非限定的例として、別個の読み出しクロックおよび書き込みクロックを有するFIFOバッファがあり、このバッファではクロスドメインにわたってFIFOステートを同期化するのにグレイコード化カウンターが使用される。
異なるカーネル内で異なるデータ幅が使用される場合、コンパチビリティおよび接続性の同じ問題が生じる。所定のブロックまたはカーネル、例えばルーティングのためのmux/demux、I/Oデバイスに対するポート、例えばホストまたはメモリを、特定のクロックまたはビット幅に固定しなくてもよい。muxは32ビット幅の2つの入力を有し、64ビットの幅の2つの入力を有することができる。同じように、クロックドメインA内に2つの入力が存在し、クロックドメインBに2つの入力が存在してもよい。リソースの使用量を最小にするためには、mux自体に対する最適なビット幅およびクロック周波数をピックアップし、クロックドメイン間の移行を最小にし、図4に略図で示されるような異なる幅の間のパッキング/アンパッキングを最小にすることが望ましい。クロックドメインおよびビット幅を選択することは、最適化する上での問題である。
図4の例では、簡単な2−カーネルプロセスネットワークが示されている。このネットワークは、カーネルA 40と、カーネルB 42とを備える。カーネルA 40は、出力ポートX44上でサイクルごとに4×8ビットのアイテム43を生成するようになっており、カーネルB 42は、入力ポートQ46上でサイクルごとに1×8ビットのアイテム45を受信するようになっている。カーネルAの生成からカーネルBへのデータ転送が必要であり、従って、データ幅を変換するためのある手段が必要である。この特徴を達成するために、ポートX44とポートQ46の間に変更ロジック48が設けられている。
FPGAのためのロジックをデザインする際に生じる別の問題は、データフローに対して特別の規定を設けない場合、デッドロックを生じさせるような所定のデータフローが生じやすくなるということである。一部のカーネルは、特定の対策をしない場合にデッドロックを生じさせるようなデータフローのパターンを取り扱うために、入力/出力上でバッファリングを必要とし得る。図5の例では、Rからの呼び出しを行うカーネルBのパターンと共に、出力XおよびYに書き込みを行うカーネルAのパターンは、バッファリングを挿入しなければならないことを意味する。カーネルAが作動しているときには、まずこのカーネルはXにデータを書き込むが、カーネルBは、カーネルAのXおよびYの双方にデータを有するまで作動できない。従って、Y(このポイントでカーネルBは読み出しを開始できる)でデータが利用可能となるまで、X上にデータを記憶するためにバッファリングが必要である。
従来は、設計者は全デザインの知識をもってマニュアルでバッファリングを挿入していた。しかしながら、このアプローチを行うには、デザイン内のすべてのカーネルの知識およびカーネルがどのように振る舞うかの知識が必要となるのでエラーが生じやすく、複雑である。
別の方法は、ネットワーク内の各カーネルおよびどのカーネルの入力/出力にも、単にバッファを挿入する方法である。しかしながらこの方法は、リソースが無駄となる。その理由は、接続されている他のカーネルで既にバッファリソースを利用できるか、または相互接続ではバッファリングは固有のものとなり得るからである。例えば異なるクロックの間でデータをクロスさせるのにFIFOバッファが使用されることが多く、理論的にはデッドロックを防止するのに同じバッファリングを使用できる。
FPGAのためのロジックのデザインで生じる別の問題は、カーネル間のデータフローを管理するのに使用されるフロー制御信号が上記のようにレイテンシー(このレイテンシー後にフロー制御信号が有効となる)を有し得るという事実に関係する。一般的なケースでは、単一カーネルに対し、これらレイテンシーは、相互に依存している。フロー制御のレイテンシーが相互に依存していることは、入力/出力ポートの一組のための特定のフロー制御信号(例えばstall(ストール))のレイテンシーが、レイテンシー=f(N、K)の関係(ここでKは特定の入力/出力に固有の定数であり、Nはポートの組内のすべての入力/出力ポートに当てはまる変数であり、f()は数学的関数である)を有することを意味する。一般的なケースでは、f()は、加算関数であり、入力ポートは、N+0のレイテンシーを有し、出力ポートは、N+1のレイテンシーを有する。
図6は、2つの入力ストリームまたはソース(AまたはB(図示せず))からデータを選択するmuxカーネルの簡単な一例を示す。2つの入力チャンネルAおよびB(およびmuxからの出力)に対応する使用されるフロー制御およびデータ信号の3つのセット66、68および70が存在する。更に、muxからデータを取り出すのにストリームAからなのか、またはストリームBからなのかを識別するために、選択信号62が使用される。入力ストリームおよび出力信号の各々に対し、STALL信号、VALID信号およびDATA信号が使用される。信号66、68および70の組の各々に対し、データを受信するレディー状態となったことを表示するために、関連するデータシンクにより、STALL信号出力がデアサートされるように、STALL/VALIDフロー制御が使用される。次に、関連するデータシンクにデータを転送するように、データソースがVALIDをアサートする。第2muxコンポーネント54からデータ出力信号60が取り出され、このコンポーネントからシンク64へ提供される。
信号stall_outとvalid_outとの間のレイテンシーの追加サイクルが生じるようにmux50がパイプライン化される。このmux50は実際には2つのmuxコンポーネント52および54から構成されている。第1muxコンポーネント52は、フロー制御を行うように作動し、第2muxコンポーネント54はデータ自体を多重化するように働く。2つのデータチャンネルまたはソース56および58は、入力としてデータを第2muxコンポーネント54へ提供するようになっている。選択信号62による適当な制御により、単一データ出力信号64がデバイスから出力されるデータとして提供される。正しい作動を保証するためにデバイス内のフロー制御が使用されるが、種々の制御信号およびデバイスのレイテンシーの間の差に起因し、複数の問題が生じ得る。
この簡単な例では、stall_outのアサートとvalid_outのデアサートとの間のレイテンシーは、stallAのアサートからvalidAのデアサートまでのレイテンシーに1サイクルを加えた値に等しい。このレイテンシーを説明するために、連続する多数のサイクルの間にvalid_Aをアサートすることにより、ソースAがシンクに対し、データを連続的に転送しているケースを検討する。選択信号は、「A」にセットされるので、valid_outは1サイクルだけ遅延されたvalid_Aに等しいので、連続する多数のサイクル中でもアサートされる。次にシンクは、(例えば残留バッファスペースがないことに起因し)データを最早受け入れできないと判断し、stall_outをアサートする。stallAにstall_outが接続されるので、Nサイクル(ここでNはAのstallレイテンシーである)後にソースAはvalid_Aをデアサートする。valid_outは、1サイクルだけ遅延されたvalid_Aであるので、シンクはstall_outをアサートした後のN+1サイクルの間、valid_outをデアサートしたものと見なす。
これまでは、muxの入力側と出力側の双方におけるインターフェースを固定できたので、stall(ストール)とvalid(有効)との間のレイテンシーを解決できた。例えば入力レイテンシーを1にセットでき、出力レイテンシーを2にセットでき、N+1の規則に適合する任意の数字をセットできた。muxの後にバッファリングを挿入し、その固定されたレイテンシーを維持する。かかる従来の解決方法による問題は、多数のカーネルが相互に接続されている場合、このようなバッファリングがハードウェアを無駄にすることである。
高度なマニュアルデザインを使用することにより、バッファリングの総量を最小化するようにレイテンシーをスケジュール化することが可能である。しかしながらこのようなタイプの高度なマニュアルデザインは、時間がかかりエラーを生じやすい。図7は、3つのカスケード接続されたmuxカーネルを有するデザインの簡単な一例を示す。この例では、バッファリングを最小にするようにレイテンシーがスケジュール化される。左側のデザインは、インターフェースごとに1つの固定されたレイテンシー(L=1)を有するので、ステージごとにレイテンシーを1に変換するためのバッファが必要である。換言すれば、最初の2つのmux57および59を通過したデータは、muxの入力において、L=1のスタートレイテンシーを有し、mux内のロジック(図6参照)がレイテンシーの追加サイクルを加えるので、L=2の累積レイテンシーを有する。バッファ61は、mux63の前にレイテンシーを1に変換するように働く。チェーンを下る方向にこのようなことが繰り返される。
右側のデザインは、L=3からL=1に変換するのに、1つのバッファだけでよいようにmuxカーネルのレイテンシーをスケジューリングしている。このようなスケジュールリングによって、バッファ61が不要となるように下流側のmux63がレイテンシーの追加サイクルを累積することを可能にしている。
従って、相互接続されたプロセス間でデータ転送をストリーミングするためのハードウェア実現例を最適化することを含むデータプロセッサの生成およびデザインでは多数の問題が生じることが理解できよう。
米国特許公報第7,315,991号は、ハイレベルのプログラミング言語(HLL)プログラムから回路を創出させる方法について開示している。この方法は、HLLプログラムからネットリストを生成することを含み、ここで、ソフトウェアに基づく回路の表示または回路のハードウェア記述であるネットリストが回路デザインを特定するようになっている。回路デザインは、プログラマブルロジックデバイス内で作動させることができ、実行時間で複数の実行スレッドを識別し、スケジュール情報を決定できる。
クラウディア・ジスレスキュー氏、バート・キーエンヒュイス氏、エド・デプレテール氏による論文「マルチプロセッサ環境における通信合成」(フィールドプログラマブルロジックおよびアプリケーションに関する議事録、2005年、フィンランド、タンペレ、2006年8月24〜26日)は、リコンフィギュラブルなデバイスにマットラブ(Matlab)のサブセットで書かれた入れ子状ループアプリケーションの高速マッピング、例えばデジタル信号処理、イメージングまたはマルチメディアのためのデザイン方法を開示している。この方法は、ポイント対ポイント状にプロセス間の通信が行われるプロセスネットワークを生成する。4つのタイプのポイント対ポイント通信が識別されている。2つのタイプは、FIFO状の通信を使用するものであり、他の2つのタイプは、データを交換するためにキャッシュ状のメモリを使用するものである。ここに開示されている方法はFPGAにおいて自動的かつ効率的に実現できる。
スバン・バン・ハーストレークト氏およびバート・キーエンヒュイス氏による「ハードウェアにおけるプロセスネットワークへのCアプリケーションをストリーミングする自動合成方法」と題する論文(欧州におけるデザイン自動化および試験に関する議事録、2009年)は、ストリーミングアプリケーションの単一のシーケンシャルなC入力仕様からFPGAでのハードウェア実現例の自動生成方法を開示している。ここでは、高レベルの合成ツールが使用されている。
上記3つのすべての論文の全内容を本願で参考例として援用する。
本発明の第1の様相によれば、複数のプロセスと、これら複数のプロセスの間でデータパスを提供するための前記プロセス間の相互接続とを備えたハードウェアストリームプロセッサデザインを自動的に生成するための方法であって、前記ストリームプロセッサによって実行すべきプロセスを指定する入力デザインの受信時に、前記入力デザイン内のプロセス間の前記相互接続に関連したパラメータを自動的に最適化し、必要な機能を提供しながらハードウェア条件を最小にするステップと、前記最適化に従って最適化された出力デザインを生成するステップとを含む、ハードウェアストリームプロセッサデザインを生成する方法が提供される。
この方法は、これまで識別した問題を解決しながら、プログラマブルロジックデバイスのデザインを生成できる方法を提供するものである。特にシステム内のパラメータの自動最適化を考慮することにより、それに対応して最適化されるデザインを自動的に生成できる。プロセスに関連しないリソースの使用を最小にするか、または解消できるようにしながら、同時にオペレータがエラーを冒すリスクを回避できる。
最適化されるパラメータをプログラマブルロジックデバイスに関連する種々のパラメータのうちの1つ以上とすることができる。例えばパラメータは、デザイン内のフロー制御またはストリームプロセッサのデザイン内のデータ幅、またはクロックレートのような他のアスペクトに関連し得る。必要な機能を提供しながら、ハードウェアの条件を最小にするよう、デザイン内のパラメータを自動的に最適にする方法を設けることにより、上記問題のすべてを解決できることが理解できよう。
例えばオペレータがマニュアルで各状況を検討し、どのフロー制御方法を実施するかを決定しなくても、プロセスごとに、各プロセスに対してフロー制御方法を自動最適化によって指定できる。更に、デザイン内のリソースを効率的に利用するように、プロセス間の弧となるクロックレートおよびデータ幅の問題を自動的に解決できる。
実施形態では、パラメータ化は、
インターフェースのタイプ(PUSH対PULL)、
インターフェースの幅、
インターフェースのクロックレート、および
フロー制御信号のレイテンシー(例えばstall(ストール)/empty(空))のうちの1つ以上を決定することを含むことができる。
本願に記載されるように、必要な機能を提供しながら、プロセス間の相互接続のためのハードウェア条件を最小にするように、これらパラメータのうちの1つ以上を自動的に最適化できる方法が提供される。従って、相互接続のためのハードウェア条件を最小にすることにより、プロセス自体のために所定サイズのデバイスのうちのより大きい部分が残るので、同じ量のロジックから高い性能を達成することが可能となる。
一例では、本方法は、デザイン内のプロセス間のフロー制御方法を自動的に決定する手順を含む。
ストリームプロセッサ内では、異なるフロー制御方法を使って、一般に異なるプロセスが作動する。プロセス間のフロー制御手順を自動的に決定することにより、プロセスに関連しない機能専用とすべきプロセッサリソースの量を最小にできるよう、プロセッサ内のリソースの利用を最適にすることが可能となる。
一例では、本方法は、所定のパラメータを使用することにより、プロセッサ間のstall(ストール)レイテンシーのスケジュールを定めるステップを含む。
プロセッサ内のstallレイテンシーのスケジュールを定めるための所定のパラメータを使用することには大きな利点がある。特にプロセッサ内のポートまたはプロセスのレイテンシーを定めるための変数またはパラメータを使用し、次にこのパラメータに対するその後のレイテンシーを定めることにより、システム内のレイテンシーを全体として、またはシステムのうちの接続された部分を容易かつ効率的にモデル化するかまたは割り当てることができる。
一例では、本方法は、前記デザイン内のプロセス間のフロー制御手順が、どれも同じ特定されたタイプである場合に、接続されたプロセスのカスケード内のstallレイテンシーを示すためのパラメータを定めるステップと、記憶条件を最小にするよう、前記パラメータに対する値を決定するステップとを含む。
一例では、前記プロセスの各々が、接続されたプロセスおよび対応するクロックレートの1つ以上の入力ポートに接続された1つ以上の出力ポートを有する例では、本方法は、前記接続されたポートのための前記クロックレートを最適化するステップを含む。
前記プロセスの各々が、接続されたプロセスおよび対応するデータ幅の1つ以上の入力ポートに接続された1つ以上の出力ポートを有する例では、本方法は、接続されたペアのポートに対してデータ幅を自動的に最適化するステップを含む。
前記入力デザインが、非周期的グラフ状となっており、このグラフではプロセスがグラフの頂点であり、プロセス間のデータストリームが前記頂点の間の弧となっている例では、本方法は、前記グラフのサブツリーに対する自動最適化を実行し、好ましくは1回終了すると、グラフ全体が最適化されるまで、前記グラフのその後のサブツリーに対し、自動最適化を実行するステップを含む。
各プロセスの前記データ幅およびクロックレートに対する最適値を決定するために任意の数値方法を利用できる。好ましい方法は、組み合わせ最適化方法を利用する方法である。
このことは、プロセスノード内の値の各コンフィギュレーションに対するコストを決定するステップと、前記プロセスに対する全最小コストを提供する値を前記プロセスに割り当てるステップによって、達成できる。このコストは、特定のコンフィギュレーションを実施できるようにするためのグルーロジックまたはプロセスに関連しないハードウェア専用としなければならないハードウェアリソースの量として定義される。
一例では、本方法は、あるプロセスから別のプロセスに移行するためのコストを決定するステップを備え、全コストは、プロセス内の値のコンフィギュレーションに対するコストに、あるプロセスから別のプロセスに移行するための前記コストを加えた合計である。したがって、目的の、一貫した、効果的で、信頼できる方法は、その最適値が、プロセスのデータ幅及びクロック・レート等のパラメータで確定できる。
一例では、1つのサブツリーに対する全コストが一旦決定されると、本方法は、全グラフが最適化されるまでグラフのうちのその後のサブツリーに対する前記最適化を実行するステップを含む。
従って、性能およびリソースの利用を最適にするように、全プロセスネットワークを自動的にコンフィギュアできるようにする方法が提供される。
一例では、この方法は、最適化が一旦実行されると、デザイン内にアスペクト変換ロジックを自動的に提供するステップを含む。
従って、第1の組の最適化が一旦考慮されると、例えばフロー制御レイテンシーまたはクロックレート、および/またはデータ幅のパラメータ化が考慮されると、デザインにアスペクト変換ロジックを追加できる。従って、このことによって、かかるアスペクト変換ロジックの使用量を最小にできる。その理由は、デザインに対して他の最適化またはコンフィギュレーションが一旦行われると、この変換ロジックしか追加されないからである。
一例では、本方法は、一旦最適化が行われた場合に、デザイン内にアダプタロジックを自動的に設けるステップを含む。
従って、再びアスペクト変換ロジックを使用した場合のように、第1の組の最適化が一旦考慮されると、デザインにアダプタロジックを追加できる。このことも、かかるロジックの使用を最小にできる。その理由は、デザインに対して他の最適化またはコンフィギュレーションがなされた場合には、かかるロジックしか追加されないからである。
一例では、本方法は、最適化が一旦実行されると、前記デザイン内にFIFOを自動的に挿入するステップを含む。
一例では、本方法は、各最適化ステップの後に、クロックレートおよびデータ幅を最適化するステップを含む。
一例では、a)前記ソースクロックレートと前記シンククロックレートとが同一でない条件、および
b)前記ソースフロー制御方法と前記フロー制御方法とが同一でない条件を含む1つ以上の条件が満たされた場合に、任意のペアのプロセスの間だけにFIFOを挿入する。例えば図13に示されるように、他の種々の条件を考慮してもよい。この方法は、追加されるFIFOの量を最小に維持できることを保証する。
本発明の第2の様相によれば、本発明の第1の様相の方法を使用するデザインを生成するステップと、前記生成されたデザインを実施するための前記ロジックデバイスをプログラミングするステップとを含む、プログラム可能なロジックデバイスを作成する方法が提供される。
本発明の第3の様相によれば、コンピュータで実行時に、本発明の第1の様相のステップを実行するようになっているコンピュータプログラムが提供される。
このコンピュータプログラムは、コンピュータで読み取り可能なメディアに記憶することが好ましい。このコンピュータで読み取り可能なメディアは、任意の適当な種類のメディアでよい。例えばこのメディアを、ディスクまたは同等物、もしくは信号のような伝達可能なメディアとすることができる。例えばこのメディアは、インターネットまたは同様なものを通して提供できる任意の伝達可能な種類のものでもよい。
本発明の第4の様相によれば、本発明の第1の様相に係わる方法を使用して生成されるデザインを有するフィールドプログラマブルゲートアレイまたは他のプログラマブルロジックが提供される。
不要なメモリまたはハードウェアの利用が全体に最小とされ、および/または不要となるので、本発明の第1の様相に従って決定されたデザインを有するように形成されたFPGAまたはその他のプログラマブルロジックデバイスは、最適な性能を提供できる。更に、各コンポーネントの最適化をユーザーがマニュアルで検討することによって生成されたデザインが受ける誤りを生じないように、FPGAまたはその他のプログラマブルロジックデバイスが迅速かつ効率的に創出される。
本発明の第5の様相によれば、本発明の第1の様相に係わる方法を実行し、前記生成されたデザインを有するプログラマブルロジックデバイスのプログラミングのための命令のリストを生成するようになっているプロセッサを含む、ハードウェアストリームプロセッサデザインを生成するためのシステムが提供される。
プロセスに関連しないタスクのためのメモリおよびロジック条件が最小とされるか、または解消される、最適にされたFPGAの形成を可能にするよう、ネットリストのような命令の必要なリストをユーザーが生成できるようにするシステムが提供される。
本発明の別の様相によれば、複数の相互接続されたプロセスを含むFPGAプロセッサのためのデザインを生成する方法であって、指定された入力デザインを受信したときに、このデザイン内で前記プロセスの各々の働きを最適化するステップと、この最適化を一旦実行すると、前記最適化されたプロセスの各々の間の前記相互接続を最適化するステップを備える、FPGAプロセッサのためのデザインを生成する方法が提供される。これによって、最小のリソース利用率で性能レベルを維持することが可能となる。
換言すれば、設計者が一般に特定のフロー制御方式を選択し、そのフロー制御方式と共に使用できるようにすべてのカーネルまたはプロセスを適合させるような従来の方式と対照的に、本方法では、各カーネルのための最適なフロー制御方式を選択し、次にカーネル間のクロス最適化を実行する。換言すれば、パラメータ化された方式の「スペース」をサポートし、カーネル間のクロス最適化に先立ち、個々の各カーネルに対して最適なポイントをスペース内から選択する。
本発明の別の様相によれば、プロセスカーネルおよび相互接続部を含む、ストリーミングプロセッサのための最適にされたプログラマブルロジックデザインを自動的に生成するための方法であって、プログラマブルロジックデザインプロセス中にカーネル相互接続部をパラメータ化するステップと、最適にされたプログラマブルロジックデザインを生成するためのパラメータを最適化するステップとを含む方法が提供される。
上記記載にわたり、例を参照すれば、必要な他の任意の特徴と組み合わせて上記特徴の任意の1つ以上を提供できることが理解できよう。
次に、添付図面を参照し、本発明の実施形態について詳細に説明する。
2つのカーネル(AおよびB)を含むハードウェアプロセッサの一部の略図である。 外部フロー制御方式を使用する計算パイプラインの略図である。 クロスクロックロジックを利用する2つのカーネル(AおよびB)の略図である。 異なるデータ幅を有する2つのカーネル(AおよびB)を含むデータフローパスの略図である。 デッドロックを防ぐためにバッファを必要とする2つのカーネル(AおよびB)の略図である。 stall/validフロー制御を使用する2つの入力ストリームのうちの1つからデータを選択するmuxカーネルの略図である。 stall/validフロー制御を使用する2つの入力ストリームのうちの1つからデータを選択するmuxカーネルの略図である。 最適化されたハードウェアデザインを生成する方法を略図で示すフローチャートである。 2つのクロックドメインおよび1つの幅ドメインを有するカーネルの略図である。 muxカーネルのチェーンの略図である。 カーネルのためのクロックおよび幅を最適にする際のステップの略図である 最適化されたバッファ挿入のプロセスを略図で示す。 FIFOバッファの最適化におけるステップの略図である。
本方法および装置がどのように作動するかの一例を詳細に説明する前に、本システムの一般的な特徴について説明する。
正しいフロー制御を保証し、デッドロックを防止するために、パラメータ化されたポートを接続する方法およびストリーミングプロセッサ上のインターフェースポートのパラメータ化が提供されている。このパラメータ化により、所定の条件が満たされるように、カーネル上のFIFOポートまたは入出力デバイスの間のインターフェースを記述するためのシステマティックな方法が提供される。まずシステムは、自動的に生成されたインターフェースロジックにより任意のカーネルポートを他の任意のカーネルポートに接続できるようにすることを保証する。第2に、自動コンパイラーが相互接続を自動的に最適にし、ハードウェアリソースの利用量および/または最大クロック周波数を低下する。換言すれば、(IPライブラリーからの、またはユーザーが設計した)ハードウェアカーネルが、パラメータ化された方法によって記述されたストリーミング入力/出力ポートを有することが可能である。実施形態では、パラメータ化は、
インターフェースのタイプ(PUSH vs PULL)
インターフェースの幅
インターフェースのクロックレート
フロー制御信号(例えばstall/empty)のレイテンシーのうちの1つ以上を決定することを含むことができる。
相互接続をストリーミングするためのクロックドメインおよび特徴の自動最適化も提供される。中間カーネル(特にルーティングmuxおよびdemuxのような簡単なカーネル)のためのクロックドメインおよび特徴(ビット幅)を選択できる。ビット幅およびクロックドメインを適正に選択することにより、クロックドメインの間でデータを移動させ、異なるビット幅の間のデータをパック/アンパックする「グルーロジック」のためのハードウェアリソースを最小にする。このグルーロジックを、一般にカーネルの間、およびカーネルとIOデバイスとの間でのデータの移動に純粋に関係するロジックと見なすことができる。
従って、マニュアルによる最適化努力をすることなく、最適なリソース利用率を有するデザインを生成するための最適化問題を解決できる。かかる最適化により、デザインはより小型で安価なデバイスに適合できるか、または性能または機能を失うことなく、他の強化のために、より多くのリソースを残すことができる。
後述するように、このことはグルーロジックのコスト、すなわちグルーロジック専用にしなければならないハードウェアリソース(例えばFPGAリソース)の量を最小にするように中間カーネルに幅およびクロックを割り当てることによって達成できる。単一ストリーム接続のためのグルーロジックのコストは、ビット幅およびクロックドメインが同じであるかどうかに応じて決まる。異なるクロックドメインの間でデータを転送させるには、ストリーミングデータと同じビット幅を有する非同期式FIFOバッファが必要であり、異なるビット幅の間でデータを転送するには、パッキング/アンパッキングロジック、もしくは異なるサイズの読み出しポートおよび書き込みポートを有するFIFOバッファが必要である。
更に、実施形態では、デッドロックを防止し、ハードウェアリソースの利用を最小にするためのバッファリングの自動最適化が提供される。後述するように、自動ツールにより、バッファの位置および量を最適にするように、カーネルのバッファ化条件を指定するための方法が提供される。各カーネルは、多数の入力ポートおよび出力ポートを有し、各ポートに1つの「バッファスペース」の制約値が関連する。各ポートは、Nバイトのバッファリング(Nは0にすることができる)を必要とするか、またはこれを提供する制約値を有する。これによってマニュアルによる最適化努力をすることなく、デッドロックを防止するためにバッファリングで消費されるハードウェアリソースを最小にできるという利点が得られる。
「Nバイトのバッファリングを必要とすること」は、出力/入力がNバイトのバッファリングのバッファリングを扱わなければならないことを意味する。1つの出力ポートに対しては、このことはデザイン内の他のカーネルが行っていることとは無関係に、デッドロックを生じることなく、バッファ内に記憶されるNバイトを出力が自由に生成できることを意味する。1つの入力ポートに対しては、このことは入力においてバッファ化されるNバイトまでのデータが生じることを意味する。Nバイトのバッファリングを行うことは、カーネルが他の入力/出力から独立したそれぞれの入力/出力において、カーネルが内部にNバイトのバッファリングを含むことを意味する。各カーネルの設計者は、すべての入力/出力に対する制約値を指定しなければならない。自動化されたツールは、デザイン内のすべてのストリーム接続に対し、(提供されるか、または必要とされる)バッファの合計がゼロよりも大となることを保証する。
最後に、ハードウェアリソースの利用量を最小にするための相互接続の自動的スケジューリングが提供される。
次に、より詳細に説明すると、図8は最適にされたハードウェアデザインを生成する方法を略図で示すフローチャートである。この方法は、適当な言語、例えばJava(登録商標)言語のコンパイラーとして具現化でき、このコンパイラーは、入力デザインを実行し、ネットリスト状のハードウェアデザインまたはパイプライン状のハードウェアデザインのための所望するプレーンを表示する他のかかる手段を生成する。このコンパイラーは、ある形態のリーダーまたはキャリア上に記憶されるコンピュータコードとして提供できる。一実施例では、コンパイラーはディスクまたは他のかかる形態のコンピュータで読み取り可能なメディアに記憶されたコードである。ネットリストは、プログラマブルハードウェアデザイン、例えばFPGA上でコンフィギュアすべきコンポーネントのシーケンスのためのものでよい。
図8を参照すると理解できるように、コンパイラーはステップ72で入力デザイン(カーネル/IOの間のカーネルインターフェースおよび接続性の記述)を取り込み、ステップ84で、最適にされたハードウェア出力デザインを生成する。コンパイラーを通るフローは、コンパイラーの作動のステージを示す個々のブロックと共に、ブロックダイアグラムとして示されている。後述するように、最適化は数個のステージ(番号2〜6)で実行される。実際には、これら最適化の多くを単一ステージに組み合わせてもよいし、個々の最適化を省略してもよい。所定の最適化ステージを同時に検討すると、より良好な質の結果を得ることができる。実際のデザインに対して良好な結果を与え、コンパイル時間を短くするような妥協を示すことができる実現例を決定することが好ましい。
第1ステップ72では、コンパイラーに入力デザインが提供される。次に、第2ステップ74においてデザイン全体にわたるstallレイテンシーのスケジュールが定められる。次のステップ76では、デザインに対するクロックおよびデータ幅などが最適化される。次のステップ78では、デザインにアスペクト変換ロジックが追加され、次に再びクロックおよびデータ幅が最適化される。次にステップ80において、デザインに対し、アダプタロジックが追加され、次にクロックおよびデータ幅に対するその後の最適化が行われる(ステップ76)。最後に、ステップ82で、既に他のすべての最適化が実行されているにもかかわらず、完了していないデザインの部分がFIFOを追加することにより、ステップ6で解決される。
更に時間が経過すると、ステップ76において、クロックおよびデータ幅が最適化され、最後にハードウェアのためのデザインが出力として提供される。従って、クロックおよびデータ幅を最適化するステップ76は、デザインに別のカーネルを追加できる他の最適化ごとに繰り返すことが好ましい。その理由は、かかる追加されるカーネルは、これら追加カーネルに割り当てられるクロックおよびデータ幅を有するからである。次に、ステップ84において、プログラマブルロジック用のデザインが生成される。従って、一実施形態では、この方法はFPGAデザインプロセス中にプロセス相互接続のパラメータ化によって得られる最適化されたFPGAデザインの自動生成を可能にする。
デザインが一旦完了すると、既知のプログラミング技術を使ってこのデザインを実行できる。例えば決定されたデザインを有するプログラム化されたデバイスが使用のために生成されるよう、FPGAに対し、適当なプログラミングを実行できる。次に、これまで述べ、かつ図8に示されたステップの各々について詳細に説明する。
入力デザイン
マネージャーコンパイラーへの入力72は、一般にカーネルとカーネル間のデータストリームとを含むユーザーデザインである。このユーザーデザインは、グラフの頂点としてカーネルを有し、頂点間の弧としてデータストリームを有する向きが定められたグラフとして表示することが好ましい。実際の入力デザインは、例えばJava(登録商標)ソフトウェアライブラリーにより、公知の態様で構成できる。マネージャーコンパイラーは、アルゴリズムを簡略化するために、周期的入力グラフを非周期的グラフに変換する。このことは、複数のサイクルにわたって複数の最適化が行われないことを意味し、このような複数のサイクルは、比較的まれなことである。これとは異なり、周期的入力グラフ上で直接より複雑なアルゴリズムが作動することもできる。周期的または円形グラフとは、1つ以上のサイクル、例えば閉じたチェーン内に接続されたある数の頂点を含むグラフのことである。これと対照的に、非周期的グラフとは、複数の頂点および向きが定められたエッジの集団によって形成されるグラフのことであり、ここで各グラフはある頂点を別の頂点に接続する。よってある頂点でスタートし、最終的にスタートした頂点に再び戻るようなループを形成する、あるシーケンスのエッジに従うような方法はない。
上記のように、各カーネルは、一般に、多数の入力/出力ポートおよび多数の「幅ドメイン」および「クロックドメイン」を有する。1つの幅ドメインとは、同じアスペクト(幅)を有する入力/出力ポートのグループのことであり、1つのクロックドメインとは、同じクロックに同期する入力/出力ポートのグループのことである。幅とクロックドメインの双方は、固定されていてもよい(固定値に指定されていてもよい)し、または浮動(デザインの他の部分に合致するような任意の値に指定可能)でもよい。
例えば図9を参照すると、カーネルAは、2つのクロックドメイン(cおよびd)と1つの幅ドメイン(w)とを有することが理解できよう。この場合、すべての入力/出力ポートは同じ幅を有し、すべての入力は、同じクロックを有し、すべての出力は同じクロックを有する。
各入力ポート(P、Q、R、S)および各出力ポート(X、Y、C、D)は、「フロー制御タイプ」も有する。このフロー制御タイプは、データ転送(PUSH/PULL)およびそのフロー制御のパラメータ化(stallレイテンシー、almost empty(ほとんど空の)レイテンシー)を管理するのに使用されるフロー制御を指定する。
入力および出力にPUSHフロー制御を有するケースでは、出力側のstallレイテンシーパラメータは、入力側のstallレイテンシー+定数Kとして表記できる。更に(PULL→PULLに対する)同様な特殊なケースを取り扱うこともできるが、実際にはこのような状況は一般に生じるものではない。定数Kの重要性は下記のようにstallレイテンシーのスケジューリングを可能にすることである。
フロー制御タイプはstallレイテンシー(PUSH)またはほとんどemptyのレイテンシー(PULL)によりパラメータ化される。stallレイテンシーとは、データが失われる前にソースがVALIDとアサートし続けることができたシンクにより、STALLがアサートされた後のシンクの数のことである。ほとんどemptyなレイテンシーとは、ソースがアンダーフロー状態となる前にソースがALMOST_EMPTYとアサートした後にシンクがリード(READ)とアサートできたサイクル数のことである。瑣末なことであるが、同じフロー制御およびパラメータを有する入力/出力ポートを共に接続してもよい。同一でないケースに対しては後に詳細に説明するように、可能な場合にはあるグルーロジック、または追加バッファリングにより、2つのインターフェースを接続するのに十分な情報が存在する。
あるポートを別のポートに接続できるかどうか、更に接続できる場合にハードウェアを追加すべきかどうかの判断は、次の規則に基づいて行われる。
1.PULL→PUSHが軽微なグルーロジックを必要とすること
2.PUSH→PULLがバッファリングを必要とすること
3.シンクのほとんどemptyなレイテンシー>ソースのほとんどemptyなレイテンシーである場合に、PULL→PULLがバッファリングを必要とすること
4.ソースのstallレイテンシー>シンクのstallレイテンシーである場合に、PUSH→PUSHがバッファリングを必要とすること
スケジュールstallレイテンシー
次に、ステップ74において、stallレイテンシーのスケジュールを定める。この動作は、PUSH入力およびPUSH出力の共通する特殊なケースを有するカーネルのstallレイテンシーのスケジュールを定めることにより、バッファリングを最小かするように働く。図10の例では、muxカーネルのチェーンがstallレイテンシー(SL)=1を有するプッシュソースと、stallレイテンシー(SL)=10を有するプッシュシンクとの間を接続している。スケジューリングアルゴリズムが使用される。好ましい例では、ASAP(できるだけ早く)スケジューリングアルゴリズムが使用されるが、基本的には任意のスケジューリングアルゴリズムを使用できる。1つの例として整数リニアプログラムがある。
次に図10を参照し、特殊な例について説明する。理解できるように、この例では、ソースとシンクプッシュインターフェースとの間でmuxカーネルのチェーンが設けられる。muxの各々の出力上のstallレイテンシー(SL)は、対応する入力上でのstallレイテンシーの関数である。対応するシンクのSLよりも大きいSLを有するソースから進むときには、バッファリングが必要である。SLの値を適当に選択することにより、muxカーネル間のバッファリングを最小にするか、解消することが可能である。stallレイテンシーをスケジューリングするステップがない場合、入力/出力上のstallレイテンシーを固定する(例えば出力ではSL=2および入力ではSL=1)。この場合、ソースにおけるSL=2からシンクにおけるSL=1まで進むパスが存在するので、2つのmuxカーネルの間に無駄にバッファリングが挿入される。
再び図8を参照する。stallレイテンシーのスケジュールが定めた後に、ステップ3においてネットワーク全体にわたってクロックおよびデータ幅が最適化される。
クロックおよびデータ幅の最適化
クロック/幅最適化ステップ(ステップ3)は、幅/クロック移行ロジック上でのリソースの利用を最小にするために、固定されたクロック/ビット幅を有していないカーネルのクロックおよびビット幅をインテリジェントに指定する。これを行うためにはある種の組み合わせ最適化を使用できる。本例では、ダイナミックなプログラミングタイプのアルゴリズムが使用され、このアルゴリズムは、複雑な問題をより簡単なサブの問題に分解することにより、最適化の複雑な問題を解決する。これとは異なり、多数の精密/近似技術も使用できる。以下、非限定的な特定の例について詳細に説明する。デザインに対し、追加カーネルを追加できる他の最適化ステップを実行するごとに、クロック/ビット幅最適化ステップを繰り返す。その理由は、これらカーネルは自らに割り当てられるクロック/ビット幅を有していなければならないからである。
一例では、使用されるアルゴリズムは次のようなものである。
1.プロセスの非周期的グラフを多数の(森の)ツリーに分割する。1本のツリーはグラフノード(プロセス)のサブセットであり、ここでは任意の2つのノードの間に正確に1つの簡単なパスが存在する。従って、非周期的グラフを使用すると、全体としてネットワークの分割が簡単になる。
2.各ツリーに対し、複数のノードにわたり、ポストオーダーで、すなわち、まず葉から、最後に根となるように繰り返しを実行する。
3.各ノードに対し、クロック/ビット幅のすべての可能な割り当ての組を計算する。例えば2つの可能なクロック(CLK_AおよびCLK_B)および2つの可能な幅(8、16)が存在する場合、可能な割り当ての組はCLK_A:8、CLK_B:8、CLK_A:16、CLK_B:16となる。
4.各割り当ての組に対し、各チャイルドノードからのクロック/幅の移行の最小コストを計算する。この割り当てコストはチャイルドノードの割り当てのコスト+チャイルドノードの割り当てから現在の割り当てまでの移行のコストとして計算される。
図11は、1つのノード(ツリーノード:カーネルA)と、2人のチャイルド(XおよびY)86および88から成る簡単なツリーにおける割り当てコストの計算の作業例を示す。各チャイルドは、クロック/幅の可能な各割り当てに関連する最小コストを有する。最初のチャイルド86に対してクロックAおよび幅8を有するための最小コストは「100」となる。クロックAおよび幅16を有するための最小コストは200となる。第2のチャイルド88に対して、クロックBを有する場合のコストは、割り当てられた幅(8または16)にかかわらず同じ「150」となる。こうしてそれぞれのチャイルドに対し、幅およびクロックを割り当てるためのコストが決定される。
次に、カーネルAに対する値がクロックAおよび幅8として決定された場合に異なるデータ幅の間で移行するためのコストがどのようになるかが決定される。異なる移行に対するコストの例を示す下記の表2を参照すれば、このことが理解できよう。
理解できるように、データ幅の変化がなく、クロックの移行もない場合、この「移行」に対するコストはゼロとなる(実際にデータを移行するためにはグルーロジックは、不要となる)。データ幅の変化(8から16へ、または16から8へ)があるが、クロックの移行がない各ケースでは、コストは「5」となる。データ幅の変化とクロックの移行の双方が存在する各ケースでは、コストは15となる。
ついに、全体で最小のコストを生成する種々のノードのパラメータに対する値を探すために、チャイルドノードに対する指定のすべての組み合わせを列挙する。各行で計算されるコストは、チャイルドノードの割り当てコストに特定の割り当てに対する移行コストを加えた(チャイルドノードごとの)合計である。下記の表3は、すべての組み合わせを列挙したこの組み合わせを示す。
表3内の数字は、表2からのコストの場合の図11に示されたオプションからの数字である。従って、行1では、クロックAおよびデータ幅8を有するカーネルAに対するコストは、クロックAおよびデータ幅8を有するチャイルドXの場合のコスト(100)+クロックBおよびデータ幅8を有するチャイルドYの場合のコスト(150)+必要とされる移行コスト(0+10)から成る。従って、全最小コストは260であり、よって指定される割り当てが行われる。この計算を使用すれば、カーネルAに対するクロックまたはデータ幅の他の任意の割り当ては、全体により高いコストとなることが明らかとなると理解できよう。例えばチャイルドXにデータ幅16が割り当てられ、チャイルドYにデータ幅8が割り当てられた場合、この移行の全コストは365に跳ね上がり、この値はかなりの増加量となる。
カーネルAに対して一旦割り当てが行われると、カーネルA自体が計算ステップ内のチャイルドノードとなるので、全体としてツリー(および最終的にはネットワーク)に対する値を決定できる。従って、この方法により全体としてデバイスに対する働きを失うことなく、かかるパラメータの割り当てを自動的かつ効率的に行うことが可能となる。
アスペクト変換ロジックの挿入
再び図8を参照する。ネットワーク全体にわたり、一旦データ幅およびクロックが決定されると、ステップ78においてデザイン内に必要なアスペクト変換ロジックが挿入される。図4に示し、図4を参照してこれまで説明したように、アスペクトのある変化がある場合、1つのアスペクトにおける受信データを処理し、このデータを第2のアスペクトで出力に提供するための、ロジックが必要となる場合がある。シフトレジスターは、アスペクト変換ロジックの周知の一例であり、このロジックはレジスターの入力における狭い幅のNを、Kサイクルごとに出力における幅の倍数N×Kに変換する。
必要なアスペクト変換ロジックを挿入した後に、新しく挿入されたロジックに対して再びクロックおよび幅最適化プロセスが実行される。
アダプタロジックの挿入
次に、ステップ80において、アダプタロジックが挿入される。このアダプタロジックは、表1を参照してこれまで説明したように、異なるタイプのフロー制御の間で変換をするのに必要とされる。アダプタロジックは、各特定の状況に応じて必要とされるようなグルーロジックまたは追加バッファリングの形態をとる。必要とされるアダプタロジックを挿入した後に新たに挿入されたロジックに対して再びクロックおよび幅最適化ロジックが実行される。
FIFOの挿入
次にステップ82において、FIFOが挿入される。このステージは、すべてのカーネルなどがパラメータ化され、上記のようにレイテンシーを最適にし、幅およびクロックが一旦割り当てられた場合に実行される。必要とされた場合に追加FIFOが挿入されることにより、デザインに関する残留問題が解決されるのはこのステージだけである。利用される追加ハードウェアを最小に維持することが望ましいので、このステージは他の最適化ステージが一旦実行された場合にしか実行しないことが好ましい。
次に図12を参照し、追加バッファリングが必要とされ得るような状況について説明する。図12に示された左側部分に示されるように、最初に2つのカーネル、すなわちカーネルAとカーネルBとが接続される。カーネルAのポートQは、2キロバイトのバッファリングを必要とするが、他方、カーネルAのポートQが接続されているカーネルBのポートRは、1キロバイトのバッファリングしか行わない。従って、1キロバイトの追加バッファリングが必要とされると判断され、よってこのような挿入が行われる。2キロバイトの記憶をするためのFIFOが選択され、他方、FIFOの出力は1キロバイトしか必要としない。従って、1キロバイトのFIFOを挿入することにより、カーネルAとBとの間の競合の問題が解決される。
図13を参照する。カーネル間で必要とされるFIFOを決定する際のステップを示すための略フローチャートが示されている。最初にステップ90において、当該接続されたシンクおよびソースの各々に対するクロックおよびフロー制御タイプのポートが同じであるかどうかが判断される。これらが同じである場合、プロセスはステップ92に進み、ここで実際のタイプのソースが決定される。同じでない場合、デザイン内に1つのFIFOが挿入される(ステップ96)。
PUSHタイプのソースの場合、プロセスはステップ94に進み、ここでソースのstallレイテンシー(SL)が接続されたシンクのstallレイテンシーよりも大きいかどうかの判断がなされる。大きい場合、デザイン内に1つのFIFOが挿入される(ステップ96)。大きくない場合、ソースバッファのスペースがシンクのスペースよりも大きいかどうかの判断がなされる(ステップ98)。大きくない場合、このプロセスは完了し(ステップ100)、追加FIFOは不要である。ソースバッファのスペースがシンクのスペースよりも大である場合、デザイン内に1つのFIFOが挿入される(ステップ96)。
ステップ92に戻り、ここでソースのタイプが識別される。ソースがPULLソースであると判断された場合、ステップ102においてソースの「ほとんどemptyなレイテンシー」(AEL)が接続されたシンクのレイテンシー未満であるかどうかの判断がなされる。
そうである場合、デザイン内に1つのFIFOが挿入される(ステップ96)。そうでない場合、プロセスは上記のようにステップ98へ進み、ここでソースバッファのスペースがシンクのスペースよりも大きいかどうかの判断がなされる。従って、簡単であるが信頼できる機構が提供され、この機構によって、本願に記載したようなノードのネットワーク内で追加FIFOが必要であるかどうかの判断を自動的に行うことができる。
一実施形態において、可変で、可能な複数の解決案により、複雑なシステムの最適化を行うための方法および装置が提供されることが理解できよう。この方法は、所望するプロセッサによって実行されるべきプロセスを指定する入力を受信すると、デザイン内のパラメータを自動的に最適化し、指定された機能を実行するためのハードウェア条件を最小にするようになっている。一旦パラメータが決定されると、最適化に従って1つのデザインが生成される。従って、複数のプロセスにわたるレイテンシー、フロー制御および可変クロックレートおよびデータ幅に関する、上記問題が解決される。
以上で、図示した例を参照して本発明の実施形態について説明した。しかしながら、本発明の範囲内では、上記例に対して変更および修正を行うことができると理解できよう。

Claims (24)

  1. 複数のプロセスと、これら複数のプロセスの間でデータパスを提供するための前記プロセス間の相互接続とを備えたハードウェアストリームプロセッサデザインを自動的に生成するための方法であって、
    前記ストリームプロセッサによって実行すべきプロセスを指定する入力デザインの受信時に、前記入力デザイン内のプロセス間の前記相互接続に関連したパラメータを自動的に最適化し、必要な機能を提供しながらハードウェア条件を最小にするステップと、
    前記最適化に従って最適化された出力デザインを生成するステップとを含む、ハードウェアストリームプロセッサデザインを生成する方法。
  2. 前記出力デザイン内で使用するためにプロセス間のフロー制御方法を自動的に決定するステップを含む、請求項1に記載の方法。
  3. 定められたパラメータを使用することにより、プロセス間のstall(ストール)レイテンシーのスケジュールを定めるステップを含む、請求項2に記載の方法。
  4. 前記出力デザイン内のプロセス間のフロー制御方法が、どれも同じ特定されたタイプである場合に接続されたプロセスのカスケード内のstall(ストール)レイテンシーを示すためのパラメータを定めるステップと、記憶条件を最小にするよう、前記パラメータに対する値を決定するステップとを含む、請求項3に記載の方法。
  5. 前記プロセスの各々は、接続されたプロセスおよび対応するクロックレートの1つ以上の入力ポートに接続された1つ以上の出力ポートを有し、前記接続されたポートのための前記クロックレートを最適化するステップを含む、請求項1〜4のいずれか1項に記載の方法。
  6. 前記プロセスの各々は、接続されたプロセスおよび対応するデータ幅の1つ以上の入力ポートに接続された1つ以上の出力ポートを有し、接続されたペアのポートに対してデータ幅を自動的に最適化するステップを含む、請求項1〜5のいずれか1項に記載の方法。
  7. 組み合わせによる最適化を使用して前記パラメータを最適化する、請求項1〜6のいずれか1項に記載の方法。
  8. ダイナミックプログラミングアルゴリズムを使用して前記組み合わせによる最適化を実行する、請求項7に記載の方法。
  9. 前記入力デザインは、プロセスがグラフの頂点であり、プロセス間のデータストリームが前記頂点の間の弧となるような非周期的グラフ状となっている、請求項1〜8のうちのいずれか1項に記載の方法であって、前記グラフのサブツリーに対する自動最適化を実行し、好ましくは1回終了すると、グラフ全体が最適化されるまで、前記グラフのその後のサブツリーに対し、自動最適化を実行するステップを含む方法。
  10. 各プロセスの前記データ幅およびクロックレートに対する最適値を決定するための数値方法を利用するステップを含む、請求項1〜9のうちのいずれか1項に記載の方法。
  11. プロセス内の値の各コンフィギュレーションに対するコストを決定するステップと、
    前記プロセスに対する全最小コストを提供する値を前記プロセスに割り当てるステップとを含む、請求項10に記載の方法。
  12. あるプロセスから別のプロセスに移行するためのコストを決定するステップを備え、全コストは、プロセス内の値のコンフィギュレーションに対するコストに、あるプロセスから別のプロセスに移行するための前記コストを加えた合計から成る、請求項11に記載の方法。
  13. 1つのサブツリーに対する全コストが一旦決定されると、全グラフが最適化されるまでグラフのうちのその後のサブツリーに対する前記最適化を実行するステップを含む、請求項11または12に記載の方法。
  14. 最適化が一旦実行されると、デザイン内でアスペクト変換ロジックを自動的に提供するステップを含む、請求項1〜13のうちのいずれか1項に記載の方法。
  15. 一旦最適化が実行されると、デザインのアダプタロジックを自動的に提供するステップを含む、請求項1〜14のうちのいずれか1項に記載の方法。
  16. 最適化が一旦実行されると、前記デザイン内にFIFOを自動的に挿入するステップを含む、請求項1〜15のうちのいずれか1項に記載の方法。
  17. 各最適化ステップの後に、クロックレートおよびデータ幅を最適化するステップを含む、請求項1〜16のうちのいずれか1項に記載の方法。
  18. a)前記ソースクロックレートと前記シンククロックレートとが同一でない条件、および
    b)前記ソースフロー制御方法と前記フロー制御方法とが同一でない条件を含む1つ以上の条件が満たされた場合に、任意のペアのプロセスの間だけにFIFOを挿入する、制御方法16に記載の方法。
  19. 請求項1〜18のうちのいずれか1項に記載の方法を使用するデザインを生成するステップと、
    前記生成されたデザインを実施するための前記ロジックデバイスをプログラミングするステップとを含む、プログラム可能なロジックデバイスを作成する方法。
  20. コンピュータで実行されるときに、請求項1〜18のうちのいずれか1項のステップを実行するようになっているコンピュータプログラム
  21. コンピュータで読み取り可能なメディアに記憶された、請求項20に記載のコンピュータプログラム。
  22. 請求項1〜18のうちのいずれか1項に記載の方法を使用して生成されるデザインを有するフィールドプログラマブルゲートアレイまたは他のプログラマブルロジック。
  23. 請求項1〜18のうちのいずれか1項に記載の方法を実行し、前記生成されたデザインを有するプログラマブルロジックデバイスのプログラミングのための命令のリストを生成するようになっているプロセッサを含む、ハードウェアストリームプロセッサデザインを生成するためのシステム。
  24. 複数の相互接続されたプロセスを含むFPGAプロセッサのためのデザインを生成する方法であって、
    指定された入力デザインを受信したときに、このデザイン内で前記プロセスの各々の働きを最適化するステップと、
    この最適化を一旦実行すると、前記最適化されたプロセスの各々の間の前記相互接続を最適化するステップを備える、FPGAプロセッサのためのデザインを生成する方法。
JP2012024079A 2011-02-08 2012-02-07 ハードウェアストリームプロセッサデザインを生成するための方法、装置およびソフトウェアコード Pending JP2012164316A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/023,275 2011-02-08
US13/023,275 US8972923B2 (en) 2011-02-08 2011-02-08 Method and apparatus and software code for generating a hardware stream processor design

Publications (1)

Publication Number Publication Date
JP2012164316A true JP2012164316A (ja) 2012-08-30

Family

ID=45607615

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012024079A Pending JP2012164316A (ja) 2011-02-08 2012-02-07 ハードウェアストリームプロセッサデザインを生成するための方法、装置およびソフトウェアコード

Country Status (4)

Country Link
US (1) US8972923B2 (ja)
EP (1) EP2495675A3 (ja)
JP (1) JP2012164316A (ja)
GB (1) GB2488021B (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015118609A (ja) * 2013-12-19 2015-06-25 インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation 予め決められた複数のビット幅のデータに対して操作を行う命令を使用してツリーの検索を行うための方法、並びに、当該命令を使用してツリーの検索を行うためのコンピュータ及びそのコンピュータ・プログラム

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9367658B2 (en) * 2011-06-22 2016-06-14 Maxeler Technologies Ltd. Method and apparatus for designing and generating a stream processor
US20130046912A1 (en) * 2011-08-18 2013-02-21 Maxeler Technologies, Ltd. Methods of monitoring operation of programmable logic
US9652570B1 (en) * 2015-09-03 2017-05-16 Xilinx, Inc. Automatic implementation of a customized system-on-chip
EP3244326B1 (de) * 2016-05-10 2021-07-07 dSPACE digital signal processing and control engineering GmbH Verfahren zum erstellen einer fpga-netzliste
US11016822B1 (en) * 2018-04-03 2021-05-25 Xilinx, Inc. Cascade streaming between data processing engines in an array
CN116128448B (zh) * 2023-01-09 2023-10-17 苏州异格技术有限公司 Fpga工程项目的设计数据处理方法、装置、电子设备

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07192029A (ja) * 1993-12-27 1995-07-28 Hitachi Ltd 論理回路の生成方法
JP2001056827A (ja) * 1999-08-18 2001-02-27 Matsushita Electric Ind Co Ltd 集積回路装置の設計方法
JP2006505056A (ja) * 2002-10-31 2006-02-09 エス・アール・シィ・コンピューターズ・インコーポレイテッド 制御フローグラフ表現を制御データフローグラフ表現に変換するためのシステムおよび方法
JP2006065457A (ja) * 2004-08-25 2006-03-09 Fuji Xerox Co Ltd インタフェース回路生成装置およびインタフェース回路
JP2007087206A (ja) * 2005-09-22 2007-04-05 Canon Inc 設計支援システム及び設計支援方法
US7305649B2 (en) * 2005-04-20 2007-12-04 Motorola, Inc. Automatic generation of a streaming processor circuit
JP2009512089A (ja) * 2005-10-18 2009-03-19 マイトリオニクス エービー データフローマシンにおけるデッドロックを回避するための方法
US20100293301A1 (en) * 2009-05-14 2010-11-18 International Business Machines Corporation Dynamically Composing Data Stream Processing Applications

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5687090A (en) * 1994-09-01 1997-11-11 Aspen Technology, Inc. Polymer component characterization method and process simulation apparatus
US6086629A (en) 1997-12-04 2000-07-11 Xilinx, Inc. Method for design implementation of routing in an FPGA using placement directives such as local outputs and virtual buffers
US6405232B1 (en) * 1999-08-19 2002-06-11 National Semiconductor Corporation Leading bit prediction with in-parallel correction
US6801924B1 (en) * 1999-08-19 2004-10-05 National Semiconductor Corporation Formatting denormal numbers for processing in a pipelined floating point unit
US7139901B2 (en) * 2000-02-08 2006-11-21 Mips Technologies, Inc. Extended instruction set for packet processing applications
JP4558879B2 (ja) * 2000-02-15 2010-10-06 富士通株式会社 テーブルを用いたデータ処理装置および処理システム
US6594316B2 (en) * 2000-12-12 2003-07-15 Scientific-Atlanta, Inc. Method and apparatus for adaptive bit rate control in an asynchronized encoding system
US7039834B1 (en) * 2000-12-21 2006-05-02 Unisys Corporation High speed processor interconnect tracing compaction using selectable triggers
EP2627008A3 (en) * 2000-12-29 2013-09-11 Intel Mobile Communications GmbH Channel codec processor configurable for multiple wireless communications standards
US6717516B2 (en) * 2001-03-08 2004-04-06 Symbol Technologies, Inc. Hybrid bluetooth/RFID based real time location tracking
US6751783B1 (en) 2001-10-30 2004-06-15 Lsi Logic Corporation System and method for optimizing an integrated circuit design
US20040022192A1 (en) * 2002-08-05 2004-02-05 Khan Raheel Ahmed Bit stream processor
US7359846B1 (en) * 2002-12-05 2008-04-15 Cadence Design Systems, Inc. Modeling an ASIC based on static pipeline delays
US7426628B2 (en) * 2003-03-14 2008-09-16 National Instruments Corporation Run-time node prefetch prediction in dataflow graphs
US7725888B2 (en) * 2003-09-26 2010-05-25 Wind River Systems, Inc. Systems and methods for dynamically linking application software into a running operating system kernel
CN100485657C (zh) * 2004-02-19 2009-05-06 Nxp股份有限公司 具有本地受控参数更新的电子流处理电路以及设计这种电路的方法
US7315991B1 (en) 2005-02-23 2008-01-01 Xilinx, Inc. Compiling HLL into massively pipelined systems
US7603492B2 (en) * 2005-09-20 2009-10-13 Motorola, Inc. Automatic generation of streaming data interface circuit
US8068541B2 (en) * 2006-01-30 2011-11-29 Jan Harding Thomsen Systems and methods for transcoding bit streams
KR100881419B1 (ko) * 2006-11-02 2009-02-05 한국전자통신연구원 Sca 기반 시스템의 애플리케이션 컴포넌트 통신 장치 및방법
JP5029053B2 (ja) * 2007-02-15 2012-09-19 富士ゼロックス株式会社 データ通信システム及びデータ通信プログラム
US8135853B1 (en) * 2007-11-21 2012-03-13 Marvell International Ltd. Streaming data engine
US8078980B2 (en) * 2008-03-20 2011-12-13 National Instruments Corporation User defined wire appearance indicating communication functionality in a graphical programming environment
US8074177B2 (en) * 2008-03-20 2011-12-06 National Instruments Corporation User defined wire appearance indicating data type in a graphical programming environment
US7817655B1 (en) * 2008-10-30 2010-10-19 Xilinx, Inc. Determining sizes of FIFO buffers between functional blocks in an electronic circuit
US8805914B2 (en) * 2010-06-02 2014-08-12 Maxeler Technologies Ltd. Method and apparatus for performing numerical calculations
US8938562B2 (en) * 2010-06-25 2015-01-20 Maxeler Technologies, Ltd. Method of, and apparatus for, mitigating memory bandwidth limitations when performing numerical calculations
US8464190B2 (en) * 2011-02-17 2013-06-11 Maxeler Technologies Ltd. Method of, and apparatus for, stream scheduling in parallel pipelined hardware
US9367658B2 (en) * 2011-06-22 2016-06-14 Maxeler Technologies Ltd. Method and apparatus for designing and generating a stream processor
US20130046912A1 (en) * 2011-08-18 2013-02-21 Maxeler Technologies, Ltd. Methods of monitoring operation of programmable logic
US8990827B2 (en) * 2011-10-11 2015-03-24 Nec Laboratories America, Inc. Optimizing data warehousing applications for GPUs using dynamic stream scheduling and dispatch of fused and split kernels
US8631380B2 (en) * 2011-11-28 2014-01-14 Maxeler Technologies, Ltd. Method of, and apparatus for, data path optimisation in parallel pipelined hardware
JP5842206B2 (ja) * 2012-01-27 2016-01-13 株式会社トプスシステムズ プロセッサ・コア、およびマルチコア・プロセッサ・システム
US9430807B2 (en) * 2012-02-27 2016-08-30 Qualcomm Incorporated Execution model for heterogeneous computing
US9514094B2 (en) * 2012-07-10 2016-12-06 Maxeler Technologies Ltd Processing data sets using dedicated logic units to prevent data collision in a pipelined stream processor
US8739101B1 (en) * 2012-11-21 2014-05-27 Maxeler Technologies Ltd. Systems and methods for reducing logic switching noise in parallel pipelined hardware
US8701069B1 (en) * 2012-11-21 2014-04-15 Maxeler Technologies, Ltd. Systems and methods for optimizing allocation of hardware resources to control logic in parallel pipelined hardware

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07192029A (ja) * 1993-12-27 1995-07-28 Hitachi Ltd 論理回路の生成方法
JP2001056827A (ja) * 1999-08-18 2001-02-27 Matsushita Electric Ind Co Ltd 集積回路装置の設計方法
JP2006505056A (ja) * 2002-10-31 2006-02-09 エス・アール・シィ・コンピューターズ・インコーポレイテッド 制御フローグラフ表現を制御データフローグラフ表現に変換するためのシステムおよび方法
JP2006065457A (ja) * 2004-08-25 2006-03-09 Fuji Xerox Co Ltd インタフェース回路生成装置およびインタフェース回路
US7305649B2 (en) * 2005-04-20 2007-12-04 Motorola, Inc. Automatic generation of a streaming processor circuit
JP2007087206A (ja) * 2005-09-22 2007-04-05 Canon Inc 設計支援システム及び設計支援方法
JP2009512089A (ja) * 2005-10-18 2009-03-19 マイトリオニクス エービー データフローマシンにおけるデッドロックを回避するための方法
US20100293301A1 (en) * 2009-05-14 2010-11-18 International Business Machines Corporation Dynamically Composing Data Stream Processing Applications

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015118609A (ja) * 2013-12-19 2015-06-25 インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation 予め決められた複数のビット幅のデータに対して操作を行う命令を使用してツリーの検索を行うための方法、並びに、当該命令を使用してツリーの検索を行うためのコンピュータ及びそのコンピュータ・プログラム

Also Published As

Publication number Publication date
GB2488021B (en) 2020-02-05
US20120200315A1 (en) 2012-08-09
EP2495675A3 (en) 2012-12-05
EP2495675A2 (en) 2012-09-05
US8972923B2 (en) 2015-03-03
GB2488021A (en) 2012-08-15
GB201201721D0 (en) 2012-03-14

Similar Documents

Publication Publication Date Title
US10452452B2 (en) Reconfigurable processor fabric implementation using satisfiability analysis
JP2012164316A (ja) ハードウェアストリームプロセッサデザインを生成するための方法、装置およびソフトウェアコード
US7509647B2 (en) Method and apparatus for modeling dataflow systems and realization to hardware
JP6001873B2 (ja) 並列パイプライン化ハードウェアにおけるストリームスケジューリング方法および装置
JP2009512089A (ja) データフローマシンにおけるデッドロックを回避するための方法
JP2016526220A (ja) プログラム可能な最適化を有するメモリネットワークプロセッサ
WO2006115635A2 (en) Automatic configuration of streaming processor architectures
KR20130009746A (ko) 스트림 기반 계산을 구현하기 위한 범용 다중 코어 시스템을 위한 방법 및 장치
AU2004250685A1 (en) Integrated circuit development system
US11709664B2 (en) Anti-congestion flow control for reconfigurable processors
CN111767041A (zh) 在数据流图中插入缓冲器的方法和设备
Hansson et al. Enabling application-level performance guarantees in network-based systems on chip by applying dataflow analysis
JP2006522406A5 (ja)
Josipović et al. Invited tutorial: Dynamatic: From C/C++ to dynamically scheduled circuits
US20180212894A1 (en) Fork transfer of data between multiple agents within a reconfigurable fabric
JP2005135411A (ja) カスタム回路デバイスの設計方法
Sittel et al. ILP-based modulo scheduling and binding for register minimization
US20020023250A1 (en) Parameterized designing method of data driven information processor employing self-timed pipeline control
US7802005B2 (en) Method and apparatus for configuring buffers for streaming data transfer
Elakhras et al. Straight to the queue: Fast load-store queue allocation in dataflow circuits
JP2018041301A (ja) Rtl最適化システム及びrtl最適化プログラム
Al-Zu'bi et al. FPGA implementation of data flow graphs for digital signal processing applications
US11954053B2 (en) Integrating buffer views into buffer access operations in a coarse-grained reconfigurable computing environment
Lin et al. A parameterized dataflow language extension for embedded streaming systems
Rodionov Automated Interconnect Synthesis and Optimization for FPGAs

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150209

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160113

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160301

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20160601

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20160801

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160901

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20170302

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170703

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20170831

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20171102