SystemC는 원래 하드웨어의 상세한 net-level 모델링을 위해 설계되었지만, 현재는 주로 다음과 같은 용도로 사용됩니다:
- Architectural Exploration: SoC의 다양한 아키텍처를 빠르고 간단하게 고수준 모델로 만들어, 버스 폭, 캐시 메모리 크기와 같은 다양한 요소에 대한 성능 변화를 탐색하는 데 사용됩니다.
- Transaction-Level ESL Models (TLM): 하드웨어의 handshaking 프로토콜과 net-level 모델링을 더 높은 수준의 모델들 간의 서브루틴 호출로 대체하여 시스템을 모델링합니다.
- Synthesis: SystemC 소스 코드를 RTL로 합성하는데, 이는 SystemC의 RTL 구조를 사용하거나 고수준 합성(high-level synthesis)을 통해 이루어집니다.
두 가지 코딩 스타일
OSCI(Open SystemC Initiative)에서는 두 가지 코딩 스타일을 권장했습니다: 1.0과 2.0입니다. 1.0 표준은 이해하기 약간 더 쉽지만, 2.0 표준이 현재 더 널리 사용되며 상호 운용성이 뛰어납니다. 두 가지 표준을 모두 소개하는 이유는 1.0이 중요한 개념을 잘 보여주기 때문입니다.
각 표준은 blocking과 non-blocking 트랜잭션을 모두 지원하지만, 2.0 라이브러리는 blocking과 non-blocking 스타일 간의 상호작용을 지원하고, back channel과 같은 여러 추가 기능을 제공합니다. 2.0 릴리즈에서는 sc_export라는 확장이 구현되었으며, 이를 통해 상위 모듈이 자식 모듈 중 하나의 인터페이스를 상속받을 수 있습니다. 이 기능은 일반적으로 연결된 모듈이 최상위 모듈이 아닌 경우에 매우 중요합니다. 또한, 구조적 netlist에서 구성 요소 간의 연결에 사용된 동일한 바인딩 메커니즘이 TLM 호출을 연결하는 데도 사용될 수 있습니다.
예시: Transactional Protocol
Figure 5.10은 net-level과 TLM 레벨에서 구현된 simplex 데이터 흐름에 대한 트랜잭셔널 프로토콜의 예시입니다. 이 예시에서는 두 가지 TLM 구현 변형이 있으며, TLM initiator가 데이터의 소스나 싱크 역할을 할 수 있음을 보여줍니다.
이러한 다양한 스타일과 기능 덕분에 SystemC는 하드웨어와 시스템 설계에서 매우 유연하고 강력한 도구로 자리 잡고 있으며, 고수준 모델링부터 세부적인 합성까지 광범위하게 사용되고 있습니다.
locking과 Non-blocking은 하드웨어 모델링과 프로그래밍에서 매우 중요한 개념이며, 특히 **Transaction-Level Modelling (TLM)**에서 자주 사용됩니다. 이 개념들은 데이터 전송을 처리할 때의 동작 방식을 정의하며, 각각의 차이점은 시스템의 성능과 동작 방식에 큰 영향을 미칠 수 있습니다.
Blocking
Blocking 방식은 데이터가 전송될 때, 그 트랜잭션이 완료될 때까지 프로세스가 멈추는 방식입니다. 즉, 데이터 전송이 완료되기 전까지 다른 작업을 수행하지 않고 기다려야 합니다.
- 특징:
- 동기식(synchronous): 데이터 전송이 끝날 때까지 기다리므로, 프로세스가 순차적으로 진행됩니다.
- 코드 구조가 간단: blocking 방식은 코드가 순차적으로 실행되기 때문에 이해하기 쉽고, 코드 구조가 단순합니다.
- 낮은 병렬 처리 효율: 트랜잭션이 끝날 때까지 기다려야 하므로, 전체 시스템의 병렬 처리 효율이 떨어질 수 있습니다.
Non-blocking
Non-blocking 방식은 데이터 전송을 요청한 후, 트랜잭션이 완료되기를 기다리지 않고 다른 작업을 계속 수행할 수 있는 방식입니다. 즉, 트랜잭션이 비동기적으로(asynchronous) 진행됩니다.
- 특징:
- 비동기식(asynchronous): 트랜잭션이 진행되는 동안 다른 작업을 수행할 수 있습니다.
- 병렬 처리 효율이 높음: 여러 작업이 동시에 진행될 수 있어, 시스템의 병렬 처리 효율이 높아집니다.
- 복잡한 코드 구조: 비동기적 처리가 가능하므로 코드 구조가 복잡해질 수 있으며, 동기화 문제를 신경 써야 합니다.
- Blocking: 트랜잭션이 완료될 때까지 프로세스가 멈추며, 코드가 단순하지만 병렬 처리 효율이 떨어질 수 있습니다.
- Non-blocking: 트랜잭션이 진행되는 동안 다른 작업을 수행할 수 있으며, 병렬 처리 효율이 높지만 코드가 복잡해질 수 있습니다.
두 방식은 각각의 장단점이 있으며, 시스템의 요구사항에 따라 적절히 선택하여 사용됩니다. 예를 들어, 시스템 성능이 중요한 경우 non-blocking 방식을 사용해 병렬 처리를 극대화할 수 있고, 코드의 단순성과 이해도가 중요한 경우에는 blocking 방식을 선택할 수 있습니다.
OSCI TLM 1.0 Standard
OSCI TLM 1.0 Standard는 주로 C++의 다중 상속(multiple inheritance) 개념을 사용한 코딩 스타일입니다. 이 표준에서는 SC_MODULE이 인터페이스를 구현할 때, C++ 상속 메커니즘을 사용하여 해당 인터페이스를 상속받습니다. TLM 1.0에서 사용되는 중요한 개념들과 그에 따른 문제점 및 개선점에 대해 설명하겠습니다.
1. TLM 1.0의 기본 개념
- 인터페이스와 상속: TLM 1.0에서는 하드웨어의 read와 write와 같은 인터페이스가 C++ 가상 클래스(virtual class)로 정의됩니다. 각 인터페이스는 하나 이상의 호출 가능한 메서드를 가지고 있습니다. 예를 들어, write 인터페이스는 데이터를 전송하기 위한 두 개의 메서드를 가질 수 있습니다.
- Net-level과 TLM의 차이: Net-level 구현에서는 데이터 버스와 핸드셰이크(handshake) 신호를 사용하여 데이터 전송과 흐름 제어를 구현하지만, TLM에서는 이러한 신호가 메서드 호출로 대체됩니다. 즉, 데이터를 전송하거나 수신하는 행위가 메서드 호출과 반환으로 처리됩니다.
- 블로킹(Blocking)과 논블로킹(Non-blocking) 트랜잭션: TLM 1.0은 블로킹과 논블로킹 트랜잭션을 모두 지원합니다. 블로킹 메서드는 SC_THREAD로 호출해야 하며, 논블로킹 메서드는 SC_METHOD로 호출할 수 있습니다.
2. TLM 1.0의 장점
- 속도: TLM 1.0은 Net-level 모델링에 비해 훨씬 빠릅니다. TLM 구현은 EDS(Event-Driven Simulation) 커널에 들어가지 않으며, 계산된 점프(computed jump)를 사용하지 않기 때문에 파이프라인 스톨이 발생하지 않습니다. 이로 인해, TLM은 Net-level 모델링보다 최대 1000배 더 빠를 수 있습니다.
3. TLM 1.0의 단점 및 문제점
- 시간과 에너지 모델링 부족: TLM 1.0에서는 시간 개념이 없으며, 트랜잭션 중에 발생하는 네트워크의 변화에 따른 에너지 소비를 동적으로 모델링하는 것이 불가능합니다. 시스템 클럭과 클럭 트리의 개념도 이 모델링 수준에서는 존재하지 않습니다.
- Payload 표준화의 부재: TLM 1.0에는 표준화된 payload 구조가 없어서, 다양한 회사에서 각각의 표준 버스 구조를 채택하게 되었습니다. 이로 인해, SoC를 조립할 때 IP 블록 모델 간의 호환성 문제가 발생할 수 있습니다.
- 다중 인터페이스 인스턴스의 문제: 하나의 컴포넌트에서 동일한 타입의 인터페이스를 여러 번 인스턴스화하는 것은 하드웨어 설계에서 일반적인 요구사항이지만, TLM 1.0에서는 이러한 기능을 지원하지 않습니다. 이를 해결하기 위해 인터페이스 사양에 가짜 타입 매개변수를 추가하는 우회 방법을 사용했지만, 이는 매우 비효율적이고 보기에도 좋지 않았습니다.
- Blocking과 Non-blocking 선택 문제: 특정 메서드가 블로킹인지 논블로킹인지를 선택해야 하는데, initiator와 target이 동일한 스타일을 사용하는 데 동의해야 했습니다. 또는 target이 두 가지 형태를 모두 제공해야 했습니다. 이는 코딩 복잡성을 증가시켰습니다.
4. TLM 2.0에서의 개선점
TLM 2.0에서는 TLM 1.0에서 발생한 여러 문제를 해결하기 위해 TLM 소켓이라는 개념을 도입했습니다. TLM 소켓은 경량 라이브러리 코드로 구현되어, 블로킹과 논블로킹 메서드 간의 차이, payload 구조의 표준화 부족, 다중 인터페이스 인스턴스화의 어려움 등을 해결했습니다.
TLM 1.0은 C++의 다중 상속 개념을 사용해 하드웨어를 모델링하는 표준으로, 속도 면에서 매우 효율적입니다. 그러나 시간과 에너지 모델링, 인터페이스의 다중 인스턴스 문제, 블로킹과 논블로킹 트랜잭션 처리의 복잡성 등 몇 가지 문제점이 있었습니다. TLM 2.0에서는 이러한 문제를 해결하기 위해 TLM 소켓이라는 개념을 도입하여, 모델링의 편의성과 호환성을 크게 향상시켰습니다.
Net-level과 TLM(Transaction Level Modelling)을 구현한 코드 예제를 각각 보여드리겠습니다. 이 예제에서는 간단한 FIFO(First In, First Out) 버퍼를 Net-level과 TLM 방식으로 구현해보겠습니다.
1. Net-level 구현 예제
Net-level에서는 데이터 전송을 위해 명시적인 핀과 신호를 사용하며, 핸드셰이크 신호를 통해 데이터 전송이 이루어집니다.
이 Net-level 구현에서는 clk, reset, din, dout과 같은 명시적인 핀과 신호를 사용하여 데이터가 전송됩니다. 데이터 전송 과정에서 핸드셰이크 신호를 사용하여 흐름 제어가 이루어집니다.
2. TLM 구현 예제
TLM에서는 명시적인 신호 대신 메서드 호출로 데이터 전송이 이루어집니다. 이는 더 높은 추상화 수준에서 모델링되며, 성능이 크게 향상됩니다.
이 TLM 구현에서는 tlm_fifo_if 인터페이스를 사용해 FIFO 모듈을 정의하고, 데이터를 write와 read 메서드로 전송합니다. tlm_writer와 tlm_reader 모듈은 각각 데이터를 FIFO에 쓰고, FIFO로부터 읽습니다. 여기서 명시적인 신호나 핀은 사용되지 않으며, 단순한 메서드 호출로 트랜잭션이 처리됩니다.
요약
- Net-level 구현은 명시적인 신호와 핸드셰이크를 사용해 데이터를 전송하며, 더 낮은 추상화 수준에서 모델링됩니다. 이 방식은 더 많은 세부 사항을 다루지만, 성능이 낮을 수 있습니다.
- TLM 구현은 메서드 호출로 데이터를 전송하며, 높은 추상화 수준에서 모델링됩니다. 이 방식은 성능이 훨씬 뛰어나지만, 시간이나 에너지 모델링을 포함하지 않으므로 특정 세부 사항을 다루기 어렵습니다.
이 두 방식은 각각의 장단점이 있으며, 설계 요구사항에 따라 적절한 방식을 선택해 사용합니다.
'IT' 카테고리의 다른 글
| Cache의 기초 (1) | 2024.08.30 |
|---|---|
| [ESL Modeling 5] Transaction-level Modelling (2) (0) | 2024.08.29 |
| [ESL Modeling 3] SystemC Modelling Library (1) | 2024.08.29 |
| [ESL Modeling 2] Interconnect Modelling (1) | 2024.08.29 |
| [ESL Modeling 1] Modeling Abstractions (0) | 2024.08.29 |