[ESL Modeling 5] Transaction-level Modelling (2)

OSCI TLM 2.0 Standard

 

SystemC 1.0에서는 채널을 통해 스레드를 전달하고, Net 모델링을 위해 설계된 인프라를 따라 서브루틴 호출을 할 수 있는 제한적인 기능이 있었습니다. 하지만 SystemC 2.0에서는 이 작업이 훨씬 더 쉬워졌습니다. TLM 2.0 (2008년 7월)에서는 TLM 1.0의 인터페이스 상속 문제를 해결하기 위해 TLM convenience socket을 제공했습니다. 이 소켓들은 Table 5.1에 나와 있습니다. 또한, TLM generic payload를 정의하여 IP 블록 벤더 간의 호환성을 촉진했습니다. 이 외에도 메모리/가비지 소유권과 타이밍 및 RAM 모델에 대한 빠른 백도어 접근을 위한 전송 원리를 정의했습니다.

 

TLM 2.0에서는 특정 애플리케이션에 맞춘 메서드 이름 대신, 일반적인 버스 동작에 중점을 둡니다. 개별 기능은 실제 하드웨어에서처럼 주소 필드를 기반으로 디스패칭(전달)하여 이루어집니다. 즉, 리셋 및 쓰기와 같은 다양한 기능을 위해 타겟 IP 블록 내의 다른 주소 지정 가능한 레지스터/메서드가 존재합니다.

TLM 2.0 generic payload structure (left) and interconnection of three IP blocks showing passthrough and demultiplexing (right)

---

Generic payload는 TLM 2.0에서 데이터 전송을 표준화하고 호환성을 높이기 위해 도입된 데이터 구조입니다. 이를 이해하려면 몇 가지 주요 개념을 알아야 합니다.

1. 데이터 패킷 (Payload): Generic payload는 데이터를 담고 있는 패킷이라고 생각할 수 있습니다. 이 패킷은 메모리에서 하나의 레코드(즉, 구조체 또는 객체)로 표현됩니다.
2. 다양한 정보 포함: Generic payload에는 다양한 정보가 포함됩니다. 예를 들어, 데이터의 주소, 데이터 자체, 명령 종류(읽기, 쓰기 등), 데이터의 길이, 바이트 활성화 정보, 스트리밍 너비 등이 있습니다. 이 정보들은 전송할 데이터와 그 데이터를 어떻게 처리할지를 나타냅니다.
3. 소켓 간의 데이터 전달: Generic payload는 SystemC TLM 모델에서 소켓을 통해 IP 블록 간에 전달됩니다. 예를 들어, 하나의 IP 블록(initiator)이 다른 IP 블록(target)에 데이터를 읽거나 쓰기 위해 generic payload를 생성하여 소켓을 통해 전달합니다.
4. 확장 가능성: Generic payload는 기본적으로 TLM 2.0에서 제공하는 필드 외에도 사용자 정의로 확장될 수 있습니다. 예를 들어, 특정한 버스 프로토콜이나 하드웨어 특성에 맞게 추가 필드를 정의할 수 있습니다. 이 추가 필드는 기본적인 TLM 2.0 기능을 확장하여 더 복잡한 데이터 전송을 처리할 수 있게 합니다.
5. 타입 안정성: C++의 강력한 타입 시스템 덕분에, generic payload는 타입 안정성을 유지하면서 여러 종류의 데이터 구조를 처리할 수 있습니다. 예를 들어, USB 요청 블록(URB), 네트워크 프레임, 캐시 라인 등 다양한 데이터 구조를 모두 generic payload를 통해 처리할 수 있습니다.
6. 실제 하드웨어 동작 반영: Generic payload의 구조와 사용 방식은 실제 하드웨어의 버스 동작과 유사하게 설계되었습니다. 예를 들어, 주소 필드를 기반으로 하드웨어의 특정 레지스터를 접근하듯이, generic payload를 통해 메모리의 특정 주소에 접근할 수 있습니다.

결론적으로, generic payload는 TLM 2.0에서 다양한 하드웨어 IP 블록 간의 데이터 전송을 표준화하고, 서로 다른 IP 블록 간의 상호 운용성을 보장하기 위해 설계된 유연하고 확장 가능한 데이터 구조입니다. 이를 통해 복잡한 SoC 설계에서 모듈 간 통신을 보다 쉽게 구현할 수 있습니다.

 

