무한 정보 시대

SOAP(Simple Object Access Protocol)는 응용 프로그램의 분산 요소가 통신할 수 있도록 하는 메시지 프로토콜입니다. SOAP는 웹 관련 HTTP (Hypertext Transfer Protocol)를 비롯한 다양한 표준 프로토콜 을 통해 수행될 수 있습니다.

SOAP는 프로그래밍 언어가 다른 응용 프로그램의 중간 언어로 개발되어 이러한 응용 프로그램이 인터넷을 통해 서로 통신할 수 있도록 합니다. SOAP는 유연하고 독립적이므로 개발자가 기능과 기능을 추가하는 동시에 다양한 언어로 SOAP API (응용 프로그래밍 인터페이스)를 작성할 수 있습니다.

SOAP는 일반적으로 XML (Extensible Markup Language)을 사용하여 웹 API를 만드는 데 사용되는 경량 프로토콜 입니다. 인터넷, HTTP, SMTP(Simple Mail Transfer Protocol) 및 전송 제어 프로토콜 을 통한 광범위한 통신 프로토콜을 지원합니다 . SOAP 접근 방식은 SOAP 메시지가 처리되는 방법, 포함된 기능 및 모듈, 지원되는 통신 프로토콜 및 SOAP 메시지 구성을 정의합니다. SOAP는 XML 정보 세트를 메시지 형식으로 사용하고 메시지 전송 및 협상을 위해 HTTP와 같은 응용 프로그램 계층 프로토콜에 의존합니다.

애플리케이션 간의 데이터 교환은 오늘날의 네트워크 환경에서 매우 중요합니다. 그러나 이러한 이기종 애플리케이션 간의 데이터 교환은 복잡할 것입니다. 이 데이터 교환을 수행하기 위한 코드의 복잡성도 마찬가지입니다.

이러한 복잡성을 해결하는 데 사용되는 방법 중 하나는 응용 프로그램 간에 데이터를 교환하기 위한 중간 언어로 XML(Extensible Markup Language)을 사용하는 것입니다.

모든 프로그래밍 언어는 XML 마크업 언어를 이해할 수 있습니다. 따라서 XML은 데이터 교환의 기본 매체로 사용되었습니다. 그러나 데이터 교환을 위한 모든 프로그래밍 언어에서 XML 사용에 대한 표준 사양은 없습니다. 그것이 SOAP 소프트웨어가 등장하는 곳입니다.

SOAP는 HTTP를 통해 XML과 함께 작동하도록 설계되었으며 모든 응용 프로그램에서 사용할 수 있는 일종의 사양을 가지고 있습니다. SOAP 프로토콜에 대한 자세한 내용은 다음 장에서 살펴보겠습니다.

SOAP의 장점

SOAP는 응용 프로그램 간의 데이터 교환에 사용되는 프로토콜입니다. 다음은 SOAP가 사용되는 이유에 대한 몇 가지입니다.

SOAP 기반 웹 서비스를 개발할 때 웹 서비스가 클라이언트 응용 프로그램과 통신하는 데 사용할 수 있는 일부 언어가 필요합니다. SOAP는 이러한 목적을 달성하기 위해 개발된 완벽한 매체입니다. 이 프로토콜은 모든 웹 표준의 관리 기관인 W3C 컨소시엄에서도 권장합니다.

SOAP는 응용 프로그램 간의 데이터 교환에 사용되는 경량 프로토콜입니다. SOAP 프로그래밍은 그 자체가 경량 데이터 교환 언어인 XML 언어를 기반으로 하기 때문에 SOAP도 같은 범주에 속하는 프로토콜입니다.

SOAP는 플랫폼에 독립적으로 설계되었으며 운영 체제에도 독립적으로 설계되었습니다. 따라서 SOAP 프로토콜은 Windows 및 Linux 플랫폼 모두에서 모든 프로그래밍 언어 기반 응용 프로그램을 작동할 수 있습니다.

HTTP 프로토콜에서 작동합니다. SOAP는 모든 웹 응용 프로그램에서 사용하는 기본 프로토콜인 HTTP 프로토콜에서 작동합니다. 따라서 World Wide Web에서 작동하기 위해 SOAP 프로토콜에 구축된 웹 서비스를 실행하는 데 필요한 일종의 사용자 정의가 없습니다.

 SOAP 빌딩 블록 및 메시지 구조 예

