Zeah Engineering Factory

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 설계는 가능하며, 그 성공 여부는 설계자의 요구사항에 맞는 도구와 방법을 얼마나 잘 선택하고 사용하는지에 달려 있습니다.

System on Chip (SoC) integrates hardware and software to communicate with the external world through various interfaces. The Electronic System Level (ESL) model of an SoC can simulate the entire system behavior in a way that allows most software to run with minimal modifications, as it would on the actual SoC. Another term for the ESL model is Virtual Platform. In some SoC design flows, creating an ESL model is the first design step. Through a process of iterative refinement, high-level components are gradually replaced with lower-level models or actual implementations. Ultimately, the whole system is implemented, but a good ESL methodology allows for any combination of interacting high- and low-level modeling styles. A common use case might involve the design existing at a high level, with the exception of one or two subsystems that require more detailed modeling to address specific design concerns.

In this context, the terms "high-level" and "low-level" refer to the abstraction level of modeling.

• High-Level: High-level models are designed with a high degree of abstraction, allowing for the quick simulation of system behavior. They are used mainly in the early stages of design to understand the big picture of the system or evaluate different architectural choices. The specific hardware implementation or cycle accuracy may be omitted or simplified, making these models useful for verifying system behavior and software interaction quickly. For example, SystemC's TLM (Transaction Level Modeling) abstracts data flow and functional behavior, representing a high-level approach.
• Low-Level: Low-level models have a lower degree of abstraction and simulate the hardware in much more detail. These are typically used later in the design process when the system's actual hardware is close to implementation. They accurately represent the system's behavior on a clock cycle basis, showing how each hardware component operates. RTL (Register Transfer Level) modeling is a common low-level modeling technique.

This section introduces the primary goals and approaches of ESL modeling. It reviews the SystemC modeling library and its transaction library (SystemC TLM), discussing how high-level models can be calibrated to provide useful insights into system performance and power consumption.

The performance of an ESL model must be good enough to run large programs in a reasonable time, typically achieving at least 1% of real system performance. ESL models are often accurate in terms of memory layout and content, but many other hardware details are ignored unless they are critical for testing. This is a key way to achieve high simulation performance.

Fundamentally, ESL models simulate the system from the power-on or reset point. Another method of applying ESL models to complex software is through checkpoints and replays. This is useful when large amounts of software need to be run before reaching a point of interest. Checkpoints are selected from points such as after booting or operating system startup. At this checkpoint, the entire state of the model is saved in a checkpoint file. While information could, in principle, be captured from the real system, the ESL model may not exactly match the real system, and small differences can occur. Additionally, installing instrumentation on the real system can be challenging, especially if it does not yet exist. Since checkpoints form the basis for multiple experiments, the time invested in creating them is offset.

To conduct experiments, the ESL model is loaded with checkpoint data, and the modeling proceeds from that point. A more detailed level of abstraction than was used during checkpoint preparation can be applied, either to the entire system or just to specific subsystems. For example, the high-level model of an I/O block could be switched to an RTL model.

The ESL description will be structured as follows:

1. Modelling Abstractions
2. Interconnect Modelling
3. SystemC Modelling Library
4. Transaction-level Modelling
5. Processor Modelling with Different Levels of Abstraction
6. ESL Modelling of Power, Performance, and Area

SoC(System on Chip)은 하드웨어와 소프트웨어를 결합하여 다양한 인터페이스를 통해 외부와 통신합니다. SoC의 전자 시스템 레벨(ESL) 모델은 실제 SoC에서 실행될 모든 소프트웨어를 거의 수정하지 않은 형태로 실행할 수 있는 전체 시스템 동작을 시뮬레이션할 수 있습니다. ESL 모델의 대안적인 이름은 가상 플랫폼(Virtual Platform)입니다. 일부 SoC 설계 흐름에서는 ESL 모델을 생성하는 것이 첫 번째 설계 단계입니다. 점진적인 정제 과정에서 고수준의 구성 요소를 하위 수준의 모델이나 실제 구현으로 점차 대체해 나갑니다. 궁극적으로 시스템 전체가 구현되지만, 뛰어난 ESL 방법론은 상호 작용하는 고수준 및 저수준 모델링 스타일의 임의의 조합을 가능하게 합니다. 일반적인 사용 사례로는, 현재 관심 있는 특정 설계 문제를 해결하기 위해 보다 자세한 모델링이 필요한 한두 개의 하위 시스템을 제외하고 나머지 모든 설계가 고수준 형태로 존재하는 경우가 있습니다.

