VisualApplets
사용자 매뉴얼

먼저, 작업하게 될 다양한 유형의 오퍼레이터에 대해 살펴보겠습니다.

오퍼레이터 유형 및 동기화에 대한 실용적인 지침은 Operator Types and Synchronization 튜토리얼 항목을 참조하십시오.

VisualApplets에는 세 가지 유형의 오퍼레이터가 있습니다.

오퍼레이터의 모양을 통해 범용 “O” 유형에 속하는지, 아니면 더 복잡한 “M” 또는 “P” 유형 중 하나에 속하는지 확인할 수 있습니다. (특정 오퍼레이터의 유형에 대한 정보는 Operator Reference에서 해당 오퍼레이터에 대한 문서를 확인하십시오.)

O-type 오퍼레이터의 기능은 비교적 단순합니다. 따라서,

M-type 오퍼레이터의 기능은 더 복잡합니다.

P형 연산자는 M형 연산자와 유사하지만,

이하에서는 P-type 오퍼레이터에 대한 예외가 언급되지 않는 한, M-type 오퍼레이터에 대해 정의된 모든 규칙이 P-type 오퍼레이터에도 적용됩니다.

O-type 네트워크는 O-type 모듈의 조합입니다. O-type 네트워크에서 모듈은 직렬뿐만 아니라 병렬로도 결합될 수 있습니다. O-type 네트워크는 항상 M-type 또는 P-type 모듈로 시작하고 끝납니다. 이 정의를 바탕으로 다음과 같은 중요한 규칙을 도출할 수 있습니다.

다음 그림은 모듈의 병렬 및 직렬 연결을 포함하는 O-type 네트워크를 보여줍니다. 보시다시피 모든 O-type 모듈은 동일한 M-type 모듈(M_source)로부터 소스를 공급받습니다.

대조적으로, 다음 그림은 ADD 모듈이 서로 다른 M-type 모듈(M_source_0 및 M_source_1)로부터 소스를 공급받으므로 O-Type Network Rule을 위반하는 O-type 네트워크를 보여줍니다.

VisualApplets(버전 2.2 이상)은 동기화 규칙을 위반할 때마다 디자인 다이어그램에 직접 안정적으로 표시해 줍니다. 해당 링크는 보라색으로 강조 표시됩니다. 링크는 올바르게 동기화되지 않은 데이터를 수신하는 오퍼레이터부터 해당 M 오퍼레이터 소스까지 강조 표시됩니다.

DRC 1 및 DRC 2에 해당 경고가 표시됩니다.

예를 들어, 위의 디자인에 대해 DRC 1은 다음과 같은 경고를 생성합니다.

M-type 모듈이 소스 및 목적지로만 사용되는 것이 아니라 이미지 처리를 위해 중간에도 포함되는 모든 모듈 네트워크를 M-type 네트워크라고 합니다. M-type 네트워크에서는 M-type 모듈을 직렬뿐만 아니라 병렬로도 연결할 수 있습니다. 또한 M-type 모듈은 제한 없이 분기할 수 있습니다. M-type 모듈의 병렬 연결에는 이미지 치수 동기화 및 타이밍 동기화가 필요할 수 있으므로 M-type 네트워크는 꽤 복잡해질 수 있습니다. (참고: M-type 모듈은 입력과 출력 사이의 픽셀/데이터 수를 변경할 수 있으며 출력을 지연시킬 수도 있습니다.)

다음 그림은 M-type 네트워크의 매우 간단한 예를 보여줍니다. 이 다이어그램의 M-type 모듈은 직렬로만 연결되어 있거나 분기되어 있습니다. 다이어그램의 유일한 O-type 네트워크도 동일한 M-type 모듈(ImageBuffer)로부터 소스를 공급받으므로, 다이어그램은 지금까지 알고 있는 모든 다이어그램 규칙을 따릅니다.

대부분의 경우 M-type 네트워크는 훨씬 더 복잡합니다. 위의 예와 달리 M-type 모듈이 병렬로 연결되어 있는 경우 (즉, 병합되는 경로가 서로 다른 M-type 소스에서 소스를 공급받는 경우), 타이밍과 이미지 치수를 동기화해야 합니다. 이는 여러 입력을 사용하는 M-type 오퍼레이터에 의해 수행됩니다.

