Other Protocols

(2) MIPI I3C Basic Specification - I3C Protocol

PCIeMaster 2024. 11. 12. 17:36

5 I3C 프로토콜

이 섹션에서는 정의된 모든 I3C 모드에 대한 통신 프로토콜을 지정합니다:

  • 단일 데이터 속도(SDR) 모드: 섹션 5.1 참조
  • 고속 데이터(HDR) 모드: 섹션 5.2 참조
    • I3C BASIC에 포함되지 않음: HDR 3진 기호 순수 버스(HDR-TSP) 모드: 섹션 5.2.3 참조
    • I3C BASIC에 포함되지 않음: HDR 3진 기호 레거시 포함 버스(HDR-TSL) 모드: 섹션 5.2.3 참조
    • HDR 더블 데이터 속도(HDR-DDR) 모드: 섹션 5.2.2 참조
    • HDR 벌크 전송 모드: 섹션 5.2.4 참조

I3C 버스는 항상 SDR 모드에서 초기화 및 구성되며, HDR 모드에서는 절대 초기화되지 않는다는 점이 중요합니다. (SDR 모드에서 HDR 모드로 전환하는 절차는 섹션 5.2.1에 자세히 설명되어 있습니다.)

결과적으로, 대부분의 기본적인 I3C 프로토콜 사양은 섹션 5.1에 나와 있으며, 여기에는 다음이 포함됩니다.

 

5.1 단일 데이터 속도(SDR) 모드

 

이 섹션에서는 단일 데이터 속도(SDR) 모드에 대한 통신 프로토콜을 지정합니다.

 

SDR 모드는 I3C 버스의 기본 모드입니다. SDR 모드는 다른 모드, 하위 모드 및 상태(섹션 5.1 및 섹션 5.2에 설명됨)로 전환하기 위해 사용되며, 공통 명령(CCC), 인밴드 인터럽트, 동적 주소 할당을 통한 I2C에서 I3C로의 전환과 같은 기본 기능을 지원합니다.

 

I3C SDR 모드는 절차와 조건 측면에서 I2C 프로토콜([NXP01] 참조)과 상당히 유사하며, 그 결과 많은 I3C 디바이스와 일부 레거시 I2C 타겟 디바이스(단, 레거시 I2C 컨트롤러 디바이스는 아님)가 동일한 I3C 버스에서 공존할 수 있습니다. 그러나 SDR 모드는 I2C에는 없는 여러 새로운 기능도 포함하고 있습니다. I2C와 공유하는 절차와 조건에 대해서는, SDR 모드는 I2C 사양에서 정의된 내용을 따릅니다. I3C 컨트롤러에서 I2C 타겟으로의 I2C 트래픽은 모든 I3C 타겟에 의해 적절히 무시됩니다. 이는 I3C 프로토콜이 I2C 트래픽을 허용하도록 설계되었기 때문입니다. I3C 타겟으로의 I3C 트래픽은 대부분의 레거시 I2C 타겟 디바이스에서는 감지되지 않으며, 이는 I2C 스파이크 필터가 I3C의 높은 클록 속도에 불투명하기 때문입니다.

 

5.1.1 버스 구성

 

I3C 버스는 여러 클라이언트 간의 링크로 구성될 수 있으며, 유연하고 효율적인 방식으로 작동합니다. 시스템 아키텍처 수준에서는 I3C 호환 디바이스에 대해 7개의 역할이 정의됩니다(표 1 참조).

I3C 상호 연결의 예시 블록 다이어그램은 그림 10에 나와 있습니다. 이 그림에서 파란색은 컨트롤러 역할을 하는 디바이스를 나타내고, 분홍색은 I3C 타겟 역할을 하는 디바이스를, 보라색은 I2C 타겟 역할을 하는 디바이스를 나타냅니다.

참고:

  • I3C 보조 컨트롤러 디바이스는 동일한 동적 주소를 사용하여 다른 시간에 컨트롤러 또는 타겟 역할을 수행할 수 있는 능력을 가집니다. 그림 10에서 I3C 기본 컨트롤러는 버스의 활성 컨트롤러 역할을 하며, I3C 보조 컨트롤러는 타겟 역할을 수행합니다(즉, 이때는 컨트롤러 기능이 활성화되지 않음).
  • I3C 디바이스는 여러 역할을 동시에 수행할 수도 있습니다. 그림 10에서는 I3C 복합 디바이스가 여러 가상 타겟을 I3C 버스에 표시하는 예시가 나와 있으며, 각 가상 타겟은 별도의 동적 주소를 갖습니다. 이러한 복합 I3C 디바이스는 공유 주변 장치 로직을 사용하여 동시에 활성 상태인 가상 타겟에 대한 전송을 처리합니다(섹션 5.1.2.1.2 참조). 다른 유형의 복합 I3C 디바이스도 가능하며, 보조 컨트롤러와 같은 다른 역할을 지원할 수 있습니다.
  • I3C 디바이스는 브리지 디바이스(예: 다른 버스에 대한 인터페이스, I2C 또는 SPI와 같은) 또는 라우팅 디바이스(다른 I3C 버스로 연결되는)로서 다른 버스에 대한 연결을 가능하게 할 수도 있습니다. 이러한 디바이스는 이 I3C 버스에서 하나 이상의 가상 타겟을 나타낼 수 있으며, 브리지 디바이스 또는 라우팅 디바이스를 통해 통신에 사용될 수 있습니다.

 

그림 11은 단순한 포인트 투 포인트 통신을 위한 I3C 최소 버스 사용 사례와 함께 또 다른 예시 블록 다이어그램을 보여줍니다. 이 사용 사례에서 단일 컨트롤러는 하나 이상의 I3C 타겟 디바이스에 동일한 동적 주소를 할당하며, 이 중 하나만이 읽기 전송과 인밴드 인터럽트를 지원합니다.

 

I3C 호환 디바이스는 I3C 버스 내에서의 기능에 따라 다양한 기능을 가질 수 있습니다. I3C 버스의 시스템 설계에 따라 특정 버스 인스턴스에 대해 모든 디바이스 기능을 활성화할 필요는 없을 수 있습니다. 그러나 모든 I3C 호환 디바이스의 활성화된 기능은 섹션 5.1.1.2에서 설명된 대로 디바이스와 그 역할에 연관된 특성 레지스터에 설명됩니다. I3C 기본 컨트롤러는 전원이 켜지기 전에 버스에 존재하는 모든 레거시 I2C 디바이스의 특성(예: 버스에 존재하는 모든 레거시 I2C 디바이스의 고정 주소)을 획득해야 합니다.

 

전원이 꺼진 상태에서 시작될 때마다, 기본 컨트롤러는 버스에서 활성 역할을 하는 모든 디바이스(자신을 포함)에 고유한 동적 주소를 할당해야 합니다. 동적 주소 할당 절차는 섹션 5.1.4에 설명되어 있습니다. 동적 주소는 인밴드 인터럽트의 우선 순위를 생성합니다. I3C 버스에 존재하는 모든 보조 컨트롤러는 섹션 5.1.9에 설명된 공통 명령 코드(CCC)를 통해 버스에 있는 각 I3C 호환 디바이스의 동적 주소 할당 및 특성 레지스터를 인식하게 됩니다.

 

5.1.1.1 I3C 디바이스 특성

 

I3C 버스의 구성은 해당 I3C 버스에서 활성화될 예정인 I3C 디바이스의 특성에 따라 달라집니다. 따라서, 특정 I3C 버스 인스턴스에서 주어진 역할을 수행하는 활성 I3C 디바이스는 그 역할에 대한 모든 책임을 다해야 하며, 이는 표 2에 자세히 설명되어 있습니다.

 

 

Table 3 I 706 2C Features Allowed in I3C Targets

책임/기능 설명 주요 컨트롤러 보조 컨트롤러 SDR 전용 주요 컨트롤러 SDR 전용 보조 컨트롤러 타겟 SDR 전용 타겟
SDA 중재 관리 주소 중재, 인밴드 인터럽트, 핫 조인, 동적 주소 등 관리 Y Y Y Y N N
동적 주소 할당 컨트롤러가 동적 주소 할당 Y Optional³ Y Optional³ N N
핫 조인 동적 주소 할당 핫 조인 후 동적 주소 할당이 가능한 컨트롤러 Y Optional³ Y Optional³ N N
자체 동적 주소 할당 주요 컨트롤러만 동적 주소를 자체 할당 가능 Y N N N N N
고정 I2C 주소¹ 동적 주소를 더 빠르게 할당하기 위해 사용 N/A Optional N/A Optional Optional Optional
타겟 주소 및 특성 메모리 레지스터 유지 Y Y Y Y N N
HDR 타겟 기능 적어도 하나의 HDR 모드에서 접근 가능 Y Y Y Y N N
HDR 컨트롤러 기능 적어도 하나의 HDR 모드에서 버스 제어 가능 Y Y N N N/A N/A
HDR 종료 패턴 생성 가능² 오류 복구를 위해 버스에서 HDR 종료 패턴 생성 가능 Y Y Y Y N N
HDR 대응 HDR 종료 패턴 인식 Y Y Y Y Y Y

