(본 글의 모든 저작권은 하제소프트가 가지고 있습니다)

1. USB 2.0 LPM(Link Power Management)

그림 1. USB 2.0 전체 구성도

그림1 USB 2.0 전체 구성도

[그림 1]을 보면, USB 2.0은 크게 Host와 Physical Device간의 연결을 정의하고 있다. 이들 각각은 자신들 내부에 또다시 3가지 역할을 담당하는 수직적인 계층을 설계하고 있다.

Host에서는 Client SW, USB System SW 그리고 USB Bus Interface 이고, Physical Device에서는 이에 대응하는 Function, USB Logical Device 그리고 USB Bus Interface 가 그것이다.

이와 같은 각각의 모듈들은 서로 유기적으로 USB 프로토콜을 지원하기 위하여 저마다 알고리즘을 사용한다. 하지만, 호스트와 디바이스는 USB 허브(포트)에 의해서 연결되어 있다. 정확하게 이야기하면, USB 허브(Downstream Port)와 디바이스(Upstream Port)간의 연결(Link)이라고 보아야 한다. 이들 포트들간의 연결을 고려하는 프로토콜이 필요한 것이다.

USB 2.0에서는 이들 포트들간의 프로토콜을 별도로 지원하고 있는데, 이것이 USB 2.0 LPM(Link Power Management) Packet이다. 아직까지 USB 2.0에서는 이런 연결(Link)을 본격적으로 고려하기에는 시기상조라고 여겨서인지 조금은 소극적인 방법으로 이런 LPM을 지원하고 있다. 이들에서 알 수 있듯이 이 패킷은 전력소비와 관련된 요청과 파라미터를 담는다.

그림 2. USB 2.0 LPM Power States

그림2 USB 2.0 LPM Power State

[그림 2]를 보면, LPM에서 규정하는 파워상태는 모두 4가지로, L0부터 L3까지이다. 이들은 링크의 파워공급상태를 크게 4가지로 규정하고 있다. 이중 L0상태가 가장 파워공급이 원활한 상태이며, L3상태는 파워가 끊어진 상태이다.

허브의 Downstream Port와 디바이스의 Upstream Port간의 연결(Link)은 이와 같이 총 4가지 파워공급상태를 가질 수 있다. [그림 3]은 이해를 돕고자 이런 파워상태의 변화를 나타내고 있다.

그림 3. LPM State Transition Diagram

그림3 LPM State Transition Diagram

각각의 파워상태의 변화는 [그림 3]에서 알 수 있듯이 여러 가지 사건들(이벤트)에 의해서 발생된다.  USB 2.0에서는 이와 같은 LPM을 정의해서 운용할 수 있기 위해서 기존에 사용하던 Token Packet의 약간의 변형을 요구할 수 밖에 없다.

그림 4. USB 2.0이 사용하는 Packet의 종류

그림4 USB 2.0 이 사용하는 Packet의 종류

[그림 4]에서 마지막에 표기된 Reserved로 예약된 값(2진수 0000)이 LPM에 사용될 수 밖에 없다.

Token Packet의 PID값을 이와 같이 Reserved(LPM에서는  EXT PID로 명명한다)값으로 사용하게 되면, 특별히 이 값을 가진 패킷다음에 이어지는 또 다른 확장된 Token Packet을 기대하게 된다.

그림 5. EXT PID와 Sub PID

그림5 EXT PID와 Sub PID

[그림 5]에 나타나있는 내용을 보면, 실제로 LPM에서는 Sub PID값으로 2진수 0011 만 사용하고 있다.

그림 6. LPM Sub PID 와 함께 사용되는 variable값

그림6 LPM Sub PID와 함께 사용되는 variable값

예를 들어 L0상태에서 L1상태로 링크상태를 변경하려는 경우, 허브의 Downstream Port는 장치의 Upstream Port측으로 LPM패킷을 보낸다. 이때, [그림 6]에서 bLinkState값은 2진수 0001 값을 사용한다.

이와 같은 LPM 지원은 USB 2.0에서 포트들간의 연결(Link)을 다루는 데 있어서, 전원공급상태에만 국한하고 있는 소극적인 지원이라고 볼 수 있다.

결론적으로 USB 2.0 LPM은 다음과 같은 요구사항을 만족시키지 못했다.

