[ESL Modeling 1] Modeling Abstractions

Modeling Abstractions

SoC는 하드웨어와 소프트웨어를 결합하여 다양한 인터페이스를 통해 외부와 통신합니다. SoC의 설계 과정에서는 설계 입력부터 제조에 이르기까지 모든 단계를 지원하는 모델링 시스템이 이상적입니다. 그러나 SoC 전체를 세부적으로 모델링하고 운영 체제 부팅을 합리적인 시간 내에 시뮬레이션하는 것은 불가능합니다. 예를 들어, 실제 하드웨어보다 백만 배 느린 모델은 10초간의 부팅 시퀀스를 시뮬레이션하는 데 115일이 걸릴 것입니다! 따라서 ESL 가상 플랫폼은 여러 수준의 추상화된 모델링을 지원하고, 이들 사이의 상호작용을 가능하게 해야 합니다.

대부분의 ESL 모델은 이벤트 기반 시뮬레이션(EDS: Event-Driven Simulation)을 바탕으로 만들어집니다. EDS 시뮬레이터는 다양한 유형의 이산 이벤트를 정의하고, 시뮬레이션은 시간 영역에서 이벤트의 진행을 따라갑니다. 모델링의 주요 차이점은 주로 사용되는 이벤트의 유형입니다. 예를 들어, 개별 디지털 네트의 상태 변화부터 전체 Ethernet 패킷의 전달까지 다양합니다. 즉 사용하고자 하는 Application에 따라 Abstraction 의 수준이 결정이 됩니다. 보고자 하는 부분은 Low Level 이 될 것입니다.

모델링 수준의 전체적인 분류는 다음과 같습니다:

 

1. Functional modelling: 시뮬레이션의 출력이 정확합니다. 기능적 모델링(Functional Modelling)에서는 내부 구조가 실제 SoC와 같을 필요는 없고, 중요한 것은 최종 출력이 동일하게 나오는 것입니다. 즉, 이 모델은 SoC가 해야 할 동작을 제대로 수행하고 있는지 확인하기 위한 것으로, 내부의 구현 방식보다는 외부로 나타나는 결과가 정확한지를 중점으로 합니다. 이렇게 하면 SoC의 기본 동작을 확인하고 설계 초기 단계에서 큰 틀을 잡는 데 유용합니다.
2. Memory-accurate modelling: 메모리의 내용과 레이아웃이 정확합니다.
3. Cycle lumped or untimed TLM: IP 블록 간의 데이터 전달과 같은 완전한 트랜잭션이 원자적(atomic) 이벤트로 모델링됩니다. 트랜잭션에 타임스탬프가 기록되지 않습니다. 프로그램 실행 후 사이클 수는 정확하지만, 개별 사이클은 모델링되지 않습니다. 일반적으로 서브 모델이 일정 작업을 수행한 후 사이클 수를 업데이트합니다.
4. Stochastic or loosely timed TLM: 트랜잭션 수는 정확하지만 순서가 틀릴 수 있으며, 표준 큐잉 모델을 기반으로 각 트랜잭션에 타임스탬프가 부여됩니다. 따라서 전체 실행 시간이 보고될 수 있습니다.
5. Approximately timed TLM: 트랜잭션 수와 순서가 정확하며, 그들이 겹치거나 방해되는 정도를 측정합니다.
6. Cycle-accurate simulation: 사용된 클럭 사이클 수가 정확하고, 각 클럭 사이클에서 수행된 작업이 정확하게 모델링됩니다. 합성 가능한 RTL 시뮬레이션이 이러한 모델을 제공합니다.
7. Net-level EDS: 서브시스템의 네트리스트가 완전히 모델링되며, 클럭 사이클 내에서 네트 변화의 순서가 정확합니다.
8. Analogue and mixed-signal simulation: 특정 노드의 전압 파형이 모델링됩니다.

이러한 모델링 수준을 더 자세히 설명하기 전에, 추가로 정의할 가치가 있는 두 가지 용어가 있습니다:

1. Programmer-view accuracy: 이 모델은 프로그래머가 볼 수 있는 메모리와 레지스터의 내용을 정확하게 반영합니다. 프로그래머의 관점(PV)은 소프트웨어 프로그래머가 명령어로 조작할 수 있는 구조적으로 중요한 레지스터만 포함합니다. 특정 하드웨어 구현의 다른 레지스터, 예를 들어 파이프라인 단계와 구조적 위험을 극복하기 위한 홀딩 레지스터 등은 PV 모델에 포함되지 않습니다. PV 모델이 시간 개념을 포함하면, 이를 PV+T라고 합니다. 비슷하게, PV+ET는 에너지와 시간 사용을 모델링하는 것을 의미합니다.
2. Behavioral modelling: 이 용어는 정확한 정의가 없지만, 일반적으로 실제 구현과는 다른 시뮬레이션 모델을 나타냅니다. 예를 들어, 특정 구성 요소나 서브시스템의 행동을 모델링하기 위해 핸드크래프트된 프로그램이 작성될 수 있습니다. 보다 구체적으로는, 소프트웨어 프로그래밍과 같이 명령형 스레드를 사용하여 구성 요소의 동작을 표현하는 모델을 의미할 수 있습니다.

