A Better Path Is Not Yet a Better Architecture
A new transport path may offer lower loss.
Greater reach.
Higher bandwidth.
Improved energy efficiency.
A smaller physical footprint.
Each can be technically meaningful.
But none proves, by itself, that the surrounding architecture has gained a useful new choice.
The improvement may be consumed elsewhere.
Greater reach may require additional conversion, control or validation.
Higher bandwidth may increase power density or thermal concentration.
Lower loss may arrive with packaging requirements that reduce placement freedom.
A smaller transport element may depend upon supporting structures that occupy area elsewhere in the system.
The link can improve while the architecture remains unchanged.
It can even improve while the system inherits a different version of the original constraint.
The relevant question is therefore not only:
Does the new path perform better?
It is:
What can the architecture now do that it could not do before?
The Argument Began at the Memory Wall
This discussion began with a familiar challenge.
The demand for memory bandwidth is increasing as AI and high-performance computing systems scale.
But bandwidth is not delivered as an abstract number.
It must traverse a physical path between memory and compute.
That path has geometry.
It occupies area.
It consumes power.
It affects thermal behavior.
It depends upon routing, return structures and signal margin.
And it has finite physical reach.
As bandwidth density increases, these characteristics begin influencing where memory and compute can be placed, how packages must be organized and which topologies remain physically viable.
The memory problem therefore becomes an architecture problem.
The interface can no longer be treated as a passive boundary between independently optimized components because the conditions imposed by the path propagate into the systems on both sides.
Transport begins participating in system definition.
That realization turns the original question around.
If today’s architecture has adapted to the limits of today’s transport path, what could change if some of those limits changed?
Placement and Movement Are Coupled Decisions
Architectural freedom is not only the ability to place memory and compute differently.
It is also the ability to reconsider where computation should occur, which information must move and which movement the architecture can avoid.
Moving computation closer to the information it requires may reduce transport demand.
Changing memory placement may shorten one portion of the path while creating new requirements elsewhere.
Partitioning functions differently may reduce repeated movement across one boundary while increasing coordination across another.
These are not independent choices.
Where computation occurs affects what data must move.
What data must move affects the transport path.
And the physical requirements of that path influence which placements remain feasible.
Once those decisions have been made, the information that still must move must preserve its value across every physical boundary it encounters.
Changing the Physics Does Not Eliminate the Boundary
Different portions of a computing system may naturally favor different physical transport regimes.
The relevant question is not whether one form of transport should replace every other form.
It is where each regime belongs within the complete architecture.
There may be no universally correct point at which electrical transport should yield to optical transport.
The appropriate boundary depends upon the workload, physical scale, bandwidth density, latency, energy, thermal environment, manufacturability and operating requirements of the complete system.
As optical transport moves closer to memory or compute, the electrical path may become shorter—but the system problem does not disappear.
Electrical reach, optical delivery, fiber routing, packaging, thermal behavior, testability and serviceability become increasingly coupled.
The boundary has moved, and the architecture must now absorb a different distribution of requirements.
Whenever data crosses from one physical regime into another, a handoff is created.
That handoff must preserve more than the intended bits.
It must preserve the physical viability of the complete path and the architectural value that motivated the change.
A successful conversion may demonstrate that a signal can change form.
It does not necessarily demonstrate that latency, bandwidth density, power, thermal behavior, signal margin, timing predictability or physical footprint remain acceptable end to end.
Nor does it prove that the architecture retained the placement freedom, reach, density or topology the new regime was expected to enable.
Conversion is therefore not the final standard.
Continuity is.
The information must survive.
The complete path must remain physically viable.
And the system must retain the architectural advantage that justified changing regimes.
Signal Integrity Has an Architectural Consequence
Signal integrity is not only a link-level measure of whether information can be recovered at an observation point.
At the architectural level, it helps determine how much compensation, power, margin, control and physical accommodation the complete path requires.
Loss, reflections, coupling and mode conversion do not remain isolated waveform concerns when the system must allocate equalization, regeneration, power, thermal capacity or additional validation to manage them.
Those resources come from the same architectural budget used for memory, compute, packaging and cooling.
Signal integrity therefore affects more than whether the path functions.
It helps determine which system configurations remain practical.
The Feasible Design Space Is the Measure
Architectural freedom is not the number of configurations that can be imagined.
It is the number that can actually satisfy the complete requirement set.
A configuration becomes feasible only when bandwidth, latency, reach, energy, thermal behavior, density, signal margin, reliability and manufacturability can be achieved together.
Improving one metric may move one boundary while tightening another.
Greater reach is not architecturally useful if the power required to obtain it exceeds the system budget.
Higher transport density may not expand the design space if it creates an unmanageable thermal concentration.
A successful handoff may not create additional freedom if its control and validation requirements offset the intended benefit.
A configuration that performs in isolation but cannot be manufactured, tested, integrated or serviced within practical system constraints has not meaningfully expanded the feasible design space.
The strongest evidence of a changed path is therefore not an isolated transport result.
It is the appearance of viable system configurations that were previously excluded.
Can memory and compute be separated differently?
Can computation occur closer to the information it requires?
Can unnecessary data movement be reduced?
Can functions be partitioned across packages or modules in a new way?
Can routing resources be reassigned?
Can power or thermal capacity return to computation?
Can the handoff occur at a different point in the system?
Can the topology change while the full performance and reliability requirements remain satisfied?
These are architectural outcomes.
They reveal whether an improvement in transport has become an improvement in the system.
Architectural Freedom Appears as New Choices
When transport requires less from the surrounding architecture, resources can become available for other purposes.
Less area consumed by the path may create placement freedom.
A lower power or thermal burden may preserve capacity for memory or compute.
Greater practical reach may allow components to be organized at different physical scales.
Reduced routing, control or validation requirements may expand the range of viable packaging strategies.
A handoff that preserves continuity with fewer supporting requirements may allow the boundary between physical regimes to move.
None of these consequences should be assumed.
Moving a boundary does not make its cost disappear.
It can redistribute latency, energy, thermal load, complexity and validation responsibility into another part of the system.
The complete architecture must still satisfy the complete requirement set.
But a boundary that can move without recreating the original constraint becomes an architectural variable rather than a fixed accommodation.
That is where transport improvement begins to create design freedom.
Architecture, Transport and Components Must Be Evaluated Together
This is the purpose of the Mitas Architecture-Transport-Components Framework™:
Architecture ↔ Transport ↔ Components
The arrows are bidirectional because the relationships are bidirectional.
Architecture establishes what data must move, where it must move, how far it must travel and which system resources may be consumed.
Transport determines which of those movements are physically viable and under what operating conditions.
Components implement the required functions, but their placement, packaging and operation are influenced by both the architecture and the path connecting them.
A component cannot be evaluated independently of the transport conditions required to use it.
A transport technology cannot be evaluated independently of the architectural resources required to support it.
And an architecture cannot be considered independently of the physical path through which its information must move.
The three must be examined as a coupled system.
Evidence Must Reach the Architectural Consequence
Claims about a new path should be supported at the level where the claimed value occurs.
A transport-performance claim requires evidence about the physical behavior of the path.
A continuity claim requires evidence across the complete route, including the handoffs into and out of each physical regime.
An architectural claim requires evidence that the system receives a meaningful new choice.
That progression matters:
- Does the transport mechanism perform under relevant operating conditions?
- Does the complete path preserve information and physical viability?
- What compensation, area, power, thermal capacity, latency, control and validation does it require?
- Can the path be manufactured, tested and integrated within practical constraints?
- Which system configurations become feasible under those requirements?
- What architectural capability results?
The evidence should follow the claim all the way from physical behavior to architectural consequence.
Otherwise, a promising local result can be mistaken for a system-level advantage that has not yet been demonstrated.
Why Mitas Is Asking These Questions
Mitas is examining how changes in transport physics could alter the assumptions future computing architectures must carry.
That inquiry does not begin with a preferred connector, package, signaling method or universal choice between electrical and optical transport.
It begins with the system.
Where should computation naturally occur?
What data must still move?
Where must it move?
How far must it travel?
Which physical regime is naturally suited to each portion of the path?
Where should the boundary between those regimes reside?
What must survive when the physics changes?
And how much should the complete transport path require from the architecture around it?
These questions establish the conditions against which technologies should be evaluated.
They also protect against optimizing a component or conversion point while overlooking the burden transferred to the rest of the system.
The Architecture Is the Result That Matters
A new transport path may be faster, longer, denser or more efficient.
Those improvements matter.
But their architectural value depends upon what remains after every handoff, supporting structure and system requirement has been accounted for.
If the complete path preserves information, remains physically viable and requires less accommodation from the surrounding system, it may expand the feasible design space.
That expansion can create new choices in computation placement, memory placement, partitioning, packaging, physical boundaries and topology.
And those choices—not the isolated transport metric—are the larger result.
The value of a new path is ultimately the architecture it makes possible.
What architecture becomes feasible when the path no longer requires the system to organize itself in the same way?
Mitas Electronics
Engineering the future of high-speed data transport.
Understand Deeply. Engineer Thoughtfully. Advance Continuously.