Arteris FlexGen Opens Up Multi-Die Traffic Management for Non-Coherent Networks
Last year I wrote about Arteris’ introduction of multi-die support for coherent NoCs. This is a very big deal because hyperscalers and OEMs are now building large systems that depend on multi-chiplet architectures and require efficient traffic management between chiplets, in one case as many as 12 compute, fabric/cache and IO chiplets, plus HBM.
작년 이맘때 저는 아터리스(Arteris)가 코히어런트 NoC(Networks-on-Chip)를 위한 멀티 다이 지원 기능을 발표한 것에 대해 글을 쓴 적이 있습니다. 이는 매우 중요한 소식인데, 하이퍼스케일러와 OEM들이 현재 대규모 시스템을 구축할 때 멀티 칩렛 아키텍처에 의존하고 있으며 칩렛 간의 효율적인 트래픽 관리가 필수적이기 때문입니다. 어떤 경우에는 컴퓨팅, 패브릭/캐시, I/O 칩렛이 HBM(고대역폭 메모리)과 함께 최대 12개까지 사용되기도 합니다.
Beyond physical connectivity between chiplets, multi-chiplet systems demand effective traffic management, including bandwidth, latency, and quality of service (QoS) across multiple traffic streams. The Arteris Ncore Multi-Die solution addresses this need for coherent traffic across chiplets, yet similar support for non-coherent traffic is an even more common requirement. This is now addressed by the Arteris FlexGen Multi-Die solution.
칩렛 간의 물리적 연결을 넘어, 멀티 칩렛 시스템은 대역폭, 지연 시간, 서비스 품질(QoS) 등 여러 트래픽 스트림에 걸쳐 효과적인 트래픽 관리를 요구합니다. 아터리스 엔코어 멀티 다이(Arteris Ncore Multi-Die) 솔루션은 칩렛 간 코히어런트 트래픽에 대한 이러한 요구를 해결하지만, 논코히어런트(non-coherent) 트래픽에 대한 유사한 지원은 훨씬 더 보편적인 요구사항입니다. 이는 이제 아터리스 플렉스젠 멀티 다이(Arteris FlexGen Multi-Die) 솔루션을 통해 해결되고 있습니다.
Why traffic management is important between chiplets
Even within a single chiplet, traffic management is an important consideration. Today, the most common architecture to address this management is network on chip (NoC), widely preferred for scalability over traditional crossbar switch architectures, while still interfacing to all AMBA and other standard protocols.
단일 칩렛 내부에서조차 트래픽 관리는 중요한 고려 사항입니다. 오늘날 이러한 관리를 위한 가장 흔한 아키텍처는 NoC(Network on Chip)로, 전통적인 크로스바 스위치 아키텍처에 비해 확장성이 뛰어나 널리 선호되며, 모든 AMBA 및 기타 표준 프로토콜과도 인터페이스를 제공합니다.
This is all good within a chiplet, but what happens when you must send traffic between chiplets? One approach is to translate through a bridge to AXI and then go through a popular AXI to UCIe translator to hook up to a UCIe connector, with a similar arrangement mirrored on the other chiplet. This works fine, except that it doesn’t preserve traffic policy management, with inter-chiplet QoS carrying over to the next chiplet. This isn’t very architect friendly; traffic management needs don’t disappear at the edge of a chiplet.
칩렛 내부에서는 이 모든 것이 잘 작동하지만, 칩렛 간에 트래픽을 전송해야 할 때는 어떤 일이 발생할까요? 한 가지 접근 방식은 브리지를 통해 AXI로 변환한 다음, 널리 사용되는 AXI-UCIe 변환기를 거쳐 UCIe 커넥터에 연결하는 것이며, 다른 쪽 칩렛에도 이와 유사한 배치를 대칭적으로 구성하는 것입니다. 이것은 잘 작동하지만, 칩렛 간 QoS에서 다음 칩렛으로 이어지는 트래픽 정책 관리가 유지되지 않는다는 단점이 있습니다. 이는 아키텍트 친화적이지 않습니다. 칩렛의 경계에 도달한다고 해서 트래픽 관리 필요성이 사라지는 것은 아니기 때문입니다.
A designer could of course handle this themselves by extracting all the QoS management information from the NoC on one side, adding it to the AXI data as sideband signals and reconstructing back into the NoC on the other side. Or they could use FlexGen Multi-Die, which does all this automatically by tunneling the NoC protocol through the UCIe link. This in effect makes the chiplet-to-chiplet interface transparent.
물론 설계자가 직접 한쪽 NoC에서 모든 QoS 관리 정보를 추출하고, 이를 사이드밴드 신호로 AXI 데이터에 추가한 뒤, 반대쪽에서 다시 NoC로 재구성하는 방식으로 이를 처리할 수도 있습니다. 혹은 NoC 프로토콜을 UCIe 링크를 통해 터널링함으로써 이 모든 과정을 자동으로 처리해 주는 FlexGen Multi-Die를 사용할 수도 있습니다. 이는 사실상 칩렛 간 인터페이스를 투명하게(transparent) 만들어 줍니다.
This flexibility allows architects and designers to concentrate on total system design and optimization. With FlexGen Multi-Die, the architect can start with a monolithic system design without needing to commit to what logic is going to go on what chiplet. They can experiment with partitioning options to see how chiplet-to-chiplet controller links at those boundaries will impact QoS, rather than hardwiring a partitioning at the outset.
이러한 유연성 덕분에 아키텍트와 설계자는 전체 시스템 설계와 최적화에 집중할 수 있습니다. FlexGen Multi-Die를 사용하면 아키텍트는 어떤 로직이 어떤 칩렛에 들어갈지 미리 확정할 필요 없이 모놀리식(단일체) 시스템 설계부터 시작할 수 있습니다. 파티셔닝 옵션을 실험하여 경계 부근의 칩렛 간 컨트롤러 링크가 QoS에 미치는 영향을 미리 파악할 수 있으며, 처음부터 파티셔닝을 하드와이어링(고정)할 필요가 없습니다.
Digging down a little more
Rick Bye, Director of Product Management and Marketing at Arteris, tells me that this solution is is very configurable and pretty agnostic to the PHY IP a designer will use. They are already working with several companies who have their own PHY IP, most notably AMD who have provided an enthusiastic endorsement for the Arteris solution. Over time, Arteris also expects to qualify this new capability with some of the commercial UCIe IP options.
아터리스의 제품 관리 및 마케팅 디렉터인 릭 바이(Rick Bye)에 따르면, 이 솔루션은 매우 유연하게 설정할 수 있으며 설계자가 사용할 PHY IP에 거의 구애받지 않는다고 합니다. 그들은 이미 자체 PHY IP를 가진 여러 기업들과 협력 중이며, 특히 AMD는 아터리스 솔루션에 대해 열렬한 지지를 표명했습니다. 시간이 흐름에 따라 아터리스는 일부 상용 UCIe IP 옵션에 대해서도 이 새로운 기능의 적합성을 검증할 것으로 기대하고 있습니다.
Another very interesting feature of the Arteris Multi-Die FlexGen IP is that it can enable more efficient use of UCIe IP. Consider two chiplets A and B communicating. If all initiator traffic comes from A and all target traffic comes from B, then perhaps all that traffic can be piped through one UCIe IP on each side. If both A and B can initiate and be targets (not an uncommon scenario when replicating chiplets each containing an XPU and memory), FlexGen Multi-Die has no problem managing that traffic, up to bandwidth limitations.
아터리스 멀티 다이 FlexGen IP의 또 다른 매우 흥미로운 특징은 UCIe IP를 더욱 효율적으로 사용할 수 있게 해준다는 점입니다. 통신 중인 두 칩렛 A와 B를 생각해 봅시다. 모든 이니시에이터(initiator) 트래픽이 A에서 오고 모든 타겟(target) 트래픽이 B에서 온다면, 아마도 그 모든 트래픽은 양쪽의 UCIe IP 하나씩을 통해 파이프라인처럼 처리될 수 있을 것입니다. 만약 A와 B 모두 이니시에이터와 타겟 역할을 동시에 수행할 수 있다면(각각 XPU와 메모리를 포함하는 칩렛을 복제할 때 흔히 발생하는 시나리오입니다), FlexGen Multi-Die는 대역폭 한계 내에서 해당 트래픽을 문제없이 관리할 수 있습니다.
However, indications are that at least some AXI-to-UCI bridges require two UCIe ports on each chiplet; one for initiation from A and one for initiation from B. In this case, FlexGen Multi-Die is more area efficient, more power efficient, and more I/O efficient. And of course more flexible for early partitioning experiments.
그러나 최소한 일부 AXI-to-UCI 브리지는 각 칩렛에 두 개의 UCIe 포트(A에서의 개시를 위한 것 하나, B에서의 개시를 위한 것 하나)를 요구하는 것으로 나타납니다. 이 경우 FlexGen Multi-Die는 면적 효율성, 전력 효율성, I/O 효율성이 더 뛰어납니다. 그리고 초기 파티셔닝 실험 측면에서도 당연히 훨씬 더 유연합니다.
Very interesting. You can read more about Arteris HERE, and more about the Arteris Multi-Die solutions HERE.
매우 흥미로운 내용입니다. 아터리스에 대한 자세한 정보는 여기, 아터리스 멀티 다이 솔루션에 대한 자세한 정보는 여기에서 확인하실 수 있습니다.