일부 애플리케이션 클래스에서는 SoC의 시작점이 SoC가 생성해야 할 출력과 동일한 출력을 생성하는 소프트웨어 프로그램일 수 있습니다. 이것이 Functional model입니다. 예를 들어 IoT 장치의 경우, 이 모델은 네트워크를 통해 동일한 응답을 제공해야 합니다. RF 송신기 서브시스템의 경우, 실제 안테나에 전달할 아날로그 파형을 모델링 워크스테이션의 파일에 기록할 수 있습니다. 이러한 모델은 SoC 구현의 구조를 전혀 나타내지 않지만, 필요한 기본 동작을 정의하고 SoC 기반 솔루션과 생태계의 나머지 부분을 평가하는 데 사용할 수 있는 참조 데이터를 제공합니다.

SoC는 일반적으로 대량의 메모리를 포함합니다. 다음 단계는 SoC 내에 몇 개의 논리 메모리 공간이 있어야 하는지를 결정하고, 그들의 상세한 레이아웃을 계획하는 것입니다. 기능적 모델의 소프트웨어는 하드웨어를 나타내는 부분과 SoC 내에서 실행되는 소프트웨어로 분할해야 합니다. 이 모델에는 최종적으로 실제 하드웨어의 하나 이상의 SRAM 및 DRAM 구성 요소에 저장될 여러 배열이 포함됩니다. Memory-accurate model에서는 모델 내 각 배열의 내용이 최종 구현에서 실제 메모리의 내용과 동일합니다. 이 모델의 배열에서의 작업 빈도 또는 내부 루프 반복 횟수를 수동으로 계산하면, SoC에 필요한 처리 능력과 메모리 대역폭을 예비 추정할 수 있습니다. 이러한 수치를 간단히 스프레드시트로 분석하여 최종 전력 소비와 배터리 수명을 첫 번째로 추정할 수 있습니다.

ESL 모델링에서 다음 단계는 트랜잭션 레벨 모델(TLM)을 생성하는 것입니다. TLM 모델에서는 수많은 실제 네트나 인터커넥트 구성 요소를 전혀 나타낼 필요가 없습니다. 이로 인해 TLM 모델이 네트 레벨 시뮬레이션보다 훨씬 빠르게 실행됩니다. TLM 모델은 옵션으로 시간, 전력 및 에너지를 포함할 수 있습니다. 

사이클 정확 모델은 서브시스템의 레지스터와 RAM의 모든 상태 비트를 모델링합니다. 상태 비트는 클럭 사이클마다 업데이트되어 해당 클럭 엣지에서의 새 값을 반영합니다. 성능을 향상시키기 위해, 사이클 정확 모델은 일반적으로 Verilog나 VHDL의 더 풍부한 논리 대신 간단한 2값 논리 시스템 또는 4값 논리 시스템을 사용합니다. 사이클 호출 가능한 모델은 하나의 클럭 도메인의 사이클 정확 모델입니다. 이는 기본적으로 상위 시뮬레이터의 스레드에 의해 호출될 수 있는 서브루틴으로 구성되어 있으며, 모델이 한 클럭 사이클씩 진행하도록 합니다. 예를 들어, 카운터의 사이클 호출 가능한 모델은 카운터 값을 증가시키는 서브루틴일 것입니다. 저수준 모델은 실제 구현의 모든 플립플롭과 버스를 나타내며, 이러한 모델들은 구성 요소의 RTL 구현을 기반으로 합니다.

논의된 것처럼, 네트에서 전압 파형을 시뮬레이션하는 저수준 시뮬레이션도 가능합니다. 이는 아날로그 및 혼합 신호 시스템에 필요하지만, 디지털 논리에는 일반적으로 필요하지 않습니다.

ESL Flow Diagram

 

 

ESL흐름은 주로 C++ 기반으로 이루어지며, SystemC TLM 라이브러리도 일반적으로 사용됩니다. SoC 설계에서 C/C++은 주로 Peripherals의 행동 모델링(Behavioural Models), 임베디드 애플리케이션, 운영 체제, 그리고 디바이스 드라이버를 위해 사용됩니다. 하드웨어와 소프트웨어 간의 API에 대한 인터페이스 사양은 .h 파일에 있으며, 이 파일들은 하드웨어와 소프트웨어 모두에서 사용됩니다. 이 C++ 파일들은 이미지의 상단에 표시되어 있습니다.

 

