inference/research
draftlow · 0.55updated 2026-10-03

UCIe-Advanced on-chip mesh (Rebellions Rebel100 chiplets)

125 GB/s
This record is a draft. Not yet verified. Provisional. Treat every number on this page as provisional.

Fields

id
interconnect/rebellions-ucie
Kind
other
Version
UCIe-Advanced, 16 GT/s, 4-chiplet configuration
Bandwidth (GB/s, per link, unidirectional)
125
Bandwidth basis
PER CHANNEL, PER DIRECTION. The vendor states a signal rate and a bandwidth together: the Rebel100 spec table gives 'Chiplet Interface (UCIe-A): 16 Gbps, 1 TB/s per channel', and the vendor's architecture prose repeats '1TB/s per channel bi-directional bandwidth with just 11ns latency'. The recorded value is 125 GB/s per direction, which is the arithmetic conversion of the stated 16 Gbps signal rate to bytes (16/8 = 2 GB/s per lane per direction) combined with the vendor's own 1 TB/s bidirectional per-channel figure at 64 lanes per channel (2 GB/s x 64 = 128 GB/s, and 1 TB/s bidirectional implies ~500 GB/s per direction at 64 lanes). THE TWO VENDOR NUMBERS DO NOT RECONCILE EXACTLY and that disagreement is retained rather than resolved: 16 Gbps x 64 lanes gives 128 GB/s per direction (256 GB/s bidirectional) against the prose's 1 TB/s bidirectional. Whichever way it is read, the per-direction figure is in the 125-500 GB/s range and NOT 1 TB/s - quoting the 1 TB/s as a per-direction rate would overstate it by roughly 4x. Confidence is set low for this reason plus the absence of a UCIe specification document in the retrieved sources. If you need an exact figure, get the UCIe-Advanced specification and the lane count from the Rebel100 datasheet.
Topology
FULL-CHIP MESH, and this is the distinguishing property. All four homogeneous chiplets of one Rebel100 are connected by a full-mesh on-chip fabric over UCIe-Advanced, so the four present to software as a single virtual die with no software-visible boundary and no I/O bottleneck - the vendor's explicit claim. At 11 ns latency that is roughly a register-to-register hop. The mesh is backed by hardware-accelerated full-mesh synchronization across 256 cores. Contrast with amd-xgmi, which is also a die-to-die mesh but only 2 or 8 dies, and with every GPU part in this repo, where crossing between devices is a real and measurable cost.
Scale-up
no
Scale-out
no
Switching
None, and none is needed: the fabric is contained within a single package. The Rebel100's external interfaces are separate and covered by pcie-gen5 for host attach; there is no Rebel100-specific scale-out fabric in the sources retrieved.
notes
The chiplet interconnect for the Rebel100, and the one part in this repo where the inter-chiplet link rather than the memory is the architectural story. PUBLISHED (Rebellions Rebel100 product page): 4 homogeneous chiplets on UCIe-Advanced, 'Chiplet Interface (UCIe-A) 16 Gbps, 1 TB/s per channel', full-chip on-chip mesh at '1TB/s per channel bi-directional bandwidth with just 11ns latency', 'Chiplets operate as one virtual die - no software changes, no I/O bottlenecks', and hardware-accelerated full-mesh synchronization across 256 cores. External side: 'PCIe Interface 2x PCIe Gen5 x16', HBM3E 144 GB at 4.8 TB/s, up to 600 W. THE UNITS WARNING, which is the most important thing in this record: '1 TB/s per channel' is a BIDIRECTIONAL figure and the typed bandwidth_gbps here is the per-direction one, so do not quote 1 TB/s per direction. As noted in bandwidth_basis the vendor's own 16 Gbps signal rate and its 1 TB/s prose do not reconcile exactly, and both readings are retained - this is why the record is status draft with confidence 0.55 rather than verified. INFERENCE RELEVANCE, and why 11 ns matters more than the raw bandwidth: at 11 ns the four chiplets are effectively one device, so a sharding scheme can treat a Rebel100 as a single 144 GB memory pool without paying a fabric penalty at every layer boundary. That is the mechanism behind the vendor's 'no stalls in sparse or imbalanced workloads' claim - if the fabric hop is free relative to the compute, work-stealing and dynamic load balancing across chiplets do not stall on communication. It also means the usual argument against splitting a model across devices (that crossing the fabric every layer is expensive) does not apply WITHIN a Rebel100 package. Against 4.8 TB/s of HBM3E, 144 GB of capacity is enough to hold a large model resident, which is the combination large-model inference actually wants - so this part is memory-bound at batch 1 (213 FLOP/byte FP16, 427 FP8) but not fabric-bound. The other optimization here is software-visible rather than fixed: the predictive DMA engine prefetches KV data ahead of the matrix units and the vendor claims 2.7 TB/s effective bandwidth for that path - a different quantity from the 4.8 TB/s HBM figure, and recorded on the accelerator record rather than here. KIND: filed as 'other' because UCIe-Advanced on-chip mesh is not a member of any named family in the schema's interconnect enum; it is a die-to-die link, not a scale-up fabric, which is why scale_up is false here despite it being an interconnect.
way
each

Notes

The chiplet interconnect for the Rebel100, and the one part in this repo where the inter-chiplet link rather than the memory is the architectural story. PUBLISHED (Rebellions Rebel100 product page): 4 homogeneous chiplets on UCIe-Advanced, 'Chiplet Interface (UCIe-A) 16 Gbps, 1 TB/s per channel', full-chip on-chip mesh at '1TB/s per channel bi-directional bandwidth with just 11ns latency', 'Chiplets operate as one virtual die - no software changes, no I/O bottlenecks', and hardware-accelerated full-mesh synchronization across 256 cores. External side: 'PCIe Interface 2x PCIe Gen5 x16', HBM3E 144 GB at 4.8 TB/s, up to 600 W. THE UNITS WARNING, which is the most important thing in this record: '1 TB/s per channel' is a BIDIRECTIONAL figure and the typed bandwidth_gbps here is the per-direction one, so do not quote 1 TB/s per direction. As noted in bandwidth_basis the vendor's own 16 Gbps signal rate and its 1 TB/s prose do not reconcile exactly, and both readings are retained - this is why the record is status draft with confidence 0.55 rather than verified. INFERENCE RELEVANCE, and why 11 ns matters more than the raw bandwidth: at 11 ns the four chiplets are effectively one device, so a sharding scheme can treat a Rebel100 as a single 144 GB memory pool without paying a fabric penalty at every layer boundary. That is the mechanism behind the vendor's 'no stalls in sparse or imbalanced workloads' claim - if the fabric hop is free relative to the compute, work-stealing and dynamic load balancing across chiplets do not stall on communication. It also means the usual argument against splitting a model across devices (that crossing the fabric every layer is expensive) does not apply WITHIN a Rebel100 package. Against 4.8 TB/s of HBM3E, 144 GB of capacity is enough to hold a large model resident, which is the combination large-model inference actually wants - so this part is memory-bound at batch 1 (213 FLOP/byte FP16, 427 FP8) but not fabric-bound. The other optimization here is software-visible rather than fixed: the predictive DMA engine prefetches KV data ahead of the matrix units and the vendor claims 2.7 TB/s effective bandwidth for that path - a different quantity from the 4.8 TB/s HBM figure, and recorded on the accelerator record rather than here. KIND: filed as 'other' because UCIe-Advanced on-chip mesh is not a member of any named family in the schema's interconnect enum; it is a die-to-die link, not a scale-up fabric, which is why scale_up is false here despite it being an interconnect.

Cross-references

This record references no other records — it is a leaf. It is cited by 2.