The Interface Was Supposed to Connect the Architecture
Interfaces are traditionally treated as boundaries.
Memory performs one function.
Compute performs another.
The interface moves information between them.
That abstraction is useful because it allows different parts of a system to be designed, optimized and evolved with some degree of independence.
But increasing bandwidth density is making that separation harder to maintain.
The physical path between memory and compute has geometry.
It requires area.
It consumes power.
It affects thermal behavior.
It requires routing and return structures.
It introduces loss, reflections and coupling.
And it has finite physical reach.
At sufficiently demanding operating conditions, those are no longer merely characteristics of the connection.
They become conditions the architecture must accommodate.
When the Boundary Begins Shaping Both Sides
Consider what happens when those conditions propagate outward.
Memory placement affects the physical path.
The path influences signaling requirements.
Signaling influences power.
Power affects thermal behavior.
Packaging determines routing density and geometry.
Those constraints influence where components can be placed and how the overall system can be organized.
The interface is therefore not isolated between two independently optimized systems.
The systems begin adapting around it.
This creates an important distinction:
An interface connects architectures.
An architectural interface helps determine them.
That distinction becomes increasingly important as the amount of data moving between memory and compute continues to grow.
Transport Has an Architectural Cost
Bandwidth is usually expressed as a performance metric.
But physically delivering bandwidth requires resources.
Area.
Power.
Thermal headroom.
Routing capacity.
Signal margin.
Package complexity.
And design freedom.
Those resources are also the resources from which architectures are built.
Every additional requirement imposed by the physical transport path therefore competes with something else the system could have done with the same architectural budget.
That changes the question.
Instead of asking only:
How much bandwidth can this interface provide?
We may increasingly need to ask:
What architecture is required to physically deliver that bandwidth?
And perhaps more importantly:
What architectural choices are being made because of the limitations of the transport path itself?
The Interface Is Becoming the System
This does not mean the interface literally replaces memory, compute, packaging or the rest of the system.
It means the distinction between component architecture and transport architecture is becoming harder to maintain.
When transport influences placement, geometry, power delivery, thermal strategy, routing density, signal integrity and topology, it is participating in system definition.
That suggests a different design sequence.
Rather than:
Architecture → Components → Interface
some high-bandwidth systems may increasingly require:
Architecture ↔ Transport ↔ Components
The arrows matter.
Transport is no longer simply an implementation detail downstream of architectural decisions.
It becomes one of the inputs to those decisions.
Architecture Before Technology
This brings us back to the principle behind this discussion.
The objective should not be to begin with a preferred connector, signaling method, packaging technology, memory architecture—or even electrical versus optical transport.
Those are technology choices.
The architectural question comes first:
What data must move, where must it move, how far must it move, and what physical resources should that movement be allowed to consume?
Only then can we determine where different transport technologies naturally belong.
That is why the boundary matters.
Because if the physical path helps determine the architecture on both sides, understanding that path becomes part of understanding the system itself.
And that leaves us with a more consequential question:
If today’s transport physics helps determine today’s architecture, what could become possible if the transport constraint itself changed?
Mitas Electronics
Engineering the future of high-speed data transport.