여기서 "고수준"과 "저수준"이라는 용어는 모델링의 추상화 수준을 가리킵니다.

• 고수준(High-Level): 고수준 모델은 추상화 수준이 높아 시스템의 동작을 간략하고 빠르게 시뮬레이션할 수 있도록 설계된 모델입니다. 이는 주로 설계 초기 단계에서 시스템의 큰 그림을 이해하거나 다양한 아키텍처 선택지를 평가할 때 사용됩니다. 하드웨어의 세부적인 구현이나 클럭 사이클 정확성(cycle-accuracy)은 생략되거나 간소화되며, 소프트웨어와 시스템 동작을 빠르게 검증하는 데 유용합니다. 예를 들어, SystemC의 TLM(Transaction Level Modeling)은 데이터 흐름과 기능적 동작을 추상적으로 모델링하는 고수준 방법론입니다.
• 저수준(Low-Level): 저수준 모델은 추상화 수준이 낮아, 시스템의 하드웨어를 매우 세부적으로 시뮬레이션합니다. 이는 주로 설계의 후반부에서 사용되며, 실제 하드웨어 구현과 매우 유사하게 동작합니다. 클럭 사이클 단위로 정확한 동작을 모사하며, 하드웨어의 각 구성 요소가 실제로 어떻게 동작하는지를 상세하게 보여줍니다. RTL(Register Transfer Level) 모델링이 대표적인 저수준 모델링 기법입니다.

이 장에서는 ESL 모델링의 주요 목표와 접근 방식을 소개합니다. SystemC 모델링 라이브러리와 그 트랜잭션 라이브러리(SystemC TLM)를 검토하고, 고수준 모델이 성능과 전력에 대한 유용한 통찰을 제공하도록 보정(calibrate)될 수 있는 방법을 논의합니다.

ESL 모델의 성능은 대규모 프로그램을 합리적인 시간 내에 실행할 수 있을 정도로 충분히 좋아야 합니다. 이는 일반적으로 실제 시스템 성능의 최소 1%를 달성해야 함을 의미합니다. ESL 모델은 메모리 레이아웃과 내용 측면에서 정확한 것이 일반적이지만, 특별히 테스트에 중요한 하드웨어 세부 사항이 아니라면 많은 다른 하드웨어 세부 사항은 무시됩니다. 이는 높은 성능의 시뮬레이션을 달성하기 위한 주요 수단입니다.

기본적으로 ESL 모델은 시스템을 전원 공급 또는 리셋 지점에서부터 시뮬레이션합니다. 복잡한 소프트웨어에 ESL 모델을 적용하는 또 다른 방법은 체크포인트(checkpoint)와 리플레이(replay)입니다. 이는 관심 지점에 도달하기 전에 많은 양의 소프트웨어가 실행되어야 하는 경우에 유용합니다. 체크포인트는 부팅 또는 운영 체제 시작 후와 같은 지점에서 선택됩니다. 이 체크포인트에서 모델의 전체 상태가 체크포인트 파일로 저장됩니다. 원칙적으로 실제 시스템에서 정보를 캡처할 수 있지만, ESL 모델이 실제 시스템과 동일하지 않을 수 있으며 작은 차이가 발생할 수 있습니다. 게다가, 실제 시스템에 계측(instrumentation)을 설치하는 것은 어렵습니다(특히 아직 존재하지 않는 경우에는 더욱 그렇습니다). 체크포인트는 여러 실험의 기초가 되므로, 이를 생성하는 데 투자된 시간은 상쇄됩니다.

실험을 수행하기 위해 ESL 모델은 체크포인트 데이터로 로드되며, 모델링은 해당 지점에서부터 진행됩니다. 체크포인트를 준비할 때 사용했던 수준보다 더 높은 수준의 세부 사항으로 전환할 수 있으며, 이는 전체 시스템 또는 일부 하위 시스템에만 적용될 수 있습니다. 예를 들어, I/O 블록의 고수준 모델을 RTL 모델로 전환할 수 있습니다.