이 그림은 TLM 2.0에서 사용되는 generic payload와 소켓을 이용한 데이터 전송 구조를 보여줍니다.

### 1. **Generic Payload (C 구조체)**
   그림의 왼쪽 부분에는 Generic Payload에 포함되는 주요 필드들이 나와 있습니다. 이 필드들은 C 구조체로 표현되며, 다음과 같은 구성 요소로 이루어져 있습니다:
   - **Command**: 수행할 명령을 나타냅니다. 예를 들어, 읽기, 쓰기, 로드-링크드, 스토어-컨디셔널 등이 있습니다.
   - **Address**: 데이터를 읽거나 쓸 메모리 주소를 나타냅니다.
   - **Data pointer**: 전송할 데이터가 저장된 메모리 주소를 가리키는 포인터입니다.
   - **Data length**: 전송할 데이터의 길이를 나타냅니다.
   - **Byte lane info ptr**: 바이트 레인 정보를 가리키는 포인터로, 전송되는 데이터의 활성화된 바이트를 나타냅니다.
   - **Response**: 명령이 성공적으로 수행되었는지에 대한 응답 상태를 저장합니다.
   - **Misc + Extensions**: 기타 확장 정보를 포함할 수 있는 필드로, 특정 사용 사례에 맞게 확장할 수 있습니다.

### 2. **시스템 구성 요소**
   그림의 오른쪽 부분은 TLM 2.0 시스템에서의 데이터 흐름을 보여줍니다. 주요 구성 요소는 다음과 같습니다:
   - **Initiator (cpu0)**: 데이터를 전송하거나 요청하는 주체입니다. 예를 들어, CPU와 같은 장치가 될 수 있습니다.
   - **Intermediate Component (bus/cache)**: 데이터가 전송되는 경로에서 중간 역할을 하는 버스 또는 캐시 같은 컴포넌트입니다. 이 예제에서는 "busmux0"라는 이름으로 표시되어 있습니다.
   - **Targets (memory1, I/O dev0)**: Initiator가 데이터를 전송하는 목적지입니다. 예를 들어, 메모리나 I/O 장치 등이 될 수 있습니다.

### 3. **데이터 전송 흐름**
   - **Payload 전송**: Initiator는 generic payload를 생성하고, 포인터를 통해 Intermediate Component로 전달합니다. 이 과정에서 payload 자체는 복사되지 않으며, 포인터로 전달되어 효율성을 높입니다.
   - **Data Packet**: 실제 데이터는 payload 안에 포함되지 않고, payload가 가리키는 메모리 주소를 통해 접근됩니다.
   - **Command**: Initiator는 읽기/쓰기 등의 명령을 실행하며, 이 명령은 주소 필드를 통해 구체적인 메모리 주소 또는 장치에 전달됩니다.
   - **Delay 변수**: 이 변수는 Initiator 스레드에 의해 관리되지만, 다른 구성 요소도 이 변수를 증가시키거나 EDS(Embedded Design Suite) 커널과 동기화할 수 있습니다.

### 요약
이 그림은 TLM 2.0에서 generic payload를 이용하여 Initiator가 Intermediate Component를 통해 메모리 또는 I/O 장치와 통신하는 과정을 보여줍니다. Generic payload는 효율적인 데이터 전송을 위해 포인터로 전달되며, 각 구성 요소는 payload를 수정하거나 참조하여 필요한 작업을 수행합니다.

---

Generic payload는 메모리 내의 기록이며, 소켓을 통해 메서드 호출 시 인자로 참조로 전달됩니다. 오른쪽 그림에서는 세 개의 IP 블록(initiator, passthrough, target)이 보여집니다. Initiator 스레드는 호출과 반환을 통해 다른 두 블록의 코드를 실행합니다. 각 블록은 generic payload를 검사하고 수정할 수 있습니다. Generic payload의 필드는 아래 그림에 나와 있는 코드와 같은 방식으로 설정할 수 있습니다.

 