서로 다른 M-type 소스에서 소스를 공급받는 네트워크를 병합하려면 여러 입력을 사용하는 M-type 오퍼레이터를 사용해야 합니다. (위에서 설명한 O-type 네트워크 규칙을 위반하므로 여러 입력을 사용하는 O-type 오퍼레이터는 사용할 수 없습니다.) 그러나 동기화에 대해 자세히 알아보기 전에 먼저 여러 입력을 사용하는 M-type 오퍼레이터에 대해 살펴보겠습니다.

여러 입력을 사용하는 M-type 오퍼레이터는 두 가지 종류의 입력을 가질 수 있습니다.

동기식 입력 및 동기식 입력 그룹

모듈의 일부 입력이 동기식인 경우, 이러한 동기식 입력들은 하나의 동기식 입력 그룹을 형성합니다. 따라서 동기식 입력 그룹은 동기식 입력들의 집합입니다. 동기식 입력 그룹의 입력은 항상 임의의 O-type 오퍼레이터 네트워크를 통해 동일한 M-type 소스에서 소싱되어야 합니다. M-type 오퍼레이터는 임의 개수의 동기식 입력 그룹을 가질 수 있습니다.

아래 그림에서 동기식 입력 그룹이 있는 M-type 오퍼레이터 사용 예를 볼 수 있습니다. RemoveImage 오퍼레이터의 두 입력 모두 동일한 M-type 오퍼레이터(ImageBuffer)에서 소싱됩니다. 두 입력이 함께 동기식 입력 그룹을 형성합니다. RemoveImage 오퍼레이터는 입력 포트에 서로 다른 M-type 소스를 사용하는 것을 허용하지 않습니다.

비동기식 입력

비동기식 입력은 동기화되지 않습니다. 이는 임의의 O-type 오퍼레이터 네트워크를 통해 서로 다른 M-type 오퍼레이터에서 소싱될 수 있습니다. 또한, 여러 입력을 가진 일부 M-type 오퍼레이터는 실제로 서로 다른 M-type 오퍼레이터에서 소싱되어야 합니다. 여러 입력을 가진 M-type 오퍼레이터가 서로 다른 M-type 오퍼레이터에서 소싱되어야 하는지 여부는 오퍼레이터 자체의 기능에 따라 다릅니다. 모든 오퍼레이터에 대한 자세한 정보는 Operator Reference에서 확인할 수 있습니다. M-type 오퍼레이터는 임의 개수의 비동기식 입력을 가질 수 있습니다.

다음 스크린샷은 두 개의 비동기식 입력을 가진 M-type 오퍼레이터의 일반적인 예를 보여줍니다. SYNC 모듈의 두 입력 모두 각각 DRAM0 및 DRAM1인 서로 다른 M-type 소스에서 소싱됩니다.

SYNC 모듈 다음에는 MergePixel 오퍼레이터가 옵니다. 이 오퍼레이터는 중간에 SYNC 오퍼레이터 없이 두 개의 M-type 소스를 병합하는 데 사용할 수 없습니다.

여러 입력을 가진 각 M-type 오퍼레이터에 대한 설명서에서는 해당 오퍼레이터에 대해 가능하거나 필요한 입력에 대해 자세히 설명합니다. 모든 오퍼레이터에 대한 포괄적인 설명은 Operator Reference를 참조하십시오.

M-type 오퍼레이터는 입력에서 서로 다른 이미지 차원을 동기화할 수 있습니다. 중요한 예 중 하나는 SYNC 오퍼레이터입니다. 이 오퍼레이터에 대한 자세한 설명은 Operator Reference를 참조하십시오.

O-type 네트워크의 경우 VisualApplets가 자동으로 타이밍 동기화를 수행합니다.

M-type 네트워크의 경우 M-type 오퍼레이터가 동기화를 수행해야 합니다.