Simple Object Access Protocol은 사양으로 웹 서비스 및 클라이언트 응용 프로그램에 전송되는 SOAP 메시지를 정의합니다. SOAP 메시지는 다음 세 가지 기본 빌딩 블록으로 구성된 XML 문서입니다.

1.     SOAP envelop는 메시지의 모든 데이터를 캡슐화하고 XML 문서를 SOAP 메시지로 식별합니다.

2.     Header 요소는 SOAP 메시지에 대한 추가 정보를 포함합니다. 이 정보는 예를 들어 호출 애플리케이션에서 사용하는 인증 자격 증명일 수 있습니다.

3.     Body 요소에는 웹 서비스에서 호출 응용 프로그램으로 보내야 하는 실제 메시지의 세부 정보가 포함됩니다. 이 데이터에는 통화 및 응답 정보가 포함됩니다.

오류 메시지는 선택적 네 번째 빌딩 블록입니다. SOAP 오류가 생성되면 HTTP 500 오류로 반환됩니다. 오류 메시지에는 오류 코드, 문자열, 행위자 및 세부 정보가 포함됩니다.

아래의 간단한 SOAP 메시지의 예를 살펴보고 요소가 실제로 수행하는 작업을 살펴보겠습니다.

SOAP 메시지 구조

위의 SOAP 메시지에서 볼 수 있듯이 SOAP 메시지의 첫 번째 부분은 전체 SOAP 메시지를 캡슐화하는 데 사용되는 봉투 요소입니다.

다음 요소는 실제 메시지의 세부사항을 포함하는 SOAP 본문입니다.

우리 메시지에는 "Guru99WebService"라는 이름의 웹 서비스가 포함되어 있습니다.

"Guru99Webservice"는 'int' 유형의 매개변수를 허용하며 이름은 TutorialID입니다.

이제 위의 SOAP 메시지가 웹 서비스와 클라이언트 응용 프로그램 간에 전달됩니다.

위의 정보가 클라이언트 애플리케이션에 얼마나 유용한지 알 수 있습니다. SOAP 메시지는 클라이언트 애플리케이션에 웹 서비스의 이름이 무엇인지, 웹 서비스가 예상하는 매개변수와 웹 서비스에서 사용하는 각 매개변수의 유형을 알려줍니다.

SOAP는 어떻게 작동합니까?

SOAP 요청은 응답을 생성하고 처리하기 쉽습니다. 먼저 클라이언트 가 XML 문서를 사용하여 서비스 요청을 생성합니다. 다음으로 SOAP 클라이언트는 XML 문서를 SOAP 서버로 보냅니다. 서버가 SOAP 메시지를 수신하면 요청된 서버 측 애플리케이션에 서비스 호출로 메시지를 보냅니다. 클라이언트에 대한 요청된 매개변수, 반환 값 및 데이터가 포함된 응답은 먼저 SOAP 요청 핸들러에 반환된 다음 요청 클라이언트에 반환됩니다. SOAP 요청과 응답은 모두 HTTPS (Hypertext Transfer Protocol Secure) 또는 HTTP와 같은 유사한 프로토콜을 사용하여 전송됩니다.

SOAP 장점과 단점

SOAP는 서비스 지향 아키텍처( SOA ) 및 웹 서비스 사양의 필수적인 부분입니다.

SOAP의 장점은 다음과 같습니다.

·  플랫폼 및 운영 체제에 독립적입니다. SOAP는 다양한 프로토콜을 통해 수행될 수 있으므로 Windows와 Linux 모두에서 서로 다른 프로그래밍 언어를 사용하는 응용 프로그램 간의 통신이 가능합니다.

· HTTP 프로토콜에서 작동합니다. SOAP는 다양한 프로토콜과 함께 작동하지만 HTTP는 웹 응용 프로그램에서 사용하는 기본 프로토콜입니다.

· 다른 네트워크 및 보안 장치를 통해 전송할 수 있습니다. SOAP는 다른 프로토콜에 특별한 조정이 필요할 수 있는 방화벽 을 통해 쉽게 전달할 수 있습니다.

그러나 다음과 같은 단점이 있습니다.