다음과 같은 순서로 ESL을 기술해 보려고 합니다.

1. Modelling Abstractions

2. Interconnect Modelling

3. SystemC Modelling Library

4. Transaction-level Modelling

5. Processor Modelling with Different Levels of Abstraction

6. ESL Modelling of Power, Performance and Area

Voltage droop in SoCs is primarily caused by the interaction between the PDN's impedance and the rapid increase in current consumption. Here's how each factor contributes to droop:

1. Power Delivery Network (PDN) Impedance

• Definition: The PDN impedance refers to the resistance, inductance, and capacitance present in the power supply path from the voltage regulator to the SoC components.
• Impedance Characteristics:
  • Resistance (R): Resistance in the PDN leads to voltage drops as current flows through the network. High resistance means more energy is lost as heat, reducing the effective voltage reaching the SoC.
  • Inductance (L): Inductance causes delays in the response of the power supply to changes in current demand. High inductance can cause significant voltage drops when the current demand changes rapidly because it opposes changes in current flow.
  • Capacitance (C): Capacitance can temporarily supply additional current during transient loads, but insufficient capacitance can lead to droop.
• Role in Droop:
  • When the PDN has high impedance, it cannot quickly adjust to sudden changes in current demand. This results in voltage droop as the network struggles to supply the necessary power to maintain stable voltage levels.

2. Sudden Increase in Current Consumption

• Scenario: A sudden increase in current consumption occurs when the SoC transitions from a low-power state to a high-performance state. This might happen, for instance, when a processor core wakes up to execute a demanding task.
• Impact:
  • Current Spike: The rapid increase in current demand can cause a spike in the required power. The PDN needs to respond quickly to this spike to prevent voltage droop.
  • Transient Load: The transient load is the immediate demand for power that occurs before the PDN can stabilize. If the PDN is not designed to handle such transient loads, it will result in a temporary voltage drop, or droop.

Interaction Between PDN Impedance and Current Consumption

• Effect of Inductance:
  • Inductance delays the response to sudden current changes. When a core demands more current, the inductive elements in the PDN resist the change, causing a temporary drop in voltage until the current stabilizes.
• Decoupling Capacitors:
  • Function: Decoupling capacitors are used to temporarily supply additional current when a transient load occurs. They act as local energy reserves to mitigate voltage droop.
  • Limitation: If the capacitors are insufficient in quantity or poorly placed, they cannot effectively mitigate the voltage droop caused by high PDN impedance and sudden current spikes.

Mitigating Voltage Droop

To reduce voltage droop in SoCs, designers focus on optimizing the PDN and managing current consumption more effectively:

1. Reduce PDN Impedance:
   • Low-Resistance Materials: Use materials with lower resistivity in the PDN to reduce voltage losses.
   • Inductance Minimization: Design PDNs with minimal inductance by optimizing trace layouts and reducing loop areas.
2. Improve Transient Response:
   • Decoupling Capacitors: Increase the number and improve the placement of decoupling capacitors to better handle transient loads.
   • Advanced VRMs: Use advanced voltage regulator modules (VRMs) that can respond more quickly to changes in current demand.
3. Dynamic Voltage and Frequency Scaling (DVFS):
   • Adjust the voltage and frequency dynamically to match the performance needs, smoothing out the transitions between different power states and reducing the impact of sudden load changes.
4. Predictive Algorithms:
   • Implement algorithms that predict high-load scenarios and pre-emptively adjust power supply settings to prepare the PDN for increased demand.

Conclusion

Voltage droop in SoCs results from the interplay between the PDN's impedance and sudden increases in current consumption. By understanding and addressing these factors, engineers can design more robust systems that maintain stable voltage levels, even during dynamic operation conditions.

SoC에서 전압 드룹은 주로 PDN의 임피던스와 전류 소모가 갑자기 증가하는 상황에서 발생합니다. 이 두 가지 요소가 드룹에 어떻게 기여하는지 살펴보겠습니다.

1. 전력 공급 네트워크(PDN)의 임피던스