소켓 자체는 어떤 유형의 payload도 처리할 수 있지만, C++의 강력한 타입 검사는 모든 연결된 사이트가 일치하도록 보장합니다. 캐시 라인, USB 요청 블록(URBs), 802.3 네트워크 프레임, 오디오 샘플과 같은 형식이 일반적인 예입니다. Generic payload는 사용자 정의로 확장할 수 있으며, 중간 버스 브리지 및 라우터는 모든 확장을 알 필요 없이 다형성(polymorphism)을 가질 수 있습니다. Generic payload는 버스트 전송 및 바이트 레이닝(byte laning)과 같은 고급 기능을 포함하지만, 명령 필드는 읽기와 쓰기만을 다루는 열거형을 사용합니다. 이 명령 세트는 현대 SoC interconnect에서 사용하는 풍부한 명령 세트에 비해 매우 부족하므로 실제 사용에서는 비표준 확장이 항상 필요합니다.

예제로 작은 SRAM을 버스 타겟으로 연결하는 상황을 고려해 봅시다. 이는 SC_MODULE로 정의된 클래스입니다. 첫 번째 단계는 .h 파일에서 타겟 소켓을 정의하는 것입니다:

SC_MODULE(cbgram)
{
tlm_utils::simple_target_socket <cbgram> port0;
...

 

여기에는 생성자가 포함되어 있습니다:

 

cbgram::cbgram(sc_module_name name, uint32_t mem_size, bool tracing_on, bool dmi_on):
sc_module(name), port0("port0"),
latency(10, SC_NS), mem_size(mem_size), tracing_on(tracing_on), dmi_on(dmi_on)
{
mem = new uint8_t [mem_size]; // 메모리를 할당하여 내용을 저장합니다.
// b_transport 인터페이스 메서드 호출을 처리하는 콜백을 등록합니다
port0.register_b_transport(this, &cbgram::b_transact);
}

 

생성자는 소켓과 다양한 콜백을 등록합니다. 이 경우, b_transact라는 차단(b_transport) 진입점을 등록했습니다. 이 코드는 다음과 같이 정의됩니다:

 

void cbgram::b_transact(tlm::tlm_generic_payload &trans, sc_time &delay)
{
tlm::tlm_command cmd = trans.get_command();
uint32_t adr = (uint32_t)trans.get_address();
uint8_t * ptr = trans.get_data_ptr();
uint32_t len = trans.get_data_length();
uint8_t * lanes = trans.get_byte_enable_ptr();
uint32_t wid = trans.get_streaming_width();
if (cmd == tlm::TLM_READ_COMMAND)
{
ptr[0] = mem[adr];
}
else ...
trans.set_response_status(tlm::TLM_OK_RESPONSE);
}

 

이것이 작동하는 최소한의 C++ 코드입니다. 인스턴스화하는 쪽에서 bind 메서드를 사용하여 initiator를 타겟에 연결합니다. bind 메서드를 호출하면 소켓 인스턴스 간의 연결 토폴로지가 설정됩니다. 코딩 스타일은 SystemC 구조적 넷리스트와 동일합니다. 인스턴스 명명 방식을 따르면, 필요한 코드는 다음과 같습니다:

 

busmux0.init_socket.bind(memory0.port0);
busmux0.init_socket.bind(memory1.port0);
busmux0.init_socket.bind(iodev0.port0);

 

Table 5.1에는 TLM 2.0이 정의한 편의 소켓의 세트가 나와 있습니다. 동일한 유형의 포트가 여러 개 존재하는 문제는 멀티 소켓으로 해결됩니다. 이 소켓들은 위의 코드처럼 여러 번 바인딩할 수 있습니다. Passthrough 소켓은 generic payload 참조를 다음 TLM 호출로 전달할 수 있습니다. 이것은 interconnect 컴포넌트가 플릿(flit)을 전달하는 동작을 직접 반영합니다. Initiator는 서브스크립션 연산자의 오버로드에 정수를 제공하여 멀티 포트 중 어느 바인딩에 메시지를 전달할지 지정합니다:

 

int n = ...; // 메시지를 전달할 바인딩
output_socket[n]->b_transport(trans, delay);

 

차단 전송 메서드뿐만 아니라, 소켓은 비차단(non-blocking) 대응 메서드를 호출하고 등록할 수 있습니다. 소켓은 필요한 타겟이 등록되지 않은 경우 호출을 다른 형태로 매핑합니다. 또한 타겟이 initiator에서 메서드를 호출할 수 있는 역방향 채널도 있습니다. 이는 L1을 initiator로 구성하여 L2에 작업을 수행하도록 하는 캐시 스누프 및 라인 무효화와 같은 작업에 특히 유용합니다.