· 참조로 데이터를 전달하는 조항이 없습니다. 동일한 개체의 여러 복사본이 동시에 전달되는 경우 동기화 문제가 발생할 수 있습니다.

·  속도. SOAP의 데이터 구조는 XML을 기반으로 합니다. XML은 대부분 사람이 읽을 수 있으므로 SOAP 메시지를 상당히 쉽게 이해할 수 있습니다. 그러나 이것은 또한 바이너리 데이터를 수용할 CORBA(Common Object Request Broker Architecture) 및 RPC (원격 프로시저 호출) 프로토콜에 비해 메시지를 상대적으로 크게 만듭니다. 이 때문에 CORBA와 RPC가 더 빠릅니다.

· 다른 방법만큼 유연하지 않습니다. SOAP는 유연하지만 RESTful 아키텍처와 같은 새로운 방법은 XML, JavaScript Object Notation , YAML 또는 필요한 모든 파서를 사용하므로 SOAP보다 유연합니다.

SOAP API

SOAP는 웹 서비스 또는 SOA 프레임워크의 컨텍스트에서 거의 항상 사용되는 프로토콜입니다. 따라서 해당 API는 일반적으로 SOA에 대한 상위 수준 인터페이스에 의해 숨겨집니다. SOA API 미들웨어 도구는 거의 모든 최신 프로그래밍 언어에 사용할 수 있으며 Microsoft는 다양한 .NET SOAP 및 SOA 도구를 제공합니다.

SOAP 대 REST

SOAP는 보안 및 제어를 잃지 않으면서 기존의 모놀리식 애플리케이션을 다중 구성 요소의 분산 형태로 분해하도록 설계되었습니다. 이와 대조적으로 REST (REpresentational State Transfer)는 HTTP 프로토콜과 웹 서버가 클라이언트를 지원하는 방식을 기반으로 하는 분산 컴퓨팅 상호 작용의 모델입니다. REST over HTTP는 거의 항상 최신 마이크로서비스 개발 및 통신의 기초입니다. RESTful API는 GET, PUT, POST 및 DELETE 데이터에 대한 HTTP 요청을 사용합니다.

REST over HTTP는 간단하고 유연하며 가벼우며 정보를 교환하는 방법 이상을 제공합니다. SOAP는 HTTP에서도 사용할 수 있지만 웹 서비스 및 SOA 프레임워크와 같은 복잡한 분산 컴퓨팅 도구 세트의 요소와 애플리케이션 구성 요소를 연결하며 이는 전체 서비스 지향 프레임워크의 일부를 형성합니다.

단순 개체 액세스 프로토콜의 미래

SOAP는 서비스 지향 아키텍처에서 웹 서비스를 연결하는 데 널리 사용되는 최초의 프로토콜입니다. 오늘날 분산 애플리케이션의 현대적인 개발은 주로 RESTful 원칙을 기반으로 합니다. SOAP는 거의 항상 레거시 플랫폼으로 제한 됩니다. SOAP가 여전히 사용되는 영역 중 하나는 온라인 트랜잭션을 처리하는 응용 프로그램입니다. 이는 더 엄격하고 프로토콜 기반의 API 스타일이기 때문입니다.

SOAP 통신 모델

SOAP에 의한 모든 통신은 HTTP 프로토콜을 통해 이루어집니다. SOAP 이전에는 많은 웹 서비스가 통신을 위해 표준 RPC(원격 프로시저 호출) 스타일을 사용했습니다. 이것은 가장 단순한 형태의 의사소통이지만 많은 한계가 있었습니다.

이제 이 SOAP API 자습서에서 이 통신이 어떻게 작동하는지 보기 위해 아래 다이어그램을 살펴보겠습니다. 이 예에서 서버가 다음과 같이 2가지 방법을 제공하는 웹 서비스를 호스팅한다고 가정해 보겠습니다.

GetEmployee – 모든 직원 세부 정보를 가져옵니다.

SetEmployee – 직원 부서, 급여 등과 같은 세부 정보 값을 적절하게 설정합니다.

일반적인 RPC 스타일 통신에서 클라이언트는 요청에 있는 메서드를 호출하고 필요한 매개변수를 서버에 보내고 서버는 원하는 응답을 보냅니다.

위의 통신 모델에는 다음과 같은 심각한 제한 사항이 있습니다.