SoC 수준의 제품에 대한 임베디드 머신 코드를 생성하기 위해, 소프트웨어 측은 해당 임베디드 코어에 적합한 컴파일러(gcc-arm 등)를 사용하여 컴파일됩니다. 하드웨어 측에서는 하드웨어의 행동 모델이 다양한 방법으로 RTL(Register Transfer Level) 및 게이트 레벨(Gate-level)로 변환됩니다. 이 과정은 그림에서 오른쪽에서 왼쪽으로 대각선 방향으로 나타나 있습니다.

반면, 가장 빠른 ESL 모델은 일반적으로 왼쪽에서 오른쪽으로 내려가는 경로를 통해 생성됩니다. 이 경로에서는 하드웨어 모델과 임베디드 소프트웨어를 함께 연결하여 전체 시스템을 단일 애플리케이션 프로그램으로 실행할 수 있게 합니다. 이는 적절한 코딩 가이드라인이 따라져야만 가능합니다. 이 하이브리드 모델은 실제 시간보다 빠르게 실행될 수 있으며, 경우에 따라서는 고성능 모델링 워크스테이션이 임베디드 SoC 코어보다 더 강력한 프로세서를 가지고 있을 때, 더 빠르게 실행될 수도 있습니다.

성능 향상의 예

네트워크 패킷을 디바이스 드라이버가 수신하고 이를 버스를 통해 메모리로 전송하는 상황을 생각해 봅시다. 실제 구현에서는 수만 번의 게이트 출력 전환이 일어나게 됩니다. 네트 레벨(Net-level) 시뮬레이션을 사용하면, 각 게이트 전환의 시뮬레이션은 모델링 워크스테이션에서 100번의 명령어를 실행할 수 있습니다. 하지만 적절한 ESL 코딩 스타일을 사용하면, 패킷 수신 트랜잭션은 한 컴포넌트에서 다른 컴포넌트로 간단한 메소드 호출로 모델링될 수 있으며, 총 100개 이하의 명령어만을 필요로 합니다. 메모리 관리를 신중하게 하면, 트랜잭션으로 전송되는 데이터는 복사될 필요가 없으며, 버퍼에 대한 포인터만 전송하면 됩니다.

주요 포인트

1. Instruction Set Simulator (ISS): ISS는 임베디드 코어의 머신 코드를 해석하기 위해 사용될 수 있습니다. 최상의 ISS 구현은 자주 사용되는 실행 경로를 식별하고, 이 코드들을 모델링 워크스테이션의 네이티브 머신 코드로 크로스 컴파일하여 실제 시간보다 빠른 성능을 달성할 수 있습니다.
2. RTL과 C++ 모델 간 변환: RTL 모델이 초기 고수준 모델과 크게 다르거나 고수준 모델이 존재하지 않는 경우, RTL 디자인은 표준 도구를 사용해 C++ 모델로 변환될 수 있습니다. Verilator와 같은 도구가 이러한 변환을 수행하는 데 자주 사용됩니다. 예를 들어, Arm은 Carbon 도구 체인을 사용해 내부 RTL에서 생성된 C++ 모델을 제공합니다.

이 흐름은 SoC 설계에서 매우 중요한데, 이 과정을 통해 빠르고 효율적인 모델링 및 시뮬레이션이 가능해집니다.

 

SystemC EDS Kernel

SystemC EDS Kernel은 SystemC 라이브러리의 핵심 구성 요소 중 하나로, **Event-Driven Simulation**(EDS) 커널이라고도 불립니다. 이는 SystemC에서 시뮬레이션을 관리하고 실행하는 중심 역할을 담당합니다. SystemC는 C++ 기반의 하드웨어 설계 언어로, 하드웨어의 동작을 소프트웨어 방식으로 시뮬레이션할 수 있게 해줍니다.

SystemC EDS Kernel의 역할

1. 이벤트 기반 시뮬레이션 관리
   - EDS Kernel은 하드웨어 시뮬레이션에서 발생하는 이벤트를 관리합니다. 하드웨어 시뮬레이션은 주로 이벤트(예: 신호의 변화, 타이머 이벤트 등)가 발생할 때마다 상태를 업데이트하고 다음 이벤트를 처리하는 방식으로 진행됩니다.
   - SystemC에서는 각 컴포넌트(예: 모듈, 프로세스)가 이벤트를 생성하거나 해당 이벤트에 반응하여 동작을 수행합니다. EDS Kernel은 이러한 이벤트들을 시간 순서에 따라 정렬하고 처리합니다.

