Interconnect Modelling
interconnect 모델은 SoC 설계 초기 단계에서 실제 interconnect를 설계하기 전에 성능을 분석하고, 최적화하기 위해 사용됩니다. 또한, 이러한 모델은 전체 SoC를 ESL(Electronic System Level)로 모델링할 때 현실적인 지연 시간을 예측하는 데 도움이 됩니다. 상세한 interconnect 모델은 생산 단계에서 발생한 문제를 복제하고, 이를 해결하기 위한 연구에 사용될 수도 있습니다.
interconnect 모델링의 주요 개념
- Packetised Networks on Chip (NoC)와 전통적인 Circuit-Switched interconnect는 모두 queuing(큐잉)과 arbitration(중재)를 포함하는 discrete event(이산 이벤트)를 처리합니다. 이러한 이유로, 두 시스템 모두에 같은 모델링 기법을 적용할 수 있습니다.
interconnect 모델링의 종류
interconnect 모델링은 매우 추상적인 수준에서부터 상세한 수준까지 여러 단계로 나눌 수 있습니다:
- High-level static analysis: 트래픽 흐름 행렬을 사용하여 간단한 스프레드시트(또는 이와 유사한 도구)를 통해 모델링합니다. 이 방법은 초기 설계에 적합하며, TLM(Transaction Level Modelling) 모델에 기본적인 지연 시간을 추가할 수 있습니다.
- Virtual queuing: 실제 queue 모델이나 지연 시간을 포함하지 않고 트랜잭션을 전파합니다. 그러나, 트래픽이 각 중재 지점에서 어떻게 변동하는지는 정확하게 반영됩니다. 이 방법은 TLM 모델에서 사용되며, 트랜잭션 지연 필드에 지연 패널티를 추가합니다.
- TLM queuing: 스위칭 요소의 high-level 모델이 트랜잭션 queue를 포함합니다. 이 방식에서는 TLM 블로킹 코딩이 필요합니다.
- Cycle-accurate modelling: 클럭 사이클 단위로 정확한 시뮬레이션을 수행합니다. 이 방식은 TLM이나 RTL(Register Transfer Level) 수준에서 이루어질 수 있습니다.
Stochastic Interconnect Modelling
네트워크 설계 분야에서는 다양한 유형의 랜덤 트래픽을 모델링하는 데 많은 연구가 이루어졌습니다. Markov process(마코프 과정)을 기반으로 한 모델은 매우 유용한 분석 도구입니다. 이러한 모델은 시스템의 현재 상태만으로 다음 상태를 예측할 수 있는 특성을 가지고 있으며, 독립적인 트래픽 소스와 라운드 트립 지연과 관계없는 부하가 있을 때 효과적으로 작동합니다.
하지만, Markov 모델은 실제 생산 칩에서 발생하는 특정 문제를 해결하는 데는 항상 도움이 되지 않습니다. 예를 들어, 트래픽 패턴의 상관관계가 높은 경우에는 Markov 모델이 잘못된 결과를 제공할 수 있습니다.
Cycle-accurate Interconnect Modelling
Cycle-accurate 모델링은 가장 상세한 수준의 interconnect 모델링입니다. 이 모델은 각 개별 트래픽 흐름을 클럭 사이클 단위로 정확하게 시뮬레이션하며, 이는 특히 여러 트래픽이 동일한 NoC virtual channel을 공유할 때 중요합니다. 예를 들어, 두 개의 패킷이 동시에 스위칭 요소에 도착하면 arbitration이 필요해 지연이 발생하지만, 순차적으로 도착하면 이러한 지연이 발생하지 않습니다.
전체 interconnect를 Cycle-accurate 수준에서 모델링하려면, 각 서브 모델이 Cycle-accurate 수준으로 동작해야 합니다. 입력 자극은 실세계 시스템에서 얻은 트레이스 자료 또는 인공적으로 생성된 시나리오를 사용할 수 있습니다.
경우에 따라 여러 클럭이 사용되거나 클럭 엣지의 세부 사항을 정확하게 모델링해야 하는 상황이 있을 수 있습니다. 이 경우에는 Cycle-accurate 모델만으로는 문제의 세부 사항을 충분히 포착하지 못할 수 있습니다.
요약
interconnect 모델링은 SoC 설계에서 매우 중요한 역할을 합니다. 모델링은 설계 초기 단계에서 성능을 최적화하고, 생산 단계에서 발생할 수 있는 문제를 해결하는 데 사용됩니다. interconnect 모델은 high-level의 정적 분석에서부터 Cycle-accurate 모델링에 이르기까지 다양한 수준에서 수행될 수 있으며, 각 수준은 특정 설계 목표와 요구에 따라 선택될 수 있습니다.
Packetised Networks on Chip (NoC)와 전통적인 Circuit-Switched interconnect는 SoC(System on Chip) 설계에서 데이터 전송을 관리하는 두 가지 주요 방식입니다. 이들은 각각 고유한 특징과 장단점을 가지고 있으며, 특정 설계 목표와 요구사항에 따라 선택됩니다. 아래에 각각의 특징과 장단점을 자세히 설명하겠습니다.
Packetised Networks on Chip (NoC)
특징:
- 패킷 기반 데이터 전송: NoC에서는 데이터가 작은 패킷으로 분할되어 전송됩니다. 각 패킷에는 목적지 주소와 같은 메타데이터가 포함되어 있어, 네트워크 내에서 독립적으로 라우팅됩니다.
- 동적 라우팅: NoC는 네트워크 내의 라우터를 통해 패킷을 동적으로 라우팅합니다. 이는 네트워크의 상태에 따라 패킷이 다른 경로를 선택할 수 있음을 의미합니다.
- 유연한 구조: NoC는 다양한 토폴로지(예: 메쉬, 링, 트리 등)를 지원하여 시스템 요구사항에 따라 설계될 수 있습니다. 이로 인해 설계 유연성이 높습니다.
- 확장성: NoC는 네트워크의 규모에 따라 쉽게 확장될 수 있으며, 복잡한 SoC에서도 효율적으로 동작합니다.
장점:
- 높은 유연성: NoC는 다양한 토폴로지를 지원하고, 동적 라우팅을 통해 네트워크 혼잡을 줄일 수 있어 설계 유연성이 매우 높습니다.
- 확장성: 네트워크의 크기와 복잡성에 관계없이 쉽게 확장할 수 있어, 대규모 SoC 설계에 적합합니다.
- 병목 현상 최소화: 패킷이 여러 경로로 라우팅될 수 있어 특정 경로의 병목 현상을 줄일 수 있습니다.
- 재사용 가능성: 모듈화된 설계 덕분에 기존 NoC 인프라를 재사용하여 새로운 설계에 적용할 수 있습니다.
단점:
- 복잡한 라우팅 및 제어: 동적 라우팅과 패킷 스위칭으로 인해 라우터의 설계와 제어가 복잡해질 수 있으며, 이로 인해 전력 소모와 설계 시간이 증가할 수 있습니다.
- 지연 시간 변동: 패킷이 서로 다른 경로로 라우팅될 수 있어, 지연 시간이 일정하지 않을 수 있습니다. 이는 실시간 애플리케이션에 문제가 될 수 있습니다.
- 전력 소모: 여러 라우터와 스위치가 필요해 전력 소모가 증가할 수 있습니다.
Circuit-Switched Interconnect
특징:
- 회로 기반 데이터 전송: Circuit-switched interconnect는 두 노드 간에 전용 경로(회로)를 설정한 후, 데이터를 전송합니다. 이 경로는 데이터 전송이 끝날 때까지 유지됩니다.
- 고정된 경로: 데이터 전송 동안 경로가 고정되어 있으므로, 데이터가 전송되는 동안 경로 변경이 일어나지 않습니다.
- 간단한 제어: 경로가 고정되므로, 라우팅 제어가 비교적 간단합니다.
장점:
- 일정한 지연 시간: 전송 경로가 고정되어 있어, 지연 시간이 일정합니다. 이는 실시간 애플리케이션에서 매우 중요한 이점입니다.
- 낮은 전력 소모: 라우터와 스위치의 복잡성이 낮아 전력 소모가 비교적 적습니다. 특히, 데이터 전송 경로가 최적화된 경우 전력 효율성이 높습니다.
- 간단한 구현: 회로 스위칭 방식은 라우팅과 제어가 비교적 간단하므로, 구현이 쉬운 편입니다.
단점:
- 비효율적인 자원 사용: 회로가 설정되면, 데이터 전송이 끝날 때까지 경로가 다른 트래픽에 의해 사용될 수 없습니다. 이는 네트워크 자원의 비효율적인 사용을 초래할 수 있습니다.
- 확장성 문제: 네트워크 규모가 커질수록 회로를 설정하고 유지하는 데 필요한 자원이 증가하므로, 대규모 SoC에서는 확장성이 제한될 수 있습니다.
- 유연성 부족: 경로가 고정되어 있어 네트워크 혼잡이 발생할 경우 대체 경로를 사용할 수 없으므로, 병목 현상이 발생할 수 있습니다.
요약
- NoC는 유연성과 확장성 측면에서 뛰어나지만, 복잡한 제어와 전력 소모, 지연 시간 변동이 단점으로 작용할 수 있습니다.
- Circuit-switched interconnect는 일정한 지연 시간과 낮은 전력 소모를 제공하지만, 자원 사용의 비효율성과 확장성 문제, 유연성 부족이 단점으로 작용할 수 있습니다.
두 방식은 각기 다른 요구사항과 상황에 맞게 선택될 수 있으며, SoC 설계의 목표와 환경에 따라 적합한 방식을 선택하는 것이 중요합니다.
Q) 위에 내용에 의하면 interconnect 모델이 cycle-accurate 하면, sub-system들이 모두 cycle-accurate 하다고 했잖아. 그러면 SoC 안에는 전부 cycle-accurate 수준으로 모델링을 해야 하네.
cycle-accurate 수준의 모델링을 한다는 것은 시스템 내의 모든 구성 요소(sub-system)들이 클럭 사이클 단위로 정확하게 동작하는 것을 의미합니다. SoC(System on Chip) 안에서 전체 interconnect를 cycle-accurate 모델링 하려면, 해당 interconnect와 상호작용하는 모든 sub-system들이 역시 cycle-accurate 수준으로 모델링되어야 합니다.
이유 및 주요 고려 사항
- 정확한 타이밍 분석:
- Cycle-accurate 모델링은 각 클럭 사이클마다 발생하는 모든 이벤트를 정확하게 시뮬레이션합니다. SoC 내에서 interconnect와 연결된 sub-system들이 서로 데이터를 주고받을 때, 이 모든 상호작용이 클럭 사이클 단위로 정확히 일치해야 하므로 모든 sub-system이 cycle-accurate로 모델링되어야 합니다.
- 성능 및 지연 시간 분석:
- SoC 전체의 성능 및 지연 시간을 정확하게 분석하기 위해서는, 모든 sub-system이 동일한 수준의 타이밍 정확도를 가져야 합니다. cycle-accurate 모델링은 클럭 사이클마다 변화를 포착하므로, 시스템 전체의 성능을 정확하게 평가하려면 모든 sub-system이 cycle-accurate 모델로 구성되어 있어야 합니다.
- 상호작용의 세부 사항 포착:
- 각 sub-system 간의 상호작용, 특히 데이터 전송이나 중재(arbitration) 같은 중요한 이벤트들은 cycle-accurate 모델링에서만 정확히 반영될 수 있습니다. 이는 특히 복잡한 SoC에서 중요한데, 작은 타이밍 오차가 전체 시스템의 동작에 큰 영향을 미칠 수 있기 때문입니다.
단점 및 현실적인 고려 사항
그러나, SoC 전체를 cycle-accurate 수준으로 모델링하는 것은 매우 복잡하고 시간이 많이 소요되며, 많은 컴퓨팅 자원이 필요합니다. 이런 이유로 설계 초기 단계에서는 고수준 모델링(high-level modelling)이나 TLM(Transaction Level Modelling) 같은 추상화된 방법을 사용하고, 중요한 부분에 대해서만 cycle-accurate 모델링을 적용하기도 합니다.
요약
- Cycle-accurate interconnect 모델링을 하려면, 해당 interconnect와 연결된 모든 sub-system들이 cycle-accurate 수준으로 모델링되어야 합니다.
- 이는 시스템의 성능과 지연 시간을 정확하게 평가하기 위한 필수 조건입니다.
- 하지만, SoC 전체를 cycle-accurate로 모델링하는 것은 복잡성과 자원 소모가 크기 때문에, 현실적으로 중요한 부분에만 적용하고, 나머지 부분은 고수준 모델링을 사용할 수 있습니다.
따라서, 전체 SoC에서 cycle-accurate 모델링이 필요한지 여부는 설계 목표와 분석의 필요성에 따라 결정됩니다.
'IT' 카테고리의 다른 글
[ESL Modeling 4] Transaction-level Modelling (1) (2) | 2024.08.29 |
---|---|
[ESL Modeling 3] SystemC Modelling Library (1) | 2024.08.29 |
[ESL Modeling 1] Modeling Abstractions (0) | 2024.08.29 |
Electronic System-Level (ESL) Modeling _ Introduction (2) | 2024.08.29 |
Causes of Voltage Droop in SoCs (0) | 2024.08.02 |