언어 독립적 이 아님 - 메서드를 호스팅하는 서버는 특정 프로그래밍 언어로 되어 있으며 일반적으로 서버에 대한 호출은 해당 프로그래밍 언어로만 이루어집니다.

표준 프로토콜이 아님 – 원격 프로시저에 대한 호출이 이루어지면 호출은 표준 프로토콜을 통해 수행되지 않습니다. 이것은 웹을 통한 대부분의 통신이 HTTP 프로토콜을 통해 이루어져야 했기 때문에 문제였습니다.

방화벽 – RPC 호출은 일반 프로토콜을 통하지 않기 때문에 클라이언트가 서버와 통신할 수 있도록 서버에서 별도의 포트를 열어야 합니다. 일반적으로 모든 방화벽은 이러한 종류의 트래픽을 차단하며 클라이언트와 서버 간의 이러한 종류의 통신이 작동하도록 하려면 일반적으로 많은 구성이 필요했습니다.

위에 언급된 모든 제한 사항을 극복하기 위해 SOAP는 다음 통신 모델을 사용합니다.

클라이언트는 프로시저 호출 및 인수에 관한 정보를 SOAP 메시지로 형식화하고 이를 HTTP 요청의 일부로 서버에 보냅니다. 데이터를 SOAP 메시지로 캡슐화하는 이 프로세스를 마샬링이라고 합니다.

그런 다음 서버는 클라이언트가 보낸 메시지를 풀고 클라이언트가 요청한 내용을 확인한 다음 적절한 응답을 SOAP 메시지로 클라이언트에 다시 보냅니다. 클라이언트가 보낸 요청을 래핑 해제하는 방식을 디마샬링이라고 합니다.

지난 몇 년 동안 열화상 카메라는 더 저렴하고 크기가 작아졌지만 여전히 이미지 처리에 필요한 형식의 열화상을 얻기가 어렵습니다. 열화상 카메라는 야간, 안개, 우천 시에 유용합니다.

열화상 센서는 온도 맵으로 다양한 환경의 물체를 감지할 수 있습니다. 이 같은 특징은 조명 상태가 좋지 않을 때 매우 중요합니다.

적외선 스펙트럼은 일반적으로 그림 1과 같이 3개의 대기 투과 창에 해당하는 3개의 대역으로 나뉩니다.

• SWIR = ~1-2.5μm short-wave infrared

• MWIR = ~3-5μm mid-wave infrared (thermal)

• LWIR = ~7-14μm long-wave infrared (thermal)

그림 1. 적외선의 세 가지 일반적인 스펙트럼.

SWIR은 광원에서 나오는 방사선이 가시광선 영역과 유사한 방식으로 물체에 반사되기 때문에 '반사된 적외선' 영역이라고도 합니다. SWIR 이미징은 물체를 이미징하기 위해 일종의 조명이 필요하며 주변의 달빛이나 별빛과 같은 일부 빛이 있는 경우에만 수행할 수 있습니다. 사실 SWIR 영역은 실외 야간 이미징에 적합합니다. 그러므로 SWIR은 열화상 카메라에 속하지 않습니다.

열화상 카메라를 선택할 때 고려해야 할 몇 가지 요소는 다음과 같습니다.

1. 지리적 또는 기후적 요인

일반적으로 추운 기후는 LWIR을 선호하고 따뜻한 기후는 MWIR을 선호합니다.

2. 전체 대기 투과율

MWIR 시스템은 대부분의 목표 범위에서 LWIR 시스템보다 습도의 영향을 덜 받습니다. LWIR 밴드는 안개 조건에서 MWIR보다 성능이 더 좋지만 두 밴드 모두 안개와 비의 영향을 받습니다. LWIR 대역은 연기 또는 에어로졸을 통한 이미징에 MWIR보다 우수하므로 LWIR은 일반적으로 소방 응용 프로그램 및 군사 응용 프로그램에 선택되는 기술입니다.

3. 목표 온도(열 플럭스, 대비, 스펙트럼 함량)

대부분의 감시 상황(주변 온도 배경 내에서 사람 또는 차량이 감지됨)의 경우 대부분의 장면 온도에서 MWIR 대역보다 LWIR 대역에서 더 많은 플럭스(표적 및 환경 배경에서 방출되는 열 에너지)를 사용할 수 있습니다.

