인피니언 TC3xx EVADC 개념 정리 - 1편 (EVADC 개요, 트리거, Queue)

아래 글은 인피니언의 ADC 변환법 중 EVADC를 다룬다. 내용은 TC3xx User Manual을 기반으로 한다. 중요한 부분과 흐름을 파악할 수 있는 부분 위주로 정리하고자 한다. 개인적인 이해 방식이 담겨있다.

 

EVADC란?

인피니언 사에서는 EVADC(Enhanced Versatile Analog-to-Digital Converter)로 정의하는 기능이 있다. SAR (Successive Approximation Register) 원리를 통해 아날로그 값(전압)을 디지털 값으로 바꿔주는 기능이다.

 

ADC에서는 각각 컨버터라고 하는 변환 장치가 있는데, 이는 '독립적'으로 동작하며 값을 변환한다. 컨버터 내에는 각각의 채널이 있다. 예를 들어 각 채널에는 온도 센서, 압력 센서 등이 각각 연결되어있다. 이러한 채널들은 각각 정해진 결과 레지스터(디지털 값으로 변환된 결과)와 그룹 차원의 레지스터에 영향을 받는다.

 

크게 보면, 클러스터 - 컨버터 - 채널로 구성되었다고 보면 된다. 

 

TC3XX에는 크게 3가지의 클러스터가 존재한다.

- Primary converter cluster: 8:1 멀티플렉서, 큐 8개, 0.5us 미만의 변환 시간

- Secondary converter cluster: 16:1 멀티플렉서, 큐 16개, 1us 미만의 변환 시간

- Fast compare cluster: 각각 하나의 채널, 0.2us만큼의 업데이트 시간

이러한 특징을 보고 채널들을 어디에 배치할지 고민해 볼 필요가 있다.

 

EVADC 특징은 아래와 같은데, 이해가 되지 않는 부분은 넘어가고 간단히 훑어보기만 해도 된다.

- 공급 전압은 5V이거나 3.3V

- 각 채널마다 Vref로 레퍼런스 전압을 사용하거나 CH0를 사용할 수 있음.

- arbitrary conversion sequence를 설정할 수 있음. 즉 변환 순서를 정의할 수 있음.

- 변환을 트리거하는 방법은 software, timer events, or external events가 있다.

이 때 external events는 예를 들어 pwm 신호의 falling edge, rising edge 등이 된다.

- Cancel-inject-restart 모드가 가능하다. (변환 중간에 우선 순위가 높다면 취소하고 먼저 변환 가능하다)

 

EVADC 개요

개요사진을 보도록 하자. ADC Kernel로 표현되어있다. 사실 큰 의미보다도 위 캡처의 요소를 가지고 ADC 변환을 수행하는 단위를 ADC Kernel로 정의하고 있다.

An ADC kernel is a unit used to convert an analog input signal into a digital value and provides means for triggering conversions, data handling and storage. (Understanding XC2000/XE166 ADC)

 

위 캡처의 몇 가지 특징만 살펴보자.

- AD converter: 실제 변환을 수행하는 변환기이다. 여기에 VAREF와 VAGND가 연결되어있다. 각각의 채널은 Analog input channels CHx로 각각 들어온다. 이 채널들이 묶이면 Group이 된다.

- Result handling: AD converter를 통해 실제 변환된 내용은 Result handling을 통해 저장된다. 변환된 결과값을 레지스터에 저장하는 등의 역할을 수행한다.

- Request control: 여러 채널에서 변환 요구가 있을 때 Arbiter를 통해 중재하여 하나의 요구를 AD Converter에 전달한다.

- Conversion control: AD converter가 어떻게 변환할지 설정하는 역할을 합니다. 예를 들어 VAREF를 쓸지, 다른 전압 채널을 레퍼런스로 할지, 변환을 한다면 샘플 타임은 얼마로 할 것인지 등등을 정의합니다.

 

이 정도만 보더라도 대략적인 구조를 이해할 수 있으므로 다음으로 넘어가도록 하자.

 

변환 요청 생성 (Conversion Request Generation)

트리거와 트리거 종류

AD Conter에게 변환 요청을 해야 ADC 작업이 이루어지게 된다. 그러면 어떤 방식으로 요청이 되는가? 3가지 방식이 있다.

- Software trigger: Software가 직접적으로 요청함.

- Self-timed trigger: 요구 시간에 따라 요청함.

- External trigger: 외부 신호에 따라 요청함. e.g. PWM 신호 또는 port pin에서의 신호

위는 트리거에 대한 세 가지 종류이고, 트리거에 의해 실제 요청되는 단위를 Request source라고 한다.

어플리케이션 소프트웨어에서 셋 중 어떤 트리거를 사용할지, 어떤 변환 요청을 선택할지, 어떤 채널을 변환할지, Request source간 우선 순위는 어떻게 할지 결정한다.

 

변환 요청 모드

각 변환 요청은 single-shot 모드 또는 continuous mode로 동작한다.

- single-shot mode: 정해진 변환 순서가 트리거 될 때마다 한 번씩 변환 요청되는 것이다. 그 이후에는 다시 트리거를 해야 변환이 이루어진다.

- continuous mode: 정해진 변환 순서가 자동적으로, 반복적으로 변환 요청된다. 한번만 트리거되면 된다.

 

Queued Request Source의 특징

Queue 구조

실제 요청들은  바로 수행되는 것이 아니라 Queue 형태로 담기게 된다. Queue는 자료 구조에서 쓰이는 방식으로, 먼저 들어온 게 먼저 나가는 형식을 가지고 있다. 즉, 먼저 들어온 요청 순으로 Queue에 담겼다가 먼저 요청되는 식이다. 위에서 살펴 본 Primary cluster는 8 stage의 queue를 가지고 있고, Secondary cluster는 16 stage의 queue를 가지고 있다.

 

Queue가 사용되는 방식

각 queue에는 채널 번호가 담기게 되고, stage 0에서 다음으로 변환될 채널을 정의한다. 그리고 각 queue에서의 변환 요청들은 Request source arbiter로 전달되고 arbiter가 실제 요청들에 대해 중재하는 역할을 한다. 하나씩 요청되어야하기 때문이고, 순서와 우선순위 등을 따지게 된다.

 

만약 다른 우선 순위 높은 요청 때문에 기존 변환이 취소되면 backup stage로 갔다가 다시 그 다음 arbitration (중재)에 참여한다.

 

트리거와 Queue의 관계

조금 더 설명해보면, 트리거 이벤트는 software(e.g. software trigger)나 hareware(e.g. external trigger)를 통해 생성되고, 발생하고 나면 queued sequence (queue에 담긴 요청)이 실행된다. 

 

트리거되면 QSRx.EV에 값이 1로 올라오고, 변환이 시작되며 QMRx.CEV를 통해 QSRx.EV 값이 클리어된다.

 

트리거와 게이트 시그널

각 요구(source)는 트리거에 의해 시작된다. 그리고 게이트 시그널에 의해 제어될 수 있다. 게이트 시그널은 동작을 말그대로 on/off하는 게이트 역할을 하며 off인 경우 트리거가 되더라도 요청이 수행되지 않는다. 게이트 시그널은 다양한 종류가 있어 TC3xx 제품에 따라 선택할 수 있는 옵션이 다르다. GTSEL을 변경하여 게이트 종류를 선택할 수 있다.

트리거와 게이트 시그널

여기까지만 하더라도 어느 정도 흐름을 파악하기에는 충분하다. 다음 장에서는 중재(Arbitration)과 결과 처리(Result handling)에 대해 알아보도록 하겠다.