• 정의: PDN 임피던스는 전압 조정기에서 SoC 구성 요소로 전력이 전달되는 경로에서 발생하는 저항, 인덕턴스, 그리고 커패시턴스를 의미합니다.
• 임피던스 특성:
  • 저항 (Resistance, R): PDN의 저항은 전류가 네트워크를 통해 흐를 때 전압 강하를 일으킵니다. 높은 저항은 더 많은 에너지가 열로 손실되며, SoC에 도달하는 유효 전압을 줄입니다.
  • 인덕턴스 (Inductance, L): 인덕턴스는 전류 수요 변화에 대한 전력 공급의 응답을 지연시킵니다. 높은 인덕턴스는 급격한 전류 수요 변화 시 전류 흐름을 방해하여 상당한 전압 강하를 일으킬 수 있습니다.
  • 커패시턴스 (Capacitance, C): 커패시턴스는 일시적인 부하 시 추가 전류를 공급할 수 있지만, 커패시턴스가 충분하지 않으면 드룹이 발생할 수 있습니다.
• 드룹에서의 역할:
  • PDN의 임피던스가 높을 경우, 전류 수요의 갑작스러운 변화에 신속하게 대응할 수 없습니다. 이로 인해 네트워크가 안정적인 전압 수준을 유지하는 데 어려움을 겪으며 전압 드룹이 발생합니다.

2. 갑작스러운 전류 소모 증가

• 시나리오: SoC가 저전력 상태에서 고성능 상태로 전환할 때 갑작스러운 전류 소모 증가가 발생합니다. 예를 들어, 프로세서 코어가 고부하 작업을 수행하기 위해 깨어날 때 발생할 수 있습니다.
• 영향:
  • 전류 급증: 전류 수요가 급격히 증가하면 필요한 전력량이 순간적으로 증가합니다. PDN은 이러한 전류 급증에 빠르게 대응해야 드룹을 방지할 수 있습니다.
  • 일시적인 부하(Transient Load): 일시적인 부하는 PDN이 안정화되기 전 발생하는 즉각적인 전력 수요를 의미합니다. PDN이 이러한 일시적인 부하를 처리하도록 설계되지 않았다면, 순간적인 전압 강하 또는 드룹이 발생합니다.

PDN 임피던스와 전류 소모의 상호작용

• 전압 강하 방정식: PDN에서의 전압 강하(VdropV_{\text{drop}}Vdrop​)는 옴의 법칙 및 관련 방정식으로 설명할 수 있습니다:Vdrop=I×ZPDNV_{\text{drop}} = I \times Z_{\text{PDN}}Vdrop​=I×ZPDN​여기서 III는 전류 수요이고, ZPDNZ_{\text{PDN}}ZPDN​은 PDN 임피던스입니다. ZPDNZ_{\text{PDN}}ZPDN​이 높거나 III가 급증하면 전압 강하가 커집니다.
• 인덕턴스의 영향:
  • 인덕턴스는 전류 변화에 대한 저항으로 작용합니다. 코어가 더 많은 전류를 요구할 때, PDN의 유도성 요소는 변화를 저항하여 전류가 안정화될 때까지 일시적인 전압 드룹을 유발합니다.
• 디커플링 커패시터(Decoupling Capacitors):
  • 기능: 디커플링 커패시터는 일시적인 부하가 발생할 때 추가 전류를 일시적으로 공급하여 전압 드룹을 완화합니다.
  • 제한점: 커패시터의 수량이 부족하거나 배치가 적절하지 않으면 높은 PDN 임피던스와 전류 급증으로 인한 전압 드룹을 효과적으로 완화할 수 없습니다.

전압 드룹 완화 방법

SoC의 전압 드룹을 줄이기 위해 설계자는 PDN 최적화와 전류 소모 관리를 보다 효과적으로 수행해야 합니다:

1. PDN 임피던스 감소:
   • 저저항 재료: PDN에서 저항이 낮은 재료를 사용하여 전압 손실을 줄입니다.
   • 인덕턴스 최소화: 배선 레이아웃을 최적화하고 루프 면적을 줄여 PDN의 인덕턴스를 최소화합니다.
2. 일시적인 응답 개선:
   • 디커플링 커패시터: 일시적인 부하를 효과적으로 처리할 수 있도록 디커플링 커패시터의 수량을 늘리고 배치를 개선합니다.
   • 고급 전압 조정 모듈(VRMs): 전류 수요 변화에 더 빨리 대응할 수 있는 고급 전압 조정 모듈을 사용합니다.