* 포트들간의 연결상태에 있어서, 전원공급문제외에 플러그엔플래이, 에러, 초기화등과 같은 모든 상태문제를 고려하지 못했다.

* 포트들간의 연결상태를 위해서 별도로 고안된 명령패킷이 존재하지 않는다(기존의 Token Packet형태를 빌려 사용하고 있다)

 

이와 같은 요구사항을 모두 만족하기 위해서 특별히 고안된 상태다이아그램이 필요했다. 이것이 LTSSM이다. LTSSM은 PCI Express, USB 3(USB 3.x)과 같은 고속 시리얼버스를 사용하는 프로토콜에서 현재 채택하고 있는 링크관리프로토콜이다.

 

2. LTSSM( Link Training and Status State Machine)

그림 7. LTSSM 도식도

[그림 7]을 보면 LTSSM에서 정의하고 있는 상태(동그라미로 둘러싼 부분)와 이벤트(사건)의 종류는 어떤 이벤트에 의해서 어떤 상태로 변이가 이루어질 수 있는지를 설명하고 있다.

혹자는 이것이 USB 3 프로토콜의 전부인가라는 질문을 던질 수 있다.(이것은 아마도 그림이 주는 부담감때문이라고 본다). 앞에서 설명했듯이 LTSSM은 PCI Express와 USB 3 모두에서 사용된다. (물론, 몇가지 이벤트의 종류가 달라질 수 있다. PCI Express 에서는 LFPS Handshaking이라는 것이 없다. 이것과 비슷한 역할을 수행하는 Beacon을 사용한다).

USB 3 에서는 [그림 1]에서 USB Bus Interface부분이 LINK와 PHY 두부분으로 나뉘어져있다.

물론, 기존의 Protocol이라는 부분도 정의되어 있다.

그림 8. USB 3 전체 개요

그림8 USB3 전체개요

[그림 8]에서 “LINK”영역에서 논의되는 개념이 바로 LTSSM 인것이다.

 

LTSSM에서 명시하는 각각의 상태들과 이들 상태를 전이하는 사건들

* eSS.Disabled 두가지 서브상태로 나뉜다.

그림 9. eSS.Disabled Substate Machine

그림9 eSS.Disabled Substate Machine

eSS.Disabled 상태는 말 그대로 정상적인 USB 3 동작을 할 수 없는 연결상태를 의미한다. 이 상태를 벗어나는 방법은 PowerOn Reset혹은 USB 2.0 Reset에 의해서이다.

 

* eSS.Inactive 두가지 서브상태로 나뉜다.

그림 10. eSS.Inactive Substate Machine

그림10 eSS.Inactive Substate Machine

전형적인 USB 3 연결의 초기상태이다.

eSS.Disabled 상태는 말 그대로 정상적인 USB 3 동작을 할 수 없는 연결상태를 의미한다.

이 상태를 벗어나는 방법은 PowerOn Reset혹은 USB 2.0 Reset에 의해서이다.

다만, 처음 링크를 형성하는 단계에서 이런 상태로 오는 것이 아니라 이미 링크가 형성되어있는 상태에서만 이곳으로 온다.

USB 3 연결의 양쪽 포트의 존재유무에 따라서 Rx.Detect단계로 들어간다. Rx.Detect단계가 되면 초기화가 시작된다. Warm Reset(USB 3에서 정의한 리셋방식중 하나)으로 인해서 Rx.Detect단계로 들어가기도 한다.

 

* Rx.Detect 세가지 서브상태로 나뉜다.

그림 11. Rx.Detect Substate Machine

그림11 Rx.Detect Substate Machine

포트의 전원이 인가되어 정상적으로 인식되면 이 단계로 들어온다. 처음 링크가 형성되는 시작단계이다. 모든 과정이 정상적으로 수행되면 Polling단계로 들어가게 된다.

 

* Polling 8가지 서브상태로 나뉜다.

그림 12. Polling Substate Machine

그림12 Polling Substate Machine

LTSSM에서 도입된 새로운 개념이 Training 이라는 개념이다. 이것은 연결상태를 U0(전원이 정상적으로 공급되는 상태로서, 모든 USB데이타 패킷이 송, 수신될 수 있다)상태로 들어가기 위해서 필요한 기본적인 준비작업을 의미한다. LTSSM에서는 U0상태가 아닌 다른 상태에서 U0상태로 들어가기 위해서는 항상 Training작업을 먼저 수행해야 한다.