4. 태양광 효과

LWIR은 태양 영향을 무시할 수 있는 반면 MWIR은 태양 영향을 보기 때문에 LWIR 이미저는 낮과 밤 시간 사이에 보다 일관된 이미지를 제공합니다. 그러나 LWIR 카메라가 실제 태양에 직접 노출되어도 되는지 확인해야 합니다. 실제로 일부 저가의 비냉각식 마이크로볼로미터는 태양에 너무 많이 직접적으로 노출되면 썬번 현상이 발생할 수 있습니다.

그림 2. LWIR 및 MWIR 열화상 카메라의 일반 적용 시나리오

열화상 카메라에 대한 추가 정보

적외선 센서의 재료에는 산화바나듐(Vox), 비정질 실리콘(α -Si) 및 바륨 스트론튬 티타네이트(BST)의 세 가지 종류가 있습니다. 비냉각식 센서 생산에는 주로 Vox(FLIR) 및 α-Si(Optris)가 있으며 대부분의 연구원은 Vox가 더 높은 광전 변환 효율, 더 높은 SNR 및 강력한 광 보호 능력에 대해 더 낫다고 생각합니다. Vox 감지기는 우수한 온도 안정성, 긴 수명 및 작은 온도 드리프트를 제공합니다.

그러나 α-Si 센서가 있는 카메라는 더 저렴하고 종종 더 높은 해상도와 프레임 속도를 갖습니다.

그림 3. 적외선 센서의 다양한 재료를 사용한 열화상 비교

조합 논리에서 출력은 현재 입력의 함수입니다. 조합 설계의 예로는 멀티플렉서, 디코더, 가산기, 감산기, 코드 변환기, 인코더 및 기타 우선 순위 인코더가 있습니다. 순차 설계에서 출력은 현재 입력과 과거 출력의 함수입니다.

순차 로직

순차 로직은 ​​출력이 현재 입력과 과거 출력의 함수인 디지털 로직으로 정의됩니다. 따라서 순차 논리는 ​​이진 데이터를 보유합니다. 순차 로직 요소는 래치 및 플립플롭이며 주어진 설계 기능에 대한 순차 논리를 설계하는 데 사용됩니다. RTL 설계 엔지니어의 경우 클록 기반 논리 회로에 대한 효율적인 RTL 설계를 이해하는 것이 중요합니다. 순차 로직은 ​​복잡한 설계에서 더 많은 양의 데이터를 보유하는 데 사용됩니다. 로직은 클록의 활성 에지에서 감지합니다. 실제 응용 프로그램에서는 클록의 양의 에지 또는 클록의 음의 에지에서 감지할 수 있는 로직 회로를 설명하는 것이 항상 필수적입니다. 로직 회로는 지정된 클록 기간 동안 유한 출력을 생성해야 합니다.

다음 그림은 클럭의 포지티브 에지에 감지한 기본 순차 로직입니다. 로직의 출력은 현재 입력과 과거 출력의 함수입니다.

포지티브 레벨 감지 D 래치

D 래치에서 D는 데이터 입력을 나타냅니다. 래치는 포지티브 또는 네거티브 레벨의 클록 또는 활성화에 감지됩니다.

포지티브 레벨의 민감한 래치는 그림 8.2에 나타나 있으며 진리표 다음 표에 설명되어 있습니다.

표에서 볼 수 있듯이 래치 활성화(E)가 양의 레벨(논리 1)과 같을 경우 출력 Q는 데이터 입력 D와 같습니다. 그렇지 않으면 출력은 이전 상태(과거 출력)로 유지되며 Qn-1로 표시됩니다.

다음 그림은 타이밍 시퀀스를 보여주고 있습니다.

타이밍 시퀀스에서 출력 Q는 인에이블 입력 E가 양의 레벨과 동일한 시간 동안 데이터 입력 D와 같습니다. 인에이블 E의 음수 레벨(논리 0) 동안 D 래치는 이전 값을 유지합니다.

module d_flip_flop (input D, input LE, output reg Q );

always@(*)

begin

if (LE)
Q <= D;

end
endmodule

네거티브 레벨 감지 D 래치

네거티브 레벨에 민감한 D 래치의 진리표는 다음 표와 같으며 활성 로우 또는 네거티브 레벨에 민감한 래치 인에이블 입력(LE_n), 데이터 입력 D, 출력 Q를 갖습니다.

