Architectural Reasoning and Tradeoff Synthesis

Architectural Reasoning

The process of choosing and evaluating hardware organizations according to the consequences they create relative to system requirements.

Design Judgment

The ability to choose among multiple correct implementations by reasoning about their engineering tradeoffs.

Correct Function + Appropriate Architecture

Two requirements of a strong digital design: the machine must compute the right behavior and organize hardware in a way that fits system goals.

Functional correctness alone does not determine the best architecture.

What central Part 10 lesson must be retained at the end of DSD-I?

Several implementations can be correct while differing substantially in engineering suitability.

Why must an architect reason beyond logical correctness?

Requirement-Driven Architecture

An architectural choice made according to the needs and constraints of the intended system.

The best architecture is the one that best matches the requirements.

What replaces the idea of a universally best digital architecture?

No Universal Best Architecture

The principle that architectural superiority depends on system goals rather than one absolute metric.

“Faster” is not automatically better if the system cannot afford the additional resource or implementation cost.

Why is architecture always requirement-dependent?

“Smaller” is not automatically better if the resulting design cannot meet required performance.

Why is minimum area not universally optimal?

“More parallel” is not automatically better if available concurrency is unnecessary or prohibitively expensive.

Why is maximum parallelism not universally optimal?

“More modular” is not automatically better if the additional boundaries create excessive interface cost.

Why is maximum decomposition not universally optimal?

Architecture is the organization of compromises required to satisfy a particular system.

What broad engineering perspective should replace single-metric optimization?

Engineering Currency

A design quantity such as area, latency, throughput, timing, power, complexity, or flexibility that can improve or worsen depending on architecture.

Competing Engineering Currencies

The reality that improving one architectural metric can consume or degrade another.

Area, latency, throughput, timing, power, and complexity.

What kinds of quantities compete during architecture selection?

Tradeoff

A design situation in which gaining an advantage in one dimension creates cost or disadvantage elsewhere.

Architecture is largely the art of managing tradeoffs.

Why?

Hardware resources and time are finite, so architectural choices redistribute cost rather than eliminate it.

What physical reality creates tradeoffs?

Architecture Objective

A property the design is intentionally trying to optimize or satisfy.

Architecture Constraint

A limit the design must not violate.

Objectives and constraints are not the same.

What distinction should an architect make before comparing alternatives?

“Minimize latency” is an objective.

What kind of design statement is “minimize latency”?

“Must fit in the selected FPGA” is a constraint.

What kind of design statement is “must fit in the device”?

“Must accept one new result every cycle” is a performance requirement.

What kind of architectural requirement is this?

“WIDTH must support 8 through 32 bits” is a configurability requirement.

What kind of requirement is this?

Requirement Hierarchy

The relative importance of competing system goals and constraints.

Why should requirements be prioritized?

When metrics conflict, the architect needs to know which ones matter most.

Hard Constraint

A requirement that must be satisfied for the design to be acceptable.

Soft Objective

A desirable property that may be traded against other goals.

A design violating a hard requirement is unacceptable even if it excels elsewhere.

Why should hard constraints be identified first?

Design Space

The set of plausible architectures that could satisfy the required function.

Architecture Candidate

One possible hardware organization within the design space.

Architecture Comparison

The deliberate evaluation of candidate architectures using common requirements and metrics.

A good architecture decision usually compares alternatives rather than evaluating one implementation in isolation.

Why?

Comparison Baseline

A common functional requirement or implementation condition used so candidate architectures can be compared fairly.

Functional equivalence is useful as a baseline when comparing different architectures.

Why?

If two machines compute the same required function, differences in their implementation consequences become meaningful design evidence.

What does a common functional baseline allow?

Architecture Selection

The decision to choose one candidate implementation after comparing its consequences with requirements.

Architecture selection should be justified rather than habitual.

What distinguishes design judgment from simply using a familiar circuit?

Design Habit

Choosing an architecture because it is familiar rather than because its tradeoffs match the requirements.

Why can design habit be dangerous?

A familiar architecture may be correct but inappropriate for the current constraints.

Design Rationale

The explicit reasoning explaining why one architecture was selected over alternatives.

A strong engineer should be able to explain why the architecture exists in its chosen form.

What evidence of design judgment should accompany implementation?

“Because it works” is insufficient architectural rationale.

Why?

Multiple other implementations may also work while having very different system consequences.

What makes functional success alone weak justification?

Architecture Consequence

A predictable effect of an organizational choice on hardware cost, performance, timing, control, verification, or scalability.

Architectural reasoning moves repeatedly from choices to consequences.

What thought pattern should become habitual?

Choice → Consequence