[그림 12]를 보면, 총 8가지의 서브상태를 보여주고 있다. 나름대로 각각의 상태들이 요구하는 절차를 모두 충족해야만 포트의 상태가 U0상태가 된다.

 

* Compliance 한가지 상태를 가진다.

Polling.LFPS 상태에서 진입하는 상태로서, 테스트목적으로 사용된다.

Transceiver 테스트용도로 사용한다.

 

* Loopback 한가지 상태를 가진다.

Polling 상태에서 진입하는 상태로서, 테스트목적으로 사용된다.

Receiver 테스트용도로 사용한다.

 

* U0 한가지 상태를 가진다.

전원공급이 정상적인 상태로서, 모든 USB 패킷이 송수신될 수 있다.

허브의 Downstream Port혹은 장치의 Upstream Port의 요청으로 U1, U2, U3(U3상태전환요청은 항상 Downstream Port에서만 요청할 수 있다)상태로 전환된다.

U0상태에서 U1, U2, U3상태로 전환하는 명령어는 USB 3 링크전용명령어 LGO_Ux 를 사용한다.

U0상태에서 에러가 발생하면, Recovery 상태로 전환된다.

 

* U1, U2, U3 한가지 상태를 가진다.

전원공급이 상대적으로 줄어드는 상태이다.(U0 > U1 > U2 > U3)

U1, U2, U3상태는 정상적인 USB 패킷을 송, 수신할 수 없는 상태이다. 따라서, U1, U2, U3상태에서 U0상태로 돌아오기 위해서는 LFPS(Low Frequency Periodic Signal) 방식을 사용한다. 이 방식은 적은 전력으로 명령전달이 가능하다.

U1, U2, U3상태는 U0상태로 돌아가기 위해서 LFPS명령어를 사용해서 우선 현재 상태를 벗어나고 어어서 Recovery상태로 전환된다.

 

* Recovery 세가지 상태를 가진다.

그림 13. Recovery Substate Machine

그림13 Recovery Substate Machine

U0 상태에서 데이터통신중 오류가 발생하거나, U1, U2, U3 상태를 빠져나오는 상황에서는 항상 Recovery 상태로 전환된다. U0, U1, U2상태에서 발생하는 Hot Reset을 처리하기 위해서도 임시로 Recovery상태로 전환된다. 그리고 U3상태에서 발생하는 Warm Reset을 처리하기 위해서도 역시 Recovery상태로 전환된다. Recovery 상태는 현재 연결상태를 U0상태로 다시 되돌리기 위해서 필요한 Retraining 작업을 시도한다. [그림 13]에서 처럼 필요한 작업이 실패하면 현재 상태는 eSS.Inactive 상태로 전환되며, 정상적인 Retraining이 수행되면 U0상태로 진입한다. 그외에 나머지 상태는 의도된 상태전환에 있어서 잠시 임시상태로 Recovery상태를 가진다.

 

* Loopback 두가지 상태를 가진다.

그림 14. Loopback Substate Machine

그림14 Loopback Substate Machine

Polling.Idle 상태와 Recovery상태에서 진입하는 상태로서, 테스트목적으로 사용된다.

Loopback Test를 진행할 수 있도록 고안된 특별한 동작상태이다.

이 상태를 마치면 [그림 14]처럼 Rx.Detect(성공), SS.Inactive(Timeout), SS.Disabled(Timeout, Downstream Port의 경우) 상태로 전환된다.

 

* Hot Reset 두가지 상태를 가진다.

그림 15. Hot Reset Substate Machine

그림15 Hot Reset Substate Machine

[그림 15]에서 처럼 Warm Reset 을 처리하는 경우에도 전원이 처음 포트에 인가된 경우가 아니라면, Hot Reset 상태를 잠시 거치게 된다.

Hot Reset 상태에서는 정상적인 TS2(Training Sequence 2) 핸드쉐이킹절차를 통해서 양쪽포트가 모두 Hot Reset 상태를 빠져나올 수 있는지를 확인한뒤, U0상태로 복귀한다.

유의할점은, 이미 Recovery단계를 통해서 필요한 Retraining절차를 모두 통과한 상태에서 Hot Reset과정을 진행한다는 점이다.