2. 동기화 및 스케줄링
   - SystemC EDS Kernel은 시뮬레이션 시간에 따라 프로세스와 이벤트를 동기화합니다. 이는 실제 하드웨어가 클럭에 따라 동작하는 것과 유사하게 시뮬레이션이 정확한 타이밍에 따라 진행되도록 합니다.
   - 커널은 각 프로세스가 언제 실행되어야 하는지, 어떤 순서로 이벤트가 발생해야 하는지를 결정합니다. 이를 통해 하드웨어 설계의 정확성과 타이밍을 검증할 수 있습니다.

3. 컨텍스트 스위칭 최소화
   - 고성능 시뮬레이션을 위해 EDS Kernel은 컨텍스트 스위칭을 최소화하도록 설계되었습니다. 이는 프로세스 간의 전환을 줄이고, 가능한 한 빠르게 시뮬레이션을 실행하는 데 도움을 줍니다.
   - 예를 들어, 하드웨어 설계 시나리오에서 여러 프로세스가 동시에 실행될 때, EDS Kernel은 이러한 프로세스들이 최대한 효율적으로 실행되도록 스케줄링합니다.

4. 하이브리드 시뮬레이션 지원
   - SystemC EDS Kernel은 소프트웨어와 하드웨어 간의 하이브리드 시뮬레이션을 지원합니다. 이는 전체 시스템을 단일 프로그램으로 실행하는 방식으로, 실제 하드웨어보다 빠르게 시뮬레이션이 가능하도록 설계되었습니다.
   - 이를 통해 복잡한 SoC의 성능을 빠르고 효율적으로 검증할 수 있습니다.

SystemC EDS Kernel은 하드웨어 시뮬레이션에서 이벤트 기반 방식으로 동작을 관리하고, 시뮬레이션 시간에 따라 프로세스와 이벤트를 동기화하며, 시뮬레이션의 효율성을 높이기 위해 컨텍스트 스위칭을 최소화하는 역할을 합니다. 이 커널은 복잡한 SoC 설계를 시뮬레이션하고 검증하는 데 필수적인 요소로, SystemC를 사용한 하드웨어 및 시스템 모델링의 핵심이라고 할 수 있습니다.

 

SystemC의 역할

SystemC가 ESL설계에서 매우 중요한 도구이긴 하지만, ESL 설계가 SystemC에만 의존하는 것은 아닙니다. SystemC는 ESL 설계를 위한 강력하고 널리 사용되는 도구이지만, ESL(전자 시스템 레벨) 설계를 수행하는 다양한 방법과 도구가 존재합니다.

SystemC는 특히 C++ 기반의 하드웨어 설계와 시뮬레이션에 탁월하며, Transaction Level Modeling(TLM)과 같은 높은 추상화 수준의 모델링을 지원합니다. 이러한 이유로, SoC(System on Chip) 설계에서 널리 사용되며, ESL 설계 흐름에서 매우 중요한 역할을 합니다.

ESL 설계의 다양한 접근법

그러나 SystemC 없이도 ESL 설계가 가능합니다. 다음은 몇 가지 예시입니다:

1. 기타 언어 및 라이브러리:
   • ESL 설계를 위해 다른 하드웨어 설계 언어 또는 라이브러리도 사용될 수 있습니다. 예를 들어, MATLAB/Simulink는 하드웨어와 시스템 수준의 모델링 및 시뮬레이션에 자주 사용됩니다.
   • Python 기반의 MyHDL, VHDL, Verilog와 같은 언어도 고수준의 모델링과 시뮬레이션에 사용될 수 있습니다.
2. 전용 ESL 툴:
   • Cadence, Synopsys, Mentor Graphics 등에서 제공하는 상용 ESL 도구들은 SystemC를 사용하지 않고도 ESL 설계를 가능하게 합니다. 이들 도구는 각각의 ESL 설계 흐름을 지원하며, 다양한 추상화 수준에서의 하드웨어와 소프트웨어 통합 설계를 수행할 수 있습니다.
3. 비-시뮬레이션 기반 검증:
   • ESL 설계는 반드시 시뮬레이션 기반일 필요가 없습니다. 수학적 검증, 형식 검증(formal verification), 모델 검증(model checking) 등의 방법도 ESL 설계에서 사용할 수 있습니다. 이러한 방법들은 SystemC와 무관하게 사용할 수 있으며, SoC 설계의 정확성을 보장하는 데 중요한 역할을 합니다.

SystemC는 ESL 설계에서 매우 유용하고 강력한 도구이지만, 필수불가결한 요소는 아닙니다. 다양한 도구와 방법을 사용해 ESL 설계를 수행할 수 있으며, 각 도구와 방법은 특정 요구사항에 따라 선택될 수 있습니다. SystemC가 없더라도 ESL 설계는 가능하며, 그 성공 여부는 설계자의 요구사항에 맞는 도구와 방법을 얼마나 잘 선택하고 사용하는지에 달려 있습니다.