VisualAppletsで作成されるダイアグラムは、オペレータインスタンス(モジュール)のネットワークです。複数のサブネットワークを組み合わせることができます。
他のプログラミング言語と同様に、VisualAppletsで作成するダイアグラムには、許可されている構造、許可されていない構造、制限されている構造に関する一連の規則が適用されます。 次のセクションでは、モジュールを接続するための基本規則を定義します。
まず、操作するさまざまなタイプのオペレータについて見ていきましょう。
オペレータのタイプと同期に関する実践的なガイダンスについては、Operator Types and Synchronizationのチュートリアル トピックを参照してください。
VisualAppletsには、3つのタイプのオペレータがあります。
| 汎用タイプ“O”(丸型): |
|
|
|
| より複雑なタイプ“M”(四角型): |
|
VisualAppletsの古いバージョンや、ドキュメント内のいくつかの例における 楕円形: |
|
| 特殊タイプ“P”(四角型): |
|
VisualAppletsの古いバージョンや、ドキュメント内のいくつかの例における 楕円形: |
|
表 4:オペレータタイプ
オペレータの形状によって、それが汎用“O”タイプに属するのか、より複雑な“M”または“P”タイプのいずれかに属するのかを確認できます。 (特定のオペレータのタイプに関する情報については、Operator Referenceにあるそのオペレータのドキュメントを確認してください。)
Oタイプオペレータの機能は比較的シンプルです。そのため、
-
Oタイプオペレータは、入力と出力の間でピクセル/データの数を変更しません。すべての入力リンクの入力ピクセル/データの数は、出力ピクセル/データの数と等しくなります。 つまり、各入力値に対して、オペレータは1つの値を出力します。
-
Oタイプオペレータは、入力と出力の間に遅延を追加する場合があります。ただし、この遅延はレイテンシバランシング中に自動的に補償されます。
-
Oタイプオペレータは、必要に応じて直列または並列にリンクできます。
Mタイプオペレータの機能はより複雑です。
-
入力と出力の間でピクセル/データの数を変更できます。
-
出力を遅延させる場合があります。
-
Mタイプオペレータのリンクには、リンクの規則と、リンクされたオペレータの機能に注意を払う必要があります。
-
Mタイプオペレータは入力をブロックする場合があります。
-
ダイアグラム内のすべてのソースオペレータ(CameraGrayAreaBaseなど)は、Mタイプオペレータです。
-
ダイアグラム内のすべての最終宛先オペレータ(DmaToPCなど)は、Mタイプオペレータです。
PタイプオペレータはMタイプオペレータに似ていますが、
-
Pタイプオペレータは帯域幅を削減しません。(この問題の詳細については、'Infinite Sources / Connecting Cameras'を参照してください。)
-
Pタイプオペレータは、入力で与えられたデータ量を超えるデータを生成しません。
-
P型オペレーターは、入力を積極的にブロックすることはありません(P型オペレーターのブロック動作の詳細については、「P型オペレーター」を参照してください)。
以下では、P型オペレーターに関する例外が明記されていない限り、M型オペレーターに対して定義されたすべての規則がP型オペレーターにも適用されます。
O型ネットワークは、O型モジュールの組み合わせです。 O型ネットワークでは、モジュールを直列にも並列にも組み合わせることができます。 O型ネットワークは、常にM型またはP型モジュールで始まり、終わります。 この定義に基づき、重要な規則を定義できます。
![]() |
O型ネットワークの規則 |
|---|---|
|
O型ネットワークでは、どれほど複雑であっても、各O型モジュールは同じM型またはP型モジュールをソースとする必要があります。 これらは、他のO型モジュールやO型(サブ)ネットワークを介してこのソースに接続されている場合があります。 (この規則はシグナルリンクには適用されないことに注意してください。) |
次の図は、モジュールの並列接続と直列接続を含むO型ネットワークを示しています。 ご覧のとおり、すべてのO型モジュールは同じM型モジュール(M_source)をソースとしています。
対照的に、次の図は、ADDモジュールが異なるM型モジュール(M_source_0およびM_source_1)をソースとしているため、O型ネットワークの規則に違反しているO型ネットワークを示しています。
VisualApplets(バージョン2.2以降)では、同期規則に違反したときに、設計図上に直接信頼性の高いインジケーターが表示されます。 該当するリンクは紫色で強調表示されます。 リンクは、正しく同期されていないデータを受信するオペレーターから、対応するMオペレーターソースまで強調表示されます。
DRC 1およびDRC 2には、対応する警告が表示されます。
たとえば、上記のデザインの場合、DRC 1によって次のような警告が生成されます。