module d_flip_flop (input D, input LE_n, output reg Q );

always@(*)
begin
  if (~LE_n)
    Q <= D;
end
endmodule

플립플롭

플립플롭은 에지 트리거 순차 로직 요소입니다. 클록의 양의 에지 또는 클록의 음의 에지에서 트리거될 수 있습니다. 플립플롭은 캐스케이드로 연결된 포지티브 및 네거티브 레벨의 래치를 사용하여 실현할 수 있습니다. 플립플롭은 메모리 저장 요소로 사용됩니다.

ASIC 설계에서 D 플립플롭은 메모리 저장 요소로 사용되며 여기서 D는 데이터 입력을 나타냅니다.

포지티브 에지 트리거 D 플립플롭

포지티브 에지 트리거 D 플립플롭은 클록의 포지티브 에지에 감지됩니다. 실제로 Edge에 감지할 수 있는 논리 게이트는 없습니다. 포지티브 에지 감지 플립플롭은 네거티브 레벨 감지 래치와 포지티브 레벨 감지 래치를 사용하여 구현됩니다.

포지티브 에지 트리거 D 플립플롭의 논리 회로는 다음 그림과 같습니다.

네거티브 에지 트리거 D 플립플롭

네거티브 에지 트리거 D 플립플롭은 클록의 네거티브 에지에 감지됩니다.

네거티브 에지 트리거 플립플롭은 포지티브 레벨 감지 래치 다음에 네거티브 레벨 감지 래치를 사용하여 실현됩니다.

포지티브 에지 트리거 D 플립플롭의 논리 회로는 다음 그림과 같습니다.

동기 및 비동기 리셋

ASIC 설계용 RTL을 코딩할 때 해결해야 할 중요한 질문 중 하나는 비동기식 리셋을 사용할 때 또는 동기식 리셋을 사용할 때입니다. 이것은 항상 설계 엔지니어의 마음에 혼란을 야기합니다. 동기식 리셋 신호는 활성 클록 에지에서 샘플링되며 데이터 경로에 일부 로직이 있습니다. 반면 비동기 리셋 신호는 활성 클록 에지와 관계없이 샘플링되므로 데이터 경로에 리셋 관련 로직이 없습니다.

비동기 리셋을 갖는 D 플립플롭

비동기식 리셋은 데이터 경로에 리셋 관련 로직이 없고 활성 클록 에지와 상관없이 플립플롭을 초기화하는 데 사용됩니다. 플립플롭을 초기화하는 이 기술은 결함이 발생하기 쉽기 때문에 내부 리셋 신호 생성에 권장되지 않습니다. 설계자는 이 리셋 신호를 내부적으로 동기화하여 글리치를 방지하도록 주의해야 합니다.

내부 동기 리셋 신호는 순차 로직에 적용됩니다. 리셋 디어설션은 비동기식 Reset 신호의 주요 문제이며, 이 문제는 2단계 레벨 동기화 장치를 사용하여 극복할 수 있습니다. 레벨 동기화는 리셋 디어설션 중에 조건을 둘러싼 경쟁을 방지합니다.

다음 예제는 활성 로우 비동기 리셋 신호 reset_n을 사용합니다.

module d_flip_flop (input d_in, input clk, input reset_n, output reg q_out );

always@(posedge clk, negedge reset_n)

begin

if(~reset_n)
q_out <= 1'b0;

else
q_out <= d_in;

end

endmodule

동기 리셋을 갖는 D 플립플롭

동기식 리셋 기술에서 리셋 관련 로직은 데이터 경로에 포함되며 리셋은 활성 클록 에지에서 샘플링됩니다. 동기식 리셋은 글리치 또는 위험 문제가 없으므로 이 접근 방식이 설계 중에 가장 적합합니다. 이 메커니즘은 추가 동기화 회로가 필요하지 않습니다.

다음 예제는 활성 로우 동기 리셋 신호 reset_n을 사용합니다.

module d_flip_flop (input d_in, input clk, input reset_n, output reg q_out );

always@(posedge clk)
begin

if(~reset_n)
q_out <= 1'b0;

else
q_out <= d_in;

end

endmodule

블록킹 할당 사용