3. 동적 전압 및 주파수 조정(DVFS):
   • 성능 요구에 맞춰 전압과 주파수를 동적으로 조정하여 전력 상태 간 전환을 매끄럽게 하여 갑작스러운 부하 변화의 영향을 줄입니다.
4. 예측 알고리즘:
   • 고부하 상황을 예측하고 전력 공급 설정을 사전 조정하여 PDN이 증가된 수요에 대비할 수 있도록 하는 알고리즘을 구현합니다.

결론

SoC에서의 전압 드룹은 PDN의 임피던스와 갑작스러운 전류 소모 증가 간의 상호작용으로 발생합니다. 이러한 요소를 이해하고 이를 해결하기 위한 설계를 통해 엔지니어는 다양한 동작 조건에서도 안정적인 전압 수준을 유지할 수 있는 견고한 시스템을 설계할 수 있습니다.

Samsung's Exynos processors have been powering smartphones and devices with cutting-edge features and performance improvements. Here’s a look at the specifications and capabilities of the Exynos 2100, 2200, and 2400 chips.

Exynos 2100

• Process Technology: 5 nm (Samsung 5LPE)
• System-Level Cache: 6 MB
• CPU Configuration:
  • 1 + 3 + 4 cores
  • 2.91 GHz Cortex-X1
  • 2.81 GHz Cortex-A78
  • 2.2 GHz Cortex-A55
• Performance:
  • 19% better single-thread performance
  • 33% better multi-thread performance
• GPU:
  • Mali G78 MP14 at 854 MHz
  • 40% performance improvement
  • Vulkan 1.1.213 support
• DSP:
  • 8K30 & 4K120 encode
  • 8K60 decode (with AV1 support claimed but unverified)
  • Multi-Format Codec (MFC) for H.265/HEVC, H.264, VP9
  • HDR10+ support
• ISP:
  • Single: up to 200MP
  • Dual: 32MP + 32MP
  • Quad simultaneous camera support
• Modem and Wireless:
  • Bluetooth 5.2
  • Integrated Exynos Modem
  • LTE Category 24/18, 6CA, 256-QAM
  • 5G NR Sub-6 and mmWave support
  • GNSS: GPS, Galileo, GLONASS, BeiDou

Exynos 2200

• Process Technology: 4 nm (Samsung 4LPE)
• System-Level Cache: 8 MB
• CPU Configuration:
  • 1 + 3 + 4 cores
  • 2.8 GHz Cortex-X2
  • 2.5 GHz Cortex-A710
  • 1.9 GHz Cortex-A510
  • 1 MB + 3x 512 KB + 2x 256 KB L2
  • 4 MB L3
• GPU:
  • Xclipse 920 at 1306 MHz (RDNA 2 architecture)
  • Vulkan 1.3.231 support
  • Hardware-based Ray Tracing
• Modem and Wireless: (Details carried over from Exynos 2100, similar enhancements implied)
  • Improvements in connectivity and processing power

Exynos 2400

• Process Technology: 4 nm (Samsung 4LPP+)
• CPU Configuration:
  • 1 + 2 + 3 + 4 cores
  • 3.21 GHz Cortex-X4
  • 2.9 GHz Cortex-A720
  • 2.59 GHz Cortex-A720
  • 1.96 GHz Cortex-A520
  • 2 MB + 2x 512 KB + 3x 512 KB + 4x 256 KB L2
  • 8 MB L3
• Performance:
  • 1.7x increase in CPU performance compared to Exynos 2200
• GPU:
  • Xclipse 940 at 1095 MHz (customized RDNA 3 architecture)
  • ANGL-based driver supporting Vulkan 1.3.231
  • Hardware-based Ray Tracing
• NPU:
  • 17K MAC units
  • Two GNPUs and two SNPUs
  • 14.7x boost in AI performance compared to Exynos 2200

Summary

The evolution from Exynos 2100 to Exynos 2400 showcases significant advancements in CPU architecture, GPU capabilities, and AI processing power. These processors continue to push the boundaries of mobile performance and multimedia capabilities, offering users enhanced experiences in gaming, photography, and connectivity.