타이밍 동기화가 올바르게 설계되지 않은 경우,

다음 예제에서는 타이밍 동기화에 대해 자세히 살펴보겠습니다.

M-type 네트워크의 또 다른 중요한 현상은 연산자 내에서의 대역폭 감소와 함께 이러한 제한이 모듈 네트워크에서 역방향으로 전파될 수 있다는 점입니다. 다음 그림은 대역폭 제한을 생성하는 다이어그램을 보여줍니다.

이 다이어그램에서는 ModuloCount 및 RemoveLine 연산자의 조합이 두 번째 라인마다 삭제합니다. 'Bandwidth of an Applet'에서 알 수 있듯이, 최대 대역폭은 사용된 Parallelism에 따라 달라집니다. RemoveLine 연산자 이후에 필요한 대역폭이 2배로 감소했습니다. 따라서 PARALLELdn ("Parallel down") 연산자를 사용하여 Parallelism을 2배 줄일 수 있습니다. 그러나 이로 인해 두 번째 라인마다 상위 경로의 대역폭도 2배로 감소하게 됩니다.

RemoveLine 연산자에서 라인이 삭제되는 동안 PARALLELdn 모듈로 입력되는 픽셀이 없습니다. 다이어그램의 입력에 주어진 전체 Parallelism은 두 경로 모두에서 사용할 수 있습니다. 대조적으로, RemoveLine 연산자에 의해 라인이 제거되지 않는 경우 현재 라인의 픽셀은 PARALLELdn의 입력으로 전달됩니다. 이제 PARALLELdn은 Parallelism을 2배 줄입니다. 즉, 입력에 비해 값을 출력하는 데 두 배의 클럭 사이클이 필요합니다. 따라서 PARALLELdn 연산자는 매 두 번째 클럭 사이클마다 입력을 차단합니다. 첫 번째 Branch와 PARALLELdn 연산자 사이에 버퍼가 사용되지 않으므로 이 차단 신호는 파이프라인을 따라 역방향으로 전파됩니다. 결과적으로 상위 경로도 매 두 번째 클럭 사이클마다 차단됩니다.

이 문제를 해결하는 방법은 PARALLELdn 연산자 앞에 최소 한 줄을 버퍼링할 수 있는 추가 FIFO를 추가하여 피크 및 유휴 기간을 보상하는 것입니다. 다음 그림은 이 솔루션을 보여줍니다.

P-type 연산자는 한 가지 예외를 제외하고는 M-type 연산자와 유사합니다. 즉, 입력을 능동적으로 차단할 수 없습니다.

그럼에도 불구하고 처리 파이프라인 상위의 모듈이 입력을 차단하면 입력 차단이 라인을 따라 역방향으로 전파됩니다. P-type 연산자가 라인 아래쪽에 위치한 경우 P-type 연산자의 입력 포트도 (수동적으로) 차단됩니다. P-type 연산자는 차단 정보를 처리 라인 아래의 다음 모듈로 역방향으로 전파합니다.

Example: M-type 연산자 PARALLELdn은 데이터가 연산자로 입력되는 시간에 비해 결과를 출력하는 데 더 많은 시간이 소요됩니다. 따라서 주기적으로 입력을 차단하게 됩니다. 대조적으로, P-type 연산자 PARALLELup은 입력 대역폭에 비해 출력 대역폭이 항상 더 높습니다. 이 동작은 무한 소스(infinite sources)를 P-type 및 M-type 연산자와 연결할 때 매우 중요합니다. 무한 소스에 대한 자세한 설명은 다음 'Infinite Sources / Connecting Cameras'에서 제공됩니다.

무한 소스는 VisualApplets 흐름 제어로 중지할 수 없는 연산자입니다. 한 가지 예는 카메라 연산자입니다. 이 연산자는 입력 링크에서 카메라로부터 데이터를 수신합니다. 출력 링크에서는 이 데이터를 다이어그램의 후속 모듈로 전달합니다. 카메라 연산자 내에는 버퍼가 없고 카메라에 전송 중지를 지시할 수 없으므로 이러한 연산자는 무한 소스입니다.