참고:

  1. 고정 주소는 동적 주소를 더 빠르게 할당하기 위해 사용할 수 있습니다(섹션 5.1.4 참조).
  2. 모든 타겟은 HDR 종료 패턴 검출기가 필요하며, HDR 기능이 없는 타겟도 포함됩니다.
  3. 보조 컨트롤러는 ENTDAA CCC를 사용하여 활성 컨트롤러 역할을 수행할 때 동적 주소를 할당할 수 있습니다(섹션 5.1.7.3.3 참조).

 

I3C 프로토콜은 I2C 타겟 기능의 일부를 지원합니다. 예를 들어, I3C 타겟은 고정 주소를 가질 수 있지만 동적 주소 할당도 지원할 수 있습니다. I3C 버스가 최대 클록 속도로 작동할 때는 50ns 스파이크 필터가 활성화되지 않아야 합니다. 이러한 차이점은 표 3에 요약되어 있습니다. I3C 시스템에서 사용될 때, I3C 타겟은 표 3에 나와 있는 대로 적절한 I2C 기능을 활성화하거나 비활성화해야 합니다.

 

I2C 기능 (I3C 버스에서 사용 시) I3C에서 필수 I3C에서 권장 I3C에서 사용되지 않음 I3C에서 허용되지 않음 참고
Fm/Fm+ 속도 – – – X 2, 3, 4
HS 속도 – – – X 3
UFm 속도 – – – X 3
고정 I2C 주소 – X – –  
50ns 스파이크 필터 – – – X (비활성화해야 함) 3
클록 스트레칭 – – – X –
20mA 오픈 드레인 드라이버 – – X – 1, 3
I2C AC 타이밍 일치 – – X – 2, 3
I2C 확장 주소 (10비트) – – – X 3
I3C 예약 주소 – – – X –

 

참고:

  1. 표 82와 표 85 참조.
  2. I3C 구동 및 타이밍 요구 사항은 I2C와 다릅니다.
  3. I3C 버스에 I2C 타겟이 I2C 버스용으로 의도된 I2C 기능을 가지고 있으면, I3C 버스에서는 사용되지 않습니다. 섹션 5.1.1.1에 따라, 타겟이 7h7E를 감지하면 I3C에서 사용되지 않는 I2C 기능을 비활성화합니다.
  4. I2C 전용 디바이스와 통신할 때 타이밍 요구 사항은 해당 I2C 전용 디바이스에서 지원되는 최대 SCL 클록 주파수에 따라 달라질 수 있습니다. 표 84와 표 85 참조.

 

I3C 버스의 성능은 해당 버스에 연결될 수 있는 I2C 전용 디바이스에 크게 의존합니다. 따라서, I3C 버스의 모든 인스턴스에서 허용되는 I2C 전용 디바이스는 표 4에 자세히 설명된 범주 중 하나를 준수해야 합니다. 또한 (표 84에 참조된 바와 같이), I3C 버스에 존재하는 어떤 I2C 또는 I3C 디바이스도 오류 유형 TE0와 관련된 주소(표 59 참조)와 일치하는 I2C 고정 주소를 가져서는 안 됩니다.

 

Table 4 Legacy I 712 2C-Only Target Categories and Characteristics

 

5.1.1.2 I3C 특성 레지스터

I3C 특성 레지스터는 I3C 호환 디바이스의 기능과 역할을 설명하고 정의하며, 디바이스가 특정 시스템에서 I3C 버스를 서비스할 때 이를 사용합니다. I3C 특성 레지스터가 없는 디바이스는 공용 I3C 버스에 연결되어서는 안 됩니다.

세 가지 특성 레지스터 유형이 있습니다:

  • 버스 특성 레지스터(BCR, 섹션 5.1.1.2.1 참조)
  • 디바이스 특성 레지스터(DCR, 섹션 5.1.1.2.2 참조)
  • 레거시 가상 레지스터(LVR, 섹션 5.1.1.2.3 참조)

모든 I3C 호환 디바이스는 디바이스 유형에 따라 다음과 같은 관련 특성 레지스터를 가져야 합니다:

  • 하나의 활성 역할을 가진 모든 I3C 준수 디바이스(표 2에 정의됨)는 하나의 버스 특성 레지스터와 하나의 디바이스 특성 레지스터를 가져야 하며, 이는 동적 주소와 연관됩니다.
  • 여러 활성 역할을 가진 I3C 준수 디바이스는 모든 활성 역할에 적용되는 단일 공유 버스 특성 레지스터 및 디바이스 특성 레지스터를 사용하거나, 각 활성 역할에 대해 하나의 역할당 한 쌍의 레지스터를 사용할 수 있습니다. 이는 각 역할의 동적 주소와 연관됩니다.
    • 여러 가상 타겟을 나타내는 복합 I3C 디바이스는 일반적으로 각 가상 타겟에 대해 별도의 버스 특성 레지스터와 디바이스 특성 레지스터 세트를 가져야 합니다. 즉, 각 가상 타겟은 해당 동적 주소와 연관된 고유한 레지스터 세트를 갖습니다.
  • I3C 버스에 연결된 모든 레거시 I2C 디바이스는 하나의 레거시 가상 레지스터를 가져야 합니다. 이러한 레지스터는 레거시 디바이스이므로 가상으로 존재할 것으로 이해되며, 이는 디바이스 드라이버의 일부로 간주됩니다.

 

5.1.1.2.1 버스 특성 레지스터 (BCR)

 

I3C 버스에 연결된 각 I3C 디바이스는 관련된 읽기 전용 버스 특성 레지스터(BCR)를 가져야 합니다. 이 읽기 전용 레지스터는 동적 주소 할당 및 공통 명령 코드에 사용되는 I3C 준수 디바이스의 역할과 기능을 설명합니다. BCR 내의 비트는 표 5에 제시된 설명에 따라야 합니다.

참고

 

  • I3C 컨트롤러(주 컨트롤러 또는 보조 컨트롤러)로서 동작할 수 있는 모든 I3C 디바이스의 BCR 디바이스 역할 비트는 2’b01입니다. 주 컨트롤러는 DEFTGTS CCC(섹션 5.1.9.3.7 참조)를 통해 타겟에 자신을 식별하며, 고정 주소 값은 7'h7E입니다.
  • I3C v1.0에서 BCR[5] 비트는 HDR 지원만을 나타냈으며, 컨트롤러는 지원되는 HDR 모드를 확인하기 위해 GETHDRCAPS CCC를 사용해야 했습니다. I3C v1.1 및 이후 버전에서는 BCR[5]가 이제 동일한 CCC(현재 GETCAPS로 이름 변경)를 사용하도록 컨트롤러에게 지시하여 I3C 디바이스가 지원하는 고급 기능을 확인합니다(HDR 지원에 국한되지 않음). I3C v1.0 방법은 I3C v1.1 및 이후 방법과 완전히 호환됩니다.
  • I3C v1.0에서 BCR[4] 비트는 브리지 디바이스가 I3C 사양을 준수하는 데 필요한지 여부만 나타냈습니다. I3C v1.1 및 이후 버전에서는 BCR[4]가 이제 디바이스가 가상 타겟인지 여부 또는 다른 다운스트림 디바이스를 노출하는지 나타내며, 컨트롤러는 Defining Byte VTCAPS(섹션 5.1.9.3.19 참조)를 사용하여 I3C 디바이스가 지원하는 기능을 확인하도록 지시합니다(브리지 디바이스에 국한되지 않음).
  • 오프라인 기능을 가진 디바이스는 동적 주소를 유지하며, 섹션 2.2에 지정되어 있습니다.
  • 컨트롤러는 GETMXDS CCC를 사용하여 특정 제한 사항을 확인하기 위해 타겟을 검사해야 합니다.

 

5.1.1.2.2 디바이스 특성 레지스터 (DCR)

I3C 버스에 연결된 각 I3C 디바이스는 관련된 읽기 전용 디바이스 특성 레지스터(DCR)를 가져야 합니다. 이 읽기 전용 레지스터는 가속도계, 자이로스코프 등과 같은 I3C 준수 디바이스의 유형을 설명하며, 동적 주소 할당 및 공통 명령 코드에 사용됩니다. DCR 내의 비트는 표 6에 제시된 설명을 따라야 합니다.

MIPI Alliance는 승인된 DCR 값 할당 및 보류 중인 할당에 대한 공개 레지스트리를 유지 관리하고 있습니다 [MIPI02].

 

 

5.1.1.2.3 레거시 가상 레지스터 (LVR)

I3C 버스에 연결될 수 있는 각 레거시 I2C 디바이스는 디바이스의 주요 기능을 설명하는 읽기 전용 레거시 가상 레지스터(LVR)를 가져야 합니다. 이러한 디바이스는 레거시 I2C 디바이스이므로, 이 레지스터는 예를 들어 디바이스 드라이버의 일부로서 가상으로 존재하는 것으로 이해됩니다. I3C 버스에 레거시 I2C 디바이스가 존재하는 경우, LVR 데이터는 허용되는 모드와 최대 SCL 클록 주파수를 결정합니다. LVR 내의 비트는 표 7에 제시된 설명을 따라야 합니다.

