High-performance computing is often discussed in terms of components.
Faster memory.
More capable accelerators.
More advanced packaging.
Higher-bandwidth interfaces.
Each matters.
But there is another variable running through all of them: the physical movement of information between where data is stored and where it is used.
That movement has distance.
It has geometry.
It occupies shoreline and routing area.
It consumes power.
It creates thermal consequences.
It crosses physical boundaries.
And it places requirements on signaling, packaging, equalization, regeneration, and sometimes conversion.
Those are usually treated as consequences of an architecture that has already been chosen.
But increasingly, the relationship appears to run in both directions.
The architecture determines the path.
And the path helps determine the architecture.
Every Architecture Inherits Transport Assumptions
Before a system is physically realized, assumptions about data movement are already embedded within it.
How far can a signal travel?
How much bandwidth must cross a particular boundary?
How much physical shoreline is available?
What interface width can the package support?
What signaling rate is required?
How much power can be spent moving and preserving information?
Where must equalization, retiming, regeneration, or conversion occur?
These questions may appear to belong to the interconnect.
Their consequences do not stay there.
They influence where memory can sit relative to compute.
They affect how packages are partitioned.
They consume routing and power-delivery resources.
They influence thermal design.
They determine which boundaries can be crossed electrically and where another transport regime may become necessary.
Published interface data reinforces that these variables are coupled rather than independent. Changes in reach can be accompanied by changes in interface width, signaling rate, bump pitch, energy per bit, and packaging structure.
So what begins as a transport assumption can eventually become an architectural boundary.
Reach Is Not Just Distance
Consider reach.
It is tempting to think of reach as a simple geometric quantity: how far information must travel from one point to another.
But changing reach changes more than length.
At package scale, shorter physical distances can support finer-pitch interfaces, wider parallelism, and lower interface energy.
Longer reach may require different signaling rates, different interface widths, different routing structures, and different packaging choices.
That makes reach an architectural variable.
Not because distance itself is architecture.
But because the system must adapt to what that distance requires.
Shorter Does Not Mean Constraint-Free
The opposite conclusion would also be a mistake.
If reducing distance lowers one transport burden, the problem does not necessarily disappear.
It may move.
HBM illustrates this particularly well.
Its memory-to-compute electrical path is already extremely short. Yet as the architecture scales, pressure appears elsewhere: shoreline density, routing complexity, power delivery, thermal concentration, bump pitch, assembly, and yield.
The research explicitly cautions against describing short reach as elimination of the interconnect problem. Its recommended framing is that shorter reach can move the dominant cost from link energy toward bump pitch, power delivery, thermal behavior, and assembly yield.
That is an important distinction.
An architectural improvement often does not remove a constraint.
It changes which constraint dominates.
Moving Memory Changes More Than the Memory Path
The same principle appears when memory is brought progressively closer to compute.
Shortening the channel may reduce electrical transport energy and latency.
But increasing physical proximity can intensify thermal coupling and power-density challenges.
The research identifies this explicitly in emerging memory architectures: tighter memory/compute co-location can shorten the electrical channel while simultaneously concentrating heat and creating new cooling requirements.
This is why memory placement cannot be evaluated independently from transport.
Nor can transport be evaluated independently from packaging.
Or packaging from power.
Or power from thermals.
The variables are coupled.
The report therefore concludes that packaging, transport, power, thermals, and compute placement cannot be considered independently.
That is an architectural statement, not merely an interconnect observation.
The Path Is Larger Than the Link
A useful way to see this is to stop thinking about “the interconnect” as a single object.
A bit moving from memory toward computation may cross a sequence of physical structures:
the DRAM array, internal bitlines, memory-die I/O, TSVs or hybrid bonds, a base or logic die, an interposer or bridge, package substrate, and finally the compute die.
Beyond that, data may cross package-to-package links, boards, scale-up fabrics, coherent-memory links, and electrical-to-optical boundaries.
Each boundary has different physics.
Each creates different constraints.
And architectures can remove, compress, relocate, or redesign some of those boundaries.
That means the useful design question is no longer simply:
How fast is the connection?
It becomes:
What physical path does the architecture require data to traverse—and what does that path force the rest of the system to become?
Change the Path. Change the Design Space.
If a transport constraint changes materially, the architecture may gain choices it did not previously have.
Memory and compute may no longer require the same proximity.
Interface width and signaling rate may take different forms.
Package boundaries may move.
Routing resources may be redistributed.
Power and thermal budgets may be reassigned.
An electrical boundary may move.
In some environments, an electrical path may remain appropriate for longer.
In others, the architectural crossover to optical transport may occur sooner.
The point is not that one transport technology universally replaces another.
The point is that changing the physical assumptions behind data movement can change the set of architectures that are physically practical.
That is what makes transport a design variable.
Architecture Before Technology
This leads to a different design sequence.
Instead of beginning with a preferred component or transport technology and asking where it can be inserted, begin with the system:
What computation must occur?
Where must the data reside?
How much of it must move?
Across what distance?
Across which boundaries?
At what bandwidth density?
At what energy and thermal cost?
Only then does the technology question become meaningful.
Because an architecture is not simply a collection of components.
It is also the set of physical relationships that allows those components to work together.
And transport is one of those relationships.
The architecture comes before the technology.™
At Mitas Electronics, we are examining how the physical movement of data shapes the architectures being built around memory, compute, packaging, and emerging electrical-to-optical boundaries.
Because before asking how fast information can move, there may be a more fundamental question:
What could the architecture become if the assumptions governing that movement were different?