Core architecture reasoning pattern in which each structural decision is connected to its likely engineering effects.

“Use parallel hardware” should immediately trigger what reasoning?

What additional resources and physical consequences does that choice create?

“Share a resource” should immediately trigger what reasoning?

What scheduling, contention, and performance consequences follow?

“Make it wider” should immediately trigger what reasoning?

What logic, storage, routing, timing, and verification consequences follow?

“Add a controller” should immediately trigger what reasoning?

What temporal complexity requires it and what control cost is introduced?

“Add another module” should immediately trigger what reasoning?

Does the new boundary improve responsibility separation enough to justify interface cost?

Architecture Prediction

The ability to anticipate implementation tendencies before detailed synthesis or physical implementation.

DSD-I develops prediction before exact measurement.

What level of architectural skill does DSD-I emphasize?

Prediction is not the same as measurement.

What distinction should a designer maintain when making architectural claims?

Architectural Prediction

An expectation based on hardware organization, such as “this choice is likely to increase routing demand.”

Physical Measurement

A result obtained after synthesis, placement, routing, or hardware testing.

Architectural predictions should eventually be tested against physical evidence.

What should happen after implementation?

Prediction Error

The difference between expected architectural consequences and measured results.

Prediction error is useful feedback.

Why?

It improves the designer's future ability to reason about implementation consequences.

What is learned when synthesis contradicts an architectural expectation?

Evidence-Based Revision

Changing architecture because measured behavior or implementation results reveal that assumptions were wrong or requirements are unmet.

A professional design process allows architecture to be revised.

Why?

Initial architecture is a hypothesis about how requirements can be satisfied.

How should early architecture be viewed?

Architecture Hypothesis

A proposed organization expected to satisfy behavior and engineering constraints.

Implementation provides a test of the architectural hypothesis.

What role does building the design play?

Measurement provides evidence about whether the hypothesis was correct.

What role do synthesis and implementation results play?

Revision closes the architecture-learning loop.

What happens when evidence reveals unacceptable consequences?

Architecture Iteration

The repeated cycle of choosing, implementing, measuring, and revising a design.

Good digital design is often iterative rather than one-shot.

Why?

Exact implementation effects are not always predictable perfectly before synthesis and physical placement.

Why is iteration necessary even for experienced designers?

Design Loop

The complete process of moving from requirements through architecture, implementation, measurement, and revision.

REQUIREMENTS → CHOOSE ARCHITECTURE → PREDICT CONSEQUENCES → IMPLEMENT & VERIFY → SYNTHESIZE / PLACE / ROUTE / MEASURE → REVISE

What is the Part 10 architectural design loop?

Requirements

What begins the DSD-I architectural design loop?

Choose Architecture

What follows identification of requirements?

Predict Consequences

What should happen immediately after selecting a candidate architecture?

Implement & Verify

What phase tests whether the selected architecture has been expressed correctly and behaves as intended?

Synthesize / Place / Route / Measure

What phase reveals actual physical implementation consequences?

Revise Architecture

What should happen if measurements conflict with requirements?

Requirements again

Where does architectural revision ultimately reconnect in the design loop?

Requirements → Architecture

The transition from what the system needs to how the machine will be organized.

Architecture → Prediction

The transition from structural choice to expected consequences.

Prediction → Implementation

The transition from reasoning to a concrete RTL machine.

Implementation → Measurement

The transition from described hardware to physical evidence.

Measurement → Revision

The transition from evidence back to architecture.

Architecture is therefore a feedback process.

What does the complete design loop demonstrate?

Requirement Interpretation

The process of translating system goals into architectural decisions.

“High throughput required” might motivate what kind of architectural investigation?

Whether greater concurrency or pipelining is justified.

“Very limited hardware resources” might motivate what kind of investigation?

Whether resource sharing or iterative computation is appropriate.

“Low response time required” might motivate what kind of investigation?

Which architecture minimizes relevant physical-time latency.

“Future WIDTH growth expected” might motivate what kind of investigation?

Whether parameterization and scalability are strong enough.

“Internal implementation expected to evolve” might motivate what kind of investigation?

Whether stable modular boundaries can isolate change.

Architecture Question Set

A set of alternative-structure questions used when translating requirements into a machine.

Parallel or iterative?

What Part 10 design question asks whether work should be distributed in space or across time?

Dedicated or shared?

What Part 10 design question concerns whether functional resources receive separate hardware or reuse?

Narrow or wide?

What Part 10 design question concerns representation size and hardware growth?

Combinational or registered?

What Part 10 design question concerns whether transformations cross clock boundaries?

Simple datapath or datapath + controller?

What Part 10 design question concerns whether temporal sequencing requires explicit control state?