모든 LVR은 I3C 버스를 제어하는 상위 레벨 엔티티에 의해 설정되며, 버스 구성 전에 I3C 버스의 주 컨트롤러로 전송됩니다. 모든 I2C 디바이스의 LVR 내용은 주 컨트롤러가 항상 알고 있으며, 주 컨트롤러는 DEFTGTS CCC(섹션 5.1.9.3.7 참조)를 사용하여 모든 I2C 디바이스의 LVR 내용을 보조 컨트롤러로 전송해야 합니다.

 

5.1.2 버스 통신

I3C의 기본 프로토콜 및 모드는 SDR(단일 데이터 속도) 모드입니다. SDR 프로토콜은 I2C 표준 프로토콜([NXP01] 참조)을 기반으로 하며, 몇 가지 주요 차이점이 있습니다:

  • I3C의 시작(START) 및 정지(STOP)는 신호 방식에서 I2C와 동일하지만, 타이밍에서는 I2C와 다를 수 있습니다(표 86 및 표 85 참조).
  • 참고: I3C SDR(하지만 HDR에서는 아님)에서는, SCL이 High 상태일 때 컨트롤러가 SDA를 제어하거나 SDA가 오픈 드레인일 경우 언제든 STOP 또는 반복된 START가 허용됩니다. 이는 I2C와 달리, I2C에서는 주소 또는 데이터의 NACK 후에만 STOP 또는 반복된 START를 허용합니다. I3C는 STOP 및 반복된 START를 이러한 상황에서만 사용하는 것을 선호하지만, I3C 브로드캐스트 주소가 ACK된 경우 이를 다른 위치에서도 허용하며, 주소 또는 데이터 중간에 STOP 또는 반복된 START가 나타나면 해당 주소 또는 데이터가 취소된 것으로 해석됩니다.
  • I3C 주소 헤더는 비트 형식과 신호 방식에서 I2C 주소 헤더와 동일하지만, 타이밍은 I2C와 다를 수 있습니다(섹션 5.1.2.2, 표 86 및 표 87 참조).
  • 데이터 9비트 워드는 I2C와 동일한 비트 수를 사용하지만, 9번째 비트에서 다릅니다(섹션 5.1.2.3 참조).
  • I3C에서는 SCL 라인이 컨트롤러에 의해서만 구동됩니다. 이 드라이브는 일반적으로 푸시-풀 방식이지만, 오픈 드레인 방식도 가능합니다.

주소 헤더와 데이터 워드의 비트 수가 동일하기 때문에, I3C 타겟은 메시지가 해당 타겟에 직접 또는 브로드캐스트 방식으로 주소 지정된 경우에만 이를 I3C 메시지로 인식할 수 있습니다.

I3C 메시지는 초기 START(또는 반복된 START)부터 다음 반복된 START 또는 STOP까지의 모든 것을 포함합니다.

I3C 메시지는 다음과 같은 경우 SDR 메시지입니다:

  • 주소 헤더의 주소가 7'h7E(즉, I3C 브로드캐스트 주소)일 때, 모든 I3C 타겟은 주소 7'h7E와 일치해야 합니다. I2C 타겟은 이 주소를 인식하지 않습니다.
  • 주소 헤더의 주소가 타겟의 동적 주소와 일치할 때(섹션 5.1.4 참조), 모든 I3C 타겟은 자신의 동적 주소와 일치하는지 확인해야 합니다(필요시 헤더를 NACK할 수 있음).

모든 I3C 타겟은 7'h7E 또는 I3C 컨트롤러 할당 주소가 아닌 주소의 메시지를 무시해야 하며, 버스에서 일치하지 않는 주소에 대한 반복된 START 또는 STOP을 기다려야 합니다.

 

참고 

  • 레거시 I2C 타겟은 자신에게 주소가 지정되지 않은 메시지는 무시하며, 다음 START 또는 STOP을 기다립니다. 섹션 5.1.2.4에 따라, 레거시 I2C 타겟은 SCL 신호 속도 때문에 일부 또는 모든 I3C 메시지와 모드를 감지하지 못할 수도 있습니다.

 

 

5.1.2.1 I3C 타겟의 역할

I3C 타겟은 I3C 디바이스에 의해 구현되거나 표시되는 기능적 역할입니다. 이 역할은 단일 타겟을 나타내는 독립형 물리적 디바이스이거나, 공유 주변 로직을 통해 여러 가상 타겟을 나타내는 복합 디바이스일 수 있습니다. 두 경우 모두, 각 타겟(가상 타겟일 수 있음)은 고유한 동적 주소를 할당받을 수 있으며, 컨트롤러는 전송을 위해 개별적으로 해당 주소를 참조할 수 있습니다.

 

참고: 

  • I3C 타겟은 자신이 레거시 I2C 버스 또는 I3C 버스에 있는지 알 필요가 없습니다. 만약 I3C 타겟에 고정 주소가 있다면, 동적 주소가 할당되기 전까지 해당 주소를 사용하여 통신할 수 있습니다. 동적 주소가 할당된 후에는, 리셋되지 않는 한 I3C 타겟으로만 작동해야 합니다.

I3C 대응 타겟은 동적 주소(DA)가 할당되기 전까지 PC 디바이스로서 작동할 수 있습니다. 그러나 타겟은 7'h7E 주소로 시작을 ACK 해야 합니다(유일한 예외는 특정 버스나 용도로 I2C 전용 디바이스로 남기로 선택한 경우로, 이 경우 50ns 스파이크 필터를 활성화 상태로 유지함).

 

동적 주소를 받기 전:

START 및 7'h7E 주소를 인식하는 타겟은 ENTDAA(섹션 5.1.9.3.4 참조)를 제외한 모든 CCC를 사용할 수 있습니다. 다음을 수행해야 합니다:

  • 타겟은 ENTDAA, RSTDAA(섹션 5.1.9.3.3 참조), ENEC(섹션 5.1.9.3.1 참조), DISEC(섹션 5.1.9.3.1 참조) 등의 필수 브로드캐스트 CCC를 적절히 처리해야 합니다.
    • 적절한 처리 예시:
      • RSTDAA는 효과가 없습니다. 동적 주소가 할당되지 않았기 때문입니다.
      • 특정 I3C 버스에서만 사용되는 타겟 디바이스의 경우, SETAASA 및/또는 SETDASA를 사용하여 동적 주소를 할당할 수 있습니다.
      • 컨트롤러 역할 요청이 없을 경우, 컨트롤러 역할 요청을 위한 DISEC CCC는 무시됩니다.
  • 타겟은 ENTHDR0에서 ENTHDR7까지의 CCC를 인식해야 하며, HDR 종료 패턴을 기다립니다(섹션 5.1.9.3.9 참조).
  • 타겟은 필요에 따라 SETDASA CCC(섹션 5.1.9.3.10 참조) 또는 SETAASA CCC(섹션 5.1.9.3.23 참조)를 처리해야 합니다.
  • 타겟은 직접적으로 주소 지정된 CCC 명령을 무시할 수 있지만, 브로드캐스트로 보내진 필수 및 조건부 브로드캐스트 CCC를 인식해야 합니다.

동적 주소가 할당되기 전에는, 타겟은 이러한 CCC를 지원할 수도 있고 지원하지 않을 수도 있습니다. 예를 들어, 특정 타겟은 동적 주소가 없는 상태에서 테스트 모드만 지원할 수 있습니다.

I3C 타겟은 TE0 유형 오류와 관련된 주소에 대해서는 모든 주소 할당 요청을 무시해야 합니다(표 59 참조).

 

주소 헤더 매칭