블로킹 할당은 (=)로 표시되며 조합 논리 설계의 기능을 설명하기 위해 절차 블록 내에서 사용됩니다.

연속 할당을 사용할 때 사용하는 (=) 할당은 블로킹과 논블로킹이 아니므로 혼동하면 안됩니다.

다음 예는 다중 할당 구문을 사용하여 디자인의 기능을 설명합니다.

module half_adder (
input a_in;
input b_in;

output sum_out;

output carry_out ) ;

assign sum_out = a_in ^ b_in;
assign carry_out = a_in & b_in;
endmodule

다음은 절차 블록에서 블로킹 할당을 사용하는 예제입니다. 상호 의존적 블로킹 할당의 순서가 올바르지 않으면 시뮬레이션 및 합성 불일치의 가능성이 있습니다.

이 예제에서는 블로킹 문의 순서로 인한 시뮬레이션 및 합성 불일치 문제가 표시됩니다. 할당을 차단하면 현재 할당이 실행되지 않는 한 다음 할당 실행이 차단됩니다.

module blocking_assignment (input a_in, output reg y1_out, output reg y2_out ) ;
always@(a_in)
begin
  y2_out=y1_out;
  y1_out=a_in;
end
endmodule

if...else 대 case 구조의 사용

케이스 구성 내 조합 설계의 경우 모든 블로킹 할당이 포함되어야 합니다!

다음 예제는 case문을 사용하여 병렬 로직을 추론하는 방법을 보여주고 있습니다. 's_in' 상태에 따라 입력 d_in[3:0] 중 하나가 출력 'y_out'에 할당됩니다. 'case' 구조를 사용하기 때문에 병렬 논리를 생성합니다.

module mux_4to1(input [3:0] d_in, input [1:0] s_in, output reg y_out) ;

always @ (*)
begin
  case (s_in)
    2'b00 : y_out = d_in[0];
    2'b01 : y_out = d_in[1];
    2'b10 : y_out = d_in[2];
    default : y_out = d_in[3];
  endcase
end
endmodule

중첩 멀티플렉서 또는 우선 순위 논리

if-else 구문을 사용하여 기능을 설명하면 합성 결과가 우선 순위 논리로 귀결됩니다. 우선 순위 논리를 설명하기 위해 if-else 구문을 사용하는 것이 좋습니다.

다음 예제는 중첩된 if-else 구성을 사용하는 4:1 mux의 기능에 대한 코딩입니다.