이와 같이 모든 LTSSM 과정을 살펴보았다. 모든 상태중에서 가장 일반적인 상태 변화를 나타내면 다음과 같다. Power On Reset => Rx.Detect => Polling => U0

만일, 사용중인 연결(Link)상태가 사용중에 U0상태에서 Recovery상태로 들어가는 경우는 링크단에서 살펴볼때, 송, 수신데이타가 깨졌거나, 프레임 Align이 깨졌거나, U1, U2, U3등의 상태에서 U0상태로 돌아오거나, 그것도 아니면 Warm Reset 또는 Hot Reset 명령어를 처리하는 과정이라고 볼 수 있다.

 

3. 링크단계에서 추가 지원되는 USB 3 명령어들

USB 3 에서는 연결(Link)단계를 위해서 별도의 추가 명령어를 정의하고 있다.

그림 16. USB 3 Link Command

그림16 USB3 Link Command

[그림 16]을 보면 USB 3 에서 사용되는 링크명령어(명령어, 처리결과)와 이것을 담고 있는 전체 패킷구조체를 보여주고 있다. 패킷구조는 다음 강좌에서 소개하도록 하고 여기서는 명령어와 처리결과만 집중해서 보도록 한다. 명령어와 처리결과는 모두 같은 포맷을 사용하기 때문에 둘 다 명령어라고 불러도 무방하기 때문에 앞으로 둘다 명령어로 간주한다.

[그림 16]에서 LGO_Ux 명령어와 LAU, LXU 명령어를 볼 수 있다.

LGO_Ux 명령어는 LGO_U1, U2, U3 명령어를 의미하고 U0상태에서 해당하는 Ux상태로 상태전환을 요청하는 링크단계명령어이다.

LAU 명령어는 LGO_Ux 명령어에 의해 요구된 상태변경을 수락한다는 뜻이다.

LXU 명령어는 LGO_Ux 명령어에 의해 요구된 상태변경을 허락하지 않는다는 뜻이다.

 

LTSSM을 관리하기 위해서는 위에서 설명한 링크단계의 명령어외에도 PHY계층에서 정의한 몇가지 패킷시퀀스도 개입된다.

 

4. LTSSM을 관리하기 위해서 사용되는 PHY 패킷 시퀀스

PHY와 관련된 내용은 다음 강좌에서 소개하도록 하고 여기서는 이중에서 LTSSM에서 중요하게 다루어지는 3가지 시퀀스만 잠시 살펴보도록 한다. 이 내용은 USB 3.0과 USB 3.1이 서로 다르다.

그림 17. TSEQ 시퀀스(USB 3.0)

그림17 TSEQ 시퀀스(USB3.0)

그림 18. TS1, TS2 시퀀스(USB 3.0)

그림18 TS1, TS2 시퀀스(USB 3.0)

[Table 6-5]

그림 19. TSEQ, TS1, TS2 시퀀스(USB 3.1)

그림19 TSEQ, TS1, TS2(USB 3.1)

USB 3 PHY에서 정의되는 Encoded Data 중에서 특별한 명령어로 사용하는 특수문자들이 있다.

이것들을 조합으로 사용하는 일련의 문자열스트림을 시퀀스라고 부른다.

[그림 17, 18, 19]를 보면 이런 문자열스트림의 값을 보여주고 있다.

 

Hot Reset 명령어를 처리하는 과정을 예로 들어서 이런 스트림을 설명하도록 하겠다.

Hub의 Downstream Port(DP)와 Device의 Upstream Port(UP)간의 형성된 연결(Link)이 있다고 가정한다. 어떤 이유에서, DP는 UP와 함께 Hot Reset 시퀀스를 가지려고 한다면, 이때 다음과 같은 시퀀스가 발생된다.

그림 20. DP와 UP의 Hot Reset 처리 시퀀스

그림20 Hub DP와 Device UP의 Hot Reset 처리 시퀀스

[그림 18, Table 6-5]를 보면 RESET BIT의 위치를 확인할 수 있다.

[그림 20]에서 설명하는 내용처럼 DP와 UP는 TS2 시퀀스를 사용해서 서로가 Hot Reset 을 성공적으로 완료했다는 결과를 보고하고 있다.