![]() |
例外:シグナルリンク |
|---|---|
|
O型ネットワークの規則は、シグナルリンクを伝送するO型オペレーターには適用されません(「シグナルリンクの異なる規則」を参照)。 |
M型モジュールをソースおよびデスティネーションとしてだけでなく、画像処理の目的でその間にも含むモジュールのネットワークは、M型ネットワークと呼ばれます。 M型ネットワークでは、M型モジュールを並列および直列にリンクさせることができます。 M型モジュールは、制限なく分岐させることもできます。 M型モジュールの並列リンクには画像サイズの同期やタイミングの同期が必要になる場合があるため、M型ネットワークはかなり複雑になることがあります。 (忘れないでください:M型モジュールは、入力と出力の間でピクセル/データの数を変更でき、出力を遅延させることもできます。)
次の図は、M型ネットワークの非常にシンプルな例を示しています。 この図のM型モジュールは、直列に接続されているか、分岐しているのみです。 図内の唯一のO型ネットワークは同じM型モジュール(ImageBuffer)をソースとしているため、この図はこれまでに説明したすべての図の規則に従っています。
ほとんどの場合、M型ネットワークははるかに複雑です。 上記の例とは対照的に、M型モジュールが並列にリンクされている場合 (つまり、マージされるパスが異なるM型ソースをソースとしている場合)、 タイミングと画像サイズを同期させる必要があります。 これを行うには、複数の入力を使用するM型オペレーターを使用します。
異なるM型ソースをソースとするネットワークをマージする場合は、複数の入力を持つM型オペレーターを使用する必要があります。 (前述のO型ネットワークの規則に違反するため、複数の入力を持つO型オペレーターを使用することはできません。) ただし、同期の詳細に入る前に、一般的な複数の入力を持つM型オペレーターを見てみましょう。
複数の入力を持つM型オペレーターには、2種類の入力があります。
-
同期入力
-
非同期入力
同期入力および同期入力グループ
モジュールの一部の入力が同期入力である場合、これらの同期入力は合わせて1つの同期入力グループを形成します。 したがって、同期入力グループとは、同期入力のセットのことです。 同期入力グループの入力は、O型オペレータの任意のネットワークを介して、常時同じM型ソースから供給される必要があります。 M型オペレータは、任意の数の同期入力グループを持つことができます。
下の図は、同期入力グループを持つM型オペレータの使用例を示しています。 RemoveImageオペレータの両方の入力は、同じM型ソース(ImageBuffer)から供給されています。 これら2つの入力が合わさって同期入力グループを形成します。 RemoveImageオペレータは、その入力ポートで異なるM型ソースを使用することを許可していません。
非同期入力
非同期入力は同期されません。 これらは、O型オペレータの任意のネットワークを介して、異なるM型ソースから供給される場合があります。 さらに、複数の入力を持つ一部のM型オペレータは、実際には異なるM型ソースから供給される必要があります。 複数の入力を持つM型オペレータを異なるM型ソースから供給する必要があるかどうかは、オペレータ自体の機能によって異なります。 すべてのオペレータに関する詳細情報は、Operator Referenceに記載されています。 M型オペレータは、任意の数の非同期入力を持つことができます。
次のスクリーンショットは、2つの非同期入力を持つM型オペレータの典型的な例を示しています。 SYNCモジュールの両方の入力は、それぞれDRAM0およびDRAM1という異なるM型ソースから供給されています。
SYNCモジュールの後には、MergePixelオペレータが続きます。 間にSYNCオペレータを挟まない場合、このオペレータを使用して2つのM型ソースをマージすることはできません。
![]() |
M型オペレータの入力 |
|---|---|
|
M型モジュールの入力は、異なるM型ソースから供給される場合があります。 ただし、同期入力グループの入力は、O型オペレータの任意のネットワークを介して、同じM型ソースから供給される必要があります。 |
複数の入力を持つ各M型オペレータのドキュメントには、そのオペレータで可能または必要な入力について詳しく説明されています。 すべてのオペレータの詳細な説明については、Operator Referenceを参照してください。
M型オペレータは、その入力における異なる画像次元を同期させることができます。 重要な例の1つがSYNCオペレータです。 このオペレータの詳細な説明については、Operator Referenceを参照してください。
O型ネットワークの場合、VisualAppletsは自動的にタイミング同期を実行します。
M型ネットワークの場合、同期はM型オペレータによって実行される必要があります。
タイミング同期の設計が正しくない場合、
-
いわゆるデッドロック状態が発生するか、
-
帯域幅が不足するか、または
-
データが失われます。
![]() |
正しいタイミング同期の確保 |
|---|---|
|
タイミング同期はVisualAppletsで実装するアルゴリズムの動作に依存するため、ダイアグラム内のタイミング同期が正しいことを確認する必要があります。 |
以下の例では、タイミングの同期について詳しく見ていきます。
-
独立したソースの同期
図 59「独立したソースの同期」に示すような、2台のカメラを使用した単純なスティッチングの例を見てみましょう。 この例では、2台のカメラがソースとして使用されています。 ImageBufferオペレータがデータをバッファリングします。 最後に、M型のオペレータであるInsertLineが、両方のカメラのラインを1つの出力リンクに多重化します。 このオペレータは、2つのパラレルリンクをマージします。
2台のカメラが同期していない場合どうなるかを想像してみてください。 一方のカメラのフレームレートが他方のカメラのフレームレートよりも高いと仮定します。 InsertLineオペレータは厳密にラインを多重化、つまり入力を順番に使用します。 フレームレートの違いにより、DRAMバッファのいずれかが実際にデータをバッファリングする必要が生じます。そのFillレベルは 増加し続けます。 オーバーフロー状態が発生するとすぐに、これ以上データをバッファリングできなくなり、データが失われます。
![[重要]](../common/images/admon/important.png)
等しいデータレートの確保 したがって、非同期ストリームをマージする場合は、ラインレート、フレームレート、ピクセルレートが等しく、 同期できることを確認してください。
-
同一ソースからのデータの同期
M型オペレータの中には、結果を出力するまでに遅延が生じるものがあります。 代表的な例は、以下の図で検討するダイアグラムで使用されているFIRkernelNxMオペレータです。 このオペレータは、ピクセルとその周囲の隣接ピクセルを出力してカーネルを形成します。 隣接ピクセルを出力するために、オペレータはそれら(必要な隣接ピクセル)が入力で利用可能になるまで待機する必要があります。 中間結果が保存されます。 私たちの例では、FIRkernelNxMオペレータは、4つのフルラインがオペレータに入力されて初めて最初の結果を出力できます。 したがって、このオペレータは現在の構成で4画像ラインの遅延を生成します。
この例をさらに詳しく見ていきましょう。
前提条件
最初のピクセルはカメラからバッファを経由してブランチに送信されます。 ここで、データが複製され、SYNCおよびFIRkernelNxMモジュールに転送されます。 説明したように、FIRkernelNxMには4ラインの遅延があるため、最初のピクセルをすぐに出力することはできません:
デッドロック
SYNCオペレータは両方の入力を同期しようとします。 2番目の入力からデータが送信されないため、最初の入力でSTOPシグナルが生成されます。 このSTOPシグナルはパイプライン内をバッファまで逆方向に伝播します。 これでデッドロック状態が発生します: カーネルオペレータはデータを出力するためにさらにデータを必要としますが、SYNCがこれ以降の入力をすべてブロックしているため、新しいデータを利用できません。
デッドロックの修正
デッドロックを解決するには、上側のパスにバッファを追加して、以下に示すようにカーネルオペレータの遅延を補償する必要があります:
デッドロックの回避
最善の解決策は、同期を完全に回避することです。多くの場合、これが可能です。 以下の解決策の例では、ダイアグラム内にM型オペレータのシリアルパイプラインのみが存在するため、マージ時の同期は必要ありません。
M型ネットワークにおけるもうひとつの重要な現象は、オペレーターにおける帯域幅の減少と、それに伴うモジュールのネットワーク内でのこの制限の逆方向への伝播の可能性です。 次の図は、帯域幅制限を発生させるダイアグラムを示しています。
このダイアグラムでは、ModuloCountとRemoveLineの各オペレーターの組み合わせにより、2行おきに削除が行われます。 「アプレットの帯域幅」からわかるように、最大帯域幅は使用するParallelismに依存します。 RemoveLineオペレーターの通過後、必要な帯域幅は半分に削減されます。 そのため、PARALLELdn(「Parallel down」)オペレーターを使用してParallelismを半分に削減できます。 しかし、これにより、2行ごとに上流パスの帯域幅も半分に削減されます。
RemoveLineオペレーターで1行が削除される間、PARALLELdnモジュールにはピクセルが供給されません。 ダイアグラムの入力で指定された完全なParallelismを両方のパスで使用できます。 対照的に、RemoveLineオペレーターによって行が削除されない場合、現在の行のピクセルはPARALLELdnの入力に転送されます。 ここでPARALLELdnはParallelismを2分の1に削減します。つまり、入力と比較して、値を出力するのに2倍のサイクル数が必要になります。 したがって、PARALLELdnオペレーターは、2クロックサイクルごとにその入力をブロックします。 最初のBranchとPARALLELdnオペレーターの間にバッファが使用されていないため、このブロック信号はパイプライン内を逆方向に伝播します。 そのため、上流パスも2クロックサイクルごとにブロックされます。
この問題の解決策は、最小で1行分のバッファリングが可能な追加のFIFOをPARALLELdnオペレーターの前に追加し、ピーク期間とアイドル期間を補償することです。 次の図はこの解決策を示しています。
P型オペレーターは、1つの例外を除き、M型オペレーターと似ています。 それらは入力を能動的にブロックできません。
それにもかかわらず、処理パイプラインの上流にあるモジュールが入力をブロックすると、入力のブロックがラインに沿って逆方向に伝播します。P型オペレーターが下流に配置されている場合、P型オペレーターの入力ポートも(受動的に)ブロックされます。P型オペレーターは、ブロック情報を処理パイプラインの下流にある次のモジュールへと逆方向に伝播させます。
例: M型オペレーターのPARALLELdnは、オペレーターにデータが供給される時間と比較して、結果を出力するのにより多くの時間を必要とします。 そのため、随時入力をブロックします。 これに対し、P型オペレーターのPARALLELupは、入力帯域幅と比較して、常に出力側で高い帯域幅を持ちます。 この動作は、無限ソースをP型およびM型オペレーターに接続する際に非常に重要です。 無限ソースの詳細な説明については、次の「無限ソース / カメラの接続」を参照してください。
無限ソースとは、VisualAppletsのフロー制御によって停止できないオペレーターのことです。 一例としてカメラオペレーターが挙げられます。 これらのオペレーターは、入力リンクでカメラからデータを受信します。出力リンクでは、このデータをダイアグラム内の後続のモジュールに転送します。 カメラオペレーター内にはバッファがなく、カメラに転送の停止を指示することもできないため、これらのオペレーターは無限ソースとなります。
停止可能および停止不可能なデータストリームに関する実践的なガイダンスについては、 停止可能および停止不可能なデータストリームのチュートリアルのトピックを参照してください。
無限ソースは、無限ソースを受け入れるM型オペレーターにのみ接続できます。 個々のM型オペレーターを無限ソースに接続できるかどうかは、そのオペレーターのそれぞれのドキュメントに記載されています(オペレーターリファレンスを参照してください)。 無限ソースを受け入れないM型オペレーターに無限ソースが接続されている場合、DRCレベル2によってエラーが生成されます。
すべてのP型およびO型オペレーターを無限ソースに接続できます。 無限ソースの情報は、パイプライン内のオペレーターが無限ソースのデータストリームを制御可能なデータストリームに変換するまで、オペレーターを伝播します。 通常、これらの変換オペレーターはバッファです。 バッファオペレーターは、出力でフロー制御を使用することができ、入力をブロックすることなく入力データストリームをバッファリングします。
したがって、前の例のオペレーターを入れ替えた場合、DRCレベル2はエラーを生成しません。
一部の変換オペレーターの動作は、無限ソースを受け入れるかどうかを変更できます。 これらのオペレーターにはInfiniteSourceというパラメーターが含まれており、これをEnabledまたはDisabledに設定できます。
無限ソースに接続されていない変換オペレーターは、必ずDisabledに設定する必要があります。
![]() |
警告 |
|---|---|
|
それぞれのモジュールのパラメーターInfiniteSourceがEnabledに設定されている場合、そのモジュールは無限ソースに接続されている必要があります。 無限ソースに接続されていない変換オペレーターは、Disabledに設定する必要があります。 |
![]() |
ヒント |
|---|---|
|
確信がない場合は、必ずパラメータをDisabledに設定し、DRCレベル2チェックの後に不具合のあるモジュールを変更してください。 |
モジュールのパラメータ設定の詳細については、「Module Properties」を参照してください。
シグナルリンクは、すべてのクロックサイクルで有効な1ビットの信号データを伝送します。 sシグナル伝送入力リンクを持つモジュールのリンク規則は、これまでに説明したリンク規則とは以下の2点で異なります。
-
シグナルリンク入力を備えたすべてのO型およびM型モジュールは、異なるM型ソースからソース供給を受けることができます。
-
シグナルリンク入力を備えたモジュールは、常に無限ソースに接続できます。
シグナルリンクの詳細については、「Image Protocols, Image Dimensions and Data Structure」を参照してください。
この章では、リンクの規則について紹介しました。 リンクの規則は、VisualAppletsアプリケーションを実装する際に最も重要となります。
O型ネットワークは常にM型モジュールで始まり、M型モジュールで終わります。 各O型モジュールは、他のO型モジュールの任意のネットワークを介して、同じM型またはP型モジュールからソース供給を受ける必要があります。 異なるM型ソースのマージは、M型モジュールによってのみ実行できます。
M型ネットワークは、シリアルシーケンスで任意にリンクすることも、任意に分岐させることもできます。 モジュール内での異なるM型ソースのマージには、タイミング同期と画像寸法同期が必要です。 複数の入力を備えたM型モジュールは、同期入力グループを持つことができます。 同期入力グループは、任意のO型ネットワークを介して同じM型ソースからソース供給を受ける必要があります。
タイミング同期は、タイミングが遅延している異なるソースを同期させます。 タイミング同期には、ユーザー実装に関する知識が必要です。 タイミング同期が不適切であると、デッドロックやバッファオーバーフローが発生します。
無限ソースは、統合されたフロー制御によって制御することはできません。 無限ソースへの接続が許可されているM型オペレーターのみが、無限ソースに接続できます。
シグナルリンク入力を備えたモジュールには、2つの変更点を伴う一般的な同期規則が適用されます。 シグナルリンク入力(M型およびO型モジュール)は、異なるM型ソースからソース供給を受けることができます。 シグナルリンク入力を備えたモジュールは、常に無限ソースに接続できます。
![]() |
警告 |
|---|---|
|
VisualAppletsはユーザープロジェクトの実装に依存するため、論理的な同期エラーを検出することはできません。 タイミングと遅延における動作については、各M型オペレーターのマニュアルを注意深くお読みください。 |







![[ヒント]](../common/images/admon/tip.png)






![[Warning]](../common/images/admon/warning.png)











前へ