module mux_4to1(input[3:0]d_in, output reg y_out, input [1:0] s_in ) ;
always @ (*)
begin
  if( s_in == 2'b00)
    y_out = d_in[0];
  else if( s_in == 2'b01)
    y_out = d_in[1];
  else if( s_in == 2'b10)

y_out = d_in[2];

else

y_out = d_in[3];

end

endmodule

module decoder_2to4 ( input [1:0] sel_in, input enable_in, output wire [3:0] y_out);
assign y_out = enable_in ? ( 1 << sel_in ) : 4'b0000;

endmodule

병렬 논리 또는 디코딩 논리

디코딩 논리의 기능을 설명하는 동안 연속 할당 또는 사례 구성을 사용합니다. 둘 다 병렬 논리를 생성합니다. 챕터에서 논의된 바와 같이. 6, 디코더는 병렬 선택 입력을 가지며 병렬 출력을 생성해야 합니다.

디코더가 case-endcase 구성을 사용하여 설명된 경우. 그런 다음 병렬 논리도 추론합니다. Assign 및 case-endcase를 사용하여 디코더 구현을 위해 추론된 논리는 그림 7.11에 나와 있습니다.

//Decoder using ‘case-endcase’
module decoder_2to4 (input [1:0] sel_in, input enable_in, output reg [3:0] y_out ) ;

always @ (*)
begin
  if (enable_in)
    case (sel_in)
      2'b00 : y_out = 4'b0001;
      2'b01 : y_out =4'b0010;
      2'b10 : y_out =4'b0100;
      default : y_out =4'b1000;
    endcase
  else
    y_out = 4'b0000;
end
endmodule

case 구성에서 누락된 기본 조건

case-endcase 표현식을 사용하는 동안 모든 조건이 포함되지 않으면 설계에 의도하지 않은 래치가 발생합니다. 디자인 기능에 모든 케이스 조건이 지정되지 않은 경우 디폴트문을 사용하는 것이 좋습니다. 기본값이 누락되고 모든 조건이 포함되지 않은 경우 합성 도구는 누락된 케이스 조건으로 경고를 깜박이고 의도하지 않은 래치가 있는 로직를 유추합니다.

module decoder_2to4 (input [1:0] sel_in, input enable_in, output reg [3:0] y_out );

always @ (*)

begin
if (enable_in)
  case (sel_in)
    2'b00 : y_out = 4'b0001;
    2'b01 : y_out =4'b0010;
    2'b10 : y_out =4'b0100;
  endcase
else
  y_out = 4'b0000;

end

endmodule

else 조건이 없는 중첩된 if...else

표시된 대로 4:1 mux 기능은 중첩된 if-else를 사용하여 설명되지만 else 조건이 없기 때문에 의도하지 않은 래치로 4:1 mux를 유추합니다. RTL 디자인에 else 조건을 통합하여 의도하지 않은 래치를 피하는 것이 좋습니다.

다음은 로직이 의도하지 않은 래치를 생성하는 예를 보여주고 있습니다.

module mux_4to1_else_mising (output reg y_out, input [3:0] d_in, input [1:0] s_in );

always @ (*)
begin
  if( s_in == 2'b00)
    y_out = d_in[0];
  else if( s_in == 2'b01)
    y_out = d_in[1];
  else if( s_in == 2'b10)
    y_out = d_in[2];
  else if (s_in == 2'b11)
    y_out = d_in[3];
end
endmodule

논리적 등식 대 케이스 평등

논리적 등식(==) 및 논리적 부등식(!=) 연산자는 합성 가능한 설계에 사용되는 반면, 대/소문자 등호(===) 및 대소문자의 부등식(!==)은 합성 가능한 설계에서 권장되지 않습니다.

논리적 등식과 논리적 부등식 연산자

1. 합성 가능한 디자인에 사용 권장

2. 피연산자 중 하나라도 x 또는 z 값을 갖는 경우 결과는 미지수(x)이며 논리적 비교 결과는 거짓으로 귀결됩니다.

3. 피연산자 중 하나에 x 또는 z 값이 있는 경우 비교 결과가 비결정적입니다.

다음은  a_in을 b_in과 비교하는 예제입니다. 여기에서 피연산자 중 하나에 x 또는 z 값이 있으면 else 절이 실행되고 else 조건에 지정된 논리를 유추합니다.

always@(a_in, b_in)
begin
  if (a_in==b_in)
    y_out= a_in ^b_in;
  else
    y_out =a_in &b_in;
end
//For either of a_in, b_in has ‘x’ or ‘z’ value then the result is y_out=a_in & b_in;

대소문자 동등 연산자와 대소문자 불일치 연산자

1. 합성이 불가능한 디자인에 사용 권장

2. 피연산자 중 하나에 x 또는 z 값이 있는 경우 결과는 알려진 값이고 결과는 참 또는 거짓입니다.

3. 피연산자 중 하나에 x 또는 z 값이 있는 경우 비교 결과가 결정적입니다.

다음은 a_in을 b_in과 비교하는 예제입니다. 여기서 피연산자 중 하나가 x 또는 z 값이면 a_in이 b_in과 같으면 if 절이 실행되고 if 조건에 지정된 논리를 유추합니다.

always@(a_in, b_in)
begin
  if (a_in===b_in)
    y_out= a_in ^b_in;
  else
    y_out =a_in &b_in;
end
//For either of a_in, b_in has ‘x’ or ‘z’ value then the result is y_out=a_in ^ b_in;

여러 드라이버 할당

연속 할당을 사용하는 동안 동일한 네트(와이어)가 여러 표현식에 의해 구동되는 경우 합성 도구는 '다중 드라이버 할당' 오류를 깜박입니다.

유사하게, 동일한 'reg' 변수가 여러 절차 블록 내에서 다른 표현식에 의해 구동되면 다중 드라이버 오류가 발생합니다.

wire y_tmp;
assign y_tmp = a_in ^ b_in;
assign y_tmp = a_in & b_in;
//in this example y_tmp is assigned by using ‘xor’ and ‘and’ at a me and hence mulple driver assignment error.