중지 가능 및 중지 불가능 스트림에 대한 실용적인 지침은 Stoppable and Non-Stoppable Data Streams 튜토리얼 항목을 참조하십시오.

무한 소스는 무한 소스를 허용하는 M-type 연산자에만 연결할 수 있습니다. 개별 M-type 연산자가 무한 소스에 연결될 수 있는지 여부는 해당 연산자의 설명서에 설명되어 있습니다(Operator Reference 참조). 무한 소스를 허용하지 않는 M-type 연산자에 무한 소스가 연결되면 DRC 레벨 2에서 오류가 발생합니다.

모든 P-type 및 O-type 연산자는 무한 소스에 연결할 수 있습니다. 무한 소스 정보는 파이프라인의 연산자가 무한 소스 데이터 스트림을 제어 가능한 데이터 스트림으로 변환할 때까지 연산자를 통해 전파됩니다. 일반적으로 이러한 변환 연산자는 버퍼입니다. 버퍼 연산자는 출력에서 흐름 제어를 사용할 수 있으며 입력을 차단할 필요 없이 입력 데이터 스트림을 버퍼링합니다.

따라서 이전 예시의 연산자를 서로 바꾸면 DRC 레벨 2에서 오류가 발생하지 않습니다.

일부 변환 연산자의 동작은 무한 소스 허용 여부에 따라 변경될 수 있습니다. 이러한 연산자에는 InfiniteSource라는 파라미터가 포함되어 있으며, 이 파라미터는 Enabled 또는 Disabled로 설정할 수 있습니다.

무한 소스에 연결되지 않은 변환 연산자는 반드시 Disabled로 설정해야 합니다.

모듈 파라미터화에 대한 자세한 내용은 'Module Properties'를 참조하십시오.

신호 링크는 모든 클럭 사이클에서 유효한 1비트 신호 데이터를 전송합니다. 신호 전송 입력 링크가 있는 모듈에 대한 링크 규칙은 지금까지 설명한 링크 규칙과 다음 두 가지 면에서 다릅니다.

신호 링크에 대한 자세한 내용은 'Image Protocols, Image Dimensions and Data Structure'에서 확인할 수 있습니다.

이 장에서는 링크 규칙을 소개했습니다. 링크 규칙은 VisualApplets 애플리케이션을 구현할 때 가장 중요합니다.

O형 네트워크는 항상 M형 모듈로 시작하고 끝납니다. 각 O형 모듈은 다른 O형 모듈의 임의의 네트워크를 통해 동일한 M형 또는 P형 모듈로부터 소스를 공급받아야 합니다. 서로 다른 M형 소스의 병합은 M형 모듈에 의해서만 수행할 수 있습니다.

M형 네트워크는 직렬 시퀀스로 임의로 링크될 뿐만 아니라 임의로 분기될 수도 있습니다. 모듈에서 서로 다른 M형 소스를 병합하려면 타이밍 동기화와 이미지 치수 동기화가 필요합니다. 입력이 여러 개인 M형 모듈은 동기화 입력 그룹을 가질 수 있습니다. 동기화 입력 그룹은 임의의 O형 네트워크를 통해 동일한 M형 소스에서 소스를 공급받아야 합니다.

타이밍 동기화는 시간적으로 지연된 서로 다른 소스를 동기화합니다. 타이밍 동기화에는 사용자 구현에 대한 이해가 필요합니다. 타이밍 동기화가 잘못되면 교착 상태나 버퍼 오버플로가 발생합니다.

무한 소스는 통합된 흐름 제어에 의해 제어될 수 없습니다. 무한 소스에 연결이 허용된 M형 오퍼레이터만 무한 소스에 연결할 수 있습니다.

신호 링크 입력이 있는 모듈의 경우, 두 가지 수정 사항을 제외하고 일반 동기화 규칙이 적용됩니다. 신호 링크 입력(M형 및 O형 모듈의)은 서로 다른 M형 소스에서 소스를 공급받을 수 있습니다. 신호 링크 입력이 있는 모듈은 항상 무한 소스에 연결할 수 있습니다.