I3C 타겟의 역할은 다음과 같습니다:

  • START 또는 반복된 START 이후, 이 사양의 섹션 6에 따라 속도가 설정되면, I3C 타겟은 I3C 브로드캐스트 주소(7'h7E) 또는 할당된 경우 자신의 동적 주소와 주소가 일치하는지 확인해야 합니다.일치하는 주소가 있으면, I3C 타겟은 해당 메시지를 I3C SDR로 처리합니다.
    타겟이 그룹 주소 기능(섹션 5.1.4.4 참조)을 지원하는 경우, 할당된 그룹 주소 중 하나와 일치하는지도 확인해야 합니다.
    메시지가 타겟의 동적 주소로 전송된 경우, 타겟은 주소 헤더를 ACK하거나 수동으로 NACK할 수 있습니다:
    • 타겟이 주소 헤더를 ACK하면, 이 섹션에서 설명된 모든 규칙에 따라 메시지를 I3C SDR로 처리합니다.
    • 타겟이 주소 헤더를 NACK(ACK 비트를 Low로 구동하지 않음)하면, 타겟은 다음 반복된 START 또는 STOP까지 뒤따르는 모든 비트를 무시해야 합니다.
  • 메시지가 타겟에 할당된 그룹 주소 중 하나에 쓰기(RnW 비트가 0)로 전송된 경우, 타겟은 주소 헤더를 ACK하거나 수동으로 NACK할 수 있습니다:
    • 타겟이 주소 헤더를 ACK하면, 해당 메시지를 자신의 동적 주소로 I3C SDR 쓰기와 동일한 방식으로 처리합니다.
  • 메시지가 I3C 브로드캐스트 주소(7'h7E)로 전송되고, 쓰기(RnW 비트가 0)일 경우, 타겟은 해당 메시지를 처리해야 합니다. 이때 메시지에 데이터가 포함되어 있다면 첫 번째 바이트까지는 처리해야 합니다.
    • 7'h7E 브로드캐스트 메시지에 데이터 바이트가 포함되어 있으면, 해당 메시지는 섹션 5.1.9에 따라 CCC(공통 명령 코드) 명령으로 간주됩니다.

    • I3C 타겟은 섹션 5.1.9.3에 따라 모든 관련 필수 CCC 명령을 처리해야 합니다. 명령은 항상 필요한 것일 수도 있고, 조건부로 필요한 것일 수도 있습니다(표 16 참조).
      필수 CCC의 경우: 타겟은 동적 주소에 전송된 특정 직접 CCC 명령(예: GETSTATUS, 섹션 5.1.9.3.15 참조)에 응답할 준비가 항상 되어 있어야 하며, 타겟(또는 내부 시스템)이 이전에 전송된 메시지를 처리 중일 때도 다른 CCC 또는 메시지를 처리하거나 ACK하지 못할 수 있습니다(섹션 5.1.10.2.5 참조).

    • CCC 명령이 I3C 버스의 모드를 변경하는 경우, I3C 타겟은 새로운 모드를 다음 두 가지 방식 중 하나로 처리해야 합니다.
      •  Either:
      • 옵션 1: i. 새로운 모드가 동적 주소 할당 모드(섹션 5.1.4 참조)일 경우, 모든 I3C 타겟에 필수이며, 타겟이 현재 동적 주소가 없는 경우 참여해야 합니다. 그렇지 않으면, 타겟은 동적 주소 할당 모드에서 벗어나는 STOP 신호를 기다려야 합니다.
      • Or:
      • 옵션 2: ii. 새로운 모드가 HDR(고속 데이터 전송) 모드인 경우, 타겟은 지원되는 경우 HDR 모드로 진입하거나(섹션 5.2.1.3.1 참조), 아니면 HDR 종료 패턴 검출기를 활성화하여 HDR 모드 종료를 대기해야 합니다(섹션 5.2.1.1 및 섹션 5.2.1.1.3 참조).
 
  • 메시지가 I3C 브로드캐스트 주소(7'h7E) 또는 타겟에 현재 할당된 주소(예: 동적 주소 또는 그룹 주소)로 전송되지 않은 경우, I3C 타겟은 반복된 START 또는 STOP 신호를 기다려야 합니다. 타겟은 필요에 따라 지나가는 비트를 기록하거나 모니터링할 수 있지만, 반복된 START 또는 STOP 신호를 기다리는 것이 유일한 의무입니다.
  • 참고:
    • 반복된 START와 STOP은 섹션 2.2 및 섹션 6.2에 지정되어 있으며, I2C와 유사합니다. 두 경우 모두 I3C의 타이밍이 I2C와 동일할 수도 있고 다를 수도 있습니다.

 

5.1.2.1.1 I2C 타겟으로서 정적 주소를 가진 I3C 타겟의 역할

 

다른 섹션에서 언급된 것처럼, I3C 타겟은 I2C 정적 주소를 가지고 있는 한 표준 I2C 타겟으로서 동작할 수 있습니다. 두 가지 상황이 있습니다:

  1. I3C 타겟이 레거시 I2C 버스에 있을 때, 모든 메시징은 레거시 I2C 컨트롤러에서 발생합니다.
  2. I3C 타겟이 I3C 버스에 있지만, I3C 컨트롤러가 동적 주소를 할당하지 않으므로, I3C 타겟은 계속해서 I2C 타겟으로서 동작합니다. 메시지의 송수신은 I2C 정적 주소를 사용하여 I2C 프로토콜을 따릅니다.

I2C 버스에서 동작할 때, 타겟은 Fm/Fm+ 스파이크 필터(50ns 이상)를 사용할 수 있으며, 이 필터는 필요할 경우 사용할 수 있습니다.

I3C 버스에서 동작할 때, 타겟은 50ns 이상의 Fm/Fm+ 스파이크 필터를 사용할 수 있지만, I3C 컨트롤러의 메시지(특히 버스 초기화 후 첫 번째 I3C 주소 헤더)를 감지한 경우 이를 비활성화해야 합니다. 이를 지원하기 위해, I3C 컨트롤러는 첫 번째 I3C 주소 헤더에 대해 오픈 드레인 타이밍 매개변수로 신호를 보냅니다(표 86 참조).

참고:

  • 스파이크 필터가 활성화된 타겟이 오픈 드레인 타이밍 매개변수로 설정된 I3C 주소 헤더를 감지한 경우, ACK 후 스파이크 필터를 비활성화해야 합니다.

I2C 타겟으로 동작하는 I3C 타겟은 스파이크 필터가 없거나 비활성화된 상태에서도 I3C 버스에서 정상적으로 작동합니다. 모든 I3C 타겟에는 두 가지 요구 사항이 있습니다:

  1. 모든 필수 브로드캐스트 CCC를 인식하고 각 명령에 대해 적절하게 작동해야 합니다. 동적 주소를 받지 않은 경우에도 이를 수행해야 하며, ENTHDRn CCC(섹션 5.1.9.2 및 표 16 참조)가 포함됩니다.
  2. HDR 종료 패턴을 인식할 수 있어야 합니다(섹션 5.2.1.1.1 참조).

이 두 가지 요구 사항으로 인해, I3C 타겟이 짧은 SCL 신호(high 및 low)를 볼 수 있는 환경에서 I2C 타겟으로 동작하는 것이 안전합니다. 이를 통해 레거시 I2C 디바이스와 달리 스파이크 필터 없이도 I3C 버스에서 I2C 타겟으로서 정상적으로 동작할 수 있습니다.

 

5.1.2.1.2 복합 디바이스와 가상 타겟

앞서 설명한 바와 같이, 가상 타겟은 I3C 디바이스에 의해 표시되며, 해당 디바이스는 I3C 버스에서 여러 가상 타겟을 표시할 수 있고, 이러한 모든 가상 타겟의 통신을 관리해야 합니다. 이러한 방식으로, 가상 타겟은 여러 활성 타겟 역할을 동시에 보유하는 복합 I3C 디바이스의 기능으로 간주될 수 있습니다. I3C 디바이스는 각 가상 타겟에 대해 개별 구성을 유지하며, 동적 주소도 포함됩니다.

 

동적 주소 할당 중(섹션 5.1.4.2 참조), 공유 주변 로직은 I3C 컨트롤러 및 버스의 다른 I3C 타겟과의 상호 작용을 관리하며, ENTDAA 절차를 수행합니다. 이는 주소 중재를 관리하고, 48비트 할당된 ID를 제공하며, 모든 활성 가상 타겟이 동적 주소를 받을 수 있도록 보장합니다. 또한 공유 주변 로직은 초기화 중 또는 필요 시 핫 조인 요청(섹션 5.1.5 참조)을 시작합니다.

 

참고:

  • 여러 가상 타겟을 나타내는 디바이스는 ENTDAA CCC 대신 SETDASA 및/또는 SETAASA CCC를 지원할 수 있으며, 이 경우 각 가상 타겟은 고유한 정적 주소를 가져야 합니다.

동적 주소가 할당되면, 공유 주변 로직은 SDR 모드에서 I3C 버스와의 기본 통신을 관리하며, 각 가상 타겟은 동적 주소로 전송된 비공개 쓰기 전송 데이터를 수신하고, 인밴드 인터럽트 요청을 위해 공유 주변 로직에 데이터를 제공합니다.

 

공유 주변 로직은 HDR 모드에서의 신호 및 프레이밍 처리도 담당하며, 브로드캐스트 및 직접 CCC 흐름에도 참여합니다. 이는 SDR 모드(섹션 5.1.9 참조)와 HDR 모드에서 지원되는 모든 CCC에 해당합니다(섹션 5.2.1.2 참조).

 

공유 주변 로직은 또한 RSTACT CCC와 타겟 리셋 패턴(섹션 5.1.11 참조)과 관련된 리셋 흐름을 처리하고, 리셋 유형에 따라 가상 타겟 기능에 적절한 내부 리셋 메시지를 생성합니다. 대부분의 경우, 가상 타겟 기능을 보고하는 디바이스는 BCR의 비트[4](섹션 5.1.1.2.1 참조)를 통해 이를 나타내며, GETCAPS CCC에서 Defining Byte VTCAPS를 통해 추가 기능을 보고합니다(섹션 5.1.9.3.19 참조).

 

구현에 따라, 하나의 가상 타겟의 동적 주소로 전송된 특정 명령 또는 CCC는 복합 디바이스가 나타내는 다른 가상 타겟에 부작용을 일으킬 수 있습니다. 경우에 따라, 타겟의 동적 주소가 보고하는 일부 기능 및 특성이 디바이스 전체에 동일하게 적용될 수 있습니다(예: GETCAPS CCC에 의해 보고되는 기능).

 

5.1.2.1.3 그룹 주소를 지원하는 타겟

타겟이 그룹 주소 지정(섹션 5.1.4.4 참조)을 지원하는 경우, 일반적으로 타겟 자체나 특별한 경우에는 디바이스 또는 주변 로직과 관련된 단일 기능 세트 또는 구성 가능한 매개변수를 갖게 됩니다.

  • 이러한 기능이 직접 GET CCC(예: GETCAPS CCC, 섹션 5.1.9.3.19 참조)를 통해 접근할 수 있는 경우, 이는 타겟 및 모든 할당된 주소, 할당된 그룹 주소를 포함하여 타겟 전체에 적용된다고 가정됩니다. 단, 특정 Direct CCC의 정의에서 달리 명시된 경우는 예외입니다.
  • 이러한 구성을 직접 SET CCC(섹션 5.1.9.3 참조)를 통해 설정할 수 있는 경우에도 동일하게 타겟 전체에 적용되며, 섹션 5.1.9.4에 명시된 예외 및 제한 사항이 적용됩니다.

이러한 기능이나 다른 구성 가능한 매개변수에 대해, 타겟은 할당된 동적 주소 또는 할당된 그룹 주소로 전송된 Direct SET CCC 명령을 수락(즉, ACK)해야 합니다. 단, 특정 그룹 주소에 대해 Direct CCC 형식이 지원되지 않거나, 특정 Direct CCC 명령이 그룹 주소에 전송될 때 다른 형식을 사용하는 경우는 예외입니다(예: MLANE CCC, 섹션 5.1.9.3.30 참조).

 

 

5.1.2.2 I3C 주소 헤더

I3C 주소 헤더는 START 또는 반복된 START 이후에 따라오며, 형식은 I2C와 동일하게 7비트 주소, 1비트의 RnW, 1비트의 ACK/NACK입니다.

 

START 이후의 주소 헤더는 중재 가능한 주소 헤더로, 섹션 5.1.2.2.1에서 설명한 바와 같이, START와 첫 번째 주소 비트 및 ACK/NACK은 I2C와 유사하게 오픈 드레인 버스 드라이브를 사용하여 SDA에 발행됩니다. 그러나 일부 중재 가능한 주소 헤더는 SDA에서 푸시-풀 방식과 더 높은 속도로 구동될 수 있습니다(섹션 5.1.2.2.2 참조).

 

반복된 START 이후의 주소 헤더는 ACK/NACK을 제외하고 푸시-풀 방식으로 SDA에 항상 구동됩니다(섹션 5.1.2.2.4 참조).

 

I3C 중재 가능한 주소 헤더를 사용하여, I3C 타겟은 I3C 컨트롤러에 세 가지 요청 중 하나를 전송할 수 있습니다:

  1. 인밴드 인터럽트(섹션 5.1.6 참조): 컨트롤러의 주의를 끌기 위해 와이어를 토글하는 것과 유사합니다. 인밴드 인터럽트 요청은 타겟의 동적 주소와 RnW 비트가 1로 설정되어 전송됩니다.
  2. 컨트롤러 역할 요청(섹션 5.1.7 참조): I3C 디바이스는 BCR 레지스터에서 컨트롤러 역할이 가능한 디바이스로 표시되지 않는 한 이 요청을 수행하지 않습니다(섹션 5.1.1.2.1 참조). 컨트롤러 역할 요청은 주 컨트롤러가 역할을 포기한 후 다시 활성 컨트롤러의 역할을 되찾기 위해 보조 컨트롤러 또는 주 컨트롤러에 의해 전송될 수 있습니다. 이 요청은 타겟의 동적 주소와 RnW 비트가 0으로 설정되어 전송됩니다.
  3. 핫 조인 요청(섹션 5.1.5 참조): I3C 타겟은 I3C 버스가 운영 중일 때만 이 요청을 수행할 수 있습니다. 핫 조인 요청은 예약된 핫 조인 주소(7'h02)를 사용하여 전송됩니다.

I3C 타겟은 다음 두 가지 버스 조건에서만 I3C 컨트롤러에 이러한 요청을 할 수 있습니다:

  1. 버스 해제 조건 이후에 START(반복된 START는 아님)가 버스에 발행된 경우(섹션 5.1.3 참조). 타겟은 섹션 5.1.2.2.1에 따른 I3C 주소 중재 규칙을 준수하여 자신의 동적 주소 또는 핫 조인 주소(7'h02)를 전송할 수 있습니다.
  2. 버스 사용 가능 조건(섹션 5.1.3 참조)에 있는 경우, 타겟은 다음과 같은 절차에 따라 START를 발행할 수 있습니다:
    • a. 타겟이 SDA 라인을 Low로 끌어내리면, 컨트롤러는 tCAS 내에서 SCL을 Low로 끌어내려야 합니다(표 86 참조).
    • b. 타겟은 SCL을 Low로 유지하면서 SDA 라인도 Low로 유지할 수 있습니다.
    • c. 컨트롤러가 SCL을 Low로 유지하면, 컨트롤러는 SDA 라인을 오픈 드레인 모드(즉, High로 유지)로 설정해야 합니다.
    • d. 그 후, 타겟은 정상적인 방식으로 주소 헤더를 발행할 수 있습니다(위의 조건 1 참조).

 

5.1.2.2.1 I3C 주소 중재

START(반복된 START는 아님) 이후의 주소 헤더는 중재 대상이 됩니다. 즉, 컨트롤러와 하나 이상의 타겟이 SDA를 사용하여 버스에 주소를 전송하려고 시도할 수 있습니다. 이러한 주소 헤더는 중재 가능한 주소 헤더로 정의됩니다.

중재 모델은 일반적인 오픈 드레인 접근 방식을 따릅니다. 주소를 전송하는 모든 디바이스(컨트롤러 또는 타겟)는 다음 규칙을 따릅니다:

  1. 현재 전송할 비트가 0이면, 디바이스는 SCL의 하강 에지 후에 SDA를 Low로 구동하고, 다음 SCL의 하강 에지까지 Low 상태를 유지해야 합니다. 참고: 다른 디바이스도 SDA를 Low로 구동할 수 있지만, 이는 허용됩니다.
  2. 현재 전송할 비트가 1이면, 디바이스는 SDA를 구동하지 않고 SCL의 하강 에지에서 SDA를 High-Z 상태로 둡니다.
    • a. 또한, 디바이스는 SCL의 상승 에지에서 SDA를 모니터링하여 다른 디바이스가 SDA를 Low로 구동했는지 확인해야 합니다.
    • b. 다른 디바이스가 SDA를 Low로 구동한 경우, 해당 디바이스는 중재에서 '패배'한 것으로 간주하고, 이 주소 헤더에서 더 이상 참여하지 않아야 합니다. 즉, 디바이스는 더 이상 비트를 전송하지 않고, 이후의 START(반복된 START는 아님)를 기다려야 합니다.

 

5.1.2.2.2 I3C 주소 중재(Arbiatation) 최적화

I3C 중재는 이 섹션에서 설명된 대로 선택적으로 최적화할 수 있습니다.

컨트롤러는 버스 초기화 후 첫 번째 I3C 주소 헤더(즉, 7'h7E와 RnW 비트가 0인 START 후)에 대해 이 섹션에서 설명된 최적화 기능을 적용하지 않습니다. 이는 I3C 타겟이 I3C 버스에 연결되었음을 감지하고, 그 결과 스파이크 필터를 비활성화할 수 있도록 허용합니다. 컨트롤러는 해당 I3C 타겟에 스파이크 필터가 없다는 것을 아는 경우 이 요구 사항을 무시할 수 있습니다.

섹션 5.1.2.2에서 설명된 바와 같이, I3C 컨트롤러는 7비트 동적 주소를 7'h03에서 7'h7B 범위 내에 할당합니다. 그러나 I3C 컨트롤러는 9비트 중재 가능한 주소 헤더를 오픈 드레인으로 발행할 때, 타겟 디바이스가 일부(또는 전체) 주소 헤더에 대해 자신의 주소를 전송할 수 있는지 여부를 감지해야 합니다.

인밴드 인터럽트를 요청할 수 있는 I3C 보조 컨트롤러 및 I3C 타겟의 경우, I3C 컨트롤러는 7'h03에서 7'h3F까지의 가용 범위의 하위 절반에 동적 주소를 할당하여 A6 주소 비트 값이 0으로 유지되도록 제한하는 것이 일반적입니다. 인밴드 인터럽트를 요청할 수 없는 다른 I3C 타겟의 경우, I3C 컨트롤러는 가용 범위의 상위 절반(7'h40에서 7'h7B)으로 동적 주소를 제한하여 A6 비트 값이 1로 유지되도록 합니다.

  • 참고:
    • 이 동적 주소 할당 전략은 모든 경우에 적용될 수 있는 것은 아닙니다. 일부 I3C 타겟은 I2C 정적 주소가 있을 때와 같이 가용 범위 내에서 임의의 동적 주소 값을 지원해야 할 수도 있습니다. 또한 SETNEWDA CCC를 지원하지 않는 경우에도 적용이 제한될 수 있습니다(섹션 5.1.9.3.11 참조).

이 방식으로 제한된 동적 주소를 갖는 경우, I3C 컨트롤러는 중재 가능한 주소 헤더를 최적화할 수 있습니다.

  • 컨트롤러가 1값을 전송 중인 경우(즉, SDA에서 High-Z 상태), 컨트롤러는 SCL의 상승 에지에서 SDA를 모니터링하여 다른 타겟이 SDA를 Low로 드라이브했는지 확인할 수 있습니다. SDA가 여전히 1이면(즉, 다른 타겟이 이를 드라이브하지 않은 경우), 컨트롤러는 주소 헤더의 나머지를 푸시-풀 모드로 전송할 수 있습니다.
  • 컨트롤러가 0값을 전송 중이거나 타겟이 SDA를 Low로 드라이브한 경우, I3C 컨트롤러는 오픈 드레인 방식으로 주소 헤더의 나머지를 전송합니다.
  • 컨트롤러가 다른 I3C 디바이스에만 전송하려는 경우(I2C 디바이스가 아닌 경우), 컨트롤러는 SCL 펄스 폭을 50ns로 줄여 버스의 모든 I2C 디바이스가 Low 값을 갖도록 할 수 있습니다. 이렇게 하면 더 높은 데이터 속도를 얻을 수 있습니다.
  • 컨트롤러가 I2C 디바이스에 전송하려는 경우, I2C 타이밍에 따라 느린 속도를 사용해야 합니다.

그림 13의 상단 파형은 이러한 최적화를 보여줍니다. I3C 컨트롤러가 A6 주소 비트에서 1을 전송 중이고, 동적 주소가 있는 모든 타겟이 비트 A6에서 0을 갖도록 보장한 경우, I3C 컨트롤러는 해당 라인이 활성 상태가 아니므로 인밴드 인터럽트 요청이나 컨트롤러 역할 요청이 없음을 알 수 있습니다.

 

 

 

5.1.2.2.3 I3C 타겟 주소로 프레임을 시작하는 컨트롤러의 결과

I3C 컨트롤러는 일반적으로 7'h7E 주소(모든 I3C 메시지의 경우) 또는 레거시 I2C 타겟으로 메시지를 전송할 때 I2C 정적 주소로 프레임을 시작해야 합니다.

이 경우 주소가 중재될 수 있으므로, 컨트롤러는 인밴드 인터럽트 요청, 컨트롤러 역할 요청(즉, 보조 컨트롤러가 활성 컨트롤러가 되기 위한 요청), 또는 핫 조인 요청이 있는지 모니터링해야 합니다.

  • 요청이 없다면 컨트롤러는 정상적으로 진행할 수 있습니다.
  • 요청이 있다면, 컨트롤러는 해당 요청을 ACK 또는 NACK하고 이에 따라 대응합니다.

컨트롤러가 I3C 동적 주소로 I3C 메시지를 시작하려고 하면, 특정 상황을 고려해야 합니다. I3C 타겟이 IBI(In-Band Interrupt) 또는 컨트롤러 역할 요청을 시작할 수 있기 때문입니다. 다음 세 가지 시나리오가 발생할 수 있습니다:

  1. 주소가 일치하지만 RnW 비트에 차이가 있으며, 컨트롤러가 개인 쓰기(RnW = 0)를 시작하려는 동안 타겟은 IBI 요청(RnW = 1)을 시작하려고 했습니다.
    • 이 경우, 컨트롤러가 승리(RnW = 1인 IBI가 패배)하며, 타겟은 IBI를 ACK 또는 NACK하고 나중에 다시 시도할 수 있습니다.
  2. 주소가 일치하지만 RnW 비트에 차이가 있으며, 컨트롤러가 개인 읽기(RnW = 1)를 시작하려는 동안 타겟은 컨트롤러 역할 요청(RnW = 0)을 시작하려고 했습니다.
    • 이 경우, 타겟이 승리(RnW = 1인 개인 읽기가 패배)하며, 컨트롤러는 개인 읽기를 ACK 또는 NACK하고 나중에 다시 시도할 수 있습니다.
  3. 주소와 RnW 비트가 모두 일치하지만, 컨트롤러와 타겟 중 어느 쪽도 ACK하지 않으며, 양쪽 모두 상대가 ACK를 제공할 것으로 예상하기 때문입니다. 이로 인해 양쪽 모두 중재에 "승리"했다고 생각할 수 있지만, 결과적으로 진행을 멈추고 상대가 ACK를 제공하지 않았음을 인식하게 됩니다.
    • a. RnW = 0인 경우(컨트롤러가 개인 쓰기를 시작하고 타겟이 컨트롤러 역할 요청을 시도 중), 컨트롤러는 역할 요청을 보류하고 나중에 다시 시도할 수 있습니다.
    • b. RnW = 1인 경우(컨트롤러가 개인 읽기를 시작하고 타겟이 IBI 요청을 시도 중), 타겟은 IBI 요청을 보류하고 나중에 다시 시도할 수 있습니다.

RnW의 각 값에 대해, NACK으로 인해 컨트롤러는 개인 쓰기 또는 개인 읽기를 보류하고, 반복된 START 후(즉, 중지 후가 아닌 프레임의 동일한 위치에서) 다시 주소 헤더를 전송하는 것이 일반적입니다. 주소 헤더가 중재에서 승리할 것이므로 컨트롤러는 항상 승리하게 됩니다(섹션 5.1.2.2.4 참조).

이 방법은 컨트롤러가 타겟이 동일한 RnW 비트 값을 사용할 것인지 여부를 확인할 수 있게 해줍니다.

 

5.1.2.2.4 반복된 START 이후의 주소 헤더는 Push-Pull 방식

 

I3C 컨트롤러가 반복된 START 이후에 전송하는 주소는 중재되지 않습니다. 즉, 반복된 START 이후에는 어떤 I3C 타겟도 자신의 동적 주소나 예약된 핫 조인 주소(7'h02)를 전송하려고 시도해서는 안 됩니다.

따라서 주소 헤더(즉, 7비트 주소와 RnW 비트)는 레거시 I2C 타겟에 대한 메시지가 아닌 경우, SDA에서 Push-Pull 모드로 전송됩니다. RnW 비트 다음의 ACK/NACK 비트는 타겟이 주소를 ACK 또는 수동으로 NACK할 수 있도록 오픈 드레인 방식으로 유지됩니다.

 

5.1.2.2.5 I3C 타겟 주소 제한

I3C 타겟 주소 공간은 컨트롤러의 결정에 따라 달라집니다. 즉, 컨트롤러는 다음과 같은 필수 및 선택적 제한을 준수하여 동적 주소를 선택할 수 있습니다. 이러한 제한은 표 8에도 나와 있습니다.

  • I3C 컨트롤러는 7'h00, 7'h01, 7'h02, 7'h7E, 7'h7F 주소를 사용하지 않아야 합니다. 이 모든 주소는 I3C용으로 예약되어 있습니다.
  • I3C 컨트롤러는 7'h3E, 7'h5E, 7'h6E, 7'h76, 7'h7A, 7'h7C, 7'h7F 주소를 사용하지 않아야 합니다. 이러한 주소는 금지되어 있으며, I3C 타겟이 이러한 주소 중 하나를 사용한 I3C 주소 헤더를 7'h7E 브로드캐스트 주소와 단일 비트 오류로 해석할 수 있기 때문입니다. 오류 유형 TE0에 대한 자세한 내용은 섹션 5.1.10.1.1을 참조하십시오.
  • I3C 컨트롤러는 I2C에서 예약된 7'h03을 사용하지 않을 수 있습니다.
  • I3C 컨트롤러는 "고속 모드"를 지원하는 레거시 I2C 디바이스가 버스에 있는 경우, 7'h04, 7'h05, 7'h06, 7'h07 주소를 사용하지 않아야 합니다.
  • I3C 컨트롤러는 I2C 디바이스 ID 모드를 지원하는 레거시 I2C 디바이스가 버스에 있는 경우, 7'h7C 또는 7'h7D 주소를 사용하지 않아야 합니다.
  • I3C 컨트롤러는 I2C 확장 주소 모드를 지원하고 확장 주소가 있는 레거시 I2C 디바이스가 버스에 있는 경우, 7'h78, 7'h79, 7'h7A, 7'h7B 주소를 사용하지 않아야 합니다.

5.1.2.3 I3C SDR 데이터 워드

I3C SDR에서 데이터 워드는 길이가 9비트라는 점에서만 I2C와 일치합니다. I3C SDR 데이터 워드는 다음 세 가지 방식에서 I2C와 다릅니다:

요약:

  1. 주소 ACK에서 SDR 컨트롤러 쓰기 데이터로의 핸드오프: SDR 쓰기를 수행할 때, 타겟의 주소 헤더 ACK에서 컨트롤러의 첫 번째 데이터 비트로의 핸드오프는 I3C에서 다릅니다. I2C는 오픈 드레인 방식이므로 ACK Low가 첫 번째 비트로 겹쳐도 무해합니다. 반면 I3C는 푸시-풀 방식을 사용하므로 이 핸드오프가 지정됩니다(섹션 5.1.2.3.1 참조).
  2. SDR 컨트롤러가 쓴 데이터의 9번째 비트는 패리티로 사용: I2C에서는 컨트롤러가 쓴 데이터의 9번째 비트가 타겟의 ACK입니다. 반면 I3C에서는 컨트롤러가 쓴 9번째 데이터 비트가 이전 8비트 데이터 비트의 패리티입니다. 따라서 I3C에서 타겟은 SDA 라인을 구동하지 않으며, 9번째 쓰기 데이터 비트를 T-비트("전환"으로 사용)라고 합니다(섹션 5.1.2.3.2 참조).
  3. SDR 타겟이 반환한(읽은) 데이터의 9번째 비트는 데이터의 끝을 나타냄: I2C에서는 타겟에서 컨트롤러로 전달되는 9번째 비트가 컨트롤러의 ACK입니다. 반면 I3C에서는 이 비트가 읽기를 종료하도록 타겟에 신호를 보내고, 컨트롤러가 읽기를 중단하도록 허용합니다. SDR 용어로, 읽기 데이터의 9번째 비트는 T-비트("전환"으로 사용)라고 불립니다(섹션 5.1.2.3.4 참조).

참고:
타겟은 SCL 클럭이 100μs 이상 변경되지 않은 경우 읽기를 포기하고 SDA를 High-Z로 전환하여 반복된 START 또는 STOP을 대기할 수 있도록 하는 SDA 읽기 검출기를 가져야 합니다.

 

5.1.2.3.1 주소 ACK에서 SDR 컨트롤러 쓰기 데이터로의 전환

모든 주소 헤더의 끝(중재 여부에 관계없이)은 버스의 한 개 또는 여러 타겟이 SDA에서 오픈 드레인 방식으로 ACK 또는 NACK을 수행하는 것입니다.

  • 주소가 7'h7E인 경우, 이는 버스에 있는 모든 I3C 타겟의 ACK입니다.
  • 단일 타겟 주소인 경우, 이는 해당 타겟의 ACK 또는 NACK입니다. 버스에 해당 타겟이 없으면 NACK이 됩니다.

주소 헤더가 ACK로 끝나고 메시지가 컨트롤러의 SDR 쓰기일 때, 첫 번째 데이터 비트에서 SDA 라인을 오픈 드레인에서 푸시-풀로 전환해야 합니다. I3C SDR에서는 안전하게 전환이 이루어지는 방법이 지정되어 있습니다. 아래에 요약된 절차는 그림 142에 표시된 내용을 따릅니다.

  1. I3C 타겟은 ACK 동안 SDA 라인을 Low로 유지합니다(SCL이 Low일 때).
    • 이는 오픈 드레인 SDA Low 기간이어야 합니다.
  2. I3C 타겟이 SCL의 상승 에지를 감지한 후, SDA 라인을 High-Z로 전환합니다.
    • I3C 타겟은 정상적인 타이밍(푸시-풀)을 사용하여 SDA 라인을 해제해야 합니다(SCL이 상승하면 즉시 SDA 라인을 해제).
  3. SCL이 상승한 후, I3C 컨트롤러는 SDA 라인을 Low로 구동합니다.
    • 결과적으로, 컨트롤러와 타겟 모두 짧은 시간 동안 SDA 라인을 Low로 구동하게 되며, 이는 안전합니다.
    • SCL High 기간은 섹션 6.2에 명시된 최소 tDIG_Ht_{DIG\_H}와 같거나 그 이상일 수 있습니다.
  4. SCL의 하강 에지에서 I3C 컨트롤러는 푸시-풀 방식으로 SDA 라인에 데이터를 구동하기 시작합니다(그림 142에 표시됨).

주소 헤더가 NACK으로 끝나는 경우, 컨트롤러는 다음 중 하나를 선택할 수 있습니다:

  1. 반복된 START를 생성하여 트랜잭션을 계속 진행합니다.
  2. 그림 143에 표시된 대로 STOP을 생성하여 버스를 해제합니다.

 

5.1.2.3.2 IBI 동안 주소 ACK에서 필수 바이트로의 전환

 

IBI 요청 중에 발생하는 모든 IBI 주소 헤더의 끝(주소 헤더가 중재 여부와 관계없이)은 컨트롤러가 SDA에서 오픈 드레인 방식으로 ACK 또는 NACK을 수행하는 것입니다.

컨트롤러가 타겟 주소 중 하나를 감지하고, 요청을 수신하기로 선택한 경우, 컨트롤러는 섹션 5.1.6.2에 따라 ACK를 반환합니다.

  • ACK: IBI 타겟 주소 헤더가 ACK로 끝나고, 타겟 디바이스가 필수 바이트를 전송할 수 있는 경우, SDA 라인은 첫 번째 데이터 비트를 위해 오픈 드레인에서 푸시-풀로 전환해야 합니다. 이를 안전하게 전환하기 위해 I3C SDR은 전환 방법을 지정합니다. 아래에 요약된 절차는 그림 14에 표시된 내용을 따릅니다.
    1. I3C 컨트롤러는 ACK 동안 SDA 라인을 Low로 유지합니다(즉, SCL 라인이 Low일 때). 이는 오픈 드레인 SCL Low 기간이어야 합니다.
    2. SCL 라인의 상승 에지 후, I3C 타겟은 가능한 한 빨리 SDA 라인을 Low로 구동합니다. 결과적으로 컨트롤러와 타겟 모두 짧은 시간 동안 SDA 라인을 Low로 구동하게 되며, 이는 안전합니다.
    3. (A) 타겟 디바이스에서 보고된 최소 tSCOt_{SCO} 시간, (B) 모든 타겟이 인계받을 수 있는 안전한 시간, 또는 (C) 컨트롤러가 SDA 라인을 완전히 제어하기 위해 SCL 라인의 다음 하강 에지까지 SDA 라인을 Low로 유지하여 다양한 타겟의 tSCOt_{SCO} 값을 수용할 수 있도록 하는 시간을 고려하여, I3C 컨트롤러는 SDA 라인을 해제합니다. SCL High 기간은 섹션 6.2의 최소 tDIG_Ht_{DIG\_H}와 같거나 그 이상일 수 있습니다.
    4. SCL의 하강 에지에서 I3C 타겟은 푸시-풀 방식으로 SDA 라인에 데이터를 구동하기 시작합니다(그림 14에 표시됨).
  • NACK: 주소 헤더가 NACK으로 끝나는 경우(그림 15에 표시됨), 컨트롤러는 다음 중 하나를 선택할 수 있습니다:
    • 트랜잭션을 계속 진행하여 반복된 START를 생성하거나
    • STOP을 생성하여 버스를 해제합니다.

 

5.1.3 버스 조건

이 사양은 오픈 드레인 풀업(Open Drain Pull-Up)과 하이키퍼(High-Keeper)를 정의하며, I3C 버스가 비활성 상태로 간주되는 세 가지 조건인 Bus Free, Bus Available, 그리고 Bus Idle 상태에 대해서 설명합니다.

 

 

5.1.3.1 오픈 드레인 풀업(Open Drain Pull-Up)과 하이키퍼(High-Keeper)

I3C 컨트롤러 디바이스는 버스가 오픈 드레인 모드일 때 활성 오픈 드레인 클래스 풀업을 제공해야 합니다(예외적인 경우에는 약한 풀업이 사용될 수 있습니다). 이 활성 풀업은 다음 중 한 가지 방법으로 구현되어야 합니다.

  1. VDD 에서의 패시브 저항으로,
  2. 전류 소스에서의 패시브 저항으로,
  3. 또는 다음 두 가지를 모두 수행할 수 있는 방법으로:
    • SDA가 지정된 시간 내에 상승하도록 전류 소싱을 조절함(표 85 참고).
    • 최소 IOL 드라이버(표 82 참고)를 가진 타겟이 지정된 시간 내에 SDA를 Low로 드라이브할 수 없도록 충분히 강하지 않도록 함.

 

활성 오픈 드레인 클래스 풀업 외에도, 버스에는 하이키퍼(High-Keeper)가 필요합니다. 하이키퍼는 일반적으로 컨트롤러에서 타겟 또는 타겟에서 컨트롤러로의 핸드오프를 위해 필요하며, 선택적 종료 시 컨트롤러가 SDA를 Low로 구동하여 High 상태로 멈추는 경우를 위해 사용됩니다.

* 핸드오프(handoff) : 통신 주도권(제어권)을 한 디바이스에서 다른 디바이스로 넘기는 과정을 의미. I3C에서는 컨트롤러와 타겟 간에 신호 라인의 제어권을 주고 받는 상황이 발생할 수 있다. 예를들어, 컨트롤러가 통신을 시작한 후 특정 타겟이 데이터를 전송해야 할 때, 컨트롤러는 SDA와 같은 신호 라인의 제어권을 해당 타겟으로 넘긴다. 이 과정이 핸드오프다. 

**하이키퍼(High-Keeper)는 I3C 또는 I2C와 같은 버스 통신 시스템에서 버스의 신호 라인을 일정한 논리 상태(주로 High 상태)로 유지하기 위해 사용하는 전자 회로 요소입니다. 하이키퍼는 신호 라인이 공중에 뜨지 않고 일정한 상태를 유지하게 함으로써, 전력 소모를 줄이고 신호 안정성을 높이는 역할을 합니다.

 

버스에 있는 하이키퍼는 시스템 누설을 방지하기에 충분히 강해야 하며(예: 모든 디바이스의 누설 전류가 SDA 및 때로는 SCL을 Low로 당기는 것을 방지), 약한 수준이 되어야 타겟이 SDA, SCL 또는 둘 다를 Low로 설정할 수 있습니다.

 

컨트롤러는 버스에 하이키퍼를 제공할 수 있습니다. 컨트롤러가 이를 제공하는 경우, 필요에 따라 하이키퍼를 비활성화하는 방법도 제공할 수 있습니다. 하이키퍼가 충분히 강하지 않거나 현재의 시스템 누설을 지원하기에 적절하지 않은 경우 등 하이키퍼를 비활성화할 이유가 있을 수 있습니다.

 

컨트롤러 제공 하이키퍼는 단일 풀업 디바이스로 구현되거나, 활성 오픈 드레인 클래스 풀업 기능과 약한 하이키퍼 클래스를 모두 지원할 수 있습니다.

컨트롤러는 SCL과 SDA 각각에 대해 별도의 풀업을 사용하거나, 세 가지 풀업 상태(다음 중 하나)로 설정할 수 있습니다.

  1. 풀업 없음(High-Z)
  2. 하이키퍼 풀업
  3. 오픈 드레인 풀업

SDA 및 SCL에는 하이키퍼가 있어야 하며, 충분한 하이키퍼를 제공할 수 없을 경우 외부에서 해결해야 합니다.

 

버스에는 SDA와 SCL에 하이키퍼(High-Keeper)가 있어야 합니다. 컨트롤러가 충분한 하이키퍼를 제공할 수 없을 경우, 시스템 설계자가 이를 외부적으로 해결해야 합니다. 컨트롤러가 충분한 하이키퍼를 제공하지 못하는 이유로는 컨트롤러가 하이키퍼를 지원하지 않거나, 제공되는 하이키퍼가 현재의 필요에 비해 강도가 충분하지 않거나, 버스의 길이가 너무 길어 컨트롤러에서 제공하는 하이키퍼를 사용할 수 없는 경우가 있을 수 있습니다.

 

시스템에서 SCL과 SDA의 하이키퍼는 VDD에 연결된 하나 이상의 패시브 저항으로 구현될 수 있으며, 특정 임계값 이하로 당겨졌을 때 해당 라인을 끄는 액티브 버스 키퍼 디바이스로 구현될 수도 있습니다. SCL과 SDA의 시스템 하이키퍼는 시스템 누설과 I3C 디바이스가 tDIG_L 기간 내에 해당 라인을 Low로 당길 수 있는 요구사항을 균형 있게 맞추도록 크기 조정이 되어야 합니다.

 

참고:

  • 컨트롤러는 오픈 드레인 모드에서 SDA가 이미 High인 경우(즉, SCL이 하강 에지에 들어가고 있음) 오픈 드레인 클래스 풀업을 사용하지 않도록 선택할 수 있습니다. 이 경우, 컨트롤러는 하이키퍼만을 사용하여 타겟이 SDA를 Low로 구동할 때 전력을 적게 사용할 수 있도록 선택할 수 있습니다.

5.1.3.2 버스 조건 타이밍

정지(STOP) 신호 이후, 세 가지 정의된 타이밍 조건이 컨트롤러나 타겟이 시작(START) 신호로 이어지는 정의된 동작을 수행할 수 있는 권한을 생성하는 데 사용됩니다. 이 조건들은 Bus Free Condition(버스 프리 조건), Bus Available Condition(버스 사용 가능 조건), Bus Idle Condition(버스 유휴 조건)입니다. 각 조건의 타이밍은 그림 24에 설명되어 있으며, 각 조건은 아래의 하위 섹션에서 자세히 설명됩니다.

 

5.1.3.2.1 Bus Free Condition (버스 프리 조건)

버스 프리 조건은 정지(STOP) 신호 이후, 시작(START) 신호 이전에 발생하는 일정한 기간으로 정의되며, 다음과 같은 지속 시간이 필요합니다:

  • 순수 버스(Pure Bus)의 경우: 최소 tCAS의 기간 (표 86 참고).
  • 혼합 버스(Mixed Bus)의 경우 (즉, I3C 버스에 하나 이상의 기존 I²C 디바이스가 있는 경우): 최소 tBUF의 기간 (표 85 참고). tBUF 값은 I²C FM 디바이스 또는 I²C FM+ 디바이스가 혼합 버스에 존재하는지 여부에 따라 달라집니다.

5.1.3.2.2 Bus Available Condition (버스 사용 가능 조건)

버스 사용 가능 조건은 버스 프리 조건이 최소 tAVAL 기간 동안 (표 86 참고) 연속적으로 유지되는 기간으로 정의됩니다. 타겟은 버스 사용 가능 조건 이후에만 (예: 인밴드 인터럽트 또는 컨트롤러 역할 요청을 위한) 시작 요청(START Request)을 발행할 수 있습니다.

 

5.1.3.2.3 Bus Idle Condition (버스 유휴 조건)

I3C 버스 유휴 조건은 핫 조인(Hot-Join) 이벤트 동안 버스 안정성을 보장하기 위해 정의되며, SDA와 SCL 라인이 둘 다 최소 tIDLE (표 86 참고) 기간 동안 High 레벨을 유지하는 기간으로 정의됩니다.

 

5.1.3.3 활동 상태(Activity States)

I3C는 컨트롤러가 I3C 버스에서 예상되는 향후 활동 수준에 대해 타겟에게 알림으로써, 타겟이 내부 상태를 더 잘 관리할 수 있도록 돕는 메커니즘을 제공합니다. 0부터 3까지 네 가지 활동 상태 레벨이 정의되어 있습니다(표 11 참고).

 

 

활동 상태(Activity State) 번호는 타겟에게 힌트를 제공하여, 컨트롤러가 해당 타겟에게 버스 활동을 지시하기까지 걸리는 예상 시간을 나타내며, 타겟이 In-Band Interrupt 요청 또는 컨트롤러 역할 요청을 위해 SDA를 Low로 끌어내릴 때 응답하는 데 필요한 대기 지연 시간을 줄이는 데 도움을 줍니다.

 

컨트롤러는 네 가지 예상되는 버스 활동 상태를 타겟에 전달하기 위해 CCC 명령인 ENTAS0, ENTAS1, ENTAS2, ENTAS3(섹션 5.1.9.3.2 참고)를 사용합니다. 각 ENTASx CCC는 브로드캐스트 버전과 Directed(타겟별) 버전이 있으며, 컨트롤러는 적절한 ENTASx CCC 명령을 통해 언제든지 다른 활동 상태로 전환할 수 있습니다.

 

이 네 가지 Direct CCC(그림 34)와 네 가지 Broadcast CCC(그림 35)는 활성 컨트롤러가 하나 이상의 타겟 디바이스에게 I3C 버스에서 일정 기간 동안 활성 상태가 되지 않을 것임을 알리도록 합니다. 이를 통해 타겟 디바이스는 그 기간 동안 더 낮은 전력 상태를 사용할 수 있습니다(섹션 5.1.3.3 참고). 활동 상태(Activity State)당 하나의 Direct CCC와 하나의 Broadcast CCC가 있습니다. 참고: 이 CCC들은 타겟 디바이스에 대한 요구사항을 부과하지 않습니다. 단지 활성 컨트롤러가 비활성 상태, 즉 더 낮은 전력 상태가 될 의도를 신호로 전달할 뿐입니다. 그러나 모든 I3C 타겟 디바이스는 활성 컨트롤러의 상태에 관계없이 모든 활동 상태에서 I3C 통신 기능을 유지해야 합니다.

 

타겟은 수신한 활동 상태 힌트를 사용하여 전력 절감, FIFO 트리거 수준, 타임스탬프 카운터 및 클럭 속도 등의 내부 설정을 조정할 수 있습니다. 그러나 타겟은 ENTASx CCC를 지원할 필요가 없으며, 무시할 수도 있습니다.

 

활동 상태 메커니즘은 컨트롤러와 타겟 간의 일반적인 합의를 위한 기초로, 타겟이 일반적인 시간 프레임보다 이른 접근을 NACK할 수 있습니다. 예를 들어, 컨트롤러가 ENTAS2 CCC를 전송하여 2ms 이내에 요청을 시작하지 않을 것임을 암시한 경우, 그보다 이른 요청이 오면 타겟은 이를 NACK할 수 있습니다.

 

활동 상태 CCC는 I3C 버스 타이밍 파라미터 tCAS를 조정하여, 타겟이 SDA를 Low로 끌어내린 후 컨트롤러가 SCL 클럭을 생성하기 위해 최대 시간을 지정합니다.

 

활동 상태는 특정 전력 모드로 전환하는 역할이 아니라, 컨트롤러와 타겟 간의 사전 협약에 따라 버스의 활동 수준을 조정하는 것입니다.

 

 

'Other Protocols' 카테고리의 다른 글

Common Command Codes (CCC)  (0) 2024.11.26
(3) I3C - Bus Initialization Sequence with Dynamic Address Assignment  (1) 2024.11.21
Open drain 방식과 Push pull 방식  (0) 2024.11.12
(1) MIPI I3C Basic Specification - Overview  (1) 2024.11.11
I3C (Improved Inter-Integrated Circuit) Protocol  (1) 2024.11.08

'Other Protocols'의 다른글

  • 현재글(2) MIPI I3C Basic Specification - I3C Protocol

관